Big problems in moving from v6 to v8 and back with "ReplaceToBiomeName:" option

OTG Plugin or Mod

[x] OTG Mod for Forge
[ ] OTG Plugin for Spigot

OTG Version

[x] 1.12.2_v8_r1
[ ] 1.12.2_v7_DEV_r26
[ ] 1.12.2-v6
[ ] 1.12.2-v5
[ ] 1.11.2-v8
[ ] 1.11.2-v9
[ ] 1.10.2-v21
[ ] Other - specify here

Forge or Spigot Versions
forge-1.12.2-<IP_ADDRESS>47
Description
I wanted  to test my finished with v6 preset with v8 before posting (god bless the backups!...), and noticed some strange issues with grass and leaves colors.So those colors became vanilla ones(I guess) in virtual biomes and remade vanilla biomes.I checked those virtual biomes,checked remade vanilla ones,compared them with backups.All was absolutely identical.But colors were from OTG vanilla, not from my remade vanilla biomes!
Screenshots:
Roofed Forest Border (virtual, replaced to Roofed Forest remade)in v6:

Roofed Forest Border (virtual, replaced to Roofed Forest remade) in v8:

Plains (vanilla remade) v6:

Plains (vanilla remade)v8 (trees are a bit different, first screenshot was old, but colors were not touched):

Then I changed OTG version back to v6, and after restart I got plenty of errors about biomes with ids>255.It was strange.Checking .bc files shows:
All vanilla biomes names from "ReplaceToBiomeName:"  were removed! My custom biomes with ids<255 names in this line were not touched.

I made new folder,reinstalled mods and my preset, and everything changed.ReplaceToBiomeName now contains something like "minecraft:mesa_clear_rock" for example, for not virtual Mesa Plateau biome. Colors of course changed to vanilla.I removed that line, removed "region", reloaded-this line appears again and colors are still vanilla.

Well, it stopped rewriting my configs,but nothing changed,colors are still vanilla.

And I also found, that everything works fine with an empty line in ReplaceToBiomeName in a virtual biome.It doesn't crash or say something about it the log...

I'm not really clear as to what the issue is, all of my presets seem to be ok when tested with v8

I had the same problem. I loaded up my preset in v8 to test, then when i changed back to v6 with the same preset ALL the ReplaceToBiomeName entries were blank.

MCPitman,
Did you have any changed colors(leaves and grass with multiplier:false) in vanilla biomes in your presets?If not, you may simply not run into this problem...
So, I see a few problems now:
1.Vanilla biomes don't accept any color changes(with temp/humidity multiplier:false);all colors remain default;
2.Virtual biomes, replacedtobiomename with vanilla ones,also stay with default colors;
3.Blank fields instead of vanilla names in the ReplaceToBiomeName field after going back to OTG v6.Custom biomes names were not affected(in my case).
I guess it may be somehow connected to the v8 added ability of using modded biomes in the  ReplaceToBiomeName field.OTG changes "biome name"(like Plains) to "biome registry name"(minecraft: plains)after restart.If these registry names adress to Minecraft biomes colors etc. instead of user-changed OTG ones, it may be the reason...It is just my guess-work,I don't know what happens inside OTG code))

AdaraChristine,
Were your blank entries vanilla biomes names or your custom biomes names?For me custom names were not affected...

Why would you use vanilla biomes if you're going to change their biome colours instead of a custom one? Can't you just copy the biomes and make them custom to fix this?
Worlds with v8 replacetobiomename syntax are not compatible with v6 that is normal.

Hey guys, thanks for responding to this.

Updating v6 configs to v8 should work fine, but v6 may not be able to handle updated configs. You can prevent configs being updated using SettingsMode:WriteDisable.
For mod compatibility, OTG no longer replaces any vanilla biomes in the registry for v8. If you want to use custom colors, you'll have to turn your biomes into custom biomes.

MCPitman,
v8 sintax is not compatible with v6-yes,it is logical,ok)
I thought about this "elegant" solution of the issue with colors already.It's not good at all.Well,I use vanilla biomes mostly to save free ids.Why not?Colors can be changed,nothing forbids it ( in v6).Simple calculations:there are at about 60 vanilla biomes.I have to make 60 more custom copies: free ids= (255-60)-60.And...I already have only 49 ids free now, when I'm using vanilla to save at least some ids free! I'm a bit worried even now about compatibility with other mods in modpacks in that case,to few free ids...Why would i use so many non-virtual biomes?Mostly because of different colors,sometimes to make some significant biomes to have their own biome tags,climate and to use them for teleportation with NatureCompass.
Well,I see.It is the way OTG v8 functions now...It is a bit sad.

Hey @Darsenia , sorry we had to sacrifice colors for vanilla biomes, OTG works a lot better with other mods now though :).


[new linter] Add mix linter for elixir

This deals with #340 by adding a mix linter for elixir to get syntax errors. Used @evnu 's example in that issue, but using mix instead of elixirc so that dependencies won't crash the linter.

Does the mix command place the resulting .beam file into _build? If so, that might surprise users when running an interactive shell in parallel. Maybe :build_path can be overriden.
(thanks for picking up that linter! :))

is there a way to configure that?

I spent some time a while ago to find such an option, but did not find any. It seems that the current Elixir master contains an environment variable to configure the output directory (MIX_BUILD_PATH, see), but this environment variable is not part of the current Elixir version v1.6.5 (see).  I guess that it will be possible in the future to override the build path with this convenient environment variable, but for now this does not work. I tried to override the build path with the following script override.exs within a Mix project, but it I could not make it work either. It seems very brittle to even attempt this. For future reference, this is what I tried:
#!/usr/bin/env elixir

:ok = Mix.start()

# Ensure that everything we might need is loaded
Mix.CLI.main()

# Ensure that we are within a mix project
Mix.Project.get!()
config = Mix.Project.config()

updated_config =
  Keyword.merge(
    config,
    build_path: "/tmp/foo/_bar"
  )

# FIXME The args should refer to the file being compiled.
args = []

# FIXME This path might need to be adapted
path = "."

# We need to pop the previously loaded project to allow reloading it
Mix.Project.pop()
Mix.Project.in_project(updated_config[:app], path, updated_config, fn module ->
  Mix.Project.compile(args)
end)

Note that the :build_path option is intended to be used for child apps of an umbrella and possibly does not work correctly in other cases.

Maybe. It would be good to check against Elixir's master Branche (e.g. build it woth kex).

Cool  made those changes, also found out about the ale#path#CdString for properly changing directories while i was at it. Sorry about the errors this is my first vimscript PR, i'm a bit of a noob, but Vader is really neat!

So i got testing the temp file working but now i can't figure out how to test the CdString portion of this in conjunction with FindNearestFile I made a dummy mix project but for some reason the command is not picking it up. This is what i'm doing in my before section
  " ./mix_paths/wrapped_project is the dummy project.
  call ale#test#SetFilename(ale#path#Simplify(g:dir .  '/mix_paths/wrapped_project/lib/main.ex'))

  let g:project_root = ale#path#Simplify(g:dir . '/mix_paths/wrapped_project')

Then when I am testing my command i am doing this:
  AssertEqual
  \ GetCommand(),
  \ ale#path#CdString(g:project_root)
  \ . g:env_prefix
  \ . 'mix compile %s'

but for some reason the linter won't pick up the project file using FindNearestFile when running the test. Might be doing something wrong.

Cheers! :beers:

Oh thanks so much!

Sorry noob here, how can I test this?

Talk to @colbydehart and install mix on your system.


Jonescobedo/tripviewer

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: jonescobedo sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Cam Support

+1 i've seen other examples where this is already supported, but I do not know what it requires other than the custom firmware from wyze

hi @LeonCaesa and @seecoolguy i have no idea how we could do video streaming in this plugin. have you tried the homebridge-camera-ffmpeg plugin? there are articles in medium and everything talking about how to integrate it with wyze cams and homebridge. it requires the RTSP firmware to work. give it a try and let us know.
let's say we can't do the video portion. is there any feature you see beneficial to justify it as an accessory?

