HTML-CSS, FF32+, stretchy integral clipped

Something as simple as $$\int$$ gets clipped on the right, , e.g., on mathjax.org or using http://cdn.mathjax.org/mathjax/latest/test/sample-dynamic-2.html.
It happens at default and smaller zoom levels for me, disappears at larger zoom levels.
Seeing this on the develop branch as well.

This is a display bug in Firefox.  We have seen it in the past, but it appears that it has become much more reproducible since version 32.  The HTML generated by MathJax is not in error, but Firefox seems to be using the wrong clipping region.  (The ink for the integral sign lies considerably outside its character bounding box, which is likely the issue.)  You can get it to display properly by zooming out and then back in, for example, or resizing the window, or forcing a reflow in other ways, so this indicates that the underlying HTML is OK, and it is just not being displayed properly.
One hack solution would be to force a reflow after the math has been displayed (this is fragile).
The sample-dynamic-2.html file is actually somewhat complicated in that it uses a double-buffering approach so that the displayed result never shows the raw TeX code.  It appears that that might be part of what triggers the problem, as sample-dynamic.html (which is single-buffered) doesn't seem to exhibit the clipping.  I will have to see if I can come up with a minimal test case (not involving MathJax) that produces the problem.

This is a display bug in Firefox. We have seen it in the past, but it appears that it has become much more reproducible since version 32.

Got it.

You can get it to display properly by zooming out and then back in, for example, or resizing the window, or forcing a reflow in other ways,

Usually (i.e., with other clipping bugs), that works for me, but FYI not this time. I do get some funky rendering artefacts when resizing the window though (the missing top right piece is smeared across the viewport). Fun...

It appears that that might be part of what triggers the problem, as sample-dynamic.html (which is single-buffered) doesn't seem to exhibit the clipping.

The following reproduces the error for me.
<!DOCTYPE html>

  <meta charset="utf-8">
  <title>MathJax#1009</title>

 Testing https://github.com/mathjax/MathJax/issues/1009

$$\int$$

I will have to see if I can come up with a minimal test case (not involving MathJax) that produces the problem.

Thanks!

OK, I see the problem with just
<!DOCTYPE html>

  <title>Bad clipping of integral sign</title>

  ∫

but this relies on the font being local.  If I switch to the web font, then it doesn't clip.
<!DOCTYPE html>

  <title>Bad clipping of integral sign</title>

  ∫

Are you running with local fonts?  I will ask on SE if the OP there has local fonts.
I get even word results with local STIX fonts, but again, the web fonts work fine.  Not sure what's up with that.  I would hate to have to force web fonts for Firefox.

Well, it looks like everyone having the problem has local fonts installed.  Since a number of systems now come with STIX fonts installed, that is probably pretty common, now.
A temporary workaround for those experiencing it is to force the use of web-based fonts, which don't seem to exhibit the problem.  To do that, take the following steps:

Open the debugging console (select Tools -> Web Developer -> Web Console in the menu bar).

Type
 MathJax.Menu.showFontMenu(true);

in the console type-in area and press RETURN.

Right-click on any typeset expression to open the MathJax contextual menu.

Select Math Settings -> Font Preferences -> TeX (web) (or STIX (web) if you prefer).

The page will reload, and you should be using web fonts rather than local fonts (use the About MathJax contextual menu item to verify that).

Filed upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1126704

Seems to be resolved ing FF36.

Good to know.

And it's back.

There's update from Mozilla on this https://bugzilla.mozilla.org/show_bug.cgi?id=1126704 It's unfortunate expected behavior from their performance optimizations. A workaround would be to use optimizeLegibilty but AFAIK is costly in terms of performance, cf. https://bocoup.com/weblog/text-rendering. Then again, it's always applied to webfonts for FF so to some degree we're not getting worse (but this might also explain why FF is always slower).

I'll check to see if that helps.  It would be possible to add this only for the affected characters (the integral signs are the only ones I know about).

. It would be possible to add this only for the affected characters (the integral signs are the only ones I know about).

Not for 2.6.1, correct?

It could go in 2.6.1.  I can have it only add the style to those characters that extend appreciably beyond their character width, like the integral signs.  That is a one-line change that only affects a small number of characters and it can be restricted to Firefox, so it is easy to run the tests again. Shall I do that?  I'm still waiting for a reply from Volker on my comments on his pull request, so 2.6.1 isn't quite ready for release anyway.

PS, I think this only affects HTML-CSS output, even though CommonHTML also uses the same fonts.  I'm not sure exactly why that is, but it may be because CommonHTML uses @font-face directives to access even the local fonts, and that may trigger the optimizeLegibility rendering even though it is not actually a web-based font.
Has anyone seen this clipping effect in CommonHTML?

Shall I do that?

Seems you did :wink:

Has anyone seen this clipping effect in CommonHTML?

Not as far as I know.

By "that" I meant include this fix in 2.6.2 and run tests.  I haven't done that yet.  Figuring out if it would work was effectively figuring out the fix, so I made a branch that included it rant rather than lose the work.  That doesn't have to added to 2.6.1.

Copy that.

=> Merged

=> In testsuite
MathMLToDisplay/issue1009.html


JAB Code to increase data capacity?

I haven't looked into it deeply yet, but my first impression of this project is: "This is amazing! Can we add colors to the QR code to boost data transmission capacity?" There's a project called https://github.com/jabcode/jabcode that brings this extra color dimension to QR codes. I'm not certain if this is practical, and there may be other options, but I just wanted to share this idea!

Thank you for your sharing, cc @sumimakito, she is trying to add color channels to QR codes


Select All option not working

when I select all and try to unfollow, it doesn't work. it only works when I select the accounts that do not follow, one by one.

I'll take a look asap

I'll take a look as well.
It would also be helpful if you could describe what actually happens when you try to perform the action.
i.e. - does the UI change or remain the same? And if it changes, what is being displayed? etc..
@Ditome

when I select all and try to unfollow, it doesn't work. it only works when I select the accounts that do not follow, one by one.

Merged the @tomleb3 fix.
Try now.


Test case for devices with multiple instances of the same device type

Is there a test case for something like a single light device with four independently controllable bulbs? Each bulb would be on its own end_point but the all EPs have the same device type. This is needed to ensure that controllers don't make an assumption of only one copy of a device type per device when it is legal to have many.  A parallel case would be a single device implementing multiple light switches. Just want to make sure this is tested for since controllers could easily make a one to one assumption instead of one to many.
A specific hardware example: LED string light controllers that control multiple, independent strings.  It would have a single IP address with four color light EPs.

I am also facing this issue using examples/lighting-app/python.


Fix #448 - pfTableView: conflicting PF and A-PF datatables deps

Overrode the datatables's main definition in its bower.json (like the example above) to remove the reference to jquery.dataTables.js

Hi, I believe this change needs to go into the 'branch-4.0-dev' branch.  In 'master' a-pf 3.x we do not have datatables as a dependency.
Thanks!

Hi, why did you close this issue?  The PR is still open.
Thanks,

Dave

Sorry.
I closed the PR to master and GitHub automatically closed the issue. I
created a new PR to v4 branch.
On Thu, May 18, 2017 at 2:03 PM, David Taylor<EMAIL_ADDRESS>wrote:

Hi, why did you close this issue? The PR is still open.
Thanks,

Dave

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/patternfly/angular-patternfly/pull/465#issuecomment-302473180,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0lT5hNpduAp566A_pqOBXlM4KOGnQDks5r7Hn1gaJpZM4NfWiN
.

--
ALEXANDRE KIELING
SOFTWARE ENGINEER, MIDDLEWARE
RED HAT
https://www.redhat.com/
https://red.ht/sig


YARN-10493: RunC container repository v2

2848

 Quality gate: Failed
13 Issues

 3 Vulnerabilities
 10 Code issues

Details

 Quality gate: Failed
12 Issues

 3 Vulnerabilities
 9 Code issues

Details


Telegam funktion for open window detection

Hi @SeydX.
Is it possible for you to add the telegram feature for this plugin too?
Would be really nice.
Thanks in advance.

Will add this to my list thx

Would be great with the revision of the plugin if you can install the telegram function also for the presence sensors as with the Fritz plugin 😉

Added to list #48

Added in v6


steam-rom-manager: 2.4.17 -> 2.4.24

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/SteamGridDB/steam-rom-manager/releases.
meta.description for steam-rom-manager is: An app for managing ROMs in Steam
meta.homepage for steam-rom-manager is: https://github.com/SteamGridDB/steam-rom-manager
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.4.22 with grep in /nix/store/8ny8dkrimsa52yk6r6wfkqscjynyw3m4-steam-rom-manager

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

steam-rom-manager

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/8ny8dkrimsa52yk6r6wfkqscjynyw3m4-steam-rom-manager \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A steam-rom-manager https://github.com/r-ryantm/nixpkgs/archive/95445c826b335b917e40c95d723b206fea0e95cb.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/95445c826b335b917e40c95d723b206fea0e95cb#steam-rom-manager

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/8ny8dkrimsa52yk6r6wfkqscjynyw3m4-steam-rom-manager
ls -la /nix/store/8ny8dkrimsa52yk6r6wfkqscjynyw3m4-steam-rom-manager/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

steam-rom-manager

Maintainer pings
cc @SquarePear for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/SteamGridDB/steam-rom-manager/releases.
meta.description for steam-rom-manager is: An app for managing ROMs in Steam
meta.homepage for steam-rom-manager is: https://github.com/SteamGridDB/steam-rom-manager
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.4.24 with grep in /nix/store/dgsp6nbq4iigjs9h5p03p9wn70qph6bg-steam-rom-manager

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

