The panels option causes the file .config/plasma-org.kde.plasma.desktop-appletsrc to grow indefinitely

The panels option creates new panels on every login (and removes the old ones beforehand).
All the widgets inside the new panels will then be registered in plasma-org.kde.plasma.desktop-appletsrc.
Unfortunately KDE Plasma doesn't cleanup the old entries, so the file will grow indefinitely.
I don't know if it would be safe to delete that file every time.
KDE Plasma seems to automatically regenerate the file, but maybe there are some side-effects on the containment / widget numbering.

I have noticed after a while it made the taskbar hang for a few seconds when plugging in a monitor, but apart from that it doesn't seem to cause any issues.
That said that's on a 7840U with a pretty decent SSD, and I see this being a problem on old/low power devices. We might want to add a warning about this on the readme

One problem that is caused by this issue, is how keyboard shortcuts for panel applets normally work on plasma.
When you configure a keybinding on one of your panel applets (e.g. plasma-pass), you will notice that the applet will be registered with a (random?) containment and applet number inside plasma-org.kde.plasma.desktop-appletsrc. Even though the actual keybinding is configured in this file, the keybinding also needs to be in kglobalshortcutsrc. The way this works is that inside kglobalshortcutsrc is that it refers to the applet number inside plasma-org.kde.plasma.desktop-appletsrc.
But if you now delete all you pannels, and regenerete new ones via plasma-manager's panels option on every login. These applet numbers are no longer vaild, because new ones were generated for the new panels.

Did a bit of testing and I think we can fix this!

It also shows up with the same ID in kglobalshortcutsrc

Might look into this but I need to finish the konsole module first

How would a possible fix look like? Add a script to panels.extraSettings which gets the new applet numbers and writes them into plasma-org.kde.plasma.desktop-appletsrc and kglobalshortcutsrc?
I'm still a bit concerned about the old entries. If you would want to remove the old entries from both files, you would need to know which widget ids are no longer valid.
Also I'm wondering what's the maximum number plasma does generate for these ids, and if it does search for a unused number, as soon as a certain limit is reached.
I think this wouldn't be something to worry about too much for a KDE dev, because how many panels will a user possibly create in his entire life? But again, with plasma-manager we are creating new panels on every login...

We could save the IDs when we generate the panels so that we can clean up old entries.
Btw that screenshot was talking about the keyboard shortcut thing you mentioned

I think this wouldn't be something to worry about too much for a KDE dev, because how many panels will a user possibly create in his entire life? But again, with plasma-manager we are creating new panels on every login...

Unless you have overrideConfig enabled we only run the panels script when there's a change, and if you have that enabled you're probs deleting both files anyways

Ah okay, thank you for clarification! I was under the impression the script will run on every startup.
I've just lazily checked the number of lines in plasma-org.kde.plasma.desktop-appletsrc after every startup and it was growing everytime. But maybe this is caused by another issue. I will test this again, as soon as I have time.

Hmm...
Are you deleting last_run_layouts in .local/share/plasma-manager?

I've now tested it.
The last_run_layouts is updated on every startup, so I guess the panel script runs on every startup in my case...

I've now looked a little bit deeper into the "script runs on every startup" issue.
The problem is, that .local/share/plasma-manager/data/layout.js always has the startup timestamp.
The file itself is a link to /nix/store/...-home-manager-files/.local/share/plasma-manager/data/layout.js which is another link to /nix/store/...-hm_plasmamanagerdatalayout.js.
So, I assume that the timestamp layout.js has, is the timestamp of when the link was created, which I think is on every login.
I'm using home-manager as a nixos module, so I can build the whole system config including the home-manager config with a single nixos-rebuild. Could this kind of setup lead to the issue?

The last_run_* files are present. But when the contents of last_run_layouts is compared with the timestamp of layout.js, it will always be older, because layout.js always has the current startup timestamp. I assume it is the time, when the link to the actual ...hm_plasmamanagerdatalayout.js was created, which seems to happen on every startup.

I cannot tell for sure, because the original file in the nix store has no timestamp (1. Jan 1970).

It doesn't compare the timestamp against layout.js, it compares it against the last run files
Here's the script that applies theme settings:
#!/bin/sh
last_update=$(stat -c %Y "$0")
last_update_file=/home/toast/.local/share/plasma-manager/last_run_themes
stored_last_update=0
if [ -f "$last_update_file" ]; then
    stored_last_update=$(cat "$last_update_file")
fi

if [ $last_update -gt $stored_last_update ]; then
    success=1
    plasma-apply-lookandfeel -a Catppuccin-Mocha-Mauve || success=0
    plasma-apply-desktoptheme default || success=0
    plasma-apply-cursortheme Breeze_Snow || success=0
    plasma-apply-colorscheme CatppuccinMochaMauve || success=0
    /nix/store/9lfr9sqjnifnc51i1w3n6yxhkrlgxs28-plasma-workspace-5.27.10/libexec/plasma-changeicons breeze-dark || success=0

    [ $success = 1 ] && echo "$last_update" > "$last_update_file"
fi

Looking at the code it does compare it to the timestamp of layout.js:
https://github.com/pjones/plasma-manager/blob/74fa336c22adf822c6ef13b21bfff18fbef66e9c/modules/panels.nix#L183

:raised_eyebrow:
Huh I guess I did miss that

@magnouvean any ideas on what could be happening here?

I have noticed this too. I think the problem may have to do with how symlinks work with nix, and that they may get symlinked again after reboot. I think I though they worked differently when I wrote this, and didn't consider time-changes between reboots. On my machine at least it runs every time I reboot, but not when I log out and re-log back in. What I think we could do is to instead of checking the timing of the file, to just check the sha256-sum or something, and compare that instead. As far as solving this I think we can just delete this file before generating the plasma-layout. I can't see anything wrong with that tbh as that is what I actually thought was happening, and the file is not needed when all the panels are deleted anyway.

B.t.w. @FF-AntiK a much cleaner and simpler way of doing what you have done above would be something like:
panels = {
        widgets = [
          {
            name = "org.kde.plasma.icontasks";
            config = {
              General.launchers = [
                "applications:org.kde.dolphin.desktop"
               "enter more applications you want here"
              ];
            };
          }
        ];
};

See how you can specify what is written with writeConfig directly for each of the widgets via the config-option. I do see that this is not well documented at all. We really should work some more on documentation once we have gotten some more functionality in place as it is lagging quite behind I see. What is causing the problem might not be that there is a duplicated kglobalshortcuts entry or something, but one problem could be that writeConfig in general writes to [Containments][SomeID][Applets][AnotherID][Configuration], meaning what I would expect the above to do is write to [Containments][SomeID][Applets][AnotherID][Configuration][Shortcuts], but I seem to remember you saying the config needing to be in [Containments][SomeID][Applets][AnotherID][Shortcuts]. If this is the source of the problem there hopefully is a way in plasma-scripts to write also to such groups and that we can implement this as an option as well.

Deleting plasma-org.kde.plasma.desktop-appletsrc would also revert any desktop and panel changes that were made outside of plasma-manager. If this is desirable or not is an open question, I guess.
But also deleting the file wouldn't solve the problem of incrementing widget ids.
As in my plasma-pass example, this will invalidate previously configured keyboard shortcuts.
And who knows where else Plasma references panel widget ids.
@magnouvean thanks for the example. This is helpful for all the widgets directly in the panel. But it won't help for widgets inside the system-tray like plasma-pass. Also it won't help with the kglobalshortcutsrc problem, where we need to reference the correct widget id.
Regarding the sections in  plasma-org.kde.plasma.desktop-appletsrc fortunately it works with and also without the [Configuration] part :-)

Ah alright, that's a good sign I guess. I would think the panels-option would revert all the panels already though seeing as it will delete all the panels and re-generate them on each startup. I see you are probably correct though with deleting the file wont solve much as I use overrideConfig (which deletes the file on every generation) and my plasma-org.kde.plasma.desktop-appletsrc is still much longer than what it probably should be (2000 lines or something). I got no idea what is happening there though, maybe something weird on the kde plasma side.

Yeah, I think it is an odd decision of the KDE devs to not automatically clean up plasma-org.kde.plasma.desktop-appletsrc (also I wish the filename was shorter ^.^)
I cannot speak for your overrideConfig setup, but I already manually deleted the file and didn't see any old entries.
Deleting the file is like a "fresh start" for me. The only thing I see, is that plasma won't re-use any widget ids. It will always increment from the ids it used before, whether the file is deleted or not.

So far I'd vote for comparing checksums insted of timestamp, regarding the apply_layout script.
This would at least prevent incrementing the widget ids too often.
Regarding the incrementing widget ids, I could live with that.
In this case I would prefer plasma-manager deleting appletsrc file by default and mentioning in the docs that changes to the config outside of plasma-manager will not persist.
But I still would need a solution for my special case with keyboard shortcuts for widgets inside the systray.
Maybe I will be able to add something to my extraSettings script, to delete all old entries of my shortcut in kglobalshortcutsrc.
I still think it's a little bit odd that I have to define the shortcut both in appletsrc and also kglobalshortcutsrc.

@magnouvean I've just checked the overrideConfig option you mentioned.
plasma-org.kde.plasma.desktop-appletsrc is not in the default list of config files.
Did you specify it in overrideConfigFiles?

I appears you are correct, nice spot. For some reason I always thought it was there. It definitely should be there though. appletsrc should also be there as well thinking about it. I think that list was just gathered from the list of files tracked by rc2nix, but it is definitely due an update it looks like.

Since I enabled overrideConfig and added plasma-org.kde.plasma.desktop-appletsrc to overrideConfigFiles.
I don't even get incremented widget numbers. It looks very smooth now to be honest.
The kglobalshortcutsrc doesn't behave like I'd expected though.
I was hoping that deleting it would result in having no shortcuts at all (plus the ones configured in plasma-manager).
But it will always have the default shortcuts. I still have to test what happens now, if I use some of the default shortcuts for other tasks. Will it override the default shortcut or not? I'll check this later.

It seems like default shortcuts will be overwritten automatically when using some of the default key-sequences for other tasks.
So all my issues are fixed now! :-)
Do you want me to close the issue, or do you want to keep it open, until you've added some minor improvements (startup script compares checksum, plasma-org.kde.plasma.desktop-appletsrc added to the default config files, ...)?

Overrideconfig will essentially set all the settings not explicitly set in your nix config to the default ones, but the ones you set in your nix config should not be overridden. If you want to unset some of the settings (which is often needed when there are colliding keybindings for example) you may want to explicitly disable them in your config. In some cases adding "[$i]" at the end of your key can help settings not being overridden.