hi @pjotal yeah I just added the RTSP beta firmware and this does allow me to configure the camera and I am able to stream on VLC but I don't have the right configuration to stream to HomeKit :-/

try this: https://medium.com/dirigible/wyze-cam-homekit-58c4878c4124
i did and it worked. on my hardware the performance was not great so i decided to revert to the production firmware.
implementing the video portion is not simple and it’s not in our plans. we would love to have someone contributing with this feature though. if you’re a developer, feel free to send a pull request and i am pretty sure @misenhower will like integrating it.
if you see there is something else other than the video portion that could be beneficial in an automation let us know. maybe if it’s something simple that could add value to the ecosystem, we could take a look.

Thank you pjotal, my version of Raspberry pi was missing the ffmpeg lib, thanks for the guide, this is very cool

I do like the concept that if the camera senses motion, have it turn on a light :). I don't know if the API allows you to get that information from the camera?

i am not 100% sure if this is possible but it’s something that can be
investigated. do you remember if the camera has a motion sensor on it?
if it’s purely based on image i guess it’s not. if this is something they
flag via api, it is.
On Tue, Jun 23, 2020 at 18:01 seecoolguy<EMAIL_ADDRESS>wrote:

I do like the concept that if the camera senses motion, have it turn on a
light :). I don't know if the API allows you to get that information from
the camera?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/misenhower/homebridge-wyze-connected-home/issues/10#issuecomment-648451003,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB23T6KDVX2FYZGNIG6IWUDRYEQ5JANCNFSM4N7GBPSA
.

--
Pedro Carneiro

You cannot see the motion sensor in the wyze API, but you can see the option to turn the camera on and off along with setting other options.


aws-cpp-sdk Issue GetBucketLocation returns Access Denied - when not called by bucket owner

We are running on Centos and Ubuntu and seen the issue on both the systems.
GCC version 4.9.3
Here is the scenario - The data that we want to process in our application is available on S3 buckets. The customers control these S3 buckets. The buckets can be in any region (typically they are is us-east-1, us-west-2 and eu-west-2). We try to stream the data from S3 directly to ensure this works from any location we try GetBucketLocation - the issue is GetBucketLocation returns Access Denied if the client running the instance is not the owner of the bucket.
Not sure how to get around this limitation
Thanks
Jimmy

These are the Actions allowed on the bucket
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:ListMultipartUploadParts",
"s3:PutObject"

I also would add I can access buckets in us-east-1 without any issues. I get intermittent failures on both us-west (oregon) and eu-west (ireland)

Hi
The issue I have is we stream directly from S3 and we cannot stream from buckets in different regions without getting the bucket location and setting it in the Aws::Client::ClientConfiguration structure.
For e.g. if my bucket is in US-WEST-2 but I started my instance in us-east-1 I have no recourse to get the bucket location. Sounds like the only way around is to use pre signed url's or make the bucket owner the same as the instance owner.

Hi wps132230
Yes I have a similar policy on my bucket.
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": [
                "arn:aws:iam::pubweb",
                "arn:aws:iam::job",
                "arn:aws:iam::batch"
            ]
        },
        "Action": [
            "s3:AbortMultipartUpload",
            "s3:GetBucketLocation",
            "s3:GetObject",
            "s3:GetObjectVersion",
            "s3:ListBucket",
            "s3:ListBucketVersions",
            "s3:ListMultipartUploadParts",
            "s3:PutObject"
        ],
        "Resource": [
            "arn:aws:s3:::data-1",
            "arn:aws:s3:::data-1/*"
        ]
    },

Yeah it's a service limitation.
Depending on the nature of your application, you could store the location of the buckets in some lookup table. Say a global table in DynamoDB.

Thanks Marco for the response -  we are going to use the presigned URL's for now. One suggestion I have seen at other places is to use head bucket. In the C++ sdk head bucket seems to return nothing if it is successful. Looking through the code it looks like some of the information exists in the XmlOutcome but is cleared out before we return.
Here is the code from aws-cpp-sdk-s3/source/S3Client.cpp
HeadBucketOutcome S3Client::HeadBucket(const HeadBucketRequest& request) const
{
Aws::StringStream ss;
Aws::Http::URI uri = ComputeEndpointString(request.GetBucket());
uri.SetPath(uri.GetPath() + ss.str());
XmlOutcome outcome = MakeRequest(uri, request, HttpMethod::HTTP_HEAD);
if(outcome.IsSuccess())
{
return HeadBucketOutcome(NoResult());
}
else
{
return HeadBucketOutcome(outcome.GetError());
}
}
Looks like it is HeadBucketOutcome is cleared - can this still return the metadata from the bucket. I can then parse it out for the location and avoid using GetBucketLocation.
Thanks
--
Jimmy

Just for reference this is the post I found https://github.com/aws/aws-sdk-go/issues/720
And using boto we see this

client = boto3.client('s3')
info = client.head_bucket(Bucket="data-1")

print info['ResponseMetadata']['HTTPHeaders']['x-amz-bucket-region']
us-east-1  <= Good result

info2 = client.head_bucket(Bucket="data-eu-west-1")
print info2['ResponseMetadata']['HTTPHeaders']['x-amz-bucket-region']
eu-west-1  <== Good result

Unfortunately we don't have the values of the HTTP headers exposed. But I can see how that can be useful in such cases. I'll add an item to our backlog.

Hi
Thanks very much for adding this to your backlog. It is indeed a very useful feature.
--
Jimmy


SNMP V1 Trap Showing Varbind of SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 which is not present in actual PDU

Hi
In PySNMP v1 TRAP receiver shows SNMP-COMMUNITY-MIB::snmpTrapCommunity.0  but it does not exist in actual V1 trap PDU.
There is no translation of SNMP v2 TRAP to V1. (rfc3418
)
Its an actual v1 trap PDU which don't have snmpTrapCommunity.0 in its var bind.( RFC 1157)
Refer:
the attached debug_log.txt
debug_log.txt
Refer v1 PDU capture.
v1_trpa_pdu.pcapng.txt
used code is something like this:
def cbFun(snmpEngine, stateReference, contextEngineId, contextName,
          varBinds, cbCtx):
    global mibViewController
    print "####################### NEW Notification() #######################"
    execContext = snmpEngine.observer.getExecutionContext(
        'rfc3412.receiveMessage:request'
    )
    print('#Notification from %s \n#ContextEngineId: "%s" \n#ContextName: "%s" \n#SNMPVER "%s" \n#SecurityName "%s"' % ('@'.join([str(x) for x in execContext['transportAddress']]),contextEngineId.prettyPrint(),contextName.prettyPrint(), execContext['securityModel'], execContext['securityName']))
    for oid, val in varBinds:
        output = rfc1902.ObjectType(rfc1902.ObjectIdentity(oid),val).resolveWithMib(mibViewController).prettyPrint()
        print output

used Pysnmp version : 4.3.8

Thank you for rising this!
Yes, that's the intended behavior -- with pysnmp, user-facing side is always SMIv2. That is why even SNMPv1 TRAPs get translated into SNMPv2 TRAPs. Or when you are sending v1 TRAPs you still need to pass v2 TRAPs to pysnmp.
Why is it a problem? I thought of it as a feature because you get TRAPs uniformly, regardless of SNMP version your peer is talking, no?
You can convert it back to SNMPv1 if you want to:
from pysnmp.proto.proxy import rfc2576

v1_pdu = rfc2576.v2ToV1(v2_pdu)

Where v2_pdu is what you get from low-level pysnmp hooks. Or you could reconstruct it from the var-binds you get in the callback:
from pysnmp.proto.proxy import rfc2576
from pysnmp.proto.api import v2c

v2_pdu = v2c.SNMPv2TrapPDU()

v2c.TrapPDUAPI.setVarBinds(v2c_pdu, varBinds)
v1_pdu = rfc2576.v2ToV1(v2_pdu)

Does it make sense?

Ya it's it helpful. My concern was it should not add the community string since the original PDU don't have it, and creates confusion to end user. Now as you point out the v1 conversation I will try that out so I can avoid community string. Please close the case.

