v0.6.0: symbolize unit test fails again in Release mode

When building and testing glog v0.6.0 in Release mode, the unit test of symbolize fails. If I build and test in Debug mode, it succeeds. This was previously mentioned in this issue https://github.com/google/glog/issues/435 and was fixed in v0.5.0. I also tried it in v0.5.0 and there, it succeeds in both Release and Debug mode.
Built with Ubuntu 20.04.5, g++-9.

Our CI runs tests both in debug and release mode and does not exhibit the described problem. The failure is likely specific to your setup and therefore we need a full reproducer.

I'm running it in a basic VSCode Devcontainer:
devcontainer.json:
{
	"name": "Ubuntu",
	"image": "ubuntu:20.04",

	"settings": {
		"terminal.integrated.defaultProfile.linux": "bash"
	},
        "postCreateCommand": "apt-get update && apt-get -y install git build-essential cmake",
        "customizations": {
               "vscode": {
                     "extensions": ["ms-vscode.cmake-tools", "ms-vscode.cpptools-themes", "ms-vscode.cpptools-extension-pack", "twxs.cmake", "ms-vscode.cpptools", "cschlosser.doxdocgen"]
        }
    }
}

and CMakeLists.txt:
cmake_minimum_required(VERSION 3.16)

project(test_proj VERSION 0.0.1 LANGUAGES CXX)

option(WITH_GFLAGS OFF)
option(BUILD_SHARED_LIBS OFF) # for GLOG
set(CMAKE_BUILD_TYPE Release)

include(FetchContent)

FetchContent_Declare(
  googletest
  GIT_REPOSITORY https://github.com/google/googletest.git
  GIT_TAG        release-1.11.0
)

FetchContent_Declare(
  glog
  GIT_REPOSITORY https://github.com/google/glog
  GIT_TAG        v0.6.0
)

FetchContent_MakeAvailable(glog)
FetchContent_MakeAvailable(googletest)

enable_testing()
include(GoogleTest)

Thanks. This issue is duplicate of #630.

Oh, ok. However, here I think WITH_GTEST is ON per default and the problem has to do with the Release mode compared to the linked issue. But may be the same issue in the end.

WITH_GTEST is not the problem (see the discussion). TL;DR: either set BUILD_SHARED_LIBS=ON or WITH_TLS=OFF.


TOSCA IDE - Message warning to check the TOSCA

Related to #367 .
While the TOSCA IDE is not able to detect errors it should show a message saying something like:
"Don't forget to check the TOSCA file generated in case there are some errors."

Not useful and not so stylish.
Applications should raise errors or do their job.

This warning will have to go on the manual


C++ IntelliSense works fine except for PCL (Point Cloud Library)

VSCode Version: 1.47.2
OS Version: Ubuntu 18.04 LTS (also, Ubuntu 16.04 LTS)

Steps to Reproduce:
Step 1:
I'm already using C/C++ Extension by Microsoft and IntelliSense works fine for all the different in-built classes, functions, STLs, etc. But, when it comes to PCL (Point Cloud Library), somehow, mysteriously, IntelliSense doesn't work.
If you are familiar with PCL then must be knowing that most of its syntaxes are too big. And as the IntelliSense not working for it, there are very high chances of making typos if you don't pay close attention while typing every single character, e.g.,
pcl::PointCloud<pcl::PointXYZRGB>::Ptr point_cloud_ptr (new pcl::PointCloud<pcl::PointXYZRGB>);

In fact, auto-completion for even those variables and functions do not work--i.e., from the above example, I have to manually type every single character of point_cloud_ptr every time I want to use it.
So, how can I fix this? or it's not possible for PCL?

Step 2:
Previously, my c_cpp_properties.json was like this:
{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "gnu11",
            "cppStandard": "gnu++14",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}

All the Header files for PCL library are located at /usr/include/pcl-1.8/pcl/ so as per the documentation on IntelliSense for cross-compiling, I tried modifying my c_cpp_properties.json file like this:
.
.
           "includePath": [
                "${workspaceFolder}/**",
                "/usr/include/pcl-1.8/"
            ],
.
.

and like this:
.
.
           "includePath": [
                "${workspaceFolder}/**",
                "/usr/include/pcl-1.8/*"
            ],
.
.

and like this:
.
.
           "includePath": [
                "${workspaceFolder}/**",
                "/usr/include/pcl-1.8/**"
            ],
.
.

and even like this:
.
.
           "includePath": [
                "${workspaceFolder}/**",
                "/usr/include/pcl-1.8/pcl/"
            ],
.
.

But, none of the above modifications worked :(

Does this issue occur when all extensions are disabled?: N/A

Sorry, I missed that guidelines and thanks for the suggestion.
If someone else is also facing this issue and came across this page then go to https://github.com/microsoft/vscode-cpptools/issues/5843. I have created a new issue over there!


UI: incoming transactions out of order

Restarted the client inbetween a few times and the transaction history is out of order, see "Date":

This is actually intersting, because I tested
ui->txHistoryTable->setSortingEnabled(true);

... earlier, which worked for all fields, except the date field, so it looks like there is something slightly off. But might as well be unrelated, didn't look further into it at that point.

You mentioned a hidden tab with transaction ids. Could we have another hidden tab with the absolute position of a transaction, as of "block - position within block" and use that as sorting anchor? And somehow maybe even bind that to the "confirmation" or "date" column, to be able to handle sorting?

Yeah I can do, but it shouldn't be required (since there is no model behind this, it's a basic table and stuff gets added in wallet order (we iterate over wallet).  I think it'll be related to https://github.com/zathras-crypto/mastercore/issues/34

I roughly understand the process:

transactions are fetched from the wallet
parsed
inserted into the history

What makes me wonder: instead of clearing the history and really inserting the elements one by one, they are replaced and in the background it looks as if there is some caching ongonig. This is probably good, and clearing and inserting every entry each time is likely much more time consuming, but the actual update/insert process isn't very clear to me, and this is probably where old entries are not correctly updated, or have outdated data, or are replaced in the wrong order.

To resolve this issue, it looks like a more accurate sorting key is required.
Core uses an extra object to represent an entry, but related to this issue, the sorting key used in transactionrecord.cpp#L162-L167:
// Sort order, unrecorded transactions sort to the top
status.sortKey = strprintf("%010d-%01d-%010u-%03d",
    (pindex ? pindex->nHeight : std::numeric_limits<int>::max()),
    (wtx.IsCoinBase() ? 1 : 0),
    wtx.nTimeReceived,
    idx);

This is not entierly viable, because we have to deal with transactions outside of the wallet as well, namely STO transactions, and therefore really just could use a key such as [block height][tx position], but if I'm not mistaken, then the transaction position within a block doesn't appear to be stored.

Been many moons since I looked at that particular code, but IIRC tx postion is stored in the CMPTransaction class?
 unsigned int tx_idx;  // tx # within the block, 0-based

Yes, but it looks like they are not set, when transactions are parsed from within the UI: txhistorydialog.cpp#L356:
int parseRC = parseTransaction(true, wtx, blockHeight, 0, &mp_obj);

Getting the position could be done this way, though it creates further overhead:
//! Returns position of a transaction within a block
inline int getPositionForEntry(const CBlockIndex* pindex, const CTransaction& tx)
{
    if (NULL == pindex) {
        return - 1;
    }
    CBlock block;
    if (!ReadBlockFromDisk(block, pindex)) {
        return - 2;
    }
    return std::find(block.vtx.begin(), block.vtx.end(), tx) - block.vtx.begin();
}

I see - how about it's position in levelDB?  That's written to in order (during parsing) - it won't give us an index specifically but it can tell us whether tx's are before/after another if they're same block?

The other alternative is to just store tx_idx when we write the TX to levelDB.

I see - how about its position in levelDB?

LevelDB entries are sorted in lexicographical order based on the keys, which are transaction ids, if I'm not mistaken.

The other alternative is to just store tx_idx when we write the TX to levelDB.

Agreed, probably the way to go. Not sure about how many places and parts are affected though. :/

Agreed, probably the way to go. Not sure about how many places and parts are affected though. :/

Yeah we'd have to be careful doing that as it means adding a field to the value we're storing for each tx.  I guess the Q is really do we need to know the index specifically, or just whether it was before or after another tx (see edits above).

This sounds as a perfect workaround actually. :)

Working on this today, will ping you when I have something :)

Actually shoot, sorry Chest has failed this morning need to look into it - hopefully will be a quick fix.

Just a quick FYI, still working on this - txhistory is in little pieces like a smashed Greek plate - rewriting it with a caching model - taking longer than I'd like and

Sorry, just ignore all that rubbish re open and closing, mouse going crazy

