Timezone conversion

Hi,
When I'm using a where condition such as
.Where("RequestedDate > \"Fri, 10 May 2019 11:03:17 GMT\"")

the output sql query contains:
[RequestedDate] > '2019-05-10T13:03:17.0000000+02:00'

My server is running in CEST timezone and I guess that is why I get +2 hours. However, this behavior is not what I'm after as all dates in my DB are considered to be UTC and clients (browser - javascript) are providing dates always in UTC as well and thus the conversion breaks the functionality.
Is there any way to stop this behavior? Is this behavior intented?
I figured I can just omit the zone and provide  Fri, 10 May 2019 11:03:17 , but this format is 'not supported' via native Javascript Date and I would have to remove it manually (which is possible and current workaround I'm using, but it doesn't feel right).
Thank you for any insights you can provide :-)

I need to investigate this.
Maybe add a config setting to define the datetime parse timezone.

Having a config or a function that I can use to transform DateTime before it gets parsed would be awesome!

I've added a new config setting DateTimeIsParsedAsUTC which should be set to true in your case.
Try latest preview NuGet from:
1.0.18-ci-11429
(https://github.com/StefH/System.Linq.Dynamic.Core/wiki/MyGet-preview-versions)

@enngage did you have time to test this?

@Enngage Did you have time to test this MyGet ?

@Enngage Can you please test this ?

https://github.com/StefH/System.Linq.Dynamic.Core/pull/277

Hello @StefH.
We have tested your change from PR #277. This seems to work very well, except for the case when the fields are of type nullable DateTime. Can this be fixed for nullable types as well?
PS: We would like to use your fix ASAP, when do you plan to have this merged?
Thanks,
Tudor

Can you please test 1.0.19-ci-11834 on myget? This one should fix nullable datetime

We have tested this and it seems to work great for both DateTime and nullable DateTime now. For some reason we weren't able to find the 1.0.19-ci-11834 version from myget, but we built the sources from the branch locally, and we manually copied the DLLs.
I've noticed that the all checks have passed for PR #277. Do you have an ETA for when this will be merged? Thanks!

ETA = soon


Borderless Window Glitches

When Spore encounters an error on startup. the error appears as a fullscreen borderless window.

If the Spore Mod Manager is set to launch Spore as a borderless window but then the option to override Spore's window mode is disabled, Spore still starts as a fullscreen, borderless window.

When launching Spore as a borderless window through the Spore Mod Launcher instead of through the Spore Mod Manager, there's a high chance that this error will appear:

Closing the error forces Spore to close, unless you close the Spore Mod Launcher instead.

Update: after updating to <IP_ADDRESS>, launching Spore as a borderless window acts the same as launching it as a regular window. It doesn't put Spore into borderless windowed mode anymore.

I've opened a new issue for the sole remaining component of this one. Closing this composite issue since the rest of it has been addressed.
@VanillaCold I really appreciate your ongoing initiative in filing these bug reports. Thank you. But in case I haven't already mentioned this to you before...please try to keep it to one issue per post. Makes things easier to manage. Thanks.


refactor(dh): move identity and master data components to feature library

Description

DataHub

Move identity, primary-master-data and secondary-master-data to separate library

References

https://github.com/Energinet-DataHub/geh-metering-point/issues/580

Good point. I was thinking whether it's a good idea to keep loading of metering point data in dh-metering-point-overview.component.ts but inject DhMeteringPointDataAccessApiStore in dh-metering-point-identity-and-master-data.component.ts and get the metering point data that way. This will make the library more like a feature.
I think that will work. Should we try it?


About the ACR service currently used by "az ml image create".

According to the Azure model management deployment document
Developers has to setup an az ml environment for the image creating process, all docker images are created under this enviornment and all images are push/pull with an Azure Container Registry (ACR) service that is automatically created when the environment is created, and this ACR's SKU is Classic according to the information in my azure portal.
Now, here is my question, according to the documentation about ACR's SKU, The Classic SKU will be deprecated in March 2019. Use Basic, Standard, or Premium for all new container registries.

Does this means after March 2019, when developers start to use model management services, it automatically use Basic, Standard, or Premium ACR service other than Classic SKU, which causes addtional cost when using "az ml image create" commands?
How about the existing ACR services? Do they forced to be upgraded to the three SKUs or get access-forbiddened after March 2019?

Just wandering what is the roadmap for this ACR change, since the docker images creation and storage is the esscence of the Azure ML service in deployment, if this service requires addtional charge or SKU changes, it effect the cost estimation in production stage.
Looking forward to your reply.

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

ID: dfe5a2a3-6fd3-2cca-0387-5c0d9b19906c
Version Independent ID: 3b1ddae9-b0c3-78ff-15a5-428abea3773e
Content: Azure Container Registry SKUs
Content Source: articles/container-registry/container-registry-skus.md
Service: container-registry
GitHub Login: @mmacy
Microsoft Alias: marsma

@gitathrun Thank you very much for you interest in Azure! We are currently investigating your inquiry and will get back with you.

@mmacy @neilpeterson Can either of you help answering this roadmap question on container registry?

Adding @SteveLasker from the product team for comment.

Assigning this issue to @SteveLasker as well, for insights. I will close this out once the product roadmap question is answered. :)

@SteveLasker Can you please help with this customer's question on ACR roadmap?

Hi, we are going to update the Azure ML services very soon and will deprecate the classic ACR as a dependency.

Hey folks. Sorry for the delay as we engaged the ML team on the issue.
We are still working through the details.
Existing ACR Classic customers should migrate to Basic, Standard or Premium registries. While I appreciate there's a direct daily/monthly charge for these tiers, Classic wasn't free either. Customers paid for storage, with no SLA on the service.
The goal here is to have ML create registries that are basic or higher, and customers will have all the features they desire from the managed tiers. See https://aka.ms/acr/skus for more details.
As for what happens in March, we're working through that plan. We'll likely disable creating new classic registries, and provide a timeline by which existing Classic will no longer be supported.
It's possible customers could run the OSS Docker Distribution themselves on their storage, but we haven't found customers really willing to put that much effort into it.
I hope that provides some insight from the ACR team.
Steve

@SteveLasker Many thanks! Great work!

@SteveLasker Thanks for detailed explanation on customer's query.
@gitathrun We will now close this issue. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Proposal: Implement OCI image downloader

skopeo is a good image downloader, but it's belonged to projectatomic.

The problem with a generic image-downloader is that the OCI doesn't
define an HTTP protocol for accessing images.  We could fetch
image-layouts over HTTP (just like we already do for tar- and
directory-backed image-layouts).  I think adding support for that
would be useful.  And it would be fairly straightforward after #5, but
you could land it before #5 if you don't mind updating some existing
walker-style consumers.

There is also a oci-fetch(https://github.com/containers/oci-fetch) can download oci image.
I'm +1 on supporting this in image-tool.

I think we can setup a new sub-command in image-tools repo, like oci-image-fetch, which help to fetch the image from like docker hub, to compress it to OCI image, as supporting resource for OCI image tools of validate and unpack.

I think we can setup a new sub-command in image-tools repo, like oci-image-fetch, which help to fetch the image from like docker hub, to compress it to OCI image, as supporting resource for OCI image tools of validate and unpack.

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)
BTW, there are already tools out there to do this, and since distribution isn't defined by image-spec I would not clutter the repo with this new command

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)
BTW, there are already tools out there to do this, and since distribution isn't defined by image-spec I would not clutter the repo with this new command

I think it will be easier to debug and work for image-tools by adding the command. And we can make modification with probable change of OCI image. I don't think it will lead to clutter, and It seems little benefit to set up another repo.

https://github.com/containers/image is a powerful library,  it's great if move it under OCI.

if mixing OCI and Docker is an option why don't we move https://github.com/containers/image under OCI? :)

I think image-tools should stick to implementing image-spec.  Tools that bridge with other formats and APIs belong outside of opencontainers/.  Of course, we should make the image-tools libraries easily extensible to those external projects don't have to re-implement our functionality.

I agree with @wking in that since it's not part of the spec it shouldn't live here.
@runcom that would be an interesting mix. Since containers/image supports multiple sources and destinations it would be a good companion the rest of the OCI projects and it's literally the only missing part from being able to create a container from scratch with just OCI tools.

