[FEATURE] remove traefik lb pod when using --no-lb

Scope of your request
When launching k3d with --no-lb command this means you don't need a load balancer but the pods svclb-traefik and traefik are still running.
Describe the solution you'd like
I believe not launching the svclb-traefik pod and even the traefik pod  when using the --no-lb flag would make sense
Describe alternatives you've considered
I guess this could be done with a kubectl delete once the cluster is running but I believe this would make more sense to do it automatically.

Hi @sgandon, thanks for opening this issue.
The --no-lb flag only refers to the cluster-external loadbalancer, the serverlb container that is running alongside your node containers and does loadbalancing over the k3s server containers (e.g. for HA and easier ingress management, etc.).
svclb and traefik are in-cluster services managed by k3s, not k3d.
If you also don't need or want those, you can use --k3s-server-arg='--no-deploy=traefik' --k3s-server-arg='--no-deploy=servicelb' :+1:

I wonder what is the use case of run those loadbalancer and traefik without the external loadbalancer ? How can you leverage those loadbalancing without external loadbalancer ?
Indeed they are managed by K3s but why would you have them run in K3d without the external loadbalancer ?

The servicelb is managed by a part of k3s called klipper. It's there to enable you to use Kubernetes services of type: LoadBalancer which usually is not possible outside of a cloud provider.
Traefik is the ingress controller, so without it you wouldn't be able to use Ingress objects in Kubernetes.
So the k3d serverlb is completely decoupled from it. You can indeed use both servicelb and traefik (ingress) without having the serverlb in place (in fact the serverlb didn't even exist in k3d versions prior to v3). E.g. you just expose the ports on k3d nodes other than the serverlb.

Thanks for the details, so you mean  I don't need k3d LB even if I want to use the traefik ingress controller , that is great news, then what is the usage of the extra k3d docker loadbalancer container ?

Load balancing requests to the server nodes e.g. for kubectl, easing port mapping for cluster creation and stuff like that 👍

feel free to close this ticket if you will.
I believe this external loadbalancer should be documented somehow. It is still unclear for my use case in a single node cluster what it is used for.

For the sake of completness, if you want to remove traefik do not use --no-deploy=traefik but use --disable=traefik.

feel free to close this ticket if you will.
I believe this external loadbalancer should be documented somehow. It is still unclear for my use case in a single node cluster what it is used for.

In a single-node cluster it's only benefit is being able to expose ports after cluster creation (as a feature to come in the future).
Additionally, it allows you to add more master nodes seamlessly (once we fixed the cluster-init issues).
If you don't need it, disable it :+1:

For the sake of completness, if you want to remove traefik do not use --no-deploy=traefik but use --disable=traefik.

Ah true, didn't know the --no-deploy flag got deprecated :+1:


Templated pages do not build for "off page" links on DataTable

Steps To Reproduce

Create a DataTable which contains links to a templated page per row
Create > 10 rows, but only display 10 on the first page
Deploy the site (or npm run build and inspect the assets created)
Attempt to navigate to one of the templated pages that is not shown on the first page of table results on the deployed site

Expected Behavior
The templated page is loaded
Actual Behaviour
There is no page, you get a 404

https://github.com/evidence-dev/evidence/assets/58074498/c12c4271-b286-43e7-b0c7-4b87f029a0f3
Why does this happen

Evidence renders a site statically: It has to know the links for all the pages in advance.
Evidence crawls the site, and finds all the links to other pages.

Any pages it finds links for, it builds

When a table is included, only the rows in the first page of the table are included in the static render

The other rows in the table are rendered dynamically using js when the user goes to later pages of the table.

So when evidence does the crawl it only finds the links that are visible in page one, and only these are built

Workarounds
You need to make sure that every page you want to render has a link somewhere in Evidence that will be picked up at build time. Some options:

Extend the number of displayed rows of your table so that all auctions are visible
Add links to all the pages elsewhere on the site

using an unordered list of all the items on a page
Or perhaps by putting a link to "next item" on all items, so that the pages self reference to each other.

Related Slack Thread

Somewhat related: https://github.com/evidence-dev/evidence/issues/1046

Could also do something like:
    {#if link}

            {#each Array.from(new Set(data.map(row => row[link]))) as unique_link}
                a
            {/each}

    {/if}

Inside DataTable.svelte

Interesting.
A nice thing about a more general solution is that I suspect there may be other components that have this behaviour too.
What if the only link to a page is inside a modal, for example? Would that render?

I believe it's just any links that are present when SSR happens, so no for the modal

Hey team! Please add your planning poker estimate with Zenhub @csjh @ItsMeBrianD

Relevant SK source:
for (const href of hrefs) {
    if (!is_root_relative(href)) continue;

    const { pathname, search, hash } = new URL(href, 'http://localhost');

    if (search) {
        // TODO warn that query strings have no effect on statically-exported pages
    }

    if (hash) {
        const key = decode_uri(pathname + hash);

        if (!expected_hashlinks.has(key)) {
            expected_hashlinks.set(key, new Set());
        }

        /** @type {Set<string>} */ (expected_hashlinks.get(key)).add(decoded);
    }

    enqueue(decoded, decode_uri(pathname), pathname);
}

(context: enqueue queues a page to be parsed for hrefs to run through this same loop)
So yeah no way to pass page params or hash through to tell the DataTable to cycle through the pages

Fixed by #1132


Revisit PICA encoding of decomposition

Decomposition as created by DNB (this record):
045H/10 $eDDC23ger$a700.90440747471$c700.904$f09044$f0901-0905:074$g7471$ADE-601

Decomposition by coli-ana API:
045H/10 $eDDC23ger$a700.90440747471$c7$f09044$f074$g7471$Acoli-ana

In the interface the elements are 700.904, T1--09044, T1--0901-0905:074, and T2--7471 so there seems to be a bug in mapping to PICA.

Duplicate of #34


x/tools/internal/lsp/regtest: tracking various regtest improvements

This is a follow-up to #36879.  We've been using the gopls regtests for a few months now, and several usability bugs / missing features / overall themes have emerged.  None of these seemed worthy of an issue, but I want to track them in aggregate.  I've been trying to let the regtests soak in their current form, but plan to take another pass soon.
Here's a list of what I've noted along the way, either from my own usage or feedback from others'. Feel free to comment with more, and I'll edit this comment to keep it up to date.

[ ] Once @ianthehat's jsonrpc2 shutdown fixes are merged, we should t.Parallel the regtests once more.
[x] Add more documentation about how to develop new regtests (tricks like using -regtest_timeout to avoid waiting for the default regtest timeout).
[x] Having the run options after the test body in runner.Run is hard to spot. Use a different options pattern to allow passing them before the test body.
[x] Fix the 'NoOutstandingWork' expectation, by making sure that 'progress finished' messages never fail to be sent due to a cancelled context.
[x] Somehow fix regtest cleanup on Windows (which runs into problems with file locking from the go command). Perhaps awaiting 'NoOutstandingWork' could help here.
[x] Move regtests into the gopls module, so that they can run staticcheck.
[ ] Once regtests are in the gopls module, replace the synthetic file watching with actual file watching, using fsnotify. The fact that file-watching is faked has been a source of bugs. The file watching should also respect the GlobPattern provided in the file watching capability registration.
[ ] Make the DiagnosticAtRegexp expectation lazy, so that it doesn't eagerly evaluate the regexp position (and therefore no longer needs the Env receiver).
[ ] Make DiagnosticAtRegexp match the full range of the regexp match, not just the starting position (this was a cause of some confusion in a CL).
[x] ~Return a copy of State from Await: whatever caused expectations to be be met~ (the underlying requirement was instead achieved with less effort by adding a 'ReadDiagnostics' expectation that atomically reads from State).
[x] Explicitly set GOPACKAGESDRIVER=off for all regtests.
[x] Use a top-level TMPDIR for the entire regtest suite, rather than letting each regtest create it's own sandbox in /tmp. This reduces cruft in /tmp when tests are ctrl-c'ed before they can clean themselves up.
[x] Add continuous integration to run the regtests against a true daemon, not an in-process daemon. This is not done currently because it will be problematic on Windows, and would increase the test duration.
[x] Fix handling of multi-byte runes in source text.
[x] Remove the need to count didChange/didOpen requests when writing expectations.

CC @pjweinbgo @stamblerre @heschik

I think we've done enough here.


Transformer: support babel targets

https://babeljs.io/docs/options#targets

https://github.com/oxc-project/oxc/pull/3371


Improve state machine client code

Using state machines on the client side still involves some boilerplate: Initialising the contract with role tokens and the thread token, wiring user-facing endpoints to transactions, etc. Some of that is unavoidable (for example, when a single user input results in multiple transitions of the state machine), but I think we can make this easier for a numer of simple cases. In particular:

Add a type of state machine where the transitions are parameterised by the role that is allowed to do it
In the client code we need to be aware of our own role
When the SM starts set up all the tokens
When the SM is running, we need to be aware of our own role in the contract

if we can perform a transition, expose an endpoint to the user to trigger it
if we are waiting for someone else to do something, we watch the blockchain for changes to the state

With this scheme it should be possible to turn a state machine (defined by its transition function) into an executable contract without much extra work. Possibly just a single function.

Moved to JIRA (this is just for reference)


Suggestion: Have a library of stored patterns / regexes

Have a way to store a regexp and to navigate stored ones.

This sounds like a really cool Idea! If you want you can provide a PR that will implement it :)


Raw MARC record is not written to sourceRecordStorageObject

in OrderImport, a MarcWriter is instantiated with the following lines:
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
MarcWriter w = new MarcStreamWriter(byteArrayOutputStream, "UTF-8");
AnselToUnicode conv = new AnselToUnicode();
w.setConverter(conv);

Further down, when it is writing data to the source record, it instantiates another ByteArrayOutputStream and writes the raw record to it:
ByteArrayOutputStream rawBaos = new ByteArrayOutputStream();
MarcWriter writer = new MarcStreamWriter(rawBaos);
writer.write(record);

It then uses the original byteArrayOutputStream for adding the content to the jsonWithRaw object and eventually posted to to source-storage/records.  As a result, the raw record is never actually copied to source storage.
to fixe this, the original instantiation of the MarcWriter can be removed and the rawBaos instance used instead.  Open question is whether the writer should be instantiated using the AnselToUnicode converter.
jsonWithRaw.put("content", byteArrayOutputStream);

As it turns out, the raw records, after being transformed to json aren't being saved either.  The following code writes the record to the "content" object, but it's not saved
logger.trace("MARC RECORD: " + record.toString());
 ByteArrayOutputStream baos = new ByteArrayOutputStream();
MarcJsonWriter jsonWriter =  new MarcJsonWriter(baos);
jsonWriter.setUnicodeNormalization(true);
sonWriter.write(record);
jsonWriter.close();
String jsonString = baos.toString();
JSONObject mRecord = new JSONObject(jsonString);
JSONObject content = new JSONObject();
content.put("content", mRecord);
logger.trace("MARC TO JSON: " + mRecord.toString(3));

@fereira, temporarily assigning to myself as I investigate the bigger picture of SRS integration with this app.


resolve_local_name fails for param case

resolve_local_name currently does not handle this case:
fn foo(i<|>: u32) -> u32 {
    i
}

in this case i is not a ast::NameRef I believe it is a bind pattern. Should resolve_local_name be able handle this case (effectively returning the current cursor position)? Found when implementing #135 since this will return no references.

Is this new API something you envision the LSP would consume directly?
Do you see something like: analysis.get_decl_descriptor(TextRange) -> Option<DeclarationDescriptor> and then the DeclarationDescriptor::find_all_references would call back into analysis on demand?

I definitely like the idea of separating out the syntactic/semantic APIs. It's something I've been struggling with and will become more important as we flesh these features out.


[BUG]Office and wps height inconsistency.

screenshot
Office:

WPS:

Code
sheet.addImage(img, {
                      tl: {
                        col: col + 0.02,
                        row: row + 1.02,
                      } as any,
                      ext: {
                        width: 100,
                        height: rowHeight + 20,
                      },
                      editAs: 'oneCell',
                    });

You probably meant to raise the issue elsewhere (not this repo), but it wouldn't be surprising if WPS had a different internal PPI from Excel.


PNG support?

I see this doesn't seem to work with transparent PNG images? Are there any plans for the future to add PNG support or any way to get it working now?

same issue here...


fix: Bring back additional artwork screen tracking fields

The type of this PR is: Bugfix

This PR resolves []
Description
Bring back additional artwork screen tracking fields.
PR Checklist (tick all before merging)

[ ] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[ ] I have tested my changes on iOS and Android.
[ ] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[ ] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added an app state migration, or my changes do not require one. (What are migrations?)
[ ] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Warnings

:warning:

❌ An error occurred while validating your changelog, please make sure you provided a valid changelog.

  Generated by :no_entry_sign: dangerJS against 921452f529bd5df2146c1f9d62c7751ee5970652


Remove duplicate localization

Related issues

closes #
Short description and why it's useful

Removed duplicate entry for the Customer service (Magento CMS) from en-US.csv

Screenshots of visual changes before/after (if there are any)

Which environment this relates to
Check your case. In case of any doubts please read about Release Cycle

[X] Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
[ ] RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
[ ] Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

[x] No upgrade steps required (100% backward compatibility and no breaking changes)
[ ] I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change
Contribution and currently important rules acceptance

[X] I read and followed contribution rules
[X] I read the TypeScript Action Plan and adjusted my PR according to it
[X] I read about Vue Storefront Modules and I am aware that every new feature should be a module

Thanks! :)


builder all should not try to run aysfs

Reproduce
-j.tools.cuisine.local.builder.all(start=True)
-will not be able to mount to /opt
goal
make the builder only build fs even if it is given start

https://github.com/Jumpscale/jumpscale_core8/pull/262


bug(material): activated nav-list-item font color is not readable in dark mode

Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
I have an App that uses a sidenav with a nav-list inside. I want the activated nav-list-item to be noticeable, so I'm using that state, but the default behavior with a dark theme, results in an unreadable font color.
Reproduction
StackBlitz link: https://stackblitz.com/edit/components-issue-3qaoos
Steps to reproduce:

Open it.
See how the first nav list item is activated and barely readable.

Expected Behavior
The background and font color have a minimum contrast, so the item is readable.
Actual Behavior
The background and font color do not have a minimum contrast, so the item is not readable.
Environment

Angular: 16.1.0
CDK/Material: 16.1.5
Browser(s): Chrome 116.0.5845.97 (Official Build) (64-bit)
Operating System (e.g. Windows, macOS, Ubuntu): Windows 11 (10.0.22621.2134)

This is something that should be changed in the purple-green prebuilt theme

This is something that should be changed in the purple-green prebuilt theme

Not only that theme. If, in the StackBlitz, you change the import for @import '~@angular/material/prebuilt-themes/pink-bluegrey.css';, you'll see the other dark prebuilt theme is also not as readable as one would want. Not as terrible as the purple-green one, but not fully accessible, nonetheless.
Contrast ratio (according to Edge's CSS Overview Dev Tools):

purple-pink: 1.22
pink-bluegrey: 1.71

If one needs a contrast ratio of 4.5 for AA, and 7 for AAA, none of these prebuilt themes passes the test.


Upgrade Gradle and dependencies

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

Coverage data is based on head (6bf6673) compared to base (bd1ccab).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##              master       #37   +/-   ##
===========================================
  Coverage     100.00%   100.00%
  Complexity        20        20
===========================================
  Files              2         2
  Lines             22        22
===========================================
  Hits              22        22

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

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


support AuthLevel.REQUIRED annotation

It is currently not easy to support all AuthLevel modes, but REQUIRED
is likely to be the the most used and easy to implement, so support is
added here.

Codecov Report

Merging #117 into master will increase coverage by 0.02%.
The diff coverage is 75%.

@@             Coverage Diff             @@
##             master    #117      +/-   ##
===========================================
+ Coverage     79.68%   79.7%   +0.02%
- Complexity     1643    1646       +3
===========================================
  Files           156     156
  Lines          5523    5529       +6
  Branches        706     708       +2
===========================================
+ Hits           4401    4407       +6
+ Misses          846     844       -2
- Partials        276     278       +2

Impacted Files
Coverage Δ
Complexity Δ

...ver/spi/request/RestServletRequestParamReader.java
92.59% <100%> (ø)
21 <3> (ø)
:arrow_down:

.../server/spi/request/ServletRequestParamReader.java
84% <71.42%> (-0.88%)
24 <0> (+2)

...api/server/spi/response/UnauthorizedException.java
50% <0%> (+4%)
7% <0%> (+1%)
: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 058d3ad...86a7e73. Read the comment docs.


Great library

Really cool adaptation of vite-ssg to react. GG!

Thanks! Tanstack Router will be supported in the next step, and you can provide more optimization suggestions.


Use of FastAdapter with sqlite data

Mike, another question :
I'm trying to use your FastAdapter lib to fill an expandable recyclerview (from two master/detail tables).
Usuallly, with classic recyclerview, I'm used to read data with cursor loaders.
In your sample app, your expandable recyclerview is filled with two array in an iteration.
Is there a way to do the same thing with cursor loaders ?
If not, i'll fill arrays but i'm afraid this is not very safe !
What do you think about this ?

@engi there is no adapter which directly accesses a cursor. So this doesn't exist yet. It should be possible to implement a CursorAdapter implementing the IAdapter interface, but will require some code.
If you want to add such a functionality to the library it will be great.


test: update inflation unit-tests

Description

Closes: #XXX
PR Checklist:

[ ] Have you read the CONTRIBUTING.md?
[ ] Does your PR follow the C4 patch requirements?
[ ] Have you rebased your work on top of the latest master?
[ ] Have you checked your code compiles? (make)
[ ] Have you included tests for any non-trivial functionality?
[ ] Have you checked your code passes the unit tests? (make test)
[ ] Have you checked your code formatting is correct? (go fmt)
[ ] Have you checked your basic code style is fine? (golangci-lint run)
[ ] If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
[ ] If your changes affect the client infrastructure, have you run the integration test?
[ ] If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
[ ] If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] confirmed that this PR does not change production code

Codecov Report

Merging #92 (7dc11f0) into main (f82f6be) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #92      +/-   ##
==========================================
+ Coverage   74.59%   74.67%   +0.08%
==========================================
  Files          22       22
  Lines        1842     1848       +6
==========================================
+ Hits         1374     1380       +6
  Misses        428      428
  Partials       40       40

Impacted Files
Coverage Δ

x/inflation/types/genesis.go
78.57% <ø> (ø)

app/upgrades/v1_1/upgrades.go
91.89% <100.00%> (ø)

x/inflation/keeper/hooks.go
95.18% <100.00%> (+0.81%)
:arrow_up:

x/inflation/types/params.go
85.24% <100.00%> (-1.33%)
:arrow_down:


Single File Picker reading the selected file as stream

Which sample are you requesting a feature to be added to?
FilePicker: update current Single File Picker so it actually access the file content
Describe the feature
The current example states the picked file has read/write access, but it is not tested as just file name is used:
// Application now has read/write access to the picked file
OutputTextBlock.Text = "Picked photo: " + file.Name;

However, when using direct access I am getting famous UnauthorizedAccessException:
using (FileStream fileStream = new FileStream(file.Path, FileMode.Open))

That exception is thrown regardless the file location: in Downloads, Documents or arbitrary folder on C:\ drive.
I suppose there is something what needs to be tweaked, but it is not clear from the original example.

The FileAccess sample shows how to read from a file. See Scenario 5.


REopt integration not working for Generic-Battery configurations

To reproduce:

Create Generic-Battery, Residential case.

On Battery Cell and System page, click Get size and dispatch.

UI callback error:
Could not evaluate callback function:call_reopt->on_change
[5]: error: _s
[5]: error: _s
[4]: eval error in statement list

The error is caused by this line in the on_change{'call_reopt'} function in the Battery REopt Optimization callback script:
	wf_len = 60 / ${ui_step_minutes} * 8760;

For the PV-Battery configuration ui_step_minutes is set by an equation on the Solar Resource Data UI form, but the Generic-Battery configuration does not use that form.
One solution is to set ui_step_minutes in an equation on the Generic System Plant page because the options on that page determine the simulation time step.
A better solution would be to detect the simulation time step without referring to inputs on other forms to minimize risk of breaking the REopt call. As we make changes to the Solar Resource or Generic System Plant page, we may not be aware of the connection to the REopt call.
https://sam.nrel.gov/forum/forum-general/3098

Thanks for posting and looking through why it may not be working! Unfortunately, the ReOpt sizing fxn is not meant to be used with the Generic Battery at all. It's tightly coupled with PV simulations, and will expect PV-related inputs. So I think the best solution is to remove that from the Generic Battery configurations


Reducing size and dependencies

We're currently generating a huge library that Android developers have to include in their projects, the reason is that we're including a lot of stuff from flashlight that might not be used by Android clients.
If we reduce the number of dependencies to only the minimum necessary the size would likely be reduced as well.
I think we could start by trying to get a minimal client based on github.com/getlantern/fronted.

Hello @oxtoacart!
I think I need a bit of help here: I tried to import github.com/getlantern/fronted from another package, but it fails with an error that is being originated in fronted itself, this error I'm talking about is the same we see when trying to get the fronted package with go get -u:
go get -u github.com/getlantern/fronted
# github.com/getlantern/fronted
../fronted/dialer.go:145: unknown enproxy.Conn field 'Addr' in struct literal
../fronted/dialer.go:146: unknown enproxy.Conn field 'Config' in struct literal
../fronted/dialer.go:179: unknown enproxy.Conn field 'Addr' in struct literal
../fronted/dialer.go:180: unknown enproxy.Conn field 'Config' in struct literal

At first I thought it was that my enproxy was a bit outdated, but the error persist even after updating it:
go get -u github.com/getlantern/enproxy

Maybe I'm targeting the wrong branches, does the error look familiar to you?
Thanks!

@xiam The main repos for a lot of our libraries have probably gotten out of date.  We're doing most of our work in the flashlight-build repo, and only occasionally pushing out to the main repos.
Your best bet is probably to branch the flashlight-build project and then add your work as another item in there.  That'll also help ensure that the mobile and desktop clients are working from the same versions of the libraries.

@oxtoacart Yeah, that worked. I'll stick to the flashlight-build repository then. Thank you!

@xiam You're welcome!  I hope building using just fronted instead of the full flashlight will make your life easier :)

Hey @myleshorton,
I think I'm getting some progress here, I was able to create a working proxy using some Go standard libraries plus getlantern/balancer and getlantern/fronted. Now I have some questions:

We're currently using roundrobin.getiantem.org as the only fronted server, for testing purposes. I understand that flashlight can update this fronted server list from the network and store it in a configuration file, but in the Go+Android case writing to file system is not that easy, we can surely hack a way to save this list to permanent storage but I think an easier way is providing a method like AddFrontedServer(addr string) to the Java program, so the actual app is the responsible for keeping a list up to date as it's easier for the app to access permanent storage. What do you think?
What does the ChainedServers property do? Would it be useful for Android too?

I'll still need to work a bit on this code, I just wanted to do a quick test to make sure it could be done.

We're currently using roundrobin.getiantem.org as the only fronted server, for testing purposes. I understand that flashlight can update this fronted server list from the network and store it in a configuration file, but in the Go+Android case writing to file system is not that easy, we can surely hack a way to save this list to permanent storage but I think an easier way is providing a method like AddFrontedServer(addr string) to the Java program, so the actual Android app is responsible for keeping a list up to date as it's easier for the app to access permanent storage. What do you think?

Yeah interesting. Lantern/Go both just dynamically download them and then store them, which you probably saw, but it could just download, not store, and call the method. Also with built-in automatic updates, it should be less of an issue because we can always just update the hard-coded list with the full client.
The actual domain fronts at this point should be a list of about 1000 domains, and roundrobin.getiantem.org is technically where they front to. So we still want to have a hard-coded list of those domains, associated pinned certs, and IPs hard coded in the client.

What does the ChainedServers property do? Would it be useful for Android too?

That basically will relay to a traditional proxy. So flashlight is the first proxy in the "chain" and a normal HTTP proxy running on a server somewhere is the second. I think we should just skip that for Android, though, because we don't have a good blocking-resistant way of distributing them.

I compiled a very basic test library with no imports besides the Go-Java bootstrapping libraries, its size was 2732b, so I'm assuming we can't go lower than that. I'm using that number to compute the Relative size column in the following table that illustrates the sizes of the compiled libgojni.so:

Library
Absolute size (b)
Relative size (b)

Old libgojni.so
8488
5756

Current libgojni.so
6452
3720

Reduction
31%
54%

I frankly was expecting more reduction than that.
This fronted wrapper has the ability to stop the http server at will, so the proxy can now be stopped and restarted within the Go program space, without the need of using Java threads to avoid blocking! A direct consequence is that the example code was also simplified.
Balancer and reverse proxy are now implemented with channels as in the original flashlight client.
The issue with the list is still pending, we can have a fixed list and also update that list from the network, as @myleshorton proposed. I'm looking into that too.

@xiam Nice!

I frankly was expecting to see a greater reduction, but cutting a third from the original size is not that bad.

Yeah, that's the one downside to Go.  If you import net and net/http, I bet you'll see that a lot of the size is consumed by those.
The other benefit to what you've done other than size is simplicity, which is worth a lot too.

The other benefit to what you've done other than size is simplicity, which is worth a lot too.

Yup I actually wasn't even initially thinking about the size but only the simplicity, so I totally agree there's a huge win there as well. It should also significantly reduce the overall diff. Is this all actually captured in that initial PR, or maybe it's not quite ready to pull yet is that right @xiam? Great stuff either way.

@myleshorton I actually closed the initial PR as it is not required anymore :-), no need to add build tags for this one, we just need to keep balancer and fronted as light as we can. I'm planning to copy lantern-android to flashlight-build and create a new PR but I shall finish the issue with the fronted server list first.