steam-rom-manager

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dgsp6nbq4iigjs9h5p03p9wn70qph6bg-steam-rom-manager \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A steam-rom-manager https://github.com/r-ryantm/nixpkgs/archive/1c288f438c28694b0ba37251f00b825d7444fd9f.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1c288f438c28694b0ba37251f00b825d7444fd9f#steam-rom-manager

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dgsp6nbq4iigjs9h5p03p9wn70qph6bg-steam-rom-manager
ls -la /nix/store/dgsp6nbq4iigjs9h5p03p9wn70qph6bg-steam-rom-manager/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

steam-rom-manager

Maintainer pings
cc @SquarePear for testing.


add fix timer race code

/azp run

/azp run

/azp run

    break;

Break should go one line higher

Refers to: win32/tests/threadpool_win32_int/threadpool_win32_int.c:1064 in 491e0ff. [](commit_id = 491e0ff53d6e2f42d92f89d4bcba4259f234ecdd, deletion_comment = False)

    break;

Here and below.

In reply to:<PHONE_NUMBER>

Refers to: win32/tests/threadpool_win32_int/threadpool_win32_int.c:1064 in 491e0ff. [](commit_id = 491e0ff53d6e2f42d92f89d4bcba4259f234ecdd, deletion_comment = False)

TEST_FUNCTION(schedule_after_close_works_v2)

I think the same chaos tests should be run on Linux also.
As a matter of fact, why are we even having 2 separate test suites for Linux and Windows for the integration part?
Unit tests should be different, but at integration level we should be running exactly the same test code on both platforms and it should pass ....

Refers to: linux/tests/threadpool_linux_int/threadpool_linux_int.c:869 in 491e0ff. [](commit_id = 491e0ff53d6e2f42d92f89d4bcba4259f234ecdd, deletion_comment = False)

    break;

done

In reply to:<PHONE_NUMBER>

Refers to: win32/tests/threadpool_win32_int/threadpool_win32_int.c:1064 in 491e0ff. [](commit_id = 491e0ff53d6e2f42d92f89d4bcba4259f234ecdd, deletion_comment = False)

/azp run

/azp run

/azp run

/azp run

TEST_FUNCTION(schedule_after_close_works_v2)

combine them the linux/win32 int test are same now, will move it to c-pal/common in next prhttps://msazure.visualstudio.com/One/_workitems/edit/30570832

In reply to:<PHONE_NUMBER>

Refers to: linux/tests/threadpool_linux_int/threadpool_linux_int.c:869 in 491e0ff. [](commit_id = 491e0ff53d6e2f42d92f89d4bcba4259f234ecdd, deletion_comment = False)

/azp run

/azp run

/azp run

/azp run

/azp run

#include <string.h>

Didn't we say we should have only one int test file?

Refers to: linux/tests/threadpool_linux_int/threadpool_linux_int.c:8 in 438a45a. [](commit_id = 438a45aee823d4fc9b049f33511f9480a12678a2, deletion_comment = False)

/azp run

/azp run


Issues with SSR since<EMAIL_ADDRESS>

I am trying to integrate @optimizely/react-sdk with a project that uses the next.js framework. Everything was working fine, but since the release of<EMAIL_ADDRESS>there is a problem with the initialization of optimizely instance on the client-side.
Even though I am providing the datafile that is fetched during server-side rendering, optimizely.isReady() initially returns false.
So my experiments that are defined like below:

Experiments:

<OptimizelyExperiment experiment="DEV_experiment">
  {variation =>
got variation {variation}
}
</OptimizelyExperiment>

<OptimizelyExperiment experiment="DEV_experiment">
  <OptimizelyVariation variation="variation_1">
    variation_1
  </OptimizelyVariation>
  <OptimizelyVariation variation="variation_2">
    variation_2
  </OptimizelyVariation>
  <OptimizelyVariation default>
    default
  </OptimizelyVariation>
</OptimizelyExperiment>

During the server-side render the content for variation_2.

Experiments:

got variation variation_2

variation_2

But in the browser, it cannot retrieve it for some reason.

Experiments:

got variation

default

Instead, I can see logs in the console that Client became ready (https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L132). However, since I provided datafile, should not the client be ready right after initialization?
To Reproduce
You can use this repository to see the issue: https://github.com/oMatej/nextjs-optimizely
I think it can be something related to: #58

Ok, I think I found what is the issue.
https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L108-L160
Here we have a useClientInitializationState hook, that will update clientReady and didTimeout inside useEffect when Optimizely becomes ready. This hook is used later on by useExperiment and useFeature.
However, both useExperiment and useFeature are not aware of changes to clientReady and didTimeout that happens after optimizely.onReady({ timeout: finalReadyTimeout }) execution. Because of that, decisionState has { variation: null } as initial state: https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L192-L197.
Because of that, https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L210 this line is not executed, because previous and current decisionState are equal. And this line: https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L216 is also not executed because we provided the user object during the initial render.
useClientInitializationState is used right before returning the values from the useExperiment / useFeature hooks: https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L222-L224
There is a workaround to tackle this case. Even though we have user and datafile from the beginning, we cannot provide them to OptimizelyProvider immediately. Instead, we can wait for the onReady promise to be fulfilled, and update the user object when this happened. This will trigger this callback: https://github.com/optimizely/react-sdk/blob/master/src/hooks.ts#L216.
    // https://github.com/oMatej/nextjs-optimizely/blob/test/optimizely/withOptimizelyProvider.js#L10-L31
    const WithOptimizely = ({ datafile, id, ...props }) => {
        const { query } = useRouter();

        const optimizely = getOrInitializeOptimizely({ datafile, isBrowser });

        const [isReady, setReady] = useState(!isBrowser());

        const user = useMemo(() => {
            if (!isReady) {
                return {};
            }

            return {
                id,
                attributes: query
            };
        }, [id, query, isReady]);

        useEffect(() => {
            optimizely.onReady().then(() => {
                setReady(true);
            });
        }, [optimizely]);

        return (
            <OptimizelyProvider
                optimizely={optimizely}
                user={user}
                isServerSide={!isBrowser}
            >
                <PageComponent {...props} />
            </OptimizelyProvider>
        );
    };

However, I think it should be solved inside useExperiment and useFeature hooks.

I have the same issue, the optimizely datafile is fetched during server side rendering, and bound to the window object for the client to pick it up. The issue is not related to Next.js, I have a custom implementation.
Once that happens the optimizelyInstance is initialized on the client side with the datafile and the user already there (also populated during SSR).
The app proceeds with rendering and comes across the component which uses useExperiment hook, the returning value for variation is null.
If I call optimizelyInstance.getVariation(<experiment>) manually the correct variation identifier is returned.
At any point the component is not re-rendered by useExperiment so the variant remains null at all times.
The same applies when using OptimizelyExperiment hoc, the default variation is always rendered.
The data does not seem to be consistent between the instance (optimizelyInstance) itself and the ReactSDK.
I can see the log from the main optimizely-sdk lib which contains the correct data.
https://github.com/optimizely/javascript-sdk/blob/8028443919aa6beea06564324621189f911e8f29/packages/optimizely-sdk/lib/utils/enums/index.ts#L118
@oMatej Your solution unfortunately doesn't work for me, as the variation is never recomputed and my components are not re-rendered.

Can confirm this is still an issue. Any chance for a fix soon?

Confirm as well, any chance for a fix anytime soon?

To be clear this issue is blocking my team from becoming Optimizely customers and we are actively looking at integrating competitors such as LaunchDarkly. Please maintain your SDK's.

Hi @oMatej 👋 The !ready solution appears to work well. Can you explain what you mean by "there is a problem with event listeners"?

@will-stone I wanted to register notification listeners for optimizely instance created inside this WithOptimizely HOC (inside some additional useEffect). The problem with using !ready for isServerSide prop was that in such a case these listeners were, most probably, registered for the instance of optimizely that was replaced after updating the value of ready.
As far as I remember, the working alternative was moving the logic responsible for setting them up directly to getOrInitializeOptimizely function, but on the other hand, it made it impossible to update these listeners based on some props of the HOC, and so on.

Thank you @oMatej for the quick reply 😄 Okay, I'm not sure we need to use those so looks like the !ready solution should be enough for our needs. Thanks for that too!

The issue was automatically closed by Github when the related PR got merged. This was not intended. Reopening the issue and will soon share an Alpha release based on the fixes done in this PR.

@oMatej @drazenbuljovcic @rrdelaney @8enSmith @will-stone @BartJanvanAssen we just released an alpha patch version 2.7.1-alpha that hopefully resolves issues reported here. We would very much appreciate your feedback, so please feel free to provide us with your updates here.
Thanks everyone for your patience as we continue working to resolve this issue!

@yavorona it seems like now the output is the same after the hydration process, but there is a problem with updating the decision after user provided to OptimizelyProvider got updated.
So I have this component that renders some content based on the decision, and I am providing query parameters as attributes. Whenever there is test=experiment then my user should be part of the experiment, but it does not mean that my initial render happened with this query parameter.
const Home = () => {
  const [decision] = useDecision('react-sdk-test', { autoUpdate: true });

  return (

      <Link href="/">No experiment</Link>

      <Link href="/?test=b">No experiment</Link>

      <Link href="/?test=experiment">Experiment active</Link>

Experiments:

      {
        decision.enabled
        ? (
 Feature enabled
)
        : (
 Feature not enabled
)
      }

  )
};

With current alpha version, first change of user object does not trigger the new decision. Following updates to user trigger new decisions properly.

@yavorona just wanted to bump this issue as we were seeing this in prod and the alpha release seems like it fixed it. Just wondering if you had a timeline for when this would be promoted to a non-alpha release?

You can expect a new release including this fix by the end of next week.

You can expect a new release including this fix by the end of next week.

Amazing! Thank you!!


Enhancement/sex behaviour data

I can't find a way of reducing the line lengths on these files because of all the long names for data fields so I keep failing static checks

So this addresses #28 and #29, right?


Installation command problem

