kconfig: Decode Kconfig sources as UTF-8 instead of as LC_CTYPE

Decode Kconfig sources as UTF-8 instead of decoding them according to
the system locale (which might be ascii-only).
This resolves an issue that can be reproduced like this:
$ export LANG=C
$ echo '# Sebastian Bøe' >> ~/zephyr/Kconfig
$ build_any_zephyr_app
See the Python comment for details.
Signed-off-by: Sebastian Bøe<EMAIL_ADDRESS>

Looks good, is this present upstream and/or in our Kconfig fork?

I think that Kconfiglib is also used by the documentation, should we change it there too?

"Looks good, is this present upstream and/or in our Kconfig fork?"
This is a modification to a file that is maintained purely in Zephyr. It is not a part of any kconfiglib fork (I believe).

This is a modification to a file that is maintained purely in Zephyr. It is not a part of any kconfiglib fork (I believe).

You are right, I deleted my comment. Sorry for the noise

"I think that Kconfiglib is also used by the documentation, should we change it there too?"
Really? I was not aware, I'll do some grepping to make sure this patch is applied everywhere it should be.

Codecov Report

Merging #6716 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6716      +/-   ##
==========================================
+ Coverage   54.07%   54.07%   +<.01%
==========================================
  Files         442      442
  Lines       41916    41916
  Branches     7970     7970
==========================================
+ Hits        22665    22666       +1
+ Misses      16051    16050       -1
  Partials     3200     3200

Impacted Files
Coverage Δ

kernel/posix/pthread.c
69.5% <0%> (+0.5%)
:arrow_up:

Continue to review full report at Codecov.

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

"I think that Kconfiglib is also used by the documentation, should we change it there too?"
Done.


3 suggestions for your project..

Hi,
just some ideas about your project..
note expect #1 other two may be better to investigate once project is more mature..