@oxtoacart should I target the tcpproxying branch of flashlight-build as the origin for this eventual PR?

@xiam You can actually target devel now, since we've merged tcpproxying into devel already.

@oxtoacart Another one, I've borrowed the static masquerade and root CA list from masquerades.go and tested it, works beautifully. Now, a huge improvement would be the ability to download and parse the cloud.yaml file referred in ./flashlight/genconfig/updateyaml.bash to keep the internal list up to date (if we can't download this cloud.yaml file we can always fallback to the defaults). What's the permantent URL of this file? Thanks again!

This is the current config @xiam:
https://s3.amazonaws.com/lantern_config/cloud.1.5.11.yaml.gz

Actually check that. The latest is at:
http://s3.amazonaws.com/lantern_config/cloud.1.6.0.yaml.gz

Got it @myleshorton!

I solved our pending issue with the configuration file this way: when the application starts it will immediately look for a configuration file over the network, if this can't be done for some reason, or if the configuration file is invalid (wrong format, no useful data, etc) the application will fall back to the default embedded configuration.
I think it would be useful to have a https://getlantern.org/config/cloud.yaml.gz?v=$LANTERN_VERSION URL that redirects to the latest version of this configuration file for a given lantern client version, but for now the S3 URL works beautifully :-).
I'll copy my new repo on the devel branch of flashlight-build and will update the README.md accordingly.