....\AppData\Roaming\npm\node_modules\generator-fountain-webapp\node_modules\fountain-generator\lib\Base.js:21
const {framework, modules, js} = this.options;
SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
at Object. (C:\Users\Akash\AppData\Roaming\npm\node_modules\generator-fountain-webapp\node_modules\fountain-generator\index.js:2:9)
at Module._compile (module.js:410:26)
at Object.Module._extensions..js (module.js:417:10)
Hi,
I am getting above error while launching the generator after all dependencies installed properly.
$npm install -g yo generator-fountain-webapp  ==>  this works fine with no issue.
However I am stuck immediately while try to run the below command.
$ yo fountain-webapp
Please help.

This should come from your node version. Have you Node 6+ as required?

Oh thank you so much. I am using 4.4.1. let me upgrade it.

mmm... that is interesting.
This page needs updating: http://yeoman.io/codelab/setup.html

I guess I missed it that time, they already mention here.
https://github.com/FountainJS/generator-fountain-webapp

what happened with me that i had an old version of node and yeoman requires node v6 or higher
so i simply run:
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

and it works with me
you can check this if you have Linux OS distribution:
https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions
[http://yeoman.io/codelab/setup.html]
(http://yeoman.io/codelab/setup.html)


Nodes column number now starts at 1 as it should be

Codecov Report

Merging #30 (3ef0d7f) into master (87ef8d0) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master      #30   +/-   ##
=========================================
  Coverage     47.56%   47.56%
  Complexity      243      243
=========================================
  Files            63       63
  Lines          1169     1169
  Branches        123      123
=========================================
  Hits            556      556
  Misses          564      564
  Partials         49       49

Impacted Files
Coverage Δ

...in/kotlin/org/actorlang/parser/impl/AntlrParser.kt
73.30% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Release v1.1.2-rc8

Deps:

GUI: v1.1.2-rc8
Installer:v1.1.2-rc8
network controller: 0.3.2-rc5

The commits include backport of https://github.com/harvester/harvester/pull/3787

create a new single node cluster, work fine

upgrade v1.1.1->v1.1-head work

Upgrade from v1.1.1 -> v1.1-head and basic operations look well.
Also, the downstream cluster is created then PVC works.


No way to change font size in v1.0?

Hi there.
Nice update, thanks.
However, there is still no way to control the font size?
I'll just remind you that if I resize (enlarge) the size of the preview window, then the caption's font gets bigger accordingly, which starts to look less pretty.
And you said you'd see what you could do with it in the next release.
So, any progress on it?
Oh, and one more thing while we're at it.
Is it possible to call this window when hovering over the active tab, but without an image preview?
Just like it is implemented in MS Edge, for example (see attachment)..
TIA

@VitalSkib I’m flattered that you stick around. As this update mainly focuses on performance and compatibility, introduction of new features were dropped.
The text-only tab preview panel on active tab is achievable with edits to the CSS theme. Appending this after the original CSS theme will enable the effect.
/* shows the tab preview panel on active tab */
.tabbrowser-tab[selected]:hover::after {
	opacity: 1 !important;
}

/* text-only variation */
.tabbrowser-tab[selected]::after {
	--preview-height: 50px !important;
	background-position: bottom;
}

/* height transition (optional) */
#tabbrowser-arrowscrollbox:not(:hover) .tabbrowser-tab::after {
	transition: opacity 0.5s, filter 0s var(--preview-delay-tolerance), height 100ms !important;
}

#tabbrowser-arrowscrollbox:hover .tabbrowser-tab::after {
	transition: opacity 0.5s, filter 0.5s var(--preview-delay), height 100ms !important;
}

Ha, that's cool, thanks. 😎👍
A couple of wishes, kinda future request..
A favicon icon on the left of the url and dynamic text wrapping to another line(s) if the text is too long.
tia

My pleasure. In the released version, I didn’t include the above CSS because it seems to cause stuttering / performance degradation when Adaptive Tab Bar Colour is also installed. If you notice any unwanted behaviour, you might want to revoke the changes.
Customisations, including the possibility to change text size, are under way. So is adding favicon to the text box.
Text wrapping might be difficult.

My pleasure. In the released version, I didn’t include the above CSS because it seems to cause stuttering / performance degradation when Adaptive Tab Bar Colour is also installed. If you notice any unwanted behaviour, you might want to revoke the changes.
Customisations, including the possibility to change text size, are under way. So is adding favicon to the text box.
Text wrapping might be difficult.

Well, I don't use the Adaptive Tab Bar Colour, but I also noticed some unwanted behavior that is a bit annoying.
So, yeah, I'm probably going to drop this idea, but thanks for the help.

In order not to create many posts, I’ll ask here, if you don’t mind.
I'm wondering if there is a way to change the background color of this part?
I couldn't figure out how (if) I could do this.
tia

@VitalSkib The background colour of the text box is decided by the frame colour of the current Firefox theme. For now, it cannot be configured alone.

@VitalSkib The background colour of the text box is decided by the frame colour of the current Firefox theme. For now, it cannot be configured alone.

Tab-Preview-On-Hover doesn't want to work for me for a couple of months now with some of the latest Firefox Nightly updates.
I don't know why and I don't have time to find out which of their changes affected this.
So..

Thanks for the information. Preview panels not showing up will be the CSS’s issue, while they being blank should be the add-on’s issue. Either way, I’ll wait until the new iteration of Firefox releases.

Yeah, it just doesn't show up at all.
Thanks.


fix: convert defineNuxtRouteMiddleware to legacy middleware

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Fixed defineNuxtRouteMiddleware as it needs to be converted to legacy middleware and executed.
Also, abortNavigation has been updated with reference to Nuxt 3.
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Thank you! 👌

FYI now that this has been released to npm, we cannot use the latest nuxt bridge. Trying to start our application results in a blank page. And an error in the console that states:
composables.mjs:126 Uncaught (in promise) TypeError: Cannot set properties of undefined (setting '_processingMiddleware')
    at _callee$ (composables.mjs:126:40)
    at tryCatch (runtime.js:64:15)
    at Generator.invoke (runtime.js:299:1)
    at Generator.eval [as next] (runtime.js:124:1)
    at asyncGeneratorStep (asyncToGenerator.js:3:1)
    at _next (asyncToGenerator.js:25:1)
    at eval (asyncToGenerator.js:32:1)
    at new Promise (<anonymous>)
    at eval (asyncToGenerator.js:21:1)
    at eval (composables.mjs:136:4)

@Towerism
If possible, could you provide a reproduction?
It will help us to resolve that error quickly.


REPL is missing in Exercise section in Dictionaries page of learningpython.org

Thanks for the awesome materials.
REPL is missing in Exercise section in the Dictionaries page in learningpython.org.
https://www.learnpython.org/en/Dictionaries

Closed by #538

Closed by #538


Feature request: MOCHA_GREP environment variable (alternative to --grep)

Is your feature request related to a problem or a nice-to-have?? Please describe.
I've been working with sequelize lately and it's awkward to grep for tests in their repo.  Here are some of their package scripts:
    "test-docker": "npm run test-docker-unit && npm run test-docker-integration",
    "test-docker-unit": "npm run test-unit",
    "test-docker-integration": "env-cmd $npm_package_options_env_cmd npm run test-integration",
    "test-integration": "mocha --require scripts/mocha-bootload --globals setImmediate,clearImmediate --exit --check-leaks --colors -t 30000 --reporter spec \"test/integration/**/*.test.js\"",
    "test-integration-postgres": "cross-env DIALECT=postgres npm run test-integration",

Grepping for tests is a hassle because

I have to use a variable number of --, like npm run test-docker-integration -- -- --grep foo, depending on the script, to pass --grep to the actual mocha command.  yarn doesn't have this problem if you use yarn instead of npm run in the package scripts, but I don't control that.
npm run test-docker -- -- --grep foo would only apply the --grep to the test-docker-integration script, not to the test-docker-unit script.

Describe the solution you'd like
If I could just do MOCHA_GREP=foo npm run test-docker it would be a lot easier.
Describe alternatives you've considered
I'm planning to PR some additional scripts to their repo for grepping tests, but I'm sure sequelize isn't the only repo that makes grepping difficult like this, so I'd rather have a quick and easy way to do it for future projects I may work on.

Couldn't you use configuration files?

I guess that's true...it would be a bit more of a hassle to edit the grep and avoid committing the file to the repo than if I could just use an environment variable though

I don't agree to add MOCHA_GREP. Because if we support mocha flags with environment variable, we should support all flags with environment variable rather than only --grep.
It makes hard to maintain mocha's flags.


[kubernetes] create kubelet check

What does this PR do?
Add a kubelet check that consumes prometheus-formatted metrics from the kubelet.
Motivation
cAdvisor isn't surfaced by default anymore. The recommended way to get local metrics is through the kubelet now.
Testing Guidelines
WIP
Versioning

[x] Bumped the version check in manifest.json
[x] Updated CHANGELOG.md

Additional Notes
rely on:

https://github.com/DataDog/datadog-agent/pull/1183
https://github.com/DataDog/datadog-agent/pull/1211

thanks for the review @CharlyF I have a notebook that tracks metrics from kubernetes check --> kubelet check, will clone it on a shared account so it gets more 👀


[PE-D][Tester A] UI screenshot is not annotated to orientate users to GUI

The UI screenshot in the quick start does not explain the components of the GUI which might confuse users.

Labels: type.DocumentationBug severity.VeryLow
original: Darren159/ped#9

Just need to add annotation, no need explain components (done in glossary already)


use automatic detection of the OpenStack BS version

What this PR does / why we need it:
Use automatic detection of the OpenStack BS version.
Use automatic detection of the OpenStack BS version in the Kubelet's cloud-config

/assign @alvaroaleman

/retest

/retest

/retest

/retest

/retest

/lgtm
/approve

/retest

/retest

/retest

/retest

/retest

/retest


Minecraft Neoforge?

