Implement a custom __repr__

          No, the following expression must be true, which it is not: `eval(repr(repository)) == repository`.

Please use the default methods from dict for the time being. In the future, we can look into implementing true __repr__ which would provide true serliaization functionality if it is necessary. See https://docs.python.org/3/library/functions.html#repr
Originally posted by @tdstein in https://github.com/posit-dev/posit-sdk-py/pull/300#discussion_r1834855089

Ideas:

Use the dict's repr method

     def __repr__(self) -> str:
          items = super().items()
          args = ", ".join(f"{k}={repr(v)}" for k, v in items)
          return repr(f"ApiDictEndpoint({repr(self._ctx)}, {repr(self._path)}, {args})")

ApiDictEndpoint({}, '/me'<EMAIL_ADDRESS>username='barret', first_name='Barret', last_name='Schloerke', password='', user_role='publisher', created_time='2018-04-25T19:03:10.669201Z', updated_time='2024-10-31T16:06:54.43695Z', active_time='2024-11-08T21:30:01.62323Z', confirmed=True, locked=False, guid='123', privileges=['add_vanities', 'publish_apps', 'remove_vanities'])

Notes:

Should this also be applied to Context or other classes? Currently its repr is {}. Suggested change which inherits from object as dict isn't leveraged:

class Context:
    session: requests.Session
    url: Url
    _version: str

    def __init__(self, session: requests.Session, url: Url):
        self.session = session
        self.url = url
        # self._version is retrieved on demand of `.version` property

    @property
    def version(self) -> Optional[str]:
        try:
            return self._version
        except AttributeError:
            endpoint = self.url + "server_settings"
            response = self.session.get(endpoint)
            result = response.json()
            value = self._version = result.get("version")
        return value

    @version.setter
    def version(self, value):
        self._version = value

My understanding is that implementing __repr__ is only necessary when supporting serialization/deserialization is necessary. However, according to the Python documentation, it should be implemented whenever possible.
side note; using class variables this way is incorrect.
class Context:
    session: requests.Session
    url: Url
    _version: str

This implies that these variables are shared across all instances of the class. Since we support creating multiple Client instances (see the cookbook on blue/green deployments), we need to create multiple instances of Context with different session and URL values.

Thinking through this a bit more. I'm not convinced implementing repr in this way is worth the effort. My opinion is that the current implementations using dict, and the implementation on ActiveSequence is sufficient for the purposes of serialization. For example, someone wants to query a list of users from Connect and then serialize the information for later. When deserializing, do they need instances of Users? Or is the list of dictionaries is enough? I would argue the list of instances is enough for any downstream uses cases.

Thanks for all the context and details here. Very much agree that if there's doubt about if we'll need it, we should continue to build out the SDK so that we can gather more experience + information on if it's needed.

When deserializing, do they need instances of Users? Or is the list of dictionaries is enough? I would argue the list of instances is enough for any downstream uses cases.

I might not be following but in the last sentence here did you mean list of dictionaries instead of list of instances?

I might not be following but in the last sentence here did you mean list of dictionaries instead of list of instances?

Yes, I meant "list of dictionaries". Sorry about that.


Trace skb with fragments.

Some NIC driver may also put packet header(IP/TCP header) in skb non-linear area(frags).
in this case, packet related information(e.g. IP/port) cannot be retrieved from linear data area.
bpf_skb_load_bytes() can load packet data in fragments, however, it only works in tc/sk_filter/lwt bpf progs and fail verification in kprobe.
Since pwru use kprobe, do u have any plan or idea about supporting tracing fragmented skb in pwru?
Thanks

We would need to track fragments in a BPF map. Not sure what an entry function would be good for that.


description that sort orders the 'key' tensor numerically

This is sort of borderline, but I had to google around for 15-20 minutes to find this information, passing through:

thrust doc: https://github.com/thrust/thrust/wiki/Quick-Start-Guide#sorting (which states that sort is based on key values, in alignment with behavior in standard library)
c++ doc: http://www.cplusplus.com/reference/map/map/ (which states that default sort on a map is based on the key values)

Intuitively, I was expecting sort to be by value.
(Edit: sort works on cltorch now :-D )

Thanks Hugh!


reuqest Model for semantic segmentation tasks

I have carefully studied the [linear head weights] model in redme and the eval/linear.py in the project It seems that the pre-trained weights anyhow need to continue training a linear_classifiers in eval/linear.py, is this the case? Is there a published pre-trained model for the semantic segmentation task?

#55

We are not publishing the heads or models for semantic segmentation at this time. Closing this task, but we are keeping track of the demand in #55.

We are not publishing the heads or models for semantic segmentation at this time. Closing this task, but we are keeping track of the demand in #55.

thanks，got it.keep study

We have just added the models and supporting code for semantic segmentation.


chore(deps): update

Coverage remained the same at 100.0% when pulling 67eac91c9e9697436a4bab5c411b47f6ca96d243 on deps into aa006b7edfcfada6ee0ff71352f992ef03b65f08 on main.

:tada: This PR is included in version 2.0.3 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


GLES3 environment light did not work as it should be [macOS, Intel driver bug]

Godot version:

3.2.2 stable
OS/device including version:

Device: 2013 late Macbook Pro 13-inch with  Intel Iris Graphics(No Discrete Graphics), OS: macOS 10.13.6
Issue description:

when use GLES3, the environment light looks weird

here is the GLES2 with default environment setting