@dexX7 alrighty, this still isn't perfectly finished I have some work to do on the byte offset stuff and providing a sort key for that first visible column (the status icon), but other than that this should be working now.  Sort order is currently defaulted to date while I work the status/confirmations icon sortkey stuff - it's worth noting a lot of blocks on testnet come in a DeLorean which means you can have for example a transaction with 2 confirmations that has a timestamp earlier than a transaction with say 3 or 4 confirmations.
It's a pretty substantial rewrite of the history methodology; I've created an in memory map that will hold a bunch of transaction objects for each transaction in history (including outbound pending transactions) and this serves in effect as a cache for the history table.  In a nutshell:
PopulateHistoryMap() goes through all pending and wallet transactions with a first step of checking if they are already in the history map - if they are not found we parse and add the transaction to the map, otherwise we know we already have it so just move on to the next transaction (this should solve repeatedly reparsing transactions).  PopulateHistoryMap() can thus be called frequently and only result in parsing if the transaction is not already in the map.
UpdateHistory() (this is what the signals connect to) first calls PopulateHistoryMap() to make sure the map is up to date, and then iterates through the map checking if each transaction is in the history table.  If it is, again we don't need to do anything and just move on (otherwise we add it with a new row).  This should solve the repeated re-population of the history table since we only add rows when we spot new transactions via PopulateHistoryMap() and those rows are simply appended and left to the sortorder to organize.
Lastly UpdateHistory() will loop through all rows in the history table, checking just the time of the block they're in vs current chain height so it can update the confirmations icon.
TL:DR; this should result in a far more efficient methodology for transaction history and require far less compute since we should only ever parse once for each transaction, and the cache and fixes to sorting allow us to maintain the same history table without repopulating it top to bottom over and over.
Extremely limited testing, I'll continue to work trying to add a sort key using [block height] [byte offset] for that 1st visible column with the status icons, but excluding that it should be in workable for you to test if you have the time :)
Thanks
Z
https://github.com/zathras-crypto/mastercore/commit/03151b62aed4f43e6aa04ca68e345d32e6c96a06

Looks like there are still some bugs actually...

Awesome, I'll give it a try probably very soon. I peaked into the earlier version of it earlier already. :)

... which means you can have for example a transaction with 2 confirmations that has a timestamp earlier than a transaction with say 3 or 4 confirmations.

Well, should we care about timestamps at all? [block][offset] should have the highest priority for the default sorting order imho.

Well, should we care about timestamps at all? [block][offset] should have the highest priority for the default sorting order imho.

We should if sorting by date, and date is the default sort order just temporarily while I add a new [block][offset] sort order which isn't ready yet (having some issues accessing the transaction index directly).  Additionally whilst I can do it with a hidden column then it's not reselectable by the user if they choose a different sort column and want to revert.  The better way is to do it similar to the Bitcoin tab where the status icon column can also serve as a sort, which requires probably subclassing the default QT sort for that column - still looking into it...
Basically the default sort will be by [block][offset] but I haven't got that working yet :)

Ah, I see. It wasn't 100 % clear to me why, but this explains it well. Thanks. :)

With some debug info, I can see how the history map gets filled and the number of items inserted matches what I expect. Depending on the performance impact, it might make sense to have a "negative" list as well, or tag all wallet transactions with "Bitcoin/Meta" flags, so that non-meta transactions are also processed only once.

So what's missing currently is a handy way to update transaction entries, otherwise unconfirmed ones will stuck.
Check this out: https://gist.github.com/dexX7/b768f1c9b2fcbd115939
This is not sufficient, and the label etc. should be updated  as well, so I think it would be nice to have a way to manipulate entries directly.
I'm a bit puzzled:

// now we want to locate this transaction in the history table, and update its icon - here we're going to iterate rows to make sure we get the right one *starts-to-loop-over-the-rows*

... this seems pretty crude actually?

so that non-meta transactions are also processed only once.

Processing of an in-wallet TX is abandoned fairly early in the process if it's not an Omni tx using if (p_txlistdb->exists(hash)) { meaning we'll only continue working transactions that are in txlistdb so we shouldn't be reparsing non-Omni transactions either.  We do still GetTransaction non-Omni txs though in part due to the STO insertion mechanism needing blockheights to work with, but I'll take a look and see if that check can be moved even further up the logic so we don't even bother loading up non-Omni transactions to get their blockheight which would be a further optimization sure :)

So what's missing currently is a handy way to update transaction entries, otherwise unconfirmed ones will stuck.

Yep agreed, noticed that last night too.

This is not sufficient, and the label etc. should be updated as well

I'm not sure what you mean here mate - we don't have a label column in this view (only in balances do we show labels for addresses) - could you clarify what you mean by the label etc being updated?

I did not yet have done extensive testing, because I'm trying to get a deeper understanding of Qt (the documentation is golden!).

... could you clarify what you mean by the label etc being updated?

Yes, sure. So basically an unconfirmed transaction may update it's "confirmations" icons with the patch above, but it still shows unconfirmed, because only the icon was updated, basically once set here, it never changes:
https://github.com/zathras-crypto/mastercore/blob/03151b62aed4f43e6aa04ca68e345d32e6c96a06/src/qt/txhistorydialog.cpp#L397-L403
... unless the wallet is restarted, which triggers are "reprocessing".

Right I see thanks - I'm going in a slightly different direction I started last night re unconfirmed - will push up what I have soon since only minor - basically the logic is that a pending transaction has never been truly parsed by the state engine (only assumed valid pending transaction details directly added to the map), so I figured the better way to go about things would be that when a transactions blockheight switches from 0 to >0 then we should delete the pending transaction from the map and send it in to be parsed properly (since that txid has never actually been through parseTransaction at that point).

https://github.com/zathras-crypto/mastercore/commit/9b2a2a5db09a9574f08b5eac3ff29de0463718cf
Just FYI, still working it :)

... this seems pretty crude actually?

Yep it's fairly ghetto, but I hope to replace it once I'm storing the blockheight of the transaction actually within the row itself (as part of the [block][position] sort order) stuff.
This next commit should address some of the feedback raised, specifically:

We should now be linked into the signal for blocks changing, so update the confirmations icon each block regardless of whether there were Omni transactions
We should now be removing the pending transaction from the map once it confirms and put it through ParseTransaction to get the results properly
We should now be removing the pending tranasction from the table and replacing it with the parsed transaction once confirmed
We should now be coloring the alternate rows via CSS instead of manually, so the sort doesn't mess up the alternating row colors

I (think?) that addresses outstanding items and leaves just the one remaining issue of the sorting on [block][position] but please do shout if I've missed anything further.  Also in general terms, do you feel this new methodology does a good enough job of lightening the load for these history updates?  You mentioned the potential to DoS QT clients based on the old code because it did too much work repeatedly, so I'd like to see how you feel about that in the context of this new methodology.
As always, thanks :)
Z
https://github.com/zathras-crypto/mastercore/commit/1e4eb9c8cabde7706877d03d33db0ab5695e3499

So far it works perfect! It's really a joy. Hehe..
The methology is the way to go, as for further refinements in the future, I can only think about more targeted signals and at the moment. Instead of going through transactions, signals could be fired, once transactions get processed on a lower level, etc..
Let me say it this way, and this is really a great thing: we're pretty close to the state where it goes into optimization instead of fixing or building.
You asked about ordering unconfirmed transactions: since those are wallet transactions, we have access to CWalletTx->nOrderPos (remember the pending -> conflicting restart issue?). This could probably be used here.
There is some redundancy right now, if I'm not mistaken:

refreshOmniState()
-> UpdateHistory()
   -> UpdateConfirmations()
numBlocksChanged(int)
-> UpdateConfirmations()

Looks like UpdateConfirmations() is called twice and could probably be removed from UpdateHistory().

The last statement is likely not correct regarding . I'm stopping time and calls now, will update.