Hi,
could you add Minecraft Neoforge?
https://neoforged.net/
Thanks

there are two available templates but they haven't been merged to the main branch yet
https://github.com/pufferpanel/templates/pull/295  compatible with 1.20.x
https://github.com/pufferpanel/templates/pull/297 1.21


[cmd][xzcatomicswap] Change dumprivkey RPC sequence for Zcoin

Zcoin added a one-time authorization key returned in error string from a first call to dumpprivkey. Along with a warning. The key is used in 1 (one) subsequent call to the same RPC function. The idea is that inexperienced people are warned if scammers propose they use `dumpprivkey'.

please merge dpk3

are you 100% sure?

and then how to manage the rebase that would then be demanded?

Good question.
You can fetch the refs/pull/102/head ref but I never tried pushing to it. What I would try is to reinstate your fork and create a branch with the same name that was used to start the PR, and push to it. Second idea is ask maintainer to rebase.
If both fail then indeed restarting a PR is the only way to go when you delete the fork and lose access to source branch.


[Snyk] Upgrade html-snapshots from 3.5.0 to 3.6.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade html-snapshots from 3.5.0 to 3.6.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 2 days ago, on 2024-03-22.

Release notes

Package name: html-snapshots

3.6.0 -<EMAIL_ADDRESS>

3.5.0 -<EMAIL_ADDRESS>

    from html-snapshots GitHub release notes

Commit messages

Package name: html-snapshots

4fce3c5 Merge pull request #678 from localnerve/rc-3.6.0
2b67a2f @ 3.6.0 -<EMAIL_ADDRESS>f9d4f11 Merge pull request #677 from localnerve/snyk-upgrade-5537be5b7de50546f16271f8d0780ac9
e700cb9 fix: upgrade html-snapshots from 3.4.1 to 3.5.0
72e1fe2 Merge pull request #675 from localnerve/snyk-upgrade-e11655f31c74e0f9df11e5644c4fa604
c076f9e fix: upgrade html-snapshots from 3.4.1 to 3.5.0
05d4387 Merge pull request #673 from localnerve/snyk-upgrade-b6fc637912d34ca85544485b5ad41e86
8a221dc Merge pull request #674 from localnerve/snyk-upgrade-c626969afe25adcd24b828c8856f8575
a5fa56d Merge pull request #672 from localnerve/snyk-upgrade-618ffafbdd99494ece99730f78663436
8920d8d fix: upgrade html-snapshots from 3.4.1 to 3.5.0
6da67c0 fix: upgrade html-snapshots from 3.4.1 to 3.5.0
7d5e395 fix: upgrade html-snapshots from 3.4.1 to 3.5.0
f5bcebb Merge pull request #671 from localnerve/snyk-upgrade-3922dfff9cae777de04e5d71be61407c
138e526 fix: upgrade html-snapshots from 3.4.1 to 3.5.0

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

coverage: 99.245%. remained the same
when pulling 8d9825797b1566dfbbd3a6e19933524498ee4cef on snyk-upgrade-59c31a978c6bb9d5e41560534890c286
into 22252e2212702a0d509f2532ab4145d1c727f156 on master.


Fix crash when import watch-only wallet and click send button

Resolve #182
This PR fix:

App crash when import only watch-only wallet.
App crash when click send button
App crash when import mixed account of watch-only wallet
App crash when delete wallet.

launching a fresh instance of cryptopower i get this error
$ go run . --network=testnet
Config file (/home/kennedy/.cryptopower/cryptopower.conf) does not exist. Using defaults.
2023-10-24 11:08:25.572 [INF] DLWL: Starting check and remove all dir of deleted wallets....
2023-10-24 11:08:25.572 [ERR] DLWL: can't read DCR root wallet type: open /home/kennedy/.cryptopower/testnet/testnet3/dcr: no such file or directory
2023-10-24 11:08:25.572 [INF] DLWL: Loaded 0 wallets
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x10de1ce]

goroutine 1 [running]:
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).GetCurrencyConversionExchange(...)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_config.go:141
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).initRateSource(0xc000511780)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:193 +0x10e
github.com/crypto-power/cryptopower/libwallet.NewAssetsManager({0xc00050f780?, 0x7?}, {0x186c689, 0x3}, {0x18a5e86, 0x25}, {0xc000446d20, 0x28}, {0x1871ea3, 0x7})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:172 +0x6c5
github.com/crypto-power/cryptopower/wallet.(*Wallet).InitAssetsManager(0xc000511700)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/wallet/wallet.go:81 +0xbb
main.main()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:77 +0x325
exit status 2

launching a fresh instance of cryptopower i get this error
$ go run . --network=testnet
Config file (/home/kennedy/.cryptopower/cryptopower.conf) does not exist. Using defaults.
2023-10-24 11:08:25.572 [INF] DLWL: Starting check and remove all dir of deleted wallets....
2023-10-24 11:08:25.572 [ERR] DLWL: can't read DCR root wallet type: open /home/kennedy/.cryptopower/testnet/testnet3/dcr: no such file or directory
2023-10-24 11:08:25.572 [INF] DLWL: Loaded 0 wallets
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x10de1ce]

goroutine 1 [running]:
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).GetCurrencyConversionExchange(...)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_config.go:141
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).initRateSource(0xc000511780)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:193 +0x10e
github.com/crypto-power/cryptopower/libwallet.NewAssetsManager({0xc00050f780?, 0x7?}, {0x186c689, 0x3}, {0x18a5e86, 0x25}, {0xc000446d20, 0x28}, {0x1871ea3, 0x7})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:172 +0x6c5
github.com/crypto-power/cryptopower/wallet.(*Wallet).InitAssetsManager(0xc000511700)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/wallet/wallet.go:81 +0xbb
main.main()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:77 +0x325
exit status 2

this seems to be on master as well, but this would need to be fixed in order to test this PR as i need to import a watch only wallet on a fresh install of cryptopower

launching a fresh instance of cryptopower i get this error
$ go run . --network=testnet
Config file (/home/kennedy/.cryptopower/cryptopower.conf) does not exist. Using defaults.
2023-10-24 11:08:25.572 [INF] DLWL: Starting check and remove all dir of deleted wallets....
2023-10-24 11:08:25.572 [ERR] DLWL: can't read DCR root wallet type: open /home/kennedy/.cryptopower/testnet/testnet3/dcr: no such file or directory
2023-10-24 11:08:25.572 [INF] DLWL: Loaded 0 wallets
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x10de1ce]

goroutine 1 [running]:
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).GetCurrencyConversionExchange(...)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_config.go:141
github.com/crypto-power/cryptopower/libwallet.(*AssetsManager).initRateSource(0xc000511780)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:193 +0x10e
github.com/crypto-power/cryptopower/libwallet.NewAssetsManager({0xc00050f780?, 0x7?}, {0x186c689, 0x3}, {0x18a5e86, 0x25}, {0xc000446d20, 0x28}, {0x1871ea3, 0x7})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets_manager.go:172 +0x6c5
github.com/crypto-power/cryptopower/wallet.(*Wallet).InitAssetsManager(0xc000511700)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/wallet/wallet.go:81 +0xbb
main.main()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:77 +0x325
exit status 2

this seems to be on master as well, but this would need to be fixed in order to test this PR as i need to import a watch only wallet on a fresh install of cryptopower

even though it's not within the scope of this PR, I'll fix it

seems a PR has been opened

@JustinBeBoy did you test this on a fresh install of cryptopower? cause that's how to detect the issue, it still happens
2023-10-24 17:38:42.444 [INF] DLWL: Loaded 0 wallets
2023-10-24 17:38:58.243 [INF] WLLT: Upgrading database from version 1 to 25
2023-10-24 17:39:00.939 [INF] DCR: Opened wallet
2023-10-24 17:39:00.945 [INF] SHWL: Created Watching Only Wallet
panic: assignment to entry in nil map

goroutine 39 [running]:
github.com/crypto-power/cryptopower/libwallet/assets/dcr.(*Asset).AddAccountMixerNotificationListener(0xc000648680, {0x1ff5578?, 0xc0000d4800}, {0x1877f8b, 0x8})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets/dcr/account_mixer.go:36 +0xf0
github.com/crypto-power/cryptopower/ui/page/root.(*OverviewPage).listenForMixerNotifications(0xc0000d4800)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/overview_page.go:1187 +0x22c
github.com/crypto-power/cryptopower/ui/page/root.(*OverviewPage).OnNavigatedTo(0xc0000d4800)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/overview_page.go:217 +0x22f
github.com/crypto-power/cryptopower/app.(*PageStack).Push(0xc003742d20, {0x1ffe6d8, 0xc0000d4800}, {0x2001700, 0xc000554090})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/pagestack.go:67 +0x538
github.com/crypto-power/cryptopower/app.(*MasterPage).Display(0xc000554090, {0x1ffe6d8?, 0xc0000d4800?})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/masterpage.go:46 +0x39
github.com/crypto-power/cryptopower/ui/page/root.(*HomePage).OnNavigatedTo(0xc000628000)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/home_page.go:137 +0x109
github.com/crypto-power/cryptopower/app.(*PageStack).Push(0xc0001c99e0, {0x1ffe648, 0xc000628000}, {0x2001750, 0xc0001c9a10})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/pagestack.go:67 +0x538
github.com/crypto-power/cryptopower/app.(*SimpleWindowNavigator).Display(0xc0001c9a10, {0x1ffe648?, 0xc000628000?})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/window.go:49 +0x39
github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).walletCreationSuccessCallback(0xc00157d500)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:636 +0x7a
github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).HandleUserInteractions.func3()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:554 +0x518
created by github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).HandleUserInteractions
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:517 +0x745
exit status 2

@JustinBeBoy did you test this on a fresh install of cryptopower? cause that's how to detect the issue, it still happens
2023-10-24 17:38:42.444 [INF] DLWL: Loaded 0 wallets
2023-10-24 17:38:58.243 [INF] WLLT: Upgrading database from version 1 to 25
2023-10-24 17:39:00.939 [INF] DCR: Opened wallet
2023-10-24 17:39:00.945 [INF] SHWL: Created Watching Only Wallet
panic: assignment to entry in nil map

goroutine 39 [running]:
github.com/crypto-power/cryptopower/libwallet/assets/dcr.(*Asset).AddAccountMixerNotificationListener(0xc000648680, {0x1ff5578?, 0xc0000d4800}, {0x1877f8b, 0x8})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/libwallet/assets/dcr/account_mixer.go:36 +0xf0
github.com/crypto-power/cryptopower/ui/page/root.(*OverviewPage).listenForMixerNotifications(0xc0000d4800)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/overview_page.go:1187 +0x22c
github.com/crypto-power/cryptopower/ui/page/root.(*OverviewPage).OnNavigatedTo(0xc0000d4800)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/overview_page.go:217 +0x22f
github.com/crypto-power/cryptopower/app.(*PageStack).Push(0xc003742d20, {0x1ffe6d8, 0xc0000d4800}, {0x2001700, 0xc000554090})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/pagestack.go:67 +0x538
github.com/crypto-power/cryptopower/app.(*MasterPage).Display(0xc000554090, {0x1ffe6d8?, 0xc0000d4800?})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/masterpage.go:46 +0x39
github.com/crypto-power/cryptopower/ui/page/root.(*HomePage).OnNavigatedTo(0xc000628000)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/home_page.go:137 +0x109
github.com/crypto-power/cryptopower/app.(*PageStack).Push(0xc0001c99e0, {0x1ffe648, 0xc000628000}, {0x2001750, 0xc0001c9a10})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/pagestack.go:67 +0x538
github.com/crypto-power/cryptopower/app.(*SimpleWindowNavigator).Display(0xc0001c9a10, {0x1ffe648?, 0xc000628000?})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/app/window.go:49 +0x39
github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).walletCreationSuccessCallback(0xc00157d500)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:636 +0x7a
github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).HandleUserInteractions.func3()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:554 +0x518
created by github.com/crypto-power/cryptopower/ui/page/root.(*CreateWallet).HandleUserInteractions
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/root/wallet_setup_page.go:517 +0x745
exit status 2

I have tested, seem like your wallet is the have mixer, I will test that case

clicking the send button for the first time caused a crash
however opening the app again and clicking the send button shows a modal.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x12eb8b4]

goroutine 10 [running]:
github.com/crypto-power/cryptopower/ui/page/send.(*Page).showBalanceAfterSend(0xc0000be300?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:455 +0x34
github.com/crypto-power/cryptopower/ui/page/send.(*Page).validateAndConstructTx(0x0?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:341 +0x65
github.com/crypto-power/cryptopower/ui/page/send.NewSendPage.func2()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:138 +0x1d
github.com/crypto-power/cryptopower/ui/page/send.(*destination).handle(0xc0050d1c00)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/send_destination.go:142 +0x65
github.com/crypto-power/cryptopower/ui/page/send.(*Page).HandleUserInteractions(0xc0000be300)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:510 +0x2bd
github.com/crypto-power/cryptopower/ui/page/send.(*Page).Handle(0xc000478a00?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:603 +0xbb
github.com/crypto-power/cryptopower/ui.(*Window).handleFrameEvent(0xc000191680, {{0xc146710844bbd07f, 0x126d34640b, 0x2f08680}, {0x3f800000, 0x3f800000}, {0x320, 0x28a}, {0x0, 0x0, ...}, ...})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:235 +0x171
github.com/crypto-power/cryptopower/ui.(*Window).HandleEvents(0xc000191680)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:206 +0x2b9
main.main.func3()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:110 +0x1d
created by main.main
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:108 +0x61b
exit status 2

clicking the send button for the first time caused a crash however opening the app again and clicking the send button shows a modal.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x12eb8b4]

goroutine 10 [running]:
github.com/crypto-power/cryptopower/ui/page/send.(*Page).showBalanceAfterSend(0xc0000be300?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:455 +0x34
github.com/crypto-power/cryptopower/ui/page/send.(*Page).validateAndConstructTx(0x0?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:341 +0x65
github.com/crypto-power/cryptopower/ui/page/send.NewSendPage.func2()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:138 +0x1d
github.com/crypto-power/cryptopower/ui/page/send.(*destination).handle(0xc0050d1c00)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/send_destination.go:142 +0x65
github.com/crypto-power/cryptopower/ui/page/send.(*Page).HandleUserInteractions(0xc0000be300)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:510 +0x2bd
github.com/crypto-power/cryptopower/ui/page/send.(*Page).Handle(0xc000478a00?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:603 +0xbb
github.com/crypto-power/cryptopower/ui.(*Window).handleFrameEvent(0xc000191680, {{0xc146710844bbd07f, 0x126d34640b, 0x2f08680}, {0x3f800000, 0x3f800000}, {0x320, 0x28a}, {0x0, 0x0, ...}, ...})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:235 +0x171
github.com/crypto-power/cryptopower/ui.(*Window).HandleEvents(0xc000191680)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:206 +0x2b9
main.main.func3()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:110 +0x1d
created by main.main
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:108 +0x61b
exit status 2

I can't reproduce it, please explain step by step and the extended public key you use

clicking the send button for the first time caused a crash however opening the app again and clicking the send button shows a modal.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x12eb8b4]

goroutine 10 [running]:
github.com/crypto-power/cryptopower/ui/page/send.(*Page).showBalanceAfterSend(0xc0000be300?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:455 +0x34
github.com/crypto-power/cryptopower/ui/page/send.(*Page).validateAndConstructTx(0x0?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:341 +0x65
github.com/crypto-power/cryptopower/ui/page/send.NewSendPage.func2()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:138 +0x1d
github.com/crypto-power/cryptopower/ui/page/send.(*destination).handle(0xc0050d1c00)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/send_destination.go:142 +0x65
github.com/crypto-power/cryptopower/ui/page/send.(*Page).HandleUserInteractions(0xc0000be300)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:510 +0x2bd
github.com/crypto-power/cryptopower/ui/page/send.(*Page).Handle(0xc000478a00?)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/page/send/page.go:603 +0xbb
github.com/crypto-power/cryptopower/ui.(*Window).handleFrameEvent(0xc000191680, {{0xc146710844bbd07f, 0x126d34640b, 0x2f08680}, {0x3f800000, 0x3f800000}, {0x320, 0x28a}, {0x0, 0x0, ...}, ...})
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:235 +0x171
github.com/crypto-power/cryptopower/ui.(*Window).HandleEvents(0xc000191680)
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/ui/window.go:206 +0x2b9
main.main.func3()
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:110 +0x1d
created by main.main
        /home/kennedy/Projects/src/github.com/cryptopower/cryptopower/main.go:108 +0x61b
exit status 2

I can't reproduce it, please explain step by step and the extended public key you use

After a lot of test, I have found the problem


ctr: dismiss progressbar on --debug

Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1282   +/-   ##
=======================================
  Coverage   23.58%   23.58%
=======================================
  Files          40       40
  Lines        4550     4550
=======================================
  Hits         1073     1073
  Misses       3275     3275
  Partials      202      202

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 0fa7658...b45fb98. Read the comment docs.


FTPS with TLS/SSL not working

FTPS with TLS/SSL not working at all  over the past few hours !!!
regular plain text (unsecured) FTP works, but I can't connect using FTPS
tried different combinations of settings , different computers, locations, ...

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

ID: 1506c34e-352d-15f6-73ea-3dbf8ce31b3c
Version Independent ID: cb469cf8-43e5-09fe-6b8e-ee714cf2f7cc
Content: Deploy your app to Azure App Service using FTP/S
Content Source: articles/app-service/app-service-deploy-ftp.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin;dariac

I'd recommend opening a support case or posting to the app service forums. It's difficult to troubleshoot in the comments section.

@zozzi I am not aware of any ongoing issues with FTP/S currently. If you are still having this issue, please reach out to us at<EMAIL_ADDRESS>with your subscription ID and the URL of this GitHub issue.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Feat: Let's make the website responsive

Describe the feature
The website is not responsive and it makes the user experience bad if used on different devices
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a gssoc-24-extd contributor
[X] I want to work on this issue

Already assigned to someone in issue #7
@Syed-Farazuddin

@RamakrushnaBiswal, there are many other pages that are not responsive.

Ok then @Syed-Farazuddin go for it make all pages responsive except landing page coz it's already assigned

@RamakrushnaBiswal  Working on it !!!

solved via #56


Moved session into backend/session and changed ownership

The session stuff is tied very closely to the DRM/libinput backend, so it didn't really make sense for it to be sitting at the top level of project. I moved it into backend/, where it can live alongside other similar things like wlr_udev (also very DRM/libinput specific).
Also, the user no longer needs to pass a wlr_session to wlr_backend_autocreate: it will create one on its own.
The multi backend has been modified to accept a wlr_session and a wlr_udev. It takes "ownership" of them, and will clean them up properly when it is destroyed (previously, we leaked the wlr_udev). If the multi backend is ever used for something that doesn't need a wlr_session/wlr_udev, it's perfectly safe to just pass it NULL.
This fixes the broken session issue I outlined in #28.
Again, the build system code is not committed. I'll wait for #27.
Currently, this breaks the ability to change VT in the examples, because the user doesn't have access to the wlr_session any more. We need to decide how the VT changing function and how the other backend-specific functions are going to look.

bump

I've rebased this against master and added the appropriate build files.
I also added a backend specific function wlr_multi_get_session which the examples now use to get access to the session so they can change VTs. The backend specific functions probably need to be fleshed out more and have more thought put into them, but currently this works are a temporary solution.
Now XKB_KEY_XF86Switch_VT_[0-12] is used, so Ctrl + Alt + F[0-12] is used to change VT.

Pushed a couple of small changes. Looks good otherwise, thanks!


proposal: Go2: read-only and immutability

Abstract
This document presents a solution on how to introduce read only and immutability support in go2. It is split into two parts:

A read-only language change that provides the expected compile-time guarantees with limited additional complexity or inconvenience to developers.
How immutability may be implemented on top of these language change, transparently to developers.

This document and it's ideas build up on the Go 2: read-only types proposal by Jonathan Amsterdam, which is referred to as 'the original' throughout. It focuses on the two points above while deliberately omitting the more general questions 'why is read-only needed?', 'how is read-only different to immutability?', 'why a read-only and not an immutable keyword?', etc. These are discussed in the original proposal and follow up comments and don't need to be repeated here. I encourage anyone reading this proposal to also look at this previous one for additional context, although this one should be understandable on its own.
Other posts from which I may borrow or get inspiration are Evaluation of read-only slices, Go - Immutability or Why Const Sucks.
Language changes
The ro keyword
The fundamental change in this proposal is the ro (read-only) keyword, taken in almost the same form as in the original proposal. Some highlights that still hold:

Permissions are transitive: a component retrieved from a read-only value is treated as read-only.

There is an automatic conversion from T to ro T.

This proposal is concerned exclusively with avoiding modifications to values, not variables.

A value of read-only type may not be immutable, because it may be referenced through another type that is not read-only.

On the other hand, the ideas around 'Permission Genericity' in the original proposal are dropped (as well as the ro? syntax).
The meaning of ro applied to interfaces is also subtly changed. In the original it is described as:

If I is an interface type, then ro I is effectively the sub-interface that contains just the read-only methods of I.
If type T implements I, then type ro T implements ro I.

In this proposal the meaning is slightly different - for an interface I, ro I contains a ro T for T implementing I. If type T implements I, then type ro T implements ro I, and vice versa. Additionally, if all methods in I have a ro receiver and T implements it, then ro T also implements I.
Anonymous functions are not mentioned in the original proposal, but this one regards them as a write operation and therefore not callable in ro form.
relaxed typing rules for ro qualifiers
The introduction of the ro keyword is intended to bring all the compile-time read-only guarantees at the minimum cost to developers. To achieve it, this proposal departs from the original one and establishes that the typing rules for ro-qualified types are somewhat relaxed, as in many contexts they are interchangeable with their non-ro form. Conceptually, ro-qualifying introduces compile time restriction on what operations are allowed but are largely indistinguishable at runtime.
It is a given a T may be automatically converted to ro T, but not in reverse. Similarly special allowances are introduced for functions and methods, not otherwise allowed in go.
In more detail:
Any ro-qualified argument in a function may be given a non-ro argument:
func foo(ro X) {...}
x := X{}
foo(x) // legal

Any method requiring a ro-qualified receiver may be called on a non-ro receiver:
type foo struct {}
func (_ ro foo) Bar() {...}
f := foo{}
f.Bar() // legal

Any function may be converted to another similar function with some ro-qualifying argument(s) removed:
func foo(_ ro X) {...}
f := foo          // type func(ro X)
var _ func(X) = f // legal, type func(X)

Any method with a ro receiver or argument may implement a method without it:
type foo struct {}
func (_ ro foo) Bar1() {...}
func (foo) Bar2(_ ro X) {...}

type I interface {
    Bar1()
    Bar2(X)
}
var _ I = foo{} // legal

Similar rules apply to return values - a function or method with a non-ro return value can be converted or used to implement one where the return value is ro-qualified. The same rules apply to maps, arrays, slices, channels, i.e. []X may be used as an argument to []ro X, etc. Overall, the principle is that inputs may be relaxed to permit more general forms (non-ro), and outputs may be tightened to produce more specific forms (ro).
By having ro-qualifying not produce fully independent types the need for duplicate implementations (ro and non-ro forms) is averted and the read-only can be supported with very little additional complexity or work by the developer.
Note this is not overloading as only a single function or method may exist with a given name, and the same implementation will be used regardless of the ro-ness of the arguments.
To support this language changes the linker must be relaxed to allow linking when the function types differ only in ro-ness as described above.
Interface type assertion and ro
Fundamentally, the above ro syntax allowing seamless conversions around ro-ness relies on the runtime form of a type X being identical to that of ro X. This is trivially true for non-interface types, as in the go model and unlike many other languages the type is not embedded in their runtime value. This can even be trivially extended to interfaces with regards to methods being called - calling a method on a ro I can be implemented identically to calling the same method on I. The itab can be reused and the same function will be called regardless, while non-ro receiver methods can't be called in the first place so need no special handling. However, type assertion does not immediately follow. Consider the below:
i := interface{}(X{})  // represented in runtime as {type of X, value}
j := ro interface{}(i) // type ro interface, has same runtime representation as above {type of X, value}. The value within it though is not X but ro X

To satisfy this, asserting of ro-qualified interfaces to non-ro qualified struct is illegal. When asserting a ro I to a ro-qualified struct ro X the the runtime must confirm the runtime type within the interface is X, even though it is returning a ro X. For example:
i := interface{}(X{})  // X in an interface
j := ro interface{}(i) // ro X in a ro interface, represented in memory as {type of X, value}
_, _ = j.(X)           // illegal, ro interface can't be a non-ro struct
_. ok := j.(ro Y)      // legal but false, the runtime type in the interface is X not Y
_. ok := j.(ro X)      // legal and true, the runtime type in the interface is X which is implicitly ro X

The assertion of ro-interfaces to other ro-interfaces is fundamentally the same as that of non-ro interfaces, just in ro space:
x := X{}           // assume X implements interfaces I1 and I2, but not I3
i := ro I1(x)      // type ro I1, represented in memory as {type of X, value}
_, ok := i.(ro I3) // legal but false, X does not implement I3
_, ok := i.(ro I2) // legal and true, X does implement I2

There is also the special case of interfaces with ro-only receivers, which will be implemented by types in both ro and non-ro form. The fundamental property they must guarantee is that a ro T assigned to one such I may not be asserted back to a T, nor be asserted to any interface a ro T would not satisfy. Since both T and ro T may be contained by such an I and yet the distinction be made by the runtime, they must be represented differently within the interface's type value at runtime and interpreted correctly while asserting. For example:
// Foo has non-ro receivers
type Foo interface {
    Bar()
}

// RoFoo has only ro receivers
type RoFoo interface {
    ro Bar()
}

// foo implements Foo and RoFoo. ro foo also implements RoFoo but not Foo
type foo struct{...}
func (_ ro foo) Bar() {...}

var f Foo
f = foo{}
_, ok := f.(ro foo) // illegal, does not implement it
f = ro foo{}        // illegal, does not implement it

var rf RoFoo
rf = foo{}          // foo in a RoFoo, represented in memory as {type of foo, value}
_, ok := f.(ro foo) // legal but false, runtime type is foo
_, ok := f.(foo)    // legal and true, runtime type is foo

rf = ro foo{}       // ro foo in a RoFoo, interface representation in runtime is {type of ro foo, value}
_, ok := f.(ro foo) // legal and true, runtime type is ro foo
_, ok := f.(foo)    // legal but false, runtime type is ro foo

To support this language changes, the runtime must be modified to correctly implement this new type asserting rules.
Remarks
The empty interface
The empty interface interface{} still matches everything and can always be asserted back to the exact type that was assigned to it. No change in that respect, it can still be used as a reversible wildcard type match.
Migration
These change, in it's rawest form, is backwards compatible in that existing go code will work for it.
However many methods, types and interfaces should be modified to reflect the new ro functionality. A key aspect though is that they could be migrated somewhat gradually with modest breaking changes at each step. In particular note that there is no cost in making the arguments of functions ro when not in breach of read-only rules in the first place (including receivers for methods). This way, the functions can begin to be updated before the interfaces they implement are, and the interfaces themselves can be updated in batches based on their dependencies.
The case for mutable keyword
Adding ro can be a very limiting restriction and an exception to the rule may be wanted, such as a mut (mutable) keyword. This is done in some other languages with similar features. I believe adding this is a bad idea but it is worth debating given its implication for establishing best practices around ro.
ro []ro T vs ro []T
For slices I have taken the ro syntax of the original proposal, namely []ro T to mean 'slice of read-only Ts' and ro []T to mean 'read-only slice of read-only Ts'. Alternatively, ro []ro T could take that meaning, and ro []T becomes 'read-only slice of Ts'. While more verbose, this syntax is more expressive and powerful. I believe either this or comparable solutions should be explored, and possibly also for maps and arrays.
Immutability
Transparent feature on top of ro
Consider the following:
IF the compiler can assert all references to a ro variable are also ro themselves, it can treat the variable as immutable
Note here the reference to compiler - it is not the developer who decides if a ro variable is, or even might be, immutable, but the compiler. The immutable property is completely transparent to developers and is irrelevant in all other regards other than performance - the logic of a method is identical regardless. To achieve this, the compiler must effectively do escape analysis on ro's - any non ro-escaping ro variable can be treated as immutable, but one that ro-escapes can't. This is very similar to go's heap escape analysis - whether a variable ends up in heap or stack - which is up to the compiler and irrelevant for all (non-performance) purposes to the developer.
In other languages immutability often means the memory is only written to once (during initialisation) and remains unchanged until reclaimed (const in C, final in java, etc). This is not the case in this proposal - non-immutable memory may become immutable after it has been initialised or even modified, and mutable ro variables may coexist and reference the same memory as immutable ro variables (though no non-ro variables). In this sense immutable ros are not like const (in the current go sense, not referring to C-style const).
Initialisation
Initialising immutable ros (via ro return statement)`:
// an immutable ro
func foo() /* im */ ro []int {
  out := []int{1}      // not immutable, not even ro
  out = append(out, 1) // not immutable or ro (and in fact is being modified!)
  return out           // ro AND immutable, despite having been non-immutable (and non-ro) before. Has NOT been deep-copied
}

