emacs: teach elisp builders the finalAttrs pattern [skip treewide]

Description of changes
This PR causes 0 rebuilds.
Review advice
It is easier to review this PR commit by commit.
The first four commits are small fixes and cleaning.  Almost all work is done in the last commit.
Performance overhead of eval time

package set
before
after
changed

emacs.pkgs.elpaPackages
1.925
1.935
+0.35%

emacs.pkgs.melpaPackages
8.312
8.558
+3.0%

The commands used here are
nix nixpkgs#hyperfine -- --warmup 2 --runs 10 'NIXPKGS_ALLOW_BROKEN=1 nix eval --include nixpkgs=$PWD --file . emacs.pkgs.melpaPackages --apply \'pkgSet: map (drv: drv.drvPath) (builtins.filter (p: p.type or null == "derivation") (builtins.attrValues pkgSet))\' --no-eval-cache >/dev/null'

nix nixpkgs#hyperfine -- --warmup 10 --runs 30 'NIXPKGS_ALLOW_BROKEN=1 nix eval --include nixpkgs=$PWD --file . emacs.pkgs.elpaPackages --apply \'pkgSet: map (drv: drv.drvPath) (builtins.filter (p: p.type or null == "derivation") (builtins.attrValues pkgSet))\' --no-eval-cache >/dev/null'

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[X] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Hey @Aleksanaa @inclyc, nixf-tidy reports false positives here.
Unused parameters are totally valid in the "build helpers" (or builders) use case, especially combined with the finalAttrs pattern.  These unused parameters server as the interface and documentation of the build helper, providing information about the expected parameters to both and the Nix interpreter and people reading the Nix expression:
nix-repl> lib.functionArgs emacs.pkgs.melpaBuild
{ buildInputs = true; commit = true; ename = true; files = true; meta = true; nativeBuildInputs = true; packageRequires = true; pname = false; postInstall = true; postUnpack = true; preUnpack = true; propagatedBuildInputs = true; propagatedUserEnvPkgs = true; recipe = true; version = false; }

Currently, there are other PRs to teach build helpers the finalAttrs pattern, such as go, python and rust.  There is also a general PR to ease this transition.  Presumably there will be more of these false positives reported in the future.

My local run of nixpkgs-review tells me it is indeed 0 rebuilds 🎉

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/we-added-a-linter-to-nixpkgs-checking-workflows/49722/16

Actually, these variables are not "unused".  They are passed to stdenv.mkDerivation and are used there.  It is indeed a hard thing for a parser to understand. 😅

Actually, those variables in generic.nix are not "unused". They are passed to stdenv.mkDerivation and are used there. 😅

I just kindly ask how they are passed to stdenv.mkDerivation ? Maybe we can explicitly use it in the attrset like { inherit files; } ?

It is indeed a hard thing for a parser to understand.

The parser can only understand the variable being used directly by other variables but not do heavily value tracking about how the names are used. There are indeed some cases where function formals (a.k.a parameters) in nix language they are used in builtins.functionArgs, in such case we can ignore the warnings emitted.

These unused parameters serve as the interface and documentation of the build helper, providing information about the expected parameters to both and the Nix interpreter and people reading the Nix expression

I don't think they do exactly provide "expected parameters" to Nix interpreter in this case, because we can remove it without having any side-effect. If they are the part of documentation why shouldn't they go under /** */ as per RFC 0415?

Other "truly unused" arguments are debatable. Should we keep them for documentation purposes or remove them to eliminate dead codes?
I agree with @inclyc that we should move them into the documentation. #308377 shows how such unused parts of set-pattern arguments could confuse.