One quick question by Pysnm can I forward incoming trap/inform to other pysnmp trap/inform receiver?
Something like Bellow,
(Agent)------(pysnmp fwd)-------(pysnmp receiver)

My concern was it should not add the community string since the original PDU don't have it,
and creates confusion to end user.

That's how it should work:
snmpTrapCommunity OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  accessible-for-notify
    STATUS      current
    DESCRIPTION
        "The value of the community string field of an SNMPv1
         message containing a Trap PDU which is forwarded by a
         a proxy forwarder application using an SNMP version
         other than SNMPv1.  The value of this object SHOULD
         contain the value of the community string field from
         the original SNMPv1 message containing a Trap PDU as
         generated by an SNMPv1 agent.  There is no SIZE
         constraint specified for this object because RFC 1157
         does not impose any explicit limitation on the length
         of community strings (their size is constrained
         indirectly by the SNMP message size)."
    ::= { snmpCommunityMIBObjects 4 }

Apparently, it does not fully implemented with pysnmp -- current implementation it does not carry over the community string from v1 TRAP message into v2 TRAP PDU, it just adds an empty string.
So what you have spotted looks like a bug! Let me fix that.

One quick question by Pysnmp can I forward incoming trap/inform to other pysnmp
trap/inform receiver?

Sure, why not? You just need to send your TRAP PDU elsewhere from your TRAP receiving callback function. Here is an example script for proxying SNMP commands. I can add similar for TRAPs if you need more guidance with this, do you?
BTW, there is already the SNMP proxy forwarder app that can perform TRAP forwarding.

Apparently, it does not fully implemented with pysnmp -- current implementation it does not carry over the community string from v1 TRAP message into v2 TRAP PDU, it just adds an empty string.

Fixed in 9d35779f1cf8dce05bb8abe12aa7a2bb0732967a


can't determine native query result types

Some native queries wrongly return null, for example:
s.createNativeQuery("select current_timestamp", Timestamp.class).getSingleResult()

The cause is https://github.com/eclipse-vertx/vertx-sql-client/issues/657

Once this feature is added to Vert.x, it needs to be wired in to ReactiveLoader.discoverTypes().

We merged a workround with https://github.com/hibernate/hibernate-reactive/pull/364
I will leave the issue open until we can apply the proper solution


Component Browser fails to load on erroneous node

Discord username
No response
What type of issue is this?
Permanent – Occurring repeatably
Is this issue blocking you from using Enso?

[ ] Yes, I can't use Enso because of this issue.

Is this a regression?

[ ] Yes, previous version of Enso did not have this issue.

What issue are you facing?
When opening CB on an erroneous node it goes to, what appears to be, an infinite loop.
See the recording.
Expected behaviour
Should probably open and show anything?
How we can reproduce it?

Createa node with some non-existing method
Create an edge from that node which will open CB

Screenshots or screencasts
Kazam_screencast_00004.webm
Enso Version
efe904cd9f0c44c112a254229d94522802c246e5
Browser or standalone distribution
Standalone distribution
Browser Version or standalone distribution
standalone
Operating System
Linux
Operating System Version
No response
Hardware you are using
No response

I reproduced it. It does not show anything because we don't get any suggestion in completion response. I remember some times ago there were methods of Panic suggested (e.g. catch).
The example request we send to the engine is:
{"jsonrpc":"2.0","id":142,"method":"search/completion","params":{"file":{"rootId":"5a1d2ae3-6569-4e4a-858e-03941a2d7443","segments":["src","Main.enso"]},"isStatic":false,"position":{"character":20,"line":12},"returnType":null,"selfType":"Standard.Base.Panic.Panic","tags":null}}

What happens is, IDE indeed asks for non-static methods on the Panic type
{
    "file":{
      "rootId":"9ef839a5-01ea-4c72-9dd6-b7158f8fe041",
      "segments":[
        "src",
        "Main.enso"
      ]
    },
    "isStatic":false,
    "position":{
      "character":14,
      "line":9
    },
    "returnType":null,
    "selfType":"Standard.Base.Panic.Panic",
    "tags":null
  }

But the methods on Panic are all static https://github.com/enso-org/enso/blob/bb8f910be9272fbf513f05a05f24110ed6d5d7e4/distribution/lib/Standard/Base/0.0.0-dev/src/Panic.enso, and the engine returns an empty response.


Adding regions for code block

By adding regions, the code can be referenced within in docs, instead of hard coding it. This way it avoids multiple locations to update when the code changes.
Purpose

...

Does this introduce a breaking change?

[ ] Yes
[ ] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
npm install

Test the code

What to Check
Verify that the following are valid

...

Other Information

@codemillmatt can you please merge this PR.
By adding regions, the code can be referenced within in docs, instead of hard coding it. This way it avoids multiple locations to update when the code changes.


[Loc] Sql xlf update for 5-3-2022 (add untitledNotSupported)

This PR fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
27885

Relevant Lines:
61781

💛  - Coveralls


[server][fc] metadata hash optimization

Summary, imperative, start upper case, don't end with a period

This adds an optimization to the request-based metadata where the GET request from the client also contains the hashcode of the metadata currently cached in the client (/metadata/storename/hash/)
The server compares this with the metadata it has and if it's a match, the server will return an empty response with all the fields set to null rather than sending a full response of duplicate data that won't be used
Savings here are the space of the heap objects that we have in the response (version metadata, versions list, routing tables, helix group info)
How was this PR tested?

Added unit test to KafkaStoreIngestionServiceTest and updated existing tests to reflect changes
Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to explain your proposed changes and call out the behavior change.

Closing since it is a stale branch. @avedmala Feel free to reopen if you plan to work on this


docker build on ubuntu 20.04 LTS breaks