PS: right now I am not sure is this OS driver bug(because I can't test it on macOS 10.15) or GLES3 bug

i have this problem since 3.2.x version, but I can't remember the exactly version it is

ok, I just download some preview version to test, this problem is from 3.2.0 beta2
3.2.0 beta1 is fine

3.2 beta 1 is 077b5f6c2c06bb2c0af525ee25f87e0db719f9d2, and 3.2 beta 2 is b7ea22c5d203da1b592a743a4c893de25cd34408.
Relevant changes to drivers/gles3:
$ git log 077b5f6c2c06bb2c0af525ee25f87e0db719f9d2..b7ea22c5d203da1b592a743a4c893de25cd34408 -- drivers/gles3
commit 203fb1b3484f621984e4595986cc77c9b9174d6a
Author: Clay John<EMAIL_ADDRESS>Date:   Thu Nov 21 07:44:09 2019 -0800

    Fix GL error by properly using float uniform

commit 4d6737ec730a1f620c20768c1792099683aca4f3
Author: Clay John<EMAIL_ADDRESS>Date:   Wed Nov 20 22:54:44 2019 -0800

    Fix bugs introduced by IBL fixes

commit 3be6e76f220f702d41ae5efc526064f87059539b
Merge: 1bd32388ae cd40154890
Author: Rémi Verschelde<EMAIL_ADDRESS>Date:   Wed Nov 20 08:45:53 2019 +0100

    Merge pull request #33668 from clayjohn/Fix_environment_mapping_issues

    Fix issues with environment mapping

commit cd40154890ba9791b219d66beaf187a7d8dcdba5
Author: Clay John<EMAIL_ADDRESS>Date:   Sat Nov 16 16:56:34 2019 -0800

    Fix issues with environment mapping

commit 6536105af26bb3a6a18369b4647ac479816090b7
Merge: cc3b7d2ee2 1253a33423
Author: Rémi Verschelde<EMAIL_ADDRESS>Date:   Tue Nov 19 09:36:30 2019 +0100

    Merge pull request #33527 from clayjohn/GLES2-bufferdata_optimization

commit 203fb1b3484f621984e4595986cc77c9b9174d6a
Author: Clay John<EMAIL_ADDRESS>Date:   Thu Nov 21 07:44:09 2019 -0800

    Fix GL error by properly using float uniform

commit 4d6737ec730a1f620c20768c1792099683aca4f3
Author: Clay John<EMAIL_ADDRESS>Date:   Wed Nov 20 22:54:44 2019 -0800

    Fix bugs introduced by IBL fixes

commit 3be6e76f220f702d41ae5efc526064f87059539b
Merge: 1bd32388ae cd40154890
Author: Rémi Verschelde<EMAIL_ADDRESS>Date:   Wed Nov 20 08:45:53 2019 +0100

    Merge pull request #33668 from clayjohn/Fix_environment_mapping_issues

    Fix issues with environment mapping

commit cd40154890ba9791b219d66beaf187a7d8dcdba5
Author: Clay John<EMAIL_ADDRESS>Date:   Sat Nov 16 16:56:34 2019 -0800

    Fix issues with environment mapping

I tried on two mac with macOS Catalina 10.15.5
The first one use an IGPU (Intel Iris 1536): I have the same issue
The other use an AMD card (Radeon Pro 560x): no issue

I tried on two mac running macOS Catalina 10.15.5
The first one use an IGPU (Intel Iris 1536): I have the same issue
The other use an AMD card (Radeon Pro 560x): no visible issue (BUT maybe there is also one, view issue below)
This issue seems (partly) linked: https:#39952

right now it looks like this issue only appear on Mac with Intel GPU, I guess

I tested issue on a laptop with intel 3000HD on Windows7, but that laptop is too old. even using GLES2, environment light wouldn't lighting the scene and mesh is totally black

That sounds like a separate issue.  You should file a bug report for it.

@name-here There's already an issue about that, so please don't open a new one :https://github.com/godotengine/godot/issues/25512

update: occasionally I adjusted the metallic of the material and found that the result seemed to look very similar to the GLES2 render, also I adjusted background energy to make it more similar

default GLES3 render

GLES3 render after adjusting

default GLES2 render

Closing in favor of https://github.com/godotengine/godot/issues/55754, which is more up-to-date.


Modify makefile to use incremental compilation

Use incremental compilation to speed up development time

Closing as we've pushed this upstream


NextAuth GitHub integration throws an error - refresh_token_expires_in missing in Prisma schema

Describe the bug
When you scaffold a project with NextAuth and Prisma. Setting up the env file and using the GitHub provider throws an error as the Prisma Account schema is missing the refresh_token_expires_in field. The NextAuth docs page suggests adding it to the schema.
Exact error message:
Unknown arg `refresh_token_expires_in` in data.refresh_token_expires_in for type AccountUncheckedCreateInput.

To Reproduce
Steps to reproduce the behavior:

Scaffold a new project
Select NextAuth & Prisma
Setup GitHub credentials in the env file
Use this snippet:

import { signIn } from "next-auth/react"

export default function Component() {
  return <>
    <button onClick={() => signIn()}>Sign in</button>
  </>
}

Sign in with GitHub
See the error in the log

Expected behavior
The sign-in should succeed.
The default GitHub integration throwing an error can be confusing for someone new to NextAuth. I'm happy to create a PR and add the field to the schema if it makes sense. If we don't want to change the default Schema for NextAuth, it might make sense to explore another default provider instead of GitHub.

I think Discord is a good idea.

For anyone seeing this error like me when trying github provider: you basically need to extend Account schema in schema.prisma:
model Account {
    id                String  @id @default(cuid())
    userId            String
    .....
    refresh_token_expires_in Int <<< Added new to provide github support
}

I tested with only Github provider and it works, not sure with multiple providers.


Update project

@alexsuter I didnt update this repo because I saw version 9.4.4 in the market so I thought it was updated 😳

ok good enough. as loong as the ci build on github is running.

fyi @ivy-rew

we really should re-enforce a solution to get build feedback for our market repos --> github-monitor :smiley:
otherwise we will forget repos and produce failing pipelines frequently.


MariaDB Stable Chart - does not reliably restart after laptop sleep when on minikube

Bug report
Version of Helm and Kubernetes:
helm version

Client: &version.Version{SemVer:"v2.8.0", GitCommit:"14af25f1de6832228539259b821949d20069a222", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.0", GitCommit:"14af25f1de6832228539259b821949d20069a222", GitTreeState:"clean"}

minikube version
minikube version: v0.24.1

Which chart:
mariaDB/Stable
mariadb-2.1.3.tgz
What happened:
MariaDB POD was running on K8s under minikube on a MacBook.    Laptop was closed and minikube VM went into sleep mode.
Upon reopening the laptop, minikube was manually restarted.   MariaDB POD refused to start due to errors in the initContainer.
What you expected to happen:
clean restart with persistent data from volume
How to reproduce it (as minimally and precisely as possible):
see above
Anything else we need to know:
still researching.   I may post a PR if I can reliably avoid the issue.

/remove-lifecycle stale

/remove-lifecycle stale


fix(deps): update terraform github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi to v1.1.0

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vsi
module
minor
v1.0.4 -> v1.1.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox. ⚠ Warning: custom changes will be lost.

This PR has been generated by Renovate Bot.

Autoclosing Skipped
This PR has been flagged for autoclosing, however it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error.


Enables extra parameters to be passed to the model load function.

Summary:
When someone trains a model using a GPU and then tries to this model on a machine with CPUs only. They are presented with the following error message
RuntimeError: Attempting to deserialize object on a CUDA device but torch.cuda.is_available() is False. If you are running on a CPU-only machine, please use torch.load with map_location=torch.device('cpu') to map your storages to the CPU.

If one specifies the following:
MODEL_FILENAME_DICT[model_name].load_from_checkpoint(f"{path}/{model}",  map_location=torch.device('cpu'))

The error is remedied.
This PR generalizes the error above, by allowing users to pass additional arguments to the load_from_checkpoint to avoid such complications.
See also the slack conversation https://nixtlacommunity.slack.com/archives/C031M8RLC66/p1692912462083859
for more details.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.


Support to Regtest Address

Details: https://github.com/orgs/LNP-BP/discussions/128

Codecov Report

Merging #61 (a732a1a) into master (a403e25) will decrease coverage by 0.0%.
The diff coverage is 0.0%.

@@           Coverage Diff           @@
##           master    #61     +/-   ##
=======================================
- Coverage     0.1%   0.1%   -0.0%
=======================================
  Files          40     41      +1
  Lines        3186   3318    +132
=======================================
  Hits            3      3
- Misses       3183   3315    +132

Impacted Files
Coverage Δ

cli/src/command.rs
0.0% <0.0%> (ø)

cli/src/main.rs
6.7% <0.0%> (-3.3%)
:arrow_down:

cli/src/opts.rs
0.0% <0.0%> (ø)

rpc/src/client.rs
0.0% <0.0%> (ø)

rpc/src/error.rs
0.0% <0.0%> (ø)

rpc/src/lib.rs
100.0% <ø> (ø)

rpc/src/listen_addr.rs
0.0% <0.0%> (ø)

rpc/src/messages.rs
0.0% <0.0%> (ø)

rpc/src/service_id.rs
0.0% <0.0%> (ø)

src/automata.rs
0.0% <ø> (ø)

... and 49 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Is it that AddressCompat doesn't support regtest? If not, it should - since it is a part of the address string; and I will look how to update it first.
AddressCompat provides stronger guarantees that the address, once parsed, is supported by the wallet, that is why it is used here

Is it that AddressCompat doesn't support regtest? If not, it should - since it is a part of the address string; and I will look how to update it first.
AddressCompat provides stronger guarantees that the address, once parsed, is supported by the wallet, that is why it is used here

Hi @dr-orlovsky,
I reverted the change add created a new PR related:

https://github.com/BP-WG/descriptor-wallet/pull/64

Please see my comments in https://github.com/BP-WG/descriptor-wallet/pull/64#issuecomment-1326431925
We need to decide upon that problem first


Compatibility issue with Your Tokens Visible

Repost from https://github.com/David-Zvekic/TokensVisible/issues/21
Using Drag Ruler (v1.7.7) on Foundry 0.8.8, and Your Tokens Visible (v2.5.2) with the option for walls to cancel animation checked.
As a GM when you drag a token over a wall the animation is cancelled, but the ruler that appears when you drag the token is visible for the duration that the actual move would have taken.
If you right click while the token is moving, the drag ruler disappears and from that moment onwards, for the selected token the drag ruler vanishes as intended (now and then when you pick up the token and move it a bit fast the movement is not registered at all though as a side issue).
If you choose another token at any point or deselect the first token, the same issue appears again and so on.
In the video the aforementioned behaviour is shown and just before I start moving the tokens around rapidly, I have right clicked to make the drag ruler template disappear faster.
https://user-images.githubusercontent.com/7237090/125338981-c78d2a80-e348-11eb-949a-65232a0033cf.mp4
Quoting Tokens Visible module owner:

I would report this issue to Drag Ruler.
Drag Ruler draws and erases the ruler, not YTV.
Drag Ruler should probably wrap Token.prototype.setPosition if it wants to
guarantee that the duration of the ruler rendering always matches the
duration of the animation rather than assuming a duration.
After setPosition returns then the animation is complete.

This bug does also occur in "Your Tokens Visible" when Drag Ruler is disabled when moving the token via Measure+Spacebar, meaning Drag Ruler doesn't have anything to do with this bug occuring.


for iced_layershell binding to be published and be usable

this make it can be used with iced
still need to be done

[x] hover event
[ ] keyboard event
[ ] fractal scale
[ ] ime
[ ] virtual keyboard

other things

[x] example, like set anchor, set size, move it in eight corners. such kind example

finally

[ ] use this crate make a layershell launcher with iced

etc

[x] bind ext-session-shell with the same way

if want to finish keyboard, please take https://github.com/rust-windowing/winit/blob/master/src/platform_impl/linux/common/xkb/keymap.rs as reference

https://github.com/waycrate/exwlshelleventloop/blob/master/layershellev/src/lib.rs#L875
here need to add a event to check scroll event, and passed it to iced

Cannot register subscription listen to event

Hey, I'm looking forward into using layer-shell + iced too. Maybe I can help you in some way? Unfortunately I have little (no) experience in how this protocol works and how it relates to iced, maybe you can shine some light on it for me? I would appreciate if you could tell me how it works and what can I do. Cheers

Hey, I'm looking forward into using layer-shell + iced too. Maybe I can help you in some way? Unfortunately I have little (no) experience in how this protocol works and how it relates to iced, maybe you can shine some light on it for me? I would appreciate if you could tell me how it works and what can I do. Cheers

Thank you for your reply!! I think you can help read the xkb implement in winit. Now the keyboard event handled by iced-layershell is not full. You can see this pr https://github.com/waycrate/exwlshelleventloop/pull/9 and related code is in https://github.com/rust-windowing/winit/tree/master/src/platform_impl/linux/common

Hey I think that's too complicated for me (for now at least). Maybe I'll come back to it later. Good luck on your work!

Mouse should handle right and left.. now the logic thought that them are all left button

@sundaram123krishnan can you help impl text-input-v3 in layershellev?


Greenkeeper/ts jest 23.10.5

Coverage remained the same at 96.296% when pulling 265db0fd77075a53c4c53b26a288d6d086995b94 on greenkeeper/ts-jest-23.10.5 into 865e49df4297968f1afe5f6c67b045a1a8083e4f on master.


Code First Missing foreign key in generated migration

Their is a bug in Entity Framework 6 when generating migratiion code foreign key in certain heirarchy situatuin. I have the following heirarchy
Base
Child1                               Child2                     Child3
Child11                             Child22
public class LinkTable
{
public int Id{get;set;}
public Child1 {get;set;}
public Child2{get;set;}
public Child3{get;set;}
}

All above heirarchy is created using TPC
The generated migration code will not generate foreign keys for Child1 or Child2, but will generate foreign key for Child3
Is this a bug or am i missing something

This is by design. The reference to Child3 will always be to a row in the Child3 table - which can be represented with an FK constraint in a relational database. However, the relationship to Child2 could be pointing to a row in the Child2 or Child3 table - which can not be represented with an FK constraint. Same for Child1, it could be a row in Child1, Child2, or Child3 table.
EF still treats it as a relationship, it just can't create an FK constraint in the database to represent the relationship.


Better Overview about Data in Sensor View during Simulation/Debugging

The sensor view should show its data in a more structured way. Each group of data should be collapsable ("-") and expandable ("+").
Proposal:

group: simulator data. The first 5 entries. Initially collapsed
group: sensor data. Everything else but variables. Initially expanded
group: variables. Initially expanded.

I'm interested to work on this issue. please Can you guide me so that I can make my first contribution to an open-source project?

fixed with "new" simulation


Consider using _MSVC_LANG to detect cpp version

Visual Studio has very conservative approach for macro __cplusplus. Even when used with /std:c++17 switch it still shows this:

So by fact Visual Studio will not use cpp17.h header without forcing value UTF_CPP_CPLUSPLUS  to 201703L. For windows it is better to use this:
#if (defined(_MSVC_LANG) && _MSVC_LANG >= 201703L)
//whatever
#endif

Related issue in transmission: https://github.com/transmission/transmission/issues/2256

I really don't want to chase compiler-specific corner cases.
Setting UTF_CPP_CPLUSPLUS to 201703L is the way to address the issue.


DISPLAY_BACKWARDS for sha256d

Is our usage of DISPLAY_BACKWARDS = true in the sha256d type correct?
In bip143 there is a test that includes
  hashPrevouts:
    dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
  = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37

This is displaying/parsing opposite to what our codebase does. Who is wrong, us or the BIP.
    let mut engine = sha256d::Hash::engine();
    let data = Vec::from_hex("fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000").expect("failed to parse hex");
    engine.input(&data);

    let got = sha256d::Hash::from_engine(engine);
    let want = sha256d::Hash::from_hex("96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37").expect("failed to parse prevouts hex");
    assert_eq!(got, want);

Fails with
  left: `0x37fd4e0b474311c336bafe81a703806e8db6a713672b71969b4e3d48c827b896`,
 right: `0x96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37`'

Firstly, hashPrevouts is not very interesting to display so it shouldn't matter much. I don't think we even expose it.
If we do expose it it should be a newtype, probably with DISPLAY_BACKWARDS = false.
I'm wondering if the raw hash types should even impl formatting traits (apart from Debug), maybe everything should be a newtype.

@tcharding it is the BIP that's "wrong", but this is because (as @Kixunil is hinting at) there isn't really any standardized way to write "a double sha256" without knowing more about what it is.

I'm wondering if the raw hash types should even impl formatting traits (apart from Debug), maybe everything should be a newtype.

This seems a bit extreme. If I could go back I think I'd make all the raw hash types implement Display in the natural way (lowercase hex, no reversing) and then make the reversedness a property of newtypes only. This would probably also simplify our reversing code and maybe avoid the DISPLAY_BACKWARD constant entirely.
But given that we have implemented sha256d Display to output hashes backward, and this is always the correct thing for Bitcoin types, and is probably behavior that people depend on for non-Bitcoin types, I think we should just leave it be.

Yeah, that makes sense. It might be interesting to provide cfg to turn it off (so not a cargo feature) so that people could inspect if they are accidentally relying on it but I'm not really sure how many people would want to.

FTR, in rust-miniscript we added a hash256 module that has display forward. https://github.com/rust-bitcoin/rust-miniscript/blob/master/src/miniscript/hash256.rs


[Bug] --seed parameter can't take 256-bit numbers

🐛 Bug Report
If you're offloading randomness during key generation then you might use account new --seed X. However, this X must be a decimal number and trying to give it a 256-bit decimal number produces an error.
seed=$(head --bytes 32 < /dev/urandom | xxd -p | tr -d '\n' | tr '[:lower:]' '[:upper:]')
snarkos account new --seed "$(echo "obase=10;ibase=16;$seed" | bc | tr -d '\\\n')"
error: Invalid value "38868010450269069756484274649022187108349082664538872491798902858296683054657" for '--seed <SEED>': number too large to fit in target type

Ideally --seed should just take arbitrary hex-encoded data instead.
Using a smaller seed space works but loses a great deal of security.

Thanks for the report :) indeed, we are using 64bit number for this argument. It should be fairly simple to add/modify a switch to take 32 bytes.
I can look into this a bit later, in the meantime if someone wants to contribute this sounds like a great first issue


[feature request] allow CIT to use holding entity's name

i would like to make a resource pack that changes the held item of other players based on their name. this would allow more variation in the tools/armor of other players without having to have them rename their tools.
for example, you could parse for the first letter and base the texture off that, so names starting with a-m would have texture 1, and players with n-z would have texture 2.

Added to planned features


add choice for downloading using animepahe

Add choice for downloading videos through aria2 or other external downloaders.
Since there is no progress bar while downloading, I cannot be sure whether the file is downloading. So, its better to add an external downloader option like aria2 or atleast a progressbar. And could you please make sure that whatever external downloader you add, it runs on termux?
Thanks for looking

Thanks @lelouchvibritannia1 for the idea. Regarding the progress bar, I'd say it's a nice to have feature. If you want to know the progress, you could run command watch ls -lh "<video_file>" to see the file size increasing. Hope this will help.


experience options(presentation) doesn't work when integrate express checkout client side

Description
I want to integrate express checkout using client side, try to set the pages in english, but it still always in chinese.
input_fields and flow_config works, but presentation not.
Here's my code in https://developer.paypal.com/demo/checkout/#/pattern/experience :

Affected browsers

[x] Chrome
[ ] Safari
[x] Firefox
[x] Edge
[ ] IE
[ ] Chrome Mobile/Tablet
[ ] Safari Mobile/Tablet
[ ] Web View / Safari ViewController
[ ] Other

Haven't try other browers.

Try setting locale at the button create like this doc notes.
Also use the language plus country locales. So en_US Rather than just US in your example.

Thanks for your reply.
locale in render() is work for the button, but iframe pages not help.
I found US is valid value for locale_code from  here. Try en_US too, nothing different.
Or is there any way to pass experience_profile_id when create?

Thanks for your reply.
locale in render() is work for the button, but iframe pages not help.
I found US is valid value for locale_code from  here.
Or is there any way to pass experience_profile_id when create?

locale in render() is work for the button, but iframe pages not help.

Can you elaborate on what you mean by this? Which page is not being displayed in en_US?

Sorry about my english.
I can Customize the Button by :
paypal.Button.render({
    ...
    // Specify the language displayed on your button
    locale: 'en_US',
   ...
}, '#myContainerElement');

But is not I want.
My problem is the PayPal checkout page always in chinese even my code set locale_code: "US" :
                experience: {
                    presentation: {
                        locale_code: 'US'
                    }
                }

Is the login page in chinese, or is this after you have logged in?

after login
Can it be forced to display english?

Normally after you log in, it will display the language set in your account. You should be able to change that preference in your account settings.

Thanks a lot.
I get it. Set the button in en_US, the login page will be correctly in english.

No problem!


Behavior of "closed" session/connections

I'm not sure I understand how "closing" an object (or the underlying requests.Session) works.
I added a test that I expected to fail. If the session is closed, I thought subsequent web requests could not be sent. I don't fully understand the requests internals, but is it possibly opening new connections, and close just shuts all existing, open connections?
@responses.activate
def test_cannot_use_closed_connection(collection):
    set_collection_response()
    collection.close()
    collection.refresh()

I did some poking around in the responses code, and I think the reason you aren't seeing an error is because that library changes behavior.  In requests, HTTP requests through a session are eventually propagated to a back-end "adapter".  Responses does a sneaky surgical replacement of a key method of the HTTP adapter, which bypasses the usual connection handling.  And that means you won't see the normal connection-related errors.  So I think certain tests just won't work when responses is mucking around with the innards of requests.

This test is also "failing" (not raising an error for the closed session, but getting a 404 when accessing the URL) for me. responses shouldn't be mucking around, unless it's because it's in the same file as responses.
def test_cannot_use_closed_connection():
    coll = Collection(COLLECTION_URL)
    coll.close()
    coll.refresh()

Well, I guess closing a session doesn't invalidate it after all.  I did a test directly with requests, and there was no error.  When you close a session, it closes all adapters, which for the HTTP adapter, "clears" its connection pools, which closes all their connections and disables the pools.  So at some level, something is getting disabled.  But I guess at the next request, the adapter just makes more pools.  So if we want _HTTPConnection to be unusable after a close(), I guess we'll have to implement that ourselves.

I don't think we need to worry about explicitly making things unusable. I'm curious how commonly people will use the close() functionality, though I do like the context manager behavior.

Hello. I'm trying to close a Collection connection after I make some queries, but it seems unable to. I tried to .close() then .refresh() but it seems that that connection is still up after that.
Shouldn't this close the connection, or have I understood something wrong ?
I'm trying to create a context manager for taxii client connections, but I'm struggling as you can see. I already read the other issues but with no luck.
Thanks in advance for your time.

As described above, close() does close existing connections, but it doesn't prevent subsequent connections.  refresh() sends another request, so it makes another connection.  This is just how the requests library works (at least as of 2017!  I have not looked again since then).  So it's not that the old connections haven't gone after a close(); it's just that new connections have been made.  As described above, it was not deemed important to design the taxii-client library to force failure of subsequent network operations after a close().
So your test isn't testing what you want it to.  You want to know whether there are any remaining connections after a close().  I think you will have to verify that in other ways, e.g. use OS tooling to check network connections.  Maybe try netstat to get a listing of TCP client connections and the remote hosts they are connected to, and see if any look like they shouldn't be there.


Support line wrapping when there is no space available for word wrapping

Describe the solution you'd like
Support line wrapping when there is no space available for word wrapping:

Environment

Walrus version: main e92cde6256262c9671c9d51475f0bee8669f6628
UI version: dev-606a1a9

Test Result: Failed, and the position of the scrollbar seems a bit odd.

Environment

Walrus version: main e92cde6256262c9671c9d51475f0bee8669f6628
UI version: dev-606a1a9

Test Result: pass


Fix associativity in build.sh desync check

Coverage remained the same at 82.641% when pulling 18883e9b03cbd46c9705c74057b90bcd4db0c6fe on xiphmont:silly into 06c8bda12f96a2602b490dd25477c8514f79cf07 on xiph:master.


Cardano-perf Regression: Status Quo

This is the 2nd patch in the Cardano perf regression project. Its meant to test the hypothesis that 9.2 is under-specializing. It marks all exported functions in Cardano.Ledger.Address as INLINEABLE and uses module level flags to let GHC specialize more aggressively.
NOTE
This is not intended to be merged. This patch is intended to be tested on either db-analyzer or beacon. cc @dnadales

I've decided to forgo the True Baseline patch. This patch regression the benchmarks in cardano-ledger-core so much that I deemed it wasn't worth to test it further.

I'll close this PR as stale.
FYI, I ran a simple benchmark of decoding bunch of random addresses on this approach and showed a 20% slowdown.
In any case, we might continue the investigation, but I don't want those stale unmergable PRs hanging around.


net: can {Conn,PacketConn}.Close block?

The documentation for net.Conn.Close is:

Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors.

However, it does not mention anything about whether Close itself can block.
Some net.Conn implementations have an implicit write buffer. Thus, when Close is called, it still needs to flush the buffer before returning. This means that Close is effectively an operation that involves IO. Since it involves IO, this means that Close may have to wait until the recipient acknowledges the incoming data (which could potentially be forever if the receiver's read buffer is full).
If we extend the documentation for net.Conn.Close, would the following be reasonable?

Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. Close itself may block while it is flushing any internal write buffers, but must return an error and terminate the connection  when a previously set write deadline is exceeded.

\cc @bradfitz @mikioh

For reasons that I can't understand, I'm not able to get TCPConn.Close to block even when I write as much data on one endpoint while nothing is reading on the other endpoint.
In other implementations I'm looking at, it is impossible to get Close to be non-blocking since the underlying layers provide no control over flushing and have implicit write buffers built into them.

#10527 is for Listener.Close.

Yes, we've had to make changes to the net/http package in the past due to net.Conn implementations blocking on Close. If it's an interface, anything can happen. It's fine to document that it may block, if it's not overly wordy.

Is it possible or not that a TCPConn.Close() may block?

Scenario:
I have a "high concurrency" client on a payment processing solution under production which when it detects the connection might be dead (multiple concurrent errors on non blocking read() or write() calls) it enters a reconnect loop to different secondary backup servers until it gets able to keep processing transactions.
A couple of days ago the single threaded component handling de TCP socket I/O hanged out, watching the source code for hours i couldn't find a single blocking condition, suddenly i realized, might be Close() blocking?
Why i perform the Close call? because the underlying protocol (old credit cards processing protocol implementation) would send back responses on any opened detected socket, no matter in which socket it received the request.. so if i don't perform the correct TCP connection closure before establishing a new TCP connection i might get into an scenario were the responses for the requests sent through the new established socket might start getting back in the original connection once the networking issue gets solved.
So, the question made by @dunjut is really critical in my scenario. Is Close() candidate to block? I was really not expecting this condition to happen :(

You can have a blocking conn.Close by doing something like:
...
reader := bufio.NewReader(conn)
go io.ReadFull(reader, buf)
conn.Close()

@dsnet Did you create a PR for it?

That's it, I call it a day. Can we fix it?

I finally solved it, thanks to https://stackoverflow.com/questions/28967701/golang-tcp-socket-cant-close-after-get-file, call conn.CloseRead() before calling conn.Close().
func Close(conn io.Closer) error {
	type ReadCloser interface {
		CloseRead() error
	}
	var errs []error
	if closer, ok := conn.(ReadCloser); ok {
		errs = append(errs, closer.CloseRead())
	}
	errs = append(errs, conn.Close())
	for _, err := range errs {
		if err != nil {
			return err
		}
	}
	return nil
}

Can this issue be closed?


Hiperdex: Updated domain

Checklist:

[ ] Updated extVersionCode value in build.gradle for individual extensions
[x] Updated overrideVersionCode or baseVersionCode as needed for all multisrc extensions
[ ] Referenced all related issues in the PR body (e.g. "Closes #xyz")
[ ] Added the isNsfw = true flag in build.gradle when appropriate
[x] Have not changed source names
[ ] Have explicitly kept the id if a source's name or language were changed
[ ] Have tested the modifications by compiling and running the extension through Android Studio
[ ] Have removed web_hi_res_512.png when adding a new extension

Why are you make duplicate PR?
#5766? Which one is the most correct? And didn't check for Have tested the modifications by compiling and running the extension through Android Studio making me increasingly suspicious that you just did this haphazardly without trying it in Android Studio first.


Malicious test causes gradle build to succeed despite test failure

Currently it is possible to write a Java unit test case (with TestNG - not sure if JUnit is also affected) that will make all other test cases skip and will result in a successful build. Despite the lack of execution of the skipped tests this might be used to poison build caches or add malicious code to repositories that rely on gradle build status.
I only managed to reproduce the problem using JMock and the problem is probably also related to TestNG, but gradle should ensure proper build results even if some components don't behave well.
Expected Behavior
Gradle build should fail for whatever reason tests during the build might fail.
Current Behavior
After adding the below EvilTest to any project. The test execution is aborted on executing EvilTest and all tests after EvilTest are skipped. This stacktrace is printed to console but nevertheless the gradle build finishes with status success!
Unexpected exception thrown.
org.gradle.internal.remote.internal.MessageIOException: Could not read message from '/<IP_ADDRESS>:50488'.
        at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:94)
        at org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:270)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.lang.ClassCastException: cannot assign instance of org.gradle.internal.serialize.TopLevelExceptionPlaceholder to field org.gradle.internal.serialize.ExceptionPlaceholder.toStringRuntimeExec of type java.lang.Throwable in instance of org.gradle.internal.serialize.TopLevelExceptionPlaceholder
        at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2291)
        at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2254)
        at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1473)
        at java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2556)
        at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2463)
        at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2235)
        at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1712)
        at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:519)
        at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:477)
        at org.gradle.internal.serialize.Message.receive(Message.java:53)
        at org.gradle.internal.serialize.BaseSerializerFactory$ThrowableSerializer.read(BaseSerializerFactory.java:316)
        at org.gradle.internal.serialize.BaseSerializerFactory$ThrowableSerializer.read(BaseSerializerFactory.java:313)
        at org.gradle.internal.remote.internal.hub.DefaultMethodArgsSerializer$ArraySerializer.read(DefaultMethodArgsSerializer.java:72)
        at org.gradle.internal.remote.internal.hub.DefaultMethodArgsSerializer$ArraySerializer.read(DefaultMethodArgsSerializer.java:61)
        at org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.readArguments(MethodInvocationSerializer.java:128)
        at org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.read(MethodInvocationSerializer.java:123)
        at org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.read(MethodInvocationSerializer.java:102)
        at org.gradle.internal.serialize.kryo.TypeSafeSerializer$1.read(TypeSafeSerializer.java:36)
        at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:67)
        at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
        at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:81)