Indeed yes because if declare the formal arg without actually using it (i.e. by referencing in @arg may results in a common mistake:
nix-repl> ({ a ? "foo" }@attrs: attrs.a) { }
error: attribute 'a' missing

       at «string»:1:23:

            1| ({ a ? "foo" }@attrs: attrs.a) { }
             |                       ^

nix-repl>

In this case, while the lambda is called, a -> "foo", however attrs -> { }, and thus attrs.a is undefined.
So in our "builder" example, I suggest always explicitly USE the declaration like:
{ foo, bar, ... }@args: someOtherFunction (args // { inherit foo bar })

Indeed yes because if declaring a formal arg without actually using it (i.e. by referencing in @arg) may results in a common mistake:
nix-repl> ({ a ? "foo" }@attrs: attrs.a) { }
error: attribute 'a' missing

       at «string»:1:23:

            1| ({ a ? "foo" }@attrs: attrs.a) { }
             |                       ^

nix-repl>

In this case, while the lambda is called, a -> "foo", however attrs -> { }, and thus attrs.a is undefined.

I know this example a few days ago.
However, this example is not relevant here.  There is not any args.a or attrs.a in this PR.  It is finalAttrs.a.

So in our "builder" example, I suggest always explicitly USE the declaration like:
{ foo, bar, ... }@args: someOtherFunction (args // { inherit foo bar; })

I mean why don't we need to inherit files here:
https://github.com/NixOS/nixpkgs/blob/7a34d0e63a1ef81af449c9d1cd7aaa583470aa5f/pkgs/applications/editors/emacs/build-support/melpa.nix#L82
like
- inherit packageBuild commit ename recipe;
+ inherit packageBuild commit ename recipe files;

Then the unused error will move to there?

Then the unused error will move to there?

I guess not, because inherit does not make new definition?

Adding a unneeded inherit file; just to please the CI?  I do not think it is a good idea.

Adding a unneeded inherit file; just to please the CI? I do not think it is a good idea.

Have you tried .overrideing files  I just cannot understand why finalAttrs contains files attribute if it is not inherited like other names.

Have you tried .overrideing files?

Parameters with added by `` is expected to be overridden with overrideAttrs (not override) likes this
nix-repl> (emacs.pkgs.git-undo.overrideAttrs (old: { files = "foooooo"; })).files
"foooooo"

I just cannot understand why finalAttrs contains files attribute if it is not inherited like other names.

Please have a look at lib.adaptMkDerivation and lib.extendMkDerivation.

Sorry.  I somehow missed this.

Actually, those variables in generic.nix are not "unused". They are passed to stdenv.mkDerivation and are used there. 😅

I just kindly ask how they are passed to stdenv.mkDerivation ?

In generic.nix, pname and version is implicitly passed to stdenv.mkDerivation with the help of lib.adaptMkDerivation.  Note // removeAttrs args handledArgs.  Please have a look at lib.adaptMkDerivation.

Maybe we can explicitly use it in the attrset like { inherit files; } ?

Note that files is not in generic.nix.

It is indeed a hard thing for a parser to understand.

The parser can only understand the variable being used directly by other variables but not do heavily value tracking about how the names are used. There are indeed some cases where function formals (a.k.a parameters) in nix language they are used in builtins.functionArgs, in such case we can ignore the warnings emitted.

These unused parameters serve as the interface and documentation of the build helper, providing information about the expected parameters to both and the Nix interpreter and people reading the Nix expression

I don't think they do exactly provide "expected parameters" to Nix interpreter in this case, because we can remove it without having any side-effect.

By "providing information about the expected parameters to both the Nix interpreter", I mean you can check lib.functionArgs emacs.pkgs.melpaBuild in the repl.  I already gave an example there.

If they are the part of documentation why shouldn't they go under /** */ as per RFC 0415?

Someone has to write the doc string.  Someone also has to make the doc system render these nix files.  I may do these things in the future, but not now.

Please have a look at lib.adaptMkDerivation.

CC @ShamrockLee who authored those functions. WDYT?

In generic.nix, pname and version is implicitly passed to stdenv.mkDerivation with the help of lib.adaptMkDerivation. Note // removeAttrs args handledArgs. Please have a look at lib.adaptMkDerivation.
CC @ShamrockLee, who authored those functions. WDYT?

lib.adaptMkDerivation is designed not to pass arguments implicitly to the base build helper, in contrast to lib.extendMkDerivations. Instead, arguments are passed explicitly by // removeAttrs args handledArgs.
(People are already doing this a lot in existing build helper definitions, so we still need lib.adaptMkDerivation in addition to lib.extendBuildHelper.)

IMHO, this issue is not specific to lib.adaptMkDerivation and lib.extendMkDerivation. People are already experiencing this in the current way of defining build helpers. An existing example can be found in the description of #308377.
The question is, should we keep syntactically unused arguments in the set pattern of a build helper? Should the set pattern and __functionArgs be considered a form of documentation?
CC @fricklerhandwerk, who devoted a lot of time to the documentation. What do you think about it?

I add data about performance overhead here.

@ShamrockLee on the unused code: it's tricky... indeed leaving the attributes in the argument gives a hint at the interface, but it's highly idiomatic about the Nix language, you kinda have to know to know how to read that. I'd prefer to be explicit in the doc comments and not block this on improving automation, which will take a while even if you may decide it's a good thing to accommodate.

Since this PR has been open for 4 days, I am going to merge it as is in 3 days if no new discussions are made. If you want to review this but do not have time within three days, please let me know and I will wait for you.

I don't feel comfortable taking on the complexity of extendDerivation & friends vendored into Emacs lib.
I see https://github.com/NixOS/nixpkgs/pull/234651 as a blocker for this to be merged.

The core of extendDerivation and adaptMkDerivation is quite small.
{
  extendMkDerivation' = mkDerivationBase: attrsOverlay:
    fpargs: (mkDerivationBase fpargs).overrideAttrs attrsOverlay;
  adaptMkDerivation' = mkDerivationBase: adaptArgs:
    fpargs: mkDerivationBase (finalAttrs: adaptArgs finalAttrs (lib.toFunction fpargs finalAttrs));
}

I would say extendMkDerivation' cannot be simplified further.  However, for adaptMkDerivation', there are other possible implementations, such as doing the filtering inside stdenv.mkDerivation like the rust PR does.
Are you happy with vendoring those two simplified versions?  Or do you still think it is better to block this PR on https://github.com/NixOS/nixpkgs/pull/234651 to reach a consensus?
I do not know how to make progress on https://github.com/NixOS/nixpkgs/pull/234651.  That PR seems to have been blocked in the wait-for-review state for a long time.
Understanding the finalAttrs pattern for elisp builders does solve problems, such as making it easy to override some elisp pakcages.

I don't feel comfortable taking on the complexity of extendDerivation & friends vendored into Emacs lib.

I just pushed a new commit to stop vendoring https://github.com/NixOS/nixpkgs/pull/234651.  Its commit message is as follows:

Previously, we vendor PR #234651 because we want to keep the old
behavior of filtering out packageRequires from the arguments we pass
to the underling stdenv.mkDerivation.  Doing so raises the concern
about the complexity of PR #234651.
Considering that passing packageRequires to stdenv.mkDerivation also
works well, we stop filtering it out and stop vendoring PR #234651.
Now, this PR only uses the existing interface of stdenv.mkDerivation.
Even though the name of the build helper is still extendMkDerivation',
it is nothing new and has been used in Nixpkgs, such as
php.buildComposerProject1.

@adisbladis I would like to if this commit resolves your concern about complexity.
Unfortunately, since we pass packageRequires to stdenv.mkDerivation now, packageRequires is added to derivations of almost all elisp packages.  So this PR has to target the staging branch.

Conflicts are resolved.


Fix editrule sometimes Add and delete will out-of-order

当编辑规则的时候, 缓存更新的删除和添加有一定几率会乱序.

https://github.com/eleme/banshee/pull/660


Update ImageDataGenerator to handle images with different sizes, #2324

Enables the ImageDataGenerator to handle images with different sizes and output them with the same size.

Re-running the checks

Re-re-running the CI checks.

The tests are all failing in the teardown_function.
>    shutil.rmtree('test_images')
E    OSError: [Errno 2] No such file or directory: 'test_images'

I think it's related to #2334.

If I understand this code correctly, it will resize each image in each epoch.
The alternative to resizing images in ImageDataGenerator is to resize the images (typically with something like Pillow) before running any type of fit. Using that approach, each image is resized only once.
Is resizing cheap enough that it makes sense to resize images repeatedly in each epoch, rather than doing it once up front?

First of all it isn't really resizing, it's more like copy the image into a larger one, which is cheaper than an actual resize. But yes from a cost point of view it would be cheaper to do it once and not every epoch.
But there are two things. First, which is miner and theoretically one, at the moment the resize happens after all random tranformations are done, which means, depending on the ransformation that are done, that each epoch there is a different image to be resized. So random tranformations first and then resize or the other way around, which is IMO more a theoretically issue.
Second if the position argument is random the image can be in each epoch at a different location. Depending on the differenz between image size and output size there could be cases where for all epochs not two images would be the same.

How is resizing from a random position different from the height shift and width shift that are already happening?
Isn't the claim that the images coming out of the generator won't repeat themselves already true, even without this resizing type operation?

+1, very good idea.


Remove forced ssl upgrade for localhost http requests

I've been playing around trying to glue urbit and IPFS together. For my first iteration, I tried to +curl my local IPFS API from the Dojo. Because go-ipfs doesn't implement HTTPS, I made sure to do a +curl "http://localhost:5001...", but I was still getting an ssl related error:
> +curl "http://localhost:5001/api/v0/get?arg=QmagqTLSZvdqjWp2hVFokDyThekNAACsUG8r2XGhBWPQh6"
< http://localhost:5001/api/v0/get?arg=QmagqTLSZvdqjWp2hVFokDyThekNAACsUG8r2XGhBWPQh6
http: fail (170, 504): ssl handshake failure
HTTP 504

Talking to @Fang- at the last meetup, he reassured me this should not be happening, and specifying "http" should do a regular non-ssl request. I dug in a bit and found the issue: in the definition for ++  auri there is a conditional to check if this is a localhost request (using ++  hoke), and if so, it forces it to use SSL.
This PR removes this forced upgrade, so i can specify either an http or https request to localhost.
There might be a reason for this check, but I couldn't find one. I did some git spelunking and found that this was added in commit 2c3c4c8b1db6f8617ae5376c54297560114bd599 , so maybe @cgyarvin knows if this is still needed or not.
Also, I don't fully grok the implications of creating this "iron gate" here; I cargo-culted from a similar-looking ++  aurf definition above and it worked :)

I've assumed that this was related to the way in which user-agents treat localhost as a secure origin (for certain web apis, mixed-content warnings, etc.). But it's a major pain when it comes to making requests instead of receiving them. Maybe we still want to include something similar in the latter case, but definitely not in the former. Thanks @jglukasik!


Add Faith's phylogenetic alpha diversity

Add implementation of Faith's phylogenetic alpha diversity in estimateDiversity.
This is tree-based alpha diversity measure and would nicely complement the other (non-tree) based ones.
The picante::pd() provides one implementation (GPL2). It would add a dependency here, or we could add our own implementation to reduce dependencies. This measure is not overly complex.

For this to be implemented, first it has to be decided, whether you want to reuse the estimateDiversity function name. If yes, three things need to be adjusted:

the generic has to be expanded with a tree arguments, which is then missing for all functions currently implemented.
a method has to be added for a signature c(x="SummarizedExperiment",tree="phylo"), which splits the workflow on the currently implemented methods and the ones, which depend on the tree aka. the new faith index.
a method has to be added for a signature c(x="TreeSummarizedExperiment",tree="missing") extracting the rowTree and dispatching to the method in 2.

If you want to use a special function name unrelated to the current ones, only 2. and 3. have to be implemented.

In my opinion it would be good to have also 1. implemented. The alpha diversity are all conceptually similar, Faith is just able to take into account some additional information not used by the other indices.


X Does not close the error notification

iPad and MocOS
When the connection fails the error message shows an X symbol. It is assumed that this can be used to dismiss the message but it does not.

Steps to reproduce

Begin a connection to a non-existent server to provoke the error message
Observe the error message and try to close it
Observe that selecting anywhere else on the screen except the X closes the error message

I'm sorry but it's not the intended behavior. The purpose of the X symbol is only to represent the message type : information / warning / error
The dismiss should happen when clicking-out as it's implemented under iOS.

I'm considering now this issue

Will use these statements : https://github.com/SwiftKickMobile/SwiftMessages#interaction

This is now fixed inside the latest beta release : https://testflight.apple.com/join/QSrBK59z


Tracking outage of Travis CI

This is the issue for tracking the out of balance issue with Travis CI.
Updates

So far at 2023-07-13T20:56:44Z, outage of Travis CI issue still not been solved.

Also, since master branch has already migrated  GHA, Travis CI then is only needed for old versions.
And for bors, there's some workflow update need to add make it works with GHA instead of using GCH's merge queue (which is still in Beta)

Migrated to GitHub Action on master branch.
For old branches , we will continue to use Travis CI if we still have enough credit.

Migrated to GitHub Action on master branch.
For old branches , we will continue to use Travis CI if we still have enough credit.


After using input statements that affect both present and future, sliders in interface do not have an effect anymore

@AlexanderWirtz created a scaled scenario for Ameland and has used many new input statements.
But now when you load the scenario (see below) in etmodel, the space heating sliders for households do not work anymore.
scaled scenario
INSERT INTO `scenarios` (`id`, `author`, `title`, `description`, `created_at`, `updated_at`, `user_values`, `end_year`, `in_start_menu`, `user_id`, `preset_scenario_id`, `use_fce`, `present_updated_at`, `protected`, `area_code`, `source`, `balanced_values`)
VALUES
	(NULL, NULL, 'Ameland poging 3', '
\n
Alleen wat schuifjes voor ruimteverwarming en warm water verzet.
\n
Ook wat zonthermisch en transporttechnieken verzet
\n
Schuifjes ruimteverwarming en warm water
\n
Schuifjes transportmix
\n
Poging present technologiemix mix te verzetten
\n
', '2015-12-01 14:20:41', '2015-12-01 14:20:41', '--- !ruby/hash:ActiveSupport::HashWithIndifferentAccess\nhouseholds_space_heater_combined_network_gas_share: 88.1\nhouseholds_space_heater_combined_network_gas_share_present: 88.1\nhouseholds_space_heater_heatpump_ground_water_electricity_share: 0.0\nhouseholds_space_heater_heatpump_ground_water_electricity_share_present: 0.0\nhouseholds_space_heater_micro_chp_network_gas_share: 0.0\nhouseholds_space_heater_micro_chp_network_gas_share_present: 0.0\nhouseholds_space_heater_district_heating_steam_hot_water_share: 0.0\nhouseholds_space_heater_district_heating_steam_hot_water_share_present: 0.0\nhouseholds_space_heater_heatpump_air_water_electricity_share: 0.0\nhouseholds_space_heater_heatpump_air_water_electricity_share_present: 0.0\nhouseholds_space_heater_hybrid_heatpump_air_water_electricity_share: 0.0\nhouseholds_space_heater_hybrid_heatpump_air_water_electricity_share_present: 0.0\nhouseholds_space_heater_wood_pellets_share: 11.9\nhouseholds_space_heater_wood_pellets_share_present: 11.9\nhouseholds_space_heater_electricity_share: 0.0\nhouseholds_space_heater_electricity_share_present: 0.0\nhouseholds_space_heater_network_gas_share: 0.0\nhouseholds_space_heater_network_gas_share_present: 0.0\nhouseholds_space_heater_crude_oil_share: 0.0\nhouseholds_space_heater_crude_oil_share_present: 0.0\nhouseholds_space_heater_coal_share: 0.0\nhouseholds_space_heater_coal_share_present: 0.0\nhouseholds_water_heater_combined_network_gas_share: 89.6\nhouseholds_water_heater_combined_network_gas_share_present: 89.6\nhouseholds_water_heater_heatpump_ground_water_electricity_share: 0.0\nhouseholds_water_heater_heatpump_ground_water_electricity_share_present: 0.0\nhouseholds_water_heater_micro_chp_network_gas_share: 0.0\nhouseholds_water_heater_micro_chp_network_gas_share_present: 0.0\nhouseholds_water_heater_district_heating_steam_hot_water_share: 0.0\nhouseholds_water_heater_district_heating_steam_hot_water_share_present: 0.0\nhouseholds_water_heater_heatpump_air_water_electricity_share: 0.0\nhouseholds_water_heater_heatpump_air_water_electricity_share_present: 0.0\nhouseholds_water_heater_hybrid_heatpump_air_water_electricity_share: 0.0\nhouseholds_water_heater_hybrid_heatpump_air_water_electricity_share_present: 0.0\nhouseholds_water_heater_wood_pellets_share: 10.4\nhouseholds_water_heater_wood_pellets_share_present: 10.4\nhouseholds_water_heater_resistive_electricity_share: 0.0\nhouseholds_water_heater_resistive_electricity_share_present: 0.0\nhouseholds_water_heater_network_gas_share: 0.0\nhouseholds_water_heater_network_gas_share_present: 0.0\nhouseholds_water_heater_crude_oil_share: 0.0\nhouseholds_water_heater_crude_oil_share_present: 0.0\nhouseholds_water_heater_coal_share: 0.0\nhouseholds_water_heater_coal_share_present: 0.0\nhouseholds_water_heater_fuel_cell_chp_network_gas_share: 0.0\nhouseholds_water_heater_fuel_cell_chp_network_gas_share_present: 0.0\nhouseholds_water_heater_solar_thermal_share: 0.0\nhouseholds_water_heater_solar_thermal_share_present: 0.0\nbuildings_space_heater_network_gas_share: 100.0\nbuildings_space_heater_collective_heatpump_water_water_ts_electricity_share: 0.0\nbuildings_space_heater_solar_thermal_share: 0.0\nbuildings_space_heater_wood_pellets_share: 0.0\nbuildings_space_heater_district_heating_steam_hot_water_share: 0.0\nbuildings_cooling_collective_heatpump_water_water_ts_electricity_share: 0.0\nbuildings_cooling_heatpump_air_water_network_gas_share: 0.0\nbuildings_cooling_airconditioning_share: 100.0\ntransport_car_using_electricity_share: 0.0\ntransport_car_using_diesel_mix_share: 48.6\ntransport_car_using_gasoline_mix_share: 48.9\ntransport_car_using_lpg_share: 2.5\ntransport_car_using_compressed_natural_gas_share: 0.0\nagriculture_useful_demand_electricity_both: -11.32\nhouseholds_number_of_inhabitants_both: 0.003525\nhouseholds_useful_demand_heat_per_person_both: 8.25\n# households_heat_network_connection_steam_hot_water_share_present: 12.5\n# households_collective_geothermal_share_present: 12.5\n# households_collective_chp_wood_pellets_share_present: 5.0\n# households_collective_chp_network_gas_share_present: 50.0\n# households_collective_chp_biogas_share_present: 20.0', 2020, NULL, NULL, 448956, 0, NULL, 1, 'nl', 'ETM', '--- !ruby/hash:ActiveSupport::HashWithIndifferentAccess\nhouseholds_space_heater_heatpump_air_water_electricity_share: 0.0\nhouseholds_space_heater_micro_chp_network_gas_share: 0.0\nhouseholds_water_heater_coal_share: 0.0\nhouseholds_water_heater_crude_oil_share: 0.0\nhouseholds_water_heater_fuel_cell_chp_network_gas_share: 0.0\nhouseholds_water_heater_heatpump_air_water_electricity_share: 0.0\nhouseholds_water_heater_heatpump_ground_water_electricity_share: 0.0\nhouseholds_water_heater_micro_chp_network_gas_share: 0.0\nbuildings_space_heater_coal_share: 0.0\nbuildings_space_heater_crude_oil_share: 0.0\nbuildings_space_heater_electricity_share: 0.0\nbuildings_space_heater_heatpump_air_water_network_gas_share: 0.0\n');

scenario_scaling
INSERT INTO `scenario_scalings` (`id`, `scenario_id`, `area_attribute`, `value`, `base_value`, `has_agriculture`, `has_industry`, `has_energy`)
VALUES
    (1246, 454086, 'number_of_residences', 1657, 7386740, 1, 1, 1);

including @ChaelKruip and @grdw

@antw I will give some more background to this issue
Background
We are trying to create ETM scenarios for a tiny island called Ameland. this has 1657 residences and not much else. Scaling down from a Dutch ETM scenario results in energy demands that are at best > 50% off, at worst > 300%. I know this, because I have found pretty good data on energy use in Ameland. Needless to say, these scaled scenarios just won't do.
Of course, for future values, I can always use slider setting in the scenario files, to make sure energy use per sector is roughly correct. This leaves the present values. As you are aware, I have been playing with input statements to set all kinds of percentages and demands for the present graph (as well as for both, with varying success. All these input statements I have put into the adjust_scalings directory on the new_input_statements branch of etsource.
What works
What works like a charm, for example, is first setting households_useful_demand_heat_per_person_both in a scenario file, and then using the slider to adjust the future value through: households_useful_demand_heat_per_person.
This helps me tweak residential space heating demand to just the right value for the present and future.
What doesn't work yet
A similar trick for space_heating and water_heating technologies is less successful.
First of all, because setting these values for both is not very useful. Second, because after setting the values for all technologies, the sliders no longer work (the issue at hand), even though the present technology mix does get set accordingly.
The slide balancer requires you to specify updates for all sliders in a group, otherwise the latter does not work either.
Hope this helps

Second, because after setting the values for all technologies, the sliders no longer work (the issue at hand), even though the present technology mix does get set accordingly. [...] The slide balancer requires you to specify updates for all sliders in a group, otherwise the latter does not work either.

This is because they have been assigned to the heating_households and hot_water_households share groups, which is used to balance the inputs on the future graph.
On the new_input_statements_regrouped branch, I assigned new groups to the "adjust_scalings" inputs (heating_households_present and hot_water_households_present, although you could use whatever names you want) and ETEngine appears to accept the updates without any errors.

Thanks!!!


High quality checkpoint in Spanish?

I am using the ald medium model for ES_MX
https://huggingface.co/datasets/rhasspy/piper-checkpoints/tree/main/es/es_MX/ald
I would like to continue training with a checkpoint. Is there any high-quality repository for ES_MX Spanish?
Thanks!

No, sorry. I never trained a high quality version of that model :/


Save copy of parsed mca dataset

Parse the full .mca dataset and save out. This means the process only has to be done once, and the dataset can be put on sync so it can be imported for further processing.

Closing as data can now be read quick enough to no longer warrent writing a copy to sync.


1.3.3 release?

It looks like a number of issues have been fixed on master is there likely to be a release soon?

:+1: any word on this?

:+1: yes please

ping


Stealth: Sent funds are GONE!

https://bitsharestalk.org/index.php/topic,21715.msg288209.html#msg288209
"The receipt still does not show when sending funds to a private account. It's only visible in the console.
I cannot retrieve the receipt afterwards in any case - in case I missed it in the console, my sent funds are GONE!
And when I try to import that receipt that I got from the console, I still get
Error: Missing required field: Label is required unless a private key is provided(…)
This is the same situation as over a month ago!
I hope this doesn't get released on the mainnet like this, This is seriously broken, just like a month ago."

So far, from what I see no receipts were gone ..  What was needed was refreshing better receipt reporting.   Also I should note this is TEST funds.
I did find we needed to keep an additional receipt even in the case where the transaction ended up on the blockchain.  This improves the UI as it knows better how to show you the sender and recipient (links).
Refresh upon wallet locking and unlocking has improved.  This should clear up a lot of confusion.
Still a known issue: change receipt is shown in receipt history when sending blind to blind (you see some of your balance being sent from ~self to ~self in receipt history).  That needs to be suppressed.  Could be other cases where this change recept leaks through.
I have updated http://stealth.cnx.rocks

I did additional testing and am happy to see that I can retrieve the receipt after sending a transaction.
I see that when I'm sending to a private contact that is not mine, I see the receipt, that is very good.
Please add some text like 'Please give this to the receiver of the transaction in order to complete the transaction', that would make usability better.
I was able to import the balance with the receipt, however nothing happened when I clicked "Receive" in the 'Receive funds' modal - the actual import of the balance did work. I recall there was some confirmation, so this seems to be a bug.
Good work, I'm happy to see that we're slowly ironing out those usability issues.

Sending to another persons public key still does not work properly, the receive part is bugged.
First of all, if you try to receive without first unlock the wallet, it just fails silently with no indication anything went wrong. In the console however you'll see a message that the wallet is locked.
Second, I still get this error:
-- receiveBlindTransfer error --> Error: Missing required field: Label is required unless a private key is provided

@svk31 I recreated the error.
When importing a receipt their are two things that have to be true:

There is a private key that can decrypt the receipt
That private key has a label (stealth keys have labels, the rest do not)

Both need to be true to import the receipt.  In case 1, I used the wallet key import to import the private key.  But, their was no way in the UI for me to add a label.  One idea is that the New Private Account could allow the user to provide this WIF key, however, that leaves the case where the key was imported but does not have a label (no way to label an existing key).  So, if the key exists the import receipt dialog could update and prompt the user to label to the key..  So that import will have to be smart enough to handle both of these cases.

I was pleased to find that the receipt import already had a PrivateKey element in it.  I just needed to fix it up...  So, the Add Private Account can accept a WIF now or it just lets you create a random key.  Also, I trap and report it if the wallet does not have a private key for the receipt.  So this should smoothen out receipt importing.
When importing receipts, I know of only 1 edge case: If you have a WIF imported without a label (in the wallet import), you can import the receipt now but it appears in the history with the account name of ~ ..  The key belonging to the receipt is not known until you get into the cwallet, so this is not so easy to detect.  I wonder if this is going to come up in the field, it is more likely the result of our trying to work-around the Add Private Contact not accepting a WIF..
I have updated the stealth site...

Last weekend, I wanted to demonstrate Stealth to a friend, however I was not able demonstrate it. Sending to a blinding account did not work. Seems to work now, but I'm not sure.

Another round of testing is needed on the send side..  Their maybe another issue with sending and 'Recent History'.  I'll probably find some time before early next week.

fixed


openeo grass driver: fix apply process

fix parsing of the process graph inside the apply process definition

Thanks, I also added a basename parameter to t.rast.mapcalc, because it will fail without it. Local testing was successful with the operators in OPERATOR_DICT and FN_DICT. However, using apply with two different datasets seems not to be possible at the moment, as arguments["data"] is explicitly parsed in this PR and constructions like the following cannot be validated:
[...]
    "apply1": {
      "process_id": "apply",
      "arguments": {
        "data": {
          "from_node": "loadcollection1"
        },
        "process": {
          "process_graph": {
            "lte1": {
              "process_id": "subtract",
              "arguments": {
                "x": 1,
                "y": {
                  "from_argument": "data"
                }
              },
              "result": true
            }
          }
        }
      }
# how to pass two datasets as data arguments to the following node?
    },
    "apply2": {
      "process_id": "apply",
      "arguments": {
        "data1": {
          "from_node": "loadcollection1"
        },
        "data2": {
          "from_node": "apply1"
        },
        "process": {
          "process_graph": {
            "lte1": {
              "process_id": "divide",
              "arguments": {
                "x": {
                  "from_argument": "data1"
                },
                "y": {
                  "from_argument": "data2"
                }
              },
              "result": true
            }
          }
        }
      }
    },
[...]

Validation then yields:
{
  "id": "2021-07-28T11:45:12.380149",
  "code": "Bad Request",
  "message": "'NoneType' object has no attribute 'output_objects'",
  "links": []

However this may be subject to a dedicated PR.

apply (Apply a process to each pixel) is one of the officially defined openeo processes: https://processes.openeo.org/#apply and takes only one single datacube as input. Passing two datasets is not allowed because it would violate the API.


TO -- full TrafficOps/db within docker

other components to follow.   This is intended to be a framework for bringing up a full (minimal) CDN for automated testing and for demonstration purposes.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/1819/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/1820/
Test PASSed.


[Question] Regarding nnDetection was not build with GPU support!

:question: Question

May I ask why I nms_fn is None when I run predicting?
I run
python -c "import torch; import nndet._C; import nndet"
successfully
THANKS!!!!!

should rebuild _C.cpython-38-x86_64-linux-gnu.so


Removing old apiserver source code

Old apiserver source code is removed as we are using binary of apiserver in the updated release.

This can be merged.


Extracting a .ipa file not working

Finally a zip/unzip project, which supports the Swift Package Manager 👍
When I'm trying to unzip a .ipa file   I get an io error.
Unfortunately there is no more detailed error message, so I could investigate whats not working.
Every .ipa file consists of:
/Payload/
/Payload/Application.app
/iTunesArtwork
_/iTunesArtwork@2x_
/iTunesMetadata.plist

Everything gets extracted, besides the contents of /Payload/Application.app. It stops after Info.plist.
Could you please look into it?

I exported my iOS project to .ipa file and tried unzip, but no error occurred 🤔


Web UI rule criteria input trigger parameter drop-down issue (2.4)

When using the web-ui to create a rule, the list of triggers are displayed in a drop-down list, however the trigger parameters are not in drop down list in the criteria section. If you edit the rule after saving, the trigger parameters appear in drop down lists. It appears it works when editing a previously created rule, but not from scratch.
To replicate:
i) Create a rule
ii) Select a trigger like: core.st2.generic.notify which has plenty of parameters
iii) Try adding criteria. You'll note distinct lack of trigger parameters appearing in a drop-down list
iv) Save the rule after completing required parameters like action, pack and name
v) Click edit on the rule
vi) The rule's criteria and the trigger parameters now appear when selecting the input field and triggering the javascript
Thanks,
D