Awesome @xiam! There are two big issues with the URL you mentioned as is (the https://getlantern.org/config/cloud.yaml.gz?v=$LANTERN_VERSION URL). The first is that getlantern.org is blocked in all of these regions, so we can't run anything on that domain. That's really a larger issue though -- we can't run it on any of our domains or IPs because it'll just get blocked. That's why we only put files like that on either amazon or GitHub over HTTPS (HTTPS since the censor can't tell where you're going then and would have to block all of Amazon or GitHub). In fact, we should really be putting that file on GitHub because S3 is blocked quite a bit.
That also means, though, that it can't be dynamic either. We can easily just update those fixed URLs for the different versions, though, or do something we just always update like:
https://getlantern.org/config/latest.yaml.gz

@myleshorton Oh, of course! I didn't think of that. Maybe we could also consider mirroring the config files on many different locations or CDNs that support HTTPS? The client could try each one of these different sources until succeeding and, if everything else fails, it could always fall back to its default values.

Yeah totally. At one point we were looking at setting up links on mega but just got pulled away to other things. Right now we just have S3 and GitHub where all installers are automatically copied, but we should really just universally put things like that on any site we have access to that's unblocked.
Oh, also, on that last URL I meant to say:
http://s3.amazonaws.com/lantern_config/latest.yaml.gz
and not getlantern.org


'...has no OSAXHandlers entry in its Info.plist'

I tried to use Notify() and that was shown correctly exactly one time. After that I get always an error message:
osascript: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" cannot be used with the current OS because it has no OSAXHandlers entry in its Info.plist.146:161: syntax error: A identifier can’t go after this “"”
So I assume the problem is in "/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/Info.plist" ?
But I do not see anything strange there. Although I have no idea what to look for ;-)
See the contents below.
Any ideas are very much appreciated !
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>English</string>
	<key>CFBundleExecutable</key>
	<string>Adobe Unit Types</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundlePackageType</key>
	<string>osax</string>
	<key>CFBundleSignature</key>
	<string>ascr</string>
	<key>CFBundleVersion</key>
	<string>2.0.0</string>
	<key>CSResourcesFileMapped</key>
	<true/>