// an immutable ro, which may be referenced by another ro (mutable or not, irrelevant here)
func bar() /* im */ ro []int {
  // note ro argument
  auxFunc := func(x ro []int) {...}

  out := []int{1} // not immutable, not even ro
  auxFunc(out)    // out escapes, but in ro form
  return out      // ro AND immutable, despite having been non-immutable (and non-ro) before and being referenced by another ro. Has NOT been deep-copied
}

// ro but non-immutable, may have non-ro references remaining
func nonImmutable() /* mut */ ro []int {
  auxFunc := func(x []int) {...} // note non-ro argument

  out := []int{1} // not immutable, not even ro
  auxFunc(out)    // out escapes in non-ro form
  return out      // ro but NON immutable as it may be referenced by a non-ro. Has NOT been deep-copied
}

Initialising immutable ros (via non-ro return statement and casting afterwards):
// non ro-escaping return value
func foo() []int {
  out := []int{1}
  return out // not ro but non ro-escaping
}

var _ /* im */ ro []int = foo() // immutable as return value not available after assignment

x := foo()
var _ /* mut */ ro []int = x // mutable as x is ro-escaping this assignment
// some non-ro use of x

// ro-escaping return value
func bar() []int {
  auxFunc := func(x []int) {...}

  out := []int{1}
  auxFunc(out) // causes ro-escaping
  return out   // not ro and ro-escaping
}