Track at https://github.com/StackStorm/st2web/issues/423


temp workaround for golangci

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: irisdingbj
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rshriram
If they are not already assigned, you can assign the PR to them by writing /assign @rshriram in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Rerunning your lint test: https://circleci.com/workflow-run/cbfe8f13-73bb-4a4c-9e4e-a417dc0d1157
I think its been fixed upstream:
curl https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | grep BINARY shows it has been added
If that test doesnt pass though then lets get this in, thanks for looking into this

@irisdingbj looks like the test passed, should we close this?

@irisdingbj looks like the test passed, should we close this?

thanks for closing it~


Volume over 100%

Hi, really enjoying your application. I switched from windows to linux and wanted something similar to this https://www.nirsoft.net/utils/volumouse.html, so your application is the equivalent of that in the linux ecosystem.
I would like to point out that in linux mint that I use (probably in ubuntu as well) you set the max volume to the percentage you want, even above 100%, and the volume buttons of your laptop/keyboard respect that threshold.
Your application goes above and beyond that limit, over-amplifying sometimes the output sound, thus creating distortion.
Is there's a line of code I can add to your script to fix this?
Thanks in advance for your help, and really enjoying your app.

Thank you so much for your encouragement.
You can use amixer instead of pactl.
For exemple amixer set Master 120%  will do a volume to 100% and no more
So if you want to inscrease untill 100% instead of :
subprocess.run("pactl set-sink-volume @DEFAULT_SINK@ +5% & pid=$!",shell=True)
do
subprocess.run("amixer set Master 5%+ & pid=$!",shell=True)
Look at the old version of volumouse : https://github.com/pzim-devdata/Tools-for-Linux/tree/master/Volumouse
All is explain and choose "Volumouse_amixer_right.py" and "Volumouse_amixer_left.py" to download
I hope it will help :-)