</dict>
</plist>

Solved. Turns out a passed string to Notify() should never ever have any "-chars.


Can it downgrade for running on V100?

I had run webui.py, but errors occured on generating 4 views.
otImplementedError: No operator found for memory_efficient_attention_forward with inputs:
query       : shape=(10, 6144, 1, 64) (torch.bfloat16)
key         : shape=(10, 6144, 1, 64) (torch.bfloat16)
value       : shape=(10, 6144, 1, 64) (torch.bfloat16)
attn_bias   : <class 'NoneType'>
p           : 0.0
decoderF is not supported because:
attn_bias type is <class 'NoneType'>
bf16 is only supported on A100+ GPUs
<EMAIL_ADDRESS>is not supported because:
requires device with capability > (8, 0) but your GPU has capability (7, 0) (too old)
bf16 is only supported on A100+ GPUs
cutlassF is not supported because:
bf16 is only supported on A100+ GPUs
smallkF is not supported because:
max(query.shape[-1] != value.shape[-1]) > 32
dtype=torch.bfloat16 (supported: {torch.float32})
bf16 is only supported on A100+ GPUs
unsupported embed per head: 64

https://developer.nvidia.com/cuda-gpus
The "requires device with capability" part points to this, which means it requires at least RTX 30 or 40-series GPUs (and their enterprise counterparts). Need to add settings that support older cards and apply it automatically once it detects your GPU type.