Ouch, there is some multiplication effect. I've run the regtests (900 blocks deep, 2500 transactions in total, maybe 1000-1500 STO recipients, but unsure, if relevant):
I'm only generating a new block between each dashed line right now, see how the UpdateConfirmations() time grows?
[Initialized] Exodus balance: 36223.19760705
    UpdateHistory() START
        PopulateHistoryMap() START
        PopulateHistoryMap() END (nProcessed: 501)
        0.654943350s wall, 0.280000000s user + 0.380000000s system = 0.660000000s CPU (100.8%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      0.660874356s wall, 0.700000000s user + 0.000000000s system = 0.700000000s CPU (105.9%)
    UpdateHistory() END
    1.452989677s wall, 1.130000000s user + 0.380000000s system = 1.510000000s CPU (103.9%)
----
ConnectTip() START
ConnectTip() STOP (tx_idx = 1, meta_txs = 0)
0.142028787s wall, 0.140000000s user + 0.010000000s system = 0.150000000s CPU (105.6%)
    UpdateHistory() START
        PopulateHistoryMap() START
        PopulateHistoryMap() END (nProcessed: 501)
        0.677251230s wall, 0.290000000s user + 0.360000000s system = 0.650000000s CPU (96.0%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      2.652630966s wall, 2.720000000s user + 0.000000000s system = 2.720000000s CPU (102.5%)
    UpdateHistory() END
    3.882380555s wall, 3.580000000s user + 0.360000000s system = 3.940000000s CPU (101.5%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      2.620557723s wall, 2.650000000s user + 0.000000000s system = 2.650000000s CPU (101.1%)
----
ConnectTip() START
ConnectTip() STOP (tx_idx = 1, meta_txs = 0)
0.188707673s wall, 0.140000000s user + 0.000000000s system = 0.140000000s CPU (74.2%)
    UpdateHistory() START
        PopulateHistoryMap() START
        PopulateHistoryMap() END (nProcessed: 501)
        0.656766221s wall, 0.380000000s user + 0.200000000s system = 0.580000000s CPU (88.3%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      6.293854145s wall, 6.330000000s user + 0.000000000s system = 6.330000000s CPU (100.6%)
    UpdateHistory() END
    8.149892135s wall, 7.920000000s user + 0.200000000s system = 8.120000000s CPU (99.6%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      6.254991087s wall, 6.280000000s user + 0.000000000s system = 6.280000000s CPU (100.4%)
----
ConnectTip() START
ConnectTip() STOP (tx_idx = 1, meta_txs = 0)
0.141760637s wall, 0.140000000s user + 0.000000000s system = 0.140000000s CPU (98.8%)
    UpdateHistory() START
        PopulateHistoryMap() START
        PopulateHistoryMap() END (nProcessed: 501)
        0.649867291s wall, 0.420000000s user + 0.220000000s system = 0.640000000s CPU (98.5%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      10.618020669s wall, 10.650000000s user + 0.000000000s system = 10.650000000s CPU (100.3%)
    UpdateHistory() END
    13.363969663s wall, 13.170000000s user + 0.230000000s system = 13.400000000s CPU (100.3%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      10.955463883s wall, 10.950000000s user + 0.010000000s system = 10.960000000s CPU (100.0%)
----
ConnectTip() START
ConnectTip() STOP (tx_idx = 1, meta_txs = 0)
0.142960806s wall, 0.130000000s user + 0.000000000s system = 0.130000000s CPU (90.9%)
    UpdateHistory() START
        PopulateHistoryMap() START
        PopulateHistoryMap() END (nProcessed: 501)
        0.741201589s wall, 0.400000000s user + 0.330000000s system = 0.730000000s CPU (98.5%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      16.957425276s wall, 17.000000000s user + 0.010000000s system = 17.010000000s CPU (100.3%)
    UpdateHistory() END
    20.935923347s wall, 20.650000000s user + 0.340000000s system = 20.990000000s CPU (100.3%)
      UpdateConfirmations() START
      UpdateConfirmations() END
      17.555747409s wall, 17.580000000s user + 0.000000000s system = 17.580000000s CPU (100.1%)

Just to clarify, there is no increase in the number of transactions between these blocks, yet you see an increase in the amount of time UpdateConfirmations takes to process?

I think I found the issue, but I'm not sure what happens:

Start with "many" transactions in the wallet, as mentioned above:

      UpdateConfirmations() START
        >> map iterations: 1002, row iterations: 1004004, set item: 1002
      UpdateConfirmations() END

Generate one block:

      UpdateConfirmations() START
        >> map iterations: 1503, row iterations: 2259009, set item: 1503
      UpdateConfirmations() END

Generate another block:

      UpdateConfirmations() START
        >> map iterations: 2004, row iterations: 4016016, set item: 2004
      UpdateConfirmations() END

No new transactions generated inbetween.

Great, thanks - the problem is in PopulateHistoryMap then - if the map iterations are growing without any new transactions that means we're erroneously growing the txHistoryMap.
PopulateHistoryMap() returns an int, can you pump this out too? (will tell us how many transactions were added to map; I'm expecting 500 or so when the value should be 0 (since there were no new transactions between blocks).  Just stick a printf here for nProcessed perhaps:
    // ### END WALLET TRANSACTIONS PROCESSING ###
    return nProcessed;

Think it might be to do with the changes I added for removing pending transactions and replacing with confirmed.  Looking into it...

It was 501 for the numbers above (in all three cases).
I'm trying to dump the transaction hashes now, but at least with very few transactions, the number doesn't grow in all cases, and I was unable to trigger the multiplication. Will run the tests again now.

Ohh wait. I see:
        // don't burn time doing more work than we need to
        if (nProcessed > nCount) break;

Because only processed transactions count against the limit of nCount = 500, it appeared as if it was growing, because not all of the available transactions were cached.

Ahhhh I see I see, so it was growing by 500 each time because each time PopulateHistoryMap ran, it would add a new batch of the next 500 uncached transactions to the map...  Got it - that's unintended behaviour, will look into a better way to deal.

If you add the current size of the map to nProcessed at the start, that should fix the behaviour on the cap at most recent 500 transactions.  Eg:
int64_t nProcessed = 0;
to
int64_t nProcessed = txHistoryMap.size();

Thinking about this further, with the addition of the cache is a cap on the number of displayed transactions even prudent anymore?  Probably more trouble than it's worth, especially once UpdateConfirmations is optimized...

I pinned it down more or less and it looks like the bottleneck is finding the correct item here, and not the insertion: txhistorydialog.cpp#L411-L412
for (HistoryMap::iterator it = txHistoryMap.begin(); it != txHistoryMap.end(); ++it) {
  // ...
  for (int row = 0; row < rowCount; row++) {
      if (ui->txHistoryTable->item(row, 0)->text() == QString::fromStdString(txid.GetHex())) {
          // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ costly!
      }
  }
}

We're doing n^2 comparisons, so:

Is there a faster way to find the correct row?
Could a found item be removed from the search space?
Is it required to update all items at all?

Is there a faster way to find the correct row?

Yes, by creating an abstract model and then setting up a sort filter proxy on it, then mapping the row back to the original source.

Could a found item be removed from the search space?

See my note above, there is no break; once we've found the item, so even if we find it on row=1 we still iterate all the rest pointlessly.

Is it required to update all items at all?

Nope, but I made a guestimation that analyzing each transaction for whether it needed an update was likely almost as much work as just going ahead and updating it (assuming an optimized logic).
Long story short - I concur this is where the issue is, a simple break; gives a big optimization but I'm shooting for something holistically better.  Working on that now :)

See my note above, there is no break; once we've found the item, so even if we find it on row=1 we still iterate all the rest pointlessly.

Oh, I missed that comment. This is what I tried as well. Gives about 2x speedup. :)

Could you try https://github.com/zathras-crypto/mastercore/commit/bf10a377d8f5a884adaa5bfb3009feb3cd34e763 when you have a mo?  Any better?

Looks good. About 100 ms per block with an initial processing time of 6 sec for ~2600 transactions. :) :)

Awesome thanks :)  Can't see too many folks with Omni transactions in the thousands, but good to know we don't need to cap the number of transactions displayed anymore - I was always a little uncomfortable with that :)

Oh, and sorry forgot to reply on the redundant UpdateConfirmations comment - basically it's done in UpdateHistory() too because the numBlocksChanged signal might hit the message queue before the refreshOmniState signal and thus we wouldn't get confirmations updated for any extra transactions added when refreshOmniState triggers UpdateHistory().
This is because numBlocksChanged is actually done on the bitcoin side (via a 250ms timer comparing with a cached value) and could be called very quickly after the block is received, where as refreshOmniState will only be signaled once the Omni side has finished parsing/processing the block.
Long story short, UpdateConfirmations() could be called before UpdateHistory() - the extra call guarantees that we have up to date data after UpdateHistory().

Haha yeah, this is a gigantic leap, it was several seconds earlier!

Can't see too many folks with Omni transactions in the thousands ...

True, probably not with a GUI build at least. :)

Unsure about usage of byte position in the sort key - currently trying for a sortable key generated from 6 digits [block] 10 digits [byteoffset] - but I get some pretty strange results, for example (using commit https://github.com/zathras-crypto/mastercore/commit/98c29c8bd47d1fe6e67901ce7edcec6f36b56e7d) I get http://pastie.org/pastes/9983629/text?key=qxmrvneltfd4j64kxhiqq

Let me check that. I'll try it isolated: https://gist.github.com/dexX7/f6f6f15ddac82ce0e14a

As workaround to get results:
https://github.com/dexX7/bitcoin/commit/ab28ba516d694d8755933fd728880d1050e874ad
https://github.com/dexX7/bitcoin-spock/commit/bcb5cdc16ddda220e3a8b41fbf937b7c710f5b60
I hope the spock part is expressive enough, I basically sent 5 transactions, ensured they are within the same block and printed the results:
{
  "txdb": {
    "txid": "1815946f4cfa1e0f4b063c63e09bd4483974ec47b1319152ab7f283366e71823",
    "nFile": 0,
    "nPos": 32395,
    "nTxOffset": 107
  },
  "block": {
    "txid": "1815946f4cfa1e0f4b063c63e09bd4483974ec47b1319152ab7f283366e71823",
    "blockhash": "00009abfcec0b3ca198a9af9554691bff034e19837b6aef3ea5950cdc7060f9a",
    "blockheight": 118,
    "position": 1
  }
} {
  "txdb": {
    "txid": "17977999ee86ceaed97567cf214a5e0c1cdc90ed1dee81e3421c71d93ea84dfc",
    "nFile": 0,
    "nPos": 32395,
    "nTxOffset": 332
  },
  "block": {
    "txid": "17977999ee86ceaed97567cf214a5e0c1cdc90ed1dee81e3421c71d93ea84dfc",
    "blockhash": "00009abfcec0b3ca198a9af9554691bff034e19837b6aef3ea5950cdc7060f9a",
    "blockheight": 118,
    "position": 2
  }
} {
  "txdb": {
    "txid": "c4d85e20ed0274db766ab9c87b08564163cb2cd3f4d37bf7f28a38923ffd2bbc",
    "nFile": 0,
    "nPos": 32395,
    "nTxOffset": 558
  },
  "block": {
    "txid": "c4d85e20ed0274db766ab9c87b08564163cb2cd3f4d37bf7f28a38923ffd2bbc",
    "blockhash": "00009abfcec0b3ca198a9af9554691bff034e19837b6aef3ea5950cdc7060f9a",
    "blockheight": 118,
    "position": 3
  }
} {
  "txdb": {
    "txid": "c8d058ed5b744d3436dc54478773a0d292cd50137876b0b2a10b305da4f49e87",
    "nFile": 0,
    "nPos": 32395,
    "nTxOffset": 783
  },
  "block": {
    "txid": "c8d058ed5b744d3436dc54478773a0d292cd50137876b0b2a10b305da4f49e87",
    "blockhash": "00009abfcec0b3ca198a9af9554691bff034e19837b6aef3ea5950cdc7060f9a",
    "blockheight": 118,
    "position": 4
  }
} {
  "txdb": {
    "txid": "c434ac7cc0dda979b0d152db82893dddc8a37be987ec735c27f0a7e3900de4c8",
    "nFile": 0,
    "nPos": 32395,
    "nTxOffset": 1008
  },
  "block": {
    "txid": "c434ac7cc0dda979b0d152db82893dddc8a37be987ec735c27f0a7e3900de4c8",
    "blockhash": "00009abfcec0b3ca198a9af9554691bff034e19837b6aef3ea5950cdc7060f9a",
    "blockheight": 118,
    "position": 5
  }
}

It looks like it works: whenever the real position within a block increases ("block" -> "position"), the offset increases as well ("txdb" -> "nTxOffset").
So this is appears to be an issue with your code, which I'll look into in an hour. :)

Could it be the case that you're dumping positions while the transactions are still unconfirmed?

As a side note and rant (sorry hehe): those mega functions and methods are a pain to review and it would be much easier, if every "action" is isolated, e.g. with a function to set the position etc, ... :)
The compiler probably optimizes the overhead anyway, if objects are passed by reference (const Object& thing) or via pointer as you usually do.

Nevermind dude, sorry to have wasted your time - I was a bit hazy yesterday (had a biopsy & some other stuff done and was a little out of it) - it was a dumb mistake on my part - spot the schoolboy error:
      htxo.blockByteOffset = 0;
      CDiskTxPos position;
      if (pblocktree->ReadTxIndex(hash, position)) {
           htxo.blockByteOffset = position.nTxOffset;
      }
      htxo.blockByteOffset = 0; // needs further investigation

Fixed here https://github.com/zathras-crypto/mastercore/commit/bc22edf7aa0a2e11b1eb8fe6a4799d3add9f645e - spotted it in 5 seconds flat this morning with a clear head :( probably shouldn't be coding while drowsy/medicated but so much pressure to get this UI release out sadly can't afford any downtime - apologies again for wasting your time mate :(

Ack on the separate functions, will try and adjust coding style accordingly :)

if (pblocktree->ReadTxIndex(hash, position)) {
     htxo.blockByteOffset = position.nTxOffset;
}
htxo.blockByteOffset = 0; // needs further investigation

I see, I see. :) So this is mostly covered, I think. Will need to look at the unconfirmed transaction order, and probably use nOrderPos instead of nTxOffset, if it's an issue at all.
To finalize this, I think the last missing piece would be to bind the "confirmations" column to "sort via position".

To finalize this, I think the last missing piece would be to bind the "confirmations" column to "sort via position".

Addressing that now :)