Context
I stumbled across this issue while writing a test for a spring AsyncHandlerInterceptor. The http request was mocked and also accessed in another object's toString() method. I was surprised that the build succeeded despite obviously missing expectations and wrong assertions.
Steps to Reproduce
I tried to reproduce the problem with plain Java (without JMock) but wasn't able to reproduce the exact behavior. I only managed to make the build run forever by throwing an exception with malicious toString() and printStackTrace(...) methods.
But adding the test below to a project will reproduce in 100% of the cases. It will cause all tests that are alphabetically after EvilTest to be skipped and the build will succeed despite test failure.
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.lib.concurrent.Synchroniser;
import org.testng.annotations.Test;

public class EvilTest {
    public static interface MockMe {
        public void expected(final ArgumentWithBadToString aArg);

        public String breakTest();
    }

    public static class ArgumentWithBadToString {
        private final MockMe mMockMe;

        public ArgumentWithBadToString(final MockMe aMockMe) {
            mMockMe = aMockMe;
        }

        @Override
        public String toString() {
            return mMockMe.breakTest(); // access to mocked instance in 'toString' causes test to abort
        }
    }

    public static class ClassUnderTest {
        private final MockMe mMockMe;

        public ClassUnderTest(final MockMe aMockMe) {
            mMockMe = aMockMe;
        }