You can try turning off this option memory_efficient_attention_forward to run this code. V100's memory is enough.

Where can we find this option?

You can try turning off this option memory_efficient_attention_forward to run this code. V100's memory is enough.

Is it the flag enable_memory_efficient_attention in 3D_Stage/configs/infer.yaml? But it occurs in two places in this file, one in image_tokenizer and the other in backbone. Which one should I turn off?

You can try turning off this option memory_efficient_attention_forward to run this code. V100's memory is enough.

Is it the flag enable_memory_efficient_attention in 3D_Stage/configs/infer.yaml? But it occurs in two places in this file, one in image_tokenizer and the other in backbone. Which one should I turn off?

Update: I turned both off, it doesn't help, the same error appears.
If the dev didn't just leave while refusing to elaborate further, we would have a easier time.


Fluid identification refactoring

Description of the problem
We currently use a confusing mechanism for the physical properties of the fluid. Originally, the code was not meant to have more than a single fluid, so all properties were indicated in the physical properties section. As we introduced the VOF model, things became confusing. We have fluid 0  and fluid 1 section for the fluid properties of the two fluids, but these sections are not used when the simulation is single phase.
Description of the solution
This PR makes the single and multiphase simulations coherent by introducing the usage of the fluid subsection even if simulations are single phase. Consequently, even single phase simulations use the fluid 0 subsection.
How Has This Been Tested?
All tests had to be adapted to this change in properties. Consequently, this feature is fully tested
Future changes
The next step will be the generalisation of the properties using physical properties model and to adapt the non-newtonian solver logic to this. I prefer to do it step-by-step. Once this will be finished, we will be able to use single and vof phase change and non-newtonian flows. Since this is a major breaking PR, I prefer to make it small.

That makes a lot of sense. In a next pull request, do you intend to put the non newtonian parameters in the FLUIDS struct? Everything seems good to me!

Yeah exactly. This way we could automatically have a two fluid model with two different rheology and everything would work out of the box, it's the next logical step. The only part that would remain outside is the non-newtonian boolean.


Improve GroupBy documentation