It's a bit ugly, and I do have some ideas to play with on how to do it better, but this should at least provide the main functionality in the interests of expediting binaries for @Craig & co.  https://github.com/zathras-crypto/mastercore/commit/41b63b50ffa4c30d93047bd46b626fb112078813

Will need to look at the unconfirmed transaction order, and probably use nOrderPos instead of nTxOffset, if it's an issue at all.

https://github.com/zathras-crypto/mastercore/commit/484a905a2cc6530f712e07d57225347c862be410

484a905

Going to test it in a few minutes (once my out of order chain is fully downloaded, to see it break.. hehe).
Something I was wondering about earlier: the current order is a) check pending txs, b) iterate wallet txs,  ... but given that pending txs are wallet txs as well, would it make sense to move the pending tx processing into the loop?
And quick question about txhistorydialog.cpp#L239-L243:
// tx not in historyMap, retrieve the transaction object
CTransaction wtx;
uint256 blockHash = 0;
if (!GetTransaction(hash, wtx, blockHash, true)) continue;
blockHash = pwtx->hashBlock;

I think this can be removed, because blockHash is overwritten anyway, and CWalletTx is a subclass of CMerkleTx and CTransaction , so all properties of CTransaction and more are already present.

Sorry, bit confused about this one:

because blockHash is overwritten anyway

can you point me to where this is overwritten?  The purpose of that is to get the blockHeight of the transaction (which I didn't think was directly accessible, only the block hash which is then used to ascertain the block height)
As for putting pending tx handling inside wallet iteration, you're probably right there but given the constraints and pressure to get binaries out, perhaps better left to be rewritten with our next version since it's working atm.

NOT INTERESTED IN YOUR BINARIES!

can you point me to where this is overwritten?

// tx not in historyMap, retrieve the transaction object
CTransaction wtx;
uint256 blockHash = 0;
if (!GetTransaction(hash, wtx, blockHash, true)) continue;
blockHash = pwtx->hashBlock;  // <------------------------ HERE :)

I assume the intention was get the blockHash by querying GetTransaction(), and the value overwrite aside, if this is the only reason, it should be fine to go with the wallet tx directly.

Ahh I see I see, yeah it is a duplication.

I'd actually consider this as done, except maybe sorting based on the number of confirmations both ways. I'm not sure how the "sort indication icon" can be enabled for the column, but as nasty workaround, we could remember the sort order and switch it everytime the header is clicked:
void TXHistoryDialog::checkSort(int column)
{
    static Qt::SortOrder sortOrder = Qt::DescendingOrder;

    if (column == 2) {
        ui->txHistoryTable->horizontalHeader()->setSortIndicator(1, sortOrder);

        if (sortOrder == Qt::DescendingOrder) {
            sortOrder = Qt::AscendingOrder;
        } else {
            sortOrder = Qt::DescendingOrder;
        }
     }
}

I think @craig is not @CraigSellars ... ;)

I think @craig is not @CraigSellars ... ;)

d'oh!

we could remember the sort order and switch it everytime the header is clicked

That could work, I was playing with flipping current via the values for sortIndicatorOrder() and sortIndicatorSection() but since those were always overridden as soon as the header was clicked it was a no-go... Your method seems pretty simple and workable :)

I'm very curious: where is it defined that the "date", "type", "address" and "amount" columns are sortable, but the confirmation column isn't? The workaround from above works, but it does not show a sort indicator like here:

It's in the workaround example you gave above mate - the confirmations column is column 2, and the hidden sort key is column 1.  We intercept the signal from clicking on a column header, and if the clicked header was column 2 (the confirmations column) we override the sort to be via column 1.
Since column 1 is hidden, you cannot see the sort indicator.
Hope that helps explain :)

We intercept the signal from clicking on a column header ... override

Thanks, this was basically the missing piece. :) I found a better workaround, which also shows the sort icon and works without storing the sorting state, see #54.

Hmm.. the sorting works, but unfortunally the order is messed up, once a new transaction entry is inserted (e.g. after a send), probably because after reenableing the sorting column 2 is used.

Yeah, the proper way to handle this is I think to subclass the sort so we can override the sorting process used for column 2 and make it use the data from column 1 but I'm putting that in the 'nice to have' basket for now so I can get <IP_ADDRESS> out :)

Can't see too many folks with Omni transactions in the thousands, ...

Quick note about performance: I am actually a holder of a wallet with 5000+ Master/Omni transactions (faucet!) and the performance hit is significant. The startup takes roughly 1-2 minutes after the intiial parsing, and after sending a transaction there is also a delay of a few seconds. These delays were the most notable ones.
This was sort of expected, and I'm very, very sure there is no one else with a wallet with so many transactions, but let's just say: we're not yet 100 % through this in the long term. :)

Sure sure, I think there will need to be a lot of changes to the way we do things to support a fluid MetaDEx UI for 0.0.10 (including some sort of decoding for mempool transactions to allow display of pending trades from other parties and an assessed evaluation of whether they are likely to confirm & be valid) which I think would require a rethink of the underlying logic for UI access to transactions and perhaps some kind of better atomic storage for objects.
One way or another though it's always going to take some degree of time (whether ms/sec/min etc) to load all transactions from the wallet and parse them at startup to enable a history... 5000 transactions is a big wallet and I think some kind of hit at startup is acceptable there.  The delays on sending/updates can likely be optimized (for example using a cached walletTransactionsCount value between UI updates and then only iterating the wallet if that changes or similar), definitely think this will become even more important as we start doing "more" per UI refresh (such as updating a MetaDEx interface also etc)

Oh, and as an FYI mate it was decided at last meeting my first major task for 0.0.10 is going to be building in support for a Class C transaction using OP_RETURN (encoding and decoding) and addressing some of the technical debt (like missing RPC functions for sending certain tx types).
Just a heads up :)

In general, and probably as mentioned before, I think a long term goal should be more targeted actions. UpdateOmniState is pretty crude, and a great refinement would be to pass transaction ids of the affected transactions. Next would could be to go a level deeper and describe the state change, e.g. "new transaction", "new property", etc.

Oh, and as an FYI mate ...

That's very interesting. Please keep me in the loop.
I'm still sitting on the unoptimized/POC byte serialization, which basically converts between std::vector<unsigned char> (raw transaction data) and "plain transaction objects", which represent transactions on the network level (e.g. a simple send with version, type, amount and property identifier), as well as all "encode_" RPC calls: experiment-plain-data
Integrating OP_RETURN shouldn't be very difficult, but it needs to be specified.
And what I was wondering about recently, because I played around with a super minimal stripped version of Master Core with parseTransaction() only:
There are two ways to handle it:

Split parseTransaction() into something like getSender(), getReference(), hasExodusOutput(), decodeClassA(), decodeClassB(), ...

Don't touch it ever again, consider it as "sealed" and leave it "as it is", to avoid the introduction of unexpected consensus affecting behavior. This is probably not really an issue, given that it could be deployed with other consensus affecting code.

If either one of those are chosen, integrating OP_RETURN would be more straight forward.
Speaking of: I still assume moving to Bitcoin Core 0.10 is the next step, right? If so, I'd probably should start isolating the compability commits and publish them. :) In this particular context I'd be very interested in your opinion about https://github.com/mastercoin-MSC/mastercore/issues/286#issuecomment-77267497.


Incorrect signature for MicrosoftTeams.psd1 in v4.3.0

Not possible to update the module by using Update-Module cmdlet cause of a signature mismatch. Workaround - Install-Module cmdlet with -SkipPublisherCheck parameter just to bypass signature tests.
It's easy to check the signature:
Get-AuthenticodeSignature .\MicrosoftTeams.psd1
Directory: C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\4.3.0