simply doing docker compose up --detach leads to a pip install error
Here's the full traceback
[+] Building 439.8s (16/24)
 => [dalle-playground_dalle-interface internal] load build definition from Dockerfile                                                                              0.1s
 => => transferring dockerfile: 32B                                                                                0.1s
 => [dalle-playground_dalle-interface internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [dalle-playground_dalle-backend internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 32B                                                                                0.0s
 => [dalle-playground_dalle-backend internal] load .dockerignore                                                                                0.1s
 => => transferring context: 2B                                                                                0.1s
 => [dalle-playground_dalle-interface internal] load metadata for docker.io/library/node:lts-slim                                                                  0.1s
 => [dalle-playground_dalle-backend internal] load metadata for docker.io/nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04                                              0.1s
 => [dalle-playground_dalle-interface 1/6] FROM docker.io/library/node:lts-slim@sha256:989dc486196a861f0ccc6c72f2eb7a5d3edb3451f2325bb8e81702ae42ed40e1            0.0s
 => [dalle-playground_dalle-interface internal] load build context                                                                                0.0s
 => => transferring context: 843B                                                                                0.0s
 => CACHED [dalle-playground_dalle-interface 2/6] COPY package.json /code/package.json                                                                             0.0s
 => CACHED [dalle-playground_dalle-interface 3/6] COPY package-lock.json /code/package-lock.json                                                                   0.0s
 => CACHED [dalle-playground_dalle-interface 4/6] WORKDIR /code                                                                                0.0s
 => CACHED [dalle-playground_dalle-interface 5/6] COPY . /code                                                                                0.0s
 => [dalle-playground_dalle-interface 6/6] RUN npm install                                                                                279.7s
 => [dalle-playground_dalle-backend 1/9] FROM docker.io/nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04@sha256:275d35f7985cfe12dc3e6e40a3df5fff2bb217b1c248f0f70dad  439.5s
 => => resolve docker.io/nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04@sha256:275d35f7985cfe12dc3e6e40a3df5fff2bb217b1c248f0f70dadaa298d1b938b                       0.1s
 => => sha256:275d35f7985cfe12dc3e6e40a3df5fff2bb217b1c248f0f70dadaa298d1b938b 2.43kB / 2.43kB                                                                     0.0s
 => => sha256:21c6ada6eafc65a3d872cc265726e98ccafdb9ca440977e644fa49e41d8572a3 14.87kB / 14.87kB                                                                   0.0s
 => => sha256:8e5c1b329fe39c318c0d49821b339fb94a215c5dc0a2898c8030b5a4d091bcba 28.57MB / 28.57MB                                                                   1.2s
 => => sha256:7f1ba713f7bc7d2f024e53707865310ba3598f4c672a3eb43a7d80a579f24ccd 7.93MB / 7.93MB                                                                     0.5s
 => => sha256:c6ce639536d2eb5588528344bdb11cc344b2665d3b23489b80c9c967d27cebbb 11.90MB / 11.90MB                                                                   0.7s
 => => sha256:80565d12228abcb3881d875754fb50e585808e2dc4a1fdfd6b115ce402f8ab4b 188B / 188B                                                                         1.2s
 => => sha256:cda944862fc4727530a6076be56b31755825191b8628bf396df5db891d8f8d63 6.43kB / 6.43kB                                                                     1.2s
 => => sha256:c5a3e503682d3fe7537937f4f4d6abb11686532ecbda0908858a8162603c83ef 62.87kB / 62.87kB                                                                   1.3s
 => => sha256:2552b309a76214f646371475dae9addac6200da3aa0da89a202703a01f7fa0fc 1.30GB / 1.30GB                                                                    84.0s
 => => sha256:b708836e94fc4d712c2f7883732795fb6091ade2d929aee88eb8d00d477fe8d6 1.71GB / 1.71GB                                                                   106.8s
 => => sha256:7ddd299e309f01d661432978534a1a9fda3fac6ab6b11627f6fad543ec677b49 85.87kB / 85.87kB                                                                   1.5s
 => => sha256:233934f1b026bb75e03939a8eaf7841cd6bb3be4828c813d739b866f8d0f3074 1.90GB / 1.90GB                                                                   118.1s
 => => extracting sha256:8e5c1b329fe39c318c0d49821b339fb94a215c5dc0a2898c8030b5a4d091bcba                                                                         15.6s
 => => extracting sha256:7f1ba713f7bc7d2f024e53707865310ba3598f4c672a3eb43a7d80a579f24ccd                                                                          3.9s
 => => extracting sha256:c6ce639536d2eb5588528344bdb11cc344b2665d3b23489b80c9c967d27cebbb                                                                          4.7s
 => => extracting sha256:80565d12228abcb3881d875754fb50e585808e2dc4a1fdfd6b115ce402f8ab4b                                                                          0.0s
 => => extracting sha256:cda944862fc4727530a6076be56b31755825191b8628bf396df5db891d8f8d63                                                                          0.1s
 => => extracting sha256:2552b309a76214f646371475dae9addac6200da3aa0da89a202703a01f7fa0fc                                                                         98.2s
 => => extracting sha256:c5a3e503682d3fe7537937f4f4d6abb11686532ecbda0908858a8162603c83ef                                                                          0.0s
 => => extracting sha256:b708836e94fc4d712c2f7883732795fb6091ade2d929aee88eb8d00d477fe8d6                                                                        125.5s
 => => extracting sha256:7ddd299e309f01d661432978534a1a9fda3fac6ab6b11627f6fad543ec677b49                                                                          0.0s
 => => extracting sha256:233934f1b026bb75e03939a8eaf7841cd6bb3be4828c813d739b866f8d0f3074                                                                        109.2s
 => [dalle-playground_dalle-backend internal] load build context                                                                                0.1s
 => => transferring context: 172B                                                                                0.0s
 => [dalle-playground_dalle-interface] exporting to image                                                                                159.7s
 => => exporting layers                                                                                159.7s
 => [dalle-playground_dalle-backend 2/9] WORKDIR /app                                                                                8.5s
 => ERROR [dalle-playground_dalle-backend 3/9] RUN apt-get update && apt-get install -y python3-pip                                                                1.2s
------
 > [dalle-playground_dalle-backend 3/9] RUN apt-get update && apt-get install -y python3-pip:
#0 1.092 exec /bin/sh: exec format error
------
failed to solve: executor failed running [/bin/sh -c apt-get update && apt-get install -y python3-pip]: exit code: 1

Does the error still persist? What Docker do you use? Which OS?


Problems after upgrade to 2010.10.1

(I'm still running HAOS 2021.9.7)
I upgraded the automower module and got this error message:
Failed to set up: Your API-Key is not compatible to websocket, please renew it on https://developer.husqvarnagroup.cloud/

Tried to renew the API key on Husqvarna portal and ran the curl test with success. Still no go with the integration.
Created a new Application, added AutoMower and Authentication APIs and got the following problems:
Make sure that the Authentication API and the Automower-Connect API is connected with your API-Key: https://developer.husqvarnagroup.cloud/

Any ideas?

Still same error, even with the new Application key:
Make sure that the Authentication API and the Automower-Connect API is connected with your API-Key: https://developer.husqvarnagroup.cloud/
Running the curl example for Husqvarna site works and gives ,"scope":"iam:read amc:api" in the response.
Note - I'm still on HAOS 2021.9.7 and a bit reluctant to upgrade to 2021.10 just yet...

Can't find much in the logs:
2021-10-14 18:09:18 DEBUG (MainThread) [aioautomower.rest] Resp.status get access token: 200
2021-10-14 18:09:18 DEBUG (MainThread) [aioautomower.rest] Resp.status mower data: 403

@simontegelid: I don't see an indication for that in the logs above. I think it's better to check if the basic functionality of the integration is already working in the config flow. What can you do with an integration, that gives you an "unavailable" entity? And the question is, why the data should be retrieved later, when it's not working in the config flow. The response should still be 200 and the metadata should show something like 'metadata': {'connected': False, 'statusTimestamp':<PHONE_NUMBER>564}, even if the mower is "BORTKOPPLAD". But maybe we can see if the websocket works in this special case, if @tangix can help us.
@tangix: Can you please comment out this lines with an # in your ./config/custom_components/husqvarna_automower/cnfig_flow.py?
https://github.com/Thomas55555/husqvarna_automower/blob/c1c09003019baf5e9ba86078d417564b48c37394/custom_components/husqvarna_automower/config_flow.py#L67-L82
Save it, and than restart your home assistant and try it again?

As I said, even if the mower itself is not accessible, the API should still send an status like Connected: False. There must be something else wrong, But I have no idea, what it can be.

I just experienced this myself and it's not related to the API key. Passing the stored token in the HASS config entry gives a 403 on the GetMowerData (no token refresh is performed since the token is still not expired). I also tried to refresh the token if the GetMowerData fails, but that gives aioautomower.rest.TokenRefreshError: The token cannot be refreshed, respone from Husqvarna Automower API: 400. It works just fine to use username/password (with the same API key) to get a new token. Storing that new token and passing later on also works fine.
I modified the CLI in aioautomower to take an optional token as input and use that for login instead of username/password, will push that as as debug tool for this.
Reopening this.

The mowing season is soon over in the Northern Hemisphere but starts in the Southern so you'll have plenty of user feedback to help troubleshoot this! Our mower has worked since I recreated the Application Keys but I don't know the timeout
Keep up the great work with this integration!

Can you please check, if your new token is really connected to both of the APIs? I have no other explanation right now.

This fixed the issue for me. I connected all the available APIs

GARDENA smart system API
Authentication API
Automower Connect API

Before that, I had the same issue:
Make sure that the Authentication API and the Automower-Connect API is connected with your API-Key: https://developer.husqvarnagroup.cloud/
After that, it authenticated successfully and added my mower as a device.


Bug: MissingNamespaceDatabase: There are no namespace and/or database configured.

Describe the bug
I keep seeing this error in my logs, even though I am still able to run queries just fine:
Trace: Unhandled Rejection Promise: Promise {
  <rejected> MissingNamespaceDatabase: There are no namespace and/or database configured.
      at HttpEngine.rpc (/my-server/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/library/engine.ts:340:10)
      at async Surreal.ping (/my-server/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/surreal.ts:173:21)
}
    at process.<anonymous> (/my-server/src/server/functions/server/add.process.error.handling.events.ts:18:11)
    at process.emit (node:events:518:28)
    at process.emit (node:domain:488:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/my-server/node_modules/.pnpm/@cspotcode+source-map-support@0.8.1/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/process/promises:150:20)
    at processPromiseRejections (node:internal/process/promises:284:27)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)
Trace: error unhandledRejection {
  unhandledRejectionReason: MissingNamespaceDatabase: There are no namespace and/or database configured.
      at HttpEngine.rpc (/my-server/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/library/engine.ts:340:10)
      at async Surreal.ping (/my-server/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/surreal.ts:173:21),
  unhandledRejectionPromise: '{}',
  level_name: 'error'
}

Steps to reproduce
export default class SurrealDBService {
	public static async init(): Promise<SurrealDBService> {
		if (!SurrealDBService._instance || !SurrealDBService._db) {
			this._db = new Surreal();

			await this._db.connect(config.connections.surrealdb.url);

			await this._db.use({
				namespace: config.connections.surrealdb.namespace,
				database: config.connections.surrealdb.database
			});

			this._token = await this._db.signin({
				username: config.connections.surrealdb.username,
				password: config.connections.surrealdb.password
			});
			console.log('surreal', this._token);
		}

		this._instance = new SurrealDBService();
		return this._instance;
	}

	private static _initialized: boolean = false;
	private static _token: string;
	private static _db: Surreal;
	private static _instance: SurrealDBService;
}

All values under config.connections.surrealdb are correct, as I am still able to connect and run querries successfully.
This seems to be an error in the ping call.
Expected behaviour
not to throw an error...
SurrealDB version
1.5.3 for linux on x86_64
SurrealDB.js version
1.0.0-beta.9
Contact Details
<EMAIL_ADDRESS>Is there an existing issue for this?

[X] I have searched the existing issues

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey @cope, thanks for opening this issue! While I was not able to reproduce this issue locally, I will be removing the pinger for the HTTP engine in general, as it was only added there by mistake! Only the WS engine needs a pinger, as the websocket implementation is sometimes flaky. I'll be working on some more improvements, but in one of the next beta's this issue will be fixed :D

@kearfy Thanks 😃
I hope it will be soon, 'cause this is annoying 😄
Trace: Unhandled Rejection Reason: HttpConnectionError: There was a problem with authentication.
    at process.<anonymous> (/my-app/src/server/functions/server/add.process.error.handling.events.ts:24:11)
    at process.emit (node:events:518:28)
    at process.emit (node:domain:488:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/my-app/node_modules/.pnpm/@cspotcode+source-map-support@0.8.1/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/process/promises:150:20)
    at processPromiseRejections (node:internal/process/promises:284:27)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)
Trace: Unhandled Rejection Promise: Promise {
  <rejected> HttpConnectionError: There was a problem with authentication
      at HttpEngine.rpc (/my-app/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/library/engine.ts:386:10)
      at processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async Surreal.ping (/my-app/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/surreal.ts:173:21) {
    status: 401,
    statusText: 'Unauthorized',
    buffer: ArrayBuffer {
      [Uint8Contents]: <54 68 65 72 65 20 77 61 73 20 61 20 70 72 6f 62 6c 65 6d 20 77 69 74 68 20 61 75 74 68 65 6e 74 69 63 61 74 69 6f 6e>,
      byteLength: 39
    }
  }
}
    at process.<anonymous> (/my-app/src/server/functions/server/add.process.error.handling.events.ts:25:11)
    at process.emit (node:events:518:28)
    at process.emit (node:domain:488:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/my-app/node_modules/.pnpm/@cspotcode+source-map-support@0.8.1/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/process/promises:150:20)
    at processPromiseRejections (node:internal/process/promises:284:27)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)