I think we could setup a library with some defined APIs(or interface). ｀container/imageor other tools can implement these APIs. These [Interfaces](https://github.com/containers/image/blob/master/types/types.go) incontaiener/image` are good examples.

On Thu, Nov 03, 2016 at 07:53:11PM -0700, Ye Yin wrote:

I think we could setup a library with some defined APIs(or
interface). ｀container/image` or other tools can implement these
APIs.

There are some low-level CAS/ref interfaces in flight with #5.  There
are also some validation interfaces and a media type → intra-blob
validator map in opencontainers/image-spec#403.  I've been holding off
on higher-level interface development while those are in flight, but
yeah, I think interfaces are the way to go to build a stack of
composable components.

@hustcat Here's my opinion on the topic:

skopeo already exists. Not every project that implements OCI features needs to be under the umbrella of the OCI (this is important to remember IMO). I get the frustration that distribution is not defined by the OCI (though IMO this is a blessing in disguise because it allows people to be flexible about implementing downloaders), but skopeo is a very cool project that solves this problem in the interim. If all else fails you could just create a package with your OS package manager and call it a day.

https://github.com/containers/image is not an OCI-specific library, so I feel that putting it under the OCI would be counter-productive -- we cannot really guarantee that transports like docker: or openshift: are something that we're going to maintain properly (we're responsible for our own specification, not every container-related specification that exists). Again, it's something that I believe should be its own separate project.

Having independent implementations of the "core OCI tools" is actually a very good thing IMO, because it means that we can be completely sure that the specification is sane and is well-defined. Not to mention that it results in there being a proper community around the specification (something that is very important if we want to standardise container runtimes and images).

If you want to see what my implementation of some core OCI functionality is, take a look at umoci. It's an OCI image modification tool that allows you to create diff layers (unpack + repack) as well as modify the configuration of the image (config) and so on.

oci-torrent: A tool to distribute OCI image with bittorrent


⚠ ClamAV has degraded performance

In 554234f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 92 ms

Resolved: ClamAV performance has improved in 6cb4794 after 8 minutes.


Backend rebuild

Complete Rebuild of Backend
Rewrote Tests
Rebuilt file structure
setup proper packaging and import structure
removed old tests

Left comments within the code. Two larger comments are the fact that you are considering src - dst to be equal to dst - src, and the third equality check for within you're equality overrides. Another thing, this doesn't need to happen for this specific PR, but the quality of method comment documentation has went down e.g. most methods don't have any documentation at all.

The minimized documentation has been replaced with more thorough type hints and simpler overall logic. If reading type hints and the method name gives you enough of an idea of what the methods do (note that get, set, add, and delete are all standard enough names that one can guess what the behavior is based on the name alone), then there is no need for more documentation. I put in comments explaining lines that are particularly confusing or may be unexpected, however.


Move tests to included build to separate classpaths

Thank you for submitting a pull request! But first:

[x] Can you back your code up with tests? existing tests cover it + CI will ensure it's always working
[x] Keep your commits clean: squash your commits if necessary.

Fixes:
> Configure project :tests
project ':tests' uses Kotlin 1.9.20

The Kotlin Gradle plugin was loaded multiple times in different subprojects, which is not supported and may break the build.
This might happen in subprojects that apply the Kotlin plugins with the Gradle 'plugins { ... }' DSL if they specify explicit versions, even if the versions are equal.
Please add the Kotlin plugin to the common parent project or the root project, then remove the versions in the subprojects.
If the parent project does not need the plugin, add 'apply false' to the plugin line.
See: https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl
The Kotlin plugin was loaded in the following projects: ':mockito-kotlin', ':tests'

The solution requires some explanation while refactoring from the old one.
I'll comment on each change to clarify what it does and why it's needed.
This is the Gradle-idiomatic way of sharing code between two "independent" projects.

Weird error, will rebase and try to fix.

@TimvdLippe This is ready on my side

Thanks for all the fixes!


Update SliderSounds to use one AudioSource instead of two

This change updates SliderSounds.cs (UXCore) to use one AudioSource object for both gab/release and notch sounds as well as exposing the new field in the inspector and as a property. This is a change from the previous implementation where the developer did NOT provide AudioSources (automatically created by SliderSounds). This new implementation will auto-create the necessary object if not specified by the developer.
Since the notch sound lerps the pitch of the clip. this change caches and restores pitch shift as needed. It has been audibly and visually verified in the Unity Editor's play mode.
To complete this change, the canvas and non-canvas base prefabs have been updated to contain a reference to an explicit AudioSource object so that developers can customize properties (ex: mixer channel, spatialization settings, etc.).
The following package versions (and relevant dependencies have been updated)
UXCore: 3.1.0
UXComponents: 3.1.0 (depends upon UXCore 3.1.0)
UXComponents.NonCanvas: 3.1.0 (depends upon UXCore 3.1.0)
Fixes: #438
Fixes: #486
Fixes: #493

on the unity prefab serialization changes. other than adding the AudioSource component, there were no explicit changes made during the creation of this PR.
if required, I can work on a different machine and install the exact matching Unity version that is specified in the template's project settings.

@MixedRealityToolkit/mixedrealitytoolkit-unity-maintainers
This PR should be ready for merging.


Proposal: remove tags

tags is pretty damn worthless. The only thing it has is :vendor which is by itself already useless and seldom used. It was supposed to aid in searching, but we’re not a discoverability service, and that definitely threads the line.
My initial point againt them still pretty much stands, without a need for an update. I believe tags to be bloat.
Would like some opinions on this, even if they are “I have no strong feelings one way or the other”.

Agreed. Trim the fat!

"I have no strong feelings one way or the other”

I might define "discoverability" differently than other folks here, but as a negative "brew-cask isn't a discoverability service," I take it to mean no "Top 100 apps of the month/year/all-time," no "Productivity/Game/Finance" categories, and no "Collaborator Picks" stuff.  We don't need or want that for all the many, many reasons listed over the years.
The other, positive aspect, which for the sake of this conversation I will dub "searchability," is that if someone knows the software they want it should be very easy to find and install it.  Searchability is good and dare I say required for a properly-functioning project[1], especially as the caskroom grows.
To wit, the problem with the tag stanza is that it isn't actually implemented (i.e., in search).  I agree with the above consensus about tags, but I think actually think vendor is useful to keep, and should be used far more often[2] as it provides and expands searchability.  As a quick example, take silverlight.  Someone seeking to install the cask might reasonably[3] expect it to be named microsoft-silverlight[4], and cask search microsoft should help them know what to install.
I say toss tags (not a good/useful service, as per comments above) but keep and replace it with vendor, à la name (only one vendor allowed, though).  Truthfully, and regardless of the outcome here, name should probably also get a closer look.  It's only useful if it can be searched for, like vendor

0: @vitorgalvao I almost just posted that exact video to your final comment in #15799.
1: One place I think we get hung up on here is that there are two main types of brew-cask users/uses.  The everyday "oh, I want this application cask install app yay I have it now" and the (also quite personal) case of bootstrapping new installs/machines/setups, etc.  The latter is often discussed ("don't break everyone's scripts") but "searchability" is quite critical to the former use and doesn't come up enough.
2: Assuming its integrated and implemented with search, anyway.
3: Users shouldn't have to be experts on tokenization to use brew-cask.
4: See also google-chrome, firefox, and a bunch of Facebook stuff.

I like @Amorymeltzer's arguments - this also brings up the point of brew cask search being underpowered and thus brew-cask ends up underserving the "everyday" user.
A generic "tags" or categories label seems too far down the end of spectrum of discoverability, but name and vendor should reasonably be covered by search, in my opinion - if only to help users out with finding out that's it's firefox vs mozilla-firefox, etc. Removing everything risks throwing the baby out with the bathwater, so to speak, and may actually decrease user-friendliness, not increase it.
Revamping search will clearly require quite a bit of work, but as some of our other initiatives are also geared towards making homebrew-cask more user friendly in general, it seems like something that's reasonable and to be considered.

Yes, the idea with both name and tags is that eventually they’d be searchable. I though the implementation of using name for search had already started even and been abandoned, but I can’t find the issue so perhaps I’m mistaken.
I really like your distinction between “discoverability” and “searchability” and agree the latter is important. I also agree with the point that, to keep it, we should get rid of :tags and just have vendor. You actually changed my mind on this.
However, I also think you touched on an important point when you mentioned name, because I think name would be a good place for this. Microsoft Silverlight is a perfectly valid and expected name for the silverlight cask, so why not leverage it for this? Are there any cases where a cask’s name wouldn’t make sense to have the vendor prepended as well, especially since we can have multiple name stanzas?
So (and this is not rhetorical) why not get rid of tags/vendor and in the documentation state instead

The name stanza accepts a UTF-8 string defining the full name of the software, and is used to help with searchability and disambiguation. It can be repeated multiple times if there are useful alternative names, but the first should follow the canonical branding as defined by the vendor.

This is a good place to include the software vendor’s name as well (e.g. pixlr).

And instead of pixlr having
name 'Pixlr'
vendor 'Autodesk'

it would have
name 'Pixlr'
name 'Autodesk Pixlr'

The logic behind this is that since name and tags/vendor have such similarities and even overlaps (think Google Chrome, Adobe Flash, places where the vendor is actually part of the name and is currently just repeated in tags), why not get rid of one of them and let the other carry all the weight?

So, with the above proposal, search would have to do partial matches, correct? ie, searching for microsoft should bring up office, silverlight, etc...
If so, that would work out (and also simply things - reducing the number of "unique" stanzas is a plus when it comes to maintainability.

Yeah, I honestly only figured out while writing this up that name wasn't included in search.
To answer your question @vitorgalvao, I think it depends on how search is implemented.  Basically, if search is partial (as it is right now), then why bother repeating anything?  The current content of pixlr
name 'Pixlr'
vendor 'Autodesk'

would result in accurate search results for both "pixlr" and "autodesk."  Searching for "autodesk-pixlr" or "autodesk pixlr" would presumably fail, but I think it would be sensible for search to include all concatenations of names with vendors.
The reason I'm in favor of this is because of casks that have more than one name.  There are 17 with 3 and 106 with 2.  Should every name stanza also be duplicated with the correct vendor name?  I think it's visually a lot cleaner and a lot clearer (esp. for contributors) if casks have names and 0 or 1 vendor stanzas rather than having 0, 2, 4, or 6 names.[1]  There would presumably be more stanzas overall, @adityadalal924, but I think it will be more obvious what should go in and would avoid truly excessive bloat.[2]
google-chome is a good example[1] of why the search function matters.  Its name stanza is Google Chrome (I would have expected Chrome), but yet it shows up with
cask search google
cask search chrome
cask search Google Chrome

so is there even a need for either name or vendor?  Basically, I think a decision on how this information, whether name, vendor, or tag :vendor, will be used is important for going forward.

1: A lot of those will potentially be changed following this discussion and proper search implementation in the future.  google-chrome is a good example, as per above.
2: Technically, the most straightforward reductio ad absurdumm method would be to dump everybody into one single string: name 'name2 vendor vendor-name name2 vendor-name2'

@adityadalal924

So, with the above proposal, search would have to do partial matches, correct?

Yes.
@Amorymeltzer

Basically, if search is partial (as it is right now), then why bother repeating anything?

Well, indeed that is part of my point . I purposefully gave an example that doesn’t have the vendor in the name, for clarity in the documentation, but many canonically do, perhaps most. Google Chrome, Microsoft Silverlight (whose current cask has name wrong), Adobe Flash, VMWare Fusion all have repetition, because the vendor’s name is part of the canonical name of the app.

Should every name stanza also be duplicated with the correct vendor name?

So my point is that most won’t be duplicated with the vendor name, because the vendor name is already there for many/most. In addition, some of the casks with repeated names already follow a variation of that, with multiple similar names where just an added word differs between them.
There’s no reliable way for us to get meaningful numbers on this without manually checking, since there are too many variations to take into account.

I think it's visually a lot cleaner and a lot clearer (esp. for contributors) if casks have names and 0 or 1 vendor stanzas rather than having 0, 2, 4, or 6 names.

I was also thinking about contributors when I wrote the previous post, as I believe having one less stanza is beneficial for them. My rewrite of the documentation of name left it roughly the same size and gets rid of tags at the same time.

so is there even a need for either name or vendor?

While reading your post, and before reading that part, I was reaching the same conclusion that perhaps a third stanza to replace the other two could be the solution.
Lets think why name was created, then. name was also created precisely because cask tokens are limiting, and we wanted a way to include the canonical name of the app as well. I’m not entirely sure  how successful that was. silverlight (name 'Silverlight')  and thunderbird ( name 'Mozilla Thunderbird) might actually be wrong currently (screenshots from their websites):

It seems that getting the canonical name of an app might not be as straightforward as initially thought.
I’m also leaning towards keeping name instead of an alternative because it suggests restraint. If we name it something else that immediately suggests serachability, we might start getting irrelevant information there (tags, categories, descriptions).
So my updated proposal would be to still get rid of tags/vendor, and keep name as

The name stanza accepts a UTF-8 string defining the full name of the software, and is used to help with searchability and disambiguation. It can be repeated multiple times if there are useful alternative names.

The software vendor’s name should be included as well (e.g. in pixlr).

And pixlr would link to the specific line (only name stanza) saying name 'Autodesk Pixlr'.

Checklist for progress (maintainers feel free to update as proposal evolves)

[ ] Concatenate current tags / vendor and name stanzas in Casks
[ ] Remove all tags / vendor stanzas from Casks, audit code, and core code
[ ] Rename affected Casks to comply with the token reference
[ ] Fix brew cask search to do partial matches of search strings

Tokenization will definitely need a serious change, then.  As it is, using the .app for the token is easy to follow, and involves few judgement calls.
I suppose I'm trying to consider the cases of name where something actually goes by multiple names.  ynab is an example, but the many foreign-language casks are probably better.  Under your proposal, would cave-story be read as such?
name 'Pixel Cave Story'
name 'Pixel Doukutsu'
name 'Pixel 洞窟物語'

@Amorymeltzer That looks quite ugly, and pushes me back towards just having a :name and a :vendor stanza and seeing where things go from there - that's less of a major change and more of "let's remove this generic "tag" thing and put in something with an actual purpose and see how things go"
The actual change (Cask wise) would also not be as drastic - should be a simple substituion for the Cask files, and the core code for :vendor can be copied wholesale from :name, save for the fact that "only one" vendor requirement should be enforced.
Thoughts?

Tokenization will definitely need a serious change, then.

Why?

As it is, using the .app for the token is easy to follow, and involves few judgement calls.

And it’ll stay that way. name is and always was freeform. To be clear, name exists because tokenisation has necessary restraints. Nothing changes there.
Should’ve been more specific regarding your example, though. From what I was thinking, the vendor’s name would need to appear no more than once, and simply when it makes sense. Does cave-story need a the vendor, even? If anyone wants Cave Story, having “Pixel” there (whether in name or vendor) isn’t that helpful anyway, it’s not like you’re going to find it (or look for it) through its vendor. Same with scrolls. In their website, you can’t even quickly guess they’re a Mojang game, neither should you care. To find it, you should search for “Scrolls”. If you search for “Mojang” in the hopes of “that mojang game”, or “show me all mojang games”, then you are going for discoverability (“show all casks that share this”).
Your point on searchability is the most important thing, here. If a name helps a cask be more easily findable when you know what you want, it should be included. Otherwise, it should be left out. Searches should be “I want that app and am using the vendor in my search because the name is common”, never “I want to see which apps that company released”.
Casks with foreign names are a minority, and though we need to accommodate them, they should not dictate the rule. By having only name and making the rule that “it should be as verbose as possible by including the vendor’s name”, the large majority of casks will end up with a single name stanza, and I see that as a big one. There should be no need for more than one most of the time.

To summarise, what we need to be clear on is name exists for searchability and disambiguation. That’s it. Any connected string that can be considered a name that helps to identify the app, shall be used.
So yes, we can have
name 'Pixel Cave Story'
name 'Doukutsu'
name '洞窟物語'

or
name 'Cave Story'
name 'Doukutsu'
name '洞窟物語'

Either is fine. As long as we point to a good example, I don’t think there’d be much confusion (not more than with other stanzas).

Regarding my comment on tokens, I realize now that I misunderstood your earlier point, interpreting "canonical name" to mean "token."  Sorry 'bout that, my bad.
Thank you for clarifying, @vitorgalvao, I suppose I quite agree with you and take your point.  I suppose the need for name to include "the canonical branding as defined by the vendor" will inevitably leave differences we cannot control ("Google Chrome" V "Thunderbird"), and your proposal allows that most easily.
As long as we're redefining name, though, in my utopia it would be entirely freeform, and not bound by the provider's marketing decisions; that's why I think the setup of search is important.  It should be case-insensitive, allow partial matches, and leverage token and names, spitting out what it finds.  I imagine our (ever-growing) list of examples as such:

Token
vendor and/or name stanzas

google-chrome
Unneeded

firefox
vendor 'Mozilla' name 'FF'1

thunderbird
vendor 'Mozilla'

silverlight
vendor 'Microsoft'

pixlr
vendor 'Autodesk'

cave-story
vendor 'Pixel' name 'Doukutsu' name '洞窟物語'

This way someone searching for "mozilla firefox," "mozilla thunderbird," "microsoft silverlight," "pixlr autodesk," "pixel cave story," "and pixel doukutsu," which are all valid brandings, would be easily satisfied with a minimal number of stanzas.

1: Probably not necessary, but it serves the example and isn't out of the question

name, though, in my utopia it would be entirely freeform, and not bound by the provider's marketing decisions (…) It should be case-insensitive, allow partial matches, and leverage token and names

We are in complete agreement. Taking your table, this what I envision:

Token
``name` stanzas

google-chrome
Google Chrome

firefox
Mozilla Firefox1

thunderbird
Mozilla Thunderbird

silverlight
Microsoft Silverlight

pixlr
Autodesk Pixlr

cave-story
Pixel Cave Story Doukutsu 洞窟物語

As for the Unneeded case, I’d still like to have name as mandatory. I remember that was discussed at the start of name and the agreement was “saying a cask doesn’t need name because its token is exact takes more work than just having name be a repeat of token”. Having name is cohesive, it states “this cask is identified”.

:+1: to @vitorgalvao's table above - that looks like I was envisioning

As for the Unneeded case, I’d still like to have name as mandatory.

Ah well, that is where we differ!  I consider many names to be pointless.  But I concede the point; if name is to be added to the required stanza list, then your proposal is both sound and proper.
One final nitpick since vendor is to be tossed: which name gets the vendor?  cave-story is an example, as are pycharm-ce and pycharm-edu.  Whichever one duplicates the token?

One final nitpick since vendor is to be tossed: which name gets the vendor?  cave-story is an example, as are pycharm-ce and pycharm-edu.  Whichever one duplicates the token?

On the technical side it doesn’t really matter since the best course of action here is likely to jumble up all names together and perform partial matches.
On the nitpick side (which I also subscribe to) I’d say it makes sense for us to have suggestions, not rules. The best place for both cases (duplicate token and include vendor).
With these new proposals, it no longer makes sense to have so much duplication, so I can see the suggestion as “the first position should be the most verbose name that still makes sense”. So we no longer have
name 'PyCharm'
name 'PyCharm Community Edition'
name 'PyCharm CE'
vendor 'JetBrains' # not actually in the cask, but included here to illustrate the point

but instead
name 'Jetbrains PyCharm Community Edition'
name 'PyCharm CE'

Jetbrains PyCharm Community Edition makes sense, even though it is likely never referred as such anywhere, but Jetbrains PyCharm Community Edition CE doesn’t make sense, hence why there is a second line for CE.

If we’re all in agreement, I’ll change the label for the issue accordingly. Please tell me if we’re not, so we can revert it back as a discussion.

Yep, all good here.
https://github.com/caskroom/homebrew-cask/issues/10997 is also related to this.

First draft for new name rules.

:+1:


Lucky - Milestone 5 delivery

Looks good. The ink Phat Contract logic is super clear, and the business logic is well isolated in the JS code. The JS engine is also implemented correctly.


Another aci-validator failure

From running it on ubuntu 1604:
=== RUN   TestAceValidator
--- FAIL: TestAceValidator (10.05s)
	rkt_tests.go:113: Running command: /var/tmp/rkt/builds/build-rkt-coreos-/build-rkt-1.0.0+git/tmp/functional/rkt --dir=/tmp/datadir-131459459 --local-config=/tmp/localdir-410600198 --system-config=/tmp/systemdir-457634989 --debug --insecure-options=image run --mds-register --volume database,kind=empty /var/tmp/rkt/builds/build-rkt-coreos-/build-rkt-1.0.0+git/tmp/functional/rkt-ace-validator-main.aci /var/tmp/rkt/builds/build-rkt-coreos-/build-rkt-1.0.0+git/tmp/functional/rkt-ace-validator-sidekick.aci
	rkt_ace_validator_test.go:73: Got expected ACE stage "prestart"
	rkt_ace_validator_test.go:73: Got expected ACE stage "main"
	rkt_ace_validator_test.go:76: Ignoring unknown ACE stage "poststop"
	rkt_ace_validator_test.go:73: Got expected ACE stage "sidekick"
	rkt_ace_validator_test.go:66: Expected "poststop", but not found: ExpectRegex didn't find regex 'ace-validator\[\d+\]: ([[:alpha:]]+) OK'.

The poststop stage coming before sidekick is a surprise here.

I just got this again on Fedora 23.

TestAceValidator is currently disabled, see https://github.com/coreos/rkt/issues/2621


Configurable agent timeout

Is your feature request related to a problem? Please describe.
We have long-running jobs (> 24 hours), and are commonly seeing network problems causing "Agent Lost".
Describe the solution you'd like
If we could configure the timeout, agents would no longer get lost and we wouldn't have to retry those long test runs.
Describe alternatives you've considered
As a workaround we move tests back to AWS' us-east-1, but that is more expensive.

Hi @def- , thanks for raising this. I'd like to understand the problem a bit better - where are your agents running (describing this as ping time to us-east-1 is probably fine)? Do the network problems last longer than a few minutes?
I imagine the reason the network problems are leading to lost agents is because the agent heartbeat (usually once every 2 minutes) fails. Is that the timeout you would like to increase?

The agents are running in Europe. There seem to be periods of intermediate network problems.
Yes, I'd like the possibility to allow the agent hearbeat to fail for a few consecutive minutes, which would reduce the need for us to rerun tests when the agent got lost.

@def- unfortunately this is a configuration we set in our backend, we wait 3 minutes for some communication from the agent before we declare it lost and cancel the job it's running. Please reach out to us at<EMAIL_ADDRESS>so we can understand a bit more about your use case and see if there's anything else we can help you with.

I did that before and support told me to open an issue.

Thanks @def- , I'll follow this up and reply to your original ticket.


👾 Fetch Student Data (Non-Critical)

The following tasks relate to fetching student data from the student relation. This data is non-critical (i.e., Doesn't not include the user's password):

[x] Create the endpoint to query student data without the password.
[x] Create a Student interface.
[x] Add checks in place to ensure only one student is returned in the endpoint.
[x] Create function to place the fetch request to the endpoint.
[x] [Maybe] Convert function into script to be re-used at multiple locations.
[x] Return the student data object to be used as required.

This issue was completed in #27.


TH2-3709. Invalid date in different parts of an application

fixed

closing pull request due to using wrong 6th version of backend on 5th version of ui


Question: Any support or workaround for interceptors (middleware) in the server?

Hello,
is there a way to add interceptors / middleware / filters - like functions to the server? The usual stuff like logging, tracing, authorization, etc but implemented outside of the actual functions called by the server.
For example:
defmodule Auth.UserServer do
  @behaviour Auth.UserService.Handler

  intercept Auth.MyLogger, some: :opts
  intercept Auth.MyTracer

  ... actual server methods
end

So this is basically a plug model; interceptor takes some context, request and response and calls the next interceptor, until it reaches the actual server method in the end, and then it goes through the same process for the response.

There isn't any built in support for these features. However since a behavior is defined for the generated modules it is possible to implement this outside of elixir-thrift. The callbacks can be discovered for meta-programming by calling behaviour_info/1, e.g. Auth.UserService.Handler.behaviour_info(:callbacks).


Implement an SSD cache, that stores data to the file on SSD rather than to dynamic memory

Internal ticket: 2750

@apolukhin I'm interested in trying to implement a support of such cache type.
Could you please add more ideas and/or details of expected solution?
Or should I come up with the design and approach, so we could discuss it here?

Could you please clarify what do you mean by SSD cache? If you mean  some component like CachingComponentBase that stores data on disk and provides key value access, this issue turns into development of embedded database. Maybe it would be easier to add SQLite driver #223? It seems SQLite should cover initial scenario (caching data on local disk) and also provides more features.


Error length.out in subsampleCounts()

I tried to rarefay a phyloseq object transformet to a SummarizedExperiment but obtained this Error.
ps.met.aar = subsampleCounts(makeTreeSEFromPhyloseq(ps.met.aa), min_size = mindeepth, name = "subsampled",replace = FALSE, seed = 123) Error en (function (x, length.out) : valor de 'length.out' no válido Además: Aviso: Subsampling/Rarefying may undermine downstream analyses and have unintended consequences. Therefore, make sure this normalization is appropriate for your data.
I obtained something similar with Something similar rarefy_even_depth() from phyloseq which use rarefaction_subsample() function inside.
Any idea
Thank you

Could you provide code that does the transformations and rarification to generate this error? Most ideally a reproducible example with some demo data set from phyloseq package. This would be like 3-5 lines of code I expect(?) and it would help greatly with troubleshooting,

It is a phyloseq object created from humann3 pathabundance outputs. First I imported files using file3mecho package, then I transformed it to phyloseq and after that I merged both two phyloseq.
I created a shorter phyloseq that generate same error. I attached otu, taxa and metadata tables.
`
Expample of code used to create phyloseq object originally
Read humann3 output file
met.1 = humann2meco(feature_table = "pathabundance_relab_1.tsv",db = "MetaCyc",
sample_table = "metadata_1.txt")
otu = data.frame(met.1$otu_table)
colnames(otu) = gsub("_Abundance", "", colnames(otu))
colnames(otu) = gsub("^X", "", colnames(otu))
met.1$otu_table = otu
met.2 = humann2meco(feature_table = "pathabundance_relab_2.tsv",db = "MetaCyc",
sample_table = "metadata_2.txt")
otu = data.frame(met.2$otu_table)
colnames(otu) = gsub("_Abundance", "", colnames(otu))
colnames(otu) = gsub("^X", "", colnames(otu))
met.2$otu_table = otu
Transform to phyloseq
ps.met.1 = meco2phyloseq(met.1)
ps.met.2 = meco2phyloseq(met.2)
Merge Phyloseq
ps.met.ra = merge_phyloseq(ps.met.1, ps.met.2)
This is the code to import test phyloseq parts
ot.short = read.delim2("ot.short.txt", row.names = 1, dec = ",")
tt.short = read.delim2("tt.short.txt", row.names = 1, dec = ",")
sd.short = read.delim2("sd.short.txt", row.names = 1, dec = ",")
Create phyloseq
ps.short = phyloseq(otu_table(as.matrix(ot.short), taxa_are_rows = T),
tax_table(as.matrix(tt.short)),
sample_data(sd.short))
Rarefy
mindeepth= min(sample_sums(ps.short))
mindeepth
ps.met.aar = rarefy_even_depth(ps.short, rngseed=123, sample.size=mindeepth, replace=FALSE, trimOTUs = TRUE)
 set.seed(123)`` was used to initialize repeatable random subsampling.
Please record this for your records so others can reproduce.
Try set.seed(123); .Random.seed for the full vector
...
Error en rep_len(x["OTUi"], x["times"]): valor de 'length.out' no válido
`
ot.short.txt
tt.short.txt
sd.short.txt

@thpralas ?


chore!: use conventional commit preset

What does this change?
uses conventional commit preset
Why?
the default is angular, which is different from the instructions in the pr template

this fixed the ! not triggering a breaking release (also needed https://github.com/guardian/libs/commit/08a2e07efa9f471bd52d75604e799c6435e04188)


US Gov Iowa and Texas

I'm looking into Azure Gov locations for an upcoming gov project. The current documentation shows that US Gov Iowa's backup pairing goes to Virginia and does not specify where US Gov Texas's backup pairing goes. This confuses me since I thought Iowa was retired and this leaves Texas as ambiguous (although it appears to be the backup for both Virginia and Arizona).
I think the documentation should be updated to reflect these two things:

If I create a GRS Storage Account in US Gov Texas, what is the secondary Region? This should be obvious on this page.
It should indicate that Iowa is retired.

As a side note, there are a number of other places where US Gov Regions documentation is incredibly confusing for some of these same reasons. Some examples (search for "Gov Iowa"):

https://docs.microsoft.com/en-us/azure/virtual-machines/regions
https://docs.microsoft.com/en-us/azure/import-export/storage-import-export-service
https://docs.microsoft.com/en-us/azure/backup/azure-file-share-support-matrix

This appears to have been discussed previously a couple years ago and the intention looks like it was to fix it on this page, yet it is not fixed:

https://github.com/MicrosoftDocs/azure-docs/issues/56461

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

ID: 09a788e4-0130-73f2-d985-6fc3aec77974
Version Independent ID: a9f4ec3f-f0a3-b050-020b-f487c74c5179
Content: Cross-region replication in Azure
Content Source: articles/availability-zones/cross-region-replication-azure.md
Service: azure
GitHub Login: @awysza
Microsoft Alias: rarco

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.


[BOW-69] Add tests for desktop downloading media

Resolves BOW-69.

Codecov Report
Patch coverage has no change and project coverage change: -0.01% :warning:

Comparison is base (69a7c8c) 2.82% compared to head (12590fc) 2.82%.

Additional details and impacted files
@@           Coverage Diff            @@
##            main     #91      +/-   ##
========================================
- Coverage   2.82%   2.82%   -0.01%
========================================
  Files        885     885
  Lines      29315   29384      +69
  Branches     925     925
========================================
  Hits         829     829
- Misses     28486   28555      +69

Files Changed
Coverage Δ

server/app/api/_router.ts
0.00% <0.00%> (ø)

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

Overriding TODO check - they're all related to tests that are coming shortly anyway.


Project Dashboard (frontend) + anchor links

The dashboard is the main page that the user see when they interact with the service. This page should follow the design choices of the muck ups. Furthermore, it should have a modular approach so that it can be expanded if needed.

Add anchor links to Discord, Github, Trello, Zetero, Overleaf, Diagrams.net


Update mod to Minecraft snapshot 23w44a

This pull request updates the mod to Minecraft snapshot 23w44a by using a newer bundled Fabric API dependency, although no breakage in Mod Menu itself occurred. This pull request also refactors certain usages of File to use Path instead, mirroring similar refactors in vanilla.

oops yeah I meant to but got distracted with work.


Get required OpenID Role

Summary
This change allows to perform role-based authorization for OpenID providers.
The new parameter OPENID_REQUIRED_ROLE specifies the allowed role name.
Change Type
New feature (non-breaking change which adds functionality)
Testing
Tested by the personal installation of Keycloak. The configuration process is described in the OpenID with Keycloak and Role Restriction section.
Test Configuration:
Checklist

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] I have commented in any complex areas of my code
[x] I have made pertinent documentation changes
[x] My changes do not introduce new warnings
[ ] I have written tests demonstrating that my changes are effective or that my feature works (No test for this module in the current codebase)
[ ] Local unit tests pass with my changes (No test for this module itself (No test for this module in the current codebase)
[ ] Any changes dependent on mine have been merged and published in downstream modules (Not applicable)

Hi @siriusfreak hope you're well! do you still plan on contributing this?

@danny-avila pls check it

Dear @siriusfreak , for who is looking for a groups claims integration, do you think you can add that support too? It is very common to use also security groups in addition of application roles IdPs. What do you think about?

I am relay on KeyCloack. Could you show me your identity provider?
Basically, we need only check if there are required items in the list inside JWT token. So it could be more generalized like a way to check the token.

Sure it is Entra (former Azure AD).
It HAS app roles but it is very common (not just here with Azure) to have roles check against the groups claim.
So I was wondering if you want to extend this behavior with an addition or just extending the behavior of the two new env variables you introduced.
In case, I can dig into it in the next days
Thanks!

Hi. @childotg @danny-avila
I added more flexibility to the configuration. Now, it is possible to determine the exact source for the token inside ID provider response. I tested it with Entra and Keycloak.
@childotg You can use emmiting groups as roles to retrieve roles in id_token.

thanks for the documentation. it would also be nice to have a guide on how to setup roles via azure as you showed in one the comments here but more comprehensive.

@danny-avila

docker-compose port exposing removed
docs updated
auth docs for auth providers moved to the separate files

Merging this PR's commits along with some edits, mostly documentation, in #2279


Disaster clusters duplicate when updating the disaster.

Updating a disaster causes the checked clusters to duplicate.

Fixed in PR #439


Improve performance of the latest_of_each method of the manager

Description

latest_of_each method of the manager is currently getting all the latest pks and using a pk__in filter to determine final results. But in filter is performing bad, especially when there are a lot of rows in the db. Every item in the database needs to be compared by this long list.  This can be avoided by using another subquery which would annotate the existence of later items and then it can be used to filter the query by this field to get latest of each item.
This also removes the need to have database specific implementation as the resulting query should work on each.
Related Issue

Currently there are no related issues.
Motivation and Context

Improves performance for latest_of_each method which is necessary for history tables which are having a lot of data.
How Has This Been Tested?

Existing tests for the method has been used.
Results from query analysis which ran on postgresql. The table 1.8 million entries.
This is the cost analysis for the improved query
Limit  (cost=130063.36..131511.02 rows=50 width=5438) (actual time=327.427..343.020 rows=50 loops=1)

This is the cost analysis for the normal query
Limit  (cost=483323.35..483323.47 rows=50 width=5438) (actual time=2142.676..2148.425 rows=50 loops=1)

According to these results, there is %84,7338936 improvement.
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[X] Improvement

Checklist:

[X] I have run the pre-commit run command to format and lint.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[x] I have added my name and/or github handle to AUTHORS.rst
[x] I have added my change to CHANGES.rst
[X] All new and existing tests passed.

@bagababaoglu did you happen to also test this on a mysql database?

@bagababaoglu did you happen to also test this on a mysql database?

@tim-schilling yes, I  tested it for all databases using make test  command. All tests were successful.
simple_history/__init__.py                                                                                13      0      2      0   100%
simple_history/admin.py                                                                                172      2     40      0    99%
simple_history/exceptions.py                                                                                8      0      0      0   100%
simple_history/management/__init__.py                                                                                0      0      0      0   100%
simple_history/management/commands/__init__.py                                                                                0      0      0      0   100%
simple_history/management/commands/clean_duplicate_history.py                                                                                76      1     36      2    97%
simple_history/management/commands/clean_old_history.py                                                                                40      0     14      0   100%
simple_history/management/commands/populate_history.py                                                                                100      0     40      4    97%
simple_history/manager.py                                                                                108      1     36      2    98%
simple_history/middleware.py                                                                                23      5      2      1    76%
simple_history/models.py                                                                                545     12    204     10    97%
simple_history/registry_tests/__init__.py                                                                                0      0      0      0   100%
simple_history/registry_tests/migration_test_app/__init__.py                                                                                0      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0001_initial.py                                                                           7      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0002_historicalmodelwithcustomattrforeignkey_modelwithcustomattrforeignkey.py             8      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0003_alter_historicalmodelwithcustomattrforeignkey_options_and_more.py                    4      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0004_history_date_indexing.py                                                             4      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0005_historicalmodelwithcustomattronetoonefield_modelwithcustomattronetoonefield.py       8      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0006_alter_historicalmodelwithcustomattronetoonefield_options_and_more.py                 4      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/0007_alter_historicalmodelwithcustomattrforeignkey_options_and_more.py                    4      0      0      0   100%
simple_history/registry_tests/migration_test_app/migrations/__init__.py                                                                               0      0      0      0   100%
simple_history/registry_tests/migration_test_app/models.py                                                                                37      0      4      2    95%
simple_history/registry_tests/tests.py                                                                                101      4     12      0    96%
simple_history/signals.py                                                                                5      0      0      0   100%
simple_history/template_utils.py                                                                                85      0     22      0   100%
simple_history/templatetags/__init__.py                                                                                0      0      0      0   100%
simple_history/templatetags/getattributes.py                                                                                5      0      0      0   100%
simple_history/templatetags/simple_history_admin_list.py                                                                                7      0      0      0   100%
simple_history/templatetags/simple_history_compat.py                                                                                4      0      0      0   100%
simple_history/utils.py                                                                                78      0     28      0   100%
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                1446     25    440     21    98%
py38-dj42-mysql: OK ✔ in 3 minutes 50.47 seconds

Or do you mean if I have tested the performance on mysql database? In that case, no I haven't as I had the data for Postgresql only. Do you think the performance improvement would be different for mysql?

@bagababaoglu did you compare the Subquery approach that's not vendor specific to this approach?

@tim-schilling I did now.  IMO, it is better to avoid in filter if it is possible.

Thank you! I'm in favor of this. @ddabble thoughts?

Ooh, that's a satisfying simplification! I'll check it out more closely sometime this week :)

Looks nice, great job! 😄
@bagababaoglu Do you have any feedback on the changes I made? 🙂 Did I misrepresent anything in the comments/descriptions?

Thank you for your additions :pray: They look fine to me.


.kgj

Describe the bug

Steps To Reproduce

Expected behavior

Screenshots

Device and Application Information

OS Build:
Architecture:
Application Version:
Region:
Dev Version Installed:

Additional context

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.


What to do with transmute_copy

This function is a terror. It is full of undefined behavior, even more than it's sister, transmute. The only uses of this function are either Undefined Behavior, are transmutes, except that they didn't try, or are just transmutes in a generic context.
This is unfortunate. I think we should make this function either much more useful, or deprecate it and get rid of the undefined behavior.
Changing the definition to:
unsafe fn transmute_copy<T: ?Sized, U>(t: &T) -> U {
    let u: U = std::mem::uninitialized();
    std::ptr::copy_nonoverlapping(t as *const t as *const u8, &mut u as *mut u as *mut u8
                                  std::mem::size_of::<U>());
    u
}

would allow us to pull types from byte arrays, for example, without having to do this all by hand.
Otherwise, it should be deprecated, because it isn't really useful enough, and leads to far too many issues; it's only stable because transmute was unstable at the time.

Why can't we just add ?Sized to the existing definition? The change you are proposing is to effectively remove the requirement that the address of t is suitably aligned for reading a U. If your intent is to support unaligned reads and writes then I think we would be better off adding specialized ptr::read_unaligned and ptr::write_unaligned functions rather than messing with the definition of transmute_copy.
Regarding your point that transmute_copy isn't useful, I have to disagree. I make extensive use of it in atomic-rs since it is used in a generic context, which makes plain transmute unusable.

@Amanieu That is my first suggestion.

I'd argue you should use ptr::{read, write} if you need the unsafe, assumes aligned behavior.

transmute allows unaligned reads

transmute takes a copy (or move) of its source. Any alignment issues occur outside of it.
I'm however +1 for transmute_copy using copy_nonoverlapping rather than ptr::read.

I would rather avoid having transmute_copy abused for unaligned access since that is not its main purpose. We should instead add ptr::read_unaligned and ptr::write_unaligned specifically to support unaligned access.
I think changing the signature of transmute_copy to allow ?Sized for the source is pretty uncontroversial.
The main issue that needs to be discussed is what the alignment requirements for the source argument of transmute_copy should be. I see 3 options:

Must be suitably aligned for the source type
No alignment requirement (what @ubsan is proposing)
Must be suitably aligned for the target type (what is currently implemented)

@Amanieu ptr::copy_nonoverlapping is a fine way to do unaligned access. It's what ptr::{read,write}_unaligned would desugar to.

I don't know why this issue got closed in 2017 (@ubsan 	do you remember?), but 1.5 years later with https://github.com/rust-lang/rust/pull/55052 the implementation got changed to use read_unaligned.

@RalfJung I believe this was closed when I left the Rust community, and didn't want to deal with it.

Then I guess I can just hope that there's nothing else we lost track because of issues being closed like that...


EcdoubleAssignNewXV2 hint (secp hint)

https://github.com/lambdaclass/cairo-vm/blob/db7fff18c9c1312024ebf4119fcdfeba23657b12/vm/src/hint_processor/builtin_hint_processor/hint_code.rs#L776
https://github.com/lambdaclass/cairo-vm/blob/db7fff18c9c1312024ebf4119fcdfeba23657b12/cairo_programs/efficient_secp256r1_ec.cairo#L34
https://github.com/starkware-libs/cairo-lang/blob/0e4dab8a6065d80d1c726394f5d9d23cb451706a/src/starkware/starknet/security/whitelists/cairo_secp.json#L133

Hello @TAdev0 I would like to help with this one! I know that I already have an issue assigned but I already opened a PR for that one

Let's go !

@TAdev0 Thank you sir! 🫡

@TAdev0 this PR that solves this issue is ready for review!


Unsupported Scheme error with cucumber-jvm:4.2.3

PROBLEM:
On WindowsOS, when trying to run cucumber:4.2.3  using the generated classes from this plugin v5.0.0 I am getting an error specifying an "Unsupported Scheme: " error.
DISCOVERY:
I did some investigation into the code and figure out that in the generated files on windows (not sure about linux or mac), the features value is a normal windows path (expected). Then I debugged the cucumber runner and found that it was doing a comparison of the Scheme part of the path it is given.
For example:  If the feature file is "C:\Users\user\workspace\app\src\test\resources\features\test.feature"
cucumber will try to get the scheme via the java Path api. This results in the scheme being "C" instead of "file" or "classpath" like it expects and throws an error.
TEMP SOLUTION:
I have created a simple shim that resolves this issue for me for the time being. See below:
<plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <version>1.6.0</version>
      <executions>
          <execution>
              <phase>process-test-sources</phase>
              <goals>
                  <goal>java</goal>
              </goals>
          </execution>
      </executions>
      <configuration>
          <mainClass>com.myapp.util.FixCucumberParallelFiles</mainClass>
          <arguments>
              <argument>${project.build.directory}/generated-test-sources/cucumber</argument>
          </arguments>
      </configuration>
</plugin>

package com.myapp.util;

import java.io.File;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

/**
 * This class is called from maven using exec-maven-plugin in order to correct the
 * features paths notation in the generated cucumber runner files via cucumber-jvm-parallel-plugin
 * so that the newer version of cucumber-core can correctly understand what type of resource the path is.
 */
public class FixCucumberParallelFiles {
    public static void main(String[] args) throws IOException {
        File[] files = new File(args[0]).listFiles();
        if (files == null) return;
        for (File file : files) {
            Path path = Paths.get(file.toURI());
            String content = new String(Files.readAllBytes(path), StandardCharsets.UTF_8);
            // prefix all paths using the windows path style with the 'file:' scheme
            content = content.replaceAll("\"([A-Z]+):", "\"file:$1:");
            Files.write(path, content.getBytes(StandardCharsets.UTF_8));
        }
    }
}

This code (as the comment says) prefixes all paths that use the window's path style (letter and colon) with the file: scheme so that the Path API interprets the path scheme correctly.
PROPOSED SOLUTION:
The simplest fix I have thought of is to add a maven config option that allows the person to define a custom scheme to prefix the feature file path of the generated runners.
Please let me know if I overlooked something that would nullify this issue, or if you need additional information.

It seems like cucumber core 4.2.4 fixes the issue and makes this fix obsolete:
see: https://github.com/cucumber/cucumber-jvm/commit/407627a96cbc2200246f460861489630f68ddde3
Keeping the fix will have scenarios with an outline and a test tabel run n^2 times because it makes cucumber ignore the line number in every runner, thus running all tests every single time.
See also: https://github.com/cucumber/cucumber-jvm/commit/346b6e7ee8e064ae991c3d169ca727c6a3ae8a4f
So suggested workaround for the workaround: update core to 4.2.4 (or newer) and remove the fix.

Fantastic!
Not sure about the n^2 problem with my shim, but I'm glad this is fixed in 4.2.4


how responsive hola in mobile

Hi. How I responsive hola video in mobile?
window.hola_player({videojs_options: {fluid: true}});
where should I add this code?
how should I make it width 100%?
thanks

Hi, here is an example
https://jsfiddle.net/b23Lpeaw/

thanks, but not work for me.
my web: http://mag.ebayfarsi.com/ebayfarsi-affiliate-guide/

another option is to enable it on holaspark configuration panel:
Configuration -> Hola Player -> Appearance -> Size -> Responsive 16:9

<video class="video-js vjs-default-skin vjs-16-9"
add vjs-16-9 and will do the work


Hashcat download

Centralizing hashcat installation from the agent server, and moving from 7z to tar improves user experience from both not having to install 7z and may let us do updates to all agents in the future.

Done, thanks to you 😎


add more customization options for keymap extension

related issue -> #2272

thanks! please fix the vint warning and squash. Thanks!

squashed it

thanks!


Added assertion tasks to ensure user is logged into the right cluster

Fixes #73

before we merge this please also have a cherry-pick PR onto stunnel branch. Thanks

@alaypatel07 Opened new PR against stunnel branch : https://github.com/konveyor/pvc-migrate/pull/97

Quickly trying this out, but looks good 👍 .

@pranavgaikwad I updated the warning message to match Stage 1 message. Warning worked for me, think this will save folks from mistakes 👍


fix(tooltip): NO-JIRA do not display when empty, general cleanup

fix(tooltip): do not display when empty, general cleanup

Obligatory GIF (super important!)

:hammer_and_wrench: Type Of Change

These types will increment the version number on release:

[x] Fix

:book: Description

Fixed tooltip still displaying when content was empty.
Did some general cleanup with unused methods and such
Set sticky to be true by default, as we talked about yesterday

:bulb: Context
@juliodialpad put up pr https://github.com/dialpad/dialtone/pull/341 yesterday to solve the tooltip not displaying, but the problem was actually that I broke the fix I already made by overriding the onShow method.
:pencil: Checklist

For all PRs:

[x] I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[x] I have reviewed my changes.
[x] I have added all relevant documentation.
[x] I have considered the performance impact of my change.

For all Vue changes:

[x] I have made my changes in Vue 2 and Vue 3. Note: you may sync your changes from Vue 2 to Vue 3 (or vice versa) using the ./scripts/dialtone-vue-sync.sh script. Read docs here: Dialtone Vue Sync Script

Yeah it was very confusing. Hopefully it makes a bit more sense now.


Integration with relay-tools/react-router-relay.

I like how this project reuses react-router, and I think this is the right direction for true code sharing between native apps and web.
I want to open an issue for integration with react-router-relay as well.
I'm not sure if it would work out of box as is now, but I will play with it soon to see whether it needs some modifications.

This would be an awesome addition. If you'd like to lead this effort, it would definitely be welcome! Feel free to get in touch on Discord.
At first sight it looks like react-router-relay is just a router middleware, which seems to import the default RouterContext directly, ☹, from React Router. RouterContext is our entry point to React Router. So as a first step we would have to submit a patch to ryanflorence/react-router-apply-middleware to make this work:
applyMiddleware = (RouterContext) => (...middleware) => ();

Correct me if I am wrong, but it seems the react-router-relay uses this applyRouterMiddleware.

I wonder if react-router-native can be refactored so that itself is also a middleware to react-router.
So that the code with relay looks like the following:
import useRelay from 'react-router-relay';
import {
  useNative,
  nativeHistory
} from 'react-router-native';
import {
  Router,
  Route,
  applyRouterMiddleware
} from 'react-router';

/* ... */

const AboutQueries = {
  about: () => Relay.QL`query { about }`
};

ReactDOM.render(
  <Router
    history={nativeHistory}
    render={applyRouterMiddleware(useNative, useRelay)}
    environment={Relay.Store}
    addressBar
  >
    <TabsRoute
      path="app"
      component={App}
      transition="horizontal-pager"
    >
      <Route
        path="/"
        component={About}
        queries={AboutQueries}
        overlayComponent={AboutHeader}
      />
    </TabsRoute>
  </Router>

You're right. I wasn't aware of this—looks like that was merged to master as of v2.3.0.
Either way, we would have to have full control over RouterContext to be able to support rendering with NavigationExperimental. So a middleware approach won't work.
I just created a PR that adds applyRouterMiddleware. I don't think I should merge it until we have proper testing in place. Can you play with that branch and react-router-relay, and let us know if it works at all? I should have more time over the weekend to dig into this. But feel free to take over.
🍺

I need some time to really learn how routers work. I took some time last night, but there seem to be lots of things to learn.


preferNative Support in npm package

Hi, the documentation in the README refers to the ability to use preferNative to toggle on and off the usage of text-wrap: balance;, however, the npm package doesn't include this option.
The GitHub repo here shows it's support implemented and the example website has it functioning as well, so it seems that this may potentially be a miss in publishing the updated code.
I could also be missing something meaningful, but thought I would flag this as I haven't been able to figure out what that might be.
Thanks!

Should be included in https://github.com/shuding/react-wrap-balancer/releases/tag/1.1.0.


problem of 2021/assignment1/two_layer_net

In two_layer_net.ipynb , when I use a Solver instance to train a TwoLayerNet, a numerical overflow error raised, which caused the softmax loss nan, but I have successfully passed all test above this step. Anyone also encountered this bug? Please give me some advice!

same problem, I have seen many people just change the default learning rate to 1e-3, how did you fix it?


MySQL CDC source auto schema doesn't work

Describe the bug
RW: v1.10.0-rc.1
MySQL: 8.0.35
A quick guess according to the error information, we used the wrong connection for mysql source. The <IP_ADDRESS> is RW address. The mysql is <IP_ADDRESS>. And the protocol in the error is pg_wire.

The pg table auto schema works.

Error message/log
No response
To Reproduce
No response
Expected behavior
No response
How did you deploy RisingWave?
No response
The version of RisingWave
v1.10.0-rc.1
Additional context
No response

It's worked in nightly-20240620


vsl-219: Update UI for Send Modal

Description

Refactor send modal to align with figma design
Refactor dropdown to handle more functions
Create Tooltip reusable component

Demo / Test Result

Send token flow

https://user-images.githubusercontent.com/7423845/193361946-6c91197f-65fd-4e2f-a676-3cfee907bba2.mov

Send nft flow

https://user-images.githubusercontent.com/7423845/193361968-bf0b8766-273b-4d47-81d7-8d0efb45a33e.mov

Dropdown and Tooltip
Dropdown can search by address, owner name
Dropdown input box can be used as address input

https://user-images.githubusercontent.com/7423845/193362213-5e741e8e-4829-4eae-854d-241588cdf106.mov

All looks great. Couple comments on the FE.

For the dropdown. Can we add a border radius for the bottom 2 corners of the opened dropdown modal
I played around a little bit to try to get the tooltip closer to the design. I got it close using an svg. I created a codepen that hopefully helps: https://codepen.io/almendili/pen/OJZwErJ

@almendili Fixed the border radius! Going to create another ticket for the tooltip arrow implementation. https://linear.app/dappercollectives/issue/VSL-252


”Ruginoasa”, ”Dumbrăvița”, ”Rediu”, ”Vascani” are listed in the drop-down menu

Description:
When user writes ”Ruginoasa”, ”Dumbrăvița”, ”Rediu”, ”Vascani” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Ruginoasa"

Expected results
The location appears in the drop-down menu as "Sat Ruginoasa, IAȘI (Ruginoasa)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Dumbrăvița"

Expected results
The location appears in the drop-down menu as "Sat Dumbrăvița, IAȘI (Ruginoasa)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Rediu"

Expected results
The location appears in the drop-down menu as "Sat Rediu, IAȘI (Ruginoasa)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Write in the search bar "Vascani"

Expected results
The location appears in the drop-down menu as "Sat Vascani, IAȘI (Ruginoasa)".


/** @deprecated */ support broken on mapped types

Bug Report

🔎 Search Terms
vscode, jsdoc

🕗 Version & Regression Information
4.1.3

⏯ Playground Link

Playground link with relevant code
💻 Code

type ApiDict = {
  /**
   * jsdoc for getString
   */
  getString: string;
  /**
   * jsdoc for getBoolean
   *
   * @deprecated
   */
  getBoolean: boolean;
};

type Api = {
  [key in keyof ApiDict]: {
    (url: string): ApiDict[key];
  };
};

declare const api: Api;
declare const api2: ApiDict;

api.getBoolean
api2.getBoolean

related issue
https://github.com/microsoft/TypeScript/issues/42549

Seems to be working as expected, because in that example you are making a new type of property, you're not mapping to the same properties.
In this playground example, the @deprecated propagates to the new properties because we've mapped them to the same properties.
I do think it would be a cool feature to be able to somehow propagate the @deprecated feature to properties with matching keys but of different type.
Perhaps we can change the title to make this a feature request.

Really not sure how this should work. What happens for overloads where only one of them is deprecated? It's not exactly a type system feature so we'd need some feedback to figure out what the right behavior is.

I've also run into this inconsistency and I am wondering what the expected behavior is.
For my use case, I would prefer it if the @deprecated JSDoc annotation applied to the mapped type property, and thus, raised TS compiler diagnostic 6385, i.e. 'propertyName' is deprecated. ts(6385).

Another +1 for this.
I recently built a type definition generation tool where GraphQL operation result types are expressed as mapped types from schema types. It would be great if operation users could be notified just by marking schema type fileds as @deprecated.


fixing exception with authenticateUser

This should fix #16

Hi all here,
I've copied this project in a separate package (because this one isn't supported anymore) https://pub.dev/packages/amazon_cognito_identity_dart_2
Welcome to contribute.


--no-optional-dependencies not working as expected

Please use GitHub issues only to report bugs. To ask a general question or request assistance/support, please use the Claudia.js Gitter Chat instead.
To report a bug or a problem, please fill in the sections below. The more you provide, the better we'll be able to help.

Expected behaviour:
optional dependencies such as aws-sdk are not included in zip

What actually happens:
aws-sdk is included.

Link to a minimal, executable project that demonstrates the problem:

Steps to install the project:
install aws-sdk as optional dependency npm i -O aws-sdk

Steps to reproduce the problem:
claudia update --no-optional-dependencies

Please note
it appears that claudia packages with the following npm command:
npm install -q --no-package-lock --no-audit --production --no-optional

if I remove the --no-package-lock option, then the optional dependencies are correctly omitted.

Related to #82. Would be nice to get a fix for this.

Possibly an npm version issue or something else in local environment. Have just looked at the package created as part of deployment (using Github action) and it doesn't contain aws-sdk! Maybe a Windows issue?

After battling this for hours today, I THINK the issue is the npm dedupe.  You can reproduce with:
rm -rf package-lock.json node_modules
npm install --no-optional --production

At this point aws-sdk is not installed
npm dedupe --no-optional --production

Still not installed
npm dedupe

Now it's installed
Running claudia update with  --no-optional-dependencies  does not apply --no-optional --production when running  npm dedupe
This is a total blocker for me. The size of the bundle is so large that my deploys are failing now.

^ this is with latest Node (14). Downgrading to 13, my claudia update no longer fails due to size (from aws-sdk and others).

More specifically, it's NPM 7 where Claudia has the issue with dedupe. It should be fixed to add the --no-optional --production flags. In the meantime, the workaround is to install NPM 6:
npm install -g npm@^6

Any resolution on this?

Fixed. PR is pending #225.

thanks, this is now published as v 5.14.0


Avoid use of ideep in doctest

This fixes #5134.
Please merge https://github.com/chainer/chainer-test/pull/441 after this PR and backport got merged.

Jenkins, test this please.

Jenkins CI test (for commit ee8f70efb4859251831cc54f0e6a5efd93eb8a69, target branch master) succeeded!

Jenkins, test this please.

Jenkins CI test (for commit 0605c7c237ba5fb869b168f022e0d7792f0118e5, target branch master) succeeded!

LGTM


hover window shows files with positions that I'd like to be able to open

See the following pic:

On  a defition, the hover shows nicely the location of the documentation and source of the external lib (external to the project). In the current LPS mode there is no commands that would allow me to open a buffer/browser with those file locations.
Is this possible or configurable at the moment?
E.g. if possible, there could be bolded/highlighted numbers 1 and 2  at the beginning of the corresponding lines, and pressing that number would allow the buffer to be opened or browser window opened. Maybe the action could even be somehow configurable.
The lsp mode has 'd', 'i' and 's' (go to definition, implementation and show function signature help) but they gave nothing here.

You should be able to go-to-definition of the symbol at cursor, then the links should be nearby.
Alternatively, currently you can select the link text by holding shift+left click.
As soon as Kakoune supports OSC 8 links we can add that.
Also, I think we should add an option to render the hover data into a special *hover* buffer, then this will be trivial.


Add support for filtering to note browser

This should work similar to how vim-dirvish handles filtering so it's easy to sort or filter notes based on simple regular expressions.

I don't think a separate feature for this is necessary. :help :g already works in the note browser buffer and sorting can be achieved in a similar way as well. There's a new wiki entry for sorting, and maybe one day I'll add one for filtering as well.


[DismissableLayer] Elements rendered in popup windows are not handled correctly

Bug report
Dropdown menus rendered in popup windows (i.e. separate windows created via window.open) are not dismissed correctly when clicking outside of them. This appears to be due to DismissableLayer always adding event listeners to the document global, instead of using node.ownerDocument.
Current Behavior
Clicking outside of a menu in a popup window does nothing:

Expected behavior
Clicking outside of a  menu in the main window dismisses it, the same should happen in popups:

Reproducible example
https://codesandbox.io/s/agitated-stitch-txdns4 is a simple test case. The "…" button opens a menu. It works as expected in the main window, but when we render the component in a popup window (opened by the "Open Popup" button) dismissal does not work.
Suggested solution
Event handlers such as the ones from https://github.com/radix-ui/primitives/blob/6c398d9810fc52577780b5d987d2a6f11e86276b/packages/react/dismissable-layer/src/DismissableLayer.tsx#L233-L238 should be added on node.ownerDocument rather than document. Possibly a helper ref like ownerDocumentRef  from https://github.com/radix-ui/primitives/blob/fbfa1e8072df7b12bcdfdf30ecc2fbead2022303/packages/react/announce/src/Announce.tsx#L99-L107 may be useful.
Additional context
I work on a multi-window application that renders components in popup windows (to allow window management). All of the logic runs in the main window for performance reasons (so that we don't need to load a copy of the application's code in each window).
Your environment
The environment is not really relevant since this occurs everywhere

Software
Name(s)
Version

Radix Package(s)
DropdownMenu,   DismissableLayer
1.0.0

React
n/a
18.2.0

Browser
Chrome
105.0.5195.102

Operating System
macOS
12.6

Hey @mihaip,
Thanks for reporting this, that seems entirely valid 👍


[5.5] Added domain helper to route

Originally sent by @robinvdvleuten to 5.4 branch in https://github.com/laravel/framework/pull/19243, submitting to 5.5 branch

Nice! Thanks @m1guelpf!

@m1guelpf I opened a PR on your fork (https://github.com/m1guelpf/framework/pull/1) to add a specific test for this. The test fails on current master branch but passes on your master (with these changes).
I noticed that this PR corrects some of the tests that would be broken, but currently it doesn't really have a test for this specific added feature. I think if you merge the PR the commit should show up here automatically.

@deleugpn Done!

I'd rather transitioning from 5.4 to 5.5 to be as simple as possible, but changing things like this will make it more difficult. I'm not saying I disagree with the feature, I'd just rather it not change the current behaviour to be honest.

Maybe it would be better to keep current domain() functionality, but use the new functionality when passing a parameter, like:
domain()

would act as it does now, but
domain($domain)

would do new behaviour

I think it would be quite weird to have a method that return either a string or a Route object.

I tried to stay as close to the Laravel API as possible; if you would like to add a prefix you call prefix('/api') but if you want to get the prefix of the route you'll call getPrefix().

AFAIK now you can define domain only on route group. Does this PR bring opportunity to define domain for every single Route? Or I misunderstood something?

@decadence I would infer that it does since the test I wrote for this does exactly that.

@m1guelpf yes you should make the existing domain method function as both a getter and setter depending on if an argument is passed. We do that in other parts of the framework occasionally.

Eh, nevermind, I guess we have other get* methods on this class.

Excellent PR!


Replace Mocha with Jest

Migration complete.
Only item left will is switching to a new reporter which I have opened #361, for tracking purposes.

I messed this up. Closing.

Coverage remained the same at 95.283% when pulling 72a5040f9db93d221b161bd220212b85b44e972e on master into a096dd7449d98155178356e7114e1888a0fc73e9 on jest-migration.


Extend SESSION_COOKIE_AGE for OAuth/Remember me

Staff have asked if the "remember me" option could be implemented for OAuth as they have to re-login daily. This has had some small residual effects like staff losing a typed up determination that they tried to submit 12 hours later (which should have been drafted but nonetheless). More of an inconvenience than a mission critical addition.

Can you test to set this in base.py in the OTF instance?
SOCIAL_AUTH_SESSION_EXPIRATION = True
See https://python-social-auth.readthedocs.io/en/latest/configuration/settings.html#miscellaneous-settings
Then we can see if it works and what session length Google in that case sets.

oh perfect! I didn't even do a deep dive into the social auth so I'll change this today.

alright so turns out the Google OAuth expiry is one hour so that didn't workout too well hahaha. I already reverted it but it looks like we may need to put more dev time into OAuth + magic link remember mes

@wes-otf Found https://support.google.com/a/answer/7576830?hl=en#zippy=%2Cthird-party-identity-providers
Can you check and see if you pr @Techslammer can adjust this for OTF on the Google side?


[master] Bump Mesos to nightly master f852ffa

High-level description
This is a routine bump to the latest master branch of Mesos.
Related JIRA Issues
Checklist for all PRs

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Change log from the last Mesos version integrated:
mesosphere/mesos diff
dcos/dcos-mesos-modules diff
mesosphere/dcos-ee-mesos-modules diff
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

Corresponding EE PR: https://github.com/mesosphere/dcos-enterprise/pull/2593

@mesosphere-mergebot label Work In Progress

@orsenthil: Any ideas on why this PR is not getting the automatic WIP label? I have now fixed the bumpbot script and was trying to test it out :).

@mesosphere-mergebot label Work In Progress


Light position misaligned when moving

I noticed that depending on the direction I move, the lights are misaligned. Here I'm switching between two opposite directions.

Honestly it's a bit disorienting.

It seems that since the world is no longer drawn to a render target, we're writing the lights target before the world is drawn. This means the lights data is from the previous frame instead of the current one.
Changing the client to 12 FPS shows a huge difference when running left and right

If you have a high frame rate you'll hardly notice anything, but it's quite bad at lower frame rates.


Variable support

Definitely requires a fair amount of changes!
Basically, everywhere we kept track of queries, fragments, or selection sets before, we need to pass along variables now.
Fixes #31

This is a relatively straightforward change even though it is a lot of code, so I'm going to merge it. Have no idea why just one of the appveyor builds failed...

Oh, looks like the remote service didn't return a result... #14


ceylon.net: server.stop() doesn't work if called immediately after server.startInBackground()

When running the following code (as test in Eclipse)
shared class TestServer() {
    test
    shared void testServer(){
        value server = newServer {};
        server.startInBackground(SocketAddress("<IP_ADDRESS>", 8000));
        //Thread.sleep(100);
        server.stop();
    }
}

The server (and hence the test itself) doesn't stop. If Thread.sleep(100) is uncommented, it stops correctly.
Tested on Linux Mint 17 64 bits.

I believe the correct way do to this is:
	value server = newServer {};
	server.startInBackground(SocketAddress("<IP_ADDRESS>", 8000));
	server.addListener((status) {
		if (status == started) {
			server.stop();
		}
	});


[Bug]: Dimensional Painting pops off and is sent through itself to another dimension

General Info
<!-->

[x] I am running a modpack
[ ] I can reproduce this issue consistently

[ ] In single player
[ ] In multiplayer

[x] I have searched for this issue previously and it was either (1) not previously reported, or (2) previously fixed and I'm having the same problem.
[ ] I am crashing and can provide my crash report(s)
[x] I am using the latest version of the mod

Client Info

Minecraft Version: 1.16.5

Forge Version: 36.2.8

Mod Version: Dimensional-Paintings-1.16.5-1.1.2.jar

Java Version: Unknown/8u51

Modpack: FTB OceanBlock 1.5.0

Issue Description
We were trying to figure out how to use dimensional paintings, and trying different ways to make it work. I picked up and put down the painting, and my partner said "I wonder if we have to walk through it?"
He was behind the wall and broke the block behind it, which would cause a typical painting to pop off the wall. Instead, it totally disappeared! It's not the end of the world because we aren't hurting for resources, just a pain.
We built a 1 deep, 6 across, 4 tall wall of Cobble that had been chiseled to Tiles, and built stone brick stairs up to the level of the painting.
I placed it in the middle and breaking the block one in from the corner broke the painting.
WWWWWW
WPPPPW
WPPXPW
WWWWWW

(this is the wall, the X is where we broke)
He also broke the block above that first and it didn't affect the painting.
We both logged out and reloaded the world, to no avail.
Reproduce Steps
((We have not tried it more than once))

Create wall with chiseled cobble
Place painting on wall
Break block painting was placed against

Expected Behavior
Painting pops off and is NOT destroyed
Additional Information
UPDATE: So I made another one and went through the portal (after watching videos on how to) and my other nether portal painting was there, on the other side.
I'm relaying this issue from FTBTeam/FTB-Modpack-Issues#220
User is running FTB OceanBlock 1.5.0 on a server with a friend.
Please let me know if you think your mod is not the issue so I can try to look into other solutions perhaps.
Thank you!

Apparently I forgot to check if the painting entity was still alive while doing collision checks meaning it was going into itself instantly

That was indeed a funny interaction. Thank you for the very quick reply and fix :)


Add translations for 'how_we_help_lead_in' on homepage

Codecov Report

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

@@           Coverage Diff           @@
##           master     #102   +/-   ##
=======================================
  Coverage   94.12%   94.12%
=======================================
  Files          23       23
  Lines         528      528
=======================================
  Hits          497      497
  Misses         31       31

Impacted Files
Coverage Δ

home/translation.py
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 379bfe5...e0cf273. Read the comment docs.


split ceylon.buffer into ceylon.buffer & ceylon.convert

Looking at ceyon.buffer, it seems to me that buffering & encoding should be completely orthogonal features, and that encoding should be focused on a single lazy function:
{To*} encode({From*} input);

To that end, I've created herd.convert - code, docs.
The advantages are:

Simplicity of the API & implementation
Memory efficiency (nothing is buffered)
Composability (related to memory efficiency)
Performance (ceylon.buffer operations take 2.5x to 3x as long on the JVM)

Given this, I think we should split ceylon.buffer into a new ceylon.buffer module that includes only Buffer and associated classes, and ceylon.convert that includes base and characterset converters.
WDYT @ASzc, @gavinking, @FroMage?
(Note that the herd.convert api still looks very similar to ceyon.buffer.charset, but we should be able to make further simplifications and improvements.)

This is related to https://github.com/ceylon/ceylon-sdk/issues/593 and https://github.com/ceylon/ceylon-sdk/issues/594.
cc @dlkw

I don't see a reason for a module split, other than purely organizational (which isn't enough to justify the end-user annoyance in my opinion). The reason buffer's creation was done as a split from io was because of the inherently JVM-only/non-JS nature of I/O operations. buffer has no potentially odious dependencies either, that someone wanting the functionality of the proposed convert module wouldn't want.
PieceConvert provides the fundamental functionality you're looking for, it would just need to be wrapped up in a mutable/lazy Iterable wrapper to create a function with the signature you propose.