We can keep it open as it is still a problem when not using overrideConfig, and probably needs some minor tweaks

I've explicitly tested without "unsetting" colliding shortcuts. I don't know for sure, but I assume my config will apply first and the defaults will be added later, so they loose when there are colligind key-sequences.
I may be wrong though.

I think it is a bit unpredictable. In my experience it is needed in some cases (I need them for "Meta+1", "Meta+2", ... as far as I am aware), but other times it is fine. Nice that things have worked out!

As per #78 autostart scripts now use sha256sum instead of stat for checking for changes in panels/theme configurations. Also the plasma-org.kde.plasma.desktop-appletsrc should now be deleted before the panels are generated, which hopefully should somewhat solve the problem of the file growing indefinitely. Therefore I think I can close this issue now. One thing to note though is that I did find out that activations are not only ran at a new generation, but also at boot, which does mean that when using overrideConfig, all the files are deleted and regenerated on each boot. This also means that panels and themes will have to also be generated/applied on every boot as well. That might have been the reason why the stat command didn't work, I don't really know. I still think using a sha-sum is the better option though as it should compare the content of the file and not when the file was created.


"Dynamic Schema" by passing a Hash?

Hi all, thank you for these awesome gems.
I know the way to use dry-validation is passing a block to Schema() -- then a DSL instance will be initialized and the block will be exceuted on it.
What I want to do is validate the controller params based on the schemas defined in my OpenApi document. After parsing OpenApi document, I get a Hash like { name: 'age', required: true, type: 'integer' }, but ... It can't be converted into block.
So, would you consider supporting this usage?
Dry::Validation.Schema(
  required: {
    name: :filled,
     age: { type?: Integer, gteq?: 0 }
  },
  optional: { }
)

dry-validation is being rewritten on top of dry-schema, so this is no longer applicable here (Schema DSL implementation is gone in master, it now delegates to dry-schema). Furthermore, we use issues for bug tracking and confirmed feature requests. For discussions/questions please use https://discourse.dry-rb.org. See CONTRIBUTING.md for more info.


path collision

git clone is throwing path collision warning on windows 10

we can fix this in the following way. You can rename the file in a case-sensitive way and commit the change:
git mv --cached name.txt NAME.TXT
Please take care what you are renaming by checking the number of lines in both files or by manually checking.
if number of lines differ or you find differences in code then you have to check which files has the most recent updated code and keep that only. its most probably to kebab-cased scss files and PascalCase jsx files that have the most-recent code

ref https://www.hanselman.com/blog/git-is-casesensitive-and-your-filesystem-may-not-be-weird-folder-merging-on-windows


Stop running module_test_ios in devicelab

As of https://github.com/flutter/flutter/pull/147934 module_test_ios is passing on non-devicelab machines.  Remove the devicelab build and mark the arm non-devicelab build as not flaky.
Fixes https://github.com/flutter/flutter/issues/112033
@vashworth's summary from https://github.com/flutter/flutter/issues/112033#issuecomment-2108671235:

So I believe the idea was to move Mac_arm64_ios module_test_ios to Mac_arm64 module_test_ios so it doesn't run on a devicelab bot.
However, it fails when running on a chromium bot due to a Trying to load an unsigned library issue, even though it's using a simulator:
https://ci.chromium.org/ui/p/flutter/builders/luci.flutter.staging/Mac_arm64 module_test_ios
It's unclear why, but it seemed that removing the lines that force disabling of codesigning allowed it to run. @godofredoc was going to do a follow up PR to fix it, but it was probably forgotten.

Do we also want to remove Mac_x64 module_test_ios, do we need to running on both arch?

Do we also want to remove Mac_x64 module_test_ios, do we need to running on both arch?

Good idea.  That one is my fault, when I wrote go/flutter-mac-test-architectures I put anything testing the tool as needing to run on both archs, but we can be more conservative than that.

FYI:
In my experience, running on simulators doesn't require us to get the signing right, but running on device does.
Signing for native assets should also be covered in the native assets integration test, and it's unlikely that we'll do signing differently in the code path for native assets in add2app, so it's probably safe to remove coverage for signing in the add2app scenario.


Bug fix

When deleting tags belonged to the same repository concurrently, the repository may be deleted by one API call and the other calls get 404. This commit logs a warning message and doesn't return 404.

Coverage decreased (-0.06%) to 64.305% when pulling 347eb5cf8765e7c1a07b3e73110beb63ba3244a5 on ywk253100:180412_bugfix into 75e6b5d91ce11d90e42e3b8151d4c3210666b44f on vmware:master.


convos: init at 4.22

This PR add the web based IRC client convos, including nixos module and tests.
Several perlPackage dependencies are added, and some are updated.

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

Updating convos to 4.18

Thx for reviewing :+1:

@GrahamcOfBorg test convos

Waiting for a new release from upstream that contains some important fixes.

@stigtsp Can you add the test to passthru.tests? That way the test is automatically run for PRs and easy to refer to. See tests here: https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes

This PR includes updates to perlPackages.MojoliciousPluginOpenAPI, perlPackages.JSONValidator and perlPackages.Mojolicious which are also included in https://github.com/NixOS/nixpkgs/pull/91184 I suggest  merging this PR after the cpan2nix updates have been merged.

I suggest merging this PR after the cpan2nix updates have been merged.

Those mass updates are typically stuck for 2-3 weeks (no one wants to review them), so probably there is no point to wait.
Also that PR is against staging which merged to master every few weeks.

Those mass updates are typically stuck for 2-3 weeks (no one wants to review them), so probably there is no point to wait.
Also that PR is against staging which merged to master every few weeks.

Ok - updated Mojolicious in this PR to 8.55, so it should be ready iIhope :-) Does the perlPackages update look ok?
Result of nixpkgs-review pr 88940 1

42 packages built:
- abcde
- convos
- perl528Packages.IRCUtils
- perl528Packages.JSONValidator
- perl528Packages.LinkEmbedder
- perl528Packages.MojoIOLoopForkCall
- perl528Packages.MojoJWT
- perl528Packages.MojoPg
- perl528Packages.MojoRedis
- perl528Packages.MojoSQLite
- perl528Packages.Mojolicious
- perl528Packages.MojoliciousPluginMail
- perl528Packages.MojoliciousPluginOpenAPI
- perl528Packages.MojoliciousPluginStatus
- perl528Packages.MojoliciousPluginTextExceptions
- perl528Packages.MojoliciousPluginWebpack
- perl528Packages.Mojomysql
- perl528Packages.MusicBrainz
- perl528Packages.OpenAPIClient
- perl528Packages.ParseIRC
- perl528Packages.TimePiece
- perl528Packages.UnicodeUTF8
- perl530Packages.IRCUtils
- perl530Packages.JSONValidator
- perl530Packages.LinkEmbedder
- perl530Packages.MojoIOLoopForkCall
- perl530Packages.MojoJWT
- perl530Packages.MojoPg
- perl530Packages.MojoRedis
- perl530Packages.MojoSQLite
- perl530Packages.Mojolicious
- perl530Packages.MojoliciousPluginMail
- perl530Packages.MojoliciousPluginOpenAPI
- perl530Packages.MojoliciousPluginStatus
- perl530Packages.MojoliciousPluginTextExceptions
- perl530Packages.MojoliciousPluginWebpack
- perl530Packages.Mojomysql
- perl530Packages.MusicBrainz
- perl530Packages.OpenAPIClient
- perl530Packages.ParseIRC
- perl530Packages.TimePiece
- perl530Packages.UnicodeUTF8

Fixed eval in cd8e099ffeee27d229371f4e8cba1a8b155e2a48.


Deploy nr-gwells to new OpenShift project.

Describe the task
Deploy nr-gwells to the new OpenShift project. Update the OC_TOKEN and OC_NAMESPACE in the GitHub actions environment variables: https://github.com/bcgov/nr-gwells/settings/secrets/actions
Purpose
We want to be able to isolate our changes and deploy both apps in tandem.
Acceptance Criteria

[x] App deploys to dev in new OpenShift project.
[x] nr-gwells objects have been cleaned up in gwells project

Additional context

nr-gwells dev OpenShift project
https://github.com/bcgov/quickstart-openshift - Go To "Secrets and Variables"

We needed to update resourcing as nr-gwells is less heavily resourced than gwells. We should review the resourcing in a feature ticket to fine tune.
We needed to bring over the network policies that existed in gwells. Added those to the init deployment template.
Some crunchy db related secrets were added to gwells, but not programatically created so they were missing in nr-gwells. Added those to the init deployment template.


Shorts (and other errors) in switched_capacitor_filter

@Lastdayends @kkunal1408 With the latest fixes, there are still routing errors (shorts) in switched_capacitor_filter. Here is the first error:
This is just net66.

This is net66 and vinn:

There are many shorts (1208).  I will check it.

@kkunal1408 @stevenmburns
There is a bug in the verilog file.
The common centroid capacitor code needs to know the pair of pins.
Currently it is:
Cap_cc c8_c3 ( .MINUS0(voutn), .MINUS1(voutn), .PLUS0(vss), .PLUS1(net66) );
In this case, is .MINUS0(voutn) and .PLUS0(vss) a pair? Or .MINUS0(voutn) and .PLUS1(net66) a pair?
I would suggest:
Cap_cc c8_c3 ( .MINUS0(voutn), .PLUS0(vss), .MINUS1(voutn), .PLUS1(net66) );
So that it is clear that .MINUS0(voutn) and .PLUS0(vss) is a pair. And .MINUS1(voutn), .PLUS1(net66) a pair.

I think it is clear that MINUS0 and PLUS0 make up one pair, and MINUS1 and PLUS1 make up the other pair. We can use the formal pin names instead of relying on the ordering of the parameters.

@stevenmburns
Should we distinguish the pair based on pin NAME+number? If the name are paired and number is same, then make pins a pair?
Then 'MINUS' and 'PLUS' are probably hard-coded as key of name in the code.

Yes, that makes sense to me. Should this be fixed in the Verilog parser or in the cap_placer?

@stevenmburns
In the cap_placer, I can fix that.

@Lastdayends @kkunal1408 @arvuce22 We can probably enumerate the possible formal names you will get from the frontend.
Seems like we have "PLUS", "MINUS", "dummy_gnd_PLUS", "dummy_gnd_MINUS", "PLUS1", "MINUS1", "PLUS2", "MINUS2". Any others?

"PLUS0" and "MINUS0".

@stevenmburns

Seems the viewer do not get the right cap here.
The shown cap should be connected to vin. And the caps connected to net66 is missed.