        public void toBeTested(final ArgumentWithBadToString aArg) {
            mMockMe.expected(aArg);
            mMockMe.expected(aArg); // second call to 'expected' without matching Expectation will cause ExpectationError
        }
    }

    @Test
    public void breakGradleTestExecution() throws Exception {
        final Mockery mockery = new Mockery();
        mockery.setThreadingPolicy(new Synchroniser()); // using 'Synchroniser' seems to cause this particular problem
        final MockMe mock = mockery.mock(MockMe.class);

        mockery.checking(new Expectations() {{
            oneOf(mock).expected(with(any(ArgumentWithBadToString.class)));
        }});

        final ClassUnderTest cut = new ClassUnderTest(mock);
        cut.toBeTested(new ArgumentWithBadToString(mock));
    }
}

Your Environment
Windows 2019
Gradle 7.0.1
JMock 2.12.0
TestNG 7.4.0

@dpeger I can reproduce the problem you describe. What seems to happen in this "malicious" test is that an org.jmock.api.ExpectationError is thrown. For what reason, that's a JMock, not a Gradle concern.
Gradle indeed does not handle this situation well, ie. following tests are skipped and the build succeeded. But the same thing happens, if you don't use Gradle, for example if you run your tests in IntelliJ, with the JUnit runner.
Plus even the documentation of java.lang.Error starts with the statement that "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."
This doesn't seem to be an issue which requires fixing in Gradle.

I agree that this is a JMock or perhaps actually a TestNG concern. I think however gradle should ensure build failure on any kind of issue/error and not continue unnoticed and even finish successfully.
There are already several catch Throwable statements in ExceptionPlaceholder for a good reason. I was not able to investigate why this special kind of ExpectationError completely breaks the gradle messaging with TestNG but other Errors are handled correctly and make the build fail.
One can probably craft a special Exception that will make gradle break the same way without JMock or any other external dependency. As mentioned I was able to make gradle run indefinitely by throwing an Exception that itself throws errors on printStackTrace and toString. This could already be used to DOS a CI system. With a little more tweaking - once the reason for the problem in the gradle messaging is understood - making the build succeed despite test failures should not be much of a problem.


Procedural API doesn't work in Racket 6.0