Trace: error unhandledRejection {
  unhandledRejectionReason: HttpConnectionError: There was a problem with authentication
      at HttpEngine.rpc (/my-app/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/library/engine.ts:386:10)
      at processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async Surreal.ping (/my-app/node_modules/.pnpm/surrealdb.js@1.0.0-beta.9/node_modules/surrealdb.js/src/surreal.ts:173:21) {
    status: 401,
    statusText: 'Unauthorized',
    buffer: ArrayBuffer {
      [Uint8Contents]: <54 68 65 72 65 20 77 61 73 20 61 20 70 72 6f 62 6c 65 6d 20 77 69 74 68 20 61 75 74 68 65 6e 74 69 63 61 74 69 6f 6e>,
      byteLength: 39
    }
  },
  unhandledRejectionPromise: '{}',
  level_name: 'error'
}
    at Logger._processAndSendToWinston (/my-app/src/server/logger.ts:57:39)
    at Logger.error (/my-app/src/server/logger.ts:97:8)
    at process.<anonymous> (/my-app/src/server/functions/server/add.process.error.handling.events.ts:26:10)
    at process.emit (node:events:518:28)
    at process.emit (node:domain:488:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/my-app/node_modules/.pnpm/@cspotcode+source-map-support@0.8.1/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/process/promises:150:20)
    at processPromiseRejections (node:internal/process/promises:284:27)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)


Read stored Map to Object field

@bsokolovu please explain why this change is needed. And also please add conversion tests for the change.

Also this change will break conversion of data that has type information in the source. convertCustomType  does not convert any source data if type information is not provided, so please elaborate more on the issue.

@Aloren I've found that the issue I was going to fix has already been fixed couple month ago in 2.3.2.RELEASE
Sorry for bothering you.


Can't get Copy-CompanyInNavContainer to work!

Hi
When I invoke the function 'Copy-CompanyInNavContainer' I keep getting an error.

Any ideas?

Will be fixed in the next version

Thank you. :-)

Works like a charm! :-)


Example - source code

Hi all,
Can anybody gives me the source code of this example:

Thank you!

I found.
Closing...


Setup Instructions?

The Github page claims that there is some setup instructions on this page:
https://github.com/FortAwesome/fa-icon-chooser/blob/main/packages/fa-icon-chooser/src/components/fa-icon-chooser/readme.md
but I can't find any there.
I am trying to embed the web component in Vue and would love to see how the web component has to be hooked up so it works. It would be enough to see this for plain vanilla JS. Yet not everybody is a web component pro :)

Here is the documentation on the properties that this component requires: https://github.com/FortAwesome/fa-icon-chooser/blob/main/packages/fa-icon-chooser/src/components/fa-icon-chooser/readme.md.
I'm not sure how you are expected to mount this using plain text given some of the properties are javascript functions. I could see a version of this that only requires a version or api token / kit token.
With plain JS, I think you can create the element and add the properties, then mount to the dom. In React, you can provide javascript functions as properties which is what we've done on our project.
Here is what I've done for React (TypeScript):
You need either a version like 6.6.0 or a api token and kit token. As far as I can tell the API URL is just https://api.fontawesome.com. You can start with the version since that doesn't require authorization. Maybe someone else can provide context as to why we need to provide getUrlText when it seems like common functionality. :shrug:
import { QueryHandler } from '@fortawesome/fa-icon-chooser/dist/types/components/fa-icon-chooser/fa-icon-chooser';
import { UrlTextFetcher } from '@fortawesome/fa-icon-chooser/dist/types/utils/utils';
import config from 'temp/config';

// See https://github.com/FortAwesome/fa-icon-chooser/blob/main/packages/fa-icon-chooser/dev/runtime.js

// See https://github.com/FortAwesome/fa-icon-chooser/tree/main/packages/fa-icon-chooser-react.
// If a kitToken is provided, authorization is required with `apiToken`.

const {
  fontAwesomeApiUrl: apiURL,
  fontAwesomeApiToken: apiToken,
  fontAwesomeVersion: version,
  fontAwesomeKitToken: kitToken,
} = config;

export { version, kitToken };

// Use memory storage for now.
type AccessToken = {
  token: string;
  expiresAtEpochSeconds: number;
};

let accessToken: AccessToken | undefined = undefined;

// This function loads the Font Awesome library (as Text) which is then executed by the web component.
// Essentially, loads a configurable version of the library.
export const getUrlText: UrlTextFetcher = (url) =>
  fetch(url).then((response) => {
    if (response.ok) {
      return response.text();
    } else {
      throw new Error(`DEBUG: bad query for url: ${url}`);
    }
  });