SignerCertificate                         Status                      Path
385856F7AB96024DA600A7BD6118F6C5386A5368  HashMismatch                MicrosoftTeams.psd1
Status                 : HashMismatch
StatusMessage          : The contents of file C:\Program Files\WindowsPowerShell\Modules\Microso
ftTeams\4.3.0\MicrosoftTeams.psd1 might have been changed by an unautho
rized user or process, because the hash of the file does not match the
hash stored in the digital signature. The script cannot run on the spec
ified system. For more information, run Get-Help about_Signing.
Please, re-apply a signature for the file.

Hi @MrDmig,
Can you please try with the 4.3.1-preview release?
Also, what's the locale set in the machine giving this error?
Thanks,

Hi @pbafna03,
4.3.1-preview works well for me. I've successfully updated the module by the "Update-Module" cmdlet with "-AllowPrerelease" parameter. I double checked the MicrosoftTeams.psd1 file with the Get-AuthenticodeSignature cmdlet and there was a valid signature.
I don't think that locale settings affect that behavior. Anyway, there is "ru-Ru" locale.
Best regards.

@MrDmig Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


fix(hooks): Make ETag header RFC compliant

Fixes #850
Adds support for 412 (Precondition Failed) responses from controllers when the provided If-None-Match header contains the ETag. As described in #850, this is the expected behavior of HTTP/1.1 as described in RFC7232.
I also took the liberty of updating the docs.

thanks @jgnagy , added small comment. Thanks for the PR, approved the tests


feat: use semantic-release in GitHub Actions

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Updated 'marked' to address the security issues

Closes #492, #495, esdoc/esdoc-plugins#50
The local build (npm test) is still passing with this change.
Update: This PR brings the marked dependency to a newer version than #496, but either one will get rid of the security issues.

@h13i32maru Can you merge this and publish new version?

Also, need to update esdoc-publish-html-plugin's dependencies for closing esdoc/esdoc-plugins#50
https://github.com/esdoc/esdoc-plugins/blob/4c1c596df77a5a162ace6f72349e7549d42dbdc4/esdoc-publish-html-plugin/package.json#L18

Thanks, @h13i32maru. I'm glad you're back! 😃


test(router): adding test to verify route generation from tsr.config.json

Simply adding a test to verify that the contents of tsr.config.json are being used to generate correct outputs. This PR adds one test to packages/router-generator/tests/generator that has the following configuration:
{
  "disableLogging": true,
  "routesDirectory": "./configured-routes-path",
  "generatedRouteTree": "./routeTree.gen.ts"
}

Like all other tests in this directory, this test verifies the snapshot output. routesDirectory is intentionally configured to a non-standard directory to verify that the contents of the config file are being read.
generatedRouteTree is configured as routeTree.gen.ts like in every other test, but I left this unchanged because I did not want to touch .gitignore.
Adding this PR because I noticed that there were no tests in the repo that actually loaded tsr.config.json from the file system(I could be wrong!). It would seem that a test verifying this would be a pre-requisite for supporting non-json config files (js, cjs, mjs, ts, etc)

I am not sure this is the right approach. shouldn't we rather just test that the config is loaded correctly from generator? why would we need a full blown test like this?

I am not sure this is the right approach. shouldn't we rather just test that the config is loaded correctly from generator? why would we need a full blown test like this?

Yes- if we can verify that the correct config is loaded without generating the routes that would be ideal. Do you have any suggestions for to tackle that?
My  rationale for re-using the route generator tests is that it actually loads the config from the real filesystem. This is what a real end user would do so it seems like a closer approximation than using memfs, mocking fs APIs or something similar. Maybe a better strategy would be to just test getConfig directly

Maybe a better strategy would be to just test getConfig directly

yes that's what I meant. not sure what needs to be done to test this.

Maybe a better strategy would be to just test getConfig directly

yes that's what I meant. not sure what needs to be done to test this.

Perhaps nothing- but what I really want to add is support for js files in config. In order for that to happen, there probably should be some test that verifies that json config files continue to work. Now maybe supporting js for config files isn't desired, and in that case yea, prob don't need to test this.

what do you mean by "js files in config"?

by using a vite like define... approach as we did for virtual file routes?

by using a vite like define... approach as we did for virtual file routes?

That api had crossed my mind yea. Something like:
module.exports = defineTanStackConfig({
  virtualRoutes: defineVirtualRoutes(...)
})

@schiller-manuel do you think this is worth pursuing or no?


Add rclone

Update: I also added some makefile default rules so that people get some indication of what when wrong when they try to install an unknown package.

Great, thanks!


Upgrade odbc-postgresql driver for PostgreSQL >11

We need to upgrade to Postgres 12+ to bring SODAR Core and SODAR to Django 4.2, see bihealth/sodar-core#880. (Also Postgres 11 has now dropped out of support so it shouldn't be used anyway)
Attempts for the current version of the image to connect to a newer postgres version are met with a lovely flood of column c.relhasoids does not exist errors. This is caused by an old version of the odbc-postgresql driver installed on the image, namely 1:10.01.0000-1.
Alas, there is a problem: the newer version of driver is not available for Ubuntu 18.04. At least not without us trying to compile our own version or something. Judging by the lack of results online for people doing this, that probably is not a good idea.
The new driver is available for Ubuntu 20.04. But there we run into another issue: iRODS 4.2 is not officially available for that build. It is possible to build it with a workaround, but I'd rather not have that in our image.
Hence, I believe a proper solution for this task is as follows:

First, upgrade to iRODS 4.3 (#16)
Next, upgrade the image to Ubuntu 20.04 (#19)
Last, ensure odbc-postgresql now works with Postgres >11

As far as I can tell, once the OS has been upgraded, the existing apt install command for unixodbc, unixodbc-dev and odbc-postgresql should install the new versions without any hassle. But if not, this is where we ensure the proper version gets installed.

Done.


Was this repo renamed from "peerpad"?

I'm pretty sure it was named peerpad - it's named peerpad everywhere else. Is it about the peer star work?

Yes, it was. https://github.com/ipfs-shipyard/peerpad redirects to here, so evidence of a rename.

Yes, i think they all were, https://github.com/ipfs-shipyard/peer-pad-core used to be peerpad-core


Jsx does not like a list of chars as the key of a map or properlist

I came up with a minimal example which shows that Jsx doesn't like strings --as a key.  I would like to show first how that works for both Maps and Properlists:
>jsx:encode([{id, 1}]).
<<"{\"id\":1}">>

>jsx:encode([#{id => 1}]).
<<"[{\"id\":1}]">>

Now, with id as a string (list of integers)
> jsx:encode([{"id", 1}]).
** exception error: no function clause matching jsx_encoder:unzip([{"id",1}],jsx_encoder) (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 68)
     in function  jsx_encoder:encode_/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 61)
     in call from jsx_encoder:'-encoder/3-fun-0-'/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 32)

>jsx:encode([#{"id" => 1}]).
** exception error: no function clause matching jsx_encoder:unpack(#{"id" => 1},["id"],jsx_encoder) (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 81)
     in function  jsx_encoder:encode/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 50)
     in call from jsx_encoder:unhitch/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 74)
     in call from jsx_encoder:encode_/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 63)
     in call from jsx_encoder:'-encoder/3-fun-0-'/2 (/app/_build/default/lib/jsx/src/jsx_encoder.erl, line 32)

I'm kind of new using Erlang, so I'm not sure whether this is an expected behavior or not.
Cheers,

this is an expected behaviour and also a kind of terrible user experience. i would love to fix it but the problem is that erlang strings like "id" are really lists of integers. [105, 100] in this case. "id" == [105, 100] is true in erlang. in json "id" and [105, 100] are two totally different things
that means that if i allow erlang strings as json output i have to make a choice about how to encode them. then i have to provide a way to override that choice for users who want the alternate output. so jsx would need directives like {string, "id"} or {list, [105,100]}. this is doable but i decided list_to_binary("id") was just as convenient as adding support for encoding directives. so i only wrote support for handling binary inputs
it would be possible to only allow strings as input to the encoder in the case where they are map keys or proplists as you can't have a json object with a list of integers so there's no ambiguity. it's also possible to support them as output when decoding json but no one has ever asked for that feature. if i have time this week i will look into adding support for strings as map/proplist keys

Thanks for your quick response @talentdeficit.  Your explanation makes total sense to me.  I think the support for string as map/proplist keys is a nice to have but is not mandatory at all.  Per your explanation, I can infer that I can use either an atom or a binary a the key of a map/proplist.  I'll change my code to do that transformation and see how that looks.
Thanks again!

yes, you can also use an integer as a map/proplist key and it'll be integer_to_binary'd before output. i forget why this is supported but it has something to do with equivalence with some java json library i believe

Hello. @talentdeficit .
I just faced this issue while working on my project. It's not yet complete but here it is --> (https://bitbucket.org/tdatta/fixvaasi-fixer)
In my opinion, jsx should support  strings and in fact lists as well. In Erlang everything is immutable so unlike other(not so strict on immutability) languages, it is not possible to have a list() as a key in dictionary.. While Erlang will allow it (for the right reason).
So if I the deocde gets a list which can be valid string ==> It should convert it and use that as a normal string.
Otherwise it should just "stringify" the list
For example #{[65,66] => world} should be encoded as {"AB":world} and
#{[65,66,1} => world}  as {"[65,66,1]" : world}..
Let me know if I can fork it and add the support.
Cheers
Tanmay

i'm not really sure adding support for strings/charlists as object keys is a good idea
i don't like behavior that depends on the contents of the container. what if i expect [65,66] to encode to "[65,66]" instead of "AB"? i would prefer to have users make these choices explicitly, and i think it is easier for them to do that via explicit conversions to types jsx accepts rather than adding configuration that allows it


https performance

The driver performance over HTTPS is very poor.
The same query roundtrips are 4-5 times(!) faster with HTTP. In my simple tests the average query RTT was 41.6ms with HTTP, and 196.5ms with HTTPS on a remote server.
Is there any extra option to pass to the driver?
My environment:
arangoDB 2.6.0 (stable) and 2.5.2
iojs 2.3.1
arangojs 3.8.1
The performance of the web GUI is as fast with HTTPS than with HTTP.

SSL- handshakes involve more TCP-roundtrips than plain TCP.
Did you use a connection pool in both tests? If you run tcpdump / wireshark you shold see a set of connections with lots of back and forth talking compared to many connections with little communication.
If your two hosts have slower pings, these additional roundtrips sum up.
did you try to compare it to a simple webserver with http and https?

I'm using the driver with default settings. Which options should I pass in the agentOptions to use pools, or keepalive?

HTTPS should "just work". You only need to mess with the agentOptions or agent if you want to change the default behaviour. If no agent is provided, it automatically uses http.Agent or https.Agent depending on the URL passed to the constructor.

This may be an issue with node itself. The default settings of Node.js are known to cause bad performance when using outbound HTTPS:
https://www.paypal-engineering.com/2014/04/01/outbound-ssl-performance-in-node-js/

Can you confirm that it's arangojs rather than the https module itself that is slow?
Try using https.request directly vs arangojs with HTTPS and then http.request vs arangojs with HTTP. If the relative differences are vastly different, there's probably something wrong.

I tried several test cases with many different settings (keepalive, connection pools etc). It seems that node https module itself is the problem :( The results of plain HTTPS paired with arangojs are almost equal.
I'm planing to use plain HTTP over VPN as a temporary workaround.
Is there any concrete plan to support websocket/HTTP 2.0 in an upcoming arangoDB version in the near future?

I'm not aware of any short-term plans for supporting HTTP 2.0, sorry.
If the performance tweaks for HTTPS aren't sufficient, you could also use HTTP over SSH (establish an SSH tunnel to the database server and just make all HTTP connections over that).


SetAttachType should return an error

bpf_program__set_expected_attach_type() returns an error so should its wrapper

Same effort: #223

@geyslan hello, I'd like to try these two modifications, could you assign them to me?

@CodePrometheus Thank you for applying for the task. Any doubts, please let us know.


Registration Link Linking to Incorrect Site

Hi there! The Registration link is not taking me to the registration page and actually takes me to this tech article (https://techcommunity.microsoft.com/t5/azure-infrastructure-blog/simplify-it-management-with-microsoft-copilot-for-azure-save/ba-p/3981106). This happens on both the Microsoft Learn page and on the main product site page when you click on "Apply for access".

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 24b8490e-4340-cb70-6eb3-9ddfce92105f
Version Independent ID: ea652a2b-837e-2c51-8cdd-f79b55f83f98
Content: Microsoft Copilot for Azure (preview) overview
Content Source: articles/copilot/overview.md
Service: copilot-for-azure
GitHub Login: @JnHs
Microsoft Alias: jenhayes

@juliaashleyh8
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.

Hi @juliaashleyh8 - thank you for sharing this feedback. The target of the link is actually intentional, as we wanted to make sure that people have the necessary context provided by the blog post to understand the preview and its requirements before they complete the signup request. I understand this may not be what is expected, and I've passed your feedback along to the team for consideration.
I'll close this issue now, but please let me know if you have further questions or feedback on the docs. Thanks again for taking the time to raise this issue!
#please-close


Jeff Schaller: Watch webgostarangilan.com

Jeff Schaller requests the watch of the watch_keyword webgostarangilan\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

webgostarangilan\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Daniil in Charcoal HQ


failed to locate file normalize

I'm using parcel with stylus with postcss and when I yarn add this I get failed to locate file normalize

@import '~normalize-styl'


Neovim crashing

My neovim was crashing when using A<CR> command and it was resolved by switching over to Packer.
Not sure what was causing it but my guess would be that it was related to parallel
When the crash freeze happened my neovim spiked in CPU usage and wouldn't take any input. I had to close the process manually or force exit the terminal.
I wish I could attach a log but when I used
profile start freeze_debug.txt
profile file *
profile func *

it didnt show anything except for the "second to last" command used and it's evaluations.

Please post detailed steps and a minimal configuration to reproduce your issue.

config/plugin-manager.lua
local user_packadd_path = "faerryn/user.nvim/default/default/default/default"
local user_install_path = vim.fn.stdpath("data").."/site/pack/user/opt/"..user_packadd_path
if vim.fn.isdirectory(user_install_path) == 0 then
  os.execute("git clone --quiet --depth 1 https://github.com/faerryn/user.nvim.git "..vim.fn.shellescape(user_install_path))
end
vim.api.nvim_command("packadd "..vim.fn.fnameescape(user_packadd_path))

local user = require("user")
user.setup({ parallel = true })
local plugins = require'plugins'

for _,plugin in ipairs(plugins) do
    user.use(plugin)
end
-- since we are using parallel, we *must* call user.flush()
user.flush()

plugins.lua
return {
    'faerryn/user.nvim',

    'nvim-lua/plenary.nvim',
    { 'nvim-treesitter/nvim-treesitter', run = ':TSUpdate' },
    -- LSP
     'neovim/nvim-lspconfig',
    'williamboman/nvim-lsp-installer',
    -- 'folke/lsp-colors.nvim',
    'glepnir/lspsaga.nvim',
    -- 'onsails/lspkind-nvim',
    -- 'jose-elias-alvarez/nvim-lsp-ts-utils',
    -- {'neoclide/coc.nvim', branch = 'release'},
    -- AUTOCOMPLETE
    'hrsh7th/cmp-path',
    'hrsh7th/cmp-nvim-lsp',
    'hrsh7th/cmp-buffer',
    'L3MON4D3/LuaSnip',
    'saadparwaiz1/cmp_luasnip',
    'hrsh7th/nvim-cmp',

    -- USEFUL
    'nvim-lua/popup.nvim',
    -- fuzzy find,
    'nvim-telescope/telescope.nvim',

    -- ICONS,
    'kyazdani42/nvim-web-devicons',

    -- COMMENTS
    'b3nj5m1n/kommentary',
    -- 'suy/vim-context-commentstring',

    -- KEY HELPER POPUP
    'folke/which-key.nvim',

    -- AUTO CLOSING BRACKETS
    {'windwp/nvim-autopairs', config = function() require('nvim-autopairs').setup() end },

    -- DIAGNOSTICS WINDOW
    { 'folke/trouble.nvim', config = function() require('trouble').setup {auto_close = true} end },

    -- COMMENT HIGHLIGHTING
    {
        'folke/todo-comments.nvim',
        config = function()
            require('todo-comments').setup {}
        end
    },

    -- FILE EXPLORER
    {
        'kyazdani42/nvim-tree.lua',
        requires = 'kyazdani42/nvim-web-devicons',
        config = function()
            require'nvim-tree'.setup {
                view = {
                    auto_resize = true
                },
                diagnostics = {
                    enable = true
                },
                auto_close = true,
            }
        end
    },

    -- GIT
    'f-person/git-blame.nvim',
    {
        'akinsho/toggleterm.nvim',
        config = function() require'toggleterm'.setup{} end
    },

    -- THEME / SYNTAX
    {'dracula/vim', config = function() vim.cmd[[colorscheme dracula]] end},
    'nvim-lualine/lualine.nvim',
    -- { 'folke/tokyonight.nvim', as = 'tokyonight', config = function() vim.cmd[[colorscheme tokyonight]] end },
}

init.lua
require('config.plugin-manager')

nvim/
├─ lua/
│  ├─ plugins.lua
│  ├─ config/
│  │  ├─ plugin-manager.lua
├─ init.lua

I tried one more time with disabling all LSP, autocomplete and util type plugins but the problem persisted. I used packer before i used this plugin and didn't have any problems so I went back to it "just to see" and havn't had any issues since.

I can type A<CR> without issue while using your configuration. This creates a newline much like typing o.

I know what the command does, the point is that it would then sometimes cause the entire nvim client to freeze.
Ie i opened a file with Telescope find_files and do GA<CR> to start typing a new function at the end of the document and neovim would freeze.

I seem to be unable to reproduce your issue (Telescope find_files and GA<CR> work fine for me).


Request:  Be able to change the order of the columns (left to right)

Still lovin' this!  It really is helping with my job.  (I'm doing conversions from other customer's systems to ours, so LOTS of searching through data...  )
First, I did notice that ordering the columns in the Columns top-middle section also changes the order of the columns in the results.  To be completely honest, I'm not sure if I like that or not.
Anyway...  it would be nice to be able to change the order of the columns in the results table, i.e. putting this column all the way to the left so it's with the other columns I want to view.
One way would be to do a pop-up window (maybe?) to show all of the columns and the order and allow the user to change that.  DBeaver does it this way.

Possibly a more workable way would be to add the top/up/down/bottom buttons shown in the image above to the Columns window, along with Apply and Clear buttons, probably.  (So it isn't trying to refresh every time a person moves a column up or down.)
Either would be great!
Once again, appreciate your work and extension!  :-)
Michael

Thank you for this feature request. It will be considered in a future release. 👍

Happy to know this extension is helping you in your job !


Relocate ToDataTable

I propose that the ToDataTable method group be moved to a different assembly.  Currently this is the only method group in MoreLINQ that has a dependency on System.Data or System.Xml.  That's 2/3 the dependencies for 1/50 of the features, roughly.
Code that has nothing to do with relational data, using MoreLINQ extension methods that have nothing to do with relational data, without referencing System.Data will yield the compiler error "The type 'System.Data.DataTable' is defined in an assembly that is not referenced..." A similar message occurs for System.Xml

If you never use ToDataTable in code then you should not run into a CS0012 error. How are you seeing this happening? Alternatively, you can use MoreLINQ PCL that doesn't include ToDataTable.
Also, DataTable is not relational on its own but a DataSet is. On its own, DataTable is a very useful container data structure with lots of applications and part of .NET Framework.
I'm closing this as wont-fix because:

CS0012 error does not occur
the PCL version is a reasonable workaround for those just annoyed by presence of ToDataTable
the dependencies, even if there, are not incurred at runtime or during deployment if unused

I understand not agreeing that it's a necessary change, but I do get the error.
I've even tried with a very simplified environment.  I created a new C# console app project in a new solution, deleted all standard references except System, added MoreLinq, and added this code to Program:
using MoreLinq;

class Program {
    static void Main() {
        var x = new[] { 1, 2 }.Concat(3);
    }
}

I get a CS0012 when I try to compile.
(using VS2013)

I've even tried with a very simplified environment.

@JamesFaix I tried the same but I guess the difference is coming from the compiler version in 2013 and 2015.
Here's what I did. I created a simple Program.cs in a folder (no VS):
using System;
using System.Linq;
using MoreLinq;

static class Program {
    static void Main() {
        Console.WriteLine(Enumerable.Range(1, 10).ToDelimitedString());
    }
}

Then I created a batch in the same folder with following the content and named it makenrun.cmd:
@echo off
setlocal
set NETFX=%SystemRoot%\Microsoft.NET\Framework\v4.0.30319
set CSC_PATH=%ProgramFiles%
if defined ProgramFiles(x86) set CSC_PATH=%ProgramFiles(x86)%

rem set CSC_PATH=%CSC_PATH%\MSBuild\12.0\bin
set CSC_PATH=%CSC_PATH%\MSBuild\14.0\bin

nuget install morelinq -version 1.4.0 ^
  && copy /y morelinq.1.4.0\lib\net35\MoreLinq.dll ^
  && "%CSC_PATH%\csc.exe" /noconfig /nostdlib "/r:%NETFX%\mscorlib.dll" "/r:%NETFX%\System.Core.dll" /r:MoreLinq.dll Program.cs ^
  && Program

You'll notice that to be very strict on references, I disabled the default response file (/noconfig) and even referenced mscorlib manually (i.e. /nostdlib).
Depending on which C# compiler version you want to invoke, you can uncomment the corresponding set CSC_PATH=... statement and comment out the other. I tested against the following two C# compiler versions:

C# 5 compiler shipping with MS Build Tools 2013
C# 6 (Roslyn) compiler shipping with MS Build Tools 2015

The first one reports CS0012 but second one doesn't.
Output from running the batch in case (1):
Feeds used:
  https://api.nuget.org/v3/index.json

Package "morelinq.1.4.0" is already installed.
        1 file(s) copied.
Microsoft (R) Visual C# Compiler version 12.0.40629.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

Program.cs(7,9): error CS0012: The type 'System.Data.DataTable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
MoreLinq.dll: (Location of symbol related to previous error)

Output from running the batch in case (2):
Feeds used:
  https://api.nuget.org/v3/index.json

Package "morelinq.1.4.0" is already installed.
        1 file(s) copied.
Microsoft (R) Visual C# Compiler version <IP_ADDRESS>109
Copyright (C) Microsoft Corporation. All rights reserved.

1,2,3,4,5,6,7,8,9,10

So while you're right that CS0012 is being emitted, I'm not sure if going forward it is an improvement (I hope) or a regression with the C# 6 compiler (I see 4 mentions of CS0012 in dotnet/roslyn#7278 at the time of this writing). In any event, I'm still not inclined to spend time and energy on moving out ToDataTable as I think the issue is somewhat superficial and can be sidelined today by using PCL package.


Error parsing array of objects in package settings (config.cson)

The config.cson parser seems unable to handle objects within an array. E.g,. take this package settings configuration:
module.exports = MyPackage =
  config:
    MyArrayOfObjects:
      type: 'array'
      default: []
      items:
        type: 'object'
        properties:
          myObjectProperty:
            type: 'string'

The following  config.cson values get removed on parse:
"my-module":
  MyArrayOfObjects: [
    {
      myObjectProperty: "I am a setting value"
    }
    {
      myObjectProperty: "I am a another setting value"
    }
  ]

I faced the same problem when trying to configure php-debug remote. PathMaps part doesn't get saved.
Is there any workaround for this issue?


[GOBBLIN-987] Reject unrecognized Enum symbols in JsonRecordAvroSchemaToAvroConverter

This change fixes JsonRecordAvroSchemaToAvroConverter by rejecting Enum
symbols not defined in the specified Avro schema. Allowing such values
causes runtime errors when the resulting objects are encoded.
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-987

Description

[x] Here are some details about my PR, including screenshots (if applicable):
JsonRecordAvroSchemaToAvroConverter allows unrecognized Enum symbols not declared in the specified Avro schema. Attempting to write/encode the resulting objects cause runtime errors that are difficult to diagnose or root-cause.

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
org.apache.gobblin.converter.avro.JsonRecordAvroSchemaToAvroConverterTest.testConverterThrowsOnUnrecognizedEnumSymbols()

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #2833 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #2833      +/-   ##
============================================
+ Coverage     45.61%   45.62%   +0.01%
- Complexity     8969     8972       +3
============================================
  Files          1902     1902
  Lines         71292    71295       +3
  Branches       7863     7863
============================================
+ Hits          32520    32530      +10
+ Misses        35777    35775       -2
+ Partials       2995     2990       -5

Impacted Files
Coverage Δ
Complexity Δ

...ro/JsonElementConversionWithAvroSchemaFactory.java
68.93% <100%> (+0.93%)
6 <0> (ø)
:arrow_down:

...in/java/org/apache/gobblin/cluster/HelixUtils.java
35.51% <0%> (-3.74%)
12% <0%> (-1%)

.../org/apache/gobblin/cluster/GobblinTaskRunner.java
65.27% <0%> (+0.46%)
28% <0%> (ø)
:arrow_down:

...main/java/org/apache/gobblin/util/HadoopUtils.java
30.87% <0%> (+0.67%)
25% <0%> (+1%)
:arrow_up:

.../apache/gobblin/runtime/api/JobExecutionState.java
80.37% <0%> (+0.93%)
24% <0%> (ø)
:arrow_down:

...e/gobblin/runtime/locks/ZookeeperBasedJobLock.java
64.44% <0%> (+1.11%)
16% <0%> (+1%)
:arrow_up:

.../org/apache/gobblin/metrics/RootMetricContext.java
79.68% <0%> (+1.56%)
16% <0%> (+1%)
:arrow_up:

...lin/restli/throttling/ZookeeperLeaderElection.java
72.22% <0%> (+2.22%)
13% <0%> (ø)
:arrow_down:

...rter/avro/JsonRecordAvroSchemaToAvroConverter.java
77.77% <0%> (+4.44%)
11% <0%> (ø)
:arrow_down:

...lin/util/filesystem/FileSystemInstrumentation.java
92.85% <0%> (+7.14%)
3% <0%> (ø)
:arrow_down:

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 f3cf13d...c62ae78. Read the comment docs.


Adding Owner's file

Adding Owner's file for Poseidon incubation project.

/retest

/lgtm

/approve

@timothysc I am not able to merge this pull request.


import re only once

and not 2 times
suggested by lgtm
https://lgtm.com/projects/g/mosra/pygments/alerts/?mode=tree

Hi @fchapoton! This repository is just a mirror of https://bitbucket.org/birkenfeld/pygments-main with a bunch of pending PRs from there applied during the time where the upstream project was on hold. I'm not involved with the project in any other way. Also since then, the development resumed upstream, can I suggest you propose this change there instead? :)


fix: Action on pressing enter on input names

Fixes #2060 Pressing enter changes line
Checklist:

[x] I have checked for PMD and check-style issues
[x] I have read the Contribution & Best practices Guide and my PR follows them.
[x] My branch is up-to-date with the Upstream development branch.

Changes:
Pressing Enter now takes the user to the next input field
Screenshots for the change:

@liveHarshit please check this


Draft: Add support for loadable modules at CPL-3

This set of commits was created as an effort to determine the scope of work required to get to the stage where we can support ramfs loadable modules that can be run using coconut SVSM tasks at CPL-3.
This PR is based on an earlier effort, before the scheduler and file virtual memory mapping PRs were merged (#64 and #145). The content of these merged PRs grew out of the PoC work that can be found in this PR. The original work can be seen in this PR in my own repo: https://github.com/roy-hopkins/svsm/pull/2. Although now closed, there are a number of useful comments on that PR that need to be addressed if we decide to take any of this commits forward.
This PR adds support for enumerating ELF binaries packaged into the initial ramfs image, loading and parsing those binaries and creating user-mode tasks with the relevant segments of the ELF binary mapped to the requested per-task virtual address. The SYSCALL/SYSRET interface is initialised and used to switch to CPL-3 to call the module entry point. A very basic SYSCALL handler has been put into place to allow termination, logging and sleeping (context switch) from the CPL-3 module.
Treat this PR at this stage as incomplete work, or as a basis for picking out useful features and implementing as separate PRs. I have taken a few shortcuts and assumptions in order to get a full end-to-end CPL-3 module test working, particularly around handling stacks around the CPL switch. But please feel free to take a look, try it out and comment on this PR.
I have created a sample module here: https://github.com/roy-hopkins/svsm-module. The README.md for the sample module has details on how to build it and add it to the initial ramfs image.

Superseded by other changes. Closing.


[DSPv2] Add/manage missing empty tekton config CMs/Secrets

In the DSPv2 PoC, there are some CMs and Secrets that need to simply be created in order for the v2 backend component to populate data with. To be specific, these are:
Config Maps

config-artifact-bucket
config-artifact-pvc
config-defaults
config-observability
config-spire
config-trusted-resources
feature-flags

Secrets

kfp-exithandler-webhook-certs
kfptask-webhook-certs
tekton-pipelineloop-webhook-certs

Add these to the V2 Manifests, or alternatively, figure out why the OpenShift Pipelines Operator (v1.12.0+) is no longer supply them.

Testing @gmfrasca's branch of dspv2 with Openshift Pipelines Operator v1.11.1 to test if the creation of these Config Maps and Secrets works as its supposed to.

So this isn't related to Openshift Pipelines Operator not providing these respective Config Maps & Secrets as I can see in both Openshift Pipelines Operator v1.11.1 and v1.12.0, there is an instance "pipeline-main-static-x" of CRD TektonInstallerSets which successfully creates this in the openshift-pipelines namespace. Also only the webhook pods are failing to access/leverage these config maps and secrets.

Pulled in all the latest commits on the dspv2 branch to catch up on backlog, the issue persists. So I am going ahead with manual creation of these secrets & configs and will update codebase if that works.

Looks like https://github.com/opendatahub-io/data-science-pipelines-operator/pull/443 is merged so closing this issue.


Feature/refresh by org

This adds the endpoints for refresh-by-organization for tools and workflows.  This also fixes the delete token response.  Similar response fixes will be needed.

Coverage decreased (-0.1%) to 71.626% when pulling cce061e455a3bbeeef59ec119e32f72738b4ec81 on feature/refreshByOrg into f23dd759f94dcb47d7a432861df0342201906528 on develop.

Coverage increased (+0.2%) to 71.921% when pulling ea6c51653e468553fca309aad186f53fd741f139 on feature/refreshByOrg into f23dd759f94dcb47d7a432861df0342201906528 on develop.

Coverage increased (+0.2%) to 71.907% when pulling 09a805791448830ab4b28659a9d64864b8976bce on feature/refreshByOrg into fe270fb5920a842981de8360531ecf4e2ca19d32 on develop.


Frontend: Enable $GlobalActors by default

Global actors have been an accepted language feature for a couple of compiler releases now, but the feature definition was associated with the --enable-experimental-concurrency flag. This caused some .swiftinterfaces containing global actor declarations to be unparsable because the logic for surrounding declarations with the $GlobalActors feature guard was incomplete (for example, classes with a global actor attribute were not guarded even though the declarations of global actor types were).
Rather than trying to fix the logic of usesFeatureGlobalActors(), enable it by default.
Adds a test that demonstrates that modules defining and using public global actors produce module interfaces that can be parsed successfully.
Resolves rdar://100150703

@swift-ci please test

@swift-ci please test

I suppose we should also enable $Actors by default but I think that could be a separate PR.

@swift-ci please test

This fixed https://github.com/apple/swift/issues/62370


Search highlighting broken in visual mode for first character/word in selected text

Mapping: vnoremap <leader>s <Esc><cmd>SearchBoxReplace confirm=menu visual_mode=true<CR>
Selected text:

First character searched:

( first 'l' is ignored. )

First word searched:

( first 'local' is ignored. )

First word searched except first character:

( works as intended )
Although it doesn't highlight the first character/word when searched, replacement does work.

Off by one errors...
It should be fixed now in 91808ad. And hopefully I didn't break anything else.


Update the table for authenticator passwordless

Update the table for authenticator passwordless since it can be used as secondary authentication only when CBA is primary authentication.

@Justinha

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hello @Justin @.***>,
My name is Chi from Azure ID team of Japan.
We have a S500 customer waiting for this to be published.
It would be really appreciated if you could review this in priority.
Thank you.
-chiyao-
From: Jak Koke @.>
Sent: Tuesday, February 13, 2024 1:50 PM
To: MicrosoftDocs/entra-docs @.>
Cc: Chi Yao @.>; Mention @.>
Subject: Re: [MicrosoftDocs/entra-docs] Update the table for authenticator passwordless (PR #367)
@Justinhahttps://github.com/Justinha

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-teamhttps://github.com/orgs/MicrosoftDocs/teams/public-repo-pr-review-team

Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/entra-docs/pull/367#issuecomment-1942687109, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGXHFQMFKZOUNWB2GKCWX5DYTPN2BAVCNFSM6AAAAABDHE2U76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBSGY4DOMJQHE.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

nudge @Justinha - can you take a look? (the link needs to be fixed, but I can do that if you'd like... ) thanks!


Fix inverted text display. Fix #883

This is similar to #821 but preserves background transparency.
hterm swaps foreground and background text attributes when handling inverted text (e.g. echo -e "Normal \e[7minverted"). Therefore, we can't set background-color as transparent as we'll get invisible text in this case.

@rauchg the comment has been added.


Topic missing details on how exactly to navigate to the page or what is the hierarchy to navigate to page in paortal

[Enter feedback here]
I don't see any NSG in my Synapse Works space.
The topic seems to be out of context and is missing where exactly this need to be created in the context of Synapse workspace.
Please consider all the steps leading to the topic being discussed, taking into consideration that person may not be familiar on how to arrive at the page that is being disccused

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 36342e9e-93eb-3b34-ff09-fd0378fe0664
Version Independent ID: 3523eac4-35a5-d207-94f0-69017e1d40e9
Content: Connect to workspace resources in Azure Synapse Analytics Studio from a restricted network - Azure Synapse Analytics
Content Source: articles/synapse-analytics/security/how-to-connect-to-workspace-from-restricted-network.md
Service: synapse-analytics
Sub-service: security
GitHub Login: @Danzhang-msft
Microsoft Alias: danzhang

@nssidhu
Thanks for your feedback! We will investigate and update as appropriate.

@nssidhu
I've delegated this to @Danzhang-msft , a content author, to review and share their valuable insights.

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


fix: instructions for adding a group for new team

When following the Otomi Labs, it seems that the Keycloak instructions are not complete:

The role team has not been created on install, nor after creating a team labs from the Otomi console
Each a role and group team-labs are required before a user assigned to the group can log in

The Keycloak job on team creation does not seem to have worked as it should, probably due to issues deploying on Scaleway.


Github meetup #3: March 6th 2015

Where
March 6, 7:00 PM, Sala Generalife, CEVUG C/ Real de Cartuja, 36-38 Granada. We can no longer fit in the OSL.
What

General introduction to the @github crowd in Granada
Intro to socket.io by @iblancasa
Local craft beer at El Sur de Granada

Who
Everyone is invited, whether you are in @github or not, but specially @stringparser, @iblancasa, @fergunet, @rafael1193, @psicobyte, @renatolrr, @makova, @fdavidcl, @ncordon, @m42, @eparejatobes, @pablopareja, @vterron, @pleonex, @ernestoalejo, @oskyar, @oxcar103, @algui91, @potray, @antorof, @fergunet, @demiurgosoft, @rafael1193, @unintendedbear, @agarciamontoro, @torresj, @josemlp91, @juanafernandez @ivanortegaalba @pbaeyens  y @franexposito.
Why
We githubbers will be meeting every first Friday of every month, at the @oslugr or anywhere for technical and trash talking. We'll do it in Spanish or English, depending on what language is the best for all parties involved. This issue closes #12 .

I can ask for a guest Wifi account if needed.

Niiice :space_invader: :D
Just in case, here is how the cevugr building looks like. And to get there you can go by:

Bus

Find you way with the GranadaBus app, or
Get lucky finding the bus name you need on the robert map

Foot. If you know were Triunfo is, follow the dots :dancers:.

And here is where the Sala Generalife is within the building

Car is not a good idea :oncoming_automobile:

See you there! I hope I have time to make mini-cupcakes :cake: :)

Cool!

:+1:

At the end, i have to go to my village and i can't take part, sorry :(.
Have fun!

Me too, its been a while since I was there, enjoy!

Muchachos, no os perdáis el próximo. Si no hay más crónicas o fotos que subir cierro.


one small mistake

I think here is the 'is',instead of 'if'.

if is actually correct

Alright...,but i was confused to got the message obviously,can you explain it in another way?
Many tks!

I just tried rephrasing this comment to:

The name of the slot, if this component is the child of another component

Does that make more sense?


NLI evlaution mode doesn't provide 3 classes

from alignscore import AlignScore
scorer = AlignScore(model='roberta-large', batch_size=1, ckpt_path ="models/AlignScore/checkpoint/AlignScore-large.ckpt", device= "cpu", evaluation_mode='nli')

print(scorer.score(contexts=['hello world.'], claims=['hello world.']))
Evaluating: 100%|██████████| 1/1 [00:01<00:00,  1.96s/it]
[0.9887175559997559]

During loading model checkpoint I as well got warned about not initialized model weights, as outlined in the previous issue (https://github.com/yuh-zha/AlignScore/issues/7 ).

From their codebase, the inference function for NLI only returns the score for "Aligned" class (the first class of the three). You may need to modify the inference code a bit to obtain all three.


Device audio levels duck when app is open

The home screen video is treated like it's playing sound even with no audio channel, so music/podcasts reduce volume when using it

There's an isMuted property for Expo Video. Let's try setting that and see what happens.

Fixed. We were using muted, but not isMuted.