I mean:

Is this in a PR so I can try it out?

@stevenmburns
Yes. Those caps are in PR.

Is the PR #453 ?
If it is there are still  1208 shorts. The first short is between vss and net66.

@stevenmburns
Yes. It is #453.

@stevenmburns
Ok. I will check.

The .json file generated by the cap_placer has six terminals: "MINUS0", "PLUS0", "MINUS1", "PLUS1", and "MINUS2", "PLUS2", but the verilog file has only four: "MINUS0", "PLUS0", and "MINUS1", "PLUS1". That could be the problem.
This is the Python version of the PnRDB lookup code which is probably only finding the four values:
    fa_map = {}
    for n in itertools.chain( hN.Nets, hN.PowerNets):
        for c in n.connected:
            if c.type == 'Block':
                cblk = hN.Blocks[c.iter2]
                blk = cblk.instance[cblk.selectedInstance]
                block_name = blk.name
                master_name = blk.master
                pin = blk.blockPins[c.iter]
                formal_name = f"{blk.name}/{pin.name}"
                assert formal_name not in fa_map
                fa_map[formal_name] = n.name

            else:
                term = hN.Terminals[c.iter]
                terminal_name = term.name
                assert terminal_name == n.name

Maybe you updated the code that generates the rectangles in cap_placer (and spits out .gds.json) and didn't update the code that generates "primitive"-style json.

Here are the netName fileds in a couple for representativein .json files:
(general) smburns@smburns-XPS-13-9370:~/DARPA/ALIGN-public$ egrep netName work/FinFET14nm_Mock_PDK/switched_capacitor_filter/3_pnr/Cap_cc_AspectRatio_2x3.json  | sort | uniq -c
     31             "netName": "MINUS0",
    429             "netName": "MINUS1",
    393             "netName": "MINUS2",
     31             "netName": "PLUS0",
    429             "netName": "PLUS1",
    393             "netName": "PLUS2",
(general) smburns@smburns-XPS-13-9370:~/DARPA/ALIGN-public$ egrep netName work/FinFET14nm_Mock_PDK/switched_capacitor_filter/3_pnr/Cap_cc_AspectRatio_2x4.json  | sort | uniq -c
    291             "netName": "dummy_gnd_MINUS",
    291             "netName": "dummy_gnd_PLUS",
     31             "netName": "MINUS0",
    429             "netName": "MINUS1",
    393             "netName": "MINUS2",
     31             "netName": "PLUS0",
    429             "netName": "PLUS1",
    393             "netName": "PLUS2",

@stevenmburns
This bug was fixed in #453.

Now there are 1 open and 5 minlength bug.

@stevenmburns
Now switched capacitor filter is drc clean.


Drawer lock mode

Please provide enough information so that others can review your pull request:
Explain the motivation for making this change. What existing problem does the pull request solve?
Prefer small pull requests. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise split it.
Test plan (required)
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure you test on both platforms if your change affects both platforms.
The code must pass tests and shouldn't add more Flow errors.
Code formatting
Look around. Match the style of the rest of the codebase.

Sorry, opened this up in the wrong fork.

@dabit1 this is actually just a duplicate of #793.  I forked the whole repository and merged that PR into my own fork because I really needed it and that PR doesn't seem like it's gonna get merged in anytime soon.


Test syntactic correctness after translation

Currently, https://github.com/biolab/orange-translations runs a github action that

runs trubar translate
checks syntactic correctness of entire project afterwards.

The second step wastes time (not all sources were changed) and, more importantly, could already be done by trubar after translation.
trubar should have an option (either in configuration, or command line (--nocheck), or both) to check sources after translation. To save time, check would only be run if target file was translated (not copied) and the translation differs from previous translation.
While implementing this, you can also improve the output by allowing different levels of verbosity. Report either

copying and translating (the current output)
only translating,
translating, but only if translation differs from previous.

Translated source is generated by calling ASTs tree.code_for_node, which is unlikely to be syntactically incorrect. The only possible source of problem would be incorrect auto-import config option, but this is very unlikely to go undetected for long.
Neither trubar nor orange-translation need to check the syntax of the output.
It would be, however, beneficial to reduce the output clutter.


Line breaks in update.sh broken

Hi, first of all: thanks a lot for the installer! It seems to me as if the line breaks in update.sh are broken, which is why the installer currently exits with a load of cumbersome error messages.

Hi, sorry for the late reply but I've been really busy.
Thank you for reporting the bug, and thanks to @claycooper for fixing it.


Ux

Fixes #
Describe the changes you have made in this pr -
Made changes as requested by Code Climate in #647

Coverage increased (+0.08%) to 82.582% when pulling 995384f15efdfbf4ac2f04952969b68441f77a1e on ShreyaPrasad1209:ux into f27f39451645e42111462fcea4cd5c24df26e815 on CircuitVerse:stories/new_ux.


⚠ DDoS-Relay US-W-sfo3-01 has degraded performance

In fa64c1d, DDoS-Relay US-W-sfo3-01 (http://<IP_ADDRESS>:42069/;csv) experienced degraded performance:

HTTP code: 200
Response time: 5 ms

Resolved: DDoS-Relay US-W-sfo3-01 performance has improved in 0d7eda7 after 1 hour, 3 minutes.


Add support for Ewy's Workshop

Hello,
can you please add support for Ewy's Workshop, what should be similar to Steves Workshop?
That would be great.
Thanks in advance
Michael (aka BakermanLP)

@EwyBoy was working on adding support, I don't know what happened next.

Hahha, I am sorry. I ran into some problems and kinda gave up without looking to much into it.

I can PR it for you if you'd like.

Yes please!


On editing filters for a watch, it should not return an empty change

https://github.com/dgtlmoon/changedetection.io/issues/2373 by storing multiple previous HTML versions, it can be easier to regenerate the diff on request


hiding and showing the navigation bar imperatively

does not seem to work because of https://github.com/facebook/react-native/issues/3752

closing in favor of #19


Hotkeys

Added functions and hotkeys for play/pause and stop/reset.  Some placeholders are used until further instructions.

Currently, I have cleaned up the code to using a enum timerStateEnum:
https://github.com/MajinBui/atom-pomodoro-app/blob/hotkeys/lib/index.coffee#L26-L29
I also added buttons to the view:
https://github.com/MajinBui/atom-pomodoro-app/blob/hotkeys/lib/pomodoro-app-view.coffee#L10-L27

I am now trying to add event listeners to the button but it seems as though I might have to move the timer functions into the view.

Never mind, I was able to add the event listeners in for the buttons.  Now, all that is left is the actual timer itself.  Preview:

https://github.com/MajinBui/atom-pomodoro-app/blob/hotkeys/lib/index.coffee#L38-L39

TImer is complete.

Yep, code related to debugging is now removed.


Import quickfix for "export const MyClass=class{}" broken

TypeScript Version:  2.8.1, VSCODE 1.22.1

Search Terms:
Code
// file1

export const MyClass = class {}

// file2

const variable:MyClass;

if I mouseover MyClass in file2 and do CTRL-. (dot), nothing happens
however if i change file1 into
export class MyClass {}
it works.
so the problem is that the import quick fix does not recognize MyClass as a type in the first case
i believe strongly  it worked in TS 2.7.1, hower does not in 2.8.1
Expected behavior:  VS suggests import on CTRL-. (dot)
Actual behavior: VS does not react on CTRL-. (dot)
Playground Link:  not possible, cannot import files there
Related Issues:

The following code is invalid:
const MyClass = class {};
declare const variable: MyClass;

Because when you use const MyClass = class {};, it has only value meaning and not type meaning. In order to use a class as a type it has to be declared using class MyClass {} and not const MyClass = class {}.

It's pretty hard to provide a type based on the result of a function -- the function won't evaluated until runtime, but we need types to be available at compile time. You could define an interface for what you expect it to return, and then have export const MyComponent: { new(): MyInterface } = ....

Hm, I don't understand. The type does exists. If a mouseover the const variable it shows me the type of the result.
The problem I and other users have is just that the import quick fix is broken in 2.8.1. I always have to import manually. And also not being able to use the class variable in a type position is just conceptually wrong and should be fixed, but I could care less about that right now :)

If a mouseover the const variable it shows me the type of the result.

That shows you that MyComponent has a type, not that it is a type. It's impossible in general to make every class that exists at runtime be a type, unless we ran the program at compile time.
This isn't an import quickfix bug, because it's intentionally avoiding importing something that will result in a compile error.

OK I understand now. Forget about variable type positions :)
But what about importing a react component in a react node position? Somehow the compiler can validate it when I use it at compile time perfectly, no problem. Then it should be able to quickfix import it too? Either way enabling the quickfix import here would really really be needed.
I am very sure it worked in 2.7.1. I will check that again though.

Can you find an example where the thing you want to import would not cause a compile error if imported?

Sure.
a.tsx
import * as React from 'react';
import { ComponentB } from './b';

class ComponentA extends React.PureComponent {
    render() {
        return <ComponentB ownProperty={42} />
    }
}

b.tsx
import { MapStateToProps, connect, MapDispatchToProps } from "react-redux";
import * as React from 'react';

interface DummyReduxState {
    readonly dummyStateData: string;
}

export interface OwnProps {
    readonly ownProperty: number;
}

interface StateProps {
    readonly stateProperty: string;
}

interface DispatchProps {
    dispatchFunction(): void;
}

interface AllProps extends OwnProps, StateProps, DispatchProps {
}

const mapStateToProps: MapStateToProps<StateProps, OwnProps, DummyReduxState> = (state) => {
    return {
        stateProperty: state.dummyStateData
    }
}

const mapDispatchToProps: MapDispatchToProps<DispatchProps, OwnProps> = (dispatch) => {
    return {
        dispatchFunction() {
            console.log(42);
        }
    };
}

export const ComponentB = connect(mapStateToProps, mapDispatchToProps)(class extends React.Component<AllProps>{

    render() {
        return
Working...

    }
})