other than purely organizational

It would also be for the noted benefits.

end-user annoyance

I think we'd want to deprecate the current packages, but keep them around for a while.

other than purely organizational

It would also be for the noted benefits.

If I understand the benefits correctly, they don't require an extra module. It can either replace the existing implementation of en-block encode/decode (but not encodeBuffer/decodeBuffer, or ChunkConverter, they are required for IO), or be added in parallel.

end-user annoyance

I think we'd want to deprecate the current packages, but keep them around for a while.

The annoyance I was referring to is from over-granularity of modules, which for me at least has lead to the thought process "why doesn't this module do x? I guess I need to dig around for the module that does, add it in, look at separate documentation, etc.". Without good justification (like the presence or lack of backend requirements), this hassle isn't worth creating.
I don't see which of the current packages would be deprecated.

The whole Codec formal type tree is needed to provide structure for the relationships between the different codec variants. This is especially important for the ceylon.buffer.base and ceylon.buffer.text Codecs, which I see are elided in the herd.convert prototype.

The ability to encode/decode directly into buffers is needed for efficient IO, which is the most common use case for Charset encoding/decoding. Plain encode/decode are there for testing mostly, not to be used in serious applications.

Hmm. I believe the lazy function in the issue description is more powerful and simple than the existing encode/decode and encodeBuffer/decodeBuffer functions, because if you really do need to eagerly materialize the entire stream, you can do String(stream), stream(), or CharacterBuffer(stream).
But we would need an answer for ChunkConvert and CumulativeConvert.