export const getAccessToken = () => {
  // If we don't have an apiToken, we don't need to authenticate.
  if (!apiToken) {
    return Promise.resolve();
  }

  // If we already have a valid token, we don't need to get another one.
  if (accessToken && Math.floor(Date.now() / 1000) <= accessToken.expiresAtEpochSeconds) {
    return Promise.resolve();
  }

  return fetch(`${apiURL}/token`, {
    method: 'POST',
    headers: {
      authorization: `Bearer ${apiToken}`,
    },
  })
    .then((response) => {
      if (!response.ok) {
        throw new Error('Failed to get an access token.');
      }
      return response.json();
    })
    .then((data) => {
      accessToken = {
        token: data['access_token'],
        expiresAtEpochSeconds: Math.floor(Date.now() / 1000) + data['expires_in'],
      };
    });
};

// Make queries for the Font Awesome chooser.
// This function handles authentication for the web component.
export const handleQuery: QueryHandler = (query, variables) =>
  getAccessToken()
    .then(() => {
      if (kitToken && !accessToken?.token) {
        throw new Error(
          'When using a kit, you must provide an apiToken so that an authorization token can be obtained.'
        );
      }

      const headers: {
        [key: string]: string;
      } = {
        'Content-Type': 'application/json',
      };

      if (accessToken) {
        headers['Authorization'] = `Bearer ${accessToken.token}`;
      }

      const cleanedQuery = query.replace(/\s+/g, ' ');

      return fetch(apiURL, {
        method: 'POST',
        headers,
        body: JSON.stringify({
          query: cleanedQuery,
          variables,
        }),
      });
    })
    .then((response) => {
      if (!response.ok) {
        throw new Error('bad query');
      }

      return response.json();
    });

We then load the component with
<FaIconChooser
  version={version}
  kitToken={kitToken}
  handleQuery={handleQuery}
  getUrlText={getUrlText}
  onFinish={handleResult}
/>

Where handleResult looks like
const handleResult = (event: CustomEvent<IconChooserResult>): void => {
  const prefix = event.detail?.prefix ?? '';
  const iconName = event.detail?.iconName ?? '';

  //...
};


Commander: Disarm after 5 seconds on the ground.

This needs proper testing, but will make tablet flying more fun!

@LorenzMeier This looks good, I will give it a first test in simulation.

Cool, could we maybe add a param to turn it on/off?

@LorenzMeier Works like a charm in SITL gazebo. Probably should wait for a real outdoor test.

@AndreasAntener Yes, I can do that.

@AndreasAntener Done. The default value is to disarm when landed. So you'd have to set the parameter COM_DISARM_LAND to 0. Tested in SITL.

@SimonWilks  suggested an even better idea to use the parameter as time-out value.

Sounds good :)

Actually the code had a bug before. The landing detector only update if the status has changed. So if the vehicle was in the air the timestamp was never updated. Thus, the time-out was given by the delay of the landing detector and not the actual time-out. Fixed it and tested in SITL, with values 0, 5 and 10.

@AndreasAntener @SimonWilks So we set the default time-out to zero, so nothing should have changed for you guys.

@LorenzMeier @SimonWilks @AndreasAntener Works as expected even on the PH V2! :-)
Merging.

I presume you'll rebase and then merge?

@LorenzMeier Yes, there was a conflict.

Now building fails 8). Try building px4fmu-v2_default locally.

Retested, works fine, merging.


Fixes #1 by passing SSL options to the phantomjs command.

fixes #1
Errors were a result of either an bad cert or a cert with a version other than sslv3.
Comand line options added are:
'--ssl-protocol=any'
'--ignore-ssl-errors=true'
These can be overriden from the options object passed to screenshot(url, filename, options).
where options = {ignoreSslErrors: true, sslProtocol: 'any'} by default.

Looks good! Thanks. I'll merge to master right away

These changes are released in 0.2.0.

This functionality has been changed in 1.0.0. See CHANGELOG.md to see API changes.


Surveys: not showing on change initiative page

My fault - caused by alignment of survey-section to other sections


!suggestrandommap command

No parameters - This should suggest a random map that is not on that challenge's map list.
!suggestrandommap top <x> - This should suggest a random map that is in the top x of played maps on the OTL.
!suggestrandommap bottom <x> - This should suggest a random map that is in the bottom x of played maps on the OTL.

Fixed by b34ea8b8cd1203c7175ca2792a20a5287bad5e4e.


2 for 1 bugfixes

Closes #57 by running chmod on the mount point before cleanup
Closes #60 by adding chmod to setup.sh to make sure the execute bit is set on localization.sh

Coverage decreased (-0.1%) to 59.506% when pulling 0ad1ac93269905fb8ab8f2de3a7978e2797ed3bd on dummy-linux into 82c0df4cffef5de577525e04aeeb4e15d42f73fc on master.


Develop

Codecov Report

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

@@           Coverage Diff           @@
##           master       #1   +/-   ##
=======================================
  Coverage   80.51%   80.51%
=======================================
  Files          11       11
  Lines         272      272
=======================================
  Hits          219      219
  Misses         53       53


2.7 InvokableFactory options from AbstractPluginManager affect multiple unshared instantiations

I ran into this when using a NotEmpty validator, if I specify the options for one of them, all of them get those options rather than the defaults.
public function getInputFilterSpecification()
{
	return [
		'elementA' => [
			'required' => true,
			'validators' => [
				[
					'name' => 'notEmpty',
					'options' => [
						'type' => NotEmpty::NULL,
					],
				],
			],
		],
		'elementB' => [
			'required' => true,
			//Injected validator will have type NotEmpty::NULL
		],
	];
}

I added a test and tried to fix it by having AbstractPluginManager call setCreationOptions with an empty array, but that causes testMutableMethodNeverCalledWithoutCreationOptions to fail.
AndrolGenhald/zend-servicemanager@c56f494d0948697ac2867d0b2aa4eb877a395c37

Fixed with #127.


04_figure4: empty folder?

Hi,
I'm very interested in the data and codes in figure 4 (analysis of all T cells sorted by FACS). However the folder seems empty? Is there any possibility you could share the "figure4{a-d}.Rmd"? Thank you so much!

Thanks, I have learned a lot from this project. And I am really anticipating a update for Figure4 and Figure5.


[ARCTIC-994] Introduce design of TransactionId generation to resolving data conflicts

Why are the changes needed?

fix #994
Brief change log

generate TransactionId from change snapshot sequence
spark operation begins a transaction with new TransactionId
flink operation does not begin a transaction, and uses snapshot sequence as TransactionId when committing. The TxId in fileName is set to be 0, and the correct TransactionId should get from iceberg metadata in this case
flink incremental pull using TableEntriesScan instead of the iceberg TableScan, to get the sequence number from iceberg metadata when TxId in fileName is 0
import a UUID into the file name to distinguish files with the same TxId = 0, in CommonOutputFileFactory and AdaptHiveOutputFileFactory
Introduce com.netease.arctic.io.FileNameHandle to resolve file name.
Introduce com.netease.arctic.data.file.ContentFileWithSequence to wrap ContentFile.
Make com.netease.arctic.scan.BaseChangeTableIncrementalScan can return SequenceNumber.
make the using change snapshot sequence as TransactionId be compatible with old TransactionId  (make sure snapshot sequence >= old transactionId) when ams start, in UpdateTool

How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before making a pull request

Documentation

Does this pull request introduces a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

When TransactionId is generated on commit, the TransactionId in the file name is 0, so we have to import a UUID into the file name to distinguish files.

cc @YesOrNo828

This PR also fix #1045


Feat: Add the possibility of having several language files in the tree structure for the same locale

In VueJS projects, to better organize its translation files, we sometimes create several files for the same locale.
This MR now allows it :smiley:
PS : Do not hesitate to give me feedback on my code if it does not correspond to your criteria.
Thanks !

Hi @jevillard!
I find this PR good!
Would you mind to add some tests?
This would be the only thing missing actually.

Which tests would you like to add?
Because the function extractI18nItemsFromLanguageFiles that I modified is not exposed so it is more difficult to unit test on it.

Looks good! :)
Thank you. @jevillard!


Add CI github action for testing on push and PR