fix #261

Codecov Report

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

@@           Coverage Diff           @@
##           master     #262   +/-   ##
=======================================
  Coverage   90.61%   90.61%
=======================================
  Files          20       20
  Lines        1343     1343
=======================================
  Hits         1217     1217
  Misses        126      126

Impacted Files
Coverage Δ

src/library.jl
94.01% <ø> (ø)

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 0c8944a...6dc4b98. Read the comment docs.


Calendar misaligned labels

I have a question regarding the styling of the calendar widget.
Whenever any padding is added to days it causes a top aligned date to display.
Is there any way to center these?
This question has been asked in another issue, however that one was marked as closed before the question was asked:

I just whipped up a quick example, you can style the current day using the selected state.
.calendar {
    padding: 12px;
}

.calendar:selected {
    background: teal;
}

Note: This highlights the selected day, by default the selected day will be the current day however other days will be selected when you click on them.

Did anyone figure out how to center the days? This is so unusable
Originally posted by @beyond9thousand in https://github.com/elkowar/eww/issues/378#issuecomment-1249791129

In general the documentation is super lacking for this particular widget (calendar). As you say it's basically unusable as there's no way to know how to target the elements within it. Very limited ability to customize it overall. 🤷 Might as well implement our own calendar widget.

The general issue is that these are GTK questions -- Whilst the GTK documentation is definitely lacking, especially in the CSS context, ensuring that every bit of available GTK css is fully documented as part of eww is sadly very out of scope, effort wise. Thus, your best bet for these sort of things is to either check if you can find sufficient GTK documentation about the CSS structure of the calendar widget, or to play around in eww inspector until you find something :/

Oh I see, so this isn't an eww widget, but a GTK widget. That makes a lot of sense -- I see now why it isn't very useful to us.
Thanks for clarifying!


Jesse: Watch hostyhub.com

Jesse requests the watch of the watch_keyword hostyhub\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

hostyhub\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


[20.03] adobe-reader: add knownVulnerabilities

Motivation for this change
We should really avoid that people unknowingly use Adobe Reader, it
has literally tens of known high-score code execution vulnerabilities,
probably exploited in the wild.
(cherry picked from commit 4b07b00c0de3f6c5755048038ae49c57f86b7e40)
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

We should probably indicate that Adobe is not maintaing the Linux version of the Reader anymore and that this is the last version. Therefore no fixes can be expected.

We should probably indicate that Adobe is not maintaing the Linux version of the Reader anymore and that this is the last version. Therefore no fixes can be expected.

Or maybe we should say that it will be removed at some future date? (when?) It probably does not make much sense to keep these old, unmaintained proprietary projects. If someone really needs it, they could add it to the NUR or make a flake.

Yes, probably remove, after some time in the "vulnerable" state... though not on 20.03.

Let's not wait anymore.  Merging doesn't prevent further improvements to the message, etc. (first in master, though)


when we use @Param annotation, like this param.field, that cause my custom TypeHandler dosen't work

MyBatis version
mybatis:3.4.6  mybatis-spring-boot-starter:1.3.2
Database vendor and version
mysql:5.7
Test case or example project
git: https://gitee.com/jervain_y/demo-mybatis.git
Steps to reproduce
run testcase
Expected result
when we use @Param annotation, like this param.field, that cause my custom TypeHandler dosen't work
Actual result
this is run log
2019-01-15 14:15:05.393 DEBUG 6460 --- [           main] com.example.demo2.AMapper.updateMyOne    : ==>  Preparing: update a set demo=? where id = ?
2019-01-15 14:15:05.417 DEBUG 6460 --- [           main] com.example.demo2.AMapper.updateMyOne    : ==> Parameters: [](ArrayList), 1(Integer)

expect Parameters: [](String), 1(Integer)

Hi all,
I'm sorry for a late reply.
My conclusion is that the problem (it seems more like a limitation rather than a bug) is in the property type resolution during the parsing phase, and type handler resolution works as expected.
To map type handler, MyBatis has to know the type of the property.
For a parameter, MyBatis first tries to resolve the property type in the parsing phase.
This resolution, however, is not very thorough and the property type is not correctly resolved in some cases.
It is usually not a problem because type resolution is performed again using the actual parameter instance.
In this case, however, the actual property type is different (e.g. ArrayList, etc.) and the ListTypeHandler which is registered against List is not returned.
This would explain why adding ArrayList to @MappedType resolves the problem.
And specifying type handler explicitly in the parameter expression should work as well (e.g. #{a.demo,typeHandler=....ListTypeHandler}).
The test in a portable form is here, but I won't be able to work on it anytime soon (it's a corner case with workarounds, so the priority is low).


[FEAT] Add an Option To show Which type of crud operation app user want to build?

Is your feature request related to a problem? Please describe.
current I've created a one app to try a refine before starting hackathon, it had given me a boiler plate code for admin dashboard. but the project I'm going to build is more user centric so now i've to delete lots of boiler plate code in-order to achieve that.
Describe alternatives you've considered
No response
Additional context
No response
Describe the thing to improve
add a template which focuses on user side as well. if you want i can raise a PR which will shows an template of more user side focused web app.

Hello @Thedineshk24 thanks for the issue, could you elaborate more on this one?

yes @BatuhanW can you please add a template which focuses on user side of project, current template focuses on admin templates.

Hey 👋  @Thedineshk24, thank you for your suggestion 🙏   The current templates are focused on demonstrating the features and the usage of refine. We find that the best way to do is to construct a admin panel like layouts without diving into much of the design and opinionated implementations. Current layout may look focused on admin panels but with the refine's headless approach, you can tweak and customize it however you like.
In the future, we'll definitely consider providing more starter templates and layouts but for now, we don't have the enough work force to create and maintain them. 🧯
If you're willing to create starter projects, we'll be more than happy to mention and promote your work in our website if you end up publishing them in GitHub or any other platform available. 🚀 🚀


Backport: HBASE-24379 CatalogJanitor misreports region holes when there are act…