Try this file, I have made this just for you :
I have added lines 529,530, 548,549, 564,565, 580,581 if you want to check the code.
Simply extract it and replace  volumouse.py in your destination folder
volumouse.py.zip

Sure thing, thanks man you're the best!

I have published a new version on Github with the ability to configure max volume for each card with python3 volumouse.py -c
Thank you for the idea ! ;-)


Added new version 12.1 supported databses

We have added new version supported databases for GDP version 12.1.
Below changes are there in this PR,

Added version 12.1 databases
Added new OracleCloud platform for UC so added below  files

consolidation-script2/config/configOracleCloud_UC.yaml
consolidation-script2/data/input/OracleCloud_UC.csv
consolidation-script2/data/output/csv/OracleCloud_UC.csv

Updated consolidation-script2/config/configOnPrem_UC.yaml with correct config for UC.

GRD-90599


testing: reject calls to Run within Cleanup callbacks

What version of Go are you using (go version)?
go1.17.1
Does this issue reproduce with the latest release?
Yes.
What did you do?
https://play.golang.org/p/l8yW_gkioCx:
func TestCleanupOrder(t *testing.T) {
	t.Cleanup(func() {
		t.Logf("first cleanup")
	})

	t.Cleanup(func() {
		t.Logf("second cleanup")

		t.Run("in cleanup", func(t *testing.T) {
			t.Parallel()
			t.Logf("running parallel subtest")
		})
	})
}

What did you expect to see?
Per https://pkg.go.dev/testing#T.Cleanup:

Cleanup registers a function to be called when the test (or subtest) and all its subtests complete. Cleanup functions will be called in last added, first called order.

So a Cleanup callback should not be started while there are subtests of its parent test still outstanding. Thus, either:

the call to t.Run within a Cleanup callback panics the test, or
the first-added Cleanup callback is executed after all of the subtests spawned by the second-added Cleanup callback have completed.

That would give an output like:
=== RUN   TestCleanupOrder
    prog.go:11: second cleanup
=== RUN   TestCleanupOrder/in_cleanup
    prog.go:15: running parallel subtest
=== CONT  TestCleanupOrder
    prog.go:7: first cleanup
--- PASS: TestCleanupOrder (0.00s)
    --- PASS: TestCleanupOrder/in_cleanup (0.00s)
PASS

What did you see instead?
The first Cleanup callback is executed before the parallel subtests spawned by the second Cleanup callback are run.
=== RUN   TestCleanupOrder
    prog.go:11: second cleanup
=== RUN   TestCleanupOrder/in_cleanup
=== PAUSE TestCleanupOrder/in_cleanup
=== CONT  TestCleanupOrder
    prog.go:7: first cleanup
=== CONT  TestCleanupOrder/in_cleanup
    prog.go:15: running parallel subtest
--- PASS: TestCleanupOrder (0.00s)
    --- PASS: TestCleanupOrder/in_cleanup (0.00s)
PASS

CC @ianlancetaylor @changkun @rogpeppe @jayconrod

Don't think too hard about this. Make t.Run panic during t.Cleanup callbacks.

FWIW, this broke a BDD-style structured testing library I maintain. It caught me off-guard because it wasn't mentioned in the go 1.20 release notes. As soon as I updated to 1.20 all of my tests broke and I've had to fall back to 1.19.x.
In the library, for the moment I've had to add:
//go:build go1.20

package onpar

func init() {
    panic("onpar v2 is broken in go v1.20.")
}

@nelsam Thanks.  I sent https://go.dev/cl/475215 to mention this in the release notes.

Thanks! the docs weren't very clear if it was supported, so I tried it and it worked. And it felt a lot cleaner than our old  defer o.Run(t) (which wasn't hard to forget). We've been relying on t.Cleanup since go 1.18.
I still don't know how I'm going to fix it, but I'm at least glad that the breaking change is in the release notes now.


Sweep: Automatically stream completions for visible scenarios, and don't stream completions for invisible ones

I think people will mostly always want their completions to stream if the output is visible, even if they don't explicitly ask for it. Conversely we shouldn't waste resources streaming completions that aren't on the current page even if the user did ask for it.

Isn't this already implemented?

Yes, you are correct


107 - Update All Themeing Variable Names To Camel Case

Issue Number
#107
The initial commit of this PR starts at 8a81c52.
Purpose/Implementation Notes

All themeing variable names will be updated to use camelCase, and adjust the codebase accordingly.

Updated the themeing variable names to use camelCase and adjusted the codebase accordingly.
No UI review required for this PR,  thank you!
Types of changes
New feature (non-breaking change which adds functionality)
Functional tests
List out the functional tests you've completed to verify your changes work locally.
Checklist

[x] Lint and unit tests pass locally with my changes

🗒 As mentioned in 1:1, due to the changes made in the recent PRs,  I’ll be closing any PRs that are no longer relevant. Since all the theming variables for the heading were removed and no longer used in the codebase and are one of the main cause for the merge conflicts thus, I am closing this PR as well.


Make RSA key size configurable

Right now, the RSA Key Size is hardcoded as a constant value. This issue is a request to get that made to be modifiable via environment variable as something like LEGO_RSA_KEYSIZE.
This would involve adding code here to receive a variable, and if one not set, utilize the constant value. Then a change would be made in this function to utilize the new variable for this value, instead of just consuming the constant.

Please add this!

Thanks for the thorough report @InAnimaTe - I've added the help-wanted label to this and assigned it to the next release. I'm currently trying to work through the back-log of issues and PRs, so won't have a chance to work on this myself just yet but contributions are very welcome, and I promise I'll get onto a review ASAP if there is one!


Problem using inference with trained model

Hi, @plkmo, first thank you for this repo, it is really nice.
I've trained a model using your script, this way:
python main_task.py \
    --model_no 1 \
    --model_size albert-large-v2 \
    --batch_size 16 \
    --lr 0.00004 \
    --train 1 \
    --infer 0

This generates a model in the data folder, called task_test_model_best_1.pth.tar.
Now I want to infer using this model that I previously trained, I tried doing this the following way:
!python main_task.py \
    --model_no 1 \
    --model_size "/path/to/model/task_test_model_best_1.pth.tar" \
    --train 0 \
    --infer 1

But when doing this, I'm getting the following error:
07/09/2020 10:28:10 PM [INFO]: Loading tokenizer and model...
07/09/2020 10:28:10 PM [INFO]: PyTorch version 1.5.1+cu101 available.
2020-07-09 22:28:10.268412: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudart.so.10.1
07/09/2020 10:28:11 PM [INFO]: TensorFlow version 2.2.0 available.
Traceback (most recent call last):
  File "main_task.py", line 53, in <module>
    inferer = infer_from_trained(args, detect_entities=True)
  File "/content/BERT-Relation-Extraction/src/tasks/infer.py", line 68, in __init__
    task='classification', n_classes_=self.args.num_classes)
  File "/content/BERT-Relation-Extraction/src/model/ALBERT/modeling_utils.py", line 389, in from_pretrained
    **kwargs,
  File "/content/BERT-Relation-Extraction/src/model/ALBERT/configuration_utils.py", line 176, in from_pretrained
    config_dict, kwargs = cls.get_config_dict(pretrained_model_name_or_path, **kwargs)
  File "/content/BERT-Relation-Extraction/src/model/ALBERT/configuration_utils.py", line 226, in get_config_dict
    config_dict = cls._dict_from_json_file(resolved_config_file)
  File "/content/BERT-Relation-Extraction/src/model/ALBERT/configuration_utils.py", line 315, in _dict_from_json_file
    text = reader.read()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

