[examples] Solving the diffusion issue of incompatibility issue#3169

Updated GitHub documentation:

requirements.txt content is incompatible with the version and cannot be downloaded. It is recommended to change the content opencv-python==4.6.0 to opencv-python==<IP_ADDRESS> (otherwise an error will be reported saying that the corresponding version cannot be found). Similarly, torchmetrics==0.6 should be changed into torchmetrics==0.7 (otherwise it will raise an error of incompatibility)

The instructions 'pip install colossalai' and 'pip install xformer' given in Readme will forward to the latest version. To download the suitable version for this training, pip install colossalai==0.2.5, pip install xformer==0.12.0 is recommended instead

Cuda version installation guide is added to Readme. The recommended version is cuda11.6 to 11.8.

Please resolve the conflicting files, thanks.
examples/images/diffusion/README.md

the PR looks good, but it still have some conflict, please run git pull origin main --rebase


Fix leader election

The test for eligibility for leader election is based on how long it's been since the client has received a WriteReq from prometheus. Therefore we need to record this time even if the client is not the leader.

(or after #237, it's already getting long)


Provisioning should include registering resource provider namespaces

Overview
When the necessary namespaces are not registered for Azure resources, provisioning will fail.
See this bug for an example:  #6747 I had this issue as well the first time I went through provisioning.  I thought it was just my old subscription, but this will happen to more folks out there.
I wrote a sample app to use the Azure APIs to register or unregister the Microsoft.Web namespace.  I timed how long it took to get to the desired state.
Registering: 78602 ms ~= 1 min 18 seconds
Unregistering: 614210 ms ~= 10 mins 14s
I see this behavior (or much worse) when using the Azure Portal directly. There is a SO post on it taking hours:
Proposed solution

We should have UI that lists the namespaces that need to be registered for a given profile based on the resources to be provisioned.  Each resource description should be updated with the namespaces it requires.
It is easy and quick to check if the namespaces are registered or not.
We can make all calls to register them in parallel and poll to wait for them to be registered before proceeding.
This process would need to be integrated into the design. We will also need to incorporate this into the design for other places in Composer where we provision any resource.
We may want to open an ICM ticket with the Azure team responsible for this registration if the time to register is too long.  Right now we could have our auth token expire because we would be waiting so long for the namespace to register.

@emivers8 do you have a deliverable here? We need to assess if this is R14'able or not.


Strapi v5 Beta

Strapi v5 Beta is out, would be nice to have support for it.
More info here: https://strapi.io/five

stapi already been RC

any updates?

FYI: https://github.com/nuxt-modules/strapi/pull/424

@XanderD99  awesome, closing this


ReLu function max(0,a) gives 0

Using Ladybug pic as an example, the ReLU function after the top one layer (orange colour) gives 0 when the max value is not zero. For example, I got max(0,0.64)=0. Should it be 0.64? Thank you.

Hello @jeromecy, thanks for reaching out to us!
In which ReLU layer did you see the max(0, 0.64)=0 case?
I am looking at the relu_2_2 layer for the laydybug pic and it looks correct.

Hi @xiaohk , many thanks for the reply. I apologies that it was my bad. The negative sign is too small on my screen, and I didn't notice it. After zooming in, I can see it clearly. Thank you so much!

Hey @jeromecy, you should not apologize! It's a legit usability issue, and we should apologize for the confusion. Thanks again for raising the issue so we can improve the design!
In b9c1759050033850d4245d1a85bb74c475aa377e I changed the original - sign (Hyphen-Minus) to a longer － sign (Fullwidth Hyphen-Minus). I hope it can help. Below is a before and after comparison.


Github fork issue

Crypt keeper is showing up as a fork of another project that we don't know about

Thanks @AtHeartEngineer for resolving this.


go: Generate static roles

Codecov Report
Base: 98.08% // Head: 98.08% // No change to project coverage :thumbsup:

Coverage data is based on head (9332caa) compared to base (fe9cfdc).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #427   +/-   ##
=======================================
  Coverage   98.08%   98.08%
=======================================
  Files          13       13
  Lines        2245     2245
=======================================
  Hits         2202     2202
  Misses         43       43

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Clarify permanence

This PR further clarifies the permanence of the published modules. It might change in the future but for now this is a better depiction.
Thanks to Bjørn!

Looks good to me @chartgerink!

@all-contributors add @bbartholdy for content


Make sure status is updated as HEALTHY

@howardjohn need to make sure status is updated as HEALTHY Please take a review. Thanks

@irisdingbj: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
959e27f4af49d5e6a8d8c0ebeeff2bc461d15787
link
/test pilot-multicluster-e2e_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test pilot-multicluster-e2e_istio

@irisdingbj: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

unit-tests_istio
959e27f4af49d5e6a8d8c0ebeeff2bc461d15787
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test unit-tests_istio

@irisdingbj: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
959e27f4af49d5e6a8d8c0ebeeff2bc461d15787
link
/test pilot-multicluster-e2e_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test pilot-multicluster-e2e_istio


It doesn't work

I'm using Atom 1.9.9 on OSX and I already installed this package and when I press ctrl + alt + s nothing happens, I already tried executing the command directly and nothing happens too.

Now you can support this Wish from https://beerpay.io/hashdog/scrapfy-atom/wishes/57c987b758bb2e287854c782
🍻 Cheers!

Wish granted successfully on Beerpay! https://beerpay.io/hashdog/scrapfy-atom/wishes/57c987b758bb2e287854c782
This issue will be closed.
🍻 Cheers!


fix: remove logging in load balancing dataloader to avoid potential d…

…eadlocks

since @wangraying is on her PTO, @NOBLES5E commits requested changes


Additional check for SU binaries

Hallo guys,
should we add this binaries too?
/system/bin/su
/system/xbin/su
/sbin/su
/system/su
/system/bin/.ext/.su

or this is already inside of our constants
https://github.com/scottyab/rootbeer/blob/79592a7ca16529eb2c6f1d445a2954f09627529f/rootbeerlib/src/main/java/com/scottyab/rootbeer/Const.java#L50-L80
From:
https://owasp.org/www-project-mobile-top-10/2016-risks/m8-code-tampering
https://owasp.org/www-project-mobile-top-10/2014-risks/m10-lack-of-binary-protections

Hi @WuglyakBolgoink The I added in a function that check the PATH environment variable to automatically account for any paths we've missed. This means we don't really need to keep modifying our list of paths to check anymore. This is because for the SU binary to be useful it needs to reside in a folder defined by the PATH variable, so we can use this feature to help us hunt for it.
Code is below:
    /**
     * Get a list of paths to check for binaries
     *
     * @return List of paths to check, using a combination of a static list and those paths
     * listed in the PATH environment variable.
     */
    static String[] getPaths(){
        ArrayList<String> paths = new ArrayList<>(Arrays.asList(suPaths));

        String sysPaths = System.getenv("PATH");

        // If we can't get the path variable just return the static paths
        if (sysPaths == null || "".equals(sysPaths)){
            return paths.toArray(new String[0]);
        }

        for (String path : sysPaths.split(":")){

            if (!path.endsWith("/")){
                path = path + '/';
            }

            if (!paths.contains(path)){
                paths.add(path);
            }
        }

        return paths.toArray(new String[0]);
    }

@stealthcopter thx for information


Switch from broadcast to multicast discovery

This is needed for IPv6 support. Since this is a breaking change, merge close to the v21 stable release.

This has been resolved by the switch to mdns, right?

Yes, this has been merged, and version bumped to v21.0.0-dev01


Add example encoder config option

Closes #105

Hi @SMILEY4, is there anything I can help with to get this PR merged?

sry for the delay. PR looks good in my opinion - there is an open question of understanding from my side but i think we can still merge it. I'll try to close it soon and release a new version for it.


Enddat 188

Added the ACIS service to the application. The service responds with JSON and all information needed to make the processing calls are included in the response. Was able to extend the standard Backbone fetch rather than redefining the whole method for the ACISCollection.
Sites show up on the map, but selected an ACIS site does nothing. Implementation of the next steps are part of ENDDAT-189.

Might take this opportunity to poke at the Backbone documentation and tutorials so I can figure out what's going on.

I'm going to merge this so I can make the next pull request.


refactor: reduce number of args for post_block_balance_increments

this could be slightly problematic in the near future when we consider different block types, although this should then be solved with a trait instead. because this is a byproduct of the block, makes more sense to provide the block as the argument and I agree this change makes it a lot easier to read

yeah it was with the aim of progressive change, this was the first step towards more abstraction imo


[CI:DOCS] Add pre-commit (app) hook to check IMGSFX

Intended for use by the pre-commit
app, this hook keeps track of all IMGSFX values pushed, failing when any duplicate is found.  In the case of pushing to PRs that don't build CI VM images, the hook failure must be manually bypassed.  Example .pre-commit-config.yaml:
---
repos:
  - repo: https://github.com/containers/automation_images.git
    rev: <tag or commit sha>
    hooks:
      - id: check-imgsfx

Manually tested with:
pre-commit try-repo . check-imgsfx --verbose --all-files --hook-stage pre-push
Correctly throws error:
Check IMGSFX for accidental reuse........................................Failed
- hook id: check-imgsfx
- duration: 0s
- exit code: 1

FATAL: 20240620t153000z-f40f39d13 has already been used
Please rerun 'make IMG_SFX'

If I then make IMG_SFX and stage it, running the same command returns:
Check IMGSFX for accidental reuse........................................Passed
- hook id: check-imgsfx
- duration: 0s

force-push: Renamed all IMGSFX references to IMG_SFX.

@edsantiago PTAL, even if you don't use the pre-commit app, I'd appreciate a quick look-through for any typos I may have made.
After this merges, my intention is to open a followup with an example .pre-commit-config.yaml file specific to this repo.  In addition to your neat IMG_SFX check, it will also validates yaml, EOF, trailing whitespace, shellcheck, and a few more.  But I need a commit-id on main to reference for the new check-imgsfx.

Force-push: Remove use of $HOME based storage of history.  Add intended use/purpose comment block to script.
@edsantiago this is ready for final review/merging.  I'll start working on a followup PR to add an example pre-commit configuration file.


Enable calls for dev in polkatot-v0.9.19 branch

Don't merge and don't delete the branch. The worker will depend on this branch.

Is this branch still needed?


Pitclipse JUnit 5 support cannot be (easily) installed

Bug description
This is a follow-up of #116 but I decided to create a new issue to draw attention. I think this should be marked as critical.
The current version 2.1.1 deployed to the composite and main update site https://dl.bintray.com/kazejiyu/Pitclipse/updates/ will not allow you to properly and easily install JUnit 5 support of pitclipse (that is, the bundle org.pitest.pitest-junit5-plugin).
That is due to the fact that the feature org.pitest.feature has been published several times in different children of the main composite site with the same version 1.4.11 but with different contents (i.e., requirements of org.pitest.pitest-junit5-plugin). That is, in the child update site http://dl.bintray.com/kazejiyu/Pitclipse/releases/2.1.0/ the feature does NOT include org.pitest.pitest-junit5-plugin, while in the child update site http://dl.bintray.com/kazejiyu/Pitclipse/releases/2.1.1/ the feature INCLUDES org.pitest.pitest-junit5-plugin.
However, Eclipse p2 does not check the contents when installing and takes into consideration the version only. If it inspects the first update site child first (which I think it's the default behavior, but I cannot guarantee that this strategy is deterministic), it will install org.pitest.feature 1.4.11 WITHOUT org.pitest.pitest-junit5-plugin. After that, there's no way of forcing it to install (actually update) org.pitest.feature 1.4.11 even if specifying only the http://dl.bintray.com/kazejiyu/Pitclipse/releases/2.1.1/. In fact, that feature has already been installed, and, even there's a new JAR with different contents it will be ignored since it has exactly the same version (again, actually p2 will not even detect that there's a new version since the versions are exactly the same).
Thus, after the damage is done, fixing it might not be easy for standard users: you have to uninstall "Pitclipse UI", remove the composite update site (https://dl.bintray.com/kazejiyu/Pitclipse/updates/) add only the latest single update site (http://dl.bintray.com/kazejiyu/Pitclipse/releases/2.1.1/) and finally install "Pitclipse UI" that will also pick org.pitest.pitest-junit5-plugin).
In the presence of p2 caches, the fix might also not even work.
One of the golden rules of p2 is: NEVER EVER publish p2 artifacts with the same version but with different contents: you will destroy completely the user experience and it might not even be easy for non-advanced users to fix the problem. In general, it is best practice to always publish p2 artifacts with a build qualifier to make them always different. Maven/Tycho automatically handles that if you add .qualifier and -SNAPSHOT to Eclipse metadata and POMs, respectively: it will replace the qualifier with a build qualifier using the current time stamp. It's also possible to have Tycho produce the same build qualifier if nothing has changed (using Git information), but again this requires careful attention. This way, even if you publish exactly the same artifacts (features and bundles) with exactly the same contents they will have different versions in the end.
Please let me know if you want me to open a new issue for that and if you need help with a PR.
Of course, the alternative is to make sure to bump at least the "patch" versions of all the Pitclipse bundles and features and publish a new child update site in the composite main site. However, as said above, not using build qualifiers in version is error prone.
Expected behavior
By installing "Pitclipse UI", the JUnit 5 support should be also installed.
How to reproduce
Steps to reproduce the behavior:

Download a fresh Java distribution from Eclipse
"Install New Software..." and "Work with" https://dl.bintray.com/kazejiyu/Pitclipse/updates/
Select "Pitclipse UI" version 2.1.1 (currently the latest one)
Press "Finish" and restart Eclipse after installation
Inspect the "Installation Details" (using "About Eclipse IDE) and in the tab "Plug-ins" verify that org.pitest.pitest-junit5-plugin is NOT installed.

And by the way, the versions in the git repository are still 2.1.0?

And by the way, the versions in the git repository are still 2.1.0?

And by the way, the versions in the git repository are still 2.1.0?

Looks like I never took the time to merge the 116-detect-junit5-provided-by-maven-or-gradle branch...

not using build qualifiers in version is error prone

For sure. I got rid of them because I thought it was cleaner to just update the version number but it truly was a terrible idea and it caused a real mess. Thank you for the insights, you can be sure I won't reoffend.


Cypress test. Group features.

Cypress test. Group features.
Motivation and context

How has this been tested?

Checklist

[x] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage increased (+0.07%) to 61.601% when pulling 9f11361ad06800b14cf4bd56664d8fe1f99a4155 on dvkruchinin:dkru/cypress_test_case15_group_features into 3b29621c721d3d8ef314fdb8dd6b7964695e4fe7 on openvinotoolkit:develop.


Scan QR from album - very handy from mobile-to-mobile

Updated screen is here https://zpl.io/29OQ5JB

no permissions to read and write files.

@Miolin Please, add haptic feedback if the user scans or selects from the album QR-code does not contain our address

checked


update deps

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (9348a6f) to head (2024a2a).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              main        #9   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          229       229
=========================================
  Hits           229       229

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


🚛 Upgrade babel-plugin-styled-components to 1.10.6 from 1.8.0

🚨 Add babel-plugin-styled-components to .babelrc
🚨 Update yarn.lock
Sorry if it was intentional to not have this plugin in .babelrc.
Feel free to close this PR if you think it doesn't add value!

Thanks for this. I don't think this is intentional.
@allcontributors please add @rahulakrishna for tool


cgroups: Fix race to load cgroup.hostRoot option

While loading, the package pkg/cgroups/manager sets the global variable cgroupRoot from the pkg/cgroups package.
This occurs before the configuration is fully loaded and the correct path is set in the pkg/cgroups package.
This variable is later used by the validateCgroupPath function.
As a result, the validateCgroupPath function always works with the default value instead of the user-defined one.
While using --set cgroup.autoMount.enabled=false and --set cgroup.hostRoot=/sys/fs/cgroup options, this might lead strange errors like:
level=info msg="  --cgroup-root='/sys/fs/cgroup'" subsys=daemon
level=info msg="Mounted cgroupv2 filesystem at /sys/fs/cgroup" subsys=cgroups
level=warning msg="No valid cgroup base path found: socket load-balancing tracing with Hubble will not work.See the kubeproxy-free guide for more details." subsys=cgroup-manager

And path /sys/fs/cgroup/kubepods correctly existing.
cgroups: Fix race to load cgroup.hostRoot option

Thanks @kvaps, the change looks great! However, it breaks the pkg/cgroups/manager/manager_test.go and the pkg/cgroups/manager/provider_test.go tests, as they use the variable you've removed. Could you please patch the tests as well?

Yeah, sorry, added it to provider_test.go

@kvaps thanks. Could you also please rebase on top of main?

Sure, done

/test


WebHost needs an error flag

When the setting CaptureStartupErrors is set to True and you do Db initialization after building the WebHost there is no way to tell if an exception has occured during configuration. In my case I am getting a service from WebHost.Services which throws an exception because it doesn't exist. The end result is not seeing the configuration exception

@divega @ajcvickers This is a result of doing more things in Program.Main instead of Startup. That change that we made to the pattern in 2.1 means that you don't catch these errors anymore. Do you guys have any thoughts on this?

                public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
                WebHost.CreateDefaultBuilder(args)
                .UseSetting("detailedErrors", "true")
                .CaptureStartupErrors(true)
                .UseKestrel(options =>
                {
                    options.AddServerHeader = false;
                }
                )
                .UseAutofac()
                .UseConfiguration(Configuration)
                .UseSerilog()
                .UseStartup<TStartup>();

                var host = CreateWebHostBuilder(args).Build();

                //Db initialization
                using (var scope = host.Services.CreateScope())
                {
                    var services = scope.ServiceProvider;
                     //Throws Exception
                    var taskRunner = services.GetRequiredService<TaskRunner>();

                }

                host.Run();

For the time being will use services.GetService instead and check for null but would be nice to have a flag

@davidfowl he's not asking about catching the EF error but being able to see the underlying Startup error, or at least see that there was one captured.

I see, I misunderstood. We could store the exception and expose it on a service I guess. Is that what you're asking for? Why are you using CaptureStartupErrors in the first place? Why not let it throw and catch yourself.

@davidfowl I do that for unhandled exceptions while the host is running but I like the idea of displaying the error page for startup configuration exceptions

So you just want access to the exception so you can log it again? (The web host already logs it).

Use it to avoid EF Code


Control log level of _endpointOffline log line

Is your feature request related to a problem? Please describe.
When making rolling deployments (i.e. in pod rotations in Kubernetes), we are seeing the following error in our logs:
Hub '{hub}' is now disconnected from '{endpoint}'. Please check log for detailed info.
We're treating logs of Error level as scenarios, where something is really wrong and something that developers needs to pay attention to immediately - and in this case, we don't have any control over the level of this log line because it's set up within ServiceConnectionContainerBase.cs
Ideally, we'd like to have it only as a warning since we know that it does happen when making a rolling deployment.
Describe the solution you'd like
Either:

Simply lowering the _endpointOffline to Warning or
Use a named logger so the consumers are able to control/override the log level using Serilog

Additional context
We've configured Azure SignalR to gracefully shutdown and migrate client connections, like so:
builder.Services.AddSignalR()
        .AddAzureSignalR(option =>
        {
            option.GracefulShutdown.Mode = GracefulShutdownMode.MigrateClients;
            option.GracefulShutdown.Timeout = TimeSpan.FromSeconds(30);
        })

We're using Serilog to handle the logging for us.

Lowering the _endpointOffline to Warning makes sense to me, since we will throw exceptions when there is real impact, for example, when sending message fails.


Decorative Blocks for new train system

Add automatable blocks all of which would look good used in trains / train stations
Mod Link:
](https://www.curseforge.com/minecraft/mc-mods/create-deco)


Upgrade to asciidoctor-diagram 1.5.5 not working

This issue continues asciidoctor/asciidoctor-diagram/issues/159
The Jars in Asciidoctor-Diagram are now loaded by a ServiceLoader.
Therefore they are not available to the Classloader.
It looks like the jars have to be unpacked and the Services files have to be merged.

I guess this is the reason why there isn't a asciidoctorj-Diagram 1.5.5 release yet?
...and this blocks an upgrade to asciidoctorj 1.5.6 because it seems to need diagram.1.5.5 in order to work:
https://github.com/asciidoctor/asciidoctor-diagram/issues/154
it there any way I can support fixing this bug?

I have no idea how to fix this atm.
A fix in Asciidoctorj would be to set the TCCL to the JRubyClassLoader.
I am reluctant though to do this because it would very likely break all extensions that rely on the TCCL, for example extensions running in a JavaEE environment.
A fix in asciidoctor-diagram would be to not only load extensions via the TCCL but also the classloader that loaded the asciidoctor-diagram CommandServer that loads the processors per diagram type, which should be the JRubyClassLoader: https://github.com/asciidoctor/asciidoctor-diagram-java/blob/f411d662fddc3e06d99108687122769d1270ed42/server/src/main/java/org/asciidoctor/diagram/CommandServer.java#L40

The related issue is now closed. Does that mean this issue is resolved?

Oh yes! Thanks!


Add running web interface in Runner with Gradio

close #616
There are limitations to running the web interface with Streamlit when using custom models (embedding, llm).

Use Gradio
This PR uses Gradio as the web interface because it can be run in the same process that defined the custom model.
Fix error of get_event_loop
When running web with Gradio, I faced an error in loop = asyncio.get_event_loop() in the autorag module. Here is the detailed error log.

loop = asyncio.get_event_loop()
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/anaconda3/envs/autorag/lib/python3.11/asyncio/events.py", line 681, in get_event_loop
    raise RuntimeError('There is no current event loop in thread %r.'
RuntimeError: There is no current event loop in thread 'AnyIO worker thread'.

I've modified it to create a new event loop when there is no running one, since it presumably doesn't have a running one, and the official asyncio documentation recommends using get_running_event_loop() rather than get_event_loop().

Apply ruff linter
I applied ruff linter mentioned in #621.

Hi @rjwharry
Maybe there is so much conflict after I merged Linter to main.
It will be better to close the PR and make a new one from current main branch.
It looks unsolvable manually....

Okay, I close this PR by myself and recreate new one


Fix a bug where player angle was wrongly tested around 360

@dploeger Thank you so much, you just nailed it!


Intellij Idea Class Resolving Issue

Actually I have an issue in the idea. I tried to test the example from https://www.baeldung.com/java-mongodb and I've got this annoying "cannot find symbol" error
What should I do in this case?

@Artemsetko did you import your project as a Maven one? Also, we can suggest using Maven update to re-download the dependencies. If the problem still persists please let us know.


Split calculator.py into a subpackage

Split calculatordata.py into a subpackage of calculator. Have the functions pass around a calculatordata object

Unit tests pass. Functional tests pass.


(docs/typing) refinement's s.fail returns void despite being thrown

This works runtime and compile time, but just has a bit weird typing: I haven't encountered "voids" being thrown before
ref: https://github.com/DZakh/rescript-schema/blob/main/docs/js-usage.md#refinements

Actually, s.fail throws itself, so it should probably return never instead. I'll fix it 🫡

Done in 8.0.3


add roboGuice

@aleffert  please review
integrate roboGuice.  as QEI continues to use roboGuice as DI framework, it does not make sense to introduce different DI such as Dagger.
aslo   provides initial support for roboGuice + robolectric, it will be in a separate PR
cc @1zaman

:+1:


warsow: clean up

Motivation for this change
- Do not contaminate builder environment with libraries, substitute them in the patch directly.

Switch to pname from name.
Run installPhase hooks.
Correct license.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Diff lgtm. Can you repair the passthru tests?

There are no passthru tests.


fixes Multimap::replace() #1474

Current coverage is 97.09% (diff: 0.00%)

Merging #1489 into master will increase coverage by 0.01%

@@             master      #1489   diff @@
==========================================
  Files            86         86
  Lines         10412      10412
  Methods           0          0
  Messages          0          0
  Branches       1823       1823
==========================================
+ Hits          10108      10110     +2
+ Misses          177        176     -1
+ Partials        127        126     -1

Powered by Codecov. Last update e2ef170...132f78e

Thanks!


Revert "possible GRS page publish ci"

Reverts AminoffZ/github-repo-size#67

@mAmineChniti node:inspector isn't supported by bun yet. i had planned to create a workaround to make deployments with bun work as intended. until they support it i'm gonna shelf this. it's not too much work to manually run deploy dw.


User is not able to override skip from API on entering a blank value in skip

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):

On a cluster, Run Scans
When the report generates, on any failed test, click on Skip. (when you go to the report details page)
Now run the Scan again.
Verify the report. The test marked as skip, will be skipped.
From the API UI, click on runSecurityScan.
Leave the skip input textbox as blank. Click on Send request.

Request sent:
{
"debugMaster": false,
"debugWorker": false,
"skip": [ ]
}

Expected Result:
No tests should be skipped, as the skip value is blank.
Actual Result:
The test marked as Skip in Step 2, will be skipped. User is NOT able to override from the API.
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-head
Installation option (single install/HA): single

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): custom
Kubernetes version (use kubectl version):

1.16

The new skip value is no more an array of string. Here is a sample: {"skip": { "rke-cis-1.4": [ "1.1.1", "1.2.2"] }}

As per discussions, skip will continue to be an input of array of strings. Reopening this issue for the original issue to be fixed.

Verified on master head - commit id: 48a2c4ffc

On passing empty array in the API UI -

{
"debugMaster": false,
"debugWorker": false,
"overrideBenchmarkVersion": null,
"overrideSkip": [ ]
}

Security Scan runs fine from API UI.

From API

curl -u "<token>" \
-X POST \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
--data-binary '{"debugMaster":false,"debugWorker":false,"overrideBenchmarkVersion":null,"overrideSkip":[]}' \
'https://<rancher-server>/v3/clusters/c-xvwp2?action=runSecurityScan' --insecure

Security Scan runs fine from API.
Skips in the config map are overriden.
No skips happen in this particular run


Use extensible object syntax?

Would you be open to using an extensible key/value format, to future-proof reflection in case it's needed for other use cases, even though none are implemented now?
import JoyStyle from "./joy.css" as { type: "css", media: "(width > 640px)" }

I think the media example is really compelling! Whether it fits into import reflection or not I think the use case should be strongly considered within the realm of imports in general, and it's probably a good idea to consider how it intersects with reflection and assertions and whether we want potentially three related import features: assertions, reflection, and something else (attributes?).
As CSS module scripts are a way for a JS module to depend directly on CSS, it somewhat takes the place of <link> but embedded in the module graph rather than in the top-level HTML. However imports are missing some features of <link> notably the media attribute.
Adding a media attribute would enable a form of conditional imports that close the gap with <link>. I'm not sure where else conditional static imports might have been discussed, but I could see something like this:
import * as desktopStyles from "./desktop.css" assert { type: 'css'} with { media: '(width > 640px)' };
import * as mobileStyles from "./mobile.css" assert { type: 'css'} with { media: '(width <= 640px)' };

if (desktopStyles !== undefined) {
  document.adoptesStyleSheets.push(desktopStyles.default);
}
if (mobileStyles !== undefined) {
  document.adoptesStyleSheets.push(mobileStyles.default);
}

Other potential examples in some distant future might include:
import boldOpenSans from './OpenSans-Bold.woff' assert { type: 'font' } with { weight: 700 }

await boldOpenSans.load()

import bgm from './background-music.flac' with { loop: true }

bgm.addEventListener('canplaythrough', () => {
  roar.play()
})

import myWorker from './my-worker.js' with { type: 'worker' }

myWorker.postMessage({ cmd: 'start', msg: 'Hi' })

I think it would be great if a more extensible syntax were used rather than requiring a parser change each time a new attribute is introduced. There are a lot of potential use cases for import attributes, and I don't think it always necessarily makes sense for each one to go through the TC39 process since they won't be implemented by all engines (e.g. some attributes might not make sense in browsers). I raised this back on the import assertions proposal as well, and a number of good use cases came up there: https://github.com/tc39/proposal-import-assertions/issues/99.
For example, one thing that would be cool is support for preload/prefetch attributes. For example, something like this:
import foo from "./foo.js" with { load: "prefetch" };

// some time later...
const exports = await foo.get()

Somewhat related: #16.

@devongovett I wonder if a usecase like preload might not be better suited to a dedicated import.preload function in due course over attributes. Are there specific reasons you'd want attributes over a dynamic mechanism here?

Yeah might also be useful for some cases, e.g. on-demand preloading when a user hovers over a link.
I think one benefit of attributes is that they are much more easily statically analyzed. This not only benefits build tools, but could potentially benefit browsers and other runtimes as well. A quick pass could be done to determine what to preload without parsing and evaluating the entire module.
Btw, this was actually @littledan's idea, and there was some prior discussion about it here.
Another potential use case is lazy loading, i.e. subsuming https://github.com/tc39/proposal-defer-import-eval.

import.preload(specifier) would be just as statically analyzeable as import(specifier), as well as lintable (if you want to restrict it to a static specifier), no?

Yeah, but you have to evaluate the code to know when to preload, whereas a declarative import statement allows immediate preloading without fully parsing or running any code. Browser engineers could tell us if that's useful, but seems like it could be (esp if it supported non-JS resources, i.e. subsuming asset references - #16).
I also like the idea that it could be done the same way either as an import statement or a dynamic import.
import foo from "./foo.js" with { load: "prefetch" };

import(foo, {with: {load: 'prefetch' }});

Given that import.preload would be syntactic, it would show up on a first parse (which engines have to do anyways to hoist import statements), so it doesn't seem like there'd be a need to run any code if the argument is a static string.

<link rel=modulepreload> is the early hint for browsers, and is preferable to discovered preloads (which involves latency) for the static case.

Sure, for initial page loads but would be nice to have a way to preload things for later loaded things other than insert one of those into the document manually.
Anyway, this is all kinda off topic. I am mainly interested in having a syntax that is forward compatible with future additions, as well as extensible for build tools to innovate in this space without waiting for TC39.

Sure, for initial page loads but would be nice to have a way to preload things for later loaded things other than insert one of those into the document manually.

This is a great discussion and one I would love to have further.

Anyway, this is all kinda off topic. I am mainly interested in having a syntax that is forward compatible with future additions, as well as extensible for build tools to innovate in this space without waiting for TC39.

I don't think it's at all off-topic, we should discuss features in the context of use cases. The more use case discussions the better.

I don't think it's at all off-topic, we should discuss features in the context of use cases. The more use case discussions the better.

I appreciate the optimism, and what you write is true, but it’s also incomplete. For me, an extensible API delivered in a timely manner is important, because I’m concerned a lot folks don’t understand the needs of source file tooling, and I want some space to innovate.
I’m not super encouraged to lean into a conversation about use cases if I’m concerned it won’t go anywhere.

Watching as a build tool author’s 2020 thread fizzles in 2 weeks, I sense a fleeting interest in understanding my environment.
Watching as a TC39 delegate dismisses another build tool author, I sense an outright lack of interest in understanding my environment.

I’m not super encouraged to lean into a conversation about uses cases if I’m concerned delegates and advocates misunderstand my environment, anyway.

“Content type on the local FS can only be derived from file extensions.”
— https://twitter.com/lcasdev/status/1495743689930457095

”Do you not have file extensions?”
— https://twitter.com/justinfagnani/status/1481446609128865796

Meanwhile...

”... the only change i do now is .js > open all files as > javascript > jsx. that’s all”
— https://twitter.com/dan_abramov/status/1488956873390923780

“In Next.js, a page is a React Component exported from a .js, .jsx, .ts, or .tsx file”
— https://nextjs.org/docs/basic-features/pages

Finally, I see a not insignificant number of features that would require different keywords to accomplish what we want from one.
Still, here’s another 'transform' use case I was reviewing, borrowing Justin’s syntax:
import images from './profile.jpg' as 'image-set' with { size: [ 320, 480, 640 ], type: [ 'avif', 'webp' ] }

I think that there seem to be two related but distinct use-cases that are floating around in this discussion. I believe that they may receive better attention if they were explicitly called out.

Use cases that have semantic meaning for engines at runtime (ie: media queries, workers and prefetching).
Use cases that relate to passing intent from code authors to the wider tooling ecosystem and that should not have semantic meaning at runtime (ie: font weights, image optimizations, etc).

In the spirit of the types-as-comments spec, perhaps it would be worthwhile to think about some explicit namespace or mechanism for code authors to pass expressive intent to the tooling ecosystem. If that was a first-class concept then we might find ourselves avoiding situations where semantic concepts like import specifiers or assertions are being used in unintended ways to achieve important and necessary goals.

I agree that work should go towards a general, object-based syntax rather than a single string. Many other use cases have been discussed already, in the import assertions repo, when folks were arguing that it shouldn't be limited to assertions. On the other hand, I am unconvinced that the functionality exposed in this proposal is all that high priority. Rather than as for the keyword, I would prefer something which implies that the module will be changed, e.g. with.

After seeing the presentation at TC39 and talking more with @guybedford , I'm convinced that this proposal meets an important use case; I've striked out my comment above.
While I would prefer a general syntax exposing other parameters, but there's a legitimate concern that this would be blocked in committee, as @ljharb previously did. I don't think it's worth stopping this proposal in its tracks for such a broader generalization, though the generalization would be my preferred outcome. Overall, I agree with @jridgewell 's comment that we probably made an error in import assertions using the "assert" keyword and should've been more general in the first place (however, this preference contradicts the arguments that @ljharb and @devsnek previously made, and does not have TC39 consensus; in any case, it's too late to make changes in that proposal).
If we don't go with a generalized key-value pair, I'd suggest that we use some other syntax besides as, for all the reasons that as was rejected in the import assertions case. If we're going for something specific, let's be fully specific with a keyword indicating the change in mode of importing the module. So, for example, import reflective and import asset.
For now, I'd like to focus on working out the details of this proposal, especially how it relates to module blocks, compartments, module fragments, Wasm/ESM integration, Wasm components, etc. It's good to have this syntax debate running in the background, but let's not get too bogged down on it; I am confident that we'll be able to find some syntax or other which is agreeable, and we have a lot of other details to work out.

Thanks @littledan for clarifying here, we are open to using an alternative syntax to as and would like to explore these options further, in a way that can work with and leave the door open for evaluator attributes syntax. From our discussion I'm also confident we can find a suitable approach.
Agreed the primary proposal details to work out right now though are how a user-exposed JS module record gets specified between these proposals, and what other cross-cutting concerns apply. It definitely makes sense to continue to focus on that for now.

I'm disappointed to see the syntax has been changed to yet again use a static keyword in yet another position rather than an extensible syntax. Just like I raised for import assertions (https://github.com/tc39/proposal-import-assertions/issues/99), the syntax is not symmetric between dynamic and static imports. Dynamic imports use an extensible object syntax, whereas static imports do not. From the readme:
import asset x from "<specifier>";
await import("<specifier>", { reflect: "asset" });

If the import assertions proposal had used an extensible object syntax as raised then and in this issue, this proposal wouldn't even have been necessary. We could simply do this:
import x from '<specifier>' with { reflect: 'asset' };

This syntax would allow engines to add new attributes where it makes sense for them. Again, it's already the case with the second parameter to dynamic import, just not static import, and I really don't understand why. How long are we going to keep adding attributes to the language one by one? Why does each attribute need to be in a different part of the syntax?
Lots of tools and developers want to use import attributes of some kind, for purposes beyond just the ones specified. Many use cases are covered here and in the other issue linked above. Some tools have already started abusing import assertions for this, which is bad. In my strong opinion, this needs to be solved once and for all, and not by adding new attributes one by one every few years. Progress is too slow this way, and it doesn't leave enough room for tools and engines to innovate in their respective domains.

@devongovett tools that have abused import assertions for this sort of thing are likely violating the spec; while the spec has no enforcement power, it's very important that intentions be explicitly conveyed. "of some kind" is frighteningly vague, and I'd love to hear more concrete use cases if the existing proposals don't address them.

Here are two examples I saw recently where it happened. Not sure if either of them ended up shipping because it was called out, but still. The demand for more extensibility is there.

https://twitter.com/jarredsumner/status/1495004550507360262
https://twitter.com/patak_dev/status/1495673409044373508

Further discussion on both threads shows that neither of those tools were brazen enough to blatantly violate the spec - it remains a critical gate for the ecosystem.

@ljharb What is your opposition to extensibility at a syntax level? People have been raising this for years, and every time it just goes nowhere. Clear demand and use cases have been documented and discussed. Every time it's raised someone punts anything that isn't their exact problem to some other future proposal. When are we gonna solve this? What is the actual technical reason why we can't solve it once and for all rather than blocking all future features for module loading and evaluation on TC39 adding yet another new syntax?
The semantics of specific keys in an object syntax could be specified just as they are today for dynamic import. I see no difference between import asset x from '...' and import x from '...' with { reflect: 'asset' } from a semantic point of view, but the latter allows additional keys, as well as new values for the reflect key to be added without changing the parser. How is this not better?

I feel like having a relaxed syntax for import statements could really help the community as a whole.
A lot of different bundlers have different and custom syntaxes to be able to apply custom process pipelines to files:

webpack has loader!path
parcel has loader:path
vite has the query param syntax (see https://vitejs.dev/guide/features.html#static-assets) ./asset.js?url

Even though all of those don't have actual meaning during the runtime, having an extensible spec could allow for all the bundlers to give the possibility to follow a similar syntax and reduce the gap between all bundlers (and also allow to make bundlers feel like more align with the spec)
I opened in the past an issue to add the possibility in parcel to support this (see https://github.com/parcel-bundler/parcel/issues/7648) but @devongovett rejected this idea as it is out of scope (syntax assertions aren't supposed to be used for transformations).

The semantics of specific keys in an object syntax could be specified just as they are today for dynamic import. I see no difference between import asset x from '...' and import x from '...' with { reflect: 'asset' } from a semantic point of view, but the latter allows additional keys, as well as new values for the reflect key to be added without changing the parser.

If the concern is about future collisions between user-land metadata keys and keys having semantic meaning, then let's get ahead of the problem. Give us a metadata key or key prefix that is reserved for non-semantic purposes.
Tooling could then freely strip this syntax during optimization passes but runtimes would still be able to consume it as-is.
Reserved prefix:
import Article, { metadata } from './path/to/Article.mdx' with { 'x-loaders': ['mdx'] };

Would be symmetric to dynamic import:
const { default: Article, metadata } = await import('./path/to/Article.mdx', { 'x-loaders': ['mdx'] });

Reserved key:
import Article, { metadata } from './path/to/Article.mdx' with { extra: { loaders: ['mdx'] } };

Would also be symmetric to dynamic import:
const { default: Article, metadata } = await import('./path/to/Article.mdx', { extra: { loaders: ['mdx'] } });

@jridgewell it's the entire reason the feature is allowed to exist. If such things are "gleefully ignored", then that will just ensure that future dangerous features never advance. It's also disheartening for a TC39 delegate to be publicly advocating willfully violating the spec, and comes across as very bad-faith behavior.
Things can experiment with syntax all they want - it just makes them noncompliant.
@devongovett You can think it's better all you want, but unrestrained syntax experimentation is a net detriment for the ecosystem. We all benefit from interoperability, and that means that semantics have to be tightly specified and not wildly host-defined.
Tools can do whatever they want within specifiers already - that's the space for innovation. You don't need permanent, never-removable, expensive-to-implement syntax to test things out.

You can think it's better all you want, but unrestrained syntax experimentation is a net detriment for the ecosystem. We all benefit from interoperability, and that means that semantics have to be tightly specified and not wildly host-defined.

That's incorrect, the entire motivation behind import.meta is to be a random grab-bag of metadata which can be host or bundler defined. Having extensible metadata is a good and useful thing, as has been repeatedly proven both in the JS ecosystem and in other language's ecosystems.

@Pauan that's for metadata for a module author, which is quite distinct from a module importer, by design.

@ljharb And? That doesn't make any difference, it's useful in both cases, you're trying to make a distinction which doesn't exist. People have provided multiple use cases for extensible properties on imports.
And in both the case of import.meta and import x from '...' with { foo: 'bar' } the behavior is specified by the bundler or host. So all of your arguments apply equally to import.meta.

It makes a huge difference. A module shouldn't behave differently based on who is importing it - metadata should come FROM a module or be provided to it by a host, not be passed to it by a consumer.

You can think it's better all you want, but unrestrained syntax experimentation is a net detriment for the ecosystem.

That is the entire point of making it extensible - so that we don't have to change the syntax in order to experiment or add future standard features. As stated before, the goal of interoperability is not hindered by an extensible syntax. Semantics can be specified based on keys within an object, just as they are for dynamic import already. Why do you think static imports are different?

i think extensibility is good but i am also concerned about attributes which would fork a module into multiple instances. imo those should have to be part of the specifier (or to think about it another way, these module attributes should not be considered when keying a cache). this sort of leaves my opinion in a deadlock... i'll try to think about this some more but just wanted to mention it.

i think extensibility is good but i am also concerned about attributes which would fork a module into multiple instances. imo those should have to be part of the specifier

@devsnek I think you make a good point and perhaps the first compelling point against arbitrary evaluator attributes.
If there was a reserved space for non-semantic evaluator attributes, then I think the spec would have to be clear that these would have absolutely no impact on module identity. It would follow that tooling would therefore have to manipulate the import specifier in generated code if it wanted to allow different attributes to produce different outcomes.
The important part, I think, is that it would give developers a spec-compliant place to signal rich intent to their tooling. The kind of expressiveness that translates very poorly to url query overloads. Tools have been making great use of import.meta as a namespace for extensibility and I think this would have a comparable impact.

i think extensibility is good but i am also concerned about attributes which would fork a module into multiple instances.

That's a good reason to define the semantics of specific keys, but doesn't explain why it must be done with a keyword. Clearly, these have different semantics:
import('specifier');
import('specifier', {reflect: 'module'});
import('specifier', {reflect: 'asset'});

Therefore, reflect is part of the cache key. On the other hand, assert is not. Other keys that are defined besides reflect and assert are ignored by the engine. All of this is part of the spec.
Why can't the same be done for import statements?
import foo from 'specifier';
import foo from 'specifier' with {reflect: 'module'};
import foo from 'specifier' with {reflect: 'asset'};

My point is, the syntax can be extensible, while still defining the semantics as you have been. As it is, the syntax for dynamic import already allows this, so I don't see a reason why it cannot also be done for import statements.

If such things are "gleefully ignored", then that will just ensure that future dangerous features, including this one, never advance.

I should have used willful violation. The restriction is unnecessary for bundlers, and forces their users into a considerably worse hack. If we actually cared enough to make it non-dangerous, we would specify an extension space as https://github.com/tc39/proposal-import-reflection/issues/18#issuecomment-1189690226 nicely explains.

It's also disheartening for a TC39 delegate to be publicly advocating willfully violating the spec, and comes across as very bad-faith behavior.

Again, it's a completely unnecessary runtime restriction. Should we specify that you're forbidden from monkey patching the globals prototypes, too?

Things can experiment with syntax all they want - it just makes them noncompliant.

Sure, I never argued that they should be considered valid production code. Shipping an unsupported import assertion to production should be discouraged, but having the bundler transform it beforehand is fine. Else, we should remove every non-stage-4 feature from every codebase, because they're not valid syntax either.

You can think it's better all you want, but unrestrained syntax experimentation is a net detriment for the ecosystem. We all benefit from interoperability, and that means that semantics have to be tightly specified and not wildly host-defined.

We're already hurting from the restriction. We have to invent an entirely new syntax to support import reflection, because we don't want to allow the reflection to be specified in the assertion. Of course having it inside an assert {} block is weird, but we should have seen this coming and stuck with as {}.

My point is, the syntax can be extensible, while still defining the semantics as you have been. As it is, the syntax for dynamic import already allows this, so I don't see a reason why it cannot also be done for import statements.

This is my sentiment exactly.

@devsnek Note that modules are already modified based on who imports them. The identity (and caching) of modules already takes into account more than just the import path, and therefore modules can already be forked even if they have the same import path.

@Pauan yep i'm aware of module caching semantics. for the purposes of the spec i scope my concerns to imports within the same file. there is some prior art here as well in the assert proposal.

@devsnek Even within the same module, if you import it differently then it will "fork" it (see @devongovett 's comment). There are several use cases for forking modules. For example, you already know that bundlers want to import Wasm modules, not instances. Putting a hard "no forking" policy will hurt the JS ecosystem and cut off many important use cases.

reflect does not fork it to my knowledge. its returning a different attribute of the same cache entry (the module vs the module's namespace)

@Pauan the cache isn’t part of the spec and isn’t the module; and the concern isn’t duplicating it; it’s altering it. It’s fine to have a million conceptually identical instances from the same specifier; it’s not acceptable to have even two conceptually distinct instances from the same specifier.

@ljharb You're simply incorrect. Go read the thread I linked to.
The cache is a part of the ES6 spec, and it is specified based on an (importingModule, specifier) tuple. Which means that it's possible for the same specifier to return a completely different module.
Which is why import { currentScript, url } from "js:context"; was discussed as a possible alternative to import.meta.url, because the "js:context" module can be different every time it is imported.
And if desired, it would be possible to spec it so that the cache is based on an (importingModule, specifier, metadata) tuple, so that way modules with different metadata can resolve to different modules.

That is a fair point. None the less, you can’t import the same specifier twice in the same file and get different modules, except in cases of pathological server behavior with a remote module.

Hi all, I just want to bring up a concern I have with media queries in particular. How do people interpret this code snippet?
import JoyStyle from "./joy.css" as { type: "css", media: "(width > 640px)" }

There’s a number of interpretations I see:

A: Only import this if the viewport at the time of initial load is greater than 640 pixels.
B: Dynamically evaluate the media query of "(width > 640px)" whenever the viewport changes (say if the user changes the width of their window). Does mean the entire module is evaluated again, because the following logic might have changed?
Something else?

I’m curious what @jonathantneal was intending.
From @justinfagnani example here it seems like A is the interpretation:
import * as desktopStyles from './desktop.css' assert { type: 'css'} with { media: '(width > 640px)' };
import * as mobileStyles from './mobile.css' assert { type: 'css'} with { media: '(width <= 640px)' };

if (desktopStyles !== undefined) {
  document.adoptesStyleSheets.push(desktopStyles.default);
}
if (mobileStyles !== undefined) {
  document.adoptesStyleSheets.push(mobileStyles.default);
}

The problem is that this is evaluating it only at the initial load time is that the window might be resized (say on a laptop or tablet), and now the other styles should be applied but they since they were initially undefined the page doesn’t work as expected. Which means the user would have to reload the page.
<link> tags today don’t have this problem, they are independent and don’t affect each other directly. Which means they can load if say the viewport changes in size.

You've hit the nail on the head that media queries are closer to conditional loading than a loading attribute.
The recommended pattern today would probably be the following:
await import(matchMedia('(width > 640px)') ? './desktop.css' : './mobile.css', { assert: { 'type': 'css' });

Moving this from a dynamic import into a static import you'd then effectively want the static import to reify the media query into something like a conditional export mechanism.
There are a couple of ways to do conditional exports statically:

At the resolution level - the import map, or load-time dynamic import map generation could handle this in the import map itself.
Statically at the resolution level - having import maps somehow support conditional branches which can be enabled or disabled, something like Node.js package exports conditions.
At the actual syntax level - designing a conditional import syntax at imports like your example

Note that a conditional import system that nulls its imports on predicate results basically means a DSL or out-of-band configuration system. Hard-coding media queries is fine, but it's difficult to see how that generalizes easily at all given we don't have many other similar DSLs on the work.
It's probably worth addressing the merits of the first dynamic import example, and (1) above as well before considering such an option.

Yes I agree we should be more eager to use dynamic imports — especially if what we are doing is actually dynamic.
With your example, how would you handle reevaluating the media query when the viewport changed? This is still only “evaluate the media query at initialisation”:
await import(matchMedia('(width > 640px)') ? './desktop.css' : './mobile.css', { assert: { 'type': 'css' } });

The problems with dynamic import are the poor behavior of top-level await wrt to loading, and the likely incompatibility with prescanners.
TLA use will block importing modules from evaluating, which will delay their similar TLA+dynamic-imports, and so-on up to the root of the module graph.
Prescanners are very unlikely to understand the conditional logic and so won't be able to preload any resources. Being a built-in feature would enable preloading.
That is a very good question about what's expected to happen when media queries change. Answering that would be necessary, and some re-evaluation capability would be needed to match HTML.

It seems important to question which part of the code's lifecycle is targeted by the proposed syntax. It does seem like there are some compelling ways the intent could be encoded in today's primitives.
But what I find interesting is that it is very difficult to execute on that intent for the average dev. Doing so involves a depth of understanding that few people in the world hold. However, the proposed syntax and it's intent could be transformed by tooling into the right primitives if such syntax were available.
This is where I believe that the power of an extensible syntax lies, especially when it has no runtime semantics.

We already have infinitely extensible syntax with no runtime semantics - comments. Adding syntax that does nothing at runtime is adding a lot of cost for decidedly non universal value.

Still no one has answered why it's an object literal for dynamic import (in which unknown keys have no runtime semantics) but not import statements. Why can't the syntax be the same? Import assertions already define such a syntax, so clearly it's possible.

@devongovett because it can’t be any other way for dynamic imports (because JavaScript), and there was opposition to having to type the extra boilerplate every time for the syntax case.

I'm concerned that every time there's a new usecase for an import attribute, a new bespoke syntax will need to be invented making the import statement more and more complex, and slowing down the standards process. IMO a syntax more similar to import assertions would keep reflection in import statements both more consistent with dynamic import and with import assertions, and also more extensible for future use cases (which might not make sense for TC39 to standardize, but perhaps another standards body).

We already have infinitely extensible syntax with no runtime semantics - comments. Adding syntax that does nothing at runtime is adding a lot of cost for decidedly non universal value.
Out of Topic: That's how I think of the Type Comment proposal

We already have infinitely extensible syntax with no runtime semantics - comments. Adding syntax that does nothing at runtime is adding a lot of cost for decidedly non universal value.

Out of Topic: That's how I think of the Type Comment proposal

By this logic, we can call JS a complete language. Who needs pipelines, pattern matching, or import reflection? We can just add comments to the appropriate places and let the build steps magic everything together.

@devongovett yes, that is the exact idea. Adding something to the language is a permanent decision that can never be unmade; “time to add” is, in the long run, a negligible cost compared to permanent mistakes. Moving too fast breaks things, which slows down everything that comes after it. That’s the job of JS language stewards imo - to minimize mistakes, not to accelerate experimentation (which requires no standards process anyways)

@jridgewell i don’t think your slippery slope there is accurate. What may be an accurate logical extension is, that anything without runtime semantics can and perhaps should be achieved without any alterations to the language. Anything with runtime semantics, however, is unrelated to that logic.

Not everything can or should be standardized by TC39. What if browsers want a feature that doesn't make sense in other runtimes? Or the reverse? Is JS going to standardize a feature of a single runtime? How about features of a bundler? I don't think the JS language should be playing gatekeeper.

We already have infinitely extensible syntax with no runtime semantics - comments. Adding syntax that does nothing at runtime is adding a lot of cost for decidedly non universal value.

Adding something to the language is a permanent decision that can never be unmade; “time to add” is, in the long run, a negligible cost compared to permanent mistakes. Moving too fast breaks things, which slows down everything that comes after it. That’s the job of JS language stewards imo - to minimize mistakes, not to accelerate experimentation (which requires no standards process anyways)

This comes across as dismissing community feedback because we're perceived not to fully appreciate the problem or problem space.
Is this a forum for discussion that is legitimately open to non-TC39 members of the community?
That first comment is such a facile argument; it doesn't contribute to the discussion and is unnecessarily dismissive. There is a major undertaking right now for exactly the sort of non-semantic syntax 'that can be accomplished in comments' before this very same group and with significant momentum.
I will bow out of this discussion.

As requested in the tools meeting today, here are some potential use cases for import attributes. Tried to group them into some kind of semantic categories.
// this proposal
import mod from './foo.wasm' with { type: 'module' };

// more reflections
import img from './foo.png' with { type: 'url' };
import img from './foo.png' with { type: 'arraybuffer' };
import img from './foo.png' with { type: 'dataURL' };
import img from './foo.png' with { type: 'arraybuffer' };
import worker from './worker.js' with { type: 'worker' };
import sw from './worker.js' with { type: 'service-worker' };
import svg from './foo.svg' with { type: 'dom' };
import svg from './foo.svg' with { type: 'image' };

// tc39/proposal-defer-import-eval
import {x} from "y" with { lazyInit: true };

// attributes to apply to a constructed object
import stylesheet from './foo.css' with { layer: 'utilities' }; // css cascade layers
import stylesheet from './foo.css' with { media: 'print' };
import audio from './file.mp3' with { loop: true };

// preloading (possibly related to lazyInit?)
import x from './foo.js' with { preload: true };
let mod = await x.load();

// more assertions
import x from 'y' with { assert: { integrity: '...' }};
import x from 'y' with { assert: { referrerPolicy: '...' }};

// transforms that bundlers/tools could implement
import img from './foo.png' with { width: 500 };
import img from './foo.png' with { convertTo: 'jpeg' };

I'm sure there are more as well (please leave a comment!), but hopefully this demonstrates the need for an extensible syntax.

@devongovett thanks! i'd love some more elaboration on what these do (in prose), as well as what they would be expected to do in browsers and node.

@devongovett the examples really do help a lot to try to think more concretely about the requirements here.
We also went through a lot of these cases when exploring the possibilities for import reflection, so I can share some feedback based on what came out of that process (mixed in with my own opinions of course!), see comments below:

import mod from './foo.wasm' with { type: 'module' }; This is explicitly a non-goal for the Wasm ESM integration. The content type determines the format, and that is fully set at this point. To be very clear, there will most likely never be a custom module type for Wasm, as it will work in the ESM integration without any custom attributes.
import img from './foo.png' with { type: 'url' };: The way to do this is via import.meta.resolve('./foo.png'). This use case seems ideally is most likely captured by the asset references proposal as well.
import img from './foo.png' with { type: 'arraybuffer' };, import img from './foo.png' with { type: 'dataURL' };: These are effectively decorated fetches, similar to fetch(import.meta.resolve('./foo.png')). If the benefit of moving these to syntax is being able to standardize on a static data method that tooling can inline etc I'm all for that. But that does require full standardization here I think to draw the benefits over direct fetching. Having this discussion as part of the asset references proposal seems to make sense to me. Similar concepts have also come up in the context of data imports for Wasm and there was even some mention of hope that alignment might work out for an asset type to support data segment imports somehow.
import {x} from "y" with { lazyInit: true };: This is being actively worked through. It may well align with import reflection yet.
import x from './foo.js' with { preload: true };: Lazy initialization would load all modules but not execute them. I think preload is identical from that perspective, so likely is the same?
import worker from './worker.js' with { type: 'worker' };, import sw from './worker.js' with { type: 'service-worker' };: Worker reflections were shot down by the Chrome team when I brought this up. I don't know the exact reasons, but I believe efforts are best focused on blank workers for now here per the hoped worker.addModule APIs. In turn import reflection will be designed to be compatible with this for transferring modules to workers so I think between those we should hopefully capture similar use cases.
import x from 'y' with { assert: { integrity: '...' }};, import x from 'y' with { assert: { referrerPolicy: '...' }};: These assertions could certainly be specified, it would be very interesting to see further discussion form on new assertions, that's something that hasn't happened enough yet.
import svg from './foo.svg' with { type: 'dom' };: Can this be implemented like JSON and CSS modules as a content-type-based module type?
import svg from './foo.svg' with { type: 'image' };: I'm not sure I understand what the expectation is for this one in the browser?
import stylesheet from './foo.css' with { media: 'print' };: The media query discussion above was very interesting. This proposal suffers from similar concerns as was discussed - how to deal with nullability and changes?
import stylesheet from './foo.css' with { layer: 'utilities' };: What is the expectation here for utilities?
import audio from './file.mp3' with { loop: true };: I'm not sure I understand what this one would do.
import img from './foo.png' with { width: 500 };, import img from './foo.png' with { convertTo: 'jpeg' };: I think you're going to have a hard time getting this specified anywhere? It seems these are the only ones arguing for a custom space for bundlers to have their own semi-standard meta import system?

To me it would make a lot of sense if module references didn't have evaluator attributes but asset references did:
import module x from "./foo.js";
// x is a module-block-like
await import(x);

import asset y from "./bar.png" with { type: "image" };
hostUseImage(y);

There is a need to separate these two because tc39 could have a lot to say about x and would have very little to say about y.
i.e. I think module references are a special case where most of what they do can be understood at the vanilla level, they should preload deps as static imports would and be dynamically importable. Whereas arbitrary host-managed evaluator attributes and all of their use cases would be much better suited to asset references, which already export arbitrary host-defined values.
In other words, as soon as a module reference includes host-specified evaluator attributes to make it yield a host-specified value, it becomes an asset instead.
Rather than lamenting module vs asset not being selected by an extensible scheme, we should accept module as a necessary carve-out for importable module references, and let asset be the extensible category.

Ok, I'll try to go through them with some more explanation and also try to answer @guybedford's questions along the way.

import mod from './foo.wasm' with { type: 'module' };
This was meant to be the exact same thing as the current proposed syntax import module mod from './foo.wasm'. I used type as a key here rather than reflect because I think it's more understandable to the average dev, but it's the same. Confusion with import assertions may be an issue though. Again, the name isn't really important for the example.

import img from './foo.png' with { type: 'url' };
I was thinking this would supersede the asset references proposal. Perhaps type: 'asset' would be better. Idea would be to return a constructed URL object. new URL or import.meta.resolve are also fine syntaxes, but more dynamic. Having a static syntax could also be useful potentially. Many bundlers support importing assets as resolved urls like this today because it's pretty ergonomic.

import img from './foo.png' with { type: 'arraybuffer' }; (and similar for dataURL, or other formats)
This would return the data for the image as an ArrayBuffer. Yes, you can do this with fetch, but doing so with an import statement has some benefits. It's statically analyzable, which is good for tools. It's also good for browsers, which could start downloading these resources much earlier (i.e. in a prescanning phase).

import worker from './worker.js' with { type: 'worker' }; (and service worker)
This would return a constructed Worker object. Again, the benefits are that it's static, and that the worker can be downloaded in parallel with the rest of the module graph, without waiting for JS code execution to run the Worker constructor. Sure, you could use link preloads, but this is nice and ergonomic. Also relative urls in the Worker constructor are resolved relative to the page, not the current module, so usually you have to use import.meta.url to resolve the url manually as well.

import svg from './foo.svg' with { type: 'dom' };
This would return a parsed SVGElement DOM instance for an SVG file, which could be inserted into the document. Same benefits as above. Could be implemented with import assertions like CSS/WASM modules too, but if there are multiple possible reflections for an SVG (e.g. an Image object, as described below), then there might also need to be a way to switch between them.

import svg from './foo.svg' with { type: 'image' };
I was thinking this would return an Image object. Same benefits: early loading, static dependencies, relative resolution.

import {x} from "y" with { lazyInit: true };
See https://github.com/tc39/proposal-defer-import-eval

import stylesheet from './foo.css' with { layer: 'utilities' };
Idea here would be to be able to apply attributes to a reflected object, in this case a CSSStyleSheet. In CSS, the @import rule supports applying a cascade layer to an imported stylesheet, so why not JS as well? Could be useful when importing CSS stylesheets to have control over the cascade without making a copy of a CSS file wrapped in a @layer rule.

import stylesheet from './foo.css' with { media: 'print' };
Similar to above, could apply a media query just like you can with @import in CSS. The discussion about what to do when the media query doesn't match on initial load but does later is a good one. I guess I would expect it to behave the same way @import and <link> with a media query do: it would still be downloaded (at low priority), just not applied. https://medium.com/@tomayac/why-browsers-download-stylesheets-with-non-matching-media-queries-eb61b91b85a2

import audio from './file.mp3' with { loop: true };
Same idea: applying an attribute to an imported Audio object. 🤷

import img from './foo.png' with { width: 500 };, import img from './foo.png' with { convertTo: 'jpeg' };
Goal here was to show that with an extensible syntax, tools could support custom transforms using the same syntax. I would not expect these to be standardized. Tools could strip these before shipping compiled JS to clients.

To be clear, my goal with these examples is to show that there are a wide range of potential use cases for import reflections and attributes. Some of these could eventually be standardized, either by TC39 or by other standards bodies (e.g. as a part of the CSS module script spec). Some of them could be implemented in tools and stripped before reaching runtimes. Making the syntax extensible now will avoid needing to specify new keywords or syntax later for each possible reflection or attribute. This is important not just for tools, but also for runtimes.

What would importing an image do outside of a browser environment?
The language also needs to ensure it stays universal for environments beyond browsers and node, like IoT devices and other chipset environments, and the mental and implementation cost of having syntax (as opposed to API) that works in some environments but not others can be quite high.

I think the host runtime should "register" the attributes that it supports with the JS engine, and unknown ones should be rejected. This would allow browsers to have different supported attributes from other environments, and would match the behavior of import assertions.

@ljharb The language also needs to ensure it stays universal for environments beyond browsers and node, like IoT devices and other chipset environments, and the mental and implementation cost of having syntax (as opposed to API) that works in some environments but not others can be quite high.

ES6 module resolving and loading is already environment-specific. import.meta is already environment-specific. There's nothing wrong with having a feature which varies between different environments. And having extensible syntax makes things better for different environments, because each environment can define its own custom properties.
If extensible syntax doesn't exist, then every environment must either invent its own syntax for environment-specific things, or it must create a new TC39 proposal, which isn't always desirable or possible. And if the feature is environment-specific, then it's unlikely to be accepted as a TC39 proposal. Extensible syntax fixes all of those problems.

Rollup just landed https://github.com/rollup/rollup/pull/4646, which adds support for arbitrary assertions and custom processing of those assertions by plugins.
The bundler ecosystem continues to land on the same solution, and I think it's because it's extensible.

With import assertions having transitioned to import attributes (slides) and import reflections transitioning to import phases (decoupling from attributes in the process), I think this issue is addressed.
The use cases brought up are relevant to and satisfied by import attributes now. You can see them used with their extensible syntax in conjunction with phases in one of the slides: https://docs.google.com/presentation/d/1Abdr54Iflz_4sah2_yX2qS3K09qDJGV84qIZ6pHAqIk/edit#slide=id.g216c73c7b74_0_35
(Or at least unless anyone thinks the phase should use an extensible syntax?)

at least allow booleans plz. only allowing string properties is annoying when I try to use them.

This has been resolved, as this proposal is specifically dealing with only import phases.
As import attributes is now stage 3, please direct any feedback regarding the import attributes options bag to the TC39 Discourse.


[BUG] ENS Name Does Not Populate Connect Kit Button

Describe the bug
After I connect my wallet to my dApp, I can see that the wallet is connected and I can see the wallet balance, but the ENS name associated with my wallet does not appear in the button. Additionally, I don't see any ENS name fetch in the "Recent Requests" section of my Alchemy dashboard. The same behavior occurs on the public wagmi provider.
To reproduce
Dependencies:
connectkit: ^1.1.0
wagmi: ^0.10.4
CodeSandbox: https://codesandbox.io/s/great-wood-z90onq?file=/src/App.js
Connect wallet with ENS name associated and ConnectKitButton text.
Expected behavior
I expect the wallets associated ENS name to appear in place of the truncated address. This bug does not occur on the family.co docs examples.
Environment details
Node version: 16.16.0

@raparri01 it look like your codesandbox example isn't using the AlchemyProvider at all.
Here are some links that might help implementing this correctly:

Check out the wagmi docs to see how to implement the AlchemyProvider with an Alchemy API key.
Check out this example in our docs to see how we suggest implementing providers using our client helper.

I didn't change anything but this started working weirdly. Something probably changed on the alchemy node I was using. Marking as closed.


Add friending system

screen to search for, add, and remove friends
feed only shows content from friends

My notes from friending work:
friendship status

can-send-friend-request

createFriendship
No X

needs-recipient-acceptance

updateFriendship (already sent)
updateFriendship (deleted)

can-accept-request

updateFriendship (accepted)
updateFriendship (rejected)

Friending Actions
SEND_FRIEND_REQUEST

Triggers:

Their List
Find Friends

Actions

(/) Create a friendship object with pending status
Notify recipient user of friend request
(/) Change triggers for sending user to pending icon
(/) Change triggers for receiving user to accept icon

ACCEPT_FRIEND_REQUEST

Triggers:

Their List
Find Friends

Actions

(/) Update friendship object with accepted status
(/) For both users, update users object with new friend
Notify sending user of friend accept
(/) Change Their List icon to accepted status icon (missing)
For both users, backfill new friend’s posts to their timeline (users_posts)

REJECT_FRIEND_REQUEST

Triggers:

Their List
Find Friends

Actions

(/) Update friendship object with rejected status
(/) Change Icon to send friend request

DELETE_FRIEND_REQUEST

Triggers:
Actions

(/) Update friendship object with deleted status

REMOVE_FRIEND

Triggers:

Their List

Actions

(/) Update friendship object with removed status
(/) For both users, update users object by removing friend
(/) Change Icon to send friend request
??? Remove friends post history from timeline???

FRIENDSHIPS SUBSCRIPTION

merge friendship information with a user to determine friendship status

CLOUD FUNCTIONS
When friendship status ==> ‘pending’

send a notification to receiving user

When friendship status ==> ‘accepted’

backfill both user’s timelines with new friend’s history
send a notification to sending user

Find Friends Screen
DATA

pending friend requests

fill in non-friend users

suggested friends data?

user-query by name

get missing users first if getAllUsers is too slow


[Drawer] Update mini variant to have nested menu

[x] I have followed (at least) the PR section of the contributing guide.

This is the updated drawer docs that discussed in this issue
closes #19108
closes #19557

I will help you with this I just need to figure out how to set  up collaboration with your branch.

@TommyJackson85 Thanks for the feedback! Did you mean something like this?

and yes I updated both .tsx and .js files manually :)

As a user of it, I feel the button on the nav bar has no connection with the side nav. It might be better to include on the side nav. Was this always there? Maybe it’s deliberate
Sent from my iPhone

On 10 Feb 2020, at 05:30, Alucard<EMAIL_ADDRESS>wrote:

@TommyJackson85 Thanks for the feedback! Did you mean something like this?
and yes I updated both .tsx and .js files manually :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@TommyJackson85 Thanks for the feedback! Did you mean something like this?

and yes I updated both .tsx and .js files manually :)

on those lines yeah. They might be a cramped in by the icons, but let me try and fix it :).

@TommyJackson85
Yeah I checked that CI error but unfortunately couldn't really get what it exactly means :(
Those changes looks good to me! and I'd say sorry because personally I don't have much time on weekdays for working on this.
I invited you to my forked repository as a collaborator, is it how I grant you a permission?

@ifndefdeadmau5 There are a few ways you can collaborate: as you have done (but that allows @TommyJackson85 to commit directly to your fork for changes to any brach); @TommyJackson85  creates a PR against the branch in your fork, which you can chose to merge, or request changes, just as with PRs to master here; or using the review suggestion feature on this PR using the:

button when you click on a line in the code diff view of the PR. (Good for one more more one-line changes, not so good for compound changes.)

@mbrookes do you know how to fix the argos error?

@TommyJackson85 Whoa, it looks much better with adding background!
For hr line, I think it'd be better not to have it because background of sub menus already making enough difference.
AFAIK, argo errors should be confirmed by maintainer

Ok I am on it. :) Wont be long. Thanks for confirming the argo issue with me.

@TommyJackson85 I just applied theme.palette.background.paper on background, how does it look?

@ifndefdeadmau5 I like it a lot actually. Any other suggestions of do you want to try and get more feedback first?

@TommyJackson85 I'm satisfied with current form :) maybe just wait for argos fix for now?

Any news? Progress?

We’re looking for more feedback. Any suggestions?
Sent from my iPhone

On 19 Feb 2020, at 18:02, kurtwilbies<EMAIL_ADDRESS>wrote:

Any news? Progress?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

You could use a tooltip indicating sub / listitems. Keep it clean and simple. Maybe you could use a popup to show the irems. You csn then use mouseover alike functions.

I’ve suggested this in an issue I posted. Others think it will add too much complexity to it.
Sent from my iPhone

On 19 Feb 2020, at 22:46, kurtwilbies<EMAIL_ADDRESS>wrote:

You could use a tooltip indicating sub / listitems. Keep it clean and simple. Maybe you could use a popup to show the irems. You csn then use mouseover alike functions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Well, personally I think we, as community, have to decide what is useful and what not, regardless of the complexity. This customization is very useful. So you could make it as complex as you want (maybe you can first publish several demos and then the maintainer can choose, adjust, whatever they want).

@mbrookes Is there anything I can do to finish this PR? Just curious

Well, personally I think we, as community, have to decide what is useful and what not, regardless of the complexity. This customization is very useful. So you could make it as complex as you want (maybe you can first publish several demos and then the maintainer can choose, adjust, whatever they want).
Can you at least post your support for it in issue #19646 ? Better to keep it separate to this pull request anyway.

I am also thinking, maybe we should keep the original mini-variant drawer as a base, and use this as second example titled:  "Mini Variant Drawer with Nested Menu" underneath it on the documentation page. What do yeah all think?
Theres a lot of different ways we could go about a nested drawer.

I think there may be a solution that satisfies everyone - duplicate the demo keeping the original simpler version, along with this more advanced version (with Tooltips if you wish!). @oliviertassinari?

Moving the discussion back to #19108. I don't think that making the demo more complex is a viable solution nor display the nesting directly inside the mini drawer.


Enum value in database

Hello everybody
I wanna store smth like enums in my database
I follow this, and all is good when I use First. But when I use Find I have this error:
Panic recovery -> interface conversion: interface is []uint8, not int64
/usr/local/Cellar/go/1.5/libexec/src/runtime/panic.go:423 (0x2a249)
        gopanic: reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
/usr/local/Cellar/go/1.5/libexec/src/runtime/iface.go:221 (0xd9b0)
        assertE2T: panic(&TypeAssertionError{"", *ep._type._string, *t._string, ""})
/Users/admin/gopath/src/gin_server/backend/model/item.go:63 (0x10431a)
        (*MyType).Scan: *t = MyType(value.(int64))
/usr/local/Cellar/go/1.5/libexec/src/database/sql/convert.go:190 (0x3675a1)
        convertAssign: return scanner.Scan(src)
/usr/local/Cellar/go/1.5/libexec/src/database/sql/convert.go:218 (0x368834)
        convertAssign: return convertAssign(dv.Interface(), src)
/usr/local/Cellar/go/1.5/libexec/src/database/sql/sql.go:1692 (0x374e0a)
        (*Rows).Scan: err := convertAssign(dest[i], sv)
/Users/admin/gopath/src/github.com/jinzhu/gorm/callback_query.go:82 (0x1e6782)
        Query: scope.Err(rows.Scan(values...))
/Users/admin/gopath/src/github.com/jinzhu/gorm/scope_private.go:314 (0x212298)
        (*Scope).callCallbacks: (*f)(scope)
/Users/admin/gopath/src/github.com/jinzhu/gorm/main.go:215 (0x1f6ef3)
        (*DB).Find: return s.clone().NewScope(out).inlineCondition(where...).callCallbacks(s.parent.callback.queries).db
/Users/admin/gopath/src/gin_server/backend/api/items.go:65 (0x2cd35e)
        (*MyResourse).readAll: err = db.Limit(itemsOnPage).Offset((page - 1) * itemsOnPage).Find(&item).Error
==== and stack trace of other my code there ====

And when I putting this
log.Printf("Scan() type with %v <%T>", value, value)

to my Scan method I have this output
Scan() type with [48] <[]uint8>

with same error. But when I call select method on my db I can see that value is actually equal 0.
And one question more. With gorm I can store ints fields in database (I use MySQL), but using enums I can just use this types (and go's int64 type represents as bigint(20) in database instead of int(11) for int). Can I use int(11) for this field too?
Thank you for your attention

Ok. Looking there I can say that it returned me a string with one symbol – zero.
But why string? Why encoded (or not decoded) – it has []utf8 type?
And I know that I can write code that checks type and if it is []utf8 than decode into string, convert to int and have profit, but it is crutch not solution, am I right?

Hi @aliksend
database will pass []byte to the scaner when query data from it, so I think you have to check it in your scanner.
For the second question, you could use size in field's tag. refer: https://github.com/jinzhu/gorm#define-models-structs

Please mysql usage: https://github.com/jinzhu/gorm/issues/1978#issuecomment-421919405


remember uploaded objects on first boot object sync retries

I guess this will save us some POSTs to /objects. CI is failing because of clang, remember that you have to use clang-format-11 and other versions could yield in different results


Implements performance improvments

During implementation in our SDK we found a few ways we can improve the performance and UX of the library. There will be a few changes that may need to be rolled back in this PR.
I had to move the ownerDocument change into the context object since it breaks when in the options area.

Closed due to condensed PR 😀