This PR additionally updates the TestGrantVmGroupAccess test to account for running on a machine that doesn't have support for running hyper-v VMs, which is the current case for github hosted windows images.
Signed-off-by: Kathryn Baldauf<EMAIL_ADDRESS>

Can we add -gcflags=all=-d=checkptr to the go test? It's caught a lot of stuff for hcsshim that we fixed


Downgraded to C# 4.0

In case you still want the modifications I created a new branch with only the downgrade to C# 4.0 as the pull request seems to merge the whole branch and I've been adding other commits to the other branch.

Thanks very much for the PR!


astroid chip not programable in observetory

Version of Advanced Rocketry
1.12.2-1.5.0-136
Have you verified this is an issue in the latest unstable build
Y
Version of LibVulpes
1.12.2-0.4.0-53
Version of Minecraft
1.12.2
Description of the problem
i can't program a astroid chip in the observetory

Observatory needs at least 100 Distance Data, and it to be night time to scan for Asteroids. Red Letter Scan Button means no Data. This may not be your issue, but adding it anyways.
After choosing an Asteroid, click the gears between the Unprocessed Chip and the empty slot "Process Discovery". and the processed Asteroid Chip should switch to the empty slot.
Chip must then be filled with Data in the ADP multiblock before using in Sat Rocket. This may not be your issue either, but adding it anyways.
If still unable process chip, break the Observatory block, replace and Try again.

if i click on the gears then it doesn't do enything

Do you have the required everything? Did you turn it on?

yes i did

but in the night it doesn't open to

m

It is fine. I wanted to make sure it worked. Thanks for confirming that.
Sent from my iPhone

On Jan 31, 2020, at 6:58 PM, eduradboranov<EMAIL_ADDRESS>wrote:

You are using a old version. Are you on the latest enigmatica 2?? I thought they updated to a more recent version of ar.
Correct, I was running Enigmatica2 v1.72a. I didn't update as I couldn't spot any useful fixes in their patch notes. But just updated it to 1.76a and much to my surprise, it's working fine - chip programs as expected, and observatory dome opens/closes with day/night cycle.
Sorry for the noise! :]
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Ran into this same issue. The first chip worked fine, now clicking the gears does nothing.
AR: 1.12.2-1.7.0-209
E2E: 1.80
Forge: 1.12.2-<IP_ADDRESS>47

And it just got worse. Not the observatory just eats my chips. Scan, Select an Asteroid, click gears, and the chip just disappear.
It's at night, and nothing in the log or the debug log.


Visibility of types is ignored

I have a code like following:
#[wasm_bindgen(module = "/src/helpers.js")]
extern "C" {
    #[wasm_bindgen(js_name = myHelper)]
    fn do_something(s: MyStruct);
}

#[wasm_bindgen]
struct MyStruct {
    // ...
}

In this scenario, I'm using #[wasm_bindgen] to generate type conversions for MyStruct, so that I could pass it to the JS snippet and it could operate on this value.
However, it's still a private struct that I don't want exposed from the final module.
Right now wasm-bindgen ignores visibility, and assumes that any #[wasm_bindgen] types should be exported, so MyStruct ends up visible as export class { ... } in the generated .js and .d.ts files.

Huh, I thought I could work around by using
#[wasm_bindgen(js_name = _priv_MyStruct)]
struct MyStruct {
    // ...
}

to at least discourage users from touching the class, but then wasm-bindgen generates two copies of the class - one for export class MyStruct { ... } and another export class _priv_MyStruct { ... } 😕

Huh, I thought I could work around by using
#[wasm_bindgen(js_name = _priv_MyStruct)]
struct MyStruct {
    // ...
}

to at least discourage users from touching the class, but then wasm-bindgen generates two copies of the class - one for export class MyStruct { ... } and another export class _priv_MyStruct { ... } 😕


Malfunction to parse a variable with macro

VSCode Version: 1.48.1
OS Version: Windows 10 ver 1909
C/C++ Extension Version: v0.30.0-insiders2

Steps to Reproduce:

Go to the File menu
Click on 'New File' for .c file
Type the below code

#include <stdio.h>

#define UINT8                       unsigned char
#define TEST_MACRO(ADDR)            (ADDR)

void TEST_FUNCTION(void addr)
{

}

UINT8 test;

int main()
{
    test;
    TEST_MACRO(test);
    TEST_FUNCTION(test);

    (UINT8)test;
    ((UINT8)test);
    TEST_MACRO((UINT8)test);
    TEST_MACRO(((UINT8)test));
    TEST_FUNCTION(((UINT8)test));

    (unsigned char)test;
    ((unsigned char)test);
    TEST_MACRO((unsigned char)test);
    TEST_MACRO(((unsigned char)test));
    TEST_FUNCTION(((unsigned char)test));

    return 0;
}

The abnormal symptom is below.

Expected behavior
It needs to be able to parse everything correctly, regardless of the number of parentheses surrounding the variable passed as a macro function or function parameter.
But, the line number 22 shows something wrong. This symptom occurs when the defined variable type and macro function are used and a variable is wrapped more than once by the parentheses.
I think the problem occurred by the vscode-cpptools extension. But, in originally reported VS Code at https://github.com/microsoft/vscode-cpptools/issues/5703, sean-mcmanus who is assigned added a label(Visual Studio). Additionally, I think the problem is not only for vscode-cpptools that is the reason why I address the issue again here.

Does this issue occur when all extensions are disabled?: No

/extC++


Data-generated test cases (parameterized tests)