Am I doing this wrong? Could you please correct me if I'm using this script the wrong way?

model size for inference should be the same model_size albert-large-v2, the script automatically detects the saved model path so you dont have to pass it as parameter

model size for inference should be the same model_size albert-large-v2, the script automatically detects the saved model path so you dont have to pass it as parameter

May I ask why will the model detect the saved model path automatically? I don't see any code that specifies the model path, which makes me confused that how will the infer function load our fine-tuning model?

If I'm not mistaken, it loads the fine-tuned model in this line.
The load_state function automatically searches for the best model/last checkpoint and loads it into the NN. This is called from the infer_from_trained class, so the model you get has either the last checkpoint (by default) or the best model (if you change the load_state call to have load_best=True) loaded.


examples documentation

We should probably have a readme for each separate example explaining how to download data, download other dependencies (maybe view a requirements.txt we also add), and what this example illustrates (maybe some video or screenshots).

Also what If I want to git clone just one example? Is there some git magic to only get those files?

Or maybe you can easily download example with the zeno command

Also the data folder should be kept inside each example so people can easily download just the examples and know where to put the data

100% I want to redo how the examples are structured. Maybe we create a separate repository for all examples? I haven't decided what the best way to organize them are

Hmm good question. The one big upside of having the examples here is that its easier for development.

Perhaps if we can have the examples in a separate repo and do a repository link thingy

Made it into a new repo you can clone into the main Zeno folder to still do debugging.

Note in the future it might be nice to make it a submodule https://github.blog/2016-02-01-working-with-submodules/. Too much work for now.


CreationPage Iteration4

New development after meeting with Maskinporten has resulted in a new sketch for the CreationPage (from altinn-authentication: https://github.com/Altinn/altinn-authentication/issues/331)
This issue builds on previous 3 iterations in issue #19

### Tasks
- [x] reorganize columns of page
- [x] reorganize text of page
- [x] reorganize links of page

The fourth iteration of the CreationPage is now in repo master branch, looking like this:

The new user flow has been documented in the repo wiki.


Update webmock and http dependencies to latest

I'm using this gem in a project that also includes the twitter gem, which uses newer versions of the http and webmock gems.
I updated redd's dependencies with no apparent ill effects.
As per CONTRIBUTING.md I've manually tested this change. I'm only using very basic functionality from redd so it's possible I've missed something, but to the best of my knowledge this should be okay. ¯\_(ツ)_/¯

Ah, looks like those updated libraries aren't compatible with Ruby 2.1 -- that's the reason for the Travis failure.
If you're committed to supporting Ruby 2.1 then I suppose this is a no-go!


Report qemu driver with version in /1.0

As requested, this is a draft pull request for issue #7869, having implemented most of the things mentioned in the most recent comments.
As noted in the description of commit ead2141 the Info() function in driver_qemu.go isn't quite working yet, there's some runtime bugs that I haven't sorted out relating to finding the path of the qemu binary.
Additionally, there seems to be some kind of race condition in the creation of the driver cache, as either lxc or qemu can end up appearing first in the list, though I am unsure where this would be generated so it is not listed in any particular commit.

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

The ordering of the output will be random because you are using a map and these are randomly ordered in Go.

Just a few simple fixes and this should be good to go!

 I was squashing some commits to change the variable names and I rebased too far back, so it included old commits. I then did the more stupid thing of trying to force push that to my branch despite the warnings, because I assumed it was simply warning me about the changes from the squashed commits.
I am unsure of if this needs to be undone, and how I would go about doing it.

Normally you'd fix that with something like:

git remote update
git rebase origin/master
git push --force

If you can't easily make it behave, let me know and I'll fix it up for you.

That worked, thank you. Valuable lesson learnt on that one.

Just a few tweaks needed and we should be good to go on this one!

jenkins: test this please

looks good, will just do a quick rebase to turn all this into a single commit and we'll be good to go.

Rebase done, exact same code, just different commit messages and split :)

jenkins: test this please

Testsuite passed

Testsuite passed

thanks @wester162


Support variable length embeddings

Describe the feature or improvement you're requesting
From the blog on new embedding models:

Both of our new embedding models were trained with a technique that allows developers to trade-off performance and cost of using embeddings. Specifically, developers can shorten embeddings (i.e. remove some numbers from the end of the sequence) without the embedding losing its concept-representing properties by passing in the dimensions API parameter. For example, on the MTEB benchmark, a text-embedding-3-large embedding can be shortened to a size of 256 while still outperforming an unshortened text-embedding-ada-002 embedding with a size of 1536.

Based on the API reference, this is available via a new parameter on the embedding request called dimensions (optional integer).
Additional context
I'm happy to write a PR for this.

@adri1wald PR please

https://github.com/dongri/openai-api-rs/pull/74/files
Added dimensions

https://github.com/dongri/openai-api-rs/pull/74


[web]: can't import 'dart:ffi'

Describe your issue and include the command you're running, flutter_web version, browser version

C:\Users\jmarkel\AndroidStudioProjects\audacy_on_tap>flutter build web
Compiling lib\main.dart for the Web...                                 |
...Exception: lib/choose_lights.dart:10:8:
Error: Not found: 'dart:ffi'
import 'dart:ffi';
       ^
Error: Compilation failed.

Failed to compile application for the Web.

Though the import works fine when just using dart:
C:\Users\jmarkel\AndroidStudioProjects\audacy_on_tap>dart hello.dart
Hello, World!

C:\Users\jmarkel\AndroidStudioProjects\audacy_on_tap>cat hello.dart
import 'dart:ffi';

void main() {
    print("Hello, World!");
    return;
}

C:\flutter\flutter>flutter --version
Flutter 1.10.14 • channel dev • https://github.com/flutter/flutter.git
Framework • revision 1946fc4da0 (3 weeks ago) • 2019-10-07 15:23:31 -0700
Engine • revision 1d62160fdb
Tools • Dart 2.6.0 (build 2.6.0-dev.5.0 d6c6d12ebf)

You can't use FFI on the web, if that is what you are trying to do?

Yes, that was the goal.
We are attempting to create a web application on an embedded device.
Certain actions from the ui must trigger actions to other processes running
on the target. What are some options to achieve this?
Thanks
On Thu, Oct 31, 2019 at 9:35 AM Jonah Williams<EMAIL_ADDRESS>wrote:

You can't use FFI on the web, if that is what you are trying to do?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/43898?email_source=notifications&email_token=AAZ7UBVRXQ2KPDQJM4QMO2TQRLUMFA5CNFSM4JHISYB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECX7SIY#issuecomment-548403491,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZ7UBVVSW7WL7HTGTILUDLQRLUMFANCNFSM4JHISYBQ
.

Currently on the web the recommended way to interop with the browser is to create a plugin and use package:js to access JavaScript. It is unclear what dart:ffi would do on the Web.

Running on web logs
Launching lib\main.dart on Web Server in debug mode...
Syncing files to device Web Server...
/C:/flutter/flutter/.pub-cache/hosted/pub.dartlang.org/majascan-0.3.7/lib/majascan.dart:2:8:
Error: Not found: 'dart:ffi'
import 'dart:ffi';
^
Failed to compile application.
what should i do ?

So I have no idea if this is possible or not. Is it possible for dart:ffi to target to wasm?

Is it possible for dart:ffi to target to wasm?

I would like to know too. This would make cpp libraries usable on all platforms wouldn't it ?


#302 Added support for gradient line charts

Implemented gradients for line charts
Added a new example to showcase the new behavior

Nice! Thanks!


How can I test my image using this program.

Hi, I am a graduate student and I have a interest about this project.
I wanna try it, but I think it is just implemented training section only.
How can I output masked images from my own images using this tool?

hi,OK ?


numpy.arange() / numpy.sum() segfaults

examples/sumto2 seems to crash with a segfault. Would be good if we could create a proper test case instead of just an examples. We do test to make sure that all examples compile but we don't actually run them (since we don't know what the expected outcome should be, some example apps are interactive, others are not, some expect arguments etc).
@sydow will you pick up on this one?

@sydow this issue isn't particularly prioritized right now, I just noticed it when I tried to change arange() to accept the same type of arguments as range() as per the conversation in #102. I think the improved error messages following improved rows and comprehensions are much more valuable and indeed higher priority! Looking forward to your work there :)
I can't really say if we should ditch numpy or not. It's not really used but it doesn't seem to be that much extra work, right? We could of course rip it out and reintroduce at some later point in time. I don't have any strong arguments for or against it :shrug:


CEXIO: TypeError: Cannot read property 'amount' of undefined

me/martin/CEX.io/plugins/trader/portfolioManager.js:110
return this.getFund(fund).amount;
^
TypeError: Cannot read property 'amount' of undefined
at Manager.getBalance (/home/martin/CEX.io/plugins/trader/portfolioManager.js:110:28)
at Manager.bound [as getBalance] (/home/martin/CEX.io/node_modules/lodash/dist/lodash.js:729:21)
at Manager.act (/home/martin/CEX.io/plugins/trader/portfolioManager.js:138:23)
at bound (/home/martin/CEX.io/node_modules/lodash/dist/lodash.js:729:21)
at /home/martin/CEX.io/node_modules/async/lib/async.js:232:13
at /home/martin/CEX.io/node_modules/async/lib/async.js:142:25
at /home/martin/CEX.io/node_modules/async/lib/async.js:229:17
at /home/martin/CEX.io/node_modules/async/lib/async.js:556:34
at Manager. (/home/martin/CEX.io/plugins/trader/portfolioManager.js:76:7)
at Trader.calculate (/home/martin/CEX.io/exchanges/cexio.js:135:5)

Sory miss clicked wanted to write more

Hapnend on cex io

most probably related to #481.