Attempting to use it causes a syntax error.
$ racket --version
Welcome to Racket v6.0.1.
$ uname -a
Linux x61s 3.14.8-200.fc20.x86_64 #1 SMP Mon Jun 16 21:57:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ racket objective.rkt
Racket game library v0.6.0 loaded
$ racket procedural.rkt
procedural.rkt:9:9: rename-out: bad syntax
  in: (rename-out (class-out (graphics% make-graphics) show hide update get-width get-height set-cartesian set-document use-transformation use-scale use-rotation use-cartesian use-document set-brush/pen use-brush use-pen) (show show-graphics) (hide hide-graph...
  context...:
   /usr/racket/collects/racket/provide-transform.rkt:83:2: expand-export
   /usr/racket/collects/racket/private/reqprov.rkt:667:17: transform-simple
   /usr/racket/collects/racket/private/reqprov.rkt:663:2
   standard-module-name-resolver
$ racket examples/fireworks.rkt
procedural.rkt:9:9: rename-out: bad syntax
  in: (rename-out (class-out (graphics% make-graphics) show hide update get-width get-height set-cartesian set-document use-transformation use-scale use-rotation use-cartesian use-document set-brush/pen use-brush use-pen) (show show-graphics) (hide hide-graph...
  context...:
   /usr/racket/collects/racket/provide-transform.rkt:83:2: expand-export
   /usr/racket/collects/racket/private/reqprov.rkt:667:17: transform-simple
   /usr/racket/collects/racket/private/reqprov.rkt:663:2
   standard-module-name-resolver
   standard-module-name-resolver
   standard-module-name-resolver

It's been a while, but the procedural API has now been deprecated in favour of a new API. You can view the examples to get an idea of how it looks.
In the future, I'd be glad to provide a new procedural API which is generated from the existing classes and interfaces, but that's for another issue.


Ask About HttpContext.SetSessionStateBehavior

Summary
Our repo uses HttpContext.SetSessionStateBehavior which are not supported by ASP.NetCore and this adapters.
I want to ask if there is equivalent  and if there is plan to add them to adapter.
Motivation and goals
We need migrate code (an API in Sharepoint) to ASP.NetCore and we find that the APIs are not supported by ASP.NetCore.
In scope

HttpContext.SetSessionStateBehavior
HttpContext.SessionStateBehavior

From src code, It seems that the property is used to decide whether to acquire session state. But in the adapter, the session state is gotten from the feature.
I wonder if SetSessionStateBehavior is still needed.
Examples
Here is an example of HttpContext.SetSessionStateBehavior
if (IsDataAPI(context))
{
    context.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Disabled);
}

What's the context this is used in? We currently decide if session is enabled by the SessionAttribute as metadata on the endpoint. In order to enable this, we'll need a per-request flag that could be set and checked in the SessionMiddleware.

@twsouthwick The context is that, for specific url pattern, We don't want to use session state.
The thing which makes it complex is that, we don't use the ASP.NetCore endpoint, we use Microsoft.Owin to process the endpoints and wrap them in ASP.NetCore.
Do you have suggestions?

@Clounea What I would recommend is to add a new feature:
internal interface ISessionStateFeature
{
  SessionStateBehavior State { get; set; }
}

behavior should probably be:

If the state is set here, have it be surfaced
If no state is set via the feature, default to the existing endpoint metadata if it is available

The Sessionmiddleware will need to be updated to handle this change (i.e. use this feature rather than metadata)


Feature/input focus

Refactored and improved inputs

Can we please make the following adjustments to the SHOW button in order to optimize how the space within the input is being used?
Basically I think changing the button to the small variant will help the most, and maybe some small tweaks to spacing.  Below is an illustration of where the component is now, and where I'd like it to get.


Security warning with labs on docker

Vin, please address the security issues that are being flagged for the docker labs.

@rgward fixed with https://github.com/Microsoft/sqllinuxlabs/commit/d3776298ab42e6378ddbe80d93892714d2d21dda


Update README.md and esptool.py

Update README.md with more accurate flashing instructions. Update flash.sh script for using the new esptool.py syntax.

Please tell me which version of esptool.py you are using.
On my system it works fine with v2.2.
Also paste the terminal output, so that I can have a look at it.

I got it working, it was an issue on my end

On Nov 10, 2019, at 12:43 PM, Niccolò Izzo<EMAIL_ADDRESS>wrote:

Please tell me which version of esptool.py you are using.
On my system it works fine with v2.2.
Also paste the terminal output, so that I can have a look at it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Is it possible to change the homekit identification number to a different one from 111-11-111?

You can change it but then you need to use advanced folder and compile the bin file.
I would like to know myself how to compile the bin file from the source given in advanced folder if anyone knows.


[openssl] build failure

Host Environment

OS: win10

To Reproduce
Steps to reproduce the behavior:
vcpkg install openssl:x86-windows
Failure logs
PS C:\src> .\vcpkg\vcpkg install openssl:x86-windows
Computing installation plan...
The following packages will be built and installed:
    openssl[core]:x86-windows
  * openssl-windows[core]:x86-windows
Additional packages (*) will be modified to complete this operation.
Warning: The following VS instances are excluded because the English language pack is unavailable.
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
Please install the English language pack.
Detecting compiler hash for triplet x86-windows...
Starting package 1/2: openssl-windows:x86-windows
Building package openssl-windows[core]:x86-windows...
Could not locate cached archive: C:\Users\fuomag9\AppData\Local\vcpkg/archives\e4\e4b0aba05341c2e6678336165e562f7b8f19d93e.zip
-- Using cached C:/src/vcpkg/downloads/openssl-1.1.1g.tar.gz
-- Cleaning sources at C:/src/vcpkg/buildtrees/openssl-windows/src/openssl-1-bb2a9a5801.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/src/vcpkg/downloads/openssl-1.1.1g.tar.gz
-- Using source at C:/src/vcpkg/buildtrees/openssl-windows/src/openssl-1-bb2a9a5801.clean
-- Copying openssl release source files...
-- Copying openssl release source files... done
-- Configure x86-windows-rel
-- Configure x86-windows-rel done
-- Build x86-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:83 (message):
    Command failed: nmake -f makefile install_sw install_ssldirs
    Working Directory: C:/src/vcpkg/buildtrees/openssl-windows/x86-windows-rel
    Error code: 2
    See logs for more information:
      C:\src\vcpkg\buildtrees\openssl-windows\build-x86-windows-rel-1-out.log
      C:\src\vcpkg\buildtrees\openssl-windows\build-x86-windows-rel-1-err.log

Call Stack (most recent call first):
  ports/openssl-windows/portfile.cmake:99 (vcpkg_execute_required_process)
  scripts/ports.cmake:79 (include)

Error: Building package openssl-windows:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: openssl-windows:x86-windows
  Vcpkg version: 2020.06.15-nohash

PS C:\Users\fuomag9> cat  C:\src\vcpkg\buildtrees\openssl-windows\build-x86-windows-rel-1-out.log
        "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" /                   depend && "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" /                   _build_libs
        rc  /folibcrypto.res "libcrypto.rc"
PS C:\Users\fuomag9> cat  C:\src\vcpkg\buildtrees\openssl-windows\build-x86-windows-rel-1-err.log

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"rc" non Ã¨ riconosciuto come comando interno o esterno,
 un programma eseguibile o un file batch.
NMAKE : fatal error U1077: 'rc' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.

Are we STILL having issues building OpenSSL?

Warning: The following VS instances are excluded because the English language pack is unavailable.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
Please install the English language pack.

To use vcpkg on windows, you need Visual Studio with the Desktop development with C++ workload, Windows SDK 8.1 or later and the English language pack installed.
I believe rc is part of the Windows SDK.

installing the language pack fixed it, what a strange requirement tho


Route label is not respecting the settings to display id or description

Describe the Bug
Route label is not respecting the settings to display id or description; it always display the description when there is one
Steps to Reproduce the Bug or Issue

create a route
change settings to display id for nodes
select route and provide a description
click elsewheree so that changes are applied
--> the route label is using the description

Screenshots or Videos
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 0.30.0]

Also check for Containers!


Add Dropout and train_ch3()

Add Dropout from Chapter 4 of the book.
Also added train_ch3()  in d2l/train.py as in #4

Please note that I've run the notebook again to update the outputs.

Have squashed the commits. Is it ready to be merged?

Thanks! 👍


Establish a Blazor AOT topic

Coalesce the Tooling AOT guidance with the Host and Deploy AOT guidance into a new AOT topic.
This will be for mid-'24.

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

ID: fa3e99ba-cbe1-e8a1-6628-9b6eb39710a4
Version Independent ID: dd777362-b92d-cac6-2343-a7aaf31d0bdf
Content: Tooling for ASP.NET Core Blazor
Content Source: aspnetcore/blazor/tooling.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

Ooooooops! ... again! This was already opened at #30153.


Suggestions drawer does not scroll with screen content

Hi,
I have implemented this package into an Ionic hybrid app. Generally everything is great. However I have found that if the suggestions draw is open and the screen is scrolled (on both iOs and android devices) the drawer stays in the same position on the screen and the rest of the content scrolls. This in effect detaches the drawer from the input field.
Has anyone else had any issues with this on Ionic or otherwise? My gut feeling is that the

 is placed outside the <ion-content> so therefore Ionic doesn't scroll it.
Can I specify where the

 is placed on the page somehow? If I can specify it to be placed up the page and inside <ion-content>, I have a feeling it may fix my problem.
Cheers

@nrcrabbe did you manage to have it working properly with ionic? So far for me, when I tap the result on mobile, the popup with results disappears and data model is not populated with the data from Google. It only correctly on desktop when I select an element by keyboard.


BugFix fix modify partition's storage policy with different resource issue succeed with execption

Proposed changes
Issue Number: close #34229
when we try to modify a partition's storage policy which have different resource with the previous one, we get error message "currently do not support change origin storage policy to another one with different resource", but the modification same also succeed!
expect:
the modification fail with "currently do not support change origin storage policy to another one with different resource".


Move attachment into models/repo/

As title.

Code doesn't compile (due to merged refactoring code)

Code doesn't compile (due to merged refactoring code)

I think it's a CI problem.


Workaround: Skip receipt authenticity check DO NOT MERGE

Probably due to https://developer.apple.com/documentation/technotes/tn3138-handling-app-store-receipt-signing-certificate-changes# the call to SecKeyVerifySignature throws and error and leads to a receipt validation error.
This PR temporarily disables the call (for shipping a hot fix) until we implement a replacement for SecKeyVerifySignature .

Actual fix in the making: https://github.com/IdeasOnCanvas/AppReceiptValidator/pull/93


JFXTreeTableView Css Problem

I use tree-table-view class for JFXTreeTreeTableView like this :

but it dosen't change any thing in appearance.
stylesheets successfully loaded in Main Method :
scene.getStylesheets().add(Main.class.getResource("/view/resources/css/jfoenix-components.css").toExternalForm());

Hello,
well the "tree-table-view" style class is the default java class for tree table view, so there is not need to add it as a style class. also you need to provide more details about the css file you are loading otherwise it's hard to tell what's causing the issue.
Regards,


no more spotify working on both of my boxes with 1.1.8-rc2 & stretch

Bug
I can't play Spotify stuff at all, since a couple of days,
but local media mp3 is working still
What I did
tried to use new keys for mopidy,
What happened
nothing,
webinterface and everything works fine, but no audio from Sportify...
I think there is any kind of library or connection to spotify not supported anymore!?
Is there any chance to not set up a new system !?
Raspbian GNU/Linux 9 (stretch)
Phomiebox 1.1.8-rc2

sudo nano /var/log/mopidy/mopidy.log
there are lines with:
ERROR [520:SpotifyEventLoop] spotify.session: Spotify connection error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>

Could you try to play something from Spotify and afterwards post the results of tail -n 500 /var/log/syslog and tail -n 500 /var/log/mopidy/mopidy.log?

2020-02-26 10:19:58,030 INFO [530:MainThread] mopidy.config: Loading config from builtin defaults
2020-02-26 10:19:58,045 INFO [530:MainThread] mopidy.config: Loading config from /etc/mopidy/mopidy.conf
2020-02-26 10:19:58,052 INFO [530:MainThread] mopidy.config: Loading config from command line options
2020-02-26 10:19:58,218 INFO [530:MainThread] mopidy.main: Enabled extensions: iris, mpd, http, stream, spotify, m3u, softwaremixer, file, local-images, local
2020-02-26 10:19:58,219 INFO [530:MainThread] mopidy.main: Disabled extensions: none
2020-02-26 10:19:58,761 INFO [530:MainThread] mopidy.commands: Starting Mopidy mixer: SoftwareMixer
2020-02-26 10:19:58,767 INFO [530:MainThread] mopidy.commands: Mixer volume set to 30
2020-02-26 10:19:58,769 INFO [530:MainThread] mopidy.commands: Starting Mopidy audio
2020-02-26 10:19:58,775 INFO [530:MainThread] mopidy.commands: Starting Mopidy backends: SpotifyBackend, StreamBackend, M3UBackend, FileBackend, LocalBackend
2020-02-26 10:19:58,991 INFO [530:MainThread] mopidy.local.library: Loaded 79 local tracks using json
2020-02-26 10:19:59,023 INFO [530:Audio-2] mopidy.audio.actor: Audio output set to "alsasink"
2020-02-26 10:20:00,063 INFO [530:SpotifyBackend-3] mopidy_spotify.web: Logged into Spotify Web API as s2x3dnn2eedc78ckw8bar3sst
2020-02-26 10:20:00,065 INFO [530:SpotifyBackend-3] mopidy_spotify.backend: Started spotify backend
2020-02-26 10:20:00,074 INFO [530:MainThread] mopidy.commands: Starting Mopidy core
2020-02-26 10:20:00,203 INFO [530:Thread-10] mopidy_spotify.web: Loaded 1 playlists
2020-02-26 10:20:00,209 INFO [530:Thread-10] mopidy_spotify.utils: Refresh Playlists took 143ms
2020-02-26 10:20:00,562 INFO [530:MainThread] mopidy.commands: Starting Mopidy frontends: IrisFrontend, MpdFrontend, HttpFrontend
2020-02-26 10:20:00,566 INFO [530:IrisFrontend-12] mopidy_iris.core: Starting Iris 3.30.0
2020-02-26 10:20:00,571 INFO [530:MainThread] mopidy.mpd.actor: MPD server running at [::ffff:<IP_ADDRESS>]:6600
2020-02-26 10:20:00,581 INFO [530:HttpFrontend-15] mopidy.http.actor: HTTP server running at [::ffff:<IP_ADDRESS>]:6680
2020-02-26 10:20:00,582 INFO [530:MainThread] mopidy.commands: Starting GLib mainloop
2020-02-26 10:39:22,389 ERROR [530:SpotifyEventLoop] spotify.session: Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>
2020-02-26 10:39:22,395 INFO [530:SpotifyEventLoop] spotify.session: Spotify logged out
2020-02-26 12:39:05,507 INFO [530:MpdSession-16] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:06,538 INFO [530:MpdSession-17] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:07,348 INFO [530:MpdSession-18] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:26,922 INFO [530:MpdSession-19] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:27,014 INFO [530:MpdSession-20] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:27,503 INFO [530:SpotifyBackend-3] mopidy_spotify.lookup: Failed to lookup "spotify:album:6jbxhrzeRQ87glDoAmw42C": Session must be logged in and online to load objects: <ConnectionState.LOGGED_OUT: 0>
2020-02-26 12:39:27,534 INFO [530:MpdSession-21] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:28,048 INFO [530:MpdSession-22] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:28,105 INFO [530:MpdSession-23] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:29,380 INFO [530:MpdSession-24] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:29,432 INFO [530:MpdSession-25] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:29,583 INFO [530:MpdSession-26] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:46,326 INFO [530:MpdSession-27] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:46,366 INFO [530:MpdSession-28] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:46,391 INFO [530:MpdSession-29] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:46,444 INFO [530:MpdSession-30] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:46,525 INFO [530:MpdSession-31] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:51,326 INFO [530:MpdSession-32] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:51,332 INFO [530:MpdSession-33] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:51,406 INFO [530:MpdSession-34] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:51,423 INFO [530:MpdSession-35] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:51,520 INFO [530:MpdSession-36] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:56,875 INFO [530:MpdSession-37] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:56,884 INFO [530:MpdSession-38] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:56,963 INFO [530:MpdSession-39] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:56,969 INFO [530:MpdSession-40] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:39:57,134 INFO [530:MpdSession-41] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:01,880 INFO [530:MpdSession-42] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:01,885 INFO [530:MpdSession-43] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:01,965 INFO [530:MpdSession-44] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:01,969 INFO [530:MpdSession-45] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:02,061 INFO [530:MpdSession-46] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:06,876 INFO [530:MpdSession-47] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:06,881 INFO [530:MpdSession-48] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
2020-02-26 12:40:06,952 INFO [530:MpdSession-49] mopidy.mpd.session: New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 10:19:52 phonieboxisa mpg123[520]: Title:   1 Second of Silence             Artist: Anar Software LLC
Feb 26 10:19:52 phonieboxisa mpg123[520]: Comment:                                 Album:  Blank Audio
Feb 26 10:19:52 phonieboxisa mpg123[520]: Year:                                    Genre:  Unknown
Feb 26 10:19:52 phonieboxisa systemd[1]: Started OpenBSD Secure Shell server.
Feb 26 10:19:53 phonieboxisa mpg123[520]: [0:01] Decoding of startupsound.mp3 finished.
Feb 26 10:19:53 phonieboxisa systemd[1]: Started Lighttpd Daemon.
Feb 26 10:19:53 phonieboxisa systemd[1]: Started Phoniebox Startup Sound.
Feb 26 10:19:53 phonieboxisa systemd[1]: Started The PHP 7.0 FastCGI Process Manager.
Feb 26 10:19:53 phonieboxisa exim4[519]: Starting MTA: exim4.
Feb 26 10:19:53 phonieboxisa systemd[1]: Started LSB: exim Mail Transport Agent.
Feb 26 10:19:54 phonieboxisa systemd[1]: nmbd.service: Supervising process 820 which is not our child. We'll most likely not notice when it exits.
Feb 26 10:19:54 phonieboxisa systemd[1]: Started Samba NMB Daemon.
Feb 26 10:19:54 phonieboxisa systemd[1]: Starting Samba SMB Daemon...
Feb 26 10:19:54 phonieboxisa systemd[1]: smbd.service: Supervising process 822 which is not our child. We'll most likely not notice when it exits.
Feb 26 10:19:54 phonieboxisa systemd[1]: Started Samba SMB Daemon.
Feb 26 10:19:54 phonieboxisa systemd[1]: Reached target Multi-User System.
Feb 26 10:19:54 phonieboxisa systemd[1]: Reached target Graphical Interface.
Feb 26 10:19:54 phonieboxisa systemd[1]: Starting Update UTMP about System Runlevel Changes...
Feb 26 10:19:54 phonieboxisa systemd[1]: Started Update UTMP about System Runlevel Changes.
Feb 26 10:19:54 phonieboxisa systemd[1]: Startup finished in 2.208s (kernel) + 15.250s (userspace) = 17.458s.
Feb 26 10:19:57 phonieboxisa mopidy[530]: /usr/local/lib/python2.7/dist-packages/pylast/init.py:51: UserWarning: You are using pylast with Python 2. Pylast will soon be Python 3 only. More info: https://github.com/pylast/pylast/issues/265
Feb 26 10:19:57 phonieboxisa mopidy[530]:   UserWarning,
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Starting Mopidy 2.2.1
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Loading config from builtin defaults
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Loading config from /etc/mopidy/mopidy.conf
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Loading config from command line options
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Enabled extensions: iris, mpd, http, stream, spotify, m3u, softwaremixer, file, local-images, local
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Disabled extensions: none
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Starting Mopidy mixer: SoftwareMixer
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Mixer volume set to 30
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Starting Mopidy audio
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Starting Mopidy backends: SpotifyBackend, StreamBackend, M3UBackend, FileBackend, LocalBackend
Feb 26 10:19:58 phonieboxisa mopidy[530]: INFO     Loaded 79 local tracks using json
Feb 26 10:19:59 phonieboxisa mopidy[530]: INFO     Audio output set to "alsasink"
Feb 26 10:19:59 phonieboxisa dhcpcd[506]: wlan0: no IPv6 Routers available
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Logged into Spotify Web API as s2x3dnn2eedc78ckw8bar3sst
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Started spotify backend
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Starting Mopidy core
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Loaded 1 playlists
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Refresh Playlists took 143ms
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Starting Mopidy frontends: IrisFrontend, MpdFrontend, HttpFrontend
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Starting Iris 3.30.0
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     MPD server running at [::ffff:<IP_ADDRESS>]:6600
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     HTTP server running at [::ffff:<IP_ADDRESS>]:6680
Feb 26 10:20:00 phonieboxisa mopidy[530]: INFO     Starting GLib mainloop
Feb 26 10:39:06 phonieboxisa systemd[1]: Time has been changed
Feb 26 10:39:06 phonieboxisa systemd-timesyncd[278]: Synchronized to time server <IP_ADDRESS>:123 (2.debian.pool.ntp.org).
Feb 26 10:39:06 phonieboxisa systemd[1]: apt-daily.timer: Adding 11h 34min 48.125703s random time.
Feb 26 10:39:06 phonieboxisa systemd[1]: apt-daily-upgrade.timer: Adding 18min 29.600461s random time.
Feb 26 10:39:06 phonieboxisa systemd[1]: Starting Clean php session files...
Feb 26 10:39:06 phonieboxisa systemd[1]: Started Clean php session files.
Feb 26 10:39:22 phonieboxisa mopidy[530]: ERROR    Spotify login error: <ErrorType.UNABLE_TO_CONTACT_SERVER: 8>
Feb 26 10:39:54 phonieboxisa CRON[984]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 26 10:53:36 phonieboxisa systemd[1]: Starting Cleanup of Temporary Directories...
Feb 26 10:53:36 phonieboxisa systemd[1]: Started Cleanup of Temporary Directories.
Feb 26 11:09:01 phonieboxisa CRON[1007]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 26 11:09:06 phonieboxisa systemd[1]: Starting Clean php session files...
Feb 26 11:09:07 phonieboxisa systemd[1]: Started Clean php session files.
Feb 26 11:17:01 phonieboxisa CRON[1078]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Feb 26 11:39:01 phonieboxisa CRON[1102]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 26 11:39:07 phonieboxisa systemd[1]: Starting Clean php session files...
Feb 26 11:39:07 phonieboxisa systemd[1]: Started Clean php session files.
Feb 26 12:09:01 phonieboxisa CRON[1185]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 26 12:09:07 phonieboxisa systemd[1]: Starting Clean php session files...
Feb 26 12:09:07 phonieboxisa systemd[1]: Started Clean php session files.
Feb 26 12:17:01 phonieboxisa CRON[1255]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Feb 26 12:30:24 phonieboxisa systemd[1]: Created slice User Slice of pi.
Feb 26 12:30:24 phonieboxisa systemd[1]: Starting User Manager for UID 1000...
Feb 26 12:30:24 phonieboxisa systemd[1]: Started Session c1 of user pi.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Listening on GnuPG cryptographic agent and passphrase cache.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Listening on GnuPG cryptographic agent (access for web browsers).
Feb 26 12:30:24 phonieboxisa systemd[1276]: Reached target Timers.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Feb 26 12:30:24 phonieboxisa systemd[1276]: Reached target Paths.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Feb 26 12:30:24 phonieboxisa systemd[1276]: Reached target Sockets.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Reached target Basic System.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Reached target Default.
Feb 26 12:30:24 phonieboxisa systemd[1276]: Startup finished in 75ms.
Feb 26 12:30:24 phonieboxisa systemd[1]: Started User Manager for UID 1000.
Feb 26 12:30:33 phonieboxisa systemd[1]: Started Session c2 of user pi.
Feb 26 12:39:01 phonieboxisa CRON[1335]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Feb 26 12:39:05 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:06 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:07 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:07 phonieboxisa systemd[1]: Starting Clean php session files...
Feb 26 12:39:07 phonieboxisa systemd[1]: Started Clean php session files.
Feb 26 12:39:26 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:27 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:27 phonieboxisa mopidy[530]: INFO     Failed to lookup "spotify:album:6jbxhrzeRQ87glDoAmw42C": Session must be logged in and online to load objects: <ConnectionState.LOGGED_OUT: 0>
Feb 26 12:39:27 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600
Feb 26 12:39:28 phonieboxisa mopidy[530]: INFO     New MPD connection from [::ffff:<IP_ADDRESS>]:6600

just to make sure: Can you open Spotify in your browser from a device in the same WiFi network?

yes I tried it on the a webplayer in chrome with this users/pwd - works

I can use the spotify interface on the box like to see genre / moods / but does not play
saying "Mopidy failed to add some tracks"

strange thing
I clicked "restart server" inside /iris/#/settings
which worked, but rebooting the system not !!


added vertices replacement

some fixes for the preprocessing module

Codecov Report

Merging #36 (76ae677) into master (a2e1ff1) will decrease coverage by 1.70%.
The diff coverage is 58.06%.

@@            Coverage Diff             @@
##           master      #36      +/-   ##
==========================================
- Coverage   87.12%   85.41%   -1.71%
==========================================
  Files          17       17
  Lines         598      624      +26
==========================================
+ Hits          521      533      +12
- Misses         77       91      +14

Flag
Coverage Δ

unittests
85.41% <58.06%> (-1.71%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cordex/preprocessing/__init__.py
100.00% <ø> (ø)

cordex/preprocessing/preprocessing.py
81.46% <58.06%> (-5.13%)
:arrow_down:


landfast ice parameterisation with lateral drag

What changes does this PR introduce?
New feature, lateral drag parameterization for landfast ice following Liu et al 2022, JGR
What is the current behaviour?
What is the new behaviour
Compiled with new flag SEAICE_ALLOW_SIDEDRAG and turned on by setting runtime parameter SEAICEsideDrag \=0, this parameterisation replaces the no-slip boundary condition for sea ice by a tunable lateral drag. If available, sub grid scale coastline information can be used (to be specified in tow files u/vCoastLineFile) to determine the lateral drag coefficient. Should work with all solvers, but only tested thoroughly with the default Picard/LSR solver.
Does this PR introduce a breaking change?
No
Other information:
This is a slightly modified version of @yqliu11's work, based on her seaice_lateraldrag_v3 branch.
Some details, like names can be discussed, I guess. Documentation is minimal.
No AD code yet, because the AD dynamics is not stable anyway.
Suggested addition to tag-index
o pkg/seaice: add new lateral drag parameterisation for landfast ice (Liu et al 2022, JGR)

how exciting!

i think it would help to provide some kind of quick script to produce an easy set of [u,v]coastlinefile following , for example, the easy form factor F1 (fig. 1b of Liu et al 2022).  Otherwise, it requires quite a bit of work , even for me, to read and sort out the x,y dir and to understand the explanation of how these two files are read in, and understand what the meaning of "Coast line length "normal" to the X/Y dir" parameters NcoastX/Y inside seaice_init_fixed.F is. I've made some quick test using hfac[S,W] for the drag form factor in u,v dir, and still am a bit confused whether i mult with the correct dxG,dyG (to then be centered and div by dxC,dyC in seaice_init_fixed.F...
this is how i generate the ucoastlineFile field, does this make sense to you?
(matlab syntax):
read in hfS top layer only,
read in dxG
tmp=1-hfS (so that land is 1, ocean is 0)
tmpr=0.*tmp;
tmpx(:,2:end-1) = tmpr(:,1:end-2)+tmpr(:,2:end-1)+tmpr(:,3:end) ; %so i get values of 1 or 2, note sum is in y-dir
tmpx=tmpx.*dxg;
write this to a binary file , to be read in under the name ucoastlinefile and assigned to LcoastX in seaice_init_fixed.F
So that NcoastX is now computed by centering the field above, then div by dxC.

Thanks Martin, if you could find the python script? I get the idea, as you said, you want the drag to act on a certain number of grid points starting from the coast line, more next to coast, less further away.  I was just trying to come up with something very crude using hFac as a guide (given that all we have to do is blur the hFac toward the ocean side, then we'd get the coast points and then play with it.. the i/j are always a bit confusing to try to document.. i found from experience that it might be easier to use terminology "tangential" and "normal" ( i did this for the iceplume, after it was also called x/y, and then the user got it mixed up with XC, YC, which can be a disaster for where XC is not x-dir)

@yqliu11 do you think you can share the python script that produces the u/vCoastLineFile?

compute_coastline_for_grid.zip
here is the jupyer notebook file to calculate the input grid from coastline.

In principle, I like the suggestion to rename the internal variables from X/Y to U/V.
There are many variables in pkg/seaice that are X/Y where they could be U/V, e.g. FORCEX/Y. Do you think that this should be changed, too?

@mjlosch I will take a look in the coming days (for a second thought on variable names). Could you can hold on changes until then ?

I've just had a quick look at new variable names, specially the "X/Y" vs "U/V":

"SideDragX/Y", could be changed to "sideDragU/V" (generally, MITgcm vars are starting with lower-case, but it's a detail + there are exceptions ...),  since SideDragX is just used for the U-compon seaice-velocity and is also
located at U-point.
"NcoastX/Y" : for the same reason as above, could also be changed to U/V. And may be changed even more ("sideRoughU "? "coastRoughU" ?) if you feel like.
local variable "LcoastX" in seaice_init_fixed.F: the description is not very clear to me: the coast-line length normal to X direction would be along Y dir, but then why would I scale it by 1/dxC ? Same issue with "uCoastLineFile" description in SEAICE_PARAMS.h.
May be "coast-line roughness along X-dir" ?
And variable name does not matter too much (since it's a local var) but it's loaded from file "uCoastLineFile", so might be   more consistent to use "xCoastLineFile" + "LcoastX" or "uCoastLineFile" + "LcoastU" ?

Now I personally don't see the need to rename pre-existing variables (facilitates user local-code updates).
Technical detail regarding seaice_sidedrag_stress.F arguments:
"NcoastXloc" is not a local copy (it's in this S/R argument list) and as this S/R is always called with "NcoastX" (as far as I can see), inside seaice_sidedrag_stress.F, "NcoastXloc" will point to the global variable "NcoastX" (name could be changed to "NcoastXarg", but again, it's a detail).

Regarding reading of the 2 files "u/vCoastLineFile" into "LcoastX/Y", which are located at the grid-cell corner (at XG,YG):
This will be difficult on cubed-sphere grid near/at the CS-grid corners, since:

the 2 "missing corners" are not found in standard input files (Nx,Ny). Would need to read these 2 value from a secondary auxiliary input file -- or -- to read a (Nx+1,Ny+1) array (as we do for curvilinear grid files).
the definition of  "LcoastX/Y" at the CS-grid corner is not clear, because the grid is not orthogonal at this location (3 lines at $120^o$ instead of 4 lines at $90^o$).

The fact that this Landfast parameterization would not work at the CS-grid corner might not be a real issue (e.g., if the remaining seaice-dynamics does not work neither at the CS-grid corner) but, if we want to make it compatible for CS-grid corner, we could think of changing the definition and grid-cell location of "LcoastX/Y" to be at U and V point location respectively (and skip the averaging from grid-cell corner to U & V location).

The main remaining question is about the location of the fields in u/vCoastLineFile.

Currently they are defined on corner (Z-)points (XG,YG). I guess, the reason for that was convenience. We wanted to have the information on one grid point, and it was easier to accomplish this on a Z-point than on a C-point.
To make it more general (and less confusing), it makes much more sense to read the fields already located at the U and V-points, avoid the interpolation to U/V-points (do it as part of the preparation step.
We probably should provide a simple example how to generate these files based on the python notebook that @yqliu11 provided, maybe add a verification experiment with this.

@jm-c I will follow your suggestion and change the meaning of the input files, simplify the code, and adjust the description.

@jm-c thanks for spotting my mistakes. I fixed them.

@mjlosch an other issue, I've just tried to compile the (TAF) adjoint "offline_exf_seaice" experiment but seems that some variables (which  have been renamed) have not been updated so it did not work.

@mjlosch This looks good and I think this PR is ready to be merged, do you agree ? If so and if no one wants to add something here I could merge it soon after.

I agree, let's get this out of the way.

OK, will merge this PR tomorrow (for daily regression test tracking, better to separate this one from #878).


Change batch timeouts to be both configurable and based on the time oldest message

This makes two changes:

The batch timeouts are now configurable instead of being hard-coded to 20s
We now run execute when the oldest message in the batcher has exceeded the timeout.

To provide a little context, the current behavior of the timeout is that it is based on the newest message in the batcher.  Consider the scenario where batch size = 10 and timeout = 1m.  If a message came in every 30s, then the batch wouldn't be processed until 5m has passed (because the batch size will then be 10).
I will also be looking for feedback / guidance on whether this should be a minor or major rev change.
/to @gregorysabatino @theo-lanman @StabbyCutyou

Awesome! This looks like the right set of changes here.
My personal thought is that it should be a minor revision. Since batch timeout was not configurable before, but fixed at 20 seconds, at most this will cause systems which process batches less often than every 20 seconds to process batches every 20 seconds.

Awesome! This looks like the right set of changes here.
My personal thought is that it should be a minor revision. Since batch timeout was not configurable before, but fixed at 20 seconds, at most this will cause systems which process batches less often than every 20 seconds to process batches every 20 seconds.

Only other comment is, should we be using Time.zone.now?
Otherwise, seems fine, non blocking nits aside.

We shouldn't use Time.zone.now because that's an active_support thing.  Timezones are typically only interesting when you care about it from a visual perspective or where the underlying system has some dependency on either expecting or ignoring timezones.  In our case, we don't fall under any of those scenario.

Gotcha - I was thinking from the perspective of apps using chore, they'd have zone, but you're right - we lack it in chore itself. So, ignore that one.

Specs have been added and this has been validated locally.  See below:
Before:
[2016-03-23 15:32:06 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193203-962908.0.job
[2016-03-23 15:32:06 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193203-962908.0.job
[2016-03-23 15:32:06 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:06 -0400: 1
...
[2016-03-23 15:32:11 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193210-787567.0.job
[2016-03-23 15:32:11 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193210-787567.0.job
[2016-03-23 15:32:11 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:11 -0400: 2
...
[2016-03-23 15:32:16 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193213-407804.0.job
[2016-03-23 15:32:16 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193213-407804.0.job
[2016-03-23 15:32:16 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:16 -0400: 3
...
[2016-03-23 15:32:26 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193223-412877.0.job
[2016-03-23 15:32:26 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193223-412877.0.job
[2016-03-23 15:32:26 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:26 -0400: 4
...
[2016-03-23 15:32:31 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193231-239298.0.job
[2016-03-23 15:32:31 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193231-239298.0.job
[2016-03-23 15:32:31 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:31 -0400: 5
...
[2016-03-23 15:32:41 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193238-869654.0.job
[2016-03-23 15:32:41 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193238-869654.0.job
[2016-03-23 15:32:41 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:41 -0400: 6
...
[2016-03-23 15:32:51 -0400 (11465)] DEBUG : Found a new job development_report_metrics--20160323-193247-275925.0.job
[2016-03-23 15:32:51 -0400 (11465)] DEBUG : Got message: development_report_metrics--20160323-193247-275925.0.job
[2016-03-23 15:32:51 -0400 (11465)] DEBUG : Last message added to batch: 2016-03-23 15:32:51 -0400: 7
...
[2016-03-23 15:32:59 -0400 (11465)] INFO : Manager shutting down

After:
[2016-03-23 15:37:39 -0400 (17130)] DEBUG : Found a new job development_report_metrics--20160323-193737-432563.0.job
[2016-03-23 15:37:39 -0400 (17130)] DEBUG : Got message: development_report_metrics--20160323-193737-432563.0.job
[2016-03-23 15:37:40 -0400 (17130)] DEBUG : Oldest message in batch: 2016-03-23 15:37:39 -0400, size: 1
...
[2016-03-23 15:37:44 -0400 (17130)] DEBUG : Found a new job development_report_metrics--20160323-193742-258437.0.job
[2016-03-23 15:37:44 -0400 (17130)] DEBUG : Got message: development_report_metrics--20160323-193742-258437.0.job
[2016-03-23 15:37:45 -0400 (17130)] DEBUG : Oldest message in batch: 2016-03-23 15:37:39 -0400, size: 2
...
[2016-03-23 15:37:49 -0400 (17130)] DEBUG : Found a new job development_report_metrics--20160323-193749-280834.0.job
[2016-03-23 15:37:49 -0400 (17130)] DEBUG : Got message: development_report_metrics--20160323-193749-280834.0.job
[2016-03-23 15:37:50 -0400 (17130)] DEBUG : Oldest message in batch: 2016-03-23 15:37:39 -0400, size: 3
...
[2016-03-23 15:37:59 -0400 (17130)] DEBUG : Found a new job development_report_metrics--20160323-193755-007838.0.job
[2016-03-23 15:37:59 -0400 (17130)] DEBUG : Got message: development_report_metrics--20160323-193755-007838.0.job
[2016-03-23 15:38:00 -0400 (17130)] DEBUG : Oldest message in batch: 2016-03-23 15:37:39 -0400, size: 4
[2016-03-23 15:38:00 -0400 (17130)] DEBUG : Batching timeout reached (2016-03-23 15:37:59 -0400), current size: 4
[2016-03-23 15:38:00 -0400 (17130)] DEBUG : Manager#assign: No. of UnitsOfWork: 4)

@StabbyCutyou Any thoughts on this being a minor rev bump instead of a major rev bump?

Mr Lanmans line of thinking is inline with my own - we made a fixed value configurable, and defaulted to the old fixed value.
Seems like a minor bump to me.

@theo-lanman / @StabbyCutyou looking for a final review here

LGTM

This looks good to me. Yay specs!


Can not reset password if forget the original password

Is your feature request related to a problem?
I have forget login password and can not find a way to reset my password in internal network

Describe the solution you'd like
Add a way to reset password
Additional context
No response

Reference: https://github.com/usememos/memos/issues/188


[libxlsxwriter] upgrade to 0.9.5

Upgrade to the latest version of libxlsxwriter.
Closes #12724

There is a C++ compilation issue in this release so I will close it and re-open with 0.9.6.

You can also update to 0.9.6 in this PR.


Windows Mixed Reality Commander: improve scrolling behavior

There is currently a bug in the device collection view which does not scroll vertically correctly.
The fix will involve changing the main window XAML to better contain the controls (add rows)

fix is currently being tested.


Import/Convert minfi objects?

Is it possible to import minfi rgChannel object into meffil?

I theory it's possible but would take some time to implement.  Unfortunately I'm unlikely to have time to do this for a while.  I guess you don't have access to the original IDAT files?

I managed to get hold of the idat files now. Thx.


[FEATURE (?)] 1.19 support?

Currently, the mod crashes the game when I open any world, with the following message:
The game crashed whilst unexpected error
Error: java.lang.NoSuchMethodError: 'net.minecraft.class_5250 net.minecraft.class_2585.method_10852(net.minecraft.class_2561)'
Exit Code: -1

Logs attached:
crash-2022-06-30_14.46.04-client.txt

Any movement on this? I'm trying to update it to 1.19.2 myself, but it's a lot to sift through not having any prior knowledge of the code


Rename Gamma to Embold

Gamma rebranded to Embold. This is the press release as a reference: https://www.pressebox.de/pressemitteilung/acellere-gmbh/Acellere-Announces-Rebranding-Changes-Name-to-Embold/boxid/965239

Thanks @markus-h. Had to shorten the description a little bit but it's all good now.


Be more direct about cache insert / update

Your checklist for this pull request
Please review the guidelines for contributing to this repository.

[x] Make sure you are requesting to pull a feature/bugfix branch (right side). Don't request your master!
[x] Make sure tests pass and coverage has not fallen docker-compose run --rm test.
[x] Update the CHANGELOG.md to describe your changes in a bulleted list under the "Development" section at the top of the changelog. If this section does not exist, create it.
[x] Make sure code style follows PEP 008 using docker-compose run --rm blacken.

Description
This resolves an issue in multi-process environments where multiple workers can retrieve a record and then try to insert them at the same time. This tries an insert first and then updates the record if the insertion fails. The difference between this and existing code is it doesn't poll for the key first (which might have changed in the interim).

Seems like a great idea to me. I think that was the only place the key_exists function was being used, so we may also want to strip that out? Not sure about that. Regardless, this looks to me to be ready for a merge.

The "key_exists" function could still be useful outside of context to query if it exists. I know we use it as a kind of cache primer on our end to ensure that the cache exists (we test to see if an invalid key is in there). There could be other unexpected uses of that function out there. :grin:

Sounds good. Released as eeweather==0.3.20. Thanks again!


convert FrequencyEnvelope to Typescript

@tambien , thanks for accepting the last one, this time I'm converting FrequencyEnvelope :) (I also noticed you added a linter step and I made sure to run it this time and update the docs to match the new format, let me know if I did that right)

Great job converting it to TS! thanks for your help


Fix/player numeric

Codecov Report
Attention: Patch coverage is 93.75000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 94.41%. Comparing base (4e2e6bb) to head (5b342d2).

Files
Patch %
Lines

src/Stratz.ts
83.33%
0 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
- Coverage   94.57%   94.41%   -0.17%
==========================================
  Files           3        4       +1
  Lines         166      179      +13
  Branches        9       12       +3
==========================================
+ Hits          157      169      +12
  Misses          8        8
- Partials        1        2       +1

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