That code has zero compile errors.
You can see that the inner class of ComponentB has many properties (=> AllProps interface). But that class is wrapped by react redux to form ComponentB.
ComponentB, as a result, has only 1 (!) possible prop, "ownProperty".
So when using ComponentB, it correct only allows that property "ownProperty" on the component (see file a.tsx).
The react-redux declaration file does an awesome job of subtracting the correct properties from the inner class to make that happen.
It's just that auto import doesn't work :(

Proof it worked on 2.7.1. I wasn't wrong :)

Another bug, related, but not the same (TS 2.8.1):
file a.tsx (Can quickfix first, but not second case)

file b.tsx

@neoncom I tested the example from 3 posts up and it works today with<EMAIL_ADDRESS>In that example you are using ComponentB in a value position, not a type position.


docs: fix typo

What's changed, or what was fixed?
Corrected a type
Fixes: #issue
Target Live Date: YYYY-MM-DD

[ ] This has been reviewed and approved by (NAME)
[x ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[x ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

Hey @krnsripati - would you please sign the CLA?

@petele I signed the CLA with my personal email id, but unfortunately, I committed changes from my office with my office email address.

:tada: This has been pushed live to https://developers.google.com/web/


WIP - Local fiddle examples

https://sencha.jira.com/browse/FIDDLE-508
These are some simple examples to show some examples that will get deployed to Sencha Fiddle on release of ExtReact.
Keeping as WIP for now until interested party likes the work and these examples will get moved into an attic area (to be kept as examples) and the desired examples can be created.

Closing due to reworking into a separate repo


Replace Monte-Carlo => Monte Carlo

The first spelling is the french one, and does not apply in english.

Merge or rebase + merge? 😄

I think we settled on 'rebase + merge' whenever we can =)


Introduce pipeline chaining

Which issue this PR addresses:
E2E runs every time when commit/PR is raised even when it would fail on basic checks.
What this PR does / why we need it:
E2E pipeline will start after successful run of CI checks
Signed-off-by: Petr Kotas<EMAIL_ADDRESS>Test plan for issue:
Manual
Is there any documentation that needs to be updated for this PR?
No

Hey @troy0820 it already is excluded. The CI pipelines is started without those changes once it finished successfully the E2E starts. It is not triggered otherwise.


feat: add production tailwind

:tada: This PR is included in version 0.46.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Develop

v3.0.44

Bug fix for moving Calendar.

Was not editing /var/packages/Calendar/etc/share_link.json. Issue #39
Was not moving @synocalendar if it existed. Issue #39

Pull v3.0.44 as final


GH-642, don't assign an empty string to password attribute

Fix the bug, when an empty string was assigned to the password attribute in the remote repo, if the attribute is ignored by the lifecycle management.

@alexhung, I've tried several approaches but looks like this particular case is not really testable in the state. At least not in SDKv2.


fix exports to include types as required by typescript

typescript will expect to read from the "types" in the "exports" field if that one is present.
This PR add it so typescript do not complain

@wighawag thanks for filing the fix pr 🎉, this has been published as v0.2.1


VMware boxes are no longer created/published

Commit 93e1ad90bc942c7bd2f85c7812e203b3b37d4715 stopped creating an publishing boxes for the VMware providers.  If the boxes won't be published, it seems like it makes sense to at least document the levels (bosh and warden) necessary to create a level that's compatible with the current boxes.

Fair enough we can add a readme mention for that.

@cppforlife, it's been a little bit; any thoughts around publishing bosh and warden levels used in boxes? Thanks.

Done. See builds in the pipeline: http://lite.bosh-ci.cf-app.com:8080/jobs/new-box


Add Saga project to examples

The Saga pattern sample project contains a rich example of a use case typical of developers considering actor frameworks.

 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.

Huh, weird it wasn't in the sln file. Thanks!

Seems there are some build errors though :(

@cpx86 Hi Christian, yes, just seen the build errors. Submitted the pull request on the way in to client on the train, so took a chance that the project had accidentally been left off the sln in a recent change. Obviously it's been left off for a while, at least long enough that because it's not in the sln it has effectively been left off CICD  and my commit correctly causes it to fail.
my change didn't break the build, the build was already broken.
I will take a stab at fixing the project, will be a fun way to get stuck in :)
I have not looked to see if there are any other projects not included, that was one I stumbled across because I was specifically looking for a saga-unit of work example.
(he says, rolling up sleeve)

@adamhathcock  Sorry, forgot to cc Adam. Adam this looks like your labour of love, can you please give these fixes a once over to make sure I'm not butchering your sample project? Looks like you've put a lot of effort into it.

Lastly: the build on appveyor is still failing after my last fixes, and I don't think that has anything to do with my pull request. The build is failing on this test, Proto.Tests.FutureTests.TestInATask

Error Message: Request didn't receive any Response within the expected time`

If someone can help stabilise that test so this pull request can go in, would be most appreciated.
protoactor-dotnet/tests/Proto.Actor.Tests/FutureTests.cs
Cheers, A

@adamhathcock  Just realised, this sample project has quite a bit of code in the readme and the code in the readme should also be checked. (damn, wish github supported a simple way to reference, or #include  code blocks from unit tests so that you can guarantee that readme code is always up to date without having to run some build step tool to replace tokens, those approaches are too messy, and takes a lot of fun out of working on the solution. imho.

I may have reorganized the examples and added some but I don't believe I had anything to do with the Saga one.  Doens't look familiar anyway.
I contributed the ASP.NET Core DI integration which might be relevant.

Saga one was mine @goblinfactory if it's the bank account example

@goblinfactory I think the failing test is a repro of the bug reported in #432, which isn't yet solved. So I think it should be fine to merge this PR even though that test is still not green.

Saga one was mine @goblinfactory if it's the bank account example, although I'm not very up-to-date with recent changes to Proto.Actor as I've been bogged down with other things for too long :(
Best way to check if it all still works is run it and see what sort of output you get 👍
busy with that now :)

I'll try and take a look at this sometime over the weekend

I checked out your branch and after updating all the pid.Tell methods to use the new Context.Send approach and removing the exception-throwing persistence implementation it looks like the saga example is working

hi all, just seen @tomliversidge 's comment, need to get my head back into this branch as I stopped looking at protoactor when this failed, so still don't have any domain knowledge. will look a bit later. I think it sounds like we're good or very close to being able to merge this depsite the CI build error if that's still there? Possibly might make sense to park this until that issue is resolved? i..e. that's what I'd do if this was a standup at live client project, and we'd all pile in (all systems stop) to remove the bottleneck? What do you think?

This is now ready for merging,
if someone can please merge this in that will be most appreciated.
....I will create a separate integration test for this so that we can confirm the behavior remains consistent and that this can be used as living documentation.
txs,
Alan

thanks @goblinfactory - I'll try and check this out tonight and make sure it all runs ok

@goblinfactory i'm seeing weird results after checking out the latest code:

Running 100 transfers with a 99.99% uptime i would have expected better results than this. I also don't seem to be able to get anything other than success or unknown results back.
There's some possible explanations:

There's still quite a few warnings about obsolete uses of the old .Tell API methods - maybe fixing these will help
Changing to RootContext somehow breaks things?
Some of the refactorings have broken something?

@goblinfactory Sounds awesome and your enthusiasm is appreciated! I agree it is quite complex... I think in a real life scenario, using something like Polly to do retries would simplify things, but I wanted to learn / demonstrate the supervision capabilities of the actor model.
I'll merge this in now anyway, thanks for the contribution!


make LogSearchShipper process shut down when it failed to create the nxlog service

This is currently happening quite a lot in production
{"@timestamp":"2015-12-03T09:12:02.663Z","Message":"Updating config and restarting shipping...","logger":"LogSearchShipper.Core.LogSearchShipperProcessManager","level":"INFO"}

...
...
...

{"@timestamp":"2015-12-03T09:12:21.361Z","ClassName":"System.ApplicationException","Message":"Failed to delete service nxlog_43FBF158C95F915A96BE1CA6DDB2222C","Data":null,"InnerException":{"NativeErrorCode":1072,"ClassName":"System.ComponentModel.Win32Exception","Message":"The specified service has been marked for deletion","Data":null,"InnerException":null,"HelpURL":null,"StackTraceString":null,"RemoteStackTraceString":null,"RemoteStackIndex":0,"ExceptionMethod":null,"HResult":-2147467259,"Source":null,"WatsonBuckets":null},"HelpURL":null,"StackTraceString":"   at LogSearchShipper.Core.NxLog.ServiceControllerEx.DeleteService(String name)\r\n   at LogSearchShipper.Core.NxLog.ServiceControllerEx.CreateService(String name, String filePath, String userName, String password)\r\n   at LogSearchShipper.Core.NxLog.NxLogProcessManager.StartNxLogProcess()\r\n   at LogSearchShipper.Core.NxLog.NxLogProcessManager.Start()\r\n   at LogSearchShipper.Core.LogSearchShipperProcessManager.OnEdbConfigChange()\r\n   at LogSearchShipper.Core.ConfigWatcher.OnChanged(Action actionsToRun, FileSystemEventArgs e)","RemoteStackTraceString":null,"RemoteStackIndex":0,"ExceptionMethod":"8\nDeleteService\nLogSearchShipper.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null\nLogSearchShipper.Core.NxLog.ServiceControllerEx\nVoid DeleteService(System.String)","HResult":-2146232832,"Source":"LogSearchShipper.Core","WatsonBuckets":null,"logger":"LogSearchShipper.Core.LogSearchShipperProcessManager","level":"ERROR"}

@ewilde, it looks like this message is coming from an old version of LSS - prior to our previous attempt to fix this problem. We might just update it to the current version.

Okay lets do that


Highlight entity tags the same in all places

Entity tags (via /tag) appear in three different places:

/tag command
Tags: [] NBT
tag= selector argument

Being able to highlight tags consistently in all of these places would be useful to quickly locate them.
This would be relatively easy to implement, however would require several hard-coded exceptions.

This will be supported naturally in the future by the version-specific grammars.

This has already been implemented in the form of an "entity tag" parser in the version-specific grammar. Not all of the commands that use it have been implemented, however, it is already supported.


Computation fixes in LAEA projection

Based on #9, but without the renamings.

Codecov Report
Base: 43.54% // Head: 43.64% // Increases project coverage by +0.10% :tada:

Coverage data is based on head (584e625) compared to base (f7a0f9b).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   43.54%   43.64%   +0.10%
==========================================
  Files         584      584
  Lines       48094    48078      -16
==========================================
+ Hits        20941    20985      +44
+ Misses      27153    27093      -60

Impacted Files
Coverage Δ

...Projections/LambertAzimuthalEqualAreaProjection.cs
51.06% <100.00%> (+51.06%)
:arrow_up:

AEGIS.Core/Indices/RTrees/RTree.cs
98.72% <0.00%> (-1.28%)
:arrow_down:

AEGIS.Core.Reference/Angles.cs
28.57% <0.00%> (+14.28%)
:arrow_up:

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

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


fix for issue#19, added false to uv.new_pipe() everywhere

This solves issue #19.
I blanket added false to all uv.new_pipe() statements everywhere, tested with 3 different neovim versions, my distro's 0.5, official 0.5 and 0.6-nightly, all seem to accept the change.
This is the same issue previously solved in PR #15.

Thanks for the PR, gosh, neovim 0.5's behavior is direct contrast to luv's docs, and it trips me up.


Add syntax highlighting

Colors! Because who doesn't like them?!
Just opening this PR to see if there's demand.
It's a really slow/lazy way to implement syntax highlighting but it works. I can improve the implementation if there's a need.
Summary
JSON syntax highlighting:

The color turns off if the application is not outputting to a TTY:

Preflight checklist

[X] Code formatted with rustfmt
[ ] Relevant tests added
[ ] Any new documentation added

Hey @ambiso, thanks for this, and thanks for your patience! I think this looks ok to me, although I wonder if there should be a flag to turn this off. I think it's probably ok to not have one for now unless folks start raising issues about it, but I'd like to get your thoughts.
Finally, looks like there's some cargo conflicts. If you have time, could you merge/rebase?

I rewrote the changes for the latest version; I tried adding a --color=always | never | auto flag, but couldn't find a neat way to do it with clap - it has support for a ColorChoice but it doesn't look like it's easy to support this ColorChoice as a command line flag. https://docs.rs/clap/latest/clap/builder/struct.Command.html#method.color

Thanks @ambiso! In researching a solution for #197, I realized that bunt via termcolor has support for this that we could emulate (or maybe bat supports NO_COLOR?)


Is there any plans to release the training code?

I want adjust the sd2.1 plugin to sdxl

Same concern here. I'm considering to adapt plugins of SDXL to Playground2.5.

Same concern here. I'm considering to adapt plugins of SDXL to Playground2.5.

Hi I tried it before but I'm faced with some problems. If you are interested maybe we can discuss further on wechat? My wechat number is rlm547487328.

Same concern here. I'm considering to adapt plugins of SDXL to Playground2.5.

Hi I tried it before but I'm faced with some problems. If you are interested maybe we can discuss further on wechat? My wechat number is rlm547487328.

Can you tell me what training data set you are using?

Same concern here. I'm considering to adapt plugins of SDXL to Playground2.5.

Hi I tried it before but I'm faced with some problems. If you are interested maybe we can discuss further on wechat? My wechat number is rlm547487328.

Can you tell me what training data set you are using?

A subset of Laion

Same concern here. I'm considering to adapt plugins of SDXL to Playground2.5.

Hi I tried it before but I'm faced with some problems. If you are interested maybe we can discuss further on wechat? My wechat number is rlm547487328.

Can you tell me what training data set you are using?

A subset of Laion

Can you give me a download link? Thank you.


Angular with custom webpack settings hangs on build when using .scss

Environment
Angular 14.2, but issue exists in Angular 16 as well
@angular-builders/custom-webpack 14.1.0
@sentry/webpack-plugin 2.4.0
Steps to Reproduce
Repro provided by user

npm install
npm run build

Expected Result
webpack plugin terminates itself after upload
Actual Result
terminal hangs forever unless force closed -

Changing all instances of scss to css and then running the build solves the issue.
1 . change filename app.component.scss to app.component.css
2. change filename styles.scss to styles.css
3. In app.component.ts, change styleUrls: ['./app.component.scss'] to  styleUrls: ['./app.component.css']
4. In angular.json, change "styles": ["src/styles.scss"], to "styles": ["src/styles.css"],

+1 . We have the same pb. Any Idea ?

The recommended workaround for now is to use Sentry CLI instead of the webpack plugin.

@lforst is there a way to use thirdPartyErrorFilterIntegration with Sentry CLI instead of webpack?

@jobejas No there is not but you can use the allowUrls option in Sentry.init() which achieves similar effects.

Closing this issue for clean-up. Please re-open if it still applies. Thanks!


Add noise to scenarios

To do:

[x] Add forecasts to environment state and observation space
[x] Add noise to model (carbon price and capex, opex, devex costs of offshore wind, blue and green hydrogen, CCUS)
[x] Elaborate IEV to include annual carbon emissions
[x] Agree economic approach to accounting for emissions (see #6 )
[x] Agree other factors to be randomised (eg. cost reduction curves)

Currently the problem is deterministic. Adding random noise to the scenarios would both reflect real-world uncertainty and increase the challenge difficulty.
From discussion during Workshop 2, the most volatile input may be the price of carbon. If the IEV models the annual carbon output then the environment can convert this to a noisy carbon cost at each step. Also, it then becomes natural to include expert predictions for the carbon price in the environment state and observation space.
Adding noise to the construction and/or procurement process was also discussed.

Pathways to Net Zero file has been expanded to model carbon bills for each scenario. Under the CCUS tab, there is a forecast carbon price set at £85/tonne (real), equivalent to EUR100.
For each scenario, I've calculated a total carbon price - which is effectively assuming the price is paid for generating emissions, and not dependent on what happens to the carbon. I've also calculated the carbon price for emissions. CCUS capacity is modelled to increase to be able to capture 100% of emissions in 2050, but from a slow start, so we model varying amounts of carbon emitted to the atmosphere. This trends to 0 as CCUS capacity ramps up.

The noise can be "coloured": if there any composite leading indicators for jobs or sectors, we can incorporate their dynamics.

Agreed that it makes sense to randomise future cost reduction curves

Here's an example result from training on the randomised environment
https://github.com/rangl-labs/netzerotc/blob/direct_action_on_deployment/environment/MODEL_8_10models_100episodes_DirectDeploymentRandomized.png

@jia-chenhua, the approach to adding noise looks good. Closing! :tada:


New client for touch

I have mentioned a number of times in other issues and in the hangout that I want to improve our experience on mobile devices. I would like to propose writing a second, touch-oriented client. We already have multiple servers speaking the same API, so we should be able to also write separate clients.
I would like to gather desiderata and technical suggestions before beginning, but obviously we will consider this just an experiment until we have something compelling to actually show.
Goals

Create a consistent and extensible set of UI patterns that are optimized for touch surfaces like phones and tablets. These devices do not have hover states, need larger click targets, and cannot distinguish between dragging and scrolling. Different types of servers, stories, and plugins need to be able to hook into these patterns to expose extra information or actions, that will then be presented appropriately to different types of devices.

Rewrite the client code in terms of a server-facing model layer and a user-facing interface layer. The model layer should be bootable in a scripting environment like node.js to make it easy to import data to the server or write bots that automatically change or edit data. The user-facing layer should work well across typesof devices, and allow the model layer to not worry about the type of device the site is being displayed on.

Implementation

Use a front-end MVC library like Backbone or Spine rather than storing so much information in the dom.
Use localStorage and the html5 apps apis to make the wiki work offline, have a home screen icon, etc. to fit better in the mobile environment.
Coffeescript, of course.
Need to think about load-time performance as the amount of front-end code increases. That means either asynchronously loading modules or else combining and minifying all the code together.

Roadmap
I am suggesting the following roadmap for integrating this client as first an experiment, eventually an alternative, and eventually perhaps the default client for SFW:

Create a basic implementation in a touch-client folder in the main project.
Alter the ruby implementation of the server to serve the touch client javascript when accessed with urls that use "touch" instead of "view."
Implement basic page and plugin rendering with the new client so we can play around with it.
Add conventions for editing that work across multiple device types one by one

Design
I am brainstorming a design that will use the same conventions, but with appropriate differences, for different device types. Right now my thoughts center on using little "handles," such as Appleuses in the iPhone/iPad versions of Numbers.
Each page and each plugin within it would have a little handle, that could be activated to expose edit actions on it.
I would love to hear everyone's thoughts and comments.

I went ahead and started exploring this direction, pushing it to a branch here: https://github.com/asolove/Smallest-Federated-Wiki/tree/touch-client/touch-client
This commit does nothing more than render the titles of the requested stories, but this is done dynamically and with what I hope will be meaningful objects.
There is pretty good Backbone documentation online for those who want to follow along: http://documentcloud.github.com/backbone/#

I'm excited to have serious attention focused on the touch platform. I've been afraid to get started with touch for fear of getting it wrong. We'll need effort and daring to get it right. Here's why it's worth it:
Tablets make for comfortable study. Soon readers will refactor everything they read, as they read it. This will be the "killer application" of federated wiki. This mimics the professor who teaches a new classes to learn new material with their own notes become lecture notes and then the first draft of their next book. Careful reading becomes publishing.
I've encouraged Adam to modularize the client code in the process. Sam and I had a go at integrating backbone.js a while back. It didn't work. Our conclusion: we need to build out from new models and think through the proper placement of every line of code as we go.
This is the challenge ahead. One client, with clean models, serving all html5 platforms, enabling a new kind of community engaged in a new kind of scholarship.

One option for rebuilding the frontend is http://brunch.io/
It's a integrated toolset for building rich HTML5 frontends. I've been using it for 4-5 months now and really like it. It makes it really easy to cleanly organize your code and includes integrated js testing via Mocha and minifying of js/css.

Kyle, that's interesting, Brunch is almost exactly the stack of libraries I am used to, and it solves the problem of how to build the assets independently of which server people are using. Do you have a sense of how stable Brunch is or how much trouble we would be in if Brunch stopped active development but we wanted to move forward with the same library stack?

I've used it for ~5 months with zero problems. So stability is fine. There's 14 contributors / 54 forks / 637 watchers at the moment so that's a pretty decent wide base.
I haven't made the jump to making changes to the Brunch code itself as it's met my needs perfectly so far but my understanding is the core Brunch code is fairly slender + it's written in coffeescript so it'd be pretty easy for this community to modify. That and the 1.0 release has moved to a plugin architecture so it'd be easy to add custom build steps for SFW.

Sounds good: structured tests and builds would be very helpful. I'm going to try setting this up on my remote branch for those who are interested in watching or contributing to the touch client.

I spent some time on this yesterday and got to the point of being able to display and browse a local wiki similarly to the existing client: https://github.com/asolove/Smallest-Federated-Wiki I would appreciate if those interested would go look at the structure of the code there and see if the objects make coherent sense.
The net step, it seems to me, will be to rewrite the way editing works. Because the current plugin implementations are not ideal for touch-based clients, I would like to suggest that we rewrite them but I'm not sure how much opposition there is to that idea. Specifically, instead of allowing plugins to arbitrarily bind events, I'd like to expose a handful of hooks they can use (to specify different allowed user actions) and that way we can have a single implementation for how those actions are displayed in the UI. That way we can change the UI in one place and have all plugins change to match.
For example, the chart plugin might specify that it has options like: pick dataset, select chart type, add caption. When you enter edit mode on a chart, those options would be displayed in a contextual menu and lead to the right action. The central codebase would also expose reusable components for modal dialogs, contextual menus, text editors, etc. that the plugins could use.

The emit/bind plugin interface has out lived its usefulness. I'll open another issue where we can discuss improvements. Hopefully if we work that forward together then we won't have a difficult merge between mouse and touch versions.

I've looked at a lot of the client code in the last 24 hours. I'm pretty familiar with the control and data flows once again. I'm thinking I should record my understanding in some sort of document that might suggest model objects and model lifetimes. I found creating new pages client-side particularly difficult.
One challenge is getting capitalization and punctuation from a link text to the title field of a new page on the disk. (We don't do this yet. We use the down-cased slug as the title.) For example, say I have a link that looks like this in source:
[[Tim O'Reilly]]

Clicking on this link should make a page in the database under the key:
tim-o-reilly

That has a title field that looks like:
"title": "Tim O'Reilly"

If you think of new page creation as having six phases, it use to be I needed it in phase 6 but lost it in phase 1. I now have a path from phase 2 to phase 6 so I only have one more phase wall to hurdle.

Yeah, the title was the main thing I was after when I tried to tackle this.  I was looking at getting the inner html of the  tag that called the event that led to the 404... but i'm not sure if that was going to be a fruitful approach or not.

Thinking about the client side vs. SEO... When I go to http://twitter.com/jhulten (which can be reached statically) I get the static content and I am redirected to http://twitter.com/#!/jhulten which I presume uses something like backbone.js to route the application.
This allows the page to be indexed without all the javascript.  What if we did something similar. http://wiki/page (no trailing .html) would return the static page with just enough javascript to redirect to http://wiki/#page
The bonus in regards to this issue is the ability to pick a client based on the browser while still having indexable content.

Arrgh, renewed discussion here reminds me that I need to implement server side rendering on the express server.
We are already using pushState for all of our history interaction, but I agree that there is no reason to change that.  I think the better fail over for federated wiki for browsers that don't support pushState is to just ignore the url, but otherwise function normally.
I had imagined that eventually if you went to a /view/something/view/something-else url that you would get a full page with prerendered html, and all the links in the page would be to /view/slug instead of /slug.html, meaning that if you manually open links in new tabs, or browse without javascript enabled, etc, everything would just work as expected.  But if javascript was enabled it would hook itself up to the page when loaded.


Relax case restriction

When compiling rdf4h, it was observed that
data family RDF a

class Rdf a

are currently not allowed by Eta. This is to avoid clashes in the generated code. But data families and type classes cannot possibly clash because of how the code generation works. The restriction mainly applies for data constructors and top-level bindings.

@rahulmutt is there an ETA on this fix becoming available? I do not see a more recent release than 0.8.6b2.

Sorry about that - completely slipped my mind with the holiday season. I'll do a release by January 10th. Feel free to bump this if I forget by then.

OK, thanks for the update. The sooner the better! There is a team here at Uber who literally wants this yesterday.

0.8.6b3 is released with the fix - the windows binary is still being built and it will be done in a couple hours. OS X and Linux are on the way. Let me know if you face any issues, thanks!


Batch prover service

We need need a way to spawn compute-heavy proving jobs to fast machines. See #259 .

Closing as this is superseded by https://github.com/worldcoin/semaphore-mtb/issues/5


Log.emiter does not work with a Union type

Hi,
With this code
require "log"

a = 2
if a % 2 == 0
  a = 0_u8
end

pp typeof(a)  # => (Int32 | UInt8)
Log.info &.emit("test", a: a)

I got the following error:
Showing last frame. Use --error-trace for full trace.

In /usr/share/crystal/src/log/metadata.cr:217:42

 217 | value.is_a?(Value) ? value : Value.new(value)
                                          ^--
Error: no overload matches 'Log::Metadata::Value.new' with type (Int32 | UInt8)

Overloads are:
 - Log::Metadata::Value.new(raw : Type)
 - Log::Metadata::Value.new(hash : NamedTuple | Hash)
 - Log::Metadata::Value.new(ary : Array)
Couldn't find overloads for these types:
 - Log::Metadata::Value.new(UInt8)

I see by diging in the doc that it exists Log::Metadata::Value::Type that define all supported types but:

this is never stated in the emit doc
I expect it to work with any type, by defaulting to print the same output as p!

The supported types are the ones listed in https://crystal-lang.org/api/1.0.0/Log/Metadata/Value/Type.html . The actionable here is to improve the docs of emit. It is not expected for the Log::Metadata to handle arbitrary types.

Well, neither Union nor UInt8 feels like arbitrary types to me :p. Maybe we should add for all primitive type (U)Int?

It is very arbitrary. For logging purposes, there's not much reason to preserve specific integer types. Just convert it to Int32.


Fantom5 interval data should be using R2 rather than FDR score

Done and copied to gs://genetics-portal-data


Runner update

Updates this runner to

wollok 1.3 beta
mumukit 1.1
escualo 2

Fixes #1

@npasserini @umanskyariel this updates Wollok support.
Are there significative changes from 1.3-beta to 1.3? Should we update to 1.3 or 1.4?

It's ok for me, merge at will.

1.4
On Mar 5, 2016 2:21 AM, "Franco Leonardo Bulgarelli" <
<EMAIL_ADDRESS>wrote:

@npasserini https://github.com/npasserini @umanskyariel this updates
Wollok support.
Are there significative changes from 1.3-beta to 1.3? Should we update to
1.3 or 1.4?
—
Reply to this email directly or view it on GitHub
https://github.com/mumuki/mumuki-wollok-server/pull/4#issuecomment-192579467
.

@npasserini OK, but it there a 1.4 SDK already ready to deploy?
I am not finding 1.3 stable nor 1.4-SNAPSHOT here: http://download.uqbar.org/wollok/sdk/

Javi?
On Mon, Mar 7, 2016 at 5:20 PM, Franco Leonardo Bulgarelli <
<EMAIL_ADDRESS>wrote:

@npasserini https://github.com/npasserini OK, but it there a 1.4 SDK
already ready to deploy?
I am not finding 1.3 stable nor 1.4-SNAPSHOT here:
http://download.uqbar.org/wollok/sdk/
—
Reply to this email directly or view it on GitHub
https://github.com/mumuki/mumuki-wollok-server/pull/4#issuecomment-193432811
.

This should be the link
http://download.uqbar.org/wollok/sdk/dev/org.uqbar.project.wollok.launch-1.3.0-SNAPSHOT-wdk.zip
Even if the name says 1.3.0 it is actually the build from "dev" done last
week after merging 1.4 branch.
So, it is the upcoming 1.4
On Mon, Mar 7, 2016 at 6:14 PM, Nicolas Passerini<EMAIL_ADDRESS>wrote:

Javi?
On Mon, Mar 7, 2016 at 5:20 PM, Franco Leonardo Bulgarelli <
<EMAIL_ADDRESS>wrote:

@npasserini https://github.com/npasserini OK, but it there a 1.4 SDK
already ready to deploy?
I am not finding 1.3 stable nor 1.4-SNAPSHOT here:
http://download.uqbar.org/wollok/sdk/
—
Reply to this email directly or view it on GitHub
https://github.com/mumuki/mumuki-wollok-server/pull/4#issuecomment-193432811
.

Excellent! Thanks


Add tagpack URI field

for https://github.com/graphsense/graphsense-dashboard/issues/279

see https://github.com/graphsense/graphsense-tagpack-tool/issues/23


Typo fix

This change looks good,
if not merged here you can consider to PR to:
https://github.com/abandonware/noble
Then maintainers can merge it:
https://github.com/abandonware/noble/pull/10

Released in:
<EMAIL_ADDRESS>

Please also check with:
<EMAIL_ADDRESS>Relate-to: https://github.com/noble/noble/pull/926


Create ticket that inventorises a tutorial to teach setting up Stride source

Issue here https://github.com/stride3d/stride/discussions/1211


Fix NPE and don't specify until-build

The current plugin is marked to be not compatible with IntelliJ 2023.2, because we specify an until-build. But we don't have to. According to https://plugins.jetbrains.com/docs/intellij/build-number-ranges.html: Not specifying until-build means it will include all future builds (including unreleased IDE versions, which might impact compatibility later).

@jmartisk : maybe you can take a look on this?

@t1 sorry I had a vacation. This makes sense to me. Could you just get rid of some old garbage commits that seem to have made their way into the PR? There should be just one commit.

Maybe you can simply do a squash merge?


wrap guide / ruler is null red

The ruler created with the wrap_guides config option appears to be unrecognized.

thanks for reporting this. I will push a fix 👍


Release/pipeline

Updated Jenkinsfile and docker-compose.yaml to release pipeline 5.5.0

Can one of the admins verify this patch?


What should i do?

I am getting the 418 error how should i fix that?

Hi, apparently this is an IP-Ban from the beatmapset download service provider due to too many download requests. Sorry I couldn't help much at this moment, try to avoid using the download function for now, and wait for the next update. (you can use Collection Manager for temporary replacement of download function)
more information: https://github.com/roogue/osu-collector-dl/issues/18

ok thank you!
2024-07-10, tr, 12:59 weiisennnz @.***> rašė:

Hi, apparently this is an IP-Ban from the beatmapset download service
provider due to too many download requests. Sorry I couldn't help much at
this moment, try to avoid using the download function for now, and wait for
the next update. (you can use Collection Manager
https://github.com/Piotrekol/CollectionManager for temporary
replacement of download function)
more information: #18
https://github.com/roogue/osu-collector-dl/issues/18
—
Reply to this email directly, view it on GitHub
https://github.com/roogue/osu-collector-dl/issues/19#issuecomment-2220069107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJYW7GR64DBCQI6QUIMNNO3ZLUAXXAVCNFSM6AAAAABKURDPYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRQGA3DSMJQG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Fixed in v2.7.5


On Debian and Ubuntu libxslt-dev is a virtual package

Puppet handling of virtual packages is not optimal: on each run we get:
Notice: /Stage[main]/Newrelic_plugins::Aws_cloudwatch/Package[libxslt-dev]/ensure: ensure changed 'purged' to 'present'
because libxslt-dev is not found as installed, and when we install it, being a virtual package, it installs libxslt1-dev
So better to use directly libxslt1-dev for idempotency.
References:
https://packages.debian.org/sid/libxslt-dev
http://packages.ubuntu.com/precise/libxslt-dev

:+1:

:+1:

 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.

 All committers have signed the CLA.


find element not working for iOS platform while using<EMAIL_ADDRESS>plugin

command 'findElement' was not handled by the following behaviours or plugins, even though they were registered to handle it: ["default"]. The command was handled by these: ["element-wait"].
[debug] [XCUITestDriver@1963 (f9b46943)] Encountered internal error running command: TypeError: Cannot read properties of undefined (reading 'jwproxy')
Appium v - 2.0.0-beta.65<EMAIL_ADDRESS><EMAIL_ADDRESS>

@sushilpawar12 Thanks for reporting. Will look into this.

@sushilpawar12 Please try with latest version


Fix Jekyll search console errors

In all pages except for docs we get
ReferenceError: se is not defined jekyll-search.js:1:1
Error: SimpleJekyllSearch --- You must specify a searchInput

So maybe we should just include the JS where it's used only.
The first error is in the library itself.
/CC @mdo

X-Ref: #17200


Restore autohide="on" functionality

With the fix for #34, JWM made it necessary to specify the position of the tray for auto-hiding.  Unfortunately, this seems to cause some confusion and also makes re-positioning the tray somewhat more difficult than it should be.  To address this, JWM should support on such that JWM would use the old algorithm for deciding where to hide the tray.

@joewing will it support ALL the current attributes as well.
I.E.
<Tray autohide="on"></Tray>
<Tray autohide="left"></Tray>
<Tray autohide="right"></Tray>
<Tray autohide="top"></Tray>
<Tray autohide="bottom"></Tray>
<Tray autohide="off"></Tray>

That's the plan: make it possible to override what JWM would decide by setting it explicitly or have JWM pick something based on where the tray is positioned (via on).

@joewing great!  I think that makes it easier for end users, but also supports the 'power user' to be able to fine tune their system to their exact specifications!


GNU Make Downlod is Broken

scoop install make fails on all my Windows machines. I cannot tell what the issue is, sorry.
scoop install make
Installing 'make' (4.2) [64bit]
The remote server returned an error: 227 Entering Passive Mode (108,36,217,27,91,67)
.
URL ftp://ftp.equation.com/make/64/make.exe is not valid

The URL ftp://ftp.equation.com/make/64/ is valid and reachable.
Scoop thinks that it was installed and one has to issue scoop uninstall make to get rid of the wrong state.

It asks for a username/password when I try it in Firefox. Using<EMAIL_ADDRESS>as credentials works but it says there are more than 200 users logged in. 🤷♂

Interesting, it wasn't asking me when I created the issue today but now it does.

I would suggest using only popular or reliable file servers like github, sourcefourge (well, better not). In case when it is absolutely impossible to find good source I would just make a release on github and upload files there.

According equation.com, one can see that that guy has his own nameservers on ftp.equation.com and www.equation.com //_-. Most possibly, these servers are used virtually for everything (jserver, apache, nfs, mail, etc) and I don't think they are sustainable.
By the way, can we describe mirrors in manifests?

I fully agree it's a very bad user experience this way. We have to update the manifests manually anyways, why not simply add the binaries to this repo as well.

Just received one more error right on AppVeyor:
49 Installing 'make' (4.2) [64bit]
50 The remote server returned an error: (530) Not logged in.
51 URL ftp://ftp.equation.com/make/64/make.exe is not valid

It's bad from developer perspective too because that will cause builds to fail.

As a workaround I have a solution for 64-bit systems: https://github.com/excitoon/scoop-user/blob/master/make.json .

While I appreciate statically complied tools, we could switch to http://repo.msys2.org/msys/x86_64/make-4.2.1-1-x86_64.pkg.tar.xz for a few reasons:

Download more trustworthy
Executable more trustworthy
Better chance of working with other msys tools
Pedictable updates
I promised @r15ch13 I wouldn’t repackage more msys apps, but perphaps he’ll make an exception for broken apps.

@rasa moving to a more reliable download is more important. 👍

@r15ch13: @excitoon's has many great packages in https://github.com/excitoon/scoop-user/ that may want to live in the main bucket to provide the freshest apps, and more reliable downloads.

Tried the make from https://github.com/excitoon/scoop-user/ but it fails in git bash for me with the fatal error "cygheap base mismatch detected".

@Fleshgrinder: well that’s bad news. I guess we’ll have to make sure to stay in sync with git-bash’s msys2 version.

Tried the http://repo.msys2.org/msys/x86_64/make-4.2.1-1-x86_64.pkg.tar.xz version and this one works out of the box. Maybe we can switch to this one?

@Fleshgrinder weird, that’s the same as excitoon’s: https://github.com/excitoon/scoop-user/blob/master/make.json#L15

@Fleshgrinder did you install Git-Bash from scoop as well?
As I can guess the problem is Git-Bash spoils finding cygwin1.dll in scoop app directory. Possibly it can be solved by making some kind of enforced shim, which would not pass Git-Bash environment into the application.

I think we can't afford having the same versions of every DLL of every application in a repo and in sync with all external application.

@excitoon nope, did not install Git Bash via scoop on the machine I tested your make with. However, I noticed that the installation of your make also starts installing Bash and other stuff.

This issue belongs in the Main bucket. Unfortunately, we cannot move this issue on this end, so it is being closed.
If this is still an issue, please create a new issue in the Main bucket via https://github.com/ScoopInstaller/Main/issues/new?body=Moved+from+https%3A%2F%2Fgithub.com%2Flukesampson%2Fscoop%2Fissues%2F2076


Verify correct origin in Tiler.execute

Address TODO in Tiler.java, in the execute function.

OBE


Implement Tenant Aware Metadata Topics

This patch introduces a new  configuration flag kafkaEnableMultitenantMetadata that makes KOP use separate namespaces for Metadata Operations.
Motivation:
Currently KOP cannot be used in clusters where you need strong tenant isolation because we are sharing the system metadata topics.
We need a way to totally isolate the traffic and data storage per tenant.
High level overview:
The Client authenticates passing as username the Pulsar tenant for metadata operations.
We use such tenant for every metadata operation, and so we isolate the traffic of each tenant.
Summary of changes:

Implement capture of "username" in SASL authentication
Introduce the concept of "tenant" on KOP Hander: it is the "username" if authenticated otherwise it is kafkaMetadataTenant (if the username is in the form of tenant/namespace as in older KOP versions, then we strip away the /namespace part)
Add kafkaEnableMultitenantMetadata, when this flag is enabled then the "username" is used instead of kafkaMetadataTenant  for every metadata operation and GroupCoordinator/TransactionCoordinator activity
Lazily bootstrap new GroupCoordinator/TransactionCoordinator at first usage (but we eagerly start it for the kafkaMetadataTenant in order to preserve backward compatibility and perform basic sanity check at ProtocolHandler bootstrap

@BewareMyPower @Demogorgon314
This is a draft Pull Request as I have set the new flag to "true" in order to see all tests passing with the new feature.
Unfortunately we will have to set it to "false" in order to preserve backward compatibility (if we want to preserve it, I am not sure this is true, because in 2.9.0 we stopped supporting username = tenant/namespace so there are already some breaking changes).
It would be great to set this to true in every new installation because with this feature you can really consolidated many Kafka clusters inside one single Pulsar and leverage the powerful multi tenancy feature of Pulsar, that is totally missing in Kafka.

I think we can set the new flag to "true", because 2.9.0 is not release yet.

I think we can set the new flag to "true", because 2.9.0 has not been released yet.

works well for me, thanks !

the Codacy Static Code Analysis  reports a problem against existing code.
I don't know how to fix it, I would have to refactor (split) the method, but I believe it is not good to do it for this patch (it is a separate work)

I restarted the tests, IMHO NPath complexity fixes in this PR is not good idea, is a problem left over by history, but if you like, you can fix here, because the are too many static code problem left over by history. Or you can fix this problem first in other PR? I'm very willing to review this change. what do you think?

Or you can fix this problem first in other PR? I'm very willing to review this change. what do you think?

I would prefer to defer to another patch. (I will be happy to follow up)
Let's focus on this problem now.

This PR is ready to review now?

Yes it is, all tests are passing

@Demogorgon314 I have addressed most of your comments,
I left some questions, PTAL again

I have also refactored MetadataUtils

@Demogorgon314 can you please re-run integration tests ? it looks they failed

Integration tests failed again, I will run them on my machine

there is something wrong in my last commit, tests started to fail
I am checking

@Demogorgon314 all tests passed again

@Demogorgon314 do you have a slack ID ? it would be nice to chat on slack, together with @BewareMyPower

@Demogorgon314 do you have a slack ID ? it would be nice to chat on slack, together with @BewareMyPower

My Slack ID is Kai Wang : )


Add dark mode

This PR brings minimal changes just to add support for dark mode without affecting other parts of the code and without changing the light mode (which only has minimal changes)

The second commit colors the links in the sidebar and ensures text in the graphs stays readable:

Merging for now, improvements can be made on top of this.


Bump containerd to v1.4.0-beta.0 release

Hi team!
Recently containerd released v1.4.0-beta.0. I would like to try "lazy pull" functionalities on k3c for speeding up pull operation. Can we consider to bump it up?
This project seems to use forked containerd so how can I contribute to dependencies (e.g. go.mod modification)? Are there any plans to migrate to the mainstream version of containerd?

Same here, but different issue, support for insecure registries-http.
https://github.com/containerd/cri/issues/1433#issuecomment-639144642


Improve Redis.hmset() warning message

It now describe what is deprecated and displays for the callers line by using stacklevel=2.
The warning is now tested and not emitted during normal test runs.
Pull Request check-list
Please make sure to review and check all of these items:

[x] Does $ tox pass with this change (including linting)?
[x] Does travis tests pass with this change (enable it first in your forked repo and wait for the travis build to finish)?
[x] Is the new or changed code fully tested?
Is a documentation update included (if this change modifies existing APIs, or introduces new ones)? N/A

Codecov Report

Merging #1282 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1282      +/-   ##
==========================================
+ Coverage   92.45%   92.47%   +0.01%
==========================================
  Files          19       19
  Lines        6415     6428      +13
==========================================
+ Hits         5931     5944      +13
  Misses        484      484

Impacted Files
Coverage Δ

tests/test_commands.py
99.94% <100%> (ø)
:arrow_up:

redis/client.py
85.8% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks @jdufresne. I changed all references from HMSET to HSET in the test suite except for the test that specifically tests HMSET.


[WIP]: UnderlineNav with updated design for states and counter

Closes #1240
UnderlineNav has updated design and this PR is for the updated states (default, selected, hover and focus state) as well as adding counter as a prop.
Screenshots

Screen Recording
https://user-images.githubusercontent.com/1446503/187836734-e7d1c516-5ab2-445c-83d4-bf20b9995f51.mp4
Merge checklist

[ ] Added/updated tests
[ ] Added/updated documentation
[x] Tested in Chrome
[ ] Tested in Firefox
[ ] Tested in Safari
[ ] Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

Thanks for the review @pksjce !

The underline from the nav seems to have gone away.

I used the states reference from Figma and there is no underline there so I though this line must have been removed with the updated design but for all the other references in Figma, the line is there! I added it back ✨  Sorry for the confusion!

The selected underline seems a bit longer on both sides compared to the Item.

Yes, you are right! I might have missed that. I also realised there was way too much margin between the li items. So all together, I re-styled them and this is for the reference to compare before and after. (I updated the PR description as well with the new screenshots)
Before

After

And the design

Also I'm sceptical about the name change from UnderlineNav.Link to UnderlineNav.Item. It would break existing API. Though, I agree its a change that makes full sense. Not sure how to proceed with it honestly.

Yeah I agree. It makes sense to me too and I see other "new" components such as ActionList uses Item too so it is good to be consistent. I guess we can discuss with others as well and find the best strategy to move forward with the major release.

Sorry for the confusion about the removal of the underline.
I initially intentionally removed it so with the removal of actions, consumers could easily build a custom UnderlineNav + actions horizontal layout and deal with the bottom border on the parent container. I also did so to support the use case in the code clone tab where we don't use a border at all.
But now that we have a clearer idea of what needs to be supported (and not) and how we'll move forward in the mid-long term, we should bring the underline back.

I also think the name change from UnderlineNav.Link to UnderlineNav.Item makes sense. Please feel free to point anyone interested in this discussion to the design API proposal: https://github.com/github/primer/pull/1239


refactor: remove react dependencies in the WalletController

Changes

add @terra-dev/wallet-types (Plain)
add @terra-money/wallet-controller (Plain)

depends on @terra-dev/wallet-types
now, modals does not depends on react (you don't need to install react, react-dom and styled-components)

@terra-money/use-wallet (React)

depends on @terra-dev/wallet-types

@terra-money/wallet-provider (React)

depends on @terra-dev/wallet-types, @terra-money/use-wallet, @terra-money/wallet-controller

React developers (No changes)
npm install @terra-money/wallet-provider@next # or 3.2.0-alpha.1

Other developers (New)
npm install @terra-money/wallet-controller@next # or 3.2.0-alpha.1

import { WalletController } from '@terra-money/wallet-controller'

const controller = new WalletController({ ...options }) // do not create multiple instance

TODOs

[x] Release alpha version
[ ] Test (anchor-web-app)
[ ] Add JSDoc comments
[ ] Release latest version
[ ] Update wallet-controller template

Does this also support the mobile integration, with deeplink to Terra Station on your phone, and with QR popup on desktop (e.g. safari)?

Ok I havent tested your changes yet, but I know that the QR modal depends on React.
I also copy pasted the wallet-provider some time ago one of our vue project, and I removed all the React code manually to make it work. And I also had to remove the QR and mobile support, because it depended too much on React. (and I had no quickfix for it) - so I just support Chrome now with Terra extension.
Thats why I asked if you found a support for the QR modal, and mobile support.

@phips28 Ah... this change is the update to remove react from the internal modal components.


Is it possible add a new environment variable to configure the timezone?

The default timezone is America, if it is possible add an environment variable TZ to configure the timezone. Thanks

TZ variable is already working on the docker compose

Ah, OK, Sorry, in the documentation I don't see this variable.

The content in docker compose,
version: "3.1"
services:
saic-mqtt-gateway:
image: "saicismartapi/saic-python-mqtt-gateway:latest"
container_name: "saic-mqtt-gateway"
environment:
- MQTT_URI=${MQTT_BROKER_URI}
- MQTT_USER=${MQTT_USERNAME}
- MQTT_PASSWORD=${MQTT_PWD}
- SAIC_USER=${SAIC_USERNAME}
- SAIC_PASSWORD=${SAIC_PWD}
volumes:
- ./charging-stations.json:/usr/src/app/charging-stations.json
I don't see the TZ in environment.
Thanks

Just add it in the environnement section it is a common environnement variable system based juste like the user and group ids one


ToB state management (#23420)

This PR:

Introduces app_state for navigation and state management.
Loads and shows a selected unit's content.
Removes SdkModel in favor of Sdk from playground_components.

This PR is based on an unmerged https://github.com/akvelon/beam/tree/tob-23316-models branch, so after its merge and an internal review it will be rebased to the updated master.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Will this PR include tests of state management?

Maybe later.

Published in Apache as 23572.


Pagination

Could you please add pagination?

You can use jekyll's built in feature for that - https://jekyllrb.com/docs/pagination/


setBorderColor causing error in IE11

dataset.setBorderColor(borderColors.toArray(new String[0]));

Works fine on all browsers except IE11 gives an error :

Unknown.Crx_g$(ArrayString.java:63)
Unknown.bKx_g$(HovingDataset.java:340)

When removing the setBorderColor line the graph work without any problem

@FrankW76 I've tested right now on IE11.
Here my code:
PieDataset dataset = chart.newDataset();
dataset.setBorderWidth(5,5,5,5,5,5,5);
List<String> list = Arrays.asList(Colors.ALL[8].toRGBA(), Colors.ALL[5].toRGBA(),Colors.ALL[13].toRGBA(),Colors.ALL[15].toRGBA(),Colors.ALL[1].toRGBA(),Colors.ALL[0].toRGBA(),Colors.ALL[19].toRGBA());
dataset.setBorderColor(list.toArray(new String[0]));

Here the result:

I have checked also the code of the error you got it and sounds really strange because is the native object.
May I ask you which chart type you are using (I assumed Pie or Doughnut)?

Noted that also setBorderWidth does not work for me.

  ResourcesType.setClientBundle(EmbeddedResources.INSTANCE);

  DoughnutChart chart = new DoughnutChart();
  chart.getCanvas().getElement().getStyle().setOutlineStyle(Style.OutlineStyle.NONE);

  DoughnutDataset dataset = new DoughnutDataset();
  dataset.setBorderWidth(5,5,5,5,5,5,5);

This gives an error
(TypeError) : Kan de eigenschap apply van een niet-gedefinieerde verwijzing of een verwijzing naar een lege waarde niet ophalen

Unknown.zox_g$(ArrayInteger.java:61)
Unknown.fKx_g$(HovingDataset.java:412)
Unknown.kZi_g$(BalanceTileBox.java:152)

With BalanceTileBox.java:152 being the setBorderWidth line.

I've added also the style of canvas you are using and it works fine.
I know it sounds a strange request but could you recompile your GWT application?

I found that Array javascript object has got a method Array.from and in Charba implementatio we created a overlay method on Array object with the same name but different signature and not native.
I have the feeling that could create some conflicts (between polyfill and how JSINTEROP acts overlaying methods, I'm still investigating) therefore we have changed the name of Charba method and committed.
Unfortunately I'm not able to reproduce the issue because, as wrote above, I don't get that error.


Need checks and constraints for bract development.

From @cerivs on March 11, 2019 23:21
I found a improper zebrafish annotation to bract development GO:0010432 (that I made by accident)  which is showing up on the current data release of amigo.  It looks like there should be error reports  to let us know if there are data issues but I don't think they are running.  Annotation has been in place for at least a couple of years.
Usage of term should be restricted to phyllome.  If this ticket needs to be moved to a different tracker please do.
Annotation has been updated so the bad data should go away but we still need a report if we violate the constraint.

Copied from original issue: geneontology/go-annotation#2289

@cerivs We put these requests in the ontology tracker. I'll move this one.
Thanks, Pascale

When will taxon restrictions be working again?

@pgaudet the constraint is there in PO, we'll check what is going on cc @balhoff @dougli1sqrd
@ValWood not sure what you mean can you open a new ticket?

I see an anonymous ancestor for this being only_in Viridiplantae. This looks like it is coming from PO. Not sure why it isn't being used. @balhoff @dougli1sqrd ?

Taxon constraints are reported in the reports but not filtered.
We would really like to have them filtered in AmiGO, and in the files we produce.
They would still be in reports, and when submitting groups fix them, they would come back (iunder the correct annotation).
Thanks, Pascale

I thought we were waiting for some new method to be implemented by Jim?
https://github.com/geneontology/go-ontology/issues/16722

I agree I saw this when I was trying to track the status
https://github.com/geneontology/go-site/issues/763
should be a hard check, as they are incorrect as they stand. the curator used the wrong term.

I commented over on #16722.

@balhoff, I'm still not sure why the PO taxon constraints aren't being used.

@ukemi where is the problem? Was the taxon violation not in the report? I think the annotation was already fixed, because I can't find it in snapshot.

From the comments above, I concluded that the taxon violation was not detected. @ValWood?
What did you mean by:

When will taxon restrictions be working again?

It's OK, I was under the impression that they were not currently being reported...but it is possible that they are. We can't check because we don't have any examples right now.

I confirmed that 'bract development' and 'in taxon' some 'Vertebrata <Metazoa>' is unsatisfiable, will go ahead and close this.


Post release tasks for 4.9.1

Description
This issue attempts to track the steps necessary to complete post-release maintenance tasks for 4.9.1.
The goal is to complete the following tasks, each task must have a PR associated with this issue.
The branches must follow the naming: merge-<ORIGIN_BRANCH>-into-<DESTINATION_BRANCH>. For example, merge-4.9.1-into-4.10.0.
Tasks

[x] Merge branch 4.9.1 into branch 4.10.0.

https://github.com/wazuh/wazuh-dashboard/pull/364

[x] Merge branch 4.10.0 into branch 4.10.1.

https://github.com/wazuh/wazuh-dashboard/pull/365

[x] Merge branch 4.10.1 into branch 4.10.2.

https://github.com/wazuh/wazuh-dashboard/pull/366

[x] Merge branch 4.10.2 into branch master.

https://github.com/wazuh/wazuh-dashboard/pull/367

[x] Publish GitHub release as latest.
[x] Delete all stage pre-releases for 4.9.1 (https://github.com/wazuh/wazuh-dashboard/releases).
[x] Delete all stage tags for v4.9.1. BE CAREFUL NOT TO DELETE DEFINITIVE TAG. Example: v4.9.1-rc1, 4.9.1-alpha1, etc.

LGTM

LGTM


Support slice types

This fixes bug related to parsing values given as array. containous/traefik#2416

Coverage increased (+0.6%) to 80.965% when pulling a6f3a5b9dc61b3a63db003a45c9116f130093193 on iahmedov:array_support into af517d5b70db9c4b0505e0144fcc62b054057d2a on containous:master.