So, the discussion on ceylon/ceylon#6406 hints at a Stream I/O system based on Iterables, where each time and Iterator is created from that, the file is opened or the socket connection is duplicated. Don't quite know how a "sink"/output would work though, I guess a function that accepts a Iterable and doesn't return one.
Your proposed function would fit into that system quite nicely, as a translation layer for character sets, etc. Buffers wouldn't be involved.

Your proposed function would fit into that system quite nicely, as a translation layer for character sets, etc. Buffers wouldn't be involved.

Sadly, the implementation I posted doesn't seem to work at all for ChunkConvert, which, as I think you're suggesting, is needed for "push" processing. That puts us back to at least using (small) Buffers, at least within implementations of PieceConverters.
I'm inclined to

update my sample herd.convert code with a new version that goes back to the PieceConvert idea, which is necessary for ChunkConvert, but also has lazy encode/decode methods, re-written to be based on the PieceConverters. With what I currently have, the performance is somewhere between that of the original code I posted and the current SDK code.

close this issue, since a module split seems to make less sense if convert will just import buffer anyway.

Closing for the reasons above.


Experiment prop as sub tree

This PR adds support for rendering remote-ui sub tree as props.
Idea:
For Core:

Introduce new fragment type which can hold a sub tree.
Add fragment serializer for all component props before returning root tree to receiver callback.
Move / remove all fragment props whenever these actions happen: createComponent, updateProps, appendChild, removeChild, insertChildBefore. The important task here is keeping rootInternals.tops in sync.
Add renderer for RemoteFragment to RemoteComponent to render sub tree using same receiver.

For React:

Initiate a new reconciler for each sub tree. Turn out that if we reuse same reconciler for each fragment, the reconciler can just send delta update to remote receiver which is a plus.

Similar to how we can't restrict children for components, we can't restrict children inside fragments either.

I agree that validating children and sub tree are tricky. I was thinking I could make RemoteFragment as a generic interface. However, we need more validation than that.

Ready for another look