…ually over laps. (#1741)
Signed-off-by: stack<EMAIL_ADDRESS>

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 35s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
3m 38s
branch-2.3 passed

+1 :green_heart:
checkstyle
1m  6s
branch-2.3 passed

+1 :green_heart:
spotbugs
1m 58s
branch-2.3 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 11s
the patch passed

+1 :green_heart:
checkstyle
1m  5s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
16m 55s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m  1s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 15s
The patch does not generate ASF License warnings.

37m 59s

Subsystem
Report/Notes

Docker
Client=19.03.9 Server=19.03.9 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1776

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux d089fc053ce6 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 162e1d069d

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 33s
Docker mode activated.

-0 :warning:
yetus
0m  7s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
3m 42s
branch-2.3 passed

+1 :green_heart:
compile
0m 54s
branch-2.3 passed

+1 :green_heart:
shadedjars
5m  0s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 36s
branch-2.3 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 10s
the patch passed

+1 :green_heart:
compile
0m 54s
the patch passed

+1 :green_heart:
javac
0m 54s
the patch passed

+1 :green_heart:
shadedjars
5m  5s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 42s
the patch passed

_ Other Tests _

-1 :x:
unit
130m 20s
hbase-server in the patch failed.

153m  9s

Subsystem
Report/Notes

Docker
Client=19.03.9 Server=19.03.9 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1776

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux e273f746f0ac 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 162e1d069d

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/testReport/

Max. process+thread count
4480 (vs. ulimit of 12500)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
4m 49s
Docker mode activated.

-0 :warning:
yetus
0m  7s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+1 :green_heart:
mvninstall
4m 35s
branch-2.3 passed

+1 :green_heart:
compile
1m  8s
branch-2.3 passed

+1 :green_heart:
shadedjars
5m 53s
branch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 43s
hbase-server in branch-2.3 failed.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 11s
the patch passed

+1 :green_heart:
compile
1m  9s
the patch passed

+1 :green_heart:
javac
1m  9s
the patch passed

+1 :green_heart:
shadedjars
7m  7s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 51s
hbase-server in the patch failed.

_ Other Tests _

-1 :x:
unit
138m 57s
hbase-server in the patch failed.

171m 29s

Subsystem
Report/Notes

Docker
Client=19.03.9 Server=19.03.9 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1776

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux efc998b05da3 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / 162e1d069d

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/testReport/

Max. process+thread count
3754 (vs. ulimit of 12500)

modules
C: hbase-server U: hbase-server

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1776/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

The test failure is about
precommit checks / yetus jdk8 Hadoop2 checks / org.apache.hadoop.hbase.master.store.TestLocalRegionOnTwoFileSystems.testFlushAndCompactFailing for the past 1 build (Since #1 )Took 17 sec.Error MessageWaiting timed out after [15,000] msecStacktracejava.lang.AssertionError: Waiting timed out after [15,000] msec
at org.apache.hadoop.hbase.master.store.TestLocalRegionOnTwoFileSystems.testFlushAndCompact(TestLocalRegionOnTwoFileSystems.java:178)
Standard OutputFormatting using clusterid: testClusterID
Standard Error2020-05-26 00:26:29,624 INFO  [main] hbase.HBaseClassTestRule(94): Test class
Which is a flaky, I created HBASE-24437 to track it.


test: behaviors-message_on_lock_failure (2024-03-07 16:47:55.854780+00:00)

automatic test cleanup


PR: Constrain setuptools for macOS standalone installer

Constrain setuptools<70.0.0 for macOS standalone installer to resolve "ImportError: cannot import name 'packaging' from 'pkg_resources'".
Also, missed a macos-11 spec on PR #22102.

@ccordoba12, hopefully we're done playing whack-a-mole!

This is not necessary for master, right?

Correct; this is not necessary for master.


Create attestations in a different repository

From the README:

If the repository initiating the GitHub Actions workflow is public, the public-good instance of Sigstore will be used to generate the attestation signature. If the repository is private/internal, it will use the GitHub private Sigstore instance.

I have an organization where we have repo A (public, containing all the source code) and repo B (private, containing deployment workflows, scripts, etc). When we want to trigger a release, repo B builds artifacts and uploads them to a release on repo A using a custom GITHUB_TOKEN.
In this setup, we would like to create the attestations in repo A, rather than in repo B (and so use the public-good instance). To my understanding, this is not possible right now?

Could this realistically be supported in the future? Or is this fundamental to how attestation works?

I think that it may be possible to support something like this in the future, but will probably require that attestation support get baked-in to the GitHub Actions system as a first-class feature. In it's current form, the provenance attestation really requires that the source and the build workflow be located in the same repository.

Noting that this also affects workflows that use a reusable workflow from another repo to create the attestation. The attestation refers to the reusable workflow rather than the workflow that used it, and if that exists in another repo then the attestation won't be verifiable.

@johnbillion I think the use case you're describing is a bit different. We definitely support verification of attestations created with reusable workflows from different repositories. See the information about using the --signer-repo and --signer-workflow flags here.

@bdehamer Thanks!

I think so


Install multiple lsp servers with :LspInstall

Hi there! It'd be great if lspinstall could install many lsp servers at the same time , like having multiple arguments for :LspInstall , example :
:LspInstall html css js
but this gives me some other error

Right now this is mainly blocked because we need a proper UI first. Currently every install runs in a terminal split window. Installing 5 language servers at once would open 5 terminal splits which would be very confusing.

You can already write a Lua function for this, but as I said it'll open a split window for every server that you install.
https://github.com/kabouzeid/nvim-lspinstall/issues/83#issuecomment-854029170

Right now this is mainly blocked because we need a proper UI first. Currently every install runs in a terminal split window. Installing 5 language servers at once would open 5 terminal splits which would be very confusing.

Isnt there something like deleting a buffer without closing its window? so we could just do this :
example :  LspInstall css bash
open new tab (only done once) --> then install css lsp --> clear its buffer -> then install bash lsp -> clear its buffer

parallel install would be way faster though 🤔

parallel install would be way faster though

oh yes , btw why create splits? cant we just open new tabs? it'll allow parallel install too

Using tabs instead of splits might be a good idea. I'll test it out to see how it "feels"

@kabouzeid any updates?

This is a necessary feature so that one can execute post_install_hook only once after multiple LSP servers are intsalled.

I no longer use lspinstall so I'll be closing this :|

I no longer use lspinstall so I'll be closing this :|

What are you using now?

@siduck76 Please leave this opened -- you are not the only user of this plugin. Many users would still want this feature.

I no longer use lspinstall so I'll be closing this :|

What are you using now?

Nothing , i was using lspinstall for nvchad to make things more newbie friendly but lspinstall doesn't work properly for windows , I know there's another lspinstaller too but I'm just fine installing lspservers on my system manually.


git-tfs fails to rcheckin, but checkin works

Please bear with me if I'm missing something fundamental -- which I may well be.
I've only recently started using git-tfs because a client uses tfs (and I'd much rather use git). My workflow was typically:
git tfs pull
// do some work
git add
git commit -m "amazing message!"
// some time later....
git tfs rcheckin
I chose rcheckin because I understand that it preserves all of my commits as TFS checkins, which I'd prefer.
However, I've started getting this message when I attempt to rcheckin:
Basing from parent 'default:1654', use -i to override
Fetching changes from TFS to minimize possibility of late conflict...
error: latest TFS commit should be parent of commits being checked in
I panicked the first time I saw it because (a) I don't really understand what I'm doing wrong (I'm assuming I'm doing something wrong) and (b) I wasn't sure how I was going to get my changes to the client, short of manually merging and using old-fashioned tfs. On a whim, I tried:
git tfs checkin
And success! Though now all of my commits are rolled up into one changeset, which I'd prefer not to do.
So:

What did I do wrong? Or:
If I didn't do something wrong, how do I help debug this?

So far, git-tfs has taken a lot of the pain out of my forced TFS interactions. Thank you!

error: latest TFS commit should be parent of commits being checked in

I think this means that your TFS branch has diverged from your local Git branch. Maybe look at the output of git log --graph --pretty=format:"%h %d" HEAD refs/remotes/tfs/default? Or post the output here or in a gist?

@spraints Apoligies for the delay: this is a work project and I only saw your reply at beer-o-clock on Friday (:
gist here:
https://gist.github.com/fluffynuts/37fed8026a578ad9d3a6
To me, it looks like I am still attached to tfs/default -- but I could well be missing something. If I had diverged, surely checkin should fail in addition to rcheckin? Or is that (just another) piece of the puzzle that I'm missing?

*   f3db68a  (HEAD -> master, tfs/default)

This makes it look like your current branch (master) is up to date with TFS, and has no new commits either.

@spraints: quite correct: as the title of the issue states: checkin worked just fine; rcheckin, on the other hand, didn't. I've had code to commit today and the other team has merged in changes too, so I can get output from each step along the way:

git commit -- now I'm ahead of the remote: https://gist.github.com/fluffynuts/61c056c6ddaa23a2122a
git tfs pull to get their latest, and then graph: https://gist.github.com/fluffynuts/0a202ed15f711c3de8a0
attempt git tfs rcheckin (and get error message): https://gist.github.com/fluffynuts/b9420642684c17d3966d
immediately attempt git tfs checkin (and get success): https://gist.github.com/fluffynuts/2bd9cdd903feacf8cb93

As I stated in the initial splurb, I'm assuming that I've done something wrong or made an incorrect assumption about rcheckin vs checkin -- however, I'm totally unsure what I'm missing as I'm doing what I understand I should be doing.
As far as I understand, rcheckin and checkin only differ in that rcheckin creates one changeset per commit where checkin rolls up all pending commits into one changeset -- please correct me if I've misunderstood the documentation on this point.
rcheckin was working for me up until the day I opened this issue and I've been following the same workflow all this time with the exception that now I have to checkin instead of rcheckin as the latter doesn't appear to like me any more )':

Awesome, thanks for detailed the repro steps. I think I see what's happening now.  When you git tfs pull, it makes a merge commit (e725e3f) with the TFS branch and your git commit as parents. This forked history must be what's confusing git tfs rcheckin.
Here are a couple of things to try. First, you could do git tfs fetch instead of git tfs pull in step 2. That won't create the merge commit. I think rcheckin knows how to rebase your changes on the most recent TFS commit. If it still complains, try doing git rebase tfs/default after you git tfs fetch.

I think rcheckin knows how to rebase your changes on the most recent TFS
commit.

Indeed.

If it still complains, try doing git rebase tfs/default after you git tfs
fetch.

Or you could do a git tfs pull -r
You're right, doing merge when using rcheckin (which is the best way to use
git-tfs IMHO) is a bad practice...

