Add support for the NAB Transact payment gateway (AU)

This commit is a repackaging of code written by Tom Meier (github.com/tommeier) to add support for the NAB's Transact payment gateway. Gateway and remote gateway unit tests all appear to be good and pass.
Lighthouse ticket with the original patch appeared to go unnoticed. Updated here:
https://jadedpixel.lighthouseapp.com/projects/11599/tickets/164-patch-add-support-for-nab-transact-au-payment-gateway
Cheers,
James Brooks

Closing this in preference for #124.


Downgrade to tablescan

Refer to https://github.com/pingcap/tikv-client-lib-java/issues/179
TiSpark PR https://github.com/pingcap/tispark/pull/140

Can add downgrade information in TiDAGRequest.
Rename where to filter in TiDAGRequest.
Add REGION_INDEX_SCAN_DOWNGRADE_THRESHOLD config.

This change is

@zhexuany @ilovesoup @birdstorm PTAL


Switching Representations with different loaders

Problem
Currently we seem to be only supporting switching representations if they are all supported by the same loader. This effectively prevent using this for switching proxy geometries for render time proxies (geometry -> arnold standin for instance)
Solution
From my initial testing it seems that it would be enough to get the loader from the new representation being loaded, rather than container and all should be good. Now obviously if there are more loaders per representation, then there's the question which one to use.
Additional problem is that I have artists asking on a daily basis for being able to keep the representation but change the loader. For instance changing referenced alembic to gpu cache and back. This is very useful for huge scenes.

This is an amazingly interesting case, and a big plus if we can figure it out in a stable way.
Unfortunately this isn't trivial. When "switching" from a referenced Alembic GEO to a gpuCache it means that the Alembic GEO reference should actually be removed from the scene, right? Or what other special logic would you apply?
Whenever you remove the referenced Alembic GEO then any local changes to that geometry would be gone, any shader assignments, any tweaks or changes in positioning. As such, switching back and forth makes no sense.
What was your idea on tackling that?
Currently with "switch" it's all done on the Loader itself, as such, any data that needs to persist on the switch can be tracked there. It's up to the Loader (if not a Maya reference, as that would store reference edits even if failed anyway) to potentially store that data somewhere if it needs to remain after switching back and forth. However, if you do the same between different Loaders - then every loader would need to take into account any other loader and what kind of data it might want to preserve?)
In your case, if the removal of data is alright, it's a matter of calling "remove" on the existing instances and "load" on the new ones. Yes?

And yes, the other problem is knowing what Loader to switch to if a specific representation and subset supports multiple loaders. (If we are allowed to "switch Loader")

When "switching" from a referenced Alembic GEO to a gpuCache it means that the Alembic GEO reference should actually be removed from the scene, right?

Correct. that's the only way I can think of at this point.

Whenever you remove the referenced Alembic GEO then any local changes to that geometry would be gone

we're aware of that and don't really have a good solution at this point to be honest. However we would keep the transform of the top group at the very least which is trivial.
At this point I'd approach it with a warning before the actual switching notifying the user that all his changes apart from the position will be lost.

the other problem is knowing what Loader to switch to

I thought a good solution might be adding a a 4th dropdown that lists available loaders, so the user can choose

Alembic GEO then any local changes to that geometry would be gone, any shader assignments,

actually I had a though. Maybe we could store the changes that can be serialized (like ref edits) in an attribute on the container. So if artist switches back to original loader at later time we could reapply them.
For instance. I have model loaded using reference loader. When switching to gpu cache we take all ref edits and serialize them into json format and save to attribute.\ on container
along the lines of
referenceLoader:{attributes: ......, connections: ....... etc.}

when switching back to reference, we try to find referenceLoader in the specified attribute data and apply all of them again. This would of course be quite limited to how far we can push it, but could most probably cover the most used cases. i.e. switching from reference to gpuCache and back, or in our case from reference to arnold standin and back

Just to throw this in there, could a loader call another loader? That way, maybe there could be a "loader container" of sorts.
class LoaderA(...):
  ...

class LoaderB(...):
  ...

class LoaderContainer(...):
  def load(...):
    if some_expression:
      return api.loader("LoaderA").load(...)

Maybe wouldn't even have to be a "container", just one loader calling another.

I think I could share something on this. :)
My implementation for switching proxy (GPU cache), take my model loader for example, was done by extracting not only model .mb but also the gpu cache during the publish, and the gpu cache gets wrapped into a mayaAscii file during that process in this way, which could be referenced later on :
gpu_files = ["modelDefault/v001/gpu.abc"]
output_path = "modelDefault/v001/gpu.ma"

MayaAscii_template = """//Maya ASCII scene
requires maya "2016";
requires -nodeType "gpuCache" "gpuCache" "1.0";
"""

gpu_node_template = """
$cachefile = `file -q -loc "{filePath}"`;  // Resolve relative path
createNode transform -n "{nodeName}";
createNode gpuCache -n "{nodeName}Shape" -p "{nodeName}";
    setAttr ".cfn" -type "string" $cachefile;
"""

gpu_script = ""
for gpu_path, node_name in gpu_files:
    gpu_path = gpu_path.replace("\\", "/")
    gpu_script += gpu_node_template.format(nodeName=node_name,
                                           filePath=gpu_path)

with open(output_path, "w") as maya_file:
    maya_file.write(MayaAscii_template + gpu_script)

And then I could swap the reference between model file and the gpu cache with the same model loader.
Hope this helps ?
Not sure about other renderer specific like Arnold stand-in or VRay proxy, haven't gone that far, yet. But I think as long as we could wrap everything into a Maya referenceable format, should be able good enough for this issue, right ?

Had a deeper look at this since I was also trying to implement cross loader switch for switching in between Arnold Stand-In and model or rig.
I imaging the ultimate goal would be something like this :
        +----------+      +-------------+
    --> | xgenHair | <--> | gpuCacheHat | <..
        +----------+      +-------------+
..         4      4         4        4         ..
  \       /        \       /          \       /
   v     v          v     v            v     v
 +----------+      +---------+     +------------+
 | meshHair | <--> | meshHat | --> | hairSimRig | <-..
 +----------+      +---------+     +------------+

An XGen hair subset for example, can be switched to hair card model, gpu cache, or other representation of asset Hat.
We could switch freely as long as the chosen loader has been implemnted to be able to process the subset which was not loaded by itself.
Implementation proposal
Assume that we all using scene file referencing to load those subset.
Asset Switcher GUI
The switcher GUI must aware of all Loaders that matched with the selected representation. So for this issue:

the other problem is knowing what Loader to switch to if a specific representation and subset supports multiple loaders

I propose to implement like this to reslove:

If only one loader that matched with the representation
Display loader icon, and maybe loader name in tool hint

If there are multiple loaders that matched
Turn into question mark, and click LMB or RMB to show a drop-down menu for selecting the loader.

cbsceneinventory
Adding one more optional arg options for indecating which loader been selected.
# avalon.tools.cbsceneinventory.lib

def switch_item(...):
    ...
    options = dict()
    options["loader"] = Loader.__name__
    api.switch(container, representation, options)

api
And implementing one more method covered for loader to judge whether it could switch the subset currently loaded in scene.
# avalon.pipeline(api)

def switch(container, representation, options=None):

    options = options or dcit()
    cross_load = False

    # Assume they are Loader cls
    Loader_opt = options.get("loader")
    Loader = container["loader"]

    if Loader_opt is not None and Loader != Loader_opt:
        if not hasattr(Loader_opt, "covered"):
            raise RuntimeError("Cross load not supported.")
        cross_load = True
        Loader = Loader_opt

    if not hasattr(Loader, "switch"):
        raise RuntimeError("Switch not supported.")

    context = get_representation_context(representation)
    assert is_compatible_loader(Loader, context), "Not compatible."

    loader = Loader(context)

    if cross_load:
        # Whether this selected loader able to replace currently loaded subset to another.
        assert loader.covered(container, representation), "Not covered."

    loader.switch(container, representation, options)

With these, as long as the subset stay referenced, I think we could switching in between loaders without a problem.
Please let me know what you think :)

Here's a implementation sneak previews :D
Switching from model to arnold stand-in and back.

With these, as long as the subset stay referenced, I think we could switching in between loaders without a problem.

So when you load StandIn, it is already wrapped in maya file so you can reference it?  Functionally I quite like the changes.

So when you load StandIn, it is already wrapped in maya file so you can reference it?

Yes, the .ass file gets wrapped right after it's been exported.
The switching part so far no big problems, reference edits will be apply back after switching.

Functionally I quite like the changes.

Thanks ! Those GUI stuff was built upon #372 (obviously), hope it gets merged soon.

Just to double check. So it's up to the new Loader to return whether the switch can be done from a container with a different loader.
What is good about this one is that it does not hardcode the idea of References for maya. It allows the studio configuration to "store" ref edits temporarily on a custom attribute in the container like: _edits, maybe even as dict per Loader. Then you could even start storing edits for things that are not references and in other hosts.
I'm a bit afraid of the conplexity and managing the multiple directions. With this I'd love to see an example that switches consistently between a ASS standin (non-referenced) and a Maya reference.
I think it's interesting to hear that you are wrapping the ASS in maya references. Doesn't that takeaway quite a large bit of the loading speed of the scene? As ass proxies I guess are most useful if you tend to have in 100s of them (or if they are super huge files). Whereas when you have 100s of references Maya tends to become a bit sluggish with loading, or isn't that the case anymore in recent releases? - might be a bit off-topic conversation though.

Just to double check. So it's up to the new Loader to return whether the switch can be done from a container with a different loader.

Yes, but still wondering if there are any better name than covered.

I'm a bit afraid of the complexity and managing the multiple directions.

Perhaps (in my imaging) we could use that covered method to decide specifically on which asset or subset, or even version, that allowed to cross loader switching in run-time. By doing this intentionally limitation, should able to reduce some uncertainty. Does this make sense ?

With this I'd love to see an example that switches consistently between a ASS standin (non-referenced) and a Maya reference.

Here's a long GIF I tested on a animated rig from Mixamo.

Not sure why when I switching back to Rig from Ass, the rig require to refresh to pick up animation. :/

Doesn't that takeaway quite a large bit of the loading speed of the scene?

Haven't think about that before actually, not often using stand-in here (we just begin to adopt Arnold). But that's a good point, hmmm..., maybe that depends on how often you want to switch things... need to think more on this.

Doesn't that takeaway quite a large bit of the loading speed of the scene?

 I think the same will be true for vray proxies.

When "switching" from a referenced Alembic GEO to a gpuCache it means that the Alembic GEO reference should actually be removed from the scene, right?

For this part, how about just unload that reference, and using a callback like this:
from maya.api import OpenMaya as om  # API 2.0

def before_load_reference(reference_node,
                          referenced_file,
                          clientData=None):
    """Check if the reference is okay to be reloaded"""
    dep_fn = om.MFnDependencyNode()
    fn_node = dep_fn.setObject(reference_node)
    ref_node = fn_node.name()

    if ref_node in (cmds.sets("DO_NOT_LOAD", query=True) or []):
        # Or any other condition
        return False
    return True

# Register the callback
om.MSceneMessage.addCheckReferenceCallback(
    om.MSceneMessage.kBeforeLoadReferenceCheck,
    before_load_reference
)

With this callback, the reference will get reloaded only on certain condition, e.g., not being a member of "DO_NOT_LOAD" objectSet.