var _ /* mut */ ro []int = bar() // mutable as return value is already ro-escaping

Implementation
As stated before, ro is primarily a means of restricting what operations are allowed, but is virtually irrelevant at runtime. Immutability is the exact opposite, it is transparent to the developer but modifies how the code is executed. For this reason, while ro-qualified types are separate types, immutability is not. Instead it is an optimisation built into the binary, whereby function calls with inputs known by the compiler to be immutable may be linked to alternative, optimized implementations of the same function. This is similar to overloading in that a single function may have multiple implementations, but differs in that it is not the developer but the compiler that picks which one is used.
I am not certain my understanding about the go runtime, compiler and linker are entirely correct here, please share if you know better.
Some changes to both the compiler and the linker would be needed to support this 'immutability from read-only' feature'. In particular methods with ro inputs (methods that have some ro argument or receiver) would require the compiler creating multiple implementations, potentially one for each ro combination. It would then be up to the linker to decide which is called based on the immutability of the arguments and target (as known at compile/link time). For example:
func foo(ro []int) {...}

would be compiled in 2 separate ways, identical in all ways except the immutable one may include the additional optimisations:
/* compiler pseudo-code, not actual go syntax */
// compiler: foo#0 func(mut ro []int) {...}
// compiler: foo#1 func(im ro []int) {...}