Thanks a lot :D as a student i see a lot of potential in this bot with my 12 euros. Invested years ago :) anybody good setings for cex ?
My config for cex
// MACD settings:
config.MACD = {
// EMA weight (  )
// the higher the weight, the more smooth (and delayed) the line
short: 12,                                                                 long: 26,
signal: 9,
// the difference between the EMAs (to act as triggers)
thresholds: {
down: -0.0000025,
up: 0.0000025,
// How many candle intervals should a trend persist
// before we consider it real?
persistence: 1

Could you update and try again?

Thanks a lot :D as a student i see a lot of potential in this bot with my 12 euros. Invested years ago :) anybody good setings for cex ?

If I were you I would start by backtesting and or paper trading until you find a strategy that is profitable. The default settings are not recommended to be ran with real money.


Possible draw over status bar?

Option to hide status bar and replace with a built in one similar to wp?

And maybe a control center? Custom noti shades/control centers are all over google play so its definitely possible

I’m closing this issue because it’s better to make a system-wide change rather than adding it individually for this app. Stay tuned for MetroOS https://discord.gg/x4zEWXY62S


Docblocks

Standardize docblocks and use http://peej.github.com/phpdoctor/

Using apigen instead.


data entry sheet reload fix

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


Problem

I try to put Mekanism mod into my Minecraft and found out that it is conflicting with the mods that I have in the mods folder. What I mean is that it wont let the map load it goes from building terrain to back to the main menu and doesn't load the map I have try a lot of different ways and it still doesn't load the map.

Not on my end.


Please provide a License for CSOM compatible with .NET Standard cross platform?

FYI your license link for the package https://www.nuget.org/packages/Microsoft.SharePointOnline.CSOM is broken
However, I managed to track down a license through some googling:
MICROSOFT SHAREPOINT CLIENT COMPONENTS.
This specifically forbids distributing on any platform other than Windows.
iii. Distribution Restrictions. You may not
    * distribute Distributable Code to run on a platform other than the
      Windows platform;

Are there any plans to update the License around this product now that it has gone .NET Standard and effectively cross platform?

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

ID: 80e62a9d-06d0-ebc3-2c99-ce459388182a
Version Independent ID: 07d8b090-b18c-842d-ba1e-0f2b2a127ad3
Content: Using CSOM for .Net Standard instead of CSOM for .Net Framework
Content Source: docs/sp-add-ins/using-csom-for-dotnet-standard.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Good points... I'll raise with engineering as this is something MSFT needs to comment on being licensing.


Failed to resolve entry for package

Receiving this error after upgrading to the latest version.
✘ [ERROR] [plugin vite:dep-scan] Failed to resolve entry for package "svelte-awesome-color-picker". The package may have incorrect main/module/exports specified in its package.json: No known conditions for "." entry in "svelte-awesome-color-picker" package

    node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40945:10:
      40945 │     throw new Error(`Failed to resolve entry for package "${id}". ` +
            ╵           ^

    at packageEntryFailure (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40945:11)
    at resolvePackageEntry (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40941:9)
    at tryNodeResolve (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40748:20)
    at Context.resolveId (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40556:28)
    at Object.resolveId (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:39229:55)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async resolve (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:39441:26)
    at async /Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:39601:34
    at async callback (/Users/user/Documents/projects/me/kart/front/node_modules/esbuild/lib/main.js:929:28)
    at async handleRequest (/Users/user/Documents/projects/me/kart/front/node_modules/esbuild/lib/main.js:709:30)

  This error came from the "onResolve" callback registered here:

    node_modules/vite/dist/node/chunks/dep-8f5c9290.js:39591:18:
      39591 │             build.onResolve({
            ╵                   ~~~~~~~~~

    at setup (/Users/user/Documents/projects/me/kart/front/node_modules/vite/dist/node/chunks/dep-8f5c9290.js:39591:19)
    at handlePlugins (/Users/user/Documents/projects/me/kart/front/node_modules/esbuild/lib/main.js:851:23)

  The plugin "vite:dep-scan" was triggered by this import

    script:/Users/user/Documents/projects/me/kart/front/src/ParamPicker.svelte?id=0:32:7:
      32 │ import "svelte-awesome-color-picker"
         ╵        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Build failed with 1 error:
node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40945:10: ERROR: [plugin: vite:dep-scan] Failed to resolve entry for package "svelte-awesome-color-picker". The package may have incorrect main/module/exports specified in its package.json: No known conditions for "." entry in "svelte-awesome-color-picker" package

My devDependencies:
{
    "@svelte-plugins/tooltips": "^3.0.0",
    "@sveltejs/vite-plugin-svelte": "^1.0.0-next.30",
    "@tsconfig/svelte": "^2.0.1",
    "@zerodevx/svelte-toast": "^0.7.2",
    "sass": "^1.71.1",
    "svelte": "^3.44.0",
    "svelte-check": "^2.2.7",
    "svelte-gestures": "^1.5.2",
    "svelte-icons": "^2.1.0",
    "svelte-loading-spinners": "^0.1.7",
    "svelte-preprocess": "^4.9.8",
    "tslib": "^2.3.1",
    "typescript": "^4.5.4",
    "vite": "^2.9.9",
    "vite-plugin-node-polyfills": "^0.21.0"
  }

I tried upgrading svelte version to 3.55 but had no effect

Is your project public? Do you have a minimal reproducible example?
On the REPL (which is a different environment than yours):

svelte v3.44.0: it loads but the picker is broken
svelte v3.55.0: it works
svelte v3.59.2 (latest 3xx version) : it works

Is your project public?
@Ennoriel Yes, you can take a look at my project - just pull, go to /front, and perform yarn and serve with yarn dev. It should be working well.
Then when running yarn upgrade svelte svelte-awesome-color-picker --latest you should be able to see the error

Hello @JCM00N
Have you found a solution since you last reply?
This stack overflow post suggests to update vite to version 4. Can you do that and let me know if the problem is still there?
Thank you for using svelte-awesome-color-picker 🧡


Collapsible TOC list entries on configurable level

You can easily test the changes by using the docker image designed for developing bookdown themes:
docker run -it \
    -v $(pwd):/app \
    -v /path/to/your/clone/of/bookdown-bootswatch-templates/templates:/templates \
    -p 8080:8080 \
    -e TOC_SUBLIST_LEVEL=4
    asperling/bookdown-template-develop \
    docs/bookdown.json

It will generate your documentation, make it available http://localhost:8080 and regenerate it if you work on the template files,

First of all great work @asperling.But I found a bug. If you use export TOC_SUBLIST_LEVEL=1 I get a strange Processing content with errors. Could you please fix that error and I will accept your push request.

Done.


added paperless-ngx

https://github.com/jonaswinkler/paperless-ng/issues/1599
https://github.com/jonaswinkler/paperless-ng/issues/1632

Awesome, thank you


Limits for parameters are not documented

Through experimentation I have discovered that the ExceptIfSubjectOrBodyContainsWords parameter is limited to 128 characters. It would be great if you could include all of these limitations in the documentation.

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

ID: f48ae8ec-b719-c4db-c259-02e4f9e779b5
Version Independent ID: 96f609a7-578e-5568-adb3-61f483997870
Content: Set-TransportRule (ExchangePowerShell)
Content Source: exchange/exchange-ps/exchange/Set-TransportRule.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

For comparison, the documentation on Set-DlpComplianceRule seems to have such limits documented for the individual parameters. It would be interesting though, if these limits are actually based on service limits, such as those listed in Journal, transport, and inbox rule limits, as this would allow to simple reference those.

@jeremyhagan, I confirmed the limit is 128 characters in Exchange 2010 to 2019 and in Exchange Online. I updated the parameter descriptions accordingly.
The same parameters (and some other related ones) in New/Set-InboxRule have a limit of 255 characters, so I updated the information in those parameter descriptions as well.
Thanks for the feedback.
Closing


Update main.go

Fix Make build

Thank you! I didn't saw that. I hope it is helpful to have a working terraform provider at last!

Working great so far! The only odd thing is you have to add at least one custom field to IP's and Subnets for it work when actually applying in Terraform. I believe that was an issue with the original, however.


Refine Discover API

See the Technical Specification.
Refine design for downloading datasets.
See #single-cell-portal-redesign
The response to GET /v1/collections/{collection_id}/datasets/{dataset_id}/assets must be reviewed in light of portal design, including the addition of a dataset version id.
Also see Include in "dataset_version_id" in "datasets" table of Cell Census schema

Downloading specific versions of datasets
To address emerging requirements for reproducibility and the data reuse policy:

The response must include a permanent link (url) to each version of a dataset and its artifact.
It must be possible to easily download the related dataset - preferably through a simple GET operation.

Requirements from ongoing reproducibility discussions:
As a scientist who shares a finding based on versioned CZ CELLxGENE Discover data assets, I want to be equipped to explain how other scientists can reproduce my finding from the versioned CZ CELLxGENE Discover data assets so that they can review, trust, build on and cite my work.
Requirement: Scientists can access long term supported versions of h5ad and rds assets. All versions upon publication/revision are long-term supported.

Can presigned URLs be eliminated?
As noted in bug(API): Presigned S3 urls don't last long enough.:
@atolopko-czi noted:

Might we be able to do away with pre-signed URLs entirely for downloads by making these data artifacts public S3 objects? If we need to maintain our ability to revoke access (e.g. for tombstoned data), then we can also look into using https://aws.amazon.com/s3/features/access-points/.

Remove filename from the response for GET /collections/{collection_id}/datasets/{dataset_id}/assets
This was reported by an early reviewer of the Discover API.
In GET /collections/{collection_id}/datasets/{dataset_id}/assets, there is no rationale to surface the dataset filename which is always "local.[h5ad|seurat]". It also is echoed in the presigned_url.  Consumers select downloads by format and can rename the file.
[{'filename': 'local.rds',
  'filesize': 837811485,
  'filetype': 'RDS',
  'presigned_url': 'https://corpora-data-dev.s3.amazonaws.com/05b1dbc7-0add-4da1-9e77-39dc1bfdc1f0/local.rds...},
 {'filename': 'local.h5ad',
  'filesize': 703248747,
  'filetype': 'H5AD',
  'presigned_url': 'https://corpora-data-dev.s3.amazonaws.com/05b1dbc7-0add-4da1-9e77-39dc1bfdc1f0/local.h5ad...'}]

Refine and document new dataset asset for curator submitted H5AD
See single-cell-portal-redesign.
The curator submitted H5AD is now returned in dataset_assets as 'raw.h5ad'.

'dataset_assets': [{'filename': 'raw.h5ad', 'filetype': 'H5AD'},
  {'filename': 'local.h5ad', 'filetype': 'H5AD'},
  {'filename': 'local.rds', 'filetype': 'RDS'}],

This is the H5AD without ontology and gene labels.
This was not reviewed with product before it was surfaced in the API. It is not currently documented in the swagger which may cause confusion for early access consumers - "Which H5AD do I download and what is the difference between the two".
In addition, the unlabeled H5AD is only useful for curators. It saves them the step of stripping the labels prior to revalidation and submission. I need to verify if it's only returned for curator roles and not consumers.

Can bulk downloads be optimized?
Including cell census, there are cases where consumers want to perform a bulk download of the entire data corpus. Should we consider a more optimized endpoint that requires less API calls to return a list of datasets and relevant collection metadata?

Analytics Requirements
https://docs.google.com/document/d/1YLH23M7Fk2_0DIo41aLEtnTzy5RtgMq-2Y9EBXJwv-k/edit

Refine design for private revisions of public collections.
See single-cell-discover-api.
The portal redesign introduced ambiguity to the revision flow and related dataset metadata. The current behavior appears to be:

Datasets in a fresh revision immediately receive a new UUID.
A new field, datasets.original_id is set to the published dataset UUID. datasets.revision_of is set to None.
IF a published Dataset is updated in the revision, then it receives another new UUID. datasets.revision_of is then set to the published dataset UUID which matches the datasets.original_id.

Perhaps a cleaner design might be:

Datasets in a fresh revision DO NOT receive a new UUID.
IF a published dataset is updated in the revision, then it receives a new UUID. datasetss.revision_of is then set to the published dataset UUID.

This eliminates the need for datasets.original_id.
During testing, there were related conversations in single-cell-portal-redesign about original behavior after the redesign - dataset UUIDs were not updated UNLESS the dataset was updated in the revision (copy on wriite model) where I noted in the thread:

To be clear, I'm fine with the policy of not changing original uuids until there's an update to an existing dataset.

Documentation issues
In addition, it appears that datasets.revision_of has never been documented in the API (swagger).
The description for the Null value for datasets.original_id is unclear and incorrect?

For Datasets in private revisions of published Datasets, a unique identifier of the published Dataset counterpart if applicable. Null if the published Collection does not contain the revision Dataset.

Perhaps:

For previously published datasets in a private revision of a collection, original_id is set to the id of the corresponding published dataset. If new datasets are added to the private revision of a collection, then original_id is set to Null.

Deprecate datasets.revisions
See single-cell-data-portal-redesign. Further investigation has determined that datasets.revision is not strongly required by our current users. Rather than patching the current regression, the field should simply be deprecated.

@danieljhegeman / @nayib-jose-gloria : As your first task on this epic, please review the proposed issues and priorities and provide estimates. Based on that info, we'll scope this epic to fit in the allotted time.

Remove filename from the response for GET /collections/{collection_id}/datasets/{dataset_id}/assets: isn't this endpoint going to be removed entirely? @danieljhegeman


Give back the maintainer right

Hi,
This repository seems to lack maintenance, I propose myself as a new maintainer.
Could you give me the right to push in your repository or just transfer it on my account in github?
Thank you

I can adopt it

everyone is dead??

it seems :)

@jamespacileo If you do not intend to continue to maintain this project, I suggest transferring it to the https://jazzband.co/ organization and let the community the responsibility to maintain.
Some good projects like django-debug-toolbar are in the Jazzband umbrella


fix: tweak snackbars per material guidelines

MUMMNG-4155: "As a user who recently deleted a widget from my layout, I would like the opportunity to undo my action before the snackbar disappears, so that I may undo a delete if I want."
Material guidelines for snackbars & toasts
In this PR:

Increased time before auto-hide
Removed customizations that made snackbars look like notifications
No longer show widget icons in snackbar message
Snackbar always appears fixed to bottom of viewport (so it's always visible)

Demo/screenshot

Contributor License Agreement adherence:

[x] This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

I haven't found any specific guidance either, but both Angular Material projects use 3 seconds as the default delay before hiding. I think we have wiggle room to set it to whatever we feel is appropriate.

I do like defaults.  We can see how this goes.  My gut says 4 seconds is probably enough, but we can probably see how this goes with actual users.


SSL Support?

I'm trying to dockerize an SP Addin, but to have it working I think I need have it running under https, what can I do to enable it....

Install a cert and set up an https binding. You can use the IISAdministration PowerShell cmdlets/appcmd.exe to achieve that


Widen typebox peerDependency to allow 0.26

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the issue has not already been raised

Issue
typebox released version 0.26, but the peerDependency constraint prevents properly updating typebox without causing issues with the Fastify integration.
Since typebox is still at 0.x, the ^ version constraint doesn't include minor versions yet.
I'd suggest widening it to ^0.25.9 || ^0.26.0.
Release notes: https://github.com/sinclairzx81/typebox/pull/346

I don't really care as much either way as long as it's bumped so that I can start using 0.26 🙂

It's already ^0.26.x, so closing.

@mcollina
we are not only using @sinclair/typebox to define fastify sachems. we also use @sinclair/typebox in other project parts (e.g. validating mqtt messages). cause this module uses it's own version of typebox, we may end up with two different typebox versions in our project with is not compatible with each other.
isn't better to keep @sinclair/typebox as a peer-dependencies for this case?

isn't better to keep @sinclair/typebox as a peer-dependencies because of this case?

This package expose whole typebox utilities, so if you are using it inside fastify project.
You don't need to explicitly install typebox yourself.

See: #73

@climba03003
Your suggestion implies that I should always import typebox from fastify-type-provider-typebox, even in modules unrelated to Fastify.
I have created this module to integrate Typebox with Fetch, but I can't use it in a Fastify project because Fastify uses its own version/copy of Typebox.
This is precisely what peerDependencies are designed for.


Initial framework of the formal UI design

This PR is the initial commit of the formal UI design, including:

Import the UI design assets for the cutting board, the indicator, the navbar, and the markers
Layout the UI elements in two major layers (a front overlay layer and a cutting board cover layer). Place the cutting board 3d mesh in the back and put the reference object in between the two UI layers.
Use Unity localization package to support string and assets localization, with en-US and zh-CN locales
Import the fonts to render English and Chinese content.
Implement utility classes to control the UI display for different levels of visualizable numbers.
A little bit of animation code to demonstrate the UI design for the cutting board. Will be removed in later PRs.

Not including:

Now the Calculator in the UI is still an empty panel, waiting for more assets and code.
The real reference objects have not been introduced. Current PR only contains a sample cube to demonstrate a fake reference object.

For your reference, here is a video that shows the situation of the UI framework with this PR submitted:
https://user-images.githubusercontent.com/5819968/143764179-68678a90-b0ab-4304-b2eb-ce9372191d0c.mp4


feat: playing audio source android

Closes #218
Introduced changes

Checklist

[ ] Linked relevant issue
[ ] Updated relevant documentation
[ ] Added/Conducted relevant tests
[ ] Performed self-review of the code

https://docs.expo.dev/bare/installing-expo-modules/


Create a better logo for Slanine

Make it look classy and cool, you can add it by adding it in the files and changing the layout.tsx.

can you please assign to me

Assigned to you both the issues @Charul00

Any update @Charul00 ?

@Rakshit-gen do you have any specific design in mind that you want?

I don't have any as of now @coderKrysio but a black circular logo with S in between and maybe a bit simple but classy type.
You can use any software to build it

okay I will make a draft with the above description and will attach it here
if you find it suitable then you can assign me this issue

@coderKrysio sure that will be great!

hey @Rakshit-gen

this is the first draft I came up with
if you any modifications, let me know

Ohh this one looks good actually!
If you can add a little shine I'll like to see that @coderKrysio

second draft

Let's go with the first one @coderKrysio , it looks better
I assigned the issue to you, save the icon as a ico file or convert it into one.
Name it favicon.ico and update it in the local repo in the public folder.

should I remove the background first as it is set to #000?

Sure you can do it! Set it to something more appropriate,
If you modify the landing page components too then will rate the pr a level 3.

hey @Rakshit-gen
i have finished all the other two changes on homepage but just want a confirmation on the favicon
which one do you thing is the best to go

The first one I will say @coderKrysio


tesseract: 3.05.00 -> 3.05.01

Not sure whether the tesserdata attribute needs an update as well...
Things done

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

[ ] NixOS
[ ] macOS
[ ] 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 nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Updating pyocr to 0.5.1 might help.

Meanwhile, 3.05.02 was released.

Outdated.


Added an example of integrating Bootstrap via React-Bootstrap

Q
A

content fix?
no

New article?
yes

Related issues?

What's in this Pull Request?
An example of using Bootstrap in a SharePoint Framework.
It picks up the Bootstrap CSS by using a dynamic link to a CDN.
It uses React-Bootstrap in order to add the Bootstrap functionality without requiring jQuery.
It implements the React way of doing properties and state as outlined in Thinking in React.

Hi @sebastianrogers, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

Hi Sebastian,
this article looks really good, but unfortunately after long internal discussions, we have decided not to merge it for now. Article is valid and works great, but since we want to promote Office UI Fabric as the official platform from product perspective, we do not feel good on having then conflicting article in the official product documentation with alternative solution.
Technically using bootstrap is absolutely a valid solution and you can certainly take advantage of that in custom client-side web parts or with other solutions built with SPFx, but since these articles will be published in the official documentation, merging this in does not seem like the right thing to do.
We would though encourage you to create a blog post around this to some other platform and more than happy to promote that within social media using different channels. I do also apology the delay on getting this final conclusion, but this was also long lasting internal discussion on how we want to position this documentation.
We will also update the contribution guidance to include this kind of information - since we were clearly missing the details on what we would accept in and what not.

Hi Vesa
Thanks for getting back to me, I appreciate it (and understand the delay).
I've added it to my blog here and would be grateful if you would mention it.
https://simpleinnovationassociates.wordpress.com/2016/10/16/add-the-react-bootstrap-framework-to-your-sharepoint-client-side-web-part/
Right onto my next challenge - a UK compliant macro-review front end for Records Management in SharePoint using Angular 2, Azure DocumentDB and Office 365 a long term project of mine.
Sebastian Rogers
Technical Director
Simple Innovations
E<EMAIL_ADDRESS>T: 07976 562661
W: simpleinnovation.co.uk

From: Vesa Juvonen<EMAIL_ADDRESS>Sent: 15 October 2016 15:16:45
To: SharePoint/sp-dev-docs
Cc: Sebastian Rogers; Mention
Subject: Re: [SharePoint/sp-dev-docs] Added an example of integrating Bootstrap via React-Bootstrap (#210)
Hi Sebastian,
this article looks really good, but unfortunately after long internal discussions, we have decided not to merge it for now. Article is valid and works great, but since we want to promote Office UI Fabric as the official platform from product perspective, we do not feel good on having then conflicting article in the official product documentation with alternative solution.
Technically using bootstrap is absolutely a valid solution and you can certainly take advantage of that in custom client-side web parts or with other solutions built with SPFx, but since these articles will be published in the official documentation, merging this in does not seem like the right thing to do.
We would though encourage you to create a blog post around this to some other platform and more than happy to promote that within social media using different channels. I do also apology the delay on getting this final conclusion, but this was also long lasting internal discussion on how we want to position this documentation.
We will also update the contribution guidance to include this kind of information - since we were clearly missing the details on what we would accept in and what not.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SharePoint/sp-dev-docs/pull/210#issuecomment-253986901, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFtHXGdC1z7rEMTEMGBohLhfpjaAwy-Kks5q0OBNgaJpZM4KDRl0.


When integrating with CookieConsent it still sets cookies

It would be great if IframeManager could have an option to disable cookies. If using CookieConsent integration it's all handled there. It just makes documenting the cookies a bit easier as with the current setup you end up documenting every cookie for every service setup when really you could cover it all under a single cookie (CookieConsent's)

Not an exact duplicate of #23, but similar.


Fix the broken links

Category

[x] Content fix
[ ] New article
[ ] Example checked item (delete this line)

What's in this Pull Request?

Fix the broken links
Note - unfortunately, localization is not working property for these links and these links are working only with en-US so these links include the 'en-us'..

@VesaJuvonen  - Resubmitted the PR - https://github.com/SharePoint/sp-dev-docs/pull/5749#event-3350994436

Please remove all locale's from Microsoft managed URLs... they are set dynamically based on the requestor's HTTP headers.

@andrewconnell  - yes, you are right, Unfortunately, Localization is not working property for  these  both URLs
https://www.microsoft.com/microsoft-365/blog/2012/10/29/show-off-your-style-with-sharepoint-theming
https://www.microsoft.com/microsoft-365/blog/2017/05/16/new-sharepoint-and-onedrive-capabilities-accelerate-your-digital-transformation-2/
Example - https://www.microsoft.com/microsoft-365/blog/2012/10/29/show-off-your-style-with-sharepoint-theming/ - this URL is working only for en-us requesters,
I am from India. when access URL without localization https://www.microsoft.com/microsoft-365/blog/2012/10/29/show-off-your-style-with-sharepoint-theming/
It is redirecting to https://www.microsoft.com/en-in/microsoft-365/blog/2012/10/29/show-off-your-style-with-sharepoint-theming/
I am getting below error. it is working only with en-us.

@PrasadKasireddy For URLs where localization isn't working, you can use direct paths. It's not just India for those... when you explicitly set a different locale (like es-es), they aren't loading either.
So... the ones that work without a locale, there should be no locale. Otherwise, you can point to en-us

@andrewconnell

Earlier I submitted the PR (Resubmitted the PR - #5749 (comment) with direct URLs, due to localization issue, the URLs are not redirecting property to local URLs, what's a reason Vesa reject the PR.

Now URLs are pointed to en-us which is working propertly.


Extend docs to surface type information from schema

refs:

https://github.com/jsonnet-libs/docsonnet/pull/56
https://github.com/jsonnet-libs/docsonnet/pull/57

Done in #130


TypeScript regression: "Property 'displayName' does not exist on type ..."

Since v4.3.4, commit https://github.com/mobxjs/mobx-react/commit/f478d5e77203c8ad4516bfe17ab6e2c5ec422466 introduced a regression:
const FooBar = observer(() => <div />);
FooBar.displayName = 'FooBar';

Error:
[ts] Property 'displayName' does not exist on type '() => Element'.

This is because now observer is defined as:
export function observer<T extends IReactComponent>(
    target: T
): T

and does not return React.ClassicComponentClass<P> as before: https://github.com/mobxjs/mobx-react/blob/4.3.3/src/index.d.ts#L26
Writing FooBar.displayName = 'FooBar' is important otherwise you get _class in React DevTools instead of FooBar, see https://github.com/mobxjs/mobx-react/pull/340#issuecomment-341664886
From my tests, it seems this is more a react.d.ts problem:
const FooBar1 = observer(() => <div />);
FooBar1.displayName = 'FooBar'; // Error

const FooBar2 = () => <div />;
FooBar2.displayName = 'FooBar'; // Error

const FooBar3: React.SFC = () => <div />;
FooBar3.displayName = 'FooBar';

const FooBar4 = observer(() => <div />) as React.SFC;
FooBar4.displayName = 'FooBar';

vscode screenshot:

Even if its a react.d.ts issue, I wanted you opinion on it (is the as React.SFC cast legit and wanted?).
Thx in advance

I  did a 1 minute search but couldn't really find that displayName is actually a feature of SDFc's, I think they are supposed to be used like const FooBar1 = observer(function Foobar () { return <div /> }); if you want to name them?
Anyway I think it is a useful feature but should be fixed primarily in the react typings I think. I think the new typings are neater then they were since they return the type that you passed in, instead of always returning a ClassicComponent. The current typings are neater I think

Thx for you reply.
const FooBar1 = observer(function Foobar () { return <div /> }): this works.
In the end I prefer writing (Foobar as React.SFC).displayName = 'Foobar' => more explicit.


export Objectish type

🚀 Feature Proposal
I created a wrapper for immer in Svelte to enhance its capabilities and I am using a generic type for that. The problem is that applyPatches accepts a type that extends the Objectish type which I cannot import. I propose to export this type.
Can this be solved in user-land code?
I can copy paste the type from the source code.
Example
import { applyPatches, enablePatches } from "immer";

// I need to duplicate this because there is no export in immer
type Objectish = { [key: string]: unknown } | Array<unknown> | Set<unknown> | Map<unknown, unknown>;

enablePatches();

export const createImmerStore = <T extends Objectish>(obj: T) => {
  let state = obj;

  const draftStore = {
    // ...
    undo() {
      // if I don't use `T extends Objectish` it throws an error
      state = applyPatches(state, undo.inversePatches);
    },
  };

  // ...
};

Feel free to PR
On Tue, 25 Apr 2023, 15:48 Milan Jaritz, @.***> wrote:

🚀 Feature Proposal
I created a wrapper for immer in Svelte to enhance its capabilities and I
am using a generic type for that. The problem is that applyPatches
accepts a type that extends the Objectish type which I cannot import. I
propose to export this type.
Can this be solved in user-land code?
I can copy paste the type from the source code.
Example
import { applyPatches, enablePatches } from "immer";
// I need to duplicate this because there is no export in immertype Objectish = { [key: string]: unknown } | Array | Set | Map<unknown, unknown>;
enablePatches();
export const createImmerStore = (obj: T) => {
let state = obj;
const draftStore = {
// ...
undo() {
// if I don't use T extends Objectish it throws an error
state = applyPatches(state, undo.inversePatches);
},
};
// ...};
—
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/1041, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBGU6RIJZB2Q3IR4GGLXC7IZNANCNFSM6AAAAAAXLBEX6E
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Bity Transaction

I sent .510 ETH from Myetherwallet to 0x1e4ace701f5900c3d57dd50525aabc462137f4ba at Bity,
reference number BITYL7UNRR ,
I should have received 0.05517497 BTC to 1LtDXqv1JxFM3dVNTidhaoNcWDJQWNo8uc.
https://etherscan.io/block/3853208
https://etherscan.io/address/0x1e4ace701f5900c3d57dd50525aabc462137f4ba

Please go back to https://www.myetherwallet.com/#swap and click the "Issue with your Swap? Contact support." link at the bottom of the page.
This will send an email to both us and<EMAIL_ADDRESS>with the information we need from you in order to look into the issue. Namely:
REF ID#:
Amount to send:
Amount to receive:
Payment Address:
Thanks.


Packaging packages... setuptools style

I develop my projects as packages, and find it strange that this workflow isn't supported with serverless-python-requirements.
As an example, I might have a project xyz with a directory structure like this:
xyz/
  - serverless.yaml
  - setup.py
  - xyz/
    - __init__.py
    - app.py

And during development, I'll use pip install -e ., or python setup.py develop, or more probably pipenv install "-e .".
However, when processing the artifact requirements.txt that's produced by serverless-python-requirements I run into two problems:

the editable feature (-e ...) is not supported during the transformation to an uploadable zip file.
the reference to path . is not supported.

I've somewhat worked around this by disabling pipenv in the plugin options for serverless-python-requirements in my serverless.yaml file, and manage a custom requirements.txt file that is really just a pip freeze > requirements.txt and removing the -e . requirement.
What is the expected workflow here?

Experimenting a bit with it, I don't think it's currently possible with pipenv. I created this Pipfile but run into #85.
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[dev-packages]
[packages]
xyz = {path = "."}

However, without pipenv, . in a requirements.txt works fine AFAICT.

@dschep yeah, looks like you've retraced my steps!
When you say that . in a requirements.txt "works fine", I assume you're packaging with usePipenv: false, right?
Are you also trying with . or -e . in your requirements.txt file? As described in the setuptools docs I need setuptools develop mode (which is what pip -e provides) or else I'll need to reinstall the project after every change.

Just ., but yeah, makes sense that you'd need -e . for development. And I just didn't have Pipfile when I was trying requirements.txt.
Possible workaround:
you could set usePipenv: false and use pipenv for your local dev, and use a requirements.txt for deploy, manually generated with
pipenv lock -r | sed -e 's/-e//' > requirements.txt

Possible fix:
turn editable requirements into non-editable
It might make sense for the plugin to filter the requirements and remove -e(as in the above workaround) since there's no need for editable packages in actual deployments to lambda.
add option to not use hashes
This would fix #85 allowing the Pipfile I provided above to work (tho.. is that editable or not?). Would be behind a custom.pythonRequirements.pipenvHashes=false option.

As you noticed, I tested the bugfix that #85 references pipenv #1380 and that solution doesn't seem to be totally working yet.
Anyway, what's interesting is that when pipenv produces the locked requirements file (on master), it actually just comments out the "-e ." entirely from the requirements.txt file. I.e.
# requirements
boto3==1.5.32 --hash=sha256:8db0b63e0bdf0b188803a4a793a0779369d7b08e45758d0fe0ac610d124bc019  --hash=sha256:0591da93d0c5e8fda7f032cd3e175e93ab0baf7b5174e07aee92b48baeb5582f
botocore==1.8.46 --hash=sha256:52bc09d2f4439bb89ec9606ad652dedeb5bfe2c4db56f27417f4d2e5e50e4e79  --hash=sha256:d798b9aa32e070f6483a9723fb3296da546a2d9d09f17bb62adc57eb5771aaa6
docutils==0.14 --hash=sha256:7a4bd47eaf6596e1295ecb11361139febe29b084a87bf005bf899f9a42edc3c6  --hash=sha256:02aec4bd92ab067f6ff27a38a38a41173bf01bed8f89157768c1573f53e474a6  --hash=sha256:51e64ef2ebfb29cae1faa133b3710143496eca21c530f3f71424d77687764274
...
# -e .

I'm not sure that that's the right solution, either. But it would be the third alternative "get rid of editable requirement all-together". That's effectively the same work around I came to when I opened this issue, I'm just not clear on all the repercussions of doing this.

Hey 👋 I'm closing this ticket as it looks like it's heavily outdated, we can of course reopen it if needed 👍