Adding more input, not having a result, yet.
Using asset container node to hold import-only subset
On the part that switching imported subset to referenceable type or another import-only subset, currently experimenting on using Maya asset container node to hold the import-only subset.
By adding import-only subset nodes into a DAG type asset container node, it could provide a limited editing interface via exposing bonded attributes only, e.g., Arnold stand-in node's frame range attributes and hide the rest.
With that limitation, we can focus only on the attributes that we exposed while switching. And because we could use custom attribute name to bind the subset node's attribute like :
cmds.container("Hulk_01_AST", edit=True, publishAndBind=["node.anyAttr", "abs_name"])

Then we would able to implement a way to remap those attribute's connections and values to the subset that is being switched into scene, by using published attribute name "abs_name" as key.
After the connections and values' remapping and preserving is done, we could safely delete nodes in that asset container, since those were the only variations that artist could apply to. And hide it from outliner if it's being switched to a reference.


Node-shebangs (#!...) gives errors...

...Which works fine in JSCS CLI.

Created pull request to fix this issue:
https://github.com/globexdesigns/brackets-jscs/pull/18

v0.3.0 was just pushed to the Brackets Extension registry which completely removes JSX processing, so this patch should no longer be needed.


Optimize process step

Since every processor right now iterates over every single key of a style object there might be some optimisation possbiel

Could break other processors so best is to still run one after another


deprecated directive

This mostly includes adding a plethora of query positions to the current directive implementation

[ ] Verify directive uniqueness (repeated)
[ ] Expose directive in introspection


New beta cannot init containers with zfs root

Steps to reproduce (I hope):

rootfs on a zfs dataset (e.g. "system/funtoo/root")
set lxd to use a dataset on the same zpool as the rootfs (e.g. "system/lxd")

With lxd 0.27 this works as expected. However, the new betas (1 and 2) yield
error: Disk system is missing /sys/class/block entry

(where "system" is my zpool). ZFS pools&datasets don't have such entries. The offending line is this and the fix could be similar to https://github.com/lxc/lxd/commit/596a1a983d6521454982f74ad8748cb8af5c02fe in nature, though I'm not familiar enough with lxd internals to be sure.

Sounds like you're using beta1, that error message doesn't exist in beta2.

Hm, you're right, I just double checked and there was a bug in my build script for beta2, resulting in the old tarball being used. Sorry about that, I will close for now.


Plugin legacy name certbot-dns-freenom:dns-freenom may be removed in a future version. Please use dns-freenom instead.

The plugin works great, but this warning appears.
Plugin legacy name certbot-dns-freenom:dns-freenom may be removed in a future version. Please use dns-freenom instead.
How do I solve this?

fix
credentials.ini
dns_freenom_username =<EMAIL_ADDRESS>dns_freenom_password = password

sudo certbot certonly -a dns-freenom   --dns-freenom-credentials /path/to/credentials.ini   --dns-freenom-propagation-seconds 300   -d "*.example.com"   -m<EMAIL_ADDRESS> --agree-tos -n

Is it working? I knew about this warning, but don't pay much attention.
Which version of certbot do you use?
I'll check this and fix instruction.

Yes it works
certbot --version
certbot 1.12.0
sudo certbot certonly -a dns-freenom   --dns-freenom-credentials /path/to/credentials.ini   --dns-freenom-propagation-seconds 300   -d "*.example.com"   -m<EMAIL_ADDRESS> --agree-tos -n
result
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-freenom, Installer None
Requesting a certificate for *.example.com
Performing the following challenges:
dns-01 challenge for example.com
doLogin: Login successfully.
setRecord: Record added successfully
Waiting 300 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges
delRecord: Record deleted successfully

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your certificate will expire on 2022-04-29. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Yes, everything fine!
I updated test and instruction.
Thank you @xgusto!


A real-world example NER example Chapter 03

Hi everyone I am copying from the book the code that takes the NY times article but I cannot get the book's output and also the code is not in chapter 03
from bs4 import BeautifulSoup
import requests
import spacy
def url_text(url_string):
     res = requests.get(url_string)
     html = res.text
     soup = BeautifulSoup(html, 'html5lib')
     for script in soup(["script", "style", 'aside']):
      script.extract()
     text = soup.get_text()
     return " ".join(text.split())
ny_art = url_text("https://www.nytimes.com/2021/01/12/opinion/trump-america-allies.html")
nlp = spacy.load("en_core_web_md")
doc = nlp(ny_art)
len(doc.ents)
from collections import Counter
labels = [ent.label_ for ent in doc.ents]
Counter(labels)
Thank you

Hellos, thanks for writing.
Yes, I put some selected code to the repo, not all of the book.
Would it be possible to send a screenshot or just copy paste the output? This is a small code fragment, should work rather trouble free.

Hi thank you for the reply, this is an image of the output

Cheers


Don't linkify the "orgs" in organization 404 pages

Closes https://github.com/refined-github/refined-github/issues/5483

Test URLs
https://github.com/orgs/date-fns/teams/i18n-id
Before

After

I would still show orgs, but neither linkified nor deleted. People could have a repo called "teams" and we need to differentiate with that. Also there are other pages under /orgs.
There's still potentially improvement here. The teams part appears to work but in fact it just redirects and says "You’re not a member of any teams in this organization." I wonder if we should include any link that gives a redirection.

Good point, it makes me wonder if we should also not drop the other parts of the URL like blob etc, but instead keep them dimmed

we should also not drop the other parts of the URL

Done:

Test:
https://github.com/refined-github/refined-github/tree/main/nofile

we should also not drop the other parts of the URL

Done:

Nice, we can skip those meaningless parts we are sure e.g. orgs, tree, blob.
Also, could we try to should each part unstyled first, then linkify/delete them based on the response? Theoretically they can lead to another 404 if you try hard enough.


Text area auto complete for multiple items without a token

I want to have a textarea that auto complete from the collection but without using a token
Is that possible ?
so that the user whenever he types a letter it suggests from the collection and let him add multiple not just one.
Thanks in advance,
Nader Ikladious.

Hi @NaderIkladious.
Have you solved this issue, I'm trying the same thing.
I'm using @mpowaga Meteor Autoform AutoComplete
It seems to be possible, but you have to create another custom afInputType and duplicate all the template-copy logic for this new type.
I'll make this very soon, if you like, I can send you the solution.
Thanks in advance.
Loé Lobo


Athena boto client requires region_name parameter, but none in supplied.

Background
Have you tried pinging us on Slack?
https://streamalert.herokuapp.com/ - No, this can be addressed as described later in this issue.
Are you on the latest version of StreamAlert:  Yes, pulled from master about 20 minutes ago.
Description
During the init process ./manage.py terraform init the following error is thrown.
botocore.exceptions.NoRegionError: You must specify a region.

This is because the boto3.client("athena") call at line 52 (https://github.com/airbnb/streamalert/blob/27f7cf9cc6721cd36f815e00b922939c28be1bc2/stream_alert/shared/athena.py#L52)
does not include the region_name parameter.
Steps to Reproduce
run
./manage.py terraform init

with a fresh setup
Desired Change
This can be easily fixed by changing this to
self._client = boto3.client('athena', region_name=region')

However, the current init function for entry to the athena module does not include a region parameter.   I am not familiar enough with the current method of passing and calling these modules to say if this should be passed at initialization time as a parameter, or if this should be an object property referenced by self.region  I will leave that to the maintainers to decide.
PS.  I have tested this fix by hard-coding the region in my fork and this works.
High level overview of the desired change or outcome.
Error disappears, everyone goes home happy.

Receiving this same error after git clone --branch stable https://github.com/airbnb/streamalert.git with git hash 557fb3f604661cdd9bd36486cccc8ce3a34bd1f1.

thanks for filing this issue! I will be addressing soon, but in the meantime you can get around this by simply doing this in your shell:
export AWS_DEFAULT_REGION="us-east-1"
In the above, replace the region with your desired region.


Do not require all supported languages to be specified in YAML files

Djinni generator currently fails to parse a YAML file unless all of the supported languages are specified; there's an unhandled exception java.util.NoSuchElementException: key not found: <key> for any missing field (as can be seen in this run). This issue becomes more relevant as more languages get supported by the generator.

Hi,
After upgrade to version 0.5.0 and generate my files i get error:
![image](https://user-images.githubusercontent.com/395096/116300362-30ff9300-a775-11eb-850f-1ba2ed8160b2.png)

Exception in thread "main" java.util.NoSuchElementException: key not found: translator
	at scala.collection.immutable.Map$EmptyMap$.apply(Map.scala:107)
	at scala.collection.immutable.Map$EmptyMap$.apply(Map.scala:105)
	at djinni.YamlGenerator$.metaFromYaml(YamlGenerator.scala:227)
	at djinni.resolver.package$.$anonfun$resolve$1(resolver.scala:52)
	at djinni.resolver.package$.$anonfun$resolve$1$adapted(resolver.scala:38)
	at scala.collection.LinearSeqOptimized.foreach(LinearSeqOptimized.scala:75)
	at scala.collection.LinearSeqOptimized.foreach$(LinearSeqOptimized.scala:72)
	at scala.collection.mutable.MutableList.foreach(MutableList.scala:33)
	at djinni.resolver.package$.resolve(resolver.scala:38)
	at djinni.Main$.main(Main.scala:363)
	at djinni.Main.main(Main.scala)
COMMAND: /Users/paulo/Developer/workspaces/cpp/ubook-sdk-mobile/build/gluecode/djinni --java-out generated-src/java/com/ubook/domain --java-package com.ubook.domain --ident-java-field mFooBar --java-implement-android-os-parcelable true --cpp-out generated-src/cpp/ubook/domain/ --cpp-namespace ubook::domain --cpp-include-prefix ubook/domain/ --ident-cpp-field fooBar --ident-cpp-method fooBar --ident-cpp-file FooBar --ident-cpp-local fooBar --ident-jni-class UBDomainFooBar --ident-jni-file UBDomainFooBar --jni-include-cpp-prefix ubook/domain/ --jni-include-prefix com/ubook/domain/ --jni-out generated-src/jni/com/ubook/domain --objc-out generated-src/objc/ubook/domain/ --objc-type-prefix UBDomain --objc-include-prefix ubook/domain/ --objcpp-include-cpp-prefix ubook/domain/ --objcpp-include-prefix ubook/domain/ --objcpp-out generated-src/objc/ubook/domain/ --yaml-out yaml --idl proj.djinni
WORKING DIR: /Users/paulo/Developer/workspaces/cpp/ubook-sdk-mobile/files/gluecode/app-domain

Yep @paulo-coutinho, that's the problem... 😞  Since 0.5.0 all yaml files are required to also define a C# type definition.
If the yaml files are generated by djinni, I guess you could fix this by regenerating them.
If they are handwritten, you could temporarily fix this by adding a placeholder like this for each type defined in yaml:
cs:
  translator: 'coming soon'
  header: 'coming soon'
  typename: 'coming soon'
  reference: false

If you are not interested in the newly added C# support in v0.5.0, I recommend you to downgrade to v0.3.2 or v0.4.0 and wait until we provide a fix for this issue.

Hi,
Yes, im using version 0.3.2 until it be solved. I have hundreds of files.
Thanks anyway.

Nice. Thanks.


Bug Report: weird cursor behaviour in Far Manager command line

Environment
Windows build number: Microsoft Windows [Version 10.0.18362.295]
Windows Terminal version: 0.4.2382.0
Far Manager - practically any available, last tested on Far Manager v3.0 build 5454 x64 (2019-08-23)

Steps to reproduce

install Far Manager from https://farmanager.com/download.php?l=en
run Far Manager inside Windows Terminal (from cmd session or by creating new profile)
type any text, look how cursor moves in command line while typing
press Ctrl-O, try to move cursor using directions keys
press "Enter" with any text entered in command line (no matter when in panels mode or in history mode, switched by Ctrl-O, no matter if correct command or any text)
type any text again, look how cursor moves while typing
press Ctrl-O, try to move cursor using directions keys

Expected behavior

cursor follows entered text
cursor moves when "left" or "right" button pressed
just like it is after fresh start

Actual behavior

cursor is displayed before last printed character, not after
cursor does not moves when left or right buttons are pressed (just not displayed, internal position gets updated)

P.S. As I get it, it has something to do with the way Far clears and redraw the screen or with the way commands are executed in Far, but I have no ways to localize that bug in Windows Terminal or in Far. At least same version of Far works OK in plain cmd.exe or ConEmu.

Oops, it seems to be fixed by "Use Virtual Terminal for rendering" Far Manager option, just introduced in the latest version. Just for me that's enough, don't know if that "bug" still worth investigation.

Hey so I know it's been few years, but I'm playing around with Far 3.0.5888.0 and Terminal 1.12, and this seems fixed to me. OP can you confirm? I suspect this was accidentally fixed by something else along the way.


Subpar handling of blocks from the future

When the node manage to download a block from the future it is not adopted directly, rather it is tucked away with the hope that it can be adopted when the time comes. Any time a new block is downloaded or after a forged block is adopted the node checks to see if there are any old blocks-from-the-future that it could adopt. If there are such blocks they are adopted before the new block.
Notably it appears that a new slot/tick isn't enough to trigger the adoption of blocks-from-the-future, it is always dependent on another block being added.
This means that if all nodes in the network where to download a block early then the only way for the network to progress would be by a BP forging a new block on the current tip (that is without the block from the future). This would cause the BP to notice and adopt the old block-from the future, then it would attempt to adopt its forged block. If it lost due to vrf the TraceDidntAdoptBlock would be shown. If the BP lost it means that another BP would have to attempt to beat the block-from-the-future, since no new block was adopted nothing will cause the rest of the nodes in the network to adopt the block-from-the-future.
Suggestions:

Before forging a new block chainSelectionForFutureBlocks should be run so that the node can forge its block on top of blocks-from-the-future.
Trigger adoption of blocks-from-the-future without depending on any new blocks. This could be done by having a 1s timeout on the getBlockToAdd in addBlockRunner . If there was a timeout call chainSelectionForFutureBlocks and try again.

This would stop blocks from the future causing forks.
I suspect that this is at least partially the cause of https://github.com/input-output-hk/cardano-node/issues/4720
@nfrisby

My node had a block from the future around the time of the https://github.com/input-output-hk/cardano-node/issues/4720 issue .

An SPO shared logs with @gufmar  regarding another TraceDidntAdoptBlock at 2023-01-02T05:13:57.03 .
This also matches with a block from the future.

we have noticed several such examples in the last 4-5 epochs, as one pool regularly announced its blocks a little too early (enough to reach many/most other nodes before the actual slot time)
This is an example how it looks like

one of the four nodes heard about the new blockheader for slot 79817694 late enough. so he fetched and adopted, all fine.
Another node heard about the block, and had downloaded the body ~200ms before the slot time, but managed to adopt it localy.
Two other nodes also got the header and block body before the actual slot time. But then the final local adoption (green bar) was paused until the next block appearance.
In this example above the second block producer (for slot 79817700) hadn't received the previous block. It looks like all his relays hadn't adopted the block because of the early appearance.
So the second pool created a fork block.

@karknu
Glad my logs were of help to get to the bottom of this. Nice Grafana tile to visualize this problem, I shall try to reproduce this one for my own dashboard.
For anyone who wants to double check local BP log files for the same issue do this:
If there is a "TraceDidntAdoptBlock" with severity "Error" in the BP log, find the prior line in the BP log with the TraceForgedBlock message, in close vicinity above you should find a block announcement of a future block with negative delay being too early which blocked your own block.
In my case here the relevant code lines in line with the graphical representation of negative block delay:
{"app":[],"at":"2023-01-02T05:13:44.71Z","data":{"block":"ec095f8782d832cfbe936b43640cfbcfa07f8b57df333be9d23c490d3f766f13","delay":-0.285766939,"kind":"CompletedBlockFetch","peer":{"local":{"addr":"","port":""},"remote":{"addr":"","port":""}},"size":871},"env":"1.35.4:ebc7b","host":"ub20cn","loc":null,"msg":"","ns":["cardano.node.BlockFetchClient"],"pid":"833","sev":"Info","thread":"631239"}
{"app":[],"at":"2023-01-02T05:13:57.02Z","data":{"credentials":"Cardano","val":{"block":"521058f6067abb88828611255df6c2695393ae3abb4e113cf550c74ad9e88754","blockNo":8217108,"blockPrev":"9306145db376fd2aa74ea1bb24ed915f2f69a66d40dfdef2f68e82b53141a337","kind":"TraceForgedBlock","slot":81070146}},"env":"1.35.4:ebc7b","host":"ub20cn","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"833","sev":"Info","thread":"353"}
{"app":[],"at":"2023-01-02T05:13:57.02Z","data":{"block":{"hash":"521058f6067abb88828611255df6c2695393ae3abb4e113cf550c74ad9e88754","kind":"Point","slot":81070146},"kind":"TraceAddBlockEvent.TrySwitchToAFork"},"env":"1.35.4:ebc7b","host":"ub20cn","loc":null,"msg":"","ns":["cardano.node.ChainDB"],"pid":"833","sev":"Info","thread":"343"}
{"app":[],"at":"2023-01-02T05:13:57.03Z","data":{"credentials":"Cardano","val":{"kind":"TraceDidntAdoptBlock","slot":81070146}},"env":"1.35.4:ebc7b","host":"ub20cn","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"833","sev":"Error","thread":"353"}
So for my missed block this was most definitely the issue, good catch.

May I ask though for the rationale in adding the complexity to try to save blocks from the future? Why not keep it simple and just discard them to encourage proper node ntp configuration? Maybe because they are hard to avoid with improper time? A simple grep 'delay":-0' reveals 6 hits in my current node0.log. How much would really be lost though? In any case, I hope with Ouroboros Chronos implemented in the future, complexity such as this, which obviously has caused issues here, can be removed again.

We can't expect the clocks of all nodes to be completely in sync so there needs to be some allowance for blocks-from-the-future. Even Ouroboros Chronos needs to keep track of blocks-from-the-future.
There is a limit (currently 5s) for how far into the future blocks can be before they are ignored. This puts a limit on how out of sync nodes in the network can be.

I'm not 100% sure my comment will be useful, since Karl created this issue and the IOG team probably already observed similar behavior, but just in case I'll leave my logs here
So, the block d75e2bb9f1a1a7b083e081aff94a8e9363453f6a9eae40db1a884a6d468d49e8 first mentioned in my logs at 2023-01-07 05:14:09.69 UTC
[r1:cardano.node.BlockFetchDecision:Info:4018] [2023-01-07 05:14:09.69 UTC] [TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:28629, remoteAddress = <IP_ADDRESS>:3001}) (Right [At (Block {blockPointSlot = SlotNo 81502159, blockPointHash = d75e2bb9f1a1a7b083e081aff94a8e9363453f6a9eae40db1a884a6d468d49e8})]),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:18599, remoteAddress = <IP_ADDRESS>:5002}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:11805, remoteAddress = <IP_ADDRESS>:6000}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:23557, remoteAddress = <IP_ADDRESS>:3333}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:30965, remoteAddress = <IP_ADDRESS>:6002}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:14569, remoteAddress = <IP_ADDRESS>:6000}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:14771, remoteAddress = <IP_ADDRESS>:6000}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:28843, remoteAddress = <IP_ADDRESS>:3001}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:13251, remoteAddress = <IP_ADDRESS>:3001}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:17579, remoteAddress = <IP_ADDRESS>:5003}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:7281, remoteAddress = <IP_ADDRESS>:3333}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:12649, remoteAddress = <IP_ADDRESS>:3001}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:20081, remoteAddress = <IP_ADDRESS>:6000}) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (ConnectionId {localAddress = <IP_ADDRESS>:3251, remoteAddress = <IP_ADDRESS>:6000}) (Left FetchDeclineChainNotPlausible)]
and reached my block producer at 2023-01-07 05:14:09.73 UTC. According to the block schedule (based on the analysis of the blockchain), this block should have been created at 2023-01-07 05:14:10 UTC, so the block from the future. After that my pool haven't put this block into the chain (as Karl mentioned early), and just continued checking each slot for leadership till time for block creation came at 2023-01-07 05:16:01.00 UTC. After that the fork occurred
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:14:10.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502159,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:14:10.03 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 8.1502159e7)]))]
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:14:11.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502160,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:14:11.03 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 8.150216e7)]))]
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:14:12.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502161,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:14:12.02 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 8.1502161e7)]))]
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:14:13.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502162,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:14:13.03 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 8.1502162e7)]))]
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:14:14.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502163,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:14:14.02 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeNotLeader"),("slot",Number 8.1502163e7)]))]
......
[p1:cardano.node.LeadershipCheck:Info:326] [2023-01-07 05:16:01.00 UTC] {"chainDensity":4.976489e-2,"credentials":"Cardano","delegMapSize":1253566,"kind":"TraceStartLeadershipCheck","slot":81502270,"utxoSize":9598554}
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:16:01.03 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceNodeIsLeader"),("slot",Number 8.150227e7)]))]
[p1:cardano.node.Forge:Info:326] [2023-01-07 05:16:01.05 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("block",String "ac6a5ba8319f37a8997b9c6e8517710a4a61cec877992f980ebde143e9e93f90"),("blockNo",Number 8238422.0),("blockPrev",String "29a5c8bbcaf5da4de379205a5baa717f45e155432c1efad7479d6c03d2a55234"),("kind",String "TraceForgedBlock"),("slot",Number 8.150227e7)]))]
[p1:cardano.node.ChainDB:Notice:316] [2023-01-07 05:16:01.05 UTC] Chain extended, new tip: d75e2bb9f1a1a7b083e081aff94a8e9363453f6a9eae40db1a884a6d468d49e8 at slot 81502159
[p1:cardano.node.ChainDB:Notice:316] [2023-01-07 05:16:01.05 UTC] before next, messages elided =<PHONE_NUMBER>3411508
[p1:cardano.node.ChainDB:Notice:316] [2023-01-07 05:16:01.05 UTC] Chain extended, new tip: d75e2bb9f1a1a7b083e081aff94a8e9363453f6a9eae40db1a884a6d468d49e8 at slot 81502159
[p1:cardano.node.ChainDB:Info:316] [2023-01-07 05:16:01.05 UTC] Block fits onto some fork: ac6a5ba8319f37a8997b9c6e8517710a4a61cec877992f980ebde143e9e93f90 at slot 81502270
[p1:cardano.node.Forge:Error:326] [2023-01-07 05:16:01.06 UTC] fromList [("credentials",String "Cardano"),("val",Object (fromList [("kind",String "TraceDidntAdoptBlock"),("slot",Number 8.150227e7)]))]