It would be up to the linker to link to the right one:
foo([]int{1}) // uses immutable implementation foo#1

x := []int{1}
foo(x) // uses mutable implementation foo#0
// some other non-ro use of x

This property must extend to interfaces. There will be nothing in the runtime value of an interface that states it's immutability state, hence the compiler/linker must be the one that decides again. I think this can be done by modifying the use of itab (or a similar new type, say itab2) to support not just multiple types but also multiple mutability-status on these types. When a ro input method is called on an interface the type resolution getitab (or a similar new method, say getitab2) will be called with some additional argument that denotes it's immutability state, imState. That way it can resolve the correct method to call, including immutability status. For example:
type foo struct {}

/* compiler pseudo-code, not actual go syntax */
// compiler: foo:Bar#0 func(mut ro []int) {...}
// compiler: foo:Bar#1 func(im ro []int) {...}
func (foo) Bar(ro []int) {...}

type foo2 struct {}

/* compiler pseudo-code, not actual go syntax */
// compiler: foo2:Bar#0 func(mut ro []int) {...}
// compiler: foo2:Bar#1 func(im ro []int) {...}
func (foo2) Bar(ro []int) {...}

type Foo interface {
    // compiler: itab2 [imState][type]
    //           itab2 [0][0] = foo:Bar#0
    //           itab2 [0][1] = foo2:Bar#0
    //           itab2 [1][0] = foo:Bar#1
    //           itab2 [1][1] = foo2:Bar#1
    Bar(ro []int)
}

f := Foo(foo{})

// immutable
x := ro /* im */ []int{1}

// immutable input => imState=1.
// imState is a new argument to getitab2 (otherwise equal to getitab)
// the value of imState known at compile time and is different constant for each separate form of a ro input method (#0, #1 in my syntax).
// the below interface therefore calls
// getitab2(*interfacetype, *_type, bool, imState=1)
// which then resolves to the immutable form of the specific method, i.e. either foo:Bar#1 or foo2:Bar#1
// given the type of f (this is still, of course, evaluated at runtime) it calls foo:Bar#1, the immutable form of the method
f.Bar(x)

Note that the below only has one ro argument, but of course methods may have multiple ones, and the receiver itself may be ro, sogetitab2 must support different values for imState. How best to define those I leave as a future task and should be explored more carefully.
Remarks
How meaningful are the performance gains?
The purpose of immutability is to provide performance gains by avoiding unnecessary memory reads. How significant those gains are is not obvious, though. It should be investigated before commiting to this changes.
Binary bloating
If all the above changes are implemented, these may have the unintended consequence of bloating the binary as functions may have multiple implementations. Immutability is, however, at the compiler/linker's discretion and so it may decide to drop immutable implementations of methods that do not get called often or are otherwise large and provide little gain, and instead use the mutable forms.
Compile time impact
Build time of individual packages may be negatively affected as multiple implementations may need to be built for a single method, as well as an additional step of escape analysis of ro. Longer build time for binaries will inevitably follow.
Benchmarking and immutability
Given immutability is transparent to the developer but improves performance, it may be a double edge sword when running benchmarks. It is possible for a benchmark to be run on immutable inputs but then the binary does not (or vice-versa), present misleading results with little visibility to the developer.
Some risk mitigation best practices should be explored.
Immutable parameters
So far immutability has covered arguments to functions, but it should also cover parameters held within other types. For example, in the below, can parameter t be considered immutable?
type X struct {
    t ro T // immutable or mutable?
    ...
}

It is generally impossible for the compiler to identify where such X was initialised or modified, and therefore must assume the parameter is mutable. An exception can be made when all writes to such parameter are known to set immutable values, in which case the parameter can be considered immutable. This can only realistically be done for private members, and even then while the parameter may have an immutable value, it may still be changed for another immutable value. For example:
type X struct {
    t ro []int // immutable, because is private and all writes in the package set an immutable rp []int
    ...
}

x := X{
    t: []int{1,2} // t set to immutable slice
}
func(_ ro []int) {...} (x.t)  // called in it's immutable form, x.t is immutable
func(_ ro *[]int) {...} (x.t) // called in it's mutable form, &x.t is mutable
x.t = []int{1} // legal, t is re-set to another immutable slice

This makes the immutability of parameters a fairly limited property. One way to make it more powerful would be to allow ro to be applied to parameters in the following way:
type X struct {
    ro t []int // this would mean a read-only []int which can't be overwritten with different ro []int value. Also &x.t can now be considered immutable
    ...
}

For reference, this is similar to 'avoiding modifications to values, not variables' mentioned in the original proposal, but applied to parameters not variables.
Although this would also require restrictions on how dereference is done in go, i.e.
x := X{
    t: []int{1,2} // t set to immutable slice
}
xPtr := &x  // is still type *X, not ro *X
*xPtr = X{} // has to be made illegal, this overwrites x.t

This would be a significant change to the language with many breaking changes, so should not be seen as a requirement of this proposal.
Immutability Check
There may be situations when the runtime wants to validate the immutability state of a variable. A public method may be added to the runtime package for this purpose:
package runtime

/* compiler pseudo-code, not actual go syntax */
// compiler: IsImmutable#0 func(mut ro interface{}) bool {return false}
// compiler: IsImmutable#1 func(im ro interface{}) bool {return true}
func IsImmutable(ro interface{}) bool

The special thing about this method is that, while for all other methods immutability is considered merely a performance feature, in this the output actually changes. The mutable form of the function returns false, the immutable true.
This allows for the syntax below:
func  ToImmutable(x ro []int) /* im */ ro []int {
    if runtime.IsImmutable(x) {
        // input is immutable, no change needed
        return x
    }

    // input not immutable, deep-copy it
    copied := make([]int, len(x))
    copy(copied, x)
    return copied
}