At the moment, generating multiple test cases that differ only by input data is rather cumbersome:
describe('prime number checker', function() {
  [2,3,5,7].forEach(function(value) {
    it('returns true for prime number ' + value, function() {
      expect(isPrime(value)).to.be.true();
    });

  [4,6,8,9].forEach(function(value) {
    it('returns false for composite number ' + value, function() {
      expect(isPrime(value)).to.be.false();
    });
});

I am proposing to extend the current API with syntactic sugar for data-generated test cases by adding an optional second parameter to both it and describe, this parameter will be an array of data points to test.
describe('prime number checker', function() {
  it('returns true for prime numbers', [2,3,5,7], function(data) {
    expect(isPrime(data)).to.be.true();
  });

  it('returns false for composite number', [4,6,8,9], function(data) {
    expect(isPrime(data)).to.be.false();
  });
});

More advanced example:
var SAMPLES = [
  { scheme: 'http', host: 'localhost', path: '/', url: 'http://localhost/' },
  { scheme: 'https', host: '<IP_ADDRESS>', path: '/test', url: 'https://<IP_ADDRESS>/test' }
];

describe('url helper', SAMPLES, function(data) {
  it('builds url from components', function() {
    var str = urlHelper.build({ scheme: data.scheme, host: data.host, path: data.path });
    expect(str).to.equal(data.url);
  });

  it('parses url into components', function() {
    var components = urlHelper.parse(data.url);
    expect(components).to.eql({ scheme: data.scheme, host: data.host, path: data.path });
  });
});

I am happy to contribute the implementation.
The purpose of this issue is to discuss necessary details and to get maintainers' approval before I start writing code.
Related to #57.
/cc @mcollina

TL;DR: how can I use parametrized tests?

Something like this can work :)
var assert = require('assert');

describe('suite', function() {
  [1, 2, 3].forEach(function(n) {
    it('correctly handles ' + n, function() {
      assert(n);
    });
  });
});

// =>

  suite
    ✓ correctly handles 1
    ✓ correctly handles 2
    ✓ correctly handles 3

  3 passing (7ms)

Very important:

describe can not be paramterized due on problems

reason?

only it

describe can not be paramterized due on problems

What problems?
[1, 2, 3, 4].forEach(function (val) {
  describe('test ' + val, function () {
    it('bla', function () {

    })
  })
})

➜  js  mocha describe-parameterized.js

  test 1
    ✓ bla

  test 2
    ✓ bla

  test 3
    ✓ bla

  test 4
    ✓ bla

  4 passing (8ms)

I agree with @dasilvacontin, this is the approach we use and it works reasonably well. Not sure if polluting the mocha's API with parametrization is necessary at all TBH.

FWIW, the @dasilvacontin 's solution only appears to work, but thte val value isn't changed in the it blocks:
[1, 2, 3, 4].forEach(function (val) {
  describe('test ' + val, function () {
    it('bla', function () {
      console.log(val);
    })
  })
})

test 1
  ✓ bla
  4
test 2
  ✓ bla
  4
test 3
  ✓ bla
  4
test 4
  ✓ bla
  4

@btelles What version of mocha are you using? Cause it works for me.
$ cat test.js
[1, 2, 3, 4].forEach(function (val) {
  describe('test ' + val, function () {
    it('bla', function () {
      console.log(val);
    })
  })
})
dstjules:~/Desktop
$ mocha --version
2.4.5
dstjules:~/Desktop
$ mocha test.js

  test 1
1
    ✓ bla

  test 2
2
    ✓ bla

  test 3
3
    ✓ bla

  test 4
4
    ✓ bla

  4 passing (10ms)

@danielstjules Works here as well.
@btelles is that really the code you are using? From the output it looks as if you were referencing an iterator variable – once the its are actually executed, the loop has finished and the iterator points/has the limit value.

FWIW, There's a module available I wrote called Unroll which provide parameterized tests like the above but with named parameters which are also reflected in the test title. Useful if you want the test titles to be informative with regard to the parameters.

I know this is old but there is now a really simple npm package to make this easier: mocha-param

@mikejsdev I don't understand the reasoning behind mocha-param when we can use: https://mochajs.org/#dynamically-generating-tests. The latter allows for unique names for each test, which is pretty huge. Presumably we can use this same dynamic technique to stamp out multiple describes too (although I have not tried that.) Can you help me understand the use cases where mocha-param is preferable to dynamically generating tests?

I agree with @binduwavell
And this has also been approved earlier by @dasilvacontin and @danielstjules and also by me now with mocha 3.2.0
At all people who writing modules and publishing them like @mikejsdev
Please add a note about the motivation in your README:

Why did you wrote the module?
Which problems do you try to solve?
What are you doing differently compared with X?

i think it's all about readability and maintainability, mocha-param for example is more readable than dynamically testing.
 **tests.forEach(function(test) {**     it(**'correctly adds ' + test.args.length + ' args'**, function() {       var res = **add.apply(null, test.args);**       assert.equal(res, test.expected);     });   });
we should think that although this solves a problem, it can be improved

Any way to do something like it.only and it.skip with (one particular instance of) a parameterized test? For me, that would be the only reason for using a helper package rather than dynamically generating tests.

@binduwavell @timaschew
Just my two cents, but coming from the Python world the syntax proposed in https://mochajs.org/#dynamically-generating-tests looks very poor to me:

The parameters must be retrieved through the test variable while in fact they should just be function parameters
Each tests entry must contain an object with key:value for each parameter. This makes the initial parametric data way more verbose than it should.
The test function itself (the one passed to it(...) has zero parameters which is not very explicit and readable

describe('add()', function() {
  var tests = [
   // See 2., extra key and values just for re-defining function parameters.
    {args: [1, 2], expected: 3},
    {args: [1, 2, 3], expected: 6},
    {args: [1, 2, 3, 4], expected: 10}
  ];

  tests.forEach(function(test) {
    it('correctly adds ' + test.args.length + ' args',
      // See 3., no parameters to this function. Except it does have some
      function() {
      // See 1., cannot directly use `args` as a variable, need to go through `test.args`
      var res = add.apply(null, test.args);
      assert.equal(res, test.expected);
    });
  });
});

An (hypothetical) syntax that I would find superior would be:
describe('add()', function() {
  var tests = [
    // values, expected
    [[1, 2],  3],
    [[1, 2, 3],  6],
    [[1, 2, 3, 4], 10]
  ];

  using(tests).it('correctly adds with args', function(values, expected) {
      var res = add.apply(null, values);
      assert.equal(res, expected);
    });
  });
});


launch.json - add option for logging stdout/stderr to file

My application dumps useful information to stdout / stderr when I run it. When debugging, I'd like to be able to copy this to a file automatically, rather than need to use some wort of wrapper script that calls tee, copy-paste from the output console, or run separately to capture this. There may well be an existing workaround, but as this is quite a simple and I imagine commonly useful feature request, I think it would be nice to add support for it on its own.
I'd propose adding an option similar ot this to launch.json, most likely keeping it simple as it's a pretty trivial addition:
// ...
configurations: [{
    "name": "Foo",
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}/main",

    // ...
    "log": {
        "stdout": "/path/to/file.out"
        "stderr": "/path/to/file.err"
        "stdin":  "/path/to/file.in" // Optional - capture anything typed into the run console.
     }
    // ...
        },
// ...

@stellarpower in theory this feature request sounds simple to implement but in reality it is difficult.
The problem is that VS Code knows nothing about "stdout/stdin/stderr" of the debuggee because only the debug extension controls the debuggee and "knows" if it supports "stdout/stdin/stderr" and whether it is possible to redirect "stdout/stdin/stderr" to/from a file.

Thanks for the fast response!
Afraid I'm not sure I understand, what do you mean by if the debuggee supports stdout/stdin/stderr? Every process forked ought to have at least these file descriptors opened I believe.
Presumably for any extenson being used to debug, if it outputs something to the integrated console as part of this it'd need to get access to the console in the same way as a different extension, wouldn't it?

@stellarpower VS Code does not know anything about "forked processes". It is the debug extension that might fork things. But when debugging Javascript running in a browser, or when attaching a debugger to an already running process, there is no need to "fork a process" and as a consequence there is nothing like "stdout/stdin/stderr".
If a debug extension starts a debuggee in the integrated terminal (or external terminal), then debuggee's "stdout/stdin/stderr" are managed directly by the integrated terminal's shell. In this case not even the debug extension sees the input/output "stdout/stdin/stderr". Only if the debuggee is launched in the debug console, has the debug extension a chance to see the stdout/stderr (but not even stdin).

So, in that case, would it be possible to wrap the shell that is running in the integrated or external terminal? Ultimately for text to appear in the terminal for the debugging process, it must have access to a stream at this point. I think dumping that would be sufficient to achieve this goal, although granted there may be many steps inbetween that make it ugly to perform in code itself.
17 Jan 2022 16:27:42 Andre Weinand @.***>:

@stellarpower[https://github.com/stellarpower] VS Code does not know anything about "forked processes". It is the debug extension that might fork things. But when debugging Javascript running in a browser, or when attaching a debugger to an already running process, there is no need to "fork a process" and as a consequence there is nothing like "stdout/stdin/stderr".
If a debug extension starts a debuggee in the integrated terminal (or external terminal), then debuggee's "stdout/stdin/stderr" are managed directly by the integrated terminal's shell. In this case not even the debug extension sees the input/output "stdout/stdin/stderr". Only if the debuggee is launched in the debug console, has the debug extension a chance to see the stdout/stderr (but not even stdin).
—
Reply to this email directly, view it on GitHub[https://github.com/microsoft/vscode/issues/140859#issuecomment-1014713770], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABGF2APHAGPMWCUWVWMILMDUWQ7P3ANCNFSM5MEXVAMQ].
You are receiving this because you were mentioned.
[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAAAArSURBVHic7cEBDQAAAMKg909tDjegAAAAAAAAAAAAAAAAAAAAAAAAAAA+DFFIAAEctgHwAAAAAElFTkSuQmCC###24x24:true###][Tracking image][https://github.com/notifications/beacon/ABGF2AJWHPR4UUAUVUDJNQTUWQ7P3A5CNFSM5MEXVAM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHR5U3KQ.gif]

Yes, the command that is used to run the debuggee in the shell could redirect "stdout/stdin/stderr". But this command is an implementation detail of the debug extension and not controlled by VS Code, so VS Code can not support this generically. So only the debug extension could implement this.
What makes things complex on that front is the fact that for many debuggers the debuggee is not directly launched in the shell but indirectly from within a command line debugger like "gdb". Redirecting "stdout/stdin/stderr" of the "gdb" does not help redirecting "stdout/stdin/stderr" of the debuggee.