@spraints @pmiossec thanks for the detailed explanations and help guys. My normal git workflow is to pull --rebase -- this is just the first time I've been using git-tfs and I was trying to be cautious, thinking (mistakenly) that a pull (ie, merge) would be the path of least resistance. I'll git tfs pull --rebase from now on (:
Thanks again for the time and effort in grokking my situation and responding.


Add PyTorch Lightning example

Adds an example of PyTorch Lightning.
The example tries to be minimal, however

a custom logger DictLogger is defined and used to obtain the final accuracy in the objective function (without e.g. introducing additional "accuracy" attributes to the Trainer) since the default logger writes to TensorBoard even files and metrics are seemingly not kept in memory.
an explicit callback checkpoint ModelCheckpoint is instantiated per trial to ensure that checkpoint file names are unique. If they're not, PyTorch Lightning will try to restore model parameters which will fail since model architectures will vary across trials.

The model/optimizer sampling logic is copied (without being refactored, assuming tests should be independent) from the already existing pytorch_simple.py.

I'm not sure but it'll be better to update the list:
https://github.com/pfnet/optuna/blob/1e8b56b3c99d3759cd251d028c99072b444f6d09/setup.py#L61-L68

Thank you for the review, comments should be addressed now. PTAL.

Fixed the optimizer, PTAL.

Importing pytorch_lightning package raised the following error in my environment:
$ python --version
Python 3.5.3

$ python examples/pytorch_lightning_simple.py
Traceback (most recent call last):
  File "examples/pytorch_lightning_simple.py", line 26, in <module>
    import pytorch_lightning as pl
  File "/home/ohta/.local/lib/python3.5/site-packages/pytorch_lightning/__init__.py", line 1, in <module>
    from .models.trainer import Trainer
  File "/home/ohta/.local/lib/python3.5/site-packages/pytorch_lightning/models/trainer.py", line 177
    print(f'VISIBLE GPUS: {os.environ["CUDA_VISIBLE_DEVICES"]}')
                                                              ^
SyntaxError: invalid syntax

I'm not sure but it seems that pytorch-lightning only suports Python 3.6 or later. If it's true, we need to update .circleci/config.yml file to avoid executing pytorch_lightning_simple.py for unsupported Python versions.

You're right about the Python version, I'll try to fix the CI configuration.

Created a separate step for the CI. PTAL.


Command or API to replace tokens (${workspaceRoot}) with proper values in config items

VSCode Version: 1.7.2
OS Version: N/A

I can't remember, the API or command used to resolve tokens (such as ${workspaceRoot} etc) in a given string (in config settings).
Looked around the documentation but couldn't find it.

http://code.visualstudio.com/docs/editor/tasks#_variable-substitution
@gregvanl this document should be moved out of tasks into some parent document which should be linked from debug and tasks both


Support of Card Emulation API

It would be great to have Card Emulation API (including Host-based card emulation) supported by this library.

Thanks for proposing. I'll check it out and see whether it's feasible when available.

Is there any progress？

Is there any progress？

Is there any progress？

Hi @umutcetinkaya sorry for pending this feature for so long. currently we don't have plan for card emulation, since this is still an exclusive feature for Android.

Hi @whitedogg13, did you made the card emulation feature?
Thanks

I just need to duplicate the serial number in my phone, how can I do that?
Thanks