reusing existing open source projects for DXBC->SPIRV translation..
just a suggestion as you seem to be reimplementing DXBC to SPIRV shader conversion from scratch..
for me seems a waste of your time (please forgive me if mistaken) and would be better to reuse at least one of these two projects:
a) Reuse Wine source code : supports DXBC to GLSL and is someway battle tested on modern D3D11 games
(should then get SPIRV by using Khronos glslang to go GLSL->SPIRV)
notes: still lacks some byte codes related to shader linking feature, fp64 optional ops, but they aren't massively used.
PROs:
*if you end implementing missing opcodes vs Wine then wine can benefit from your work..
CONs:
*GLSL output has to be massaged for Vulkan GLSL specific restrictions?
*Get knowledgeable about Wine code base
*Wine licenses issues?
perhaps personally would choose that..
b) reuse Unity HLSLCC compiler  (https://github.com/Unity-Technologies/HLSLcc)
you will also need glslang using this path..
CONS:
*produces "GLSL for Vulkan consumption (as input for Glslang to generate SPIR-V)" so no potential problems like Wine GLSL output from DXBC..
*altough well tested in Unity shader codebase,perhaps not robust as Wine shader translation
PRO:
additionaly supports Metal language output support (supports vert,frg,compute.. Metal tesselation should be coming soon (now that Unity 2018.1 roadmap mentions Metal tesselation support)..
so if someway later this project gets forked onto DXMetal shader conversion should already be solved someway..

Test Macos support using MoltenVK (vulkan to metal translator)..
(note: this is not testable right now..)
Wine staging right now supports Vulkan on Linux and with some patches could support could be brought to Macos by linking to MoltenVK Vulkan library..
then we can see how your project Vulkan code plays with MoltenVK and workaround current MoltenVK limitations and perhaps provide feedback to MoltenVK author from improvements..
I plan on doing my testing on my way as soon as I get patches for Wine Vulkan Macos working..

Windows Visual studio support..
past week, with minor changes I got your project to compile with Visual studio 2017 some days ago..
I generated projects using meson flag: --backend vs2017
then from IDE fixed the issues one by one if I remember the most frequest were missing #include  on some files and the hardest one were to modify my Windows SDK d3d11.h and dxgi.h headers to include declspec(exportdll) as needed to match your function implementations of
D3D11CreateDevice,D3D11CreateDeviceAndSwapChain,CreateDXGIFactory1,CreateDXGIFactory..

just my three cents.. :-) keep up your great work 👍

Thanks again for the input.

It is true that the shader compiler is the elephant in the room here. I'll have to think about what to do with it. Although using wine's DXBC->GLSL without modifications is not an option, it might be possible to use its frontend and implement a SPIR-V backend that takes the Vulkan peculiarities into account - but then again it would be a lot of work.
I'm a bit reluctant to add more third-party dependencies to the project and give up the direct DXBC->SPIR-V translation at the same time, it is the most elegant and potentially the most robust solution, but it obviously requires a lot work and a lot of testing.

No objections if someone is willing to maintain it, at least when the project has matured. Right now I don't think it's worth the effort.

Nice to hear that you actually got it to compile. I'm more than willing to officially support VS2017 and Windows at this point as it can help development (particularly with testing against native Windows Dx11), but I haven't managed to compile it myself yet. Was there anything else you had to set up besides fixing the code?
As for the dllexport problem, that can be solved by renaming the functions in the code and providing a DEF file to export them with the proper symbol names.


Add tip counter

Please connect linter!

Not clear what to do in the initial screen, sumCountTextField should be focused so the keyboard will be up.

The app doesn't show the bar in landscape mode (Command + ➡).
Option 1: figure out an interface for landscape for every phone
Option 2: disable landscape rotation for the app (since the samvlu design does not specify landscape)

App crashes if no value is specified and Done clicked

Great idea with the Sum struct! 👏
How about adding couple unit tests to this project? I can help.


Controlled components not possible

See https://github.com/DenisKolodin/yew/issues/233#issuecomment-457886532 for context.
Essentially, the desired behavior is: if an edit for a field (e.g. an input or text area) is 'rejected' (i.e. not applied to the model), the render should not update. In react this is known as 'controlled components'.
In seed you can test this by commenting out this line from the todomvc example and then trying to edit an item. Because the internal state isn't changing, arguably neither should the render. Unfortunately, it does.
React solves this by restoring state after a change event (described on the linked issue).

Published in v0.2.5

I suspect the approach I used is fragile: It checks if input/textarea/select els have an "input" event, and if not, add one which reverts them to their prev value. This might be missing some use cases.

Overall: My understanding is that the purpose of this is to keep input elements from getting out of sync with the model.

But currently it doesn't keep the model and input element in sync if they have an "input" event. I just bumped into this.
To keep it in sync it would be necessary to have a listener checking the input value property (set by the user listener) and setting the actual value with input_el.set_value(value), right?

In order to keep the "value" property set by the user in sync with the render we could get the value property and use set_value right after the user event handler.
I have it implemented here:
https://github.com/tiberiusferreira/seed/commit/d14e778bc92fcb6327f76c1e43dba4ceed83349d
I tested on Safari, Firefox and Chrome.
For the case when the input field was invalidated (such as when the user typed a letter on a number input) the value property is set to empty.
When this happens I set the value as the default_value. This works because when we set the value using set_value the default_value is also set, but it doesn't get cleared when the input is invalidated.
I'm not sure if this is what you guys had in mind, or the desired behaviour. If it is, I'm happy to make a PR or you can just copy paste my changes.

Tried it - looks nice. Fire away with that PR.

Setting the value with set_value breaks inputs of type file.
I'm working on a fix which checks the input type and only uses set_value on number, text and password.  I'm not sure if it should also be set for other input types, we might need to whitelist others later.
Just letting you know.

https://github.com/David-OConnor/seed/pull/54
I did some reflowing. Checkboxes are now kept in sync from clicking, but there are still some cases where items can get out of sync, such as if a Value isn't specified, or something other than text entry changes the model.

The current impl seems broken for select elements. e.g. I have
select![
    option!["a"],
    option!["b"],
    option!["c"],
    attrs! {At::Value => model.v},
    input_ev(Ev::Input, Msg::NewV)
],

I get the error: ```
panicked at 'Unable to cast as an input element', src/libcore/option.rs:1038:5
This appears to be because the `event.target()` is a being to downcast as an `HtmlInputElement` but actually it is an `HtmlSelectElement` - [see here](https://github.com/David-OConnor/seed/blob/c69e9b8efb67ba2e7103b1e973f80a42c9729392/src/dom_types.rs#L210).

Fixed with a bandaid to mattern match on casting instead of using the helper func. More fundamentally, I'd like to replace that chunk of logic you linked with that in attach_control, which ties more directly with the model instead of relying on defaultValue. Broken atm. I think this bandaid doesn't enforce sync for select.
Is it normal to use select elements without values on the option? Does the text control (Eg "a" for your ex) replace the option?

select works in latest release. Leaving this open since may change some implementation details, and selects aren't controlled.
Considering some type of shim to prevent app slowdowns from interfering with typing.


XS✔ ◾ Minor fixes

❌ Add a description.

@usamaahmadkhan Image is available for testing. docker pull stakater/workshop-exercise:SNAPSHOT-PR-123-ae39879e


vscode's developer tools fail to debug CSS

vscode's developer tools fail to debug CSS

Is this problem a bug caused by adding a sandbox

demonstration operation

I can't repro this. But this is out of our control anyway, these are just the chrome devtools attached to electron.


refactor: Reduce duplication in download

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (90c25be) 91.89% compared to head (c057211) 91.89%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #59   +/-   ##
=======================================
  Coverage   91.89%   91.89%
=======================================
  Files           4        4
  Lines         148      148
=======================================
  Hits          136      136
  Misses         12       12

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


[monitoring v2] unable to upgrade from 14.5.100 -> 100.0.0+up16.6.0 after rancher upgrade 2.5.9 -> 2.6.1-rc3. One of the CP nodes is not accessible

Rancher Server Setup

Rancher version:v2.6.1-rc3
Installation option (Docker install/Helm Chart):helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):rke1

Proxy/Cert Details:letsencrypt, secure

Information about the Cluster

Kubernetes version: v1.19.15
Cluster Type (Local/Downstream):downstream

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):imported

Describe the bug

user is unable to upgrade 14.5.100 -> 100.0.0+up16.6.0 after upgrading rancher from 2.5.9 -> 2.6.1-rc3
it appears that, after attempting to upgrade monitoring, one of the (controlplane) nodes in the cluster went down. The node is still healthy in ec2. I am not sure if the upgrade caused it to go down, or if something unrelated caused the issue.
To Reproduce

Result
only related issue I see is etcd cluster "kube-etcd": 100% of requests for Watch failed on etcd instance <IP_ADDRESS>:2379.
I also see this error in the logs of the failing node:
[ERROR] error syncing 'system-library': handler catalog: Remote commit check failed: Repo [https://git.rancher.io/system-charts] is not accessible: Get "https://git.rancher.io/repos/system-charts/commits/dev-v2.6": context deadline exceeded (Client.Timeout exceeded while awaiting headers), handler system-image-upgrade-catalog-controller: upgrade cluster c-q7cpd system service pipeline failed: upgrade system service cattle-pipeline:registry-proxy failed, Put "https://<IP>:6443/apis/apps/v1/namespaces/cattle-pipeline/daemonsets/registry-proxy": i/o timeout, requeuing

full logs available upon request
Expected Result

monitoring should be able to upgrade; failed upgrades should not break the cluster.
Screenshots

Additional context
<!--Add any other context about the problem here.—>

closing this issue. There were many other resources installed on this setup; it appears that other resources were overloading the cluster and monitoring could not install.


Limit WebSocketFlow messages array to a fixed size

If mitmproxy/mitmdump is used with long-running (or very busy) websocket connections, memory usage grows continuously while a socket connection remains active. One approach could be to limit this array to a fixed size, so that only the last N messages are held in memory. I selected 1000 arbitrarily, but this could be a constant defined elsewhere.
It seems most of the user scripts interact with messages as they come in (vs. accessing the complete websocket message history), so this would likely not break any existing functionality.

Hey @fascinated,
I appreciate the effort (and the idea isn't too bad either), but silently discarding data is out of question for us. If you have this rare use-case of long-running websocket connections that exceed your memory, you can always do this yourself in an addon until we come up with a better solution.
refs #2196

That makes sense, and yeah, I am using this fix locally. Overall I was surprised to learn that even while using mitmdump, the entire persistent connection was stored in memory (vs. being partially discarded after processing or saving to disk as requested).

Yes - we would like to change that eventually (see #2196), but keeping connections in memory until they are closed is just good enough for almost all HTTP use cases where response streaming is not activated.

I would be open to having something like this as addon or example script - with good documentation.

@Kriechi that's a good idea, I'll try truncating flow.messages inside an addon script. Then I can add it to an existing websocket handler demo, or elsewhere.

Maybe also add a CLI option for this addon: --truncate-long-websockets=1000 messages.
I think we have a similar option for flows in general.


CNAME

Please delete the CNAME file so I can try to do this website.

Done. Give it a few to change


Error importing helm charts for airgapped configuration using private registry certificates

What happened:
When using eksctl anywhere import images on a registry with a private CA, 160 images are pushed successfully using docker, then helm is asked to log in, and fails due to not trusting the certificate of the registry.
This does complete successfully with --insecure on in the eksctl command line, so it's not preventing anything other than good practice.
Log snippet

V0	Logging in to helm registry	{"registry": "registry.redacted.com"}
V6	Executing command	{"cmd": "/usr/bin/docker exec -i -e HELM_EXPERIMENTAL_OCI=1 -e HTTPS_PROXY= -e HTTP_PROXY= -e NO_PROXY= eksa_1711276022316141685 helm registry login registry.redacted.com --username  --password-stdin"}
V9	docker	{"stderr": "time=\"2024-03-24T10:27:57Z\" level=info msg=\"Error logging in to endpoint, trying next endpoint\" error=\"Get \\\"https://registry.redacted.com/v2/\\\": tls: failed to verify certificate: x509: certificate signed by unknown authority\"\nError: Get \"https://registry.redacted.com/v2/\": tls: failed to verify certificate: x509: certificate signed by unknown authority\n"}

What you expected to happen:
The import command to complete without error.
How to reproduce it (as minimally and precisely as possible):

Configure a registry with a private CA
Install private CA .crt in /etc/docker/certs.d/<my-registry.com>/ca.crt (per this documentation)
Follow documentation airgapped procedure as far as step 5.

The error will occur after the docker images are written to the registry.
Anything else we need to know?:

My registry is serving on 443, so I have no port number in my /etc/docker/certs.d/ folder entry. Before adding this entry the docker pushes immediately fail (as expected), so the helm parts are never reached.
My registry has no authentication, but the eksctl anywhere import command errors unless REGISTRY_USERNAME is set. In my environment both REGISTRY_USERNAME and REGISTRY_PASSWORD are set to empty strings.
I have also added the CA to the Admin Machine trusted authorities, with no change in behaviour.
I attach my commands and the full output at -v9 to this issue.

Environment:

Admin OS: Ubuntu 20.04.6
eksctl version: 0.175.0
eksctl-anywhere version: v0.19.1 (bundle 61)

import.redacted.log

@rossh-iceway Thanks for the info. We'll take a look asap.

We have updated the docs to include the instructions about using --insecure flag when using self-signed certs for the registry.


How to handle the communication between the two modules ?

The VIPER is great and I have 2 questions:

WireFrameA hold the reference WireFameB, how to decouple it ?
How ModuleA can pass the parameters to ModuleB and ModuleA can listen some callback from ModuleB? Where the action can be done? WireFrameA <------>WireframeB ?

Wireframe shouldn't hold a reference to another wireframe, can you give me an example what are you trying to do?
You can pass parameters (for example some action handler block, or a delegate) in wireframe's init, and then pass them to presenter's init.

// MARK: - Extensions -

extension LoginWireframe: LoginWireframeInterface {

    func navigate(to option: LoginNavigationOption) {
        switch option {
        case .home:
            _openHome()
        }
    }

    private func _openHome() {
        let wireframe = HomeWireframe()

        navigationController?.pushWireframe(wireframe)
    }

}

LoginWireframe hold a reference to HomeWireframe? If Login module use many other modules, Login module have to hold them, they are coupled

@chris118 in this case, navigationController holds a reference to the home view controller, and that means the whole module won't be deallocated until it popped from the stack. This is fine, that's the desired way of usage.


Replacing marker pans map because of KML

Hi,
I have a group of markers
var markers = new L.FeatureGroup();

and i add few markers into that group
while something{
	var LeafIcon = L.Icon.extend({
		options: {
			iconAnchor:   [14, 33],
			popupAnchor:  [0, -33]
		}
	});
       var pin = new LeafIcon({iconUrl: '../Images/Pinovi/test.png'});
      var singleMarker = L.marker(
			[lati, longi],
			{icon: pin, myCustomId: i, myLink: link})
			.bindPopup(L.popup({maxWidth : 'auto', autoClose:false, closeButton:false})
			.setContent(alias))
			.addTo(map)
			.openPopup()
			.on("click", function(e) {
				//code
			})
			.on("mouseover", function(e) {
                               //code
			});
         markers.addLayer(singleMarker);
}

then i get bounds of them and fit map acording to it
var bounds = markers.getBounds();
map.fitBounds(bounds);

every time i try to replace existing marker with new one map pans (if i manualy leave them initial bounds) because of
	var KmlLayer = new L.KML(kmlfile, {async: true});
	map.addLayer(KmlLayer);

Please let me know if there is a fix for this or i am doing something wrong.
Thank you

Added code blocks for better readability, can you provide a fiddle showing your bug please cause there's no mention of fitbounds in kml script ?

this is a fiddle i created
https://jsfiddle.net/davor77/hjt8bq2c/3/
all looks fine
may be a problem in my kml which shows ok on map but here is the code
`<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<GroundOverlay>
	<name>gps_20131028</name>
	<color>78ffffff</color>
	<Icon>
		<href>link_to_gif</href>
		<viewBoundScale>0.75</viewBoundScale>
	</Icon>
	<LatLonBox>
		<north>44.89181083042246</north>
		<south>44.84919732333707</south>
		<east>16.92489611731664</east>
		<west>16.85589243966962</west>
	</LatLonBox>
</GroundOverlay>
</kml>

`


Show how much of a tutorial you've completed on your profile

It should have a meter in 2 colors:

green: for exercises that have been approved
yellow: for exercises that are currently in progress

Maybe they should also collapse like here:

This should be split into (at least) 2 tasks:

one which creates a UI component
one which integrates it with the BE

Done!


Consider not changing the current working dir for builds running in a daemon but always use Gradle user home as working dir

Following the discussion leading to this https://github.com/gradle/gradle/issues/16748#issuecomment-843868728, the title of this issue has been adjusted
Gradle Daemon started for Gradle TAPI operation uses working directory of the TAPI client process although org.gradle.tooling.GradleConnector#forProjectDirectory has been set.
Yes, it's a bad practice to have CWD dependant code in a build scripts. But the current behaviour is inconsistent with the terminal user experience and this leads to confusion.
Expected Behavior
The same behaviour for TAPI and terminal Gradle running.
For terminal run the newly created Gradle daemon is started with current terminal working directry.
For TAPI run the newly created Gradle daemon should be started using GradleConnector#forProjectDirectory value.
Current Behavior
For TAPI run the newly created Gradle daemon is started using IDE cwd.
Context
This report is not about changing of CWD for existing Gradle daemons which can be reused if it's compatible.
It's only about newly created Daemon processes, so the behaviour will become consistent with the command line usages.
The origin user report and other users complains can be found at https://youtrack.jetbrains.com/issue/IDEA-265203 and linked issues.

This also causes generatePrecompiledScriptPluginAccessors to fail as it tries to create .gradle\vcs-1 within the IntelliJ installation directory. So even if newly created daemons would get a project directory as CWD, it would probably still not be the correct one when running mutliple builds on that daemon.

@oehme does it look like this changed recently?
Is there a way to fix this on older Gradle versions with a change on the consumer TAPI side?

@oehme

CWD in the daemon is set to the CWD of the client. On the CLI that's whatever folder your terminal is currently in. In the IDE that's the CWD of IDEA.

Yes, that's what I've described as the current behavior at the issue description.

This is expected.

I can not agree :). It's not expected because CLI user has different behaviour. Also a number of users complains confirm this.

we should stop even trying to set the CWD in the daemon, as it is meaningless.

Yeah! But it should be done both for tooling API and CLI clients
Thanks for the fix!

@big-guy no, this was always broken. The JetBrains team worked around this by changing the user.dir of IntelliJ. They could reintroduce that change, but as you might imagine, this causes problems for other parts of the IDE. So ideally we'd do a hotfix for this, so 2021.1 can be fixed.

Is there a way to fix this on older Gradle versions with a change on the consumer TAPI side?

@oehme @big-guy +100, we need this fix on TAPI side. At least for target Gradle versions which supports precompiled script plugins

I believe this also causes https://github.com/gradle/gradle/issues/6825 and https://github.com/gradle/gradle/issues/8353.

The current dir problem hits users not only in build.gradle files, but also in settings.gradle: https://youtrack.jetbrains.com/issue/IDEA-266253
Feels like almost any invocation of new File() should produce a warning

Feels like almost any invocation of new File() should produce a warning

That would be very hard to get right, but we could set the CWD of the daemon to a directory called dont-rely-on-cwd ;)

Actually, I'd say that making daemons CWD stable and pointing to something like GRADE_USER_HOME/daemon_id/workdir would have been a good decision - users would not rely on CWD from the very beginning.

Yes, we do that for the worker API already and I'm advocating for doing the same for the main daemon. Mutating the current dir also doesn't fully work. e.g. java.nio.Path will keep reporting the initial dir.

Now it is too late, as there are a lot of scripts relying on (occasional) CWD pointing to project directory.

It's not too late, we can do that change in the next major release. All these usages are broken and probably causing weird bugs for the people who have them in their scripts.

Another problem this surfaced is that the Tooling API wrapper download uses the wrong working directory. I'll adjust that as well.
@big-guy Heads-up, we'll definitely need a 6.8.x release to unblock JetBrains and fix IntelliJ 2021.1

Unfortunately, my initial investigation was a dead-end. Turns out that the StartParameter code path is correct after all, even though the naming is misleading. The CWD issue is instead created by this call to SystemProperties#getCurrentDir. This code is on the "provider" side of the Tooling API, i.e. inside the target Gradle version. So even if we changed this, it would not change IDEA for older Gradle versions.
Right now I'm out of ideas on how to fix the general CWD issue for older Gradle versions. The best I can think of is fixing the sub-issues that are not the user's fault, i.e. #12060 (which I have a PR for) and https://youtrack.jetbrains.com/issue/IDEA-266067 (which I can't reproduce yet).

@vladsoroka @nskvortsov Would be possible for you to add System.setProperty('user.dir', gradle.startParameter.currentDir) to your init script that you inject into every build? This would solve all the issues except for the wrapper download issue, which will be fixed by https://github.com/gradle/gradle/pull/16755

@oehme we've added the old workaround (with additional condition to avoid known breakage of another IntelliJ subsystem) for IDEA 2021.1.1.
Thank you for the support, I hope we will be able to sort it out (w/o changing IDE user.dir) till the next release.

@vladsoroka so what do you think about my proposal above?

@oehme changing user.dir of the running Gradle daemon process is also looks like a workaround. It will not affect IDEA process but might lead to further issues/confusions.
Ideally, I would try to find a way to use projectDir as CWD when a new Daemon java process is being created by the TAPI request. Maybe we can try wrap code responsible for the process creation on TAPI side in a target build Gradle version independent way?

@vladsoroka Setting user.dir to the project dir is exactly what Gradle does when invoked from the command line, so doing the same in an init scrpt it would not lead to other problems. It is the appropriate fix given the situation. Trying to fix up the TAPI would be way more complicated and would not give you any better result.

It is then changed at the start of every build to match the CWD of the client.
I didn't know this. Thanks for the link. It means the results of System.getProperty('user.dir') and new File("").absolutePath will be different (on Java 11+) both for TAPI and CLI. It's also can be confusing but possibly acceptable.

@big-guy what do you think? should it be fixed this way for TAPI clients? Will it work fine with regards to other Gradle features like configuration cache? How does it work in Buildship?

Buildship never had the workaround that IDEA had, so projects that use relative paths simply don't work in Buildship. They also don't work correctly in Java 11, as you already pointed out. That's why I said that Gradle 8 should remove this behavior entirely.

I haven't looked at what has been discussed here before, so please bear with me if I misunderstand anything.
I think the title of this issue is misleading, as the working dir the daemon gets when it is spawned is not the issue it seems. Instead, changing the dir when a build is started was inconsistent but is now fixed for 7.1 with #16755. If my understanding is correct, IDEA could remove the much discussed "workaround" if it updates the Tooling API client to 7.1 then.
Is my understanding correct?
If yes, I think this issue can be closed.
If not, please share a pointer to what else shall be done on the Gradle side (if this was already said, please give me a pointer).

@jjohannes no, you misunderstood. As I said in #16755, that pull request does not do anything about the daemon's working dir. It only fixes the working dir and system properties of the wrapper download, nothing else.
The daemon working dir can't be fixed, as that logic lives in already released Gradle versions. I think we should completely remove this behavior, as it just hides bugs in people's build scripts. The working dir should always be somewhere constant like the Gradle user home. We already do this for the worker API.

Another reason to set CWD outside of the build root is that on Windows the daemon working directory is locked. See

https://github.com/gradle/gradle/issues/26447

⚠ We're also blocked by this issue.
We're using Gradle Tooling API embedded in a backend service, that when deployed, it only has write permissions to a particular folder. We set useGradleUserHomeDir() with a directory within the folder with write permissions. But Gradle Tooling API still tries to start the Daemon in 'user.dir', and fails, because that folder has read-only permissions.
Are there any plans to fix this issue? If not, is there any workaround that we could use?
Thanks!

Hey guys I noticed unusually behavior with Gradle and CWD. I'm not an expert on Gradle but it appears Gradle actually resets the CWD unlike Maven or Maven Daemon.
Does Gradle uses native code to do this?
I will copy my comments on a bug in my project:

It appears that Gradle fundamentally does bizarre things with the CWD.
The CWD in gradle is always the daemon. However it is not the true CWD where the gradle command was issued.
However the parts of the java.nio system maintain the correct CWD.
If you do in the annotation processor Path.of(".").toAbsolutePath() it will show some gradle daemon path. However if you do Files.newInputStream(Path.of("./somefile")) it will resolve and be able to find the file assuming somefile is in the CWD where the gradle command is issued on MacOS and Linux but not Windows.
This really bizarre behavior that makes me thing CWD is just never the right choice. It was always the fallback but given how unreliable it is perhaps we should not even fallback to it.
Probably the better solution is to use annotation processor Filer path location and go up the directories looking for a build.gradle or build.gradle.kts like we do with Eclipse for .classpath.
Furthermore it is strange how Maven and the Maven Daemon do not have this problem and actually resolve to the correct CWD the command was issued in. So Gradle in its script must be resetting the CWD (e.g. cd) OR it has some native code doing it and the java.nio is ignoring that resetting of the CWD.

Yes, relying on CWD in Gradle logic is almost always the wrong thing to do, as in practically any JVM program.
The only case I'm aware, where it is appropriate to use the CWD in JVM programs is, if you use a relative path given by the callling user on the commandline.
If you for example have some application (independent of Gradle) that uses new File(hardcodedPathRelativeToStartBatFile), this also only works if the user calls that bat file from the expected directory, but not if he for example calls it from another directory.
In the case of code running in the context of a Gradle build, this is even "worse", as the code is usually run within the Gradle daemon which can be reused among different projects that can have different CWDs when you invoke the CLI.
Gradle tries to set the CWD to the root project directory (or maybe the CLI CWD, I don't remember) in an already running daemon, but as you have seen, this does not always fully work or does not work for all API as some determine the CWD once and remember it as there is no really supported way to change the CWD in-process.
Gradle just tries its best to set the CWD as good as it can to support "broken" code that relies on the CWD.
Gradle logic should usually always resolve paths relative to the project directory or similar.

@Vampire yes I would never use the CWD normally. I'm in the context of an annotation processor where there are possibly 3 implementations of what is called the Filer (Eclipse, javac, and Gradle kind of).
It would take me a long time go over how the only thing supported in terms of paths is javax.tools.StandardLocation#CLASS_OUTPUT and how folks do not always put resources and or have a build system that will always copy to it.
So if an annotation processor tries to access things that are not java code (in my case mustache templates) it is a pain the butt. CWD was used as a last resort but now I will probably just fail the build and require absolute path passed to the annotation processor.
https://jstach.io/doc/jstachio/current/apidocs/io.jstach.jstache/io/jstach/jstache/JStache.html#RESOURCES_PATH_OPTION
(ignore the term CWD in that doc).
Ideally some system property or something would be set that is standard across the build systems of what the current project directory is but that probably is not going to happen and or there probably issues with that as well (especially if forking is not happening).

Long ago that I wrote my last annotation processor, but yeah, giving that in as property and requiring that the right path is given sounds like the most reliable way to me.


D4 Look and feel

![WIRE FRAME](https://github.com/user-attachments/assets/9f079168-0e9a-42f9-992c-d4b9b0dbd73f)
NOTE: These screenshots are pulled from our Figma Project and are not representative of the current state of our product
When we first started this project, we quickly realized that if we wanted to design a groupchat-focused-webapp that appeals to college students we'll have to compete directly with methods that already exist, for example: Snapchat, Groupme, Discord. With those existing products in mind, our approach was simplicity and minimalism whilst trimming out the fat that the other products mentioned offer ( features not necessary for an academically focused product such as Snapchats Location services, GroupMe's Built in Meme-Maker, Discords Game Linking Functionality ) and instead implement curated features meant to exclusively suit a students success in college not only academically but socially . As you can see in our screenshots our UI is very simple and doesn't overwhelm the user with too many options at once, this was intentional and reflective of what we heard in many of our interviews.
// UNFINISHED, WILL EDIT LATER //


New version: GitHub.GitHubDesktop version 3.4.4

Created by 🥟 Dumplings in workflow run #7861.

Log
Updated: 3.4.3 → 3.4.4
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Replace redis to redis-client

Hey, an idea...
Replace redis to redis-client gem which uses the new RESP3 protocol found in Redis 6.0+.
Ref:
https://github.com/redis-rb/redis-client

Ps: Sidekiq 7+ use redis-client

It seems that rails still recommends redis, I would like to keep it in sync with the rails gem template
https://github.com/rails/rails/blob/main/railties/lib/rails/generators/app_base.rb#L579

Updates: https://github.com/rails/rails/pull/47513

It seems that was removed just from the docker file, on the gem file they still use redis... I will try to open a PR later...
https://github.com/rails/rails/blob/c8780e2895ed7ced6c7bb8b2357a030f354e48cc/railties/lib/rails/generators/app_base.rb#L575


Implement support for pure enum types in codegen

Our union types currently must wrap a placeholder type such as an unused bool.
Ideally we could use flatbuffer enums to represent "pure" enum values that either map to a Null-wrapping union or directly to an integer-type.
Mapping to a Union likely provides better semantic forward/backward compatibility as mapping to an integer type risks incorrect interpretation of values if someone modifies the fbs file to change the order.

This is a duplicate of https://github.com/rerun-io/rerun/issues/3384 which was closed by https://github.com/rerun-io/rerun/issues/3384


Add stdlib.h to header.  Needed for size_t.

Would you mind changing that into stdlib.h? That's what used in other files to get size_t defined.

Would you mind changing that into stdlib.h?

Done.  Thank you for the correction.

Thanks!


I used gilbert in a video series

This is not an issue report, just letting you know that all the questions I asked you months ago have finally turned into something.  I used a gilbert curve as a chromosome map in this very long (5 part, 42 hour) video series:
https://www.youtube.com/watch?v=6Ev2WgLk9Oc&list=PL0elTBjXjW_52wz-JBuRfFQIgrRUfONWR
It might not be your kind of thing, but I just wanted to say thanks for the code!

Thanks for sharing! I love seeing where the code ends up, like this fascinating application. I just wish there were more introductory notes in the description -- I must admit I don't fully understand the meaning of the visualization. Anyway, thanks for letting me know.

I had vague plans to put more explanatory comments into it, but I ran out of steam and realized that if I didn't publish it now I'd probably never get it done.  So your lack of understanding is a victim of my laziness.  :-)


feat: show jobset & eval details, rewrite in rust

Summary: show jobset & eval details, rewrite in rust, bump to v2. Note that:

Obviously, you don't have to merge this at all :laughing: as the patch significantly complexifies the codebase, making it harder to maintain or review (though rust does make it easier to package the program and protects it against bit rot, compared to python).
The rewrite in rust is not justified, it's just a personal preference. As an amateur programmer, when I need some functionality (e.g. colored texts, aligned tables), I simply add a library :laughing: In rust I cargo add when necessary without much worrying (after checking the reputation of the depended crate, of course), while in python, I do not feel as comfortable to just pull in random dependencies.
I am absolutely okay if the final decision is to not merge this! I just want to share it upstream as this extended v2 version has been serving me well.

features

Print recent evaluations of the jobset if no package is specified

Add an --eval flag for information about a specific evaluation

Infer the current stable Nixpkgs release (e.g. 24.05) with a hack

Support standard channel names (e.g. nixos-unstable)
Generate shell completions with --shell-completion SHELL
Print nicely formatted, colored and aligned tables

Hey! At first whoa, thanks alot for your effort! I saw your PR 2 weeks ago but i was just a bit overwhelmed :) i will check out your rebuild and give back some feedback afterwards!

The Pull Request looks good and i would like to merge the PR under sole condition that you would have to become one of the maintainers of hydra-check with the power (and responsibility) to handle issues and merge requests together with me and @Artturin
@Artturin i hope you are also fine with that :100:

The Pull Request looks good and i would like to merge the PR under sole condition that you would have to become one of the maintainers of hydra-check with the power (and responsibility) to handle issues and merge requests together with me and Artturin

I am perfectly fine with that! It would be an honor! Thank you!
In the latest push I added two more commits: one is a rename of some internal objects (along with extra documentations) such that it would be clearer for future contributors, and the other is an improvement of the --eval cli processing such that one can simply do e.g. hydra-check --eval rustc for the latest eval filtered by rustc.

@bryango thanks a lot for your efforts! I've added you as a maintainer to the project.

Thank you very much! If there is any issue, feel free to ping me anytime!

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/hydra-check-2-0-query-evals-shell-completions-and-a-new-look/57954/1


About the ycbcr and quantization

Hi, it is a good job to incorporate the Re-parameterization into SR model. I still have some questions about the code and paper.

In Section 2, Computation Reduction, the paper says

However, quantization of SR models often can hardly maintain the SR quality because of the precision requirement of pixel-wise prediction

The original RepVGG model does not perform well in quantization. How about the error of quantization in low-level Re-parameterization quantization? It seems that there is no further explanation or results for the quantization error in the paper.

Common SR models are trained on RGB channel and tested on  Matlab version Y of YCbCr. However, in the provided code
https://github.com/xindongzhang/ECBSR/blob/eac2ff12b4fa24a24c99b6e32deff59d0ad9e3d4/datas/div2k.py#L10
https://github.com/xindongzhang/ECBSR/blob/eac2ff12b4fa24a24c99b6e32deff59d0ad9e3d4/datas/div2k.py#L54
How about the error between different versions of Ycbcr?
Thanks!

Hi, it is a good job to incorporate the Re-parameterization into SR model. I still have some questions about the code and paper.

In Section 2, Computation Reduction, the paper says

However, quantization of SR models often can hardly maintain the SR quality because of the precision requirement of pixel-wise prediction

The original RepVGG model does not perform well in quantization. How about the error of quantization in low-level Re-parameterization quantization? It seems that there is no further explanation or results for the quantization error in the paper.

Common SR models are trained on RGB channel and tested on  Matlab version Y of YCbCr. However, in the provided code
https://github.com/xindongzhang/ECBSR/blob/eac2ff12b4fa24a24c99b6e32deff59d0ad9e3d4/datas/div2k.py#L10
https://github.com/xindongzhang/ECBSR/blob/eac2ff12b4fa24a24c99b6e32deff59d0ad9e3d4/datas/div2k.py#L54
How about the error between different versions of Ycbcr?
Thanks!

Hi, thanks for your interest to this work.
(1) The quantization for SR task is a big topic, as it is related to the topology of network, selection of operations and quantizationo methods(PTQ series, QAT series...), etc. If your want to performs int8-quantization of Re-parameterization for engineering purpose, it is highly suggested that you fold the rep-networks back into a plain-net before performing PTQ. It could introduce affordable errors from our experience, more details can be refered to "Real-Time Quantized Image Super-Resolution on Mobile NPUs, Mobile AI 2021 Challenge: Report". One more thing to be added, our quantization-tools (PTQ) for this work is coming soon.
(2) Common SR models are tested on Y channel out of YCbCr, and we follow this manner, more infos can be refer to the papers from FSRCNN/ESPCN etc. There are two implementation in this repo, one is on the legacy folder which is developed and tested based on the EDSR-Pytorch, the other is on the root folder of this project which is a more lighten one. Both of them behave almost the same.

Thanks a lot！


Neo4j 4.0.4 is not supported?

I followed 'Setup' chapter to modify config/application.rb:
require 'neo4j/ratiltie'
...
config.neo4j.session.options = {ssl: false}
config.neo4j.session.type = :bolt
config.neo4j.session.url = 'bolt://neo4j:neo4j@localhost:7687'

and make a simple model Role.rb
class Role
    include Neo4j::ActiveNode
end

and excute Role.first in Rails console
Loading development environment (Rails <IP_ADDRESS>)
irb(main):001:0> Role
=> Role
irb(main):002:0> Role.first
Traceback (most recent call last):
        1: from (irb):2
RuntimeError (Couldn't agree on a version (Sent versions [1, 0, 0, 0]))

if I change type from bolt to http
# config.neo4j.session.options = {ssl: false}
config.neo4j.session.type = :http
config.neo4j.session.url = 'http://neo4j:neo4j@localhost:7474'

That not work too.
irb(main):001:0> Role.first
 HTTP REQUEST: 229ms Get http://localhost:7474/db/data/schema/cnostraint (0 bytes)
Traceback (most recent call last):
        1: from (irb):1
Neo4j::Core::CypherSession::ConnectionFaildError (Connection failure: )
    status: 404

I notice Neo4j removed REST API after 3.5, and I don't like to replace Neo4j 4.x with 3.x.
What can I do next?
Runtime information:
OS: Windows 7
Ruby: 2.6.5-p114
Rails: <IP_ADDRESS>
Neo4j database version: Community 4.0.4
neo4j gem version: 9.6.2
neo4j-core gem version: 9.0.0

I tried on my MAC. It's no problem, right?
2.6.3 :004 > Role.first
 BOLT UNSECURE: 6ms bolt://neo4j:...@localhost:7687
 BOLT UNSECURE: 102ms bolt://neo4j:...@localhost:7687
 BOLT UNSECURE: 2ms bolt://neo4j:...@localhost:7687
 BOLT UNSECURE: 1ms bolt://neo4j:...@localhost:7687
 BOLT UNSECURE: 2ms bolt://neo4j:...@localhost:7687
 BOLT UNSECURE: 2ms bolt://neo4j:...@localhost:7687
Traceback (most recent call last):
        1: from (irb):4
Neo4j::DeprecatedSchemaDefinitionError (          Some schema elements were defined by the model (which is no longer supported), but they do not exist in the database.  Run the following to create them if you haven't already:)

rake neo4j:generate_schema_migration[constraint,Role,uuid]

And then run `rake neo4j:migrate`

(zshell users may need to escape the brackets)

Runtime information:
OS: macOS Catalina 10.15.4
Ruby: 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18]
Rails: <IP_ADDRESS>
Neo4j database version: Community 3.5.14
neo4j gem version: 9.6.2
neo4j-core gem version: 9.0.0

@jihh As the error message says, you will need a DB constraint on Role#id . Kindly do as said in error message and let us know if there are still any issues. Thanks.
rake neo4j:generate_schema_migration[constraint,Role,uuid]
rake neo4j:migrate

Hi @jihh, I had the same problem here.
The problem is the version 4 of Neo4j. If you use version 3.5 you don't get the problem.

I spent a lot of time to find out this problem was related to compatibility between version 9.6 and Neo4j 4. I thought about creating a PR to help other people who could have the same problem as me. But I saw here https://github.com/neo4jrb/activegraph/compare/v9.6.2...v10.0.0.pre.beta.11#diff-1eb9dd67f3fdb946a95aa3bcf645ca10R22 that this is already working on version 10 which is nearing completion.

@jihh @raphox activegraph-10.0.0 is released. This is the only version compatible with neo4j 4.0. Please reread https://neo4jrb.readthedocs.io/. Quite a bit has changed.


期待下一篇mamba back

清华已经发了

清华已经发了

Actually, MLLA uses self-distillation to train the model, making the results unfair to compare with other models.
https://github.com/LeapLabTHU/MLLA/blob/master/main.py#L264-L270


Custom node error

https://www.loom.com/share/1763ab6f100844e6a8c7161ba58e1a50
already run the commands prior to that.

Hey @kmligue,
That looks like there is an issue with your package.json, as a test can you clear the contents of the custom folder and rather than running npm init try just running the npm link n8n-nodes-test command.


[zh] Sync core-concepts/components.md

What type of PR is this?
/kind documentation

What this PR does / why we need it:
Sync with the english text
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

/lgtm
These changes are to keep consistent with english version. You need to sign off by running:
git commit -s --amend
git push -f

@windsonsea I got it.

/lgtm
These changes are to keep consistent with english version. You need to sign off by running:
git commit -s --amend
git push -f

Sorry, I'm new to Git. What should I do next?  Press the ESC key, and type :wq

Run the command to push again:
git push origin patch-1 -f

Run this command on your patch-1 branch locally:git commit -s --amend

Need not change nothing. Press the ESC key, and type :wq
Run the command to push again:git push origin patch-1 -f

Thank you, I understand how to do it now :) @windsonsea


Network Policy does not work

Hi,
I have some troubles implementing a network policy, it seems it as no effect at all on my kubernetes-core deployment.
The following Network Policy should deny all traffic between pods, but it has no effect (for instance, service names are still resolved) :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny-all
namespace: default
spec:
podSelector: {}
ingress: []

My CNI is flannel, is it compatible with network policy ?

Network policy has no default implementation in Kubernetes. You'll need to
use Calico ( available in Canal version of Kubernetes-core )
On Wed, May 30, 2018, 07:43 yaumeg<EMAIL_ADDRESS>wrote:

Hi,
I have some troubles implementing a network policy, it seems it as no
effect at all on my kubernetes-core deployment.
The following Network Policy should deny all traffic between pods, but it
has no effect (for instance, service names are still resolved) :
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny-all
namespace: default
spec:
podSelector: {}
ingress: []
My CNI is flannel, is it compatible with network policy ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/586,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAET1YCaLNld_HSkw1VYYlotoyE_Lu4gks5t3oXsgaJpZM4UTHSr
.

Ok, thank you. I can't find a canal version for kubernetes-core, but only for the canonical-kubernetes deployment. I guess that I only have to replace this in bundle.yaml :
flannel:
    annotations:
      gui-x: '450'
      gui-y: '750'
    charm: cs:~containers/flannel-59

by this :
  canal:
    annotations:
      gui-x: '450'
      gui-y: '750'
    charm: cs:~containers/canal-37

And this :
- - flannel:etcd
   - etcd:db
- - flannel:cni
  - kubernetes-master:cni
- - flannel:cni
  - kubernetes-worker:cni

by this :
- - canal:etcd
  - etcd:db
- - canal:cni
  - kubernetes-master:cni
- - canal:cni
  - kubernetes-worker:cni

Is Canal considered as stable as Flannel ?

It is. It's flannel as networking with calico for policy management. Your
changes seem correct.
On Wed, May 30, 2018, 09:07 yaumeg<EMAIL_ADDRESS>wrote:

Ok, thank you. I can't find a canal version for kubernetes-core, but only
for the canonical-kubernetes deployment. I guess that I only have to
replace this in bundle.yaml :
flannel:
annotations:
gui-x: '450'
gui-y: '750'
charm: cs:~containers/flannel-59
by this :
canal:
annotations:
gui-x: '450'
gui-y: '750'
charm: cs:~containers/canal-37
And this :

flannel:etcd
etcd:db

flannel:cni
kubernetes-master:cni

flannel:cni
kubernetes-worker:cni

by this :

canal:etcd
etcd:db

canal:cni
kubernetes-master:cni

canal:cni
kubernetes-worker:cni

Is Canal considered as stable as Flannel ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/586#issuecomment-393154556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAET1VLoD_63djtxUUWn9ePWAYNEZl30ks5t3pmdgaJpZM4UTHSr
.

@yaumeg did you fix this issue or do you still need help?
If you clone this repo to your machine and run the command make inside the directory, you will generate a list of bundles in the bundles directory. There will be a bundle in there for deploying kubernetes-core with canal you can compare your changes with this one to ensure they are correct.
Cheers,

Calvin

I have not yet deployed the cluster with canal, it's scheduled in a few hours.
I built the repo, but here is what I obtain, no canal bundle, only flannel or calico :
cdk-calico/
cdk-calico-elastic/
cdk-flannel/
cdk-flannel-elastic/
core-calico/
core-calico-elastic/
core-flannel/
core-flannel-elastic/

I deployed the cluster with canal, but I have the following error :
unit-canal-2: 18:46:58 DEBUG unit.canal/2.update-status Failed to apply 'ipPool' resource: client: etcd cluster is unavailable or misconfigured; error #0: Forbidden
I also tried to deploy with calico, and I have the same error.
Is this a known bug ?

Hi @yaumeg looks like you might have etcd missing from the cluster? Can you share your bundle file?

I have not yet deployed the cluster with canal, it's scheduled in a few hours.
I built the repo, but here is what I obtain, no canal bundle, only flannel or calico :

My apologies, these changed just went into the bundle builder, they were in a few PR which was just merged a few hours ago. If you pull the repo you should get the new changes and you should be able to automatically generate a new bundle which contains calico or canal.
Cheers,

Calvin

I made some more tests ; I can deploy successfully the latest stable version of kubernetes-core (#337) with a flannel setup, but only if I modify the bundle to use etcd 2.3. If I use etcd 3.2, I have a "Errored with 0 known peers" error.
When I use the exact same bundle but with canal (or calico) instead of flannel, and configured with etcd 2.3, I still have the following error (with etcd up and running) :
unit-canal-2: 18:46:58 DEBUG unit.canal/2.update-status Failed to apply 'ipPool' resource: client: etcd cluster is unavailable or misconfigured; error #0: Forbidden
...and juju status displays "Waiting to retry calico pool configuration" for master and workers.
Maybe etcd 3.2 is required by canal ?
You can find all the logs hereafter :
canal_results-2018-06-01-19-19-57.tar.gz

Hi @CalvinHartwell, do you have an idea of what is going on with etcd ? Thanks.

FInally, kubernetes with canal is up and running ! My problem was caused by a bad proxy configuration.
I was experimenting egress rules with no success, until I found that they are implemented only from calico 2.6 ; and the version deployed by the juju charm is 2.5.1.
https://docs.projectcalico.org/v2.6/releases/
Is it possible to upgrade calico version with the last 2.6, by changing "calico-node-image" parameter from "quay.io/calico/node:v2.5.1" to "quay.io/calico/node:v2.6.10" ? Or do I have to do something else ?
Thanks

@yaumeg You'll have to follow the steps described in https://github.com/juju-solutions/layer-canal/blob/master/versioning.md


fix(compactor): collect metrics for fast compact runer

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
In passed implementation, we do not record drop key size for fast compaction algorithm, it will cause the table size calculated by meta-node less than sum of uncompressed size of all files.
close #12926
Checklist

[ ] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

same with https://github.com/risingwavelabs/risingwave/pull/13064


add instruction how to test pipeline

Make it clear that pipeline uses make check instead of make test to do unit testing.

Thanks @guanqun!


How to create a panel of plots when using, for example, tsne

Hi,
Would it be possible to create a panel of plots using both rows and columns when plotting tsne?
I did something similar to this:

Basically the code calls the matplotlib subplots method based on the number of plots:
def _build_subplots(n):
  '''
  Build subplots grid
  n: number of subplots
  '''
  nrow = int(np.sqrt(n))
  ncol = int(np.ceil(n / nrow))
  fig, axs = plt.subplots(nrow, ncol, dpi=100, figsize=(ncol*5, nrow*5))

  return fig, axs, nrow, ncol

Then the plots are drawn:
genes = [...list of gene symbols...]
fig, axs, nrow, ncol = _build_subplots(len(genes))

if type(axs) != np.ndarray:
  axs = [axs]
else:
  axs = axs.ravel()

for i in range(nrow*ncol):
  if i < len(genes):
    gene = genes[i]
    # df is the numpy array containing tSNE
    axs[i].scatter(df[:, 0], df[:, 1], ...)

Is it something that is already done, planned or that you don't want to integrate?
Thanks,
Francesco

Dear Francesco,
sorry about the late response... These days are incredibly busy.
Currently this is not on the list of urgent things. If you find an elegant way of introducing this in all the plotting functions at once, happy to discuss some prototype code.
For now, you can just use your method
for i in range(nrow*ncol):
  if i < len(genes):
    gene = genes[i]
    # df is the numpy array containing tSNE
    ax = sc.pl.scatter(ax=axs[i], show=False)

What do you think?
Alex

Thanks @falexwolf ,
No worries. I'd like to contribute when I can, but I'd need some time to understand how the code is structured. For now I'll be using your suggestion. If I have time I'll provide a PR.
Thanks again for the library,
Francesco

@falexwolf we just tried the solution you posted and it reveals a bug: when ax is not None you don't create the variable axs and thus throw an error here: https://github.com/theislab/scanpy/blob/master/scanpy/plotting/anndata.py#L634
Should be a simple fix:
        if ax is None:
            axs, _, _, _ = setup_axes(
                ax=ax, panels=['x'] if groupby is None else keys, show_ticks=True, right_margin=0.3)
        else:
            axs = [ax]

Yes, indeed! Should be fixed https://github.com/theislab/scanpy/commit/8fab0d1196a5ae878ee7c9ab55f44d930aca01b4
But there were no problems with pl.scatter, right?

I didn't actually check, but @aopisco will tell you soon...

yes, now it works for pl.scatter and pl.violin


broken github links on keras.io documentation

The link "Edit on Github" in the upper right corner of the keras.io documentation is broken and leads to a 404 error page.
This is an example of the current link:
https://github.com/keras-team/keras/edit/master/docs/index.md
I guess it should be:
https://github.com/keras-team/keras/tree/master/docs
This is the same for all links on keras.io.

Dear @maderafunk ,
I have started a PR for this issue.
Needs to be approved by @fchollet .


Stange Bossbar

adjust  show_boss_bar:100|Hello

I can see Boss Monster Effect
Monster trace my cursor

Outdated server versions have issues? No way!

Update your server to get rid of this issue !


case sensitivity on user emails

might close https://github.com/StatCan/daaas/issues/127 (must test ofc)

Ok I've done a fair bit of focused digging, please let me know if I am making any sense I can post a follow-up comment if not.
Few steps to find out where I am in knowledge

At the argocd layer we deploy kubeflow here using an applicationset
So we go to the referenced repoUrl
Search for anything kfam related and end up in this issue and it turns out that it is instead in some profilescomponent
So we look in our kustomization which references upstream.
And lo and behold it exists here

Next Steps in order to test the image.
So it appears that we did switch to using the upstream image. So we will need to

[ ] build this access-management image in our branch
[ ] Turn off autosync in argocd dev at the kubeflow application level in order to make an edit to the profiles-deployment Deployment to make a change to the image

[ ] Refresh and try things out, see if it performs as expected
[ ] Iff it does, we can make the change permanent by changing up the kustomize that deploys this, and bring it to Prod too (by making the change in the prod branch as well).

Other relevant information
Our fork of kubeflow is at version 1.3, so when we upgrade we will need to evaluate and check that everything works as intended.
We may want to hold off on deploying this fix to prod if that is the case.

There's a double build-push because I kept this case-sensitivity-emails in the branchname, will remove it and just keep it as the build on pr / push to stc-master.
But this issue of the docker build failing is a tad more concerning, will need to investigate

I can make it past the first failure by upgrading the golang version to be 1.17 like they do upstream but now have a new one at


Created tests.yml

Added test.yml to github workflows as I have defined some tests in my latest pr.


Back to top button

I want to add a back to top button in the website

I am a GSSOC'23 contributor.
I would like to work on this issue. Please assign me with this.


Fold divisions by 0.

The current implementation in the folder when seeing a division by zero
is to assert.  In the release build, the compiler will attempt to
compute the value, which causes its own problems.
The solution I will go with is to fold the division, and just give it
the value of 0.  The same goes for remainder and mod operations.
Fixes #1961.

wouldn't folding into OpUndef be an option?
That way further folds can happen based on ops having one operand == undef


It must use the bearer authorization method

Guys, I'm trying to integrate my strapi with meilisearch in azure. I deployed using the getmeili/meilisearch:latest. I can use normally in postman or flutterweb. but the plugin doesn't work, I keep getting the same error
{"message":"The Authorization header is missing. It must use the bearer authorization method.","code":"missing_authorization_header","type":"auth","link":"https://docs.meilisearch.com/errors#missing_authorization_header"}
Can you guys help me?

Hello @felipe-fontes how are you?
Could you please send me the package version that you are using?
Because we released a few days ago the new version of MeiliSearch server https://github.com/meilisearch/MeiliSearch/releases/tag/v0.25.0 and we released a new version of strapi-plugin-meilisearch that supports the v0.25.0 of MeiliSearch server.
By the way, getmeili/meilisearch:latest doesn’t help me that much, because the latest tag is always being upgraded to the latest release, so in that way, I would need to know when you pulled out from docker hub!
To check the current version you could use our guide or make a cURL request :)
curl \
  -X GET 'http://localhost:7700/version'

Either way I would say to you to ensure you are on the latest version of the server and the strapi-plugin, it should be fine :)

Omg!!!, I lost 10h trying to fix it, thinking that was cors or something in azure. Thank you so much.
I had version 0.4.1 of strapi-plugin-meilisearch.

OMG! 😆
I'm glad I could help! Thanks for using MeiliSearch! 🎉 🌮


Fix Time::Format API doc

The API doc comment for Time::Format was overridden in multiple places (introduced by #5123), so #6214 was not a complete fix.

It would be great to add this to 0.26.1


Changes ignite plugin config to JSON.

Ignite plugins are now configured with json instead of toml.
Good bye TOML, we'll meet again in another project.
Fixes #688

is this backwards compatible?  Does this effect these guys? https://github.com/infinitered/ignite/blob/master/PLUGINS.md

Ya, these can all just delete their TOML files.

but then how do they description though?
¯\(ツ)/¯

package.json in the description field.

^ also, I may have just invented that just now.  I can't remember if it's thing or not.  😆


create CONTRIBUTING.md file

What would you like to be added:
General guidelines
sub-topics:

Before you get started
How to contribute
Setting up local environment

Why is this needed:
Helps new contributors to understand workflow of the project
@RainbowMango @Arhell What other sub-topics should we include?

@rgrupesh  Can I work on this issue?

Yes, you can. Please, go ahead. @03amir

Can you please assign me this issue?

/assign @03amir

@RainbowMango Anything that you like to add here?

/assign


Fix GCC11 Compile Error in benchmark_register.h

Fix GCC11 compilation error (Issue #485)  to missing header "limits" in benchmark_register.h
Compiling ospray (Version 2.5, 2.6 and master) with gcc 11.1.0 leads to compilation error:

ospray/apps/common/external/benchmark/src/benchmark_register.h:22:30: error: 'numeric_limits' is not a member of 'std'     22 |       static const T kmax = std::numeric_limits<T>::max();

This fix adds the required header  to benchmark_register.h

We now fetch a newer version of Google Benchmark via the superbuild, which includes the <limits>.


bump version in package.json to v2.22.8

release version v2.22.8

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


Add -Wno-atomic-align

On Linux arm dotnet/runtime builds, this atomic instruction in platform.c warns.
https://github.com/AaronRobinsonMSFT/DNNE/blob/3657e77c4a988054ea8c0a84122b5bb450503b49/src/platform/platform.c#L298-L301
To silence the warning, use "-Wno-atomic-alignment" for clang.
https://dev.azure.com/dnceng-public/public/_build/results?buildId=354415&view=logs&j=fbba4562-0196-5144-0bc8-97e5ecde48bd&t=965fe576-127f-568f-354c-a3511c13c4cb&l=2414
I haven't yet confirmed this change fixes the issue.

We shouldn't add this flag. I see the issue. I'll make the fix in source.

@jtschuster I'm going to close this in lieu of #174


Cupertino text field - warning to delete a string

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Test environment: Pixel 6 + Android 14
Go to any app that includes text field widget provided in the code section (similar to https://gallery.flutter.dev/#/demo/text-field )
Go to the cupertino text field
Select the first input field
Change the keyboard language
Type a text
Try to delete the text by selecting the cross on the right side (try 2 o 3 times until it deletes the string)
The following warning is logged:

W/RemoteInputConnectionImpl(18845): getSurroundingText on inactive InputConnection

Expected results
None warning should be displayed after deleting a string in this way
Actual results
The following warning is logged after deleting a string by selecting the "cross" symbol in cupertino text field
Code sample
Code sample
This is the widget I’m using in Flutter:
class MaterialTextFieldView extends StatelessWidget {
  const MaterialTextFieldView({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: const Text('Text fields'),
      ),
      body: const SingleChildScrollView(
        padding: EdgeInsets.symmetric(
          horizontal: 24,
          vertical: 16,
        ),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            TextField(
              decoration: InputDecoration(
                labelText: 'Left to right',
              ),
            ),
            SizedBox(height: 48),
            TextField(
              decoration: InputDecoration(
                labelText: 'Right to left',
              ),
              textDirection: TextDirection.rtl,
            ),
            SizedBox(height: 48),
            TextField(
              maxLines: 2,
              decoration: InputDecoration(labelText: 'Max lines (2)'),
              textDirection: TextDirection.ltr,
            ),
            SizedBox(height: 48),
            PasswordTextField(),
            SizedBox(height: 48),
            PhoneNumberTextField(),
            SizedBox(height: 48),
          ],
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
W/RemoteInputConnectionImpl(18845): getSurroundingText on inactive InputConnection

Flutter Doctor output
Doctor output
[✓] Flutter (Channel master, 3.16.0-15.0.pre.52, on macOS 13.5 22G74 darwin-arm64, locale en-US)
    • Flutter version 3.16.0-15.0.pre.52 on channel master at /Users/diegogawenda/fvm/versions/master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 5ceb7284bc (2 days ago), 2023-10-23 14:28:36 -0400
    • Engine revision eaed54aa67
    • Dart version 3.3.0 (build 3.3.0-48.0.dev)
    • DevTools version 2.28.1

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/diegogawenda/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/diegogawenda/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/diegogawenda/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A240d
    • CocoaPods version 1.12.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] VS Code (version 1.80.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.74.0

[✓] Connected device (4 available)
    • Pixel 6 (mobile)         • 1A141FDF600823            • android-arm64  • Android 14 (API 34)
    • Somnio’s iPhone (mobile) • 00008120-001168D83C87C01E • ios            • iOS 17.1 21B74
    • macOS (desktop)          • macos                     • darwin-arm64   • macOS 13.5 22G74 darwin-arm64
    • Chrome (web)

[✓] Network resources
    • All expected network resources are available.

Note from android triage: re-routing to framework

Potentially a duplicate of https://github.com/flutter/flutter/issues/9471. Is this the same behavior that you're experiencing @DiegoGW?

Potentially a duplicate of #9471. Is this the same behavior that you're experiencing @DiegoGW?

Yes @Renzo-Olivares , between all comments there is a similar replication step.

I'm going to close this issue in favor of #9471. Please feel free to re-open if this issue is different.


Reversing interpolation compatible outlines should produce compatible outlines when outputImpliedClosingLine=True

A subpath (sequence of drawing commands starting with a move and containing no other move) is interpolation compatible with another subpath iff both use the same drawing commands in the same order.
For example, move, curve, close (MCZ) is compatible with all other MCZ sequences.
It should not matter:

What the values of the associated points, if any, are
Whether we interact with the curve as a point stream, drawing command stream (context-aware drawing commands, e.g. a quad has two points, implicitly starting at the current position), or segments (self-contained drawing commands, e.g. a quad has 3 points rather than implicitly using current as the first)

Reversing paths shouldn't cause them to become interpolation incompatible. https://gist.github.com/rsheeter/cef6cf71fa9e519c94f9f0d23906e5de demonstrates a case where this appears not to be the case.

I think this is legit. Suggest this patch:
diff --git a/Lib/fontTools/pens/reverseContourPen.py b/Lib/fontTools/pens/reverseContourPen.py
index a3756ab17..16c3f0209 100644
--- a/Lib/fontTools/pens/reverseContourPen.py
+++ b/Lib/fontTools/pens/reverseContourPen.py
@@ -62,7 +62,7 @@ def reversedContour(contour, outputImpliedClosingLine=False):
         if closed:
             # for closed paths, we keep the starting point
             yield firstType, firstPts
-            if firstOnCurve != lastOnCurve:
+            if firstOnCurve != lastOnCurve or outputImpliedClosingLine:
                 # emit an implied line between the last and first points
                 yield "lineTo", (lastOnCurve,)

I'm mildly aggravated you fixed it faster than I could type the issue up 😂

Sorry but I don't agree with the change proposed in #3094. We even reverted this very same change only a couple of months ago, and @behdad concurred with me: https://github.com/fonttools/fonttools/pull/2995 (he even merged that PR).
As I have tried to explain in https://github.com/googlefonts/fontations/issues/370, the two contours from Rod's gist are in fact incompatible when one looks at them as either list of points or list of segments. This is because the first contour "M0,0 C1,1 2,2 3,3 C4,4 5,5 0,0 Z" contains only two curve segments (or 6 points), whereas the second one "M0,0 C1,1 2,2 3,3 C4,4 5,5 6,6 Z" actually contains three segments (2 curves and a final closing line implied by Z, thus 7 points).
>>> from ufoLib2.objects import Glyph  # this would work exactly the same in defcon, fontParts, even robofab!!!
>>> g1 = Glyph()
>>> pen = g1.getPen()
>>> pen.moveTo((0, 0))
>>> pen.curveTo((1,1), (2,2), (3,3))
>>> pen.curveTo((4,4), (5,5), (0,0))  # last point == move; closePath is no-op
>>> pen.closePath()
>>> assert len(g1.contours[0].points) == 6  # 2 curve segments, 6 points in total
>>> g1.contours[0].points
[Point(x=0, y=0, type='curve', smooth=False, name=None, identifier=None),
 Point(x=1, y=1, type=None, smooth=False, name=None, identifier=None),
 Point(x=2, y=2, type=None, smooth=False, name=None, identifier=None),
 Point(x=3, y=3, type='curve', smooth=True, name=None, identifier=None),
 Point(x=4, y=4, type=None, smooth=False, name=None, identifier=None),
 Point(x=5, y=5, type=None, smooth=False, name=None, identifier=None)]
>>> g2 = Glyph()
>>> pen = g2.getPen()
>>> pen.moveTo((0, 0))
>>> pen.curveTo((1,1), (2,2), (3,3))
>>> pen.curveTo((4,4), (5,5), (6,6))  # last point != move; closePath adds implied closing line
>>> pen.closePath()
>>> assert len(g2.contours[0].points) == 7  # 2 cubic curves + 1 line segment, thus 7 points in total
>>> g2.contours[0].points
[Point(x=0, y=0, type='line', smooth=False, name=None, identifier=None),
 Point(x=1, y=1, type=None, smooth=False, name=None, identifier=None),
 Point(x=2, y=2, type=None, smooth=False, name=None, identifier=None),
 Point(x=3, y=3, type='curve', smooth=True, name=None, identifier=None),
 Point(x=4, y=4, type=None, smooth=False, name=None, identifier=None),
 Point(x=5, y=5, type=None, smooth=False, name=None, identifier=None),
 Point(x=6, y=6, type='curve', smooth=False, name=None, identifier=None)]

The two only appear to be compatible when looking at them as sequence of drawing pen commands, and importantly only when leaving the closing line in the second contour implied.
If you want to make two interpolatable contours where both contain two curves and one line, and the latter line collapses onto itself with zero length in the first contour, then you need to make the closing line explicit in both, e.g.:
"M0,0 C1,1 2,2 3,3 C4,4 5,5 0,0 L0,0 Z"
"M0,0 C1,1 2,2 3,3 C4,4 5,5 6,6 L0,0 Z"

move, curve, close (MCZ) is compatible with all other MCZ sequences

No, because closePath only adds a closing line when the last on-curve point != move point. When last is == move then the closing line does not get added. This is the way the fonttools pens that deal with converting between points and segment-oriented drawing commands have worked since the begininng, we can't just wake up on day and change it without major headaches.
It's not just FontTools that interpret it this way. E.g. take the popular kurbo Rust library (by our very own Raph):
use kurbo::BezPath;

let mut c1 = BezPath::new();
c1.move_to((0.0,0.0));
c1.curve_to((1.0, 1.0), (2.0, 2.0), (3.0, 3.0));
c1.curve_to((4.0, 4.0), (5.0, 5.0), (0.0, 0.0));
c1.close_path();

let segments: Vec<_> = c1.segments().collect();
assert_eq!(segments.len(), 2);
println!("{:#?}", segments);
/*
[
    Cubic(
        CubicBez {
            p0: (0.0, 0.0),
            p1: (1.0, 1.0),
            p2: (2.0, 2.0),
            p3: (3.0, 3.0),
        },
    ),
    Cubic(
        CubicBez {
            p0: (3.0, 3.0),
            p1: (4.0, 4.0),
            p2: (5.0, 5.0),
            p3: (0.0, 0.0),
        },
    ),
]
*/

let mut c2 = BezPath::new();
c2.move_to((0.0,0.0));
c2.curve_to((1.0, 1.0), (2.0, 2.0), (3.0, 3.0));
c2.curve_to((4.0, 4.0), (5.0, 5.0), (6.0, 6.0));
c2.close_path();

let segments: Vec<_> = c1.segments().collect();
assert_eq!(segments.len(), 3);   // <= no longer 2, as there's an extra line!
println!("{:#?}", segments);
/*
[
    Cubic(
        CubicBez {
            p0: (0.0, 0.0),
            p1: (1.0, 1.0),
            p2: (2.0, 2.0),
            p3: (3.0, 3.0),
        },
    ),
    Cubic(
        CubicBez {
            p0: (3.0, 3.0),
            p1: (4.0, 4.0),
            p2: (5.0, 5.0),
            p3: (6.0, 6.0),
        },
    ),
    Line(
        Line {
            p0: (6.0, 6.0),
            p1: (0.0, 0.0),
        },
    ),
]
*/

I don't remember where this rule about closePath actually comes from, but it's too entrenched by now and I would be very very wary to make such a change because I'm sure there is a lot of code out there that relies on this.

An outputImpliedClosingLine parameter only makes sense for the PointToSegmentPen, that is, the converter pen that translates from list of points to sequence of segment-oriented pen drawing commands, e.g. as used to draw UFO glyphs with a FontTools segment pen; and not also in the SegmentToPointPen (converting segment pen drawing commands to points), as proposed in #3094.
The decision there is whether to emit a final explicit lineTo for a closed path, or leave it implicit. By default, this is omitted when when last point != starting point unless the last point is of type "line" and has the same coordinates as the start point of the closed contour. In the latter case (and no matter whether outputImpliedClosingLine option is True or False) the PointToSegmentPen will always emits an explicit closing lineTo to prevent this duplicate last point to be dropped by SegmentToPointPen (which treats the last point of a closed path as the starting point when the two overlap one another).
When I undid behdad's change in https://github.com/fonttools/fonttools/pull/2995, I explicitly added tests that verified that the outputImpliedClosingLine parameter had no effect on the number of points (or segments if you prefer) actually present in a contour after it gets reversed by ReverseContourPen. See the following test cases which pass the same input contour through the pen, only parametrizing the outputImpliedClosingLine False/True, the result does not change after reversal, there are still only two curves before and after, and that's by design and how it should be!
https://github.com/fonttools/fonttools/blob/85c80be6b693b035ba7f716e703f8e69afb00de5/Tests/pens/reverseContourPen_test.py#L138-L167
Rod's PR https://github.com/fonttools/fonttools/pull/3094/ touched exactly that very test and made it so that after reversal the contour contains an extra line segment but when outputImpliedClosingLine=True.
But that parameter is meant to simply make what was implicit explicit, not change the contour itself, the number of segments or points.

This may be a tangential point, but with variable CFF2 fonts one should understand that all rrcurveto operators add 3 points to the contour, even when that curve is the last part of the contour. This means that a simple Bézier circle approximation, represented as 12 points in your font editor and in UFO, turns into 13 points inside the rasterizer. There is an implicit zero-length rlineto from the final point of the curve to the contour’s start point. In static fonts, there are no consequences. In variable, compilers must ensure that both the first and last curve point are moved to the same locations, so that the implied rlineto remains zero-length. Typically the two deltas are different since deltas accumulate around the contour.

If kurbo was not enough, I also made a little program that uses Inkscape's lib2geom to parse an SVG path into its own Geom::PathVector, count the number of segments in each subpath, reverse them using built-in Path::reversed() and asserts the number of segments does not change after reversal, finally print both original and reversed as svg path string.
https://github.com/anthrotype/2geom-toy
Here is its output with the two example contour from Rod's gist. Note how the number of segments is different:
$ ./reverse_path 'M0,0 C1,1 2,2 3,3 C4,4 5,5 0,0 Z'
Sub-path #0 has 2 segments and is closed
Original: M 0 0 C 1 1 2 2 3 3 C 4 4 5 5 0 0 z
Reversed: M 0 0 C 5 5 4 4 3 3 C 2 2 1 1 0 0 z

$ ./reverse_path 'M0,0 C1,1 2,2 3,3 C4,4 5,5 6,6 Z'
Sub-path #0 has 3 segments and is closed
Original: M 0 0 C 1 1 2 2 3 3 C 4 4 5 5 6 6 z
Reversed: M 0 0 L 6 6 C 5 5 4 4 3 3 C 2 2 1 1 0 0 z

Notice also how if I add an explicit closing line before Z, it doesn't change anything, same number of segments like before:
$ ./reverse_path 'M0,0 C1,1 2,2 3,3 C4,4 5,5 6,6 L0,0 Z'
Sub-path #0 has 3 segments and is closed
Original: M 0 0 C 1 1 2 2 3 3 C 4 4 5 5 6 6 z
Reversed: M 0 0 L 6 6 C 5 5 4 4 3 3 C 2 2 1 1 0 0 z

another gist showing how the two contours from the example would be deemed incompatible when drawn as is onto UFO glyphs and compiled interpolatably with ufo2ft, even before/without involving the ReverseContourPen:
https://gist.github.com/anthrotype/743e35caa217cb6fb555666c9f52f768

Rod and I chatted about this more, and I think there's a solution that might make everybody happy.
Currently when we reverse a contour, we start at the start-point of the original contour and reverse the direction. The first segment to add (or not) is the implied line-to by the closepath.
What if we instead start from the last-point of the original contour and reverse direction. Then the implied closepath line-to of the original contour will become the implied closepath of the new contour. Problem solved.

Vigorous thumbs up, ^ is better than both options we have on the table currently. I'll try it out when I have some free time.

@anthrotype the implication of this proposal is the start point will change. Does that break anything?

As I said, the problem is not the reverse operation, it's a more fundamental disagreement on the definition itself of a closed path. For Rod, every closed path must end with a (possibly degenerate) line segment. It's like we are saying "from tomorrow all closed contours will gain a +1 bonus point for free, courtesy of the SVG spec".

the start point will change. Does that break anything?

It would modify all fonts in production if we were to implement that by default so I would say yes, it would be breaking.
And it would not change the fact that those two contours would be incompatible, doesn't matter in which direction you see them.

The intended result is that:

The intuitive definition of interpolation compatible holds
We do not add extra points

That seems like a pretty good outcome to me. I understand it would modify fonts but it's not clear to me it would break them?

I'm afraid so I'll have to repeat myself as I run out of arguments, apologies for that.
There is currently no issue with the ReverseContourPen itself. It works fine and retains the same number of segments and keeps the starting point; if fed multiple contours that were interpolation compatbile before, they will continue to be so.
The issue here is not the contour reversing algorithm, but the very definition of what constitutes a closed contour. For fonttools, UFO, and all the font editors that I know of, this is sequence of adjacient curve or line segments, where the end point of one is the starting point of the next, and where the last segment's end point coincides with the contour's starting point, not in the sense that they are distict overlapping points, but in the sense that they are the very same point. (Think of act of dragging the end of the last segment onto the starting point of an open contour, and two points seamlessly fuse into one). There is no "implied" closing line in this definition. The last segment (i.e. the one whose end point also coincides with the starting point of the closed contour) needs not be a line, it can well and often is a (cubic or quadratic) curve.
Only when expressing such closed contours as sequence of (segment-oriented) pen drawing commands (e.g. moveTo, lineTo, etc.), there arise the possibility of omitting the lineTo command for the last segment and have that be implied by the closePath command, but that is purely out of convenience but does not change the essential nature of the contour (the number of segments/points it really contains); if the last segment (whose end point coincides with starting point) is not a line, the closePath does nothing else except communicating the intent that the contour is closed, i.e. the last segment's end point is the move point; if, on the other hand, the last segment is indeed a line, then it can be implied (omitted) and closePath closes off the contour with a line connecting the penultimate segment end point and the starting point; or it can be emitted explicitly and then the closePath is no-op, same as in the previous non-line case.
Rod is proposing to replace this definition of closed contour with one where the last segment is always a line, which sometimes has zero length. From this premise descends his conviction that his two example contours are interpolation compatible and fonttools should treat them as such.
I don't agree with this.

I think perhaps nuance is being lost wrt what I'm proposing. I'm suggesting that when presented via drawing commands, e.g. the pen interface, the only specs I have been able to identify - postscript/svg - seem to suggest you should get the zero-length line.
You can still eliminate unwanted points, but perhaps doing it blindly for all calls to close path on a pen isn't right, hence the churn and addition of things like always output implicit closing line to try to make it work nicely with interpolation.

Per f2f, the spec does appear to say to always emit it but that isn't helpful to fonttools due to implications on the point stream. We will explore always emitting the line, and using Behdad's revised reverse algorithm (only matters if you always emit the line) in fontmake-rs where the cost of doing something silly is much lower.


Samplesheets Vue app unit test improvements

Stuff left over from #750, because I wanted to wrap up that mega issue and continue with more pressing stuff to finalize the v0.9 milestone.
Tasks

[ ] Set up global warning suppression
[ ] Add extra editing tests after implementing #1036
[ ] Test AgGridDragSelect?
[ ] Solutions for bootstrap-vue testing issues? (see #1030 and #1034)
[ ] Set up coverage checking for both Python & Vue.js?

Tests will have to be reworked for #994 anyway, so this should be done for the new version once rewritten.


Add the job to upgrade the broker in eventing for 0.14

Fixes #
Proposed Changes

Release Note

/lgtm


check if resource types used in the VNF ARM template are valid

This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)

[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.
tested with invalid resource type in arm template by running "az aosm nfd build --definition-type vnf-nexus --config-file /home/priyavij/testbug/input.jsonc"

Looks good to me. One comment on the error


don't verify SSL certificates of css files

Amazone CDN: CloudFront fails.
To reproduce the problem try this:

import requests
requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css')
...
SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css', verify=False)
<Response [200]>

Please merge it and make a new release on PYPI. Thank you for your effort. This lib is great.

I'm inclined not to accept this patch, as I think that if someone chooses to serve their CSS over SSL/TLS, we should respect their wishes and make full use of what SSL/TLS offers.
On Windows 10 w/ Anaconda I get a warning, but it still works:
In [1]: import requests

In [2]: requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css')
C:\Users\Dan\Anaconda\lib\site-packages\requests\packages\urllib3\util\ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Out[2]: <Response [200]>

On Ubuntu 15.04, it works fine:
In [1]: import requests

In [2]: requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css')
Out[2]: <Response [200]>

Given the above, I think the problem is somehow related to the root certificates you have installed on the machine you're running this one. The certificate for that URL is the top-level wildcard *.cloudfront.net (which I use elsewhere with no problems).
I would try making sure your system time and date is correct (you could have a date/time set to when he certificate is no longer valid), doing a certificate update in the way that makes sense for your OS, and going through some of the suggestions here - the problem you're having is that requests can't find a valid root certificate to use with CloudFront.

thank you for quick reply. I’ll double check.

On 21 Oct 2015, at 16:46, Daniel Langer<EMAIL_ADDRESS>wrote:
I'm inclined not to accept this patch, as I think that if someone chooses to serve their CSS over SSL/TLS, we should respect their wishes and make full use of what SSL/TLS offers.
On Windows 10 w/ Anaconda I get a warning, but it still works:
In [1]: import requests
In [2]: requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css')
C:\Users\Dan\Anaconda\lib\site-packages\requests\packages\urllib3\util\ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Out[2]: <Response [200]>
On Ubuntu 15.04, it works fine:
In [1]: import requests
In [2]: requests.get('https://d2fd5orah3cbsb.cloudfront.net/CACHE/css/86199a1a6687.css')
Out[2]: <Response [200]>
Given the above, I think the problem is somehow related to the root certificates you have installed on the machine you're running this one. The certificate for that URL is the top-level wildcard *.cloudfront.net (which I use elsewhere with no problems).
I would try making sure your system time and date is correct (you could have a date/time set to when he certificate is no longer valid), doing a certificate update in the way that makes sense for your OS, and going through some of the suggestions here https://www.google.ca/search?q=routines%3ASSL3_GET_SERVER_CERTIFICATE%3Acertificate+verify+failed&rlz=1C1CHFX_enCA638CA639&oq=routines%3ASSL3_GET_SERVER_CERTIFICATE%3Acertificate+verify+failed&aqs=chrome..69i57j69i58j69i60&sourceid=chrome&es_sm=93&ie=UTF-8 - the problem you're having is that requests can't find a valid root certificate to use with CloudFront.
—
Reply to this email directly or view it on GitHub https://github.com/dlanger/inlinestyler/pull/18#issuecomment-149919271.

If you can curl the URL fine from that machine, try setting the REQUESTS_CA_BUNDLE  environment variable to whatever certificate chain OpenSSL uses (which could be /etc/ssl/certs/ca-certificates.crt, but might be something else)

Hi Daniel,
It helps with other sites, youtube for example.
But not with Amazone Cloudfront. I gave up and turned off that verification. Anyway it’s just a stylesheet.

On 29 Nov 2015, at 02:48, Daniel Langer<EMAIL_ADDRESS>wrote:
/etc/ssl/certs/ca-certificates.crt


Replace lambda with method reference in DefaultAuthenticationServer

Java 8 improvement: replace lambda with method reference in /alluxio/core/common/src/main/java/alluxio/security/authentication/DefaultAuthenticationServer.java#DefaultAuthenticationServer.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3195/
Test PASSed.

alluxio-bot, merge this please


Website size on Safari is not correct. Creates scroll bar.

Describe the bug
@vinayaksh42 raised this issue on a call with me as we were troubleshooting a PR.
In Safari, the website size does not match the initial frame of the website when it initially loads which creates a scroll bar on the right.

This combined with Shashwat's issue in this PR https://github.com/saving-satoshi/saving-satoshi/pull/146#issuecomment-1441809114 with safari as well, I'm going to open up a discussion for us to see if we want to continue to support safari as a browser since it has a tendency to have lots of bugs.

Closing this issue based on this discussion. https://github.com/saving-satoshi/saving-satoshi/discussions/216

Closed by #236


Checking if an object is an array

Is there a best practice to verify that an object is an array, e.g. during input checks?
Comparing types seems unfeasable, since the function will be be called with abstract array types during tracing.
Essentially i want to do something like
import jax.numpy as np

def is_array(obj):
   return type(obj) == np.ndarray

But also consider all jax types that might occur during tracing.
If it doesn't already exist, such an is_array function would be nice to have, especially if the abstract types used during racing should change in the future

@jekbradbury 's answer is the right one; though we might revise it (see #2014) right now you should check isinstance(x, jax.numpy.ndarray).
Hope that answers your question!


Exchange (WebDAV)

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue
Expected behavior
Tell us what should happen - I am trying to set up an exchange (WebDaV) email for my work email address but it doesn't work.
Actual behavior
Tell us what happens instead -Getting server error messages
Steps to reproduce

Entered server name
2.Entered username
3.tried to connecct to email exchange and got server error message

Environment
K-9 Mail version:5.202
Android version: 6.01
Account type (IMAP, POP3, WebDAV/Exchange): WebDAV/Exchange

Actually providing the error message is kind of useful...

Philip
Sorry, See attached.
Let me know if there is anything else I can do to help
On January 31, 2017 8:19:04 PM EST, Philip<EMAIL_ADDRESS>wrote:
Actually providing the error message is kind of useful...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/k9mail/k-9/issues/2163#issuecomment-276546135, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYSleHFG2IWhjeBsoINYPSuq58oeZITCks5rX92IgaJpZM4LzYK5.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Attachments to emails don't get uploaded to GitHub. Please use the web form.

Didn't see the portion of your question that requested the version.
Version is 14.3.301.4000 and I am using Outlook 2013.
I hope that helps

K-9 Mail supports using the WebDAV protocol to connect to Exchange servers. However, WebDAV is no longer supported by Exchange 2010 and newer, so K-9 Mail is not compatible with those Exchange versions.

https://k9mail.github.io/documentation/accounts/incoming_webdav.html
Duplicate of #606


netSLS with floodlight

How to connect netSLS with floodlight controller?

This has to be done while setting up MaxiNet. Please have a look at this guide: MaxiNet Quickstart. There it is described, how to set the controller (POX in the example). Just change the IP address and port to point to your running floodlight instance.


QuickSQL v1.3.3 \ QuickSQL.MicrosoftSqlServer v1.3.1

Update json result for:
https://github.com/The-Poolz/LambdaSet/issues/156

Important changes:
QuickSQL

now the result can be either an array or a single object.

QuickSQL.MSSQL

current SqlQueryCreator settings "FOR JSON AUTO, WITHOUT_ARRAY_WRAPPER".
Now the order in which parameters are passed to SelectedColumns decides the order in which values are returned.

Other

Discontinuing MySQL provider package support