Which in turns gives the option to actually enforce immutability to any given API (at the cost of deep coping in the inputs aren't immutable). Also note that the output of IsImmutable will be known at compile time anyways, so a smart compiler will inline it and simplify methods like ToImmutable.
For the same reason it could be added as a line directive which will fail compilation when it doesn't hold, say:
//go:immutable
var _ /* im */ ro []int = x

This could in turn provide the same (if more verbose) benefits of other proposals introducing immutable types. While I would make the case that this directive shouldn't be abused, it does ensure that there is support for it for the few times immutability is a serious concern for an API.
string vs  ro []byte
An immutable ro []byte is almost identical to a string, and opens  up for conversion between one and the other without any need for memory allocation and deep copying:
// string to ro []byte
s := "Hello World" // type string
_ = ro []byte(s)     // type ro []byte, is immutable. Does not require deep copying, the SliceHeader can use the same Data as that held by the string

// ro byte to string
imB := ro []byte{'a'} // immutable, ro []byte
_ = string(imB)       // string, does not require deep copying as the  input was immutable
mutB := /* assume some mutable ro []byte*/
_ = string(mutB)     // string, does require deep copying as any other []byte would in current go

This makes the conversion between string and ro []byte effectively free, and that from ro []byte to string potentially free, but depends on context.
Note this exact comparison is discussed extensively in Evaluation of read-only slices
Conclusion
Introducing read-only types to go2 has multiple advantages for go development in the form of clearer APIs and safer code. I believe the performance gains of immutability is also a feature of read-only types, even if it hadn't been recognised as such before. The ideas introduced or expanded in this proposal are not complete, detailed or final, but target much of the concerns from the community and go project maintainers around introducing read-only types. Overall I hope this will lead to new discussion and maybe tilt the balance towards having read-only support added to go2.

I'm personally a fan of keeping read-only-ness as a property of function parameters rather than of types as a whole. We lose a little bit of flexibility but it makes sure that the Go type system stays nice and simple.
That being said, while I'm not exactly a huge fan, I'm not opposed to this either. I think some of it gets a bit complicated when we get into how these interact with interfaces. It seems to mostly be caused by polluting the simplicity of the Go type system.
I think it's quite clear what ro []Foo means at first glance, but it's not at all clear or intuitive what interface { ro Foo() } means.

Oh I'm aware it's needed, I just don't think it's clear. It looks like the ro applies to the whole function rather than just the receiver.
Either way it's just syntax, so if there is a better way to do it, it should be easily changable.

I think some of it gets a bit complicated when we get into how these interact with interfaces.

Also by this, I didn't only mean with the example I gave. Just the general logic (which is very sound if I may add, just confusing) behind which types can implement what interfaces can get very confusing, and as I said, this is because by adding this feature, we would be adding a layer of complexity on Go's type system.
Again I'm not super against this proposal or anything, just stating my main criticisms.

@JavierZunzunegui
In your last example, rox.Bar() is invalid for the type ro x doesn't has the method Bar.

@go101 thanks for spotting, updated above


Index file templates

Currently site index files have the name of the project. Change this so they are called index.jinja
Rendered index.jinja files should not be inside an index folder. IE index/index.jinja The should render as index.html in the relevant content directory.

closed by #42


Can't reference this package with require

require('bootstrap-grid') doesn't load anything in Node.js, Webpack, Browserify style environments.  I have a pull request with a simple package.json update that fixes this problem.
I'll star if this gets fixed.
Thanks!

Closed by #1


Manually registering PointClouds using optimized RT(rotation-translation) from 2d lidar cartographer

Hello sir,
I am using 2d lidar cartographer and getting a good 2d map.
Now I also have PointCloud topics along with the lidar topic in my bagfile, so I would like to register the PointClouds based on the RT which I got from pbstream file at the end of the run.
I would be require to post process on the obtained PointCloud based on the my deep learning framework, so I need independent access to PointClouds and the corresponding RTs between them.
Could you guide me to the part of the cartographer_ros codebase where it sample the lidar scan to use as a node for graph slam, so that I could extract the corresponding PointCloud at that particular timestamp?
Please let me know if it is possible?
Thanks

You have sparsified versions of the observed scan inside a node's ConstantData. If you want the full cloud, you will unfortunately have to process the source dataset bag again using the poses from the serialized mapping result (in a .pbstream). Cartographer's assets_writer does exactly this to perform mapping with known poses.
Or, you could hack Cartographer to store the full point cloud inside the node constant Data here. This was actually stored it at one point, but it was removed in order to reduce memory consumption (I was trying to oppose this, but was not successful :-) ).

Hi,
I would use your first approach, currently I am using the tool pbstream_trajectories_to_rosbag_main, to get the rosbag file of the optimized tf topic stored in pbstream.
I would run this new bagfile along with my old bagfile containing PointClouds topics and get the synchronized topics and register it accordingly. I would update if any any issue arrives.
Thanks

Do you have success publishing other pointclouds with the corrected trajectory, that are in the same bag with other topic name?

Hi,.
I haven't been out for sometime, so haven't register pointclouds. But I got the bagfile containing the optimized trajectory from cartographer having the same timestamp as the original bagfile. So this could be registered manually using synchronisation (filter) ros library and PCL.

Thank you for the answer. Is it possible to describe more on how to use this "pbstream_trajectories_to_rosbag_main" ? Do you have a sample file (.launch) on how to use it?

First check whether you have the binary for pbstream_trajectories_to_rosbag_main in your machine, if not then build cartographer_ros again from the master branch.
After building you can directly use the binary.
To search for any file :-.
sudo find / -iname "pbstream_trajectories_to_rosbag_main"

Hi @ojura ,

Could you tell whether the output bagfile from pbstream_trajectories_to_rosbag_main, contains the last optimized trajectory when the cartographer finishes or it contains the trajectory when the cartographer was running(i.e unoptimized)?
I tried to extract the trajectory and register the PointClouds from output bagfile(from pbstream_trajectories_to_rosbag_main), here is the result :

Code for registering pointclouds from trajectory from output bagfile.

Both, it is optimized while Cartographer is running.
Also, have a look at the tuning guide - you have local SLAM making rough errors and should try tuning that first. It is futile to try optimizing if you have such bad local quality - optimization is meant to eliminate slowly accumulating drift in large loops, not to correct rough local errors.

Ok, first I would try to get good local maps, then try to get optimized trajectory. I think my robot have very bad odometry, so removing it may improve the maps. And then would comment on the optimized trajectory.
Thanks

Hi @ojura ,
Could you tell me some parameters to tune local slam . I am only using Lidar sensor (as my wheel odometry is faulty). The trajectory from cartographer is sometimes coming to be in backward direction, but in reality robot is moving forward(may be repeated rack space).  Here is a video showing the problem.
And here are my configuration files.
Is it possible to tune the parameters for good local slam or problem is because of the repeated structures in my environment?

I can see that your lidar can have problems with movement observability because it sees a long monotonic hallway with no features... I'd say that you need a wider-fov, longer range lidar. Or an environment with more features. Unfortunately, tuning local slam is more or less lots of trial and error, and I cannot give you specific advice. Try enabling the online correlative scan matcher. The 2D TSDF scan matcher might also be of help, I have not used it though.


New feature with an alert manager

Now, we have a smart alert manager to reduce the alerts by concatenating them together,

At least n anomalies to trigger an alert;
Tolerance to concat the anomalies.

Besides, I fix some bugs with spot detector.

@Superskyyy Is this project moving  into alerting rather than baseline calculation?

@Superskyyy Is this project moving into alerting rather than baseline calculation?

No, alerting is the least important at the current stage, we rather focus on visualization and expandability to let users make sense of the AIOps output.
I think the idea is to have this (AlertManager) threshold to suppress continuous anomalies and false positives as algorithms cannot be 100% correct at all times. So merging the positives will reduce noise. The alert  here will not directly send notifications to users via any channels according to the design, it should only serve as a mechanism to help annotate metrics in the BoosterUI.
Future PRs on the integration with SkyWalking will enhance this part.

I will review this PR tomorrow. Bit busy moving to a new place.

@wu-sheng @Superskyyy
Exactly, here is an example shows how the continuous anomalies from groundtruth affect the evaluation of our detectors.
Some groundtruth label a range of data as anomalies (red marker of the blue line in the pic). They always contain sort of normal data who have low anomaly scores (the black part in the pic). However, this is not a limitation of the detectors, we need a alertmanager to group the continuous anomalies into one "anomaly event".

Please resolve the conflict and address CI.

Please help me to add a     - '**/*.log' to this line https://github.com/SkyAPM/aiops-engine-for-skywalking/blob/b162918fb2cd07e79ee496c27b4639d8220e8eac/.licenserc.yaml#L31
I forgot to add one last PR to ignore log files.

Please run the linters on your local dev environment first, by make lint, you can fix many of the things like quotes by invoking make lint-fix.

Please run the linters on your local dev environment first, by make lint, it should output the exact same problems as the CI indicates. You can fix many of the things like quotes by invoking make lint-fix.

Finally ..... finished
So strict linter 😭

Please run the linters on your local dev environment first, by make lint, it should output the exact same problems as the CI indicates. You can fix many of the things like quotes by invoking make lint-fix.

Finally ..... finished
So strict linter 😭

It's the same used for skywalking-python code, for the purpose of facilitating good coding habits. The codebase will get very messy to understand for new contributors if we don't write properly, especially in Python. Please stick to the conventions. 😄

LGTM


An app called "--help" cannot be deleted

During a Cloud Foundry new users training day run by @DanielJonesEB, @jpluscplusm encountered a scenario where someone accidentally pushed an app called "--help". Running cf delete --help is impossible. We are not trolling! 😂 😂 😂
CLI Version
The latest installable version as of June 23, 2018.
CC API Endpoint Version
2.114.0
Platform & Shell Details
Using hosted CF on Pivotal Web Services.

Perhaps the string --help should not be permitted as a name you can give to an app :trollface:

In this instance, the name of the app had a single - prefix: -help.
These cf-delete tactics failed:
$ cf delete -help
$ cf delete '-help'
$ cf delete "-help"
$ cf delete \-help

These CLI tricks failed:

Renaming the app with cf rename -help app-to-delete
cf curl to delete the app via its GUID: cf app -help --guid failed, so we had no GUID to call cf curl with.

This probably would have worked, but we only thought of it later:
CF_TRACE=true cf apps | grep -i guid
... and then using the GUID in a cf curl.
We actually resolved the problem here by renaming the app via the WebUI, and then deleting it via the CLI.

Thanks @deniseyu we have a few other stories whereby users are using - or semicolons when they really should not be - this is relative low priority for us but at some point in the future will be adding forbidden characters. Thanks.

Hello @deniseyu - this issue can't be reproduced on the current v6 or v7 lines (unable to push an app called --help or -help so I'm going to close this.
Please comment and reopen if I've missed something and this issue still applies to the v7 CLI.


feat: standardize backup suffix between plugin backup and scheduledbackup

Closes #2882

/test limit=local

/test limit=local

/test limit=local

/ok-to-merge