The fact that my pool had also the block before d75e2bb9f1a1a7b083e081aff94a8e9363453f6a9eae40db1a884a6d468d49e8 might or might not be of interest

The first suggestion seems reasonable and like only a mild design challenge.

Before forging a new block chainSelectionForFutureBlocks should be run so that the node can forge its block on top of blocks-from-the-future.

This would ensure that you consider pending blocks before forging. When you do find such blocks this way, it would delay your new block by however long it takes to process the pending block.
The other suggestion, checking for pending blocks on some fixed internal (eg the midpoint of each block) might avoid that possible delay. But it also doesn't ensure that the leadership check notices the pending blocks (if they arrived very recently). Seems like a toss-up to me, and also maybe less natural to synchronize.
Not super confident either way, but those are my initial thoughts.

I'm unsure how to prioritize this wrt to other work. How prevalent is it? Are maleficent SPOs setting their clocks early, causing this to happen often?

I'm unsure how to prioritize this wrt to other work. How prevalent is it? Are maleficent SPOs setting their clocks early, causing this to happen often?

Here below is a list of all recorded blocks for last 3 weeks, with an header announced in the future.
headerTime tells the milliseconds the header reached the reporting node in advance.
adoption tells the time in milliseconds till local adoption. Values >0 <1000 are expected
Values > 1000ms indicate the situation described by Karl in this issue
Empty adoption fields also indicate a delayed local adoption. The difference is in this case the early announcing pool lost the height battle, and his block finally wasn't adopted.
Considering this extraordinarily negative impact on the rewards for the early announced block (50% of the lost slot battles go to its account, while the other 50% are shared with all the other pools), I wouldn't say that it is deliberately malicious. But if you look at the number of early announced blocks since mid-December 2022, you will notice that one particular pool is causing most of these altitude battles. (I won't name names here, the pool has already been informed).
This delaying effect may increases probability for #4252
I don't know it it opens other theoretical or practical attack vectors to malicious players.
| blockNo | slotNo   | headerTime | adoption | blockSize | reported         |
|---------|----------|------------|----------|-----------|------------------|
| 8160563 | 79905623 | -240       | 980      | 2125      | 19.12.2022 17:45 |
| 8162426 | 79943581 | -180       | 820      | 61231     | 20.12.2022 04:17 |
| 8163751 | 79972015 | -120       | 100      | 83417     | 20.12.2022 12:11 |
| 8165372 | 80003426 | -240       | 190      | 89514     | 20.12.2022 20:55 |
| 8165945 | 80014767 | -220       | 22660    | 46512     | 21.12.2022 00:04 |
| 8166572 | 80027236 | -270       | 660      | 48029     | 21.12.2022 03:32 |
| 8167190 | 80039236 | -270       | 14580    | 28482     | 21.12.2022 06:52 |
| 8167338 | 80042995 | -300       | 22780    | 2415      | 21.12.2022 07:55 |
| 8167583 | 80047611 | -290       | 16560    | 3161      | 21.12.2022 09:11 |
| 8169137 | 80080145 | -270       | 11040    | 33676     | 21.12.2022 18:14 |
| 8172488 | 80148890 | -300       | 390      | 2776      | 22.12.2022 13:19 |
| 8173782 | 80177008 | -220       | 28100    | 88576     | 22.12.2022 21:08 |
| 8175768 | 80218463 | -280       | 860      | 5492      | 23.12.2022 08:39 |
| 8176234 | 80227676 | -290       | 960      | 72537     | 23.12.2022 11:12 |
| 8178176 | 80267443 | -250       | 31790    | 52534     | 23.12.2022 22:16 |
| 8180134 | 80306773 | -300       | 5540     | 4452      | 24.12.2022 09:11 |
| 8181846 | 80343782 | -190       | 9060     | 42643     | 24.12.2022 19:28 |
| 8181980 | 80346301 | -150       | 100      | 89739     | 24.12.2022 20:09 |
| 8185162 | 80413291 | -260       | 2720     | 18212     | 25.12.2022 14:46 |
| 8188334 | 80477074 | -280       | 10490    | 25626     | 26.12.2022 08:29 |
| 8188555 | 80481990 | -260       | 20940    | 25441     | 26.12.2022 09:51 |
| 8189643 | 80503909 | -270       | 2700     | 25397     | 26.12.2022 15:56 |
| 8191455 | 80541475 | -280       | 11700    | 37297     | 27.12.2022 02:22 |
| 8167223 | 80040247 | -260       |          | 14436     | 27.12.2022 13:05 |
| 8193425 | 80582214 | -250       | 3560     | 32882     | 27.12.2022 13:41 |
| 8193725 | 80588451 | -290       | 10010    | 3653      | 27.12.2022 15:25 |
| 8194733 | 80610083 | -240       |          | 63649     | 27.12.2022 21:27 |
| 8195563 | 80626738 | -270       |          | 29210     | 28.12.2022 02:03 |
| 8196068 | 80636229 | -290       |          | 13836     | 28.12.2022 04:42 |
| 8196244 | 80640012 | -300       |          | 13745     | 28.12.2022 05:45 |
| 8197387 | 80663984 | -280       | 13910    | 21653     | 28.12.2022 12:24 |
| 8197691 | 80670450 | -260       | 22690    | 54181     | 28.12.2022 14:12 |
| 8197926 | 80675013 | -270       |          | 38979     | 28.12.2022 15:29 |
| 8198191 | 80680111 | -290       |          | 12367     | 28.12.2022 16:53 |
| 8198456 | 80686458 | -210       |          | 88978     | 28.12.2022 18:39 |
| 8198914 | 80696100 | -220       |          | 24495     | 28.12.2022 21:19 |
| 8200038 | 80719005 | -280       | 1510     | 26050     | 29.12.2022 03:41 |
| 8201064 | 80739796 | -310       | 11470    | 2656      | 29.12.2022 09:28 |
| 8201068 | 80739881 | -280       | 26270    | 2453      | 29.12.2022 09:29 |
| 8201503 | 80749162 | -290       | 14620    | 11336     | 29.12.2022 12:04 |
| 8201762 | 80754443 | -260       |          | 89656     | 29.12.2022 13:32 |
| 8201845 | 80755918 | -310       | 21620    | 9283      | 29.12.2022 13:57 |
| 8201845 | 80755918 | -310       | 21620    | 9283      | 29.12.2022 13:57 |
| 8202466 | 80768061 | -260       |          | 11323     | 29.12.2022 17:20 |
| 8202466 | 80768061 | -260       |          | 11323     | 29.12.2022 17:20 |
| 8202620 | 80771362 | -250       |          | 49763     | 29.12.2022 18:15 |
| 8202620 | 80771362 | -250       |          | 49763     | 29.12.2022 18:15 |
| 8202896 | 80777284 | -160       |          | 1767      | 29.12.2022 19:53 |
| 8202896 | 80777284 | -160       |          | 1767      | 29.12.2022 19:53 |
| 8205180 | 80823538 | -260       |          | 51533     | 30.12.2022 08:43 |
| 8205180 | 80823538 | -260       |          | 51533     | 30.12.2022 08:44 |
| 8205684 | 80834209 | -290       | 480      | 871       | 30.12.2022 11:41 |
| 8205684 | 80834209 | -290       | 480      | 871       | 30.12.2022 11:41 |
| 8205746 | 80835170 | -290       | 8640     | 18446     | 30.12.2022 11:57 |
| 8205746 | 80835170 | -290       | 8640     | 18446     | 30.12.2022 11:57 |
| 8205886 | 80838081 | -280       |          | 13140     | 30.12.2022 12:47 |
| 8205886 | 80838081 | -280       |          | 13140     | 30.12.2022 12:47 |
| 8206487 | 80850994 | -250       | 220      | 84062     | 30.12.2022 16:21 |
| 8206487 | 80850994 | -250       | 220      | 84062     | 30.12.2022 16:21 |
| 8206673 | 80854459 | -310       |          | 1543      | 30.12.2022 17:19 |
| 8206673 | 80854459 | -310       |          | 1543      | 30.12.2022 17:19 |
| 8206699 | 80854857 | -290       | 4550     | 27192     | 30.12.2022 17:25 |
| 8206699 | 80854857 | -290       | 4550     | 27192     | 30.12.2022 17:25 |
| 8206800 | 80856978 | -280       | 31800    | 8236      | 30.12.2022 18:01 |
| 8206800 | 80856978 | -280       | 31800    | 8236      | 30.12.2022 18:01 |
| 8207241 | 80866719 | -240       | 7150     | 79176     | 30.12.2022 20:43 |
| 8207241 | 80866719 | -240       | 7150     | 79176     | 30.12.2022 20:43 |
| 8207243 | 80866755 | -270       |          | 62391     | 30.12.2022 20:44 |
| 8207243 | 80866755 | -270       |          | 62391     | 30.12.2022 20:44 |
| 8209179 | 80906869 | -250       |          | 54716     | 31.12.2022 07:52 |
| 8209179 | 80906869 | -250       |          | 54716     | 31.12.2022 07:52 |
| 8209671 | 80917061 | -290       | 7860     | 17133     | 31.12.2022 10:42 |
| 8209671 | 80917061 | -290       | 7860     | 17133     | 31.12.2022 10:42 |
| 8209698 | 80917712 | -250       | 1630     | 42073     | 31.12.2022 10:53 |
| 8209698 | 80917712 | -250       | 1630     | 42073     | 31.12.2022 10:53 |
| 8210014 | 80923833 | -240       |          | 57496     | 31.12.2022 12:36 |
| 8210014 | 80923833 | -240       |          | 57496     | 31.12.2022 12:36 |
| 8212303 | 80970688 | -280       |          | 22794     | 01.01.2023 01:37 |
| 8212303 | 80970688 | -280       |          | 22794     | 01.01.2023 01:37 |
| 8213703 | 80999503 | -260       |          | 16341     | 01.01.2023 09:36 |
| 8213703 | 80999503 | -260       |          | 16341     | 01.01.2023 09:36 |
| 8214251 | 81010738 | -270       |          | 2506      | 01.01.2023 12:43 |
| 8214251 | 81010738 | -270       |          | 2506      | 01.01.2023 12:43 |
| 8214329 | 81012429 | -220       |          | 69311     | 01.01.2023 13:12 |
| 8214329 | 81012429 | -220       |          | 69311     | 01.01.2023 13:12 |
| 8215150 | 81028694 | -230       | 8110     | 53521     | 01.01.2023 17:43 |
| 8215150 | 81028694 | -230       | 8110     | 53521     | 01.01.2023 17:43 |
| 8215152 | 81028726 | -280       | 14750    | 32800     | 01.01.2023 17:43 |
| 8215152 | 81028726 | -280       | 14750    | 32800     | 01.01.2023 17:43 |
| 8215706 | 81040703 | -280       | 13140    | 9590      | 01.01.2023 21:03 |
| 8215706 | 81040703 | -280       | 13140    | 9590      | 01.01.2023 21:03 |
| 8216096 | 81049448 | -220       | 140      | 88957     | 01.01.2023 23:29 |
| 8216096 | 81049448 | -220       | 140      | 88957     | 01.01.2023 23:29 |
| 8217625 | 81080788 | -280       |          | 42751     | 02.01.2023 08:11 |
| 8217625 | 81080788 | -280       |          | 42751     | 02.01.2023 08:11 |
| 8217918 | 81086866 | -240       | 14590    | 39956     | 02.01.2023 09:52 |
| 8218356 | 81095134 | -270       |          | 49949     | 02.01.2023 12:10 |
| 8218958 | 81107130 | -200       | 130      | 84156     | 02.01.2023 15:30 |
| 8219009 | 81108007 | -210       | 140      | 77779     | 02.01.2023 15:45 |
| 8220558 | 81139420 | -260       |          | 45799     | 03.01.2023 00:28 |
| 8221597 | 81160363 | -290       |          | 16612     | 03.01.2023 06:17 |
| 8222314 | 81174155 | -270       | 21740    | 13932     | 03.01.2023 10:07 |
| 8223142 | 81190599 | -290       | 3700     | 2566      | 03.01.2023 14:41 |
| 8224299 | 81215584 | -240       |          | 36324     | 03.01.2023 21:38 |
| 8224309 | 81215803 | -270       |          | 64004     | 03.01.2023 21:42 |
| 8224446 | 81218713 | -250       |          | 3511      | 03.01.2023 22:30 |
| 8224835 | 81226921 | -230       |          | 77188     | 04.01.2023 00:46 |
| 8225568 | 81241902 | -260       |          | 66463     | 04.01.2023 04:57 |
| 8226068 | 81252133 | -280       |          | 40246     | 04.01.2023 07:48 |
| 8226716 | 81265022 | -270       |          | 47830     | 04.01.2023 11:21 |
| 8227721 | 81285145 | -70        | 80       | 71270     | 04.01.2023 16:57 |
| 8228410 | 81298597 | -250       | 230      | 88207     | 04.01.2023 20:41 |
| 8228498 | 81300819 | -250       |          | 28146     | 04.01.2023 21:19 |
| 8229218 | 81315557 | -240       |          | 80008     | 05.01.2023 01:24 |
| 8229841 | 81328274 | -300       | 13680    | 10933     | 05.01.2023 04:56 |
| 8231318 | 81357144 | -310       | 410      | 2926      | 05.01.2023 12:57 |
| 8231632 | 81363896 | -270       |          | 47121     | 05.01.2023 14:50 |
| 8233907 | 81410965 | -290       | 960      | 34255     | 06.01.2023 03:54 |
| 8234903 | 81430446 | -300       | 31880    | 35591     | 06.01.2023 09:19 |
| 8235110 | 81434403 | -290       |          | 8443      | 06.01.2023 10:25 |
| 8235385 | 81440120 | -240       |          | 89441     | 06.01.2023 12:00 |
| 8235676 | 81445735 | -260       |          | 54659     | 06.01.2023 13:34 |
| 8236105 | 81455289 | -280       |          | 3534      | 06.01.2023 16:13 |
| 8236210 | 81457738 | -160       |          | 86718     | 06.01.2023 16:54 |
| 8237465 | 81482975 | -220       | 9630     | 77700     | 06.01.2023 23:54 |
| 8238094 | 81495463 | -270       |          | 38572     | 07.01.2023 03:23 |
| 8238133 | 81496460 | -250       |          | 65769     | 07.01.2023 03:39 |
| 8238422 | 81502159 | -330       |          | 3441      | 07.01.2023 05:16 |
| 8238443 | 81502652 | -10        | 10       | 10274     | 07.01.2023 05:22 |
| 8238549 | 81505340 | -280       |          | 16270     | 07.01.2023 06:07 |
| 8238572 | 81505759 | -280       |          | 3779      | 07.01.2023 06:14 |
| 8239233 | 81519978 | -290       | 25610    | 871       | 07.01.2023 10:11 |
| 8239678 | 81529416 | -310       |          | 2527      | 07.01.2023 12:48 |
| 8240054 | 81537543 | -260       |          | 28512     | 07.01.2023 15:04 |
| 8240233 | 81541239 | -280       | 480      | 29595     | 07.01.2023 16:05 |
| 8240614 | 81549094 | -300       |          | 26625     | 07.01.2023 18:16 |
| 8241584 | 81569298 | -260       |          | 36122     | 07.01.2023 23:53 |
| 8241624 | 81570277 | -300       |          | 871       | 08.01.2023 00:11 |
| 8243651 | 81611651 | -240       |          | 24897     | 08.01.2023 11:40 |
| 8244575 | 81630859 | -170       |          | 87321     | 08.01.2023 16:59 |
| 8245741 | 81655815 | -250       | 4670     | 47936     | 08.01.2023 23:55 |
| 8245797 | 81657056 | -170       | 110      | 82198     | 09.01.2023 00:15 |
| 8245906 | 81659161 | -260       | 29460    | 72585     | 09.01.2023 00:51 |
| 8247172 | 81685299 | -260       |          | 20501     | 09.01.2023 08:06 |
| 8248085 | 81704376 | -280       |          | 12258     | 09.01.2023 13:24 |
| 8248336 | 81709549 | -230       |          | 30069     | 09.01.2023 14:50 |
| 8249369 | 81730764 | -250       |          | 61209     | 09.01.2023 20:44 |
| 8249410 | 81731520 | -260       |          | 69273     | 09.01.2023 20:56 |
| 8249639 | 81735901 | -240       |          | 3161      | 09.01.2023 22:10 |
| 8249951 | 81742707 | -210       |          | 87546     | 10.01.2023 00:03 |
| 8250119 | 81746776 | -280       |          | 16820     | 10.01.2023 01:11 |
| 8251805 | 81781697 | -300       | 27610    | 2485      | 10.01.2023 10:53 |
| 8252218 | 81790405 | -270       | 1510     | 17764     | 10.01.2023 13:18 |
| 8252236 | 81790896 | -260       | 16690    | 53654     | 10.01.2023 13:26 |```

At Slot 92045428 (9-May 06:55:19am GMT) we had a block that was announced, broadcasted and adopted too early. (around half a second before the actual slot time)
After this block, there was an 8 minutes lasting break of no new blocks and it seems as it is related to this issue here.

I again lost a block due to this issue at the time today.
My BP completed BlockFetch of the correct parent block of an unnamed pool my block should have been build upon on time, however with a negative delay, a block from the future:
{"app":[],"at":"2023-05-09T05:55:18.61Z","data":{"block":"bae1e9d042b11a86503108739a6ec054566355d520e871f44639a82732a5207f","delay":-0.392551713,"kind":"CompletedBlockFetch","peer"
My 1.35.7 BP did then not apply this block to the currentTip until 4 minutes later colliding with itself, first my BP minted my block on the old, wrong parent
{"app":[],"at":"2023-05-09T05:59:39.02Z","data":{"credentials":"Cardano","val":{"kind":"TraceNodeIsLeader","slot":92045688}},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"860","sev":"Info","thread":"377"} {"app":[],"at":"2023-05-09T05:59:39.06Z","data":{"credentials":"Cardano","val":{"block":"10c3f7e59bbcd99dbde73c6ed53d03a30bbbdf81ba056d1ec6be4c18185be56d","blockNo":8749998,"blockPrev":"d98f58ed260269164ed7cdde61cd7302597803a308dfa5b6afefaa1d802e7b54","kind":"TraceForgedBlock","slot":92045688}},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"860","sev":"Info","thread":"377"}
At the exact same UTC time my BP decided to finally add the future block of the unnamed pool to the tip, not once but twice for good measure
{"app":[],"at":"2023-05-09T05:59:39.06Z","data":{"chainLengthDelta":1,"kind":"TraceAddBlockEvent.AddedToCurrentChain","newtip":"bae1e9d042b11a86503108739a6ec054566355d520e871f44639a82732a5207f@92045428"},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.ChainDB"],"pid":"860","sev":"Notice","thread":"367"} {"app":[],"at":"2023-05-09T05:59:39.06Z","data":{"kind":"LogValue","name":"before next, messages elided","value":{"contents":825390879782320,"tag":"PureI"}},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.ChainDB"],"pid":"860","sev":"Notice","thread":"367"} {"app":[],"at":"2023-05-09T05:59:39.06Z","data":{"chainLengthDelta":1,"kind":"TraceAddBlockEvent.AddedToCurrentChain","newtip":"bae1e9d042b11a86503108739a6ec054566355d520e871f44639a82732a5207f@92045428"},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.ChainDB"],"pid":"860","sev":"Notice","thread":"367"}
Now the BP had created a fork on it's own and tried to decide which fork to take the one just created itself or the block from the future it added 4 minutes too late to its ledger db?
{"app":[],"at":"2023-05-09T05:59:39.06Z","data":{"block":{"hash":"10c3f7e59bbcd99dbde73c6ed53d03a30bbbdf81ba056d1ec6be4c18185be56d","kind":"Point","slot":92045688},"kind":"TraceAddBlockEvent.TrySwitchToAFork"},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.ChainDB"],"pid":"860","sev":"Info","thread":"367"}
My BP then dropped its own block and the losing out block never made it to my relays
{"app":[],"at":"2023-05-09T05:59:39.10Z","data":{"credentials":"Cardano","val":{"kind":"TraceDidntAdoptBlock","slot":92045688}},"env":"1.35.7:f0b4a","host":"ub22cn","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"860","sev":"Error","thread":"377"}
The losing out new block of the BP was never picked up by my relays either, so no block explorer saw the issue. This is nicely visible in the monitoring, the BP (bright green) is one block ahead and it takes minutes for all nodes to align again

Happend again today, did not lose a block this time luckily but the chain halted for 6 minutes, see https://pooltool.io/realtime/9861109
Log from one of my relays:
"app":[],"at":"2024-01-28T11:58:32.77Z","data":{"block":"3c7be56c81d2949ce7e13e2f0eb6abbe7dd9c89ebef53316a27ac57f236b097b","delay":-0.231176125,"kind":"CompletedBlockFetch","peer":{"local":{"addr":","port":""},"remote":{"addr":"<IP_ADDRESS>","port":"3001"}},"size":1788},"env":"8.7.3:30b6e","host":"ub22r2","loc":null,"msg":"","ns":["cardano.node.BlockFetchClient"],"pid":"3115980","sev":"Info","thread":"968062"}

Unfortunately i was one of the pools that lost a block because of this... Below is a copy of my logs incase they are useful
{"app":[],"at":"2024-01-28T12:03:23.03Z","data":{"credentials":"Cardano","val":{"kind":"TraceNodeNotLeader","slot":114877112}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"1547","sev":"Info",>
{"app":[],"at":"2024-01-28T12:03:24.00Z","data":{"chainDensity":4.7089357e-2,"credentials":"Cardano","delegMapSize":1333936,"kind":"TraceStartLeadershipCheck","slot":114877113,"utxoSize":10976816},"env":"8.1.2:d2d90","host":"producer","loc>
{"app":[],"at":"2024-01-28T12:03:24.11Z","data":{"credentials":"Cardano","val":{"kind":"TraceNodeIsLeader","slot":114877113}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"1547","sev":"Info",">
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"credentials":"Cardano","val":{"block":"0bb540b0b4da38badc11f98c78722c742cff125eb3b84363572977372839a272","blockNo":9861109,"blockPrev":"2a8b15efe9bd5b00d8d7391c6965ecff193ab96e8a143fecf8a80>
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"chainLengthDelta":1,"kind":"TraceAddBlockEvent.AddedToCurrentChain","newtip":"3c7be56c81d2949ce7e13e2f0eb6abbe7dd9c89ebef53316a27ac57f236b097b@114876822"},"env":"8.1.2:d2d90","host":"produc>
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"kind":"LogValue","name":"before next, messages elided","value":{"contents":343168217855463,"tag":"PureI"}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Chai>
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"chainLengthDelta":1,"kind":"TraceAddBlockEvent.AddedToCurrentChain","newtip":"3c7be56c81d2949ce7e13e2f0eb6abbe7dd9c89ebef53316a27ac57f236b097b@114876822"},"env":"8.1.2:d2d90","host":"produc>
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"block":{"hash":"0bb540b0b4da38badc11f98c78722c742cff125eb3b84363572977372839a272","kind":"Point","slot":114877113},"kind":"TraceAddBlockEvent.TrySwitchToAFork"},"env":"8.1.2:d2d90","host":">
{"app":[],"at":"2024-01-28T12:03:24.19Z","data":{"credentials":"Cardano","val":{"kind":"TraceDidntAdoptBlock","slot":114877113}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"1547","sev":"Erro>
{"app":[],"at":"2024-01-28T12:03:25.00Z","data":{"chainDensity":4.7114022e-2,"credentials":"Cardano","delegMapSize":1333936,"kind":"TraceStartLeadershipCheck","slot":114877114,"utxoSize":10976816},"env":"8.1.2:d2d90","host":"producer","loc>
{"app":[],"at":"2024-01-28T12:03:25.03Z","data":{"credentials":"Cardano","val":{"kind":"TraceNodeNotLeader","slot":114877114}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"1547","sev":"Info",>
{"app":[],"at":"2024-01-28T12:03:26.00Z","data":{"chainDensity":4.7114022e-2,"credentials":"Cardano","delegMapSize":1333936,"kind":"TraceStartLeadershipCheck","slot":114877115,"utxoSize":10976816},"env":"8.1.2:d2d90","host":"producer","loc>
{"app":[],"at":"2024-01-28T12:03:26.03Z","data":{"credentials":"Cardano","val":{"kind":"TraceNodeNotLeader","slot":114877115}},"env":"8.1.2:d2d90","host":"producer","loc":null,"msg":"","ns":["cardano.node.Forge"],"pid":"1547","sev":"Info",>

one of the pools that lost a block because of this

Here's what highly probably happened

Last block before the break period was slot 114876813 filled by RSTK
Then 9 slots but only 8.5 secs later we had another block 114876822 produced by SCAR and broadcasted ~ half a second too early.  (a "block from the future" case)
Then it took 6 minutes and 6 seconds until slot 114877188 when STAKE produced a new block, build on top of RSTK block

during these 6 minutes we probably had other slot leaders, all stuck to adopt SCAR's block and hence building their block on RSTK. So they ran into height battles with SCAR

To solve the height battle the hashes are compared, and apparently SCAR won multiple times. Against LEAD and may some other elected slot leaders, we don't know about.

So no new blocks until STAKE was lucky to win the height battle and catch out SCARs block, stuck in adoption on many nodes worldwide.

Another problem with using the block VRF to deterministically settle "fork battles" is that a malicious pool that is the next valid leader can deliberately choose to cause a fork by building upon the second last block if it knows it will win the VRF battle with the last block.  A group of such pools could work together to selectively knock out blocks produced by other pools that are not members of their malicious group.
I wonder if this attack method as well as the problem identified in this comment thread could be solved by three changes:

Change the slot leadership calculation so that only every (say) 4th slot is a possible valid slot.  IE: Add in 'mod 4' to the calculation and re-calibrate the parameters so that there is still, on average, 1 valid slot leader to produce a block every 20 seconds.
Change the chain selection algorithm so that the block VRF is only used to settle equal length forks when the terminal blocks have the exact same slot number (IE: true slot battles), otherwise the node should prefer it's current chain.
Reject blocks that arrive more than 4 seconds early.  (IE. Equal to the minimum amount of time between possible valid slots, as a consequence of change 1.)

Such changes would also fix another problem that disincentivises geographic decentralisation:  Stake pools run from more remote areas (relative to the majority in USA/EU) suffer increased network delays in sending and receiving blocks.  Such pools that experience just 1 second delays will suffer 3 times the number of "fork battles", and pools that experience 2 second delays will suffer 5 times the number of fork battles.  Since half of these battles will be lost this is a huge cost for the increased geographic decentralisation these pools provide.
IE: The majority pools in USA/EU with less than 1 second delays will only lose around 2.5% of their blocks.  But, pools with 1 second delays will lose around 7.5% of their blocks, and pools with 2 second delays will lose around 12.5% of their blocks.  Such numbers create a massive incentive for operators to centrally re-house their pool in a USA/EU data centre owned by Amazon.
The above changes would give each block 4 seconds to propagate across the network.  Therefore pools with 1, 2, or even 3 seconds of delays wouldn't be penalised for their decentralisation.

Sorry for the long delay here; this bug has now been fixed for a while (since node 8.8); but only since Conway we can be sure that all block producers have actually updated to a version containing the fix.
See https://updates.cardano.intersectmbo.org/2024-09-07-incident/ (in particular the linked reports) for all of the details.

@TerminadaPool keep us posted if you notice better block production from your node / area.


Quality of Life Improvements

Added another few quality of life improvements:

Added generalized solution for key events on JTextField and JTextArea.
Implemented ctrl + enter apply in the tag manager as well.
The last opened dataset is attempted to be opened on start.
Made the search progressbar optional using a JToggleButton.
3 and 4 use Preferences to store settings.

I did some work in the meantime to address #17 which involved refactoring how datasets are opened and closed, and a few other cleanups that should make things slightly easier to work with. Apologies for the merge conflicts!

The comments are all processed; it should be all good now. I proceeded to add a settings panel in which you can select whether you want to auto-open the last data set.
I realized there was a bug in the tag panel as well (if you didn't have an email selected whilst adding/updating a tag, it'd throw a NullReferenceException).


Failed to getValue() with method com.codepine.api.testrail.model.Result#getCustomFields(0 params): null (through reference chain: com.codepine.api.testrail.model.Result["[anySetter]"])

I've been banging my head on this for about a week straight now and can't figure out why this is happening.
I'm using the latest stable version of the testrail-api-java (1.0.1) in a mavenized java 1.8 project with the latest Selenium and TestNG.
I'm attempting to update a test run with the results of a test using the following code:
List<ResultField> customResultField = testRail.resultFields().list().execute();
testRail.results().addForCase(testRun.getId(), testId, new Result().setStatusId(testStatus), customResultField).execute();

The update was failing with a RuntimeException:
com.fasterxml.jackson.databind.JsonMappingException: Failed to getValue() with method com.codepine.api.testrail.model.Result#getCustomFields(0 params): null (through reference chain: com.codepine.api.testrail.model.Result["[anySetter]"])

My java knowledge is prob novice at best as I'm self taught so I apologize if this is obvious and not an actual issue with this library.
Any help would be greatly appreciated as I've tried literally everything I can think of.
UPDATE: I updated my pom to refer to version 1.0.2 in case I was mistaken about which version was stable and the exception still occurs.
UPDATE: A java developer I know suggested adding Lombok to my classpath, the exception still occurs regardless.

I am getting the same error. Any help would be appreciated.

So I think I figured out the problem:
The issue is with the Result.getCustomFields method, which is defined as
public Map<String, Object> getCustomFields() {
        return Objects.firstNonNull(customFields, Collections.<String, Object>emptyMap());
    }

I looked up Objects.firstNonNull and found that this was part of Guava. In the docs for Guava 20.0 (http://google.github.io/guava/releases/20.0/api/docs/com/google/common/base/Objects.html#firstNonNull-T-T-), I found this interesting tidbit:

@Deprecated
public static  T firstNonNull(@Nullable
T first,
@Nullable
T second)
Deprecated. Use MoreObjects.firstNonNull(T, T) instead. This method is scheduled for removal in Guava 21.0.

So, looking at my project's other dependencies, I found that one of them had upgraded to Guava 21.0, thus causing this issue. I forced Guava 20.0 by adding the dependency to my pom file, and I am not getting the issue anymore.
The testrail-api-java-client is currently on 16.0.1. It would be great if it was upgraded to a newer version and fixed to not use Objects.firstNonNull.

@kunal546 Would it be possible for you to update getCustomFields to  use MoreObjects.firstNonNull? Thank you.

Hi guys, could you please update to latest version in maven repository, please. This issue is really "show stopper" for me to use api-client. Because version in maven still depends on guava 16.0.1 but all Selenium Drivers already depends on guava 21. So, it is impossible to use the in api-client in projects with Selenium testing. If I can help in any way I would be pleased.

I am running into the exact same issue using appium (which in turn uses selenium), and do not have the option to force Guava < 21.0. @kunal546 please release an update. This library is currently incompatible with anything that uses guava 21.0 or higher.

@kunal546 same issue here :)

Sorry for the delay. v2.0.0 has been released which addresses this.


Higher privileges required on 10.12 for StartService

Hi.
It seems that in latest 10.12 higher privileges are required to run StartService.
SDMMD__CreateDataFromFileContents: Could not lstat.
SDMMD__CreateDictFromFileContents: Could not read from file.
SDMMD__CreateDataFromFileContents: Could not lstat.
SDMMD__CreateDictFromFileContents: Could not read from file.

Running with sudo works fine

does this mean we need to embed the entitlements.plist into the command line app?

Excuse me, the issue appears on the StartSession part.
I do not think this is an entitlement issue as I can see the issue on non sandboxed applications as well

Interesting, can you narrow down the specific file or accessor that is returning the error?

Yes, it seems access to /var/db/lockdown has been restricted
 drwx------    5 _usbmuxd         _usbmuxd             170 Aug 12 07:28 lockdown
Inside it looks same as in older versions of OS X
-rw-rw-rw-   1 root      _usbmuxd  9445 Aug 12 07:28 xxxxxxxxxxxxxxxxxxxxxxx.plist

Could anyone please tell me how to get safari cache...?
Thanks

I think I am going to close this as I don't see a practical way around this other than to require sudo. There should probably be a OS check added and tell the user to sudo, but I think that is a separate issue from this.


[GSSoC'23] Music Guess Game Ready

Title and Issue number

Title - Music Guessing Game
Issue Number - #2070
Close #2070

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

@Saurabh-kumar09 @pranjay-poddar @MohitGupta121 Sirs, Please review this pull request and requested to merge it under GSSoC'23 program for a successful contribution.

@TusharKesarwani Sir, Could you tell me how this project comes under Plagiarism. Is open source not a platform to learn or just made for applying plagiarism ?


[WIP] Convert adapter to javascript

Doesn't even function yet.  But everything has been rewrote to javascript.
I rewrote using some es6 stuff... but I think will have to either use babel or something to compile down.. or change some of the things so it'll run with nodejs 4.8.3 or even nodejs 6.x

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.3 out of 4 committers have signed the CLA.:white_check_mark: geekgonecrazy:white_check_mark: engelgabriel:white_check_mark: timkinnane:x: Tim KinnaneTim Kinnane seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


installation guide need to be described at Getting Started docs

Is your feature request related to a problem? Please describe.
currently, there is no installation guide in Getting Started.
It's tiny doc, but necessary to users who are not familiar with development or this library.
and, contributing guide need to move from Getting Started to Contributing.
Describe the solution you'd like
move contributing section from Getting Started to Contributing.
add installation guide at Getting Started.
Additional context
If maintainer allow, i will do this documentation!

Thanks for the issue. I think you'd want to consider providing installation guide for users and not contributors.
If I am understanding correctly, it would be great to contribute!

yes, i thinks Get Started section is for beginners. not contributors.
I will PR for documentation soon! 👏

@Einere
I think we have to remember dooboo-ui is universal supprted.
so installation guide need to include a various environment setup documents. (Although i think it is not needed yet...)
ex. for web user, cli quickstart, native cli setup... and so on..
I found reference site for share
https://docs.nativebase.io/installation
https://reactnativeelements.com/docs/web_usage
https://reactnative.dev/docs/environment-setup
And i have an experience to install dooboo-ui on various environment.
so i think i can help you for many problem on installation.

@Einere @luke-hanwook What a great discussion. Looking forward to your collaborations 🥇

@hyochan
I tried to resolve problem to install "dooboo-ui" on various environment but there are many unresolved problem.
I organized many problem things and i will share to him.
It's not awesome thing. but i think we will enhance every problem and i will try continuously 😺

@luke-hanwook
i commited docs/installation-guide to my dooboo-ui repo.
would you review or contribute at that repo? 👏


If setting up legacy IPP printer with "lpadmin -m everywhere" an invalid PPD file gets generated

I have some older IPP printers which are no IPP Everywhere printers and if I try to create queues for them with IPP-autogenerated PPDs via the "-m everywhere" option for the "lpadmin" command I get invalid PPD files which fail cupstestppd due to missing "PageSize"/"PageRegion"/"PaperDimension"/"ImageableArea" entries. Also there are no *cupsFilter(2) entries for a useful (PDF, PostScript, PWG Raster) page description language or no entries at all.
So there should be two checks:

Presence of "PageSize"/"PageRegion"/"PaperDimension"/"ImageableArea", the only required option in a PPD file
Presence of a *cupsFilter(2) line for PWG Raster, PDF, PostScript

Otherwise we would get a print queue which does not work.

First, is this with the latest (git master) code or with the last release?
Second, can you run:
ipptool -tv ipp://... get-printer-attributes.test

for these printers (substituting the correct device URI of course) and attach the output?
I'm all for updating the private API to error out when we can't generate a proper PPD, but I also want to make this work as reliably as possible.

I have tested on Ubuntu Yakkety (16.10), which has CUPS 2.2.0.
I have used the following two printers: HP Color LaserJet CM3530 MFP and HP OfficeJet Pro 8500 A910. The former is a color laser multi-function printer with PDF and PostScript, but only IPP 1.1. The latter is a color inkjet multi-function printer which can also print photos directly from a camera or SD card.
I have run "ippfind" to get the URIs of these two printers and created print queues with the following command:
lpadmin -p ippevtest -E -v  -m everywhere
for each printer. Both PPDs fail cupstestppd like this:
sudo cupstestppd /etc/cups/ppd/ippevtest.ppd
[sudo] password for till:
/etc/cups/ppd/ippevtest.ppd: FAIL
FAIL  REQUIRED DefaultImageableArea
REF: Page 102, section 5.15.
FAIL  REQUIRED DefaultPaperDimension
REF: Page 103, section 5.15.
FAIL  REQUIRED PageSize
REF: Pages 99-100, section 5.14.
FAIL  REQUIRED PageRegion
REF: Page 100, section 5.14.
FAIL  REQUIRED PageSize
REF: Page 41, section 5.
REF: Page 99, section 5.14.
FAIL  Missing REQUIRED PageSize option.
REF: Page 99, section 5.14.
FAIL  Missing REQUIRED PageRegion option.
REF: Page 100, section 5.14.
till@till-x1carbon:~/printing/cups/cups$
Meaning that in both cases the PPDs missing entries for the page sizes.
In addition, the PPD for the CM3530 has no *cupsFilter(2) line at all and the inkjet has lines for URF and JPEG, both not useful for printing jobs with CUPS.

Output of the command
ipptool -tv ipp://... get-printer-attributes.test
for both printers attached:
HP-Color-LaserJet-CM3530-MFP-ipp-attr.txt
HP-Officejet-Pro-8500-A910-ipp-attr.txt

OK, so the CM3530 does not actually support any of the standard PDLs, but we could (conceptually) generate a PPD that uses the sample PCL driver (thinking about that one...)
The OfficeJet should be fixed by the changes for Issue #4909 - please re-test with the current Git code and let me know if that doesn't resolve things for you...

OK, after some further thought I'm not going to support PCL with this function - that's what the sample PCL driver is for. This bug will track returning NULL and deleting any temporary PPD we create if the printer doesn't support enough IPP to work.

[master d4259b4] More IPP Everywhere fixes/improvements (Issue #4916)

I’m curious:
You write:
MS> the CM3530 does not actually support any of the standard PDLs
but the HP-Color-LaserJet-CM3530-MFP-ipp-attr.txt file Till posted says:
    printer-info (textWithoutLanguage) = MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,PCLXL,PCL,PDF,POSTSCRIPT;MDL:HP Color LaserJet CM3530 MFP;CLS:PRINTER;DES:Hewlett-Pack

so it claims that it supports PDF.

But document-format-supported does not list PDF as a supported document format over IPP... :/

Seems to be a firmware bug in the CM3530, probably because in the time when it was introduced one still did not see the necessity that printers should correctly report their capabilities in some standard format.

"MS" == Michael R Sweet<EMAIL_ADDRESS>writes:

MS> But document-format-supported does not list PDF as a supported
document format over IPP... :/
Ah.  I missed that.
-JimC
James Cloos<EMAIL_ADDRESS>       OpenPGP: 0x997A9F17ED7DAEA6


got error when store to database

plese help

I need more information to help you. What class is the code form? What is the line where the exception is thrown? etc. etc.

get error when I execute addToCart method

are you have example how to store it to database? @Crinsane


[orgmode] image directives

in ReST https://getnikola.com/quickstart.html image directives are taken
.. image:: /images/nikola.png
:height: 100
:width: 200
:scale: 50
:alt: alternate text
Would it be possible add something similar
;; Export images with custom link type
(defun org-custom-link-img-url-export (path desc format)
(cond
((eq format 'html)
(format "" path desc))))
(org-add-link-type "img-url" nil 'org-custom-link-img-url-export)
I can't seem to find any reference as to what the above defun is overriding.

Is there a definitive answer to this? This used to work on me (circa 2018), but in revisiting nikola, it's not any longer.
When I use the following:
#+attr_latex: :width 500
[[img-url:/path/to/image.png]]

I get this in the output page source:

Is this something in my setup that causes the width to be applied to
 instead of ? @frankieliu 's link above is down, so I'm not sure what the proposal was. If I ditch img-url: or try file:, width is not applied at all. Do I have to move to native export blocks and write the html by hand?

Bump. Just ran into this again. I could open a new issue, but it's identical...


Fix for joins on columns that are not a prefix to an index

As we now natively support partial indexes in GMS, we had a case where we'd match a single column to a partial index. We would then attempt to use the full index's column expressions which later failed as the columns were not a prefix to the index. Now we enforce that, when we start looking for single column matches, we only find indexes over a single column.
Also, the index builder assumed it would be used if it was created, and therefore could return an range of length 0, so that has been fixed as well. It should only be hit in erroneous cases like the preceding one, but this should prevent panics in other circumstances as well.

Fixes https://github.com/dolthub/dolt/issues/2366


Improve User Experience on the Hiero Website

I would like to contribute to improving the user experience (UX) of the Hiero website @hendrikebbers

That sounds great. Can you please describe your ideas in more detail?

@hendrikebbers sir sure i will give a detail like
1)changing and makes the styles inside the navbar links which is normal here

2)changing the other styles which is availabel here

3)adding social media links like instagram , X, youtube , facebook and pinterest links and footer section which is empty right now

Hi @hendrikebbers, @rahul-chakradhari, @ryjones, @samswag, @giftkugel,
I came across [Issue](https://github.com/hiero-ledger/hiero-website/issues/16) and would like to request permission to work on it. However, the issue currently lacks specific details, so I wanted to share some observations and suggestions after exploring the project website.
Observations:

The website still has a "Hacktoberfest" route: https://hiero.org/hacktoberfest/.
This route is not prominently linked or easily accessible from the main site.
Some issues listed on the "/hacktoberfest" page are still open and unassigned, even though Hacktoberfest has passed.

Suggestions:

Visibility: Add a link to the "Hacktoberfest" route on the main page or another prominent section to improve accessibility.
Route Name Update: Since Hacktoberfest has ended, consider renaming the route to something more generic (e.g., /community-projects or /open-issues) to keep it relevant year-round.
Issue Categorization: Perhaps create a new section on the website for ongoing or beginner-friendly issues to encourage more contributions outside of Hacktoberfest.

Let me know if these suggestions align with the project's goals. I’m happy to proceed with updating the route and improving visibility or any other tasks you think are necessary.
Looking forward to your feedback!
Best regards,
Ibrahim Bello


Fix(general)-Replace-sass-with-sass-embedded

Also enabled devSourcemap for css

Wrong destination branch


adding MOVE_MOUNT* constants for linux to use with SYS_move_mount

syscall.
close #3387

@bors r+

:pushpin: Commit 0cab9f4d7e980f872237584941180836182d24d1 has been approved by JohnTitor
It is now in the queue for this repository.

:hourglass: Testing commit 0cab9f4d7e980f872237584941180836182d24d1 with merge 77a5c7e160ccfb0b6a64ecd80522d5949fed1951...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 77a5c7e160ccfb0b6a64ecd80522d5949fed1951 to main...


Idea for object definition schemas

I think it would be useful to be able to retrieve the schema for a response (combined with the definitions so as to have a complete picture) and essentially have a simple JSON Schema for a response.  This would make it easier to then verify the API's JSON payload as well as other things.

Example of a simple JSON schema that theoretically could be obtained

{
  "type": "array",
  "items": {
    "$ref": "#/definitions/state"
  },

  "definitions": {
    "state": {
      "properties": {
        "id": {
          "type": "integer"
        },
        "code": {
          "type": "string"
        },
        "abbreviation": {
          "type": "string"
        },
        "name": {
          "type": "string"
        }
      },
      "required": [
        "id",
        "code",
        "abbreviation",
        "name"
      ]
    }
  }
}

At a minimum, it'd be nice if there were convenience methods to make it easier to retrieve the schema from the Swagger object.  The following are two ways that it can be done currently which makes the code a bit wordy and also doesn't supply the most useful object - a Property:
// Unfortunately have to know that it's a getGet or do a little more finagling (example 2)
- Example 1
swaggerDeserializationResult.getSwagger().getPaths().get("/states").getGet().getResponses().getOrDefault("200", null).getSchema()

- Example 2
    String currentUri = ((HttpServletRequest)req).getRequestURI();
    HttpMethod currentMethod = HttpMethod.valueOf(((HttpServletRequest)req).getMethod());
    Path currentPath = swagger.getPath(currentUri);
    if(currentPath != null) {
    	Operation currentOperation = currentPath.getOperationMap().get(currentMethod);
    	currentOperation.toString();
    }

Note: this isn't a condemnation of the code as it could mean that I'm not using it in the intended manner.  If there's an alternative/better way to using/retrieving the schema, let me know.  Or a better way to achieve the result mentioned at the beginning.
@fehguy Thoughts?  Thanks in advance.

This is expensive to do, which is why it hasn't been put in the parser logic.  There is an implementation here:
https://github.com/swagger-api/swagger-inflector/blob/68aa5d397331b69d691802c6fbf5a6c8fe5fd474/src/main/java/io/swagger/inflector/utils/ResolverUtil.java#L23


GST-12

Alligned table and the the tickbox with heading.
Pagination only displayed if there are multiple pages
Fixed the sorting table bug
Changed the table header font size

:+1:


pidfile --> pidFile

as mentioned in #241, the cli help and initd example are currently using pidfile instead of pidFile, breaking the option of specifying a custom pid file.

81c695ead4eb06e9e24212202d6bf475bec775b4

please consider also correcting the output of the cli help ( lib/forever/cli.js Line 48 )

on it
On Wed, Feb 29, 2012 at 11:11 AM, ruxkor
<EMAIL_ADDRESS>wrote:

please consider also correcting the output of the cli help ( lib/forever/cli.js Line 48 )

Reply to this email directly or view it on GitHub:
https://github.com/nodejitsu/forever/pull/242#issuecomment-4241962


Adding the spreadsheet operator as part of the json macro

In some cases it could be useful to have the spread operator available in the json macro. E.g.
let x = my_struct {
    a: 10,
    b: 15,
    c: "foo"
}

let json_return = json!(
    "type": "my_struct",
    ...my_struct
)

Doesn't make anything impossible possible but just makes things more convenient in some ways

I would prefer not to support this in this crate. But there may be other libraries providing more fully-featured json construction macros.


Extensions removed from Chrome store

These extensions have been removed from the Chrome store:

Multi-Highlight
Data Saver
😢

:( thanks for flagging


distinct perf updates

First commit

BREAKING CHANGE: changes distinct to use a keySelector and NOT a comparer. Comparer check was to mimic RxJS 2 or 3, which was the current version when this operator was originally created.
BREAKING CHANGE: removes distinctKey as it's redundant.
Adds the minimum necessary Set implementation if Set does not exist globally.
Improves overall perf of distinct() by 5x in first commit.
Improves overall perf of distinct(keySelector) (versus older distinctKey) by 8x in first commit

Additional commit (do not flatten)

Refactors error handling for V8 optimization. Moves deopt only to a path that is hit if a keySelector is actually provided. This further improves perf of distinct() by another 2x (total of 9-10x), and distinct(keySelector) slightly (total of 9x)

Note
comparer function argument exists in Rx4, yes, but after discussion with @mattpodwysocki, we are removing it because it is of little use, and most use cases could be solved by the keySelector. We can add it at a later time if we choose with minimal breakage.

Coverage increased (+0.003%) to 97.043% when pulling 90f478a03f09f2d96552bbe20c2f2052ef3588f2 on blesh:distinct-perf into 5460e7773d18f3e8c61ec09498121d837be3c2f5 on ReactiveX:master.

Coverage increased (+0.003%) to 97.043% when pulling 90f478a03f09f2d96552bbe20c2f2052ef3588f2 on blesh:distinct-perf into 5460e7773d18f3e8c61ec09498121d837be3c2f5 on ReactiveX:master.

commit message:

BREAKING CHANGE: distinct no signature changed, first argument is
keySelector, not comparer function.

I think the "no" was accidental. I think something like this is more clear:

BREAKING CHANGE: distinct operator has changed, first argument is
an optional keySelector and a compare function is no longer supported

Just curiosity - does micro perf test number shows expected gain? (I know micro perf hasn't run quite long time though..)

Just curiosity - does micro perf test number shows expected gain? (I know micro perf hasn't run quite long time though..)

Yes... ~9-10x faster in micro perf test that previous.

I think the "no" was accidental. I think something like this is more clear

yup, good catch

Coverage increased (+0.003%) to 97.043% when pulling df40ca592f101399977544d5b0d4e6b331b44375 on blesh:distinct-perf into 5460e7773d18f3e8c61ec09498121d837be3c2f5 on ReactiveX:master.

Coverage increased (+0.003%) to 97.043% when pulling<PHONE_NUMBER>57022ee9711b4b4f8b18eb9b65d0b9 on blesh:distinct-perf into 8ebee66e00156b3bc933370518526a2ecaa4f6c9 on ReactiveX:master.

@blesh is going to update the jsdocs, then we'll merge.

Coverage increased (+0.003%) to 97.219% when pulling 11894d0177b87cd66247b6c75908ebe51c500ce6 on blesh:distinct-perf into fee7585b4d2ed786065a40e580b862bfd9211281 on ReactiveX:master.

Coverage remained the same at 97.217% when pulling 4f11da265a997950053296063c2c52b2da0d1af9 on blesh:distinct-perf into d13dbb4560fa1803f89bd731e0302447cf9f29c8 on ReactiveX:master.

LGTM


XN Tracking: xn in Simulator

Related information
Owner - Nvidia. Scope - BMv2. Requires support for PNA table properties and externs such as idle_timeout_with_auto_delete, add_on_miss, default_action and add_entry, set_entry_expire_time. It will allow for automatic learning and expiring entries.

Aligning w/PNA

Still items to be finished, but Marian to push to Compiler, etc...

Still in progress, need to sync w/Chris for a customer docker for a compiler to upload into Marian's version of the compiler.

@chrispsommers @marian-pritsak Any updates on this issue, still on track?

Need to work on this, the way we build dockers is changed.  Marian can update his PR for docker build based on checksum.  The PR is out of date, needs to be updated.  Check back next week.

to be handled by Flow APIs and Dataplane App to provide xn tracking functionality - no longer needed.  K to close


Cache Optimization

We have a variety of opportunities to optimize our caches:

Do not clear caches via cache.delete instead, just override cache keys. This way, the user doesn't need to experience a long wait time. Caches will just  be replaced when ready. This works well except for situations where the user needs real time updates.
Rather than clearing all caches on each upvote/downvote, only clear trending and top caches

Note: To get the latest vote score, we merge fresh data with cache data

Avoid invalidating homepage caches. Instead, do so regularly via cron job that runs every 15 mins
Caching of hub feeds via preload_hub_documents does not work well at the moment. The cache keys are not consistent with other locations that add documents to cache

https://github.com/ResearchHub/researchhub-backend/pull/1013


hello function returns 'null'

Please post usage questions or broader discussions in the Forum.

For feature requests, please fill in the next sections:
What feature are you missing?
How could this feature look like in detail? Tradeoffs?

For bug reports, please fill in the next sections:
Current behavior
When requested the 'hello(name)' function returns null
Reproduction
Request:
query {
hello(name:"TEST") {
message
}
}
Result:
{
"data": {
"hello": null
}
}

If your problem can be reproduced with a certain service definition, please create a new GitHub repository with the reproduction instructions.

Expected behavior?
Should result in:
{
"data": {
"hello": {message: "Hello TEST"}
}
}

Hey @rollinball, I just did the following with<EMAIL_ADDRESS>and could not reproduce the problem:
graphcool init
graphcool deploy

This hello query works as expected:
query {
  hello {
    message
  }
}

{
  "data": {
    "hello": {
      "message": "Hello World"
    }
  }
}

Can you please include more information that helps reproduce this? Can you paste the output of graphcool version, too?

hi Mark
thanks for the reply.
well if i do just what you did:
graphcool init test
cd test
graphcool deploy
Then on playground i do
query {
hello {
message
}
}
I hit play
and I get
{
"data": {
"hello": null
}
}
graphcool version
graphcool/0.7.0 (windows-x64) node-v6.11.4
I'm on Win 10.

Hey there, I'm pretty sure you were running into this: https://github.com/graphcool/graphcool/issues/896
Can you confirm?
By the way, I'm Nilan, not Mark 😄

Hi Nilan,
Sorry about that, I myself do return null sometimes, those new technologies are very disturbing.
it seems to be related, tho I didn't change anything.
here is my log:
{"event":"{\"data\":{\"name\":\"test\"},\"context\":{\"request\":{\"sourceIp\":\"<IP_ADDRESS>\",\"headers\":{},\"httpMethod\":\"post\"},\"auth\":null,\"sessionCache\":{},\"environment\":{},\"graphcool\":{\"rootToken\":\"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDgzOTUzNTUsImlhdCI6MTUwODM5NTA1NSwiY2xpZW50SWQiOiJfIiwicHJvamVjdElkIjoiY2o4d3NiMno1MGg1eDAxNDFlbjFudmY5byIsInBlcm1hbmVudEF1dGhUb2tlbklkIjoiY2o4eTNneHRtNzFwdjAxMjIwdDZ6YzJoYSJ9._2N-WMOPNi048OT3v7LNFZUDmKi-ynUe7YLqHQcZi48\",\"endpoints\":{\"simple\":\"https://api.graph.cool/simple/v1/cj8wsb2z50h5x0141en1nvf9o\",\"relay\":\"https://api.graph.cool/relay/v1/cj8wsb2z50h5x0141en1nvf9o\",\"system\":\"https://api.graph.cool/system\",\"subscriptions\":\"wss://subscriptions.graph.cool/v1/cj8wsb2z50h5x0141en1nvf9o\"},\"projectId\":\"cj8wsb2z50h5x0141en1nvf9o\",\"alias\":null,\"pat\":\"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MDgzOTUzNTUsImlhdCI6MTUwODM5NTA1NSwiY2xpZW50SWQiOiJfIiwicHJvamVjdElkIjoiY2o4d3NiMno1MGg1eDAxNDFlbjFudmY5byIsInBlcm1hbmVudEF1dGhUb2tlbklkIjoiY2o4eTNneHRtNzFwdjAxMjIwdDZ6YzJoYSJ9._2N-WMOPNi048OT3v7LNFZUDmKi-ynUe7YLqHQcZi48\",\"serviceId\":\"cj8wsb2z50h5x0141en1nvf9o\"}}}","logs":["START RequestId: fe4538c0-b497-11e7-8d81-95426181e9ac Version: $LATEST\nUnable to import module 'src\\hello-lambda': Error\n    at Function.Module._resolveFilename (module.js:469:15)\n    at Function.Module._load (module.js:417:25)\n    at Module.require (module.js:497:17)\n    at require (internal/module.js:20:19)\nEND RequestId: fe4538c0-b497-11e7-8d81-95426181e9ac\nREPORT RequestId: fe4538c0-b497-11e7-8d81-95426181e9ac\tDuration: 36.41 ms\tBilled Duration: 100 ms \tMemory Size: 512 MB\tMax Memory Used: 20 MB\t\n"],"returnValue":{"errorMessage":"Cannot find module '/var/task/src\\hello-lambda'","errorType":"Error","stackTrace":["Function.Module._load (module.js:417:25)","Module.require (module.js:497:17)","require (internal/module.js:20:19)"]}}

Bumping this up! I'm getting the same issue :)

I can confirm that the deploy is still not working on Windows with the error from https://github.com/graphcool/graphcool/issues/885#issuecomment-337814173.

Can we update the title to 'Deploy not working on Windows' and add a 'breaking' label?

'Deploy not working on Windows'

We identified a couple of issues  (see https://github.com/graphcool/graphcool/labels/theme%2Fcli-windows and more that are not documented yet) and will add windows support soon. It will probably be released sometime leading up to version 0.10.

and add a 'breaking' label?

Side question, why is this breaking?

Side question, why is this breaking?
Because deploy on Windows is no longer possible in the released Framework Preview version? That was fine when it was still alpha, but the new function deployment is released as @next.

The breaking label signifies that adding the feature or fixing the bug is a breaking change.
The 'breaking' label does not signify a 'regression' or the introduction of new bugs.
This issue is not a breaking change, it's a feature request that can be added additively. We'll add explicit support for Windows soon, as mentioned above. 🙂

Okay, so I was wrong about the breaking label, but the fact that Windows deployment stopped working from @next 0.7.0 to @next 0.8.0 is still a valid argument I think.
Especially because downgrading to 0.7.0. doesn't help, as the change is on the server-side.

Hope this can be fixed really soon! It's put me at a stand still for doing anything function related via the cli :)

@marktani any way this can be bumped up to 0.9?

Update, as Windows deployment is still not working. Developers that use Windows 10 can take advantage of a feature called 'Windows Subsystem for Linux'. It basically runs a native Linux bash shell, with your Windows filesystem mounted. So you can easily use that shell to deploy.

This is now released in 0.9.1: https://github.com/graphcool/framework/releases/tag/0.9.1 🙂


Fix ECS field region_iso_code

This commit changes the ECS field from geo.region_code to geo.region_iso_code
Before this change, <IP_ADDRESS> gives region_code: VA
The source of region_code is Maxmind iso_code. region_code is not a ECS field but region_iso_code is.
In ECS example the value ofregion_iso_code is CA-QC, which seems to be a combination of country iso code and region iso code. So, the current region_code is not the same as ECS schema region_iso_code.
Questions:

Can we change geo.region_code to geo.region_iso_code or keep it as is?

Fixed: #195

need to combine country iso code and region iso code instead of renaming the field