vs code not display all emoji in ubuntu 18

Issue Type: Bug
I don't know why, but i not have problem display emoji in chrome or ff or terminal, only in vs code i got this

Before i was on manjaro kde and not having problems.
I have settings for terminal font family
  "terminal.integrated.fontFamily": "'Roboto Mono for Powerline', 'Noto Color Emoji'",

VS Code version: Code 1.23.1 (d0182c3417d225529c6d5ad24b7572815d0de9ac, 2018-05-10T16:04:33.747Z)
OS version: Linux x64 4.15.0-20-generic

System Info

Item
Value

CPUs
AMD FX(tm)-4350 Quad-Core Processor (4 x 2283)

GPU Status
2d_canvas: unavailable_softwareflash_3d: unavailable_softwareflash_stage3d: unavailable_softwareflash_stage3d_baseline: unavailable_softwaregpu_compositing: unavailable_softwaremultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_softwarevideo_decode: unavailable_softwarevideo_encode: unavailable_softwarevpx_decode: unavailable_softwarewebgl: unavailable_offwebgl2: unavailable_off

Load (avg)
4, 2, 1

Memory (System)
15.40GB (12.64GB free)

Process Argv
/snap/vscode/37/usr/share/code/code

Screen Reader
no

VM
0%

Extensions (28)

Extension
Author (truncated)
Version

beautify
Hoo
1.3.0

vscode-language-pack-ru
MS-
1.23.0

vscode-docker
Pet
0.0.26

code-settings-sync
Sha
2.9.2

indenticator
Sir
0.6.0

vscode-wakatime
Wak
1.2.2

quokka-vscode
Wal
1.0.124

lit-html
bie
1.2.0

vscode-svgviewer
css
1.4.4

vue-peek
dar
1.0.2

vscode-eslint
dba
1.4.9

gitlens
eam
8.3.1

prettier-vscode
esb
1.3.1

file-icons
fil
1.0.12

auto-rename-tag
for
0.0.15

path-autocomplete
ion
1.9.0

svg
joc
0.1.0

docthis
joe
0.6.0

dotenv
mik
1.0.1

theme-monokai-pro-vscode
mon
1.1.6

vscode-scss
mrm
0.6.2

python
ms-
2018.4.0

atom-keybindings
ms-
3.0.4

vetur
oct
0.12.3

language-stylus
sys
1.9.2

stylus-supremacy
thi
2.10.1

vscode-todo-highlight
way
0.5.12

change-case
wma
1.0.0

(1 theme extensions excluded)

Okay, i install Noto emoji and Segui Ui Emoji, now i have emoji.

@alexandrudima any idea why emoji wouldn't be showing up correctly?

I run vs code on manjaro 17.1 and not have problem with emoji.

@Tyriar
It probably has to do with our ancient version of Chromium. We are on Chromium 58 (released on April 19, 2017) and the current stable version is Chromium 66.

This looks like an environment/font issue to me since it works fine for @dimensi

I am also having this issue. Easily reproducible:

Create new file on Mac VSC
Enter Emoji (In my case a rocket)
Save file and copy to Ubuntu 18.04
Open in VSC

VSC Terminal output:

Ubuntu Terminal output:

Settings:
Mac:
"editor.fontFamily": "Fira Mono for Powerline, Menlo, Monaco, 'Courier New', monospace",
Ubuntu:
"editor.fontFamily": "'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback'",


in target 'RNIap' from project 'Pods'

Hi, i'm getting this error after installing this package.
error: Abort trap: 6 (in target 'RNIap' from project 'Pods')
xcode: 13.0
"react": "18.1.0"
"react-native": "0.70.2"
"react-native-iap": "^12.10.5"

check this link:
https://usmanabid477.medium.com/in-app-purchase-integration-in-react-native-app-96c0acd13649


🐞 [BUG_LP] - Navbar is sticked to the top

Description of the bug. ✍🏻
Hey, @praveenscience It seems that the navbar is too much sticked to the top and that's why it is not looking good. Please assign me this issue. Thank you!
Current Behaviour
Navbar sticked to the top
Expected Behaviour
Some margin-top to the navbar
Reproduction Steps
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Screenshots
No response
Additional information
No response
Contributor terms

[X] I agree to follow the Contributing Instructions

@praveenscience Please assign me this issue so that I can start working on it.

@sumitkr2000 please assign this issue to me under ssoc'23

@praveenscience Please assign me this issue so that I can start working on it.


document testing

Tests fail on my machine with repeated ReferenceError: window is not defined.
I imagine the test are meant to run in the browser, rather than Node. Can this be documented?

How are you running them? They should work with yarn test / npm test as the phantomjs runtime is used then. It's just set up to use the --runtime flag with pulp.

Ah okay. I should have figured that out. I was using pulp test.


InterruptedError does not exist in Python < 3.3.

Upon a interrupted select call, the code prior to this commit would fail in 2.7 with a complaint that InterruptedError is not defined. The updated code should work fine on any existing version of Python from 2.7 onwards.
Please let me know what additional work needs to be done to get this out in a released version. Seeing a released version that incorporates this and #743 is becoming a pressing matter for me.  As soon as I upgraded to Celery 4.0.2 I've started running into the EINTR issue. My Django test suite cannot pass unless I use a version of redis-py that contains the EINTR fixes.

thanks!


Cheerio crawler premature (or never) finish and bonkers pendingRequestCounts

Background: I'm running a crawl of a listing system with roughly 60,000 entries in total. I've been struggling massively with the crawler being able to scrape at the most ~40k entries before it terminated with the message:
"INFO: BasicCrawler: All the requests from request list and/or request queue have been processed, the crawler will shut down."
Conversely, on some of my trial debugging runs, it would get stuck with no progress and never terminate.
Have been debugging this for a few days now and eventually seem to be able to observe that there's something horribly wrong with the requestQueue system. A few debugging runs and observations:
Run1: Here the crawler terminates prematurely. Upon inspection of the \apify_storage\request_queues\run_name\pending folder, I found hundres of unprocessed requests:
Processing _someUrlEditedAway_
Scraping results.
Pushing data to dataset.
INFO: BasicCrawler: All the requests from request list and/or request queue have been processed, the crawler will shut down.

I've eventually added the below debug code to get some insights into the crawler's state of mind:
		handlePageFunction: async context => {
			const { request } = context;

			logger.debug(`Processing ${request.url}`);
			logger.debug("Requestqueue.getinfo(): " + JSON.stringify(await requestQueue.getInfo()));
			await router(request.userData.label, context);
		}

Run2: Here the crawler never terminates and spammed the INFO logs for the rest of its life before it was manually killed. Observe the pendingRequestCount numer:
Processing https://www.someUrl.domain/brugt/bil?includeengroscvr=true&pricefrom=250000&priceto=300000&includeleasing=false&page=54
Requestqueue.getinfo(): {"id":"bb-crawl-1581773815315","name":"bb-crawl-1581773815315","userId":null,"createdAt":"2020-02-15T13:36:55.352Z","modifiedAt":"2020-02-15T13:58:57.817Z","accessedAt":"2020-02-15T13:58:58.479Z","totalRequestCount":15708,"handledRequestCount":16589,**"pendingRequestCount":-881**}
[object Object]
Request https://www.some.domain/brugt/bil?includeengroscvr=true&pricefrom=250000&priceto=300000&includeleasing=false&page=54 failed four times.
INFO: AutoscaledPool state {"currentConcurrency":201,"desiredConcurrency":247,"systemStatus":{"isSystemIdle":true,"memInfo":{"isOverloaded":false,"limitRatio":0.2,"actualRatio":0},"eventLoopInfo":{"isOverloaded":false,"limitRatio":0.7,"actualRatio":0},"cpuInfo":{"isOverloaded":false,"limitRatio":0.4,"actualRatio":0.003},"clientInfo":{"isOverloaded":false,"limitRatio":0.3,"actualRatio":0}}}
INFO: Crawler request statistics: {"avgDurationMillis":6411,"perMinute":717,"finished":16496,"failed":94,"retryHistogram":[15856,451,88,195]}
...

Above runs take horrendous amounts of time so eventually it seems its possible to narrow the scope of the crawl down and still see the problem.
Run3. I seem to be able to reproduce it within reasonable crawl run times when my search views involve at least a 100 items per view by the time pagination goes to at least ~page=40. However, this claim is based purely on observing f.ex. pendingRequestCount: 4 just before termination. This could be explained by some benign race condition situations.
Here's my crawler setup in case it can be of interest:
const crawler = new Apify.CheerioCrawler({
		requestList,
		requestQueue,
		maxRequestRetries: 3,
		handlePageTimeoutSecs: 15,
		requestTimeoutSecs: 15,
		prepareRequestFunction: async ({ request, session }) => {
			crawlStats.requestCount++;
			request.headers = { Cookie: "PageSize=96; path=/;domain=www.some.domain" };
		},
		handlePageFunction: async context => {
			const { request } = context;
			crawlStats.successfulResponseCount++;
			logger.debug(`Processing ${request.url}`);
			logger.debug("Requestqueue.getinfo(): " + JSON.stringify(await requestQueue.getInfo()));
			await router(request.userData.label, context);
		},
		handleFailedRequestFunction: async ({ request, error }) => {
			crawlStats.failedRequestCount++;
			logger.error(`Request ${request.url} failed four times.`, { request, error });
		}
	});

Part of my problems went away when I've replaced the
enqueueLinks(...)
with
addRequest({forefront: true })
for the one statement responsible for queuing the next paginated search view.
This would strongly indicate that the crawler doesn't properly await the processing of the last queue items on some occasions.
PS: I've confirmed through logging&debugging that the respective url does definitely get added to the queue yet the crawler terminates before processing it.

The crawler not finishing and getting stuck in limbo is a known issue. See: #505 .
The crawler finishing before all requests are processed is a new one.  Mishandled async stuff can cause weird errors. See: #559
Otherwise, we're sorry about the issue and please wait for #560 to fix this for good.

I've looked more at it and am pretty comfortable that its not an async await issue. Im able to confirm that the request is added to the queue by confirming the request Id in
await requestQueue.getRequest(addedReq.requestId)
Then I don't see it processed before the crawler shuts dowm (I'm logging each processed request -in handlePageFunction).

@mnmkng I'm having the same problem when I try to add just one request to the queue, at any of the following locations:
async function run() {
  const requestQueue = await openRequestQueue();

  // <=== await requestQueue.addRequest() HERE

  const routeReq = createRouter({requestQueue, log, pushData, enqueueLinks}, {
    async amazonProfile({$}) {
      console.log($('link[rel="canonical"]').attr('href'));
    },

    async amazonEbook() {},
  });

  const crawler = new CheerioCrawler({
    requestQueue,

    async handlePageFunction(ctx) {
      log.debug(`Processing ${ctx.request.url}...`);
    },
  });

  // <=== await requestQueue.addRequest() HERE

  await crawler.run();

  await requestQueue.addRequest({  // <=== OR HERE
    url: 'http://google.com',
  });

  log.debug('Crawler finished.');
}

run();

If I initialize the crawler with requestList instead, I can at least process the list, but using the queue with or without the list prevents anything from running before the following message:
INFO: BasicCrawler: All the requests from request list and/or request queue have been processed, the crawler will shut down.
INFO: Crawler final request statistics: {"avgDurationMillis":null,"perMinute":0,"finished":0,"failed":0,"retryHistogram":[]}

@mikestopcontinues There are issues with the queue, yes, but in general, it's working. What you're suggesting is that it's not working at all?
This seems like you're not clearing the queue after each run. Are you using the CLI?
apify run -p

If not. You need to clear the queue folders manually after each run.

@mnmkng Ah, it was the queue folder. Sorry for the tangent. :)

After finding a workaround for the premature crawler finish I repeatedly run into these hang-up situations in a completely unpredictable fashion. Same code, same script, crawl job runs every night and occasionally it runs through all 55k requests but mostly the queue goes nuts driving the pendingRequestCount into the negative and hanging up the crawler.
Requestqueue.getinfo(): "totalRequestCount":2498,"handledRequestCount":2515,"pendingRequestCount":-17

We’ll start working on the new Queue this week. I’ll be sure to keep you posted so you can try the beta.

@mnmkng can the crawler be forced to terminate in any manual way as a workaround?

It can, by calling crawler.autoscaledPool.abort(), which currently is not documented (by accident).

Hey guys, it's been some time but we finally have a completely new RequestQueue ready for testing. It is based on the SQLite database and we would like to invite you to test it and see if it solves your problem. To get it, simply use
"apify": "dev" or "apify": "0.20.3-dev.0" in your package.json dependencies.
Thanks.

Hey guys, it's been some time but we finally have a completely new RequestQueue ready for testing. It is based on the SQLite database and we would like to invite you to test it and see if it solves your problem. To get it, simply use
"apify": "dev" or "apify": "0.20.3-dev.0" in your package.json dependencies.
Thanks.

Thanks for coming back I will have to advise that currently have managed to handle all the issues and have a somewhat predictable scrape job running so have moved on to some other work and it will be a while before I'm back in the scraper code.

Closing this, since the discussion in https://github.com/apifytech/apify-js/issues/505 confirms that the dev version fixes the problem.


Remove explicit prolongator construction

This PR adds support for apply() in transpose mode, and removes prolongator from the hierarchy, replacing it by action of restrictor in transpose mode.
As we don't have a proper support for transpose action in device sparse matrices, I chose to workaround that by using the implemented transpose() call of CudaMatrixOperator. That class now caches the matrix transpose when needed. I am not sure how to avoid mutable class variables, though, and open to suggestions.

Codecov Report

Merging #105 into master will decrease coverage by 0.51%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
- Coverage   87.07%   86.56%   -0.52%
==========================================
  Files          43       43
  Lines        1834     1831       -3
==========================================
- Hits         1597     1585      -12
- Misses        237      246       +9

Impacted Files
Coverage Δ

include/mfmg/common/operator.hpp
100% <ø> (ø)
:arrow_up:

...de/mfmg/dealii/dealii_trilinos_matrix_operator.hpp
100% <ø> (ø)
:arrow_up:

include/mfmg/common/hierarchy.hpp
69.38% <100%> (-0.91%)
:arrow_down:

source/dealii/dealii_trilinos_matrix_operator.cc
68.29% <100%> (-21.96%)
:arrow_down:

include/mfmg/common/level.hpp
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Event Request: On Table 5050 Contact method CreateSalesQuoteFromContact

🕮 Describe the request
In the method CreateSalesQuoteFromContact on Table 5050 Contact I require events that triggers after the sales quote for the contact has been created, but before the page is shown. And one more. This is for multiple reasons

I would like to trigger interactive UI elements when a user creates a quote from this function, but only when using this function
I would like to be able to avoid the page being shown (Handled pattern).

I therefore request two new events as shown below:

OnAfterCreateSalesQuoteFromContactBeforeShowPage: this allows me to prevent the page from showing, show a different one or do other kinds of processing before the page opens.
OnAfterCreateSalesQuoteFromContact: this allows me to do things after the page has been opened to the user. The sales quite page is not ran modally, so this allows me to sneak in some interaction logic.

Additional context
    procedure CreateSalesQuoteFromContact()
    var
        SalesHeader: Record "Sales Header";
        IsHandled: Boolean; // new line
    begin
        ...
        SalesHeader.Insert(true);
        SalesHeader.Validate("Document Date", WorkDate());
        SalesHeader.Validate("Sell-to Contact No.", "No.");
        SalesHeader.Modify();
        OnAfterCreateSalesQuoteFromContactBeforeShowPage(Contact, SalesHeader, IsHandled); // new line
        if (IsHandled) then exit; // new line
        PAGE.Run(PAGE::"Sales Quote", SalesHeader);
        OnAfterCreateSalesQuoteFromContact(Contact, SalesHeader); // new line
    end;

Availability update: We will publish a fix for this issue in the next update for release 22.
Build ID to track: 59042.


Compatible with Oracle Global Temporary Table

Enhancement

Only IvorySQL 3.x and above are supported now and the GTT feature is not available.


fix(InpHelper): use minmax to fill interior of coreshape with 1

More pleasing calculated coreshape, filling in the interior based
on the display technique from ImageGenerator.

:tada: This PR is included in version 1.3.40 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


regex denial of service vulnerability due to transient dependency on "string" package

Due to following dependency tree
├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ │ ├─┬<EMAIL_ADDRESS>│ │ │ ├─┬<EMAIL_ADDRESS>│ │ │ │ ├─┬<EMAIL_ADDRESS>│ │ │ │ │ ├──<EMAIL_ADDRESS>
regex denial of service vulnerability has been introduced, more detail can be found here: https://snyk.io/vuln/npm:string:20170907
Please either remove the dependency on "string" altogether, or we should fix one in the "string" package directly. Either ways this might turn out to be a real issue. Although I am not using ciscospark it's kind of vexing, that my application is getting affected by something which I am not using.

@Stevenic fyi ^

@nishch Cisco says this should be resolve, please let us know if you are still seeing trouble.

We are planning to do a general update of the entire sparkbot functions of slack, I was wondering if you had a chance to test with the latest version.


protractor 'advertises' its --verbose option, but cannot use that

Node Version: v6.9.5
Protractor Version: 5.1.1
Operating System and Version Linux Mint 18.1
Steps to reproduce the bug

protractor --help tells about the --verbose option:
  --verbose                              Print full spec names

I wanted to try how it works. So I executed protractor with this flag, but apparently it cannot make sense of this --verbose option, see the warning below:
$ protractor protractor-conf.js --verbose
[14:52:16] I/launcher - Running 1 instances of WebDriver
[14:52:16] I/hosted - Using the selenium server at http://localhost:4444/wd/hub
[14:52:17] W/runner - Ignoring unknown extra flags: verbose. This will be an error in future versions, please use --disableChecks flag to disable the  Protractor CLI flag checks.
Protractor animation is disabled
Protractor synchronization is disabled
(...)

So maybe this --verbose is a half-way done feature? I guess it should be completed or removed.

I can reproduce this as well; I pr'd the fix in #4200

Thanks @NickTomlin ! :)


No compiler message when calling parameterized constructor from parent class

A broken use is reported by Maracas when calling a parameterized constructor from a parent class, but the Maven compiler does not report any message. However, the error is indeed reported by the JDT compiler. The broken use is correctly reported but there is no matching compiler message (true positives reported as false positives).
Related broken use:
Path: /home/lina/Documents/code/maracas/test-data/comp-changes/client/src/mainclient/classNowAbstract/IClassNowAbstractExt.java
Line: 12
Breaking change: CONSTRUCTOR_REMOVED
API use: METHOD_INVOCATION
Used declaration: main.classNowAbstract.IClassNowAbstract(int)
Source declaration: main.classNowAbstract.IClassNowAbstract(int)

Related to #28

As discussed in a previous meeting, these cases should be manually inspected and reclassified accordingly. As mentioned before, there is a mismatch between the JDT and the Maven compiler.

This case is not considered anymore. See https://github.com/alien-tools/maracas/issues/34#issuecomment-1056665875.


add Python 3.12 images, default to Python 3.12 and CUDA 12.5 in docs

Contributes to https://github.com/rapidsai/build-planning/issues/40.

adds Python 3.12 images
defaults to latest Python (3.12) and CUDA (12.5[.1]) in docs and comments

Notes for Reviewers
Builds here will fail until all RAPIDS libraries are supporting Python 3.12, but figured we don't need to wait on that to come to an agreement about the building and testing matrices.

I cancelled CI here since it's doomed to fail until Python 3.12 packages are available. Will restart it manually once there's a chance it'll succeed.

https://github.com/rapidsai/integration/pull/719 has been merged, which triggered this build: https://github.com/rapidsai/integration/actions/runs/10892652464/job/30225989191
Once that completes (and therefore there are rapids packages available), I'll start CI here.


Perf test of mirrornode

To work with mirrornode team and prepare:
cluster with , 20M, 50M, 100M, 200M accs/NFTs

Deployed v0.56.2 to solo-engineering-1, generated 20
m

Done, per Xin


next 14 pnpm build 打包失败

Can you share a minimal reproducible repo? I tried creating a clean Next14 project with json-viewer, and it works fine.
The stackbliz example is broken on Next.js 14 because of an issue from stackbliz itself https://github.com/stackblitz/core/issues/1904

Can you share a minimal reproducible repo? I tried creating a clean Next14 project with json-viewer, and it works fine.
The stackbliz example is broken on Next.js 14 because of an issue from stackbliz itself stackblitz/core#1904

try to use App router

it can be resolved with no ssr.

Oh there is a error from mui. Looks like mui is having some issues with Next 14
Internal error: TypeError: Cannot read properties of undefined (reading '0')
    at Paper (./node_modules/@mui/material/Paper/Paper.js:101:26)
    at renderWithHooks (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8245:26)
    at renderForwardRef (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8433:28)
    at renderElement (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8589:29)
    at renderNodeDestructiveImpl (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8778:33)
    at renderNodeDestructive (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8735:28)
    at finishFunctionComponent (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8383:17)
    at renderIndeterminateComponent (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8337:17)
    at renderElement (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8528:21)
    at renderNodeDestructiveImpl (./node_modules/next/dist/compiled/react-dom/cjs/react-dom-server.edge.development.js:8778:33)

Most of the errors have gone on Next.js 14.1.0.
For people who are using Next App Directory:

With the new App Directory, React Components are categorized into two: Server Components and Client Components, and by default they are all Server Component as mentioned in: Using Server Components in Next.js.
Components that need hooks (context, use...) need to be classified as Client Components and they need to have the directive "use client" at the top of the source file before any import.

https://github.com/TexteaInc/json-viewer/issues/442#issuecomment-1907336089

Found another error related to zustand or react context. Registered built-in is missing on the server side.
 ⨯<EMAIL_ADDRESS>(1265:14) @ matchTypeComponents
 ⨯ Internal error: Error: No type matched for value: 1
    at matchTypeComponents (./node_modules/@textea/json-viewer/dist/index.mjs:1290:15)
    at eval (./node_modules/@textea/json-viewer/dist/index.mjs:1297:63)
    at Object.oL [as useMemo] (./node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:12:72230)
    at t.useMemo (./node_modules/next/dist/compiled/next-server/app-page.runtime.dev.js:35:163482)


[REQ] Add support for custom APT config and gpg key injection

What kind of request is this?
None
What is your request or suggestion?
https://github.com/project-copacetic/copacetic/blob/d648155f5424a9f4cb13acd7209195846791873b/pkg/pkgmgr/dpkg.go#L239C1-L240C1
Turning copacetic TODO comments into issues from https://docs.google.com/spreadsheets/d/1XwNj1J6e2FrUhlqaIsV10l8_tgov7WodlkvpNZXYZMU/edit#gid=1386834576.
Are you willing to submit PRs to contribute to this feature request?

[ ] Yes, I am willing to implement it.

Hii @ashnamehrotra, In first look we want to extend user's control by giving them functionality for custom APT config file.
If you have something in your mind regarding this which can help me to solve this issue, please tell me. So we can work on this in proper way.

Hi @h4l0gen, based on the comment, I think we should set up the configuration within the original dm.config.ImageState prior to applying apt update on the resulting state based custom config input into Copa.

Hey is this issue still open?If so,  I would like to work on it

Hi @h4l0gen, are you still planning on working on this issue?

Hi @ashnamehrotra @Akash-Singh04 I am really out of time right now. Akash please feel free to work on it. I will look into problem of my solution if i found time 🙂.

@ashnamehrotra kindly review and let me know if any more changes are required


Support Spring Boot @ConfigurationProperties

A common idiom when working with Spring Boot applications is to use the @ConfigurationProperties to call a number of setters on a configuration object with an empty constructor, where the fields set this way are assumed to have been initialized as @NonNull.
Consider, for example, the following Configuration class Bar:
import javax.validation.Valid;
import javax.validation.constraints.NotNull;
import lombok.Data;
import lombok.NoArgsConstructor;

public class Bar {
  @Valid @NotNull private someField;
}

Initialized from Yaml properties as follows:
import org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

@Configuration
public class Foo {

  @Configuration
  @Import({
    PropertyPlaceholderAutoConfiguration.class,
  })
  public static class Yaml {

    @Lazy
    @Bean
    @ConfigurationProperties(prefix = "bar")
    public Bar bar() {
      return new Bar();
    }
  }
}

Under the hood, Spring Boot will call Bar::setSomeField with the contents of property bar.someField as read from YAML files in the jar's resources. But, as far as NullAway can see, Bar is a class with an empty constructor - and thus uninitialized fields - which is immediately returned from Foo::bar as new Bar().
We need to handle this idiom to some degree, the question is: how far do we want to go in terms of safety?
We could:

Make javax.validation.constraints.NotNull part of the default -XepOpt:NullAway:ExcludedFieldAnnotations, since as long as validation is running, those fields have a runtime check against being null after initialization (Q: When does this validation happen? Can it possibly be skipped?)
Even further: we could do the above but show an error whenever new Bar() is returned without calling setBaz on every @NotNull baz (important: @NotNull has different semantics from @NonNull), and add logic in a SpringBootHandler for the cases where those setters  may be called implicitly, such as by @ConfigurationProperties above, but without checking that the YAML files include all relevant fields.
In the extreme, we can look at the resources during or after the build and make sure the included YAML configuration in the jar always correctly initializes @NotNull fields, without waiting for runtime. (Q: Is this within the scope for NullAway? Do other tools doing this exist?)

If we do (1), note that other frameworks rely on javax validation, so we might want to make sure whatever we do makes logical sense for multiple use cases of @NotNull.

Interesting use case.  My immediate leaning is towards 1, possibly with some additional checks that validation will occur if configured correctly.  E.g., I think the presence of the @Valid annotation in the above example is also important for enabling validation?  And this Stack Overflow post claims you might need a @Validated annotation on the class.  We can do these additional checks if they are easy, and ideally we'd do them in a way that works for javax.validation in general and not just for Spring Boot.
I'm not immediately in favor of going beyond 1, unless we have evidence that it will expose more bugs in practice.  For our current default excluded field annotations we do not do any further checking that the right runtime wiring or code generation is present (like for @Inject and @Autowired), and it doesn't seem to have been an issue thus far.  And, checking that validation is properly enabled will require a lot more work.
So those are my off-the-cuff initial thoughts.


feature(plugins): moved hopeit.toolkit.storage.redis to a plugin

MOTIVATION:
Current version of hopeit.engine provides a toolkit for help easy way to access  Redis as key/value store.
Future versions of hopeit.engine will no more require aioredis library as dependency.
Plugins can be executed Standalone.
This plugin will be released as a python library and can be installed optionally when installing hopeit.engine with extras [redis-storage].
CHANGES ON THIS PR

[x] Move  hopeit.toolkit.storage.redis to a plugin: hopeit.redis_storage
[x] Adapt CI to release redis-storage plugin to PyPi
[ ] Update installation instructions and tutorials

CURRENT STATUS
Ready for initial testing. Backwards compatible with previous implementation (*)
*Requires change on import:
1 - Install hopeit.engine using [redis-storage] plugin extras:
 pip install "hopeit.engine[redis-storage]"

2 - Change import signature
From:
from hopeit.toolkit.storage.redis import RedisStorage

To:
from hopeit.redis_storage import RedisStorage

Given that 0.2.4 and this both include small breaking chsnges, i th8nk it would be better to release as 0.3.0, so i suggest to set version to 0.3.0rc1 fir this pr.
We'll need also to port out toolkit.storage.fs to a plugin also in another PR.

I agree to change the version, and already prepare the PR to replace toolkit.storage.fs.
It looks like 0.3.0rc1 is just around the corner


image not found

This is rather basic but I've failed to fix it for a while.
I try to run intero, and get this:
dyld: Library not loaded: /usr/local/opt/ghc/lib/ghc-8.0.1/haskeline-<IP_ADDRESS>/libHShaskeline-<IP_ADDRESS>-ghc8.0.1.dylib
  Referenced from: /Users/alokbeniwal/.local/bin/intero
  Reason: image not found

How would I go about reinstalling the relevant packages?

I ran into this exact same thing and solved it by deleting ~/.local/bin/interoand then reinstalling intero.


[VOL-137] Dvol config set key

https://clusterhq.atlassian.net/browse/VOL-137
Implement setting a key with dvol config. Next up: Retrieving a key. I will create an integration test in the next branch.
NOTE This branch does not yet actually save a configuration. This will be added next.
This branch also makes some minor modifications to how error handling is performed.

Thanks @robhaswell! Looks good :)


Don't exit on Enter

Can we change the way the program exits when you hit the 'Enter' button? Maybe make the default exit ctrl-C?
Pressing 'Enter' should select the given auto-complete suggestion.

@lodenrogue Sorry, I can't imagine your situation. Please explain me that detail?
ex. json, query, your os, etc..

In the demo example

.users[1] *Tab* - shows you the result
.users[1] *Enter* - exits the program

Its confusing when Enter causes a program to terminate.

What ashishg-qburst said

What do you think enter should do when there are no suggestions being chosen?

Even doing nothing would be preferable to exiting the program.  Enter is too common of a "accept my input" command and I already exited jid three times accidentally this way :)

Is anyone working on this? I can help to do this

I love jiq.   But *ENTER* is my enemy :-(
I often accidentally hit enter (or more often paste something in that has a trailing "enter") and
*BAM*
the thing I almost had working is gone.  Sometimes I know enough to recreate it in seconds, other times it was really complex, and I have to start over.

I'd suggest, jid should use q to quit.
Enter is used to select an element from the tab completion list, if there is more than one element. If there is none or one, Enter  currently quits. User's are very likely to fall into this trap, as jid is meant to explore the json structure. thus we cannot expect that the user predicts the structure correctly.
When jid quits, it prints the selected value to the console. I'd also suggest to print a trailing newline. Currently the selected value just squeezes in before the prompt, and users may miss the fact, that it is actually there.

Wow I just realized I opened this in 2016. That's over 5 years ago. Any progress on this?


pythonPackages.typing: 3.6.6 -> 3.7.4

Motivation for this change
Fixes #66660.
Things done

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

[ ] NixOS
[ ] macOS
[x] 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 nix-review --run "nix-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.

Notify maintainers
cc @

@GrahamcOfBorg build pythonPackages.typing-extensions

seeing as this triggers 500+ rebuilds, you may want to make this change against staging which is used to mitigate how much hydra has to rebuild.

@jonringer Anything else needed from my end? When does this go from staging to the unstable channel?

I'm not completely sure, I think @FRidh usually curates the staging branch. But I'm not completely sure. I just know that the automated bot r-ryantm will do his PR's against staging if there's over 100 rebuilds to avoid thrashing compute resources on master.

@GrahamcOfBorg build python3Packages.typing python3Packages.mypy

I am surprised to see that typing causes so many rebuilds. But it is a dependency of sphinx nowadays for it to document type hints I suppose. If it builds it can go in staging. Unless it breaks sphinx that is.

@GrahamcOfBorg build python2Packages.sphinx python2Packages.mypy

Thanks. Pushed to staging.


Feature request: Add wayland support

Warpd looks really useful to me when used in combination with a tiling window manager. However, I use sway so would need wayland support.
Thanks for the cool project!

Yeah, I use sway with wayland only mode (without xorg-xwayland) and I'm so keyboard oriented that using keyboard as mouse would be bless for me.

I am not intimately familiar with wayland internals, but my understanding is that its input model might present some implementation challenges. I don't have the time or motivation for a full port at the moment, but I am willing to take a crack at it if this issue gets enough upvotes.

I'd love to see this get ported - I currently use tridactyl to replace my mouse in Firefox, and having a utility that could replace it system-wide would be a game changer. If you open Monero donations, I'd be more than happy to chip in :^)

After some additional research, it seems that wayland is ill equipped for a port. I was peripherally aware of the input problems, but it seems there is no way to draw onto the screen or absolutely position windows either :/. There are some non-standard extensions which might make a port possible on wlroots based compositors (i.e sway) but as far as I can tell, Gnome users are out of luck. I may end up proceeding anyway if there is enough interest.
It would help to have a idea of what people are using.

Fedora 36 with Wayland + Nvidia. I am not at all versed in compositors, but maybe you can leverage XWayland?

@dsych
By 'Fedora 36' I assume you mean with the stock DE (Gnome) which doesn't support the layer shell protocol.

but maybe you can leverage XWayland?

Unfortunately XWayland won't work. warpd relies on certain X behaviours (e.g shaped windows) which are not fully implemented by wayland's compatibility layer (since this would provide an easy way to bypass the security model).
From what I can tell, fragmentation seems to be a major problem in the Wayland ecosystem, with most of the useful protocols being developed by wlroots and Gnome flat out refusing to adopt them. Sadly this makes implementing an entire class of third party software impossible :(.

I know I use sway so this isn't exactly unbiased, but there are quite a lot of wayland compositors based on wlroots now. Not saying you are going to get the market share of Gnome but it would still be useful to a lot of people.

I was more referring to Gnome's obstinacy as documented [here] (https://gitlab.gnome.org/GNOME/mutter/-/issues/973) (and elsewhere). I'm not sure what is involved in the standardization process, but my impression is that Gnome has no intention of introducing support for most of the necessary protocols.
Having said that, I am not opposed to a limited port given that sway seems to be reasonably popular amongst the niche input crowd, and will probably be my first port of call when I inevitably make the transition.

I agree with @Cadair. Creating a proper implementation, sticking to the protocol specification has been the domain of the wlroots (sway) team from the beginning. Wlroots now tries to be not only a library for Sway, but for every window manager that uses it, trying to be what X.org is for environments based on it. There are plenty of wlroots-based window managers that are completely different from each other, from floating window managers to the popular and well-known tiled window managers. There's a compiz clone, an openbox clone, and others. KDE is only now catching up and from what I can see they are trying to move towards implementing various things similarly to wlroots, unlike Gnome.
Even if KDE with their Kwin, wanted to go with something completely different, rhere is a Kwin fork based on wlroots.
LXQt and XFCE are not planning their window managers and are looking at developing current window managers for Wayland. At this point, the only troublemaker is Gnome's Mutter.

Wlroots now tries to be not only a library for Sway, but for every window manager that uses it, trying to be what X.org is for environments based on it.

Admirable though it may be, wlroots != wayland.

KDE is only now catching up and from what I can see they are trying to...
At this point, the only troublemaker is Gnome's Mutter...

Evidently we have different definitions of 'fragmentation' :P.
Due to popular demand, I have added experimental support for wlroots based compositors. There were a few hard limitations on what could ultimately be achieved (and other things which I was just too lazy to implement).
I have a few ideas about how to potentially remedy some of these, but I probably won't have time to implement them for a few weeks.
See the man page for details.

Thank you very much for adding wayland support! :heart:


Remove unnecessary usings part 9

src\Microsoft.WSMan.Runtime\
Contributes to #13504.
https://docs.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0005

Can we force the rule?

Can we force the rule?

Not yet, there is still System.Management.Automation, which will be major work.


[1237] Switch edit course vacancies links to mc-fe

:shipit:

 Switch edit course vacancies links to go to mc-fe


Plugin logic separation

Coverage increased (+0.5%) to 89.109% when pulling 8cf151aae5ec5be6df9535de7678aed0c85d8df5 on plugin_logic_separation into a355f00fee8b66b0b30b23c91d8a4c9c941b68aa on develop.

Coverage increased (+0.5%) to 89.109% when pulling ba350c255b72e5a359ca7cc0dd0be4b1d58224cf on plugin_logic_separation into a355f00fee8b66b0b30b23c91d8a4c9c941b68aa on develop.

Coverage increased (+1.5%) to 90.091% when pulling abf1ff5fe1e75cccd1ed6cc0ad8787f701fbe664 on plugin_logic_separation into a355f00fee8b66b0b30b23c91d8a4c9c941b68aa on develop.

Coverage increased (+1.5%) to 90.082% when pulling 0b0a1a57bc107ec08a36501017ee67ceb4e81f98 on plugin_logic_separation into a355f00fee8b66b0b30b23c91d8a4c9c941b68aa on develop.

Coverage increased (+1.5%) to 90.055% when pulling 687d1f6dbf4100b99daff88897f88a4144a9ff17 on plugin_logic_separation into a355f00fee8b66b0b30b23c91d8a4c9c941b68aa on develop.

Coverage increased (+1.5%) to 90.055% when pulling 5bc35aa266a21a3dfe8223202f8db9821b3aca76 on plugin_logic_separation into bb8c482d807f4b2948ea8068c864e3b5a5502264 on develop.

Coverage increased (+1.5%) to 90.055% when pulling 5bc35aa266a21a3dfe8223202f8db9821b3aca76 on plugin_logic_separation into bb8c482d807f4b2948ea8068c864e3b5a5502264 on develop.

Coverage increased (+1.5%) to 90.073% when pulling 26a9a76e626be1389b329487d6b8ca2814bfc01f on plugin_logic_separation into bb8c482d807f4b2948ea8068c864e3b5a5502264 on develop.

Coverage increased (+1.5%) to 90.046% when pulling 89716334e37540fa8a57776823b5b65edd1d32ed on plugin_logic_separation into bb8c482d807f4b2948ea8068c864e3b5a5502264 on develop.


Unable to run hashicorp vault with "file" storage backend

Is this a regression?
No
Description
I was able to setup a local hashicorp vault with "file" storage backend, it created the default wallet correctly but failed when adding the first DID peer.
Please provide the exception or error you saw
m3-issuer-prism-agent-1   | Response body: {"errors":["1 error occurred:\n\t* open /vault/data/logical/b6134311-005b-2744-477b-259c225c78fe/a6f1a24f-4693-d250-d371-8ddab72208fb/metadata/8GdHsvboNsrDeGnP8MxCiyIhR8WajBIMitq7GgVfQhS6J0OCSdPmTw1cwCget3uDGsY
5CzhlAPKxey42dZ1on8zfCB7wE6zMt28pNKoGuzwKSyOziWD9Cdi9L/5kKXPnw9EiktVFBnVeYCl6q6IPgZ3KR1okxcdXQKXz5xlatNFW7VOP1ED2VLY1/5kKQkEa8jsLZQu1PkOjMbe5Nnk7wzlBaXU0YIlNiUKc5S4qSzJLsBem7VdTbGJ/7ujkCh6BErqSYoCKo7OS4vi3EtMjj6Sn49mTgJtWKCBA9fuXyzXT6HqOF7SN8QvxuS9ANLoS
pKXurRdcMSImLyTlziMTL7PeDKOklmrzUiRhHHyNprd91W87yUZ3WVP8zxjqP6CtZIfN4JEA03jZsHyMxutYmfuke0KjXcSW2D4HMHtc1s7CIPb369sk0pmYvRO0jaWwhucaS704LcYaqaWyRxaAgIe372aSjUSM91SUgQm9xRw4Ye2XpHnDOrKGDihCKu7OESA9XX588pQOWAR5esvSYkotnK9WqjQ5hPUFi6RX6iuvCeRIyoe8baSVvUI1L
R0pGdRECaP1T2UfTbVQYzybJ7eNDVUWeFr8EV8vJc9EhSumuk5WOvhUqDSgV8WXvgWvBANJ0bAMVU9Kq87NQGyeN7pdhbmEFS/5kL62X9U1wD59d3GAHB9DTCINqOWwh9MhsjogAyugwFUUYE62URQJtG6F0e0hL/_1TfEf5dV1nuPdkU5G8g4Nnnz4Alw5xVa4bJBQaqh2Gg5pSC6rYy0ynu45kXQmT43z1Jc1Bo2V: file name too lo
ng\n\n"]}

Please provide the environment you discovered this bug in
open enterprise agent v1.25.0

Anything else?
This works when using "dev" mode, meaning the vault storage backend is "inmem" (in memory).
The problem seems to be that the secret path of the DID peer is too long, I have not tested this with the production "raft" storage backend, I am only trying to run hashicorp locally with a simple storage engine.

@yshyn-iohk to triage

@robertocarvajal, could you provide your docker-compose file or any other details on how you run the Agent and the Vault?

sure, the docker vault-server entry looks like this
  vault-server:
    image: hashicorp/vault:latest
    ports:
      - "<IP_ADDRESS>:8200:8200"
    environment:
      VAULT_ADDR: ${VAULT_ADDR}
      VAULT_DEV_ROOT_TOKEN_ID: ${VAULT_DEV_ROOT_TOKEN_ID}
    volumes:
      - ./config.hcl:/vault/config/config.hcl:ro
    command: server
    #command: server -dev -dev-root-token-id=${VAULT_DEV_ROOT_TOKEN_ID}
    cap_add:
      - IPC_LOCK
    healthcheck:
      test: ["CMD", "vault", "status"]
      interval: 20s
      timeout: 5s
      retries: 10

basically I'm passing a custom config to setup my persistent storage vault, the config.hcl looks like this
ui = true

listener "tcp" {
  tls_disable = 1
  address = "[::]:8200"
  cluster_address = "[::]:8201"
  # Enable unauthenticated metrics access (necessary for Prometheus Operator)
  #telemetry {
  #  unauthenticated_metrics_access = "true"
  #}
}

#storage "inmem" {}

storage "file" {
  path = "/vault/data"
}

# Example configuration for using auto-unseal, using Google Cloud KMS. The
# GKMS keys must already exist, and the cluster must have a service account
# that is authorized to access GCP KMS.
#seal "gcpckms" {
#   project     = "vault-helm-dev"
#   region      = "global"
#   key_ring    = "vault-helm-unseal-kr"
#   crypto_key  = "vault-helm-unseal-key"
#}

# Example configuration for enabling Prometheus metrics in your config.
#telemetry {
#  prometheus_retention_time = "30s"
#  disable_hostname = true
#}

secrets {
  enable = true
}

path "secret/*" {
  backend = "kv"
  version = 2
}

When I create the agent from start, I first connect to the vault docker, init the vault, then unseal it, and then create the secrets kv store.
$ docker exec -i -t issuer-vault-server-1 /bin/sh
# vault operator init
... copy/backup the vault token and unseal keys ...
# export VAULT_TOKEN=_vault_token_here_
# vault operator unseal
... unseal is done 3 times until the vault is unsealed ...
# vault secrets enable -version=2 -path=secret kv

Then I stop the agent, set the VAULT_TOKEN on the agent, start the agent and again, unseal the vault again. Once the vault is unsealed and the agent has the VAULT_TOKEN it will create the default wallet seed, that's all great and it means it's working. The problem arises when I try to connect to the agent and it needs to create a DID peer.

Hi @robertocarvajal, thanks for raising this.
I tested with the provided configuration and it is indeed a problem. Currently, the logical path for the did:peer is defined here. The physical path seems inflated a bit and the filesystem backend is not happy with the convention we're using. We're considering moving to a fixed-length hash for some path segment (especially the DID string) to alleviate the issue on some backend / OS. It has some implication on the policy configuration, but not a show stopper.
In the meantime, SECRET_STORAGE_BACKEND=postgres can be used for local development. Or if you build from source and want to use vault, you can update this line to this, just to get around it while we're on it.
s"secret/${walletId.toUUID}/dids/peer/${did.value.take(20)}/keys/$keyId"

Any suggestions are welcome :smile:

@patlo-iog  thank you for looking into this!
Yeah the physical path is longer because Hashicorp seems to encrypts the path in the vault resulting in an even longer filename and goes over the general 255 chars limit on common linux filesystems.. I guess first I'll try specialized filesystems and mount a volume that supports very long filenames, I'm not familiar enough with the internal code of the agent to suggest a robust solution over there unless is a mix between DB and hashicorp, like using a uuid for the DID peer path that you can query using the DID peer string on the DB as a lookup, then read the keys from hashicorp, that's my naive solution without really knowing the internals of the agent :)

Hey @robertocarvajal , this change should solve it https://github.com/hyperledger-labs/open-enterprise-agent/pull/918. Could you try the new version 1.30.1 with the option VAULT_USE_SEMANTIC_PATH=false. It basically configure the path structure, so you might not be able to read old data. But it does allow backend with limited path length.
I also tested with raft storage, it allows pretty long secret path, so I figure it's best to let the users pick what is right for them. docs here


Add uptos

Add the "Clodosbaldo Russián" Territorial Polytechnic University of Oeste de Sucre to the JetBrains directory

@slorenzotorres First stage of verification passed, official domain is uptos.edu.ve as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@slorenzotorres Thank you for your patience while waiting for a review and processing your request. Pull request merged.


add numeric and letter check uiuisms

Added uiuisms

to check if character is numeric [0-9]. Numberic demo
to check if character is english letter [a-zA-Z]. Letter check demo

In numeric solution i used /= as a AND operator coz if char is number, the function will return [1,1], if its char code is smaller then @0 it will return [0,1] and if its higher then @9 it will be [1,0] so there's no way to get [0,0]
In letter solution we compare to 3 because for example letter @b will return [1 0 1 1] and we need to have (1 and 0) or (1 and 1). So basically if we have 3 1 then at least one condition is met, if we have 2 1 neither condition is met.
There is probably better solution without magic

:o Oh yeah that makes sense. I think it also needs ⊢ in the end so we go from [0] to 0

Oh yeah if we call it on string with length > 1 it will return results for each char, that makes sense, removing first now


Add features to preview guide

It feels like I reviewed this before.

We had a post about this:
https://www.sensenet.com/blog/2021-01-13-docviewer-updates  😄


Delayed_job not processing

Hi!
I am new to DJ.
I am using Rails 3.0.11 and Ruby 1.9.2p290, daemons 1.1.6, delayed_job_active_record 0.3.2.
Everything works fine in development, but when I move it to production jobs are not processed. Jobs are written to delayed_jobs table in mysql but are not processed.
I use Capistrano for deployment and use script/delayed_job start RAILS_ENV=production which runs the worker just fine. But like I said, the jobs are not processed.
Here is the portion of delayed_jobs.log
2012-02-02T05:54:36-0500: [Worker(delayed_job host:xxxx.com pid:2917)] Starting job worker
Where is the problem? Permissions? How to set them?
Thanks

Are you receiving any sort of error? Also, try specifying the rails env before the script/delayed_job.

Have seen some errors in the delayed_jobs table and I fixed the problem. It works now as it should! I also moved te RAILS_ENV before script/delayed_job. Thanks


GAT runtime error

Thank you very much for your meaningful work! However, when I change the GCN to GAT in the config file, the following error is reported, I made attempts but still did not run successfully.
Below is my error log:
Processing...
Done!
seed for seed_everything(): 2024
2024-05-25 23:48:45,472 - Loaded dataset: ABIDE
0%|          | 0/26 [00:00<?, ?it/s]edge_index shape: torch.Size([2, 1280000])
x shape: torch.Size([6400, 200])
Maximum index in edge_index: 6399
edge_attr: torch.Size([1280000])
0%|          | 0/26 [00:00<?, ?it/s]
Traceback (most recent call last):
File "D:/GraduateStudent/code/BrainGB-master/examples/example_main.py", line 152, in
main(parser.parse_args())
File "D:/GraduateStudent/code/BrainGB-master/examples/example_main.py", line 78, in main
test_micro, test_auc, test_macro = train_and_evaluate(model, train_loader, test_loader,
File "D:\GraduateStudent\code\BrainGB-master\examples\train_and_evaluate.py", line 26, in train_and_evaluate
out = model(data)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch\nn\modules\module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "D:\GraduateStudent\code\BrainGB-master\src\models\brainnn.py", line 18, in forward
g = self.gnn(x, edge_index, edge_attr, batch)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch\nn\modules\module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "D:\GraduateStudent\code\BrainGB-master\src\models\gat.py", line 147, in forward
z = conv(z, edge_index, edge_attr)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch\nn\modules\module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\28334\AppData\Local\Temp\torch_geometric.nn.sequential_f0afbb_syfjdr4d.py", line 23, in forward
x = self.module_0(x, edge_index, edge_attr)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch\nn\modules\module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch_geometric\nn\conv\gat_conv.py", line 341, in forward
out = self.propagate(edge_index, x=x, alpha=alpha, size=size)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch_geometric\nn\conv\message_passing.py", line 538, in propagate
coll_dict = self._collect(self._user_args, edge_index,
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch_geometric\nn\conv\message_passing.py", line 399, in _collect
self._set_size(size, dim, data)
File "D:\zj\miniconda\envs\Dual-HINet\lib\site-packages\torch_geometric\nn\conv\message_passing.py", line 298, in _set_size
raise ValueError(
ValueError: Encountered tensor with size 1280000 in dimension 0, but expected size 6400.
Process finished with exit code 1

It's due to your environment not matching the version. I faced the same problem, and I changed my Torch version to fix it.
Btw, if you are using Windows, you can select torch=1.8.1+cu102 with the corresponding torch_geometric version.

Thanks for the reply @Gemaxis , I've run it successfully after changing the version as you said : )


Track instances installed from a bundle

We need a way to track which instances installed on a cluster come from which bundle. The proposed solution is to label the instances with the bundle name, then allow users to query the cluster API based on that name.
Tasks:

[x] Add a required filed called name to the Bundle API
[x] At apply time, label the instances storage (Kubernetes Secret) with bundle.timoni.sh/name: <name>
[x] Add --bundle=<name> to the timoni ls -A to list all instances on a cluster filtered by bundle name

Should we?

Issue a warning if an instance is managed by a different bundle before overriding the label value
Add the bundle name as a column to timoni ls
Add --name to timoni delete bundle as an alternative to -f

Implemented in https://github.com/stefanprodan/timoni/pull/91


[Event Request] Codeunit 80 Sales Post - OnBeforePostItemTracking

Hi, in the Codeunit 80 Sales Post, would it be possible to get an event OnBeforePostItemTracking , like this :

Thanks

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Flexible builder extension and type signature API

Closes #21
For anyone who wants to try out the changes here, you can do so using the following line in Cargo.toml:
[dependencies]
bon = { git = "https://github.com/elastio/bon", branch = "feat/generic-builder-type" }

Example of how this feature works (it already compiles from this branch and existing tests in bon pass):
#[derive(bon::Builder)]
struct Mare {
    name: &'static str,
    age: u32,
    breed: &'static str,
    rating: u32,
}

use mare_builder::{SetAge, SetName, SetBreed};

// Add custom methods to the builder.
impl<State: mare_builder::State> MareBuilder<State> {
    fn name_and_age(self, name: &'static str, age: u32) -> MareBuilder<SetName<SetAge<State>>>
    where
        // Require that members are unset
        State::Name: mare_builder::IsUnset,
        State::Age: mare_builder::IsUnset,
        // Require that members are set
        // State::Breed: mare_builder::IsSet,
    {
        self.name(name).age(age)
    }
}

fn main() {
    // Builder type is finally nameable with a stable type signature!
    let builder: MareBuilder<SetBreed<SetAge<SetName>>> = Mare::builder()
        .breed("Equestrian")
        .name_and_age("Bon Bon", 24);

    let _mare: Mare = builder.rating(99).build();
}

According to my research any slightest usage of associated type projections in the generated code considerably increases the compile time. In the most minimal approach where assoc types are used as trait bounds on setter methods and they aren't used inside of the struct to change its shape the compilation performance of frankenstein (~320 structs) increases from 19 to 20 seconds (from scratch). In the worst case, when assoc types are used to define the type of optional members in the struct the compile time increases to 26 seconds 💥.
I think the ideal balance between safety and compilation performance is such that we:

Use Option<T> to store all named members, including required. We don't use the State::{Member} assoc types in the struct declaration itself to avoid compilation time overhead.
Generate random identifiers for all the private members of the builder struct and its private methods. This way we ensure the user can't use our private fields and methods that may lead to them breaking some unsafe invariants.
Introduce a new private method transition<NewState>(self) -> TBuilder<NewState> that changes the PhantomData type that holds the type state. It's technically an unsafe method (see the following), but it doesn't actually use any unsafe operations. This method will be used by all the generated setters and should reduce the amount of tokens generated considerably (especially for builders with tens of members).
Use unwrap_unchecked for required members in the finish_fn method because we know they are always initialized according to the type state in that method. This is needed because the safe "unwrap" isn't optimized-out by the compiler according to the benchmarks and generated assembly.

[x] Make setter methods inherit builder type visibility by default. Add #[builder(setters = {name})] override
[x] Tests for #[builder(setters)]
[x] Consider alternative name for mutable: overwritable, no_overwrite_protection...
[x] Insert random number into the internal field names to make them genuinely private
[x] Autoresolve name conflicts with the builder state generic parameter

[x] Add tests

[x] Add miri for testing unsafe code
[x] Don't generate the state transition fn if it's not needed (no states)
[x] Revisit naming and identifiers of members, use public_ident
[x] Compile time benchmarks
[x] Add docs to clarify which members required or optional to the default docs
[x] Fix visibility into_equivalent. Paths may start with crate or self in pub(in ...)
[x] Fix selector for overwritable. In fact, on should behave like a match and short circuit on the first match (?)
[x] Consider references and generic types in builder(with) (add tests). Allow only named lifetimes and generics to prevent users from depending on autogenerated names for generics. Maybe traverse the all syntax and reject any mentions of autogenerated lifetimes and generics anywhere
[x] Try vectorizing transition type aliases (e.g. once for every 5 members).

Performance win is not worth it

[x] Make Optional render in a box in docs?
[x] Reconsider automatic bounds on derive(...) and stuff

TODO (separate PR)

[ ] #[builder(on(..., transparent))] support
[ ] #[builder(crate = ...)] override support
[ ] Remove expose_positional_fn
[ ] Update docs about alternatives. Now it is indeed possible to extend the builder, maybe even accept by a mutable reference
[ ] Document an antipattern of impl Trait for optional members
[ ] Update ide completions
[ ] Add compilation benchmarks to the docs
[ ] Update docs on runtime benchmarks
[ ] Docs for IsSet and IsUnset tratis (cleanup lib.rs)
[ ] Add examples to the docs of IsSet trait
[ ] Add docs for various docs { ... } overrides attributes added in https://github.com/elastio/bon/pull/139
[ ] Add docs for various vis(...) configs and how the influence each other (e.g. builder_type visibility influences the builder_mod visibility)

builder_type(vis) - changes the default visibility of builder struct and all of its methods (setters, finish_fn)
start_fn/finish_fn(vis) - changes only the visibility of the start_fn/finish_fn
builder_mod(vis) - changes only the visibility of the builder_mod. Doesn't influence the visibility of items defined inside it (since they are used in the builder's type signature)

[ ] Consider adding overwritable transitions as an extension to the API rather than replacement
[ ] Document the generated builder state module. Add it to the Reference section

Not included in this release

Add support for optional() and ! operators to type patterns expressions. Take a look at rustc_on_unimplemented matching syntax. (Need to decide on the behavior here: should there be short circuit or not?).
impl From for T? There is a new IsComplete trait for the state which may serve as a replacement.
#[builder(field)] to add custom fields to the builder (restriction: custom field names must not collide with other names of members).
#[builder(getter)] to derive getters for every member (start_fn and named).
Add support for #[doc(hidden)], #[doc = include_str!("...")] to docs {} overrides and docs copied from the fields/args
The docs shouldn't reference the companion setter for optional setters if that setter has a lower visibility.

Changelog

Changed the visibility syntax from vis = "..." to vis(...). Use vis(pub(self)) for private visibility. Decided not to do this. I think = ... syntax reads better.
Allow overriding the visibility of the builder_type and finish_fn
Add #[builder(with = closure)] syntax to customize setters
Add #[builder(transparent)] for Option fields to opt out from their special handling which makes such fields optional
Add #[builder(state_mod)] to configure the builder type state API module
Add #[builder(overwritable)] and #[builder(on(..., overwritable)] to make it possible to call setters multiple times for the same member
Add #[builder(setters)] to fine-tune the setters names, visibility and docs
Add #[builder(derive(Clone/Debug(bounds(...))] to allow overriding trait bounds on the Clone/Debug impl block for builder
Improve rustdoc output

Add info that the member is required or optional.
For members with defaults values show the default value in the docs.
For optional members provide a link to a companion setter. The docs for {member}(T) setter mention the maybe_{member}(Option<T>) setter and vice versa.
Remove __ prefixes for generic types and lifetimes from internal symbols. Instead the prefixes added only if the macro detects a name collision.

Reject non-empty #[bon(...)] attribute. This attribute will accept some parameters in future releases
Reject square brackets and curly braces delimiters for builder_type, finish_fn, start_fn and on attributes syntax. Only parentheses are accepted e.g. #[builder(finish_fn(...))] or #[builder(on(...))]. This no longer works: #[builder(finish_fn[...])] or #[builder(on{...})]

Points for discussion

Should the module with builder type state API be private by default? This effectively makes the type signature of the builder (except for the initial state) private. Code outside of the module where builder is defined can't name the builder type. It's possible to make that type state API public by adding #[builder(builder_mod(vis = "pub"))]
The naming #[builder(transparent)] to disable the special handling for members of type Option<T>. Alternatives: #[builder(opaque)], #[builder(blindfold)].
Specific format of the docs (should Optional be also rendered in the box, or should it intentionally stand out less)?

Summary by CodeRabbit

New Features

Introduced new benchmarking scripts and configurations to enhance performance testing.
Added a new README.md for the compilation benchmarks, detailing dependencies and usage instructions.
Enhanced error messages for builder attributes to improve debugging experience.

Bug Fixes

Resolved issues with attribute handling in the Rust code, including redundant and unsupported syntax.

Documentation

Updated and reorganized documentation for clarity, including new examples for positional members and builder patterns.

Chores

Updated the Rust toolchain version for improved performance and compatibility.

Quick feedback on a simple example :
impl<State: endpoint_builder::State> EndpointBuilder<State> {
    pub fn smart_crop(self) -> EndpointBuilder<SetSmart<State>>
    where
        State::Smart: bon::IsUnset,
    {
        self.smart(true)
    }
}

The API is very straightforward and convenient to work with, nice work 🎉

Thank you for the feedback ❤, this should be landed in the next couple of weeks

Finally, this mega-PR is ready to merge. There are two low-effort features that I'd like to include in the upcomming release and the remaining work is left only for the documentation and a blog post.
I'll do that in separate followup PRs. Then I'll cut off a 3.0-rc (release-candidate) version of bon to gather some initial feedback on all the changes and maybe potential early bugs. Hopefully, there won't be any breaking changes to the new APIs as a result of that, but I'd still like to reserve some time to let these features boil in a "preview" 3.0-rc version for some short period of time.


Add how to build in eclipse

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[x] New feature provided

[ ] Improve performance

Related issues

Bug fix

Bug description.

How to fix?

New feature or improvement

Describe the details and related test reports.
Add How to build in eclipse

Coverage remained the same at 24.591% when pulling f1cca17903b684a9dbb8e31cb711ab8e42302228 on Xlinlin:master into cc664175e29e7584960bf5b1f9eaa880602e4fa2 on apache:master.

Completed format pom.xml and  add english version

Because the compiled RemoteCommonServiceGrpc.java files of collector-remote-grpc-provider project will compile errors.

Because the compiled RemoteCommonServiceGrpc.java files of collector-remote-grpc-provider project will compile errors.

So strange, why, the dependency should exist. Otherwise, mvn compileshould fail.

mvn can be compiled successfully, but grpc source code will display errors, adding guava dependency is normal.


Print warning when selected runtime version is/will be going EOS

Similar to the work done in the Node.js and Go Buildpacks, we should start printing deprecation messages in all Python buildpacks that let users select a runtime version when a dependency is/will be EOS.

I see that currently the miniconda and cpython dependencies have deprecation dates available in buildpack.toml. These are missing for pipenv and pip. Will we need to gather deprecation date information for those dependencies?

FYI the miniconda deprecation date is not actually meaningful and should be removed. See this comment for more details.

I have not found any meaningful policy around deprecation dates for pip. The official release policy states they generally release every three months - January, April, July, and October. The release history demonstrates that this cadence is generally followed. There is no particular date within the month that a version is released, so this cannot be programmatically determined.
There does not appear to be any policy around whether a given release is minor or major (i.e. whether it is backwards compatible or not). There is also no stated policy about historical support for past versions. Empirically, we observe that pip provides patches only for the current release, with no patches made available for past releases.


Debug on large pandas DataFrame is very slow

Environment data

VS Code version: 1.66.0-insider
6b7453421201c888b81eae5c04ec822a6423608f
x64
Jupyter Extension version (available under the Extensions sidebar): 2022.2.1030672458
Python Extension version (available under the Extensions sidebar): v2022.2.1924087327
OS (Windows | Mac | Linux distro) and version: Windows
Python and/or Anaconda version: 3.9.10
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
Jupyter server running: Remote

Expected behaviour
When working on large dataFrames, the debugger seems to slow down the process by a lot
Step to reproduce
import pandas as pd
d = pd.DataFrame(data={"a": range(10_000_000)})

d["a"].apply(lambda k: str(k) + "lol") # Run this with and without debugger

I don't know if it's the normal behavior or not, so sorry for opening an issue if not needed

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

Also, is this specific to a specific method of debugging - (run-by-line or debug cell), or does this also repro when debugging a python file?


Anvil.render() and ripple effect drawable problem

I have detected a problem with Anvil rendering of views and the ripple drawable. I have some buttons that on api >= 21 have a ripple effect when the user presses them.
The problem is if that the action of the button triggers an Anvil.render() this ripple effect is not displayed. If the button doesn't trigger any render on part of anvil the animation plays normally.
What I tested:

no click listener whatsoever -> proper animation
Anvil's onClick() with code that changes some view state -> no animation
Anvil's onClick() with empty listener -> no animation
Anvil's init() with Android setOnClickListener() with empty listener -> proper animation
Anvil's init() with Android setOnClickListener() with listener that changes some view state without Anvil.render() -> proper animation but no view change
Anvil's init() with Android setOnClickListener() with listener with only Anvil.render() -> no animation
Anvil's init() with Android setOnClickListener() with listener that changes some view state with Anvil.render() but view changes properly -> no animation

This is because Anvil use simple java equals() mechanism for comparing values. You probably set RippleDrawable to DSL.background, and Anvil sets every  render cycle new RippleDrawable object.
As workaround you can use backgroundResource(R.drawable.yourripple), and ripple will be shown just fine.


Fix image location on webpage - windows

Fix https://github.com/lstein/stable-diffusion/issues/565

Thanks for approving the changes, i will close my initial issue then.


Add requirements.txt and requirements-test.txt

As a python package it is very useful to have requirements.txt to automatically install requirements.

Hi @fjovell
It can be very useful but it isn't quite necessary for the package's dependencies because those dependencies are stored in setup.py. Pip knows how to install the package and doesn't use requirements.txt, you have to tell pip to use it. A lot of projects read that file on demand to copy it's contents whenever running setup.py.
For example, you can install the package and it's dependencies in either of these ways:

pip install cfscrape
pip install -e .

The latter of the two may be used when you've cloned the repo. Adding requirements.txt to store the dev-dependencies separately from the package's requirements is a valid use case and is conventional.
For that purpose, my preference is requirements-dev.txt. However, I prefer the use of Pipenv with Pipefile/Pipelock files over any requirements.txt since it makes the development environment more deterministic by locking all dependencies(inclusive of sub-dependencies) and uses a virtual environment. The project owner is in preference of using Pipenv as well.
Once you have a Pipefile, it's quite easy to generate a requirements.txt from it: https://docs.pipenv.org/en/latest/advanced/#generating-a-requirements-txt
requirements.txt could still be added although it would be more of a chore to keep it in sync.
You can expect this and other dev related configuration to be added to the repository soon. If you want to speed that up, PR's are welcome!

Hi @pro-src,
I just mentioned the requirements.txt as a way to quickly install requirements and test the package and since there is no information on the README I had thought I asked first. Probably a section at the end of the file to add these details you mentioned for possible contributors would be a fine addition.

I'm working on a PR to add this stuff at this very moment. Once it lands, if you want to send a PR to document the dev workflow, I'm sure that would be welcomed. Is it okay to close this?

That sounds great! you might as well add the documentation on the very same PR. Otherwise yes, it's okay to close.

@fjovell https://github.com/Anorov/cloudflare-scrape/pull/246


ecall and memory mapping info to README

It's a good idea to have these documented. I decided to start on a user guide, and added this info there.

Good that you started the documentation. However, I would not list the ecall functions under RISC-V. I doubt this is a RISC-V standard as I could not find anything in the RISC-V manual. I assume spike does not support those same calls. Or does it?
Cheers,
Martin

On 13 Aug, 2017, at 9:33, Keyhan Vakil<EMAIL_ADDRESS>wrote:
It's a good idea to have these documented. I decided to start on a user guide https://github.com/kvakil/venus/wiki, and added this info there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/kvakil/venus/pull/7#issuecomment-322026945, or mute the thread https://github.com/notifications/unsubscribe-auth/AAntmCriDUtdm-C0p5Y490MGjadJ86KIks5sXqbWgaJpZM4O0Wvt.


supports MS-DBM collection in fractal ordinal

Collection mint is still in progress, so this is a first batch of minted items.

discord link doesn't work. @r3disdead

discord link doesn't work. @r3disdead

done

Any update @cloud6605 ?
Thanks


MXNet 0.11.0 Release Feedback: Source Headers and License Files

As discussed in various email threads - Voting thread, Source Headers and ICLAs vs Contributors
1. Headers
a) "The source headers should be reverted in any areas where not all contributors to that file have signed ICLAs, otherwise we need some kind of agreement they are OK with moving to NOTICE file (which is how this has been handled in the past)"
b) While a number of file (around 50 odd) do have "Copyright (c) 2016 by Contributors” they don’t have a full Apache licensed header please fix this in the next release. More files exist with other years and without the correct header.
2. License Files
a) Missing - BSD license for this file [4]
b) Missing - MIT licensed JQuery and Sizzle.js [5]
c) Missing - This BSD licensed file [6]
d) Missing - Boost Software licensed file [7]
e) Missing - This BSD licensed files [8][9]
f) This license file may be a little misleading [1] where its apache license but also claims “All rights reserved”. I notice this in a number of other places as well.
g) A number of Apache licenses have incorrect appendixes with the copyright line filled in e.g. [2]
h) This file may incorrect have an ASF header on it [3]
3. Files referred above can be found as follows -
[1] ./src/operator/contrib/ctc_include/LICENSE
[2]../dlpack/LICENSE
[3] ./example/image-classification/predict-cpp/image-classification-predict.cc
[4] ./docs/_static/searchtools_custom.js
[5] ./docs/_static/jquery-1.11.1.js
[6] ./cub/test/mersenne.h
[7] ./cmake/Modules/FindJeMalloc.cmake
[8] ./dmlc-core/cmake/Modules/FindCrypto.cmake
[9] ./nnvm/dmlc-core/cmake/Modules/FindCrypto.cmake

Why are we hosting our own jquery? They have their own CDN and has a minified version instead of the full version, which is good for loading time.

Questions -

It says that the LICENSE of files like - /dlpack/LICENSE, ./cub/test/mersenne.h should be corrected (they include copyrights). Can I correct these submodule licenses ?

There were several email threads in this regard - “The source headers should be reverted in any areas where not all contributors to that file have signed ICLAs, otherwise we need some kind of agreement they are OK with moving to NOTICE file (which is how this has been handled in the past)“. Have we decided on how to handle this?

Is this file actually supposed to have the Apache license: https://github.com/apache/incubator-mxnet/blob/master/example/image-classification/predict-cpp/image-classification-predict.cc?

My thoughts on this, all of which should be fixed for the next release:

Headers:

Any file that existed before the dmlc->apache move should have two headers. The old one and the standard ASF one. Any file that was created after the code move should have only the standard ASF header. Note that this is high level, there may be a file that has other types of src headers, like maybe a piece of BSD code was copied in etc.

License files. All these should be fixed.

--
On your questions:
1: I don't think we should be changing those two files. The files are currently in dmlc and not in apache. They are a style-bug in dmlc, and we do have the question of whether we should be pulling this code into mxnet as source the way we do.
2: I believe this means putting back "* Copyright (c) 2015 by Contributors" (or sometimes a different year), wherever that was deleted in https://github.com/apache/incubator-mxnet/pull/7379
3: It does look confusing. It looks like it came in on this pull request pre-Apache days: https://github.com/apache/incubator-mxnet/pull/891 . As it was a contribution to an Apache 2.0 licensed project, the contribution would be under Apache 2.0. It looks like it is a specific version of the DMLC "Copyright Contributors" that is listing the 3 contributors who worked on the pull request. I would treat it the same as you do other DMLC files that say Copyright, but in this case list the three people instead of 'Contributors'.

Henri, Thanks for your response.

Headers: both a) and b) are going to affect almost all headers - this is too large a change to include in 0.12.0.
This refers to both the points -
a.  Any file that existed before the dmlc->apache move should have two headers. The old one and the standard ASF one. Any file that was created after the code move should have only the standard ASF header. Note that this is high level, there may be a file that has other types of src headers, like maybe a piece of BSD code was copied in etc.
b.  I believe this means putting back "* Copyright (c) 2015 by Contributors" (or sometimes a different year), wherever that was deleted in #7379

License files. All these should be fixed. --- done
a) done
b) done
c) submodules - not done
d) done
e) submodules - not done
f) done / submodules- not done
g) done /submodules -not done
h) done - Henri in #3 verified this file should have the ASF header

@bhavinthaker @srochel
Do you agree?

Henri - #1 is too big a change to take into 0.12 in the last minute. We will address and include in next release.

Let's flag it in the release vote and see what dev@ and general@incubator say. Release dates are not set in stone.

All issues here have been fixed.


DynComparator/LexicographicalComparator Incorrectly Handles Dictionary Nulls

Describe the bug

DynComparator does not inspect null masks. This is by design as it isn't provided a SortOptions specifying how to order them.
Unfortunately the values array of a dictionary is permitted to contain nulls, which causes the comparator to break.
To Reproduce

The builders will never put a null in a dictionary, but if you manually construct the DictionaryArray from ArrayData it is possible.
let values = Int32Array::from_iter([None, Some(1)]).into_data();
let keys =
    Int32Array::from_iter([Some(0), None])
        .into_data();

let data = keys
    .into_builder()
    .data_type(DataType::Dictionary(
        Box::new(DataType::Int32),
        Box::new(DataType::Int32),
    ))
    .child_data(vec![values])
    .build()
    .unwrap();
let dictionary = DictionaryArray::<Int32Type>::from(data);

If you then construct a comparator on this dictionary it will say that the two rows are not equal, when they are technically both null. If you remove the Some(1) it will panic.
Expected behavior

This should be handled correctly
Additional context

Longer term I intend for these to be deprecated and replaced with the row format #2677, and so perhaps we just defer on fixing this.

This same issue also impacts the ability to add support for nested types, such as structs #3187


Add script which adds worker node running via kubelet to facilitate r…

This was tested on top of https://github.com/openshift/microshift/pull/1717, which should merge soon.
To run it set WORKER_NODE_HOSTNAME to the hostname of a host which is setup to run microshift and run configure-multinode.sh on the microshift host. The worker node doesn't actually need to have microshift installed through, just CRI-O and OVN. Also make sure that microshift-ovs-init.service was run on the worker node so that OVN is setup the way that microshift expects.
Running the conformance tests on a cluster setup this way, we still have 15 test failures:
[It] [sig-network] DNS should provide DNS for pods for Hostname [Conformance]
[It] [sig-network] Services should be able to change the type from ClusterIP to ExternalName [Conformance]
[It] [sig-network] DNS should resolve DNS of partial qualified names for services [LinuxOnly] [Conformance]
[It] [sig-network] DNS should provide /etc/hosts entries for the cluster [Conformance]
[It] [sig-network] Services should be able to switch session affinity for NodePort service [LinuxOnly] [Conformance]
[It] [sig-network] DNS should provide DNS for ExternalName services [Conformance]
[It] [sig-network] DNS should provide DNS for the cluster  [Conformance]
[It] [sig-network] Services should be able to change the type from NodePort to ExternalName [Conformance]
[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance]
[It] [sig-auth] ServiceAccounts ServiceAccountIssuerDiscovery should support OIDC discovery of service account issuer [Conformance]
[It] [sig-network] DNS should provide DNS for services  [Conformance]
[It] [sig-network] DNS should provide DNS for pods for Subdomain [Conformance]
[It] [sig-network] Services should serve multiport endpoints from pods  [Conformance]
[It] [sig-network] Services should serve a basic endpoint from pods  [Conformance]
[It] [sig-network] Services should have session affinity work for NodePort service [LinuxOnly] [Conformance]

@jerpeter1, this script will not pass the verify check due to minor syntax issues.
Could you run make verify in your environment and fix those?

@jerpeter1, this script will not pass the verify check due to minor syntax issues. Could you run make verify-sh in your environment and fix those?

Done.

@jerpeter1, how do you feel about simplifying the script by adding a mode of an operation (main / worker) instead of trying to configure ssh and automatically running the script remotely? This should leave the remote invocation responsibility in the hands of the caller, which may make it more straightforward to write and use.

@jerpeter1  I got the tls error with kubelet service running on the worker node, any idea what is missing?
Failed to listen and serve" err="tls: private key does not match public key

@jerpeter1 I got the tls error with kubelet service running on the worker node, any idea what is missing?
Failed to listen and serve" err="tls: private key does not match public key

I think it's because kubelet.crt and kubelet.key don't match for some reason? Here's how to check:
[microshift@worker-node kubelet]$ openssl rsa -in kubelet.key -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
writing RSA key
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e
[microshift@worker-node kubelet]$ openssl x509 -in kubelet.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e

The fingerprints should match.

@jerpeter1 I got the tls error with kubelet service running on the worker node, any idea what is missing?
Failed to listen and serve" err="tls: private key does not match public key

I think it's because kubelet.crt and kubelet.key don't match for some reason? Here's how to check:
[microshift@worker-node kubelet]$ openssl rsa -in kubelet.key -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
writing RSA key
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e
[microshift@worker-node kubelet]$ openssl x509 -in kubelet.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e

The fingerprints should match.

they match with each other in my env:
[root@microshift-dev-worker kubelet]# openssl rsa -in kubelet.key -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
writing RSA key
SHA2-256(stdin)= fe:60:43:4d:29:f3:61:a2:7c:7c:10:bd:c1:a4:97:3f:ad:b1:03:ed:0f:52:1a:28:54:31:38:cd:66:7a:13:6e

[root@microshift-dev-worker kubelet]# openssl x509 -in kubelet.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
SHA2-256(stdin)= fe:60:43:4d:29:f3:61:a2:7c:7c:10:bd:c1:a4:97:3f:ad:b1:03:ed:0f:52:1a:28:54:31:38:cd:66:7a:13:6e

Here's a video of the script running: https://drive.google.com/file/d/1_H-Ga58sFnBVpEtv3ucSQ9bN7Hx2N2tR/view?usp=sharing

Failed to listen and serve

Did you disable selinux and the firewall on the worker node (this is done by the script, but maybe you were running some parts manually?)

@jerpeter1 I got the tls error with kubelet service running on the worker node, any idea what is missing?
Failed to listen and serve" err="tls: private key does not match public key

I think it's because kubelet.crt and kubelet.key don't match for some reason? Here's how to check:
[microshift@worker-node kubelet]$ openssl rsa -in kubelet.key -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
writing RSA key
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e
[microshift@worker-node kubelet]$ openssl x509 -in kubelet.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
SHA2-256(stdin)= d6:f5:fd:e6:9a:10:f0:db:83:93:54:85:39:31:19:9b:bc:e1:16:5d:80:7d:40:3b:bc:d0:a7:12:6b:3d:01:0e

The fingerprints should match.

they match with each other in my env:
[root@microshift-dev-worker kubelet]# openssl rsa -in kubelet.key -pubout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
writing RSA key
SHA2-256(stdin)= fe:60:43:4d:29:f3:61:a2:7c:7c:10:bd:c1:a4:97:3f:ad:b1:03:ed:0f:52:1a:28:54:31:38:cd:66:7a:13:6e

[root@microshift-dev-worker kubelet]# openssl x509 -in kubelet.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -c
SHA2-256(stdin)= fe:60:43:4d:29:f3:61:a2:7c:7c:10:bd:c1:a4:97:3f:ad:b1:03:ed:0f:52:1a:28:54:31:38:cd:66:7a:13:6e

I need to delete the files under /home/microshift/kubelet/ to make the certificate back to work on a secondary run, it seems the /home/microshift/kubelet/kubeconfig is not updated if already exist. Would it make sense to add a cleanup script?

Failed to listen and serve

Did you disable selinux and the firewall on the worker node (this is done by the script, but maybe you were running some parts manually?)

Yes, I used the script directly. selinux and firewall are disabled by the script.
btw, I see the host name contains fedora in your shared demo. are you using fedora as host system or rhel? maybe that could make a difference on the bind:<IP_ADDRESS> permission denied issue?

are you using fedora as host system or rhel?

The VM host is fedora. Both VMs (microshift node and worker node), are VMs provisioned via ./scripts/devenv-builder/manage-vm.sh. What "bind:<IP_ADDRESS> permission" issue are you talking about?

the following test pod failed with bind permission denied.

In the one conformance test that's failing? I'm not seeing that in in the sonobouy logs from my last test run: https://drive.google.com/file/d/16_vm0F0nZuAfd3quOaF5ibJdne1nxR6d/view?usp=sharing

are you using fedora as host system or rhel?

The VM host is fedora. Both VMs (microshift node and worker node), are VMs provisioned via ./scripts/devenv-builder/manage-vm.sh. What "bind:<IP_ADDRESS> permission" issue are you talking about?

I tried to spin up new VMs with manage-vm.sh and run this multinode script with selinux disabled, got the same failure.
$ oc -n kubectl-726 logs -f frontend-78cd9dfff5-kz59m
I0505 01:57:38.911498       1 log.go:198] listen tcp :80: bind: permission denied

what are the rhel and selinux pkg versions in your env?
here is mine:
$ uname -r
5.14.0-283.el9.x86_64

$ rpm -qa  |grep selinux
libselinux-3.5-1.el9.x86_64
libselinux-utils-3.5-1.el9.x86_64
python3-libselinux-3.5-1.el9.x86_64
selinux-policy-38.1.8-1.el9.noarch
selinux-policy-targeted-38.1.8-1.el9.noarch
rpm-plugin-selinux-<IP_ADDRESS>-22.el9.x86_64
selinux-policy-devel-38.1.8-1.el9.noarch
container-selinux-2.208.0-2.rhaos4.13.el9.noarch
microshift-selinux-4.14.0_0.nightly_2023_04_26_154754_20230503190749_dacabf8e_dirty-1.el9.noarch
openvswitch-selinux-extra-policy-1.0-31.el9fdp.noarch

@ggiguash  are you able to run the conformance tests with the PR,  wonder what result did you get?

I tried to spin up new VMs with manage-vm.sh and run this multinode script with selinux disabled, got the same failure.

Are you following the instructions for running the conformance tests on openshift?
https://github.com/cncf/k8s-conformance/tree/master/v1.24/openshift
Maybe you didn't run the commands to allow unprivileged users to run privileged containers?
oc adm policy add-scc-to-group privileged system:authenticated system:serviceaccounts
oc adm policy add-scc-to-group anyuid system:authenticated system:serviceaccounts

what are the rhel and selinux pkg versions in your env?

Same on microshift node and worker node:
[microshift@microshift-jerpeter-fedora-9 microshift]$ uname -r
5.14.0-283.el9.x86_64
[microshift@microshift-jerpeter-fedora-9 microshift]$ rpm -qa  |grep selinux
libselinux-3.5-1.el9.x86_64
libselinux-utils-3.5-1.el9.x86_64
python3-libselinux-3.5-1.el9.x86_64
selinux-policy-38.1.8-1.el9.noarch
selinux-policy-targeted-38.1.8-1.el9.noarch
rpm-plugin-selinux-<IP_ADDRESS>-22.el9.x86_64
selinux-policy-devel-38.1.8-1.el9.noarch
container-selinux-2.199.0-1.el9.noarch
microshift-selinux-4.14.0_0.nightly_2023_04_03_211601_20230419120715_060a5a07-1.el9.noarch
openvswitch-selinux-extra-policy-1.0-31.el9fdp.noarch

I tried to spin up new VMs with manage-vm.sh and run this multinode script with selinux disabled, got the same failure.

Are you following the instructions for running the conformance tests on openshift?
https://github.com/cncf/k8s-conformance/tree/master/v1.24/openshift
Maybe you didn't run the commands to allow unprivileged users to run privileged containers?
oc adm policy add-scc-to-group privileged system:authenticated system:serviceaccounts
oc adm policy add-scc-to-group anyuid system:authenticated system:serviceaccounts

@jerpeter1 You're right, I didn't configure these policies. I followed the cncf/k8s-conformance instructions, wasn't aware of the openshift specific settings. thanks for sharing!
I got the same result as you now after configuring the policies.
[FAIL] [sig-auth] ServiceAccounts [It] ServiceAccountIssuerDiscovery should support OIDC discovery of service account issuer [Conformance]

I0506 02:54:43.170130       1 log.go:198] failed to validate with in-cluster discovery: failed to verify signature: fetching keys oidc: get keys failed Get "https://<IP_ADDRESS>:6443/openid/v1/jwks": x509: certificate is valid for <IP_ADDRESS>, not <IP_ADDRESS>

Looks like the certificate issue again, <IP_ADDRESS> is control plane node IP.

/retitle USHIFT-485: Add script which adds worker node running via kubelet

We discussed this on the team meeting and the current implementation seems to work with some prerequisites.
Let's merge this PR and iterate on documenting the flow and enhancing the script.
/lgtm

The #1717 PR has merged
/unhold

/override ci/prow/e2e-openshift-conformance-reduced


Set window.Turbo on import

This makes sure Turbo is available for Request.js and Turbo Native out
of the box.
Related to rails/request.js#6

Added a test to make sure the ESM module also sets window.Turbo
This one should be ready to go @dhh @marcelolx

are you sure that this a good idea @excid3 ?
what happens if a user does not want to expose this to window ? wouldn't be better to delegate this to the user ?

are you sure that this a good idea @excid3 ?
what happens if a user does not want to expose this to window ? wouldn't be better to delegate this choice to the user ?

@michelson Have you a scenario where it would be a bad idea Turbo exposing itself to the window? I'm asking because I really don't know if there would be a problem or not

I think this is indeed the better default, but I'd also like to see an option where someone could import Turbo without triggering window + autostart. That would be a separate build target, though. That's more of a nice-to-have.
Having window.Turbo set is needed for all the native integrations anyway. And it makes it easier to drop Turbo into a site and start using it right away.

@michelson Have you a scenario where it would be a bad idea Turbo exposing itself to the window? I'm asking because I really don't know if there would be a problem or not
the only scenario I can imagine right now is for example some sort of widget app that could be imported on sites (like chat widgets like intercom) I would expect that app will self contained and not mess with the rest of the app.


Upcoming .NET 8 migration

Summary
We are currently working on migrating our Azure Pipelines Agent to use .NET 8 instead of .NET 6. This migration will result in some legacy systems being deprecated and falling outside of support.
Why?
.NET 6 is approaching its end of life, and we will soon be unable to deliver critical security updates.
Versioning
We will begin releasing a new major version of the agent (v4), while continuing to provide new features and fixes for the current mainstream version (v3) until end of this year.
Operating system support
removed
added

Linux

x64

Debian 10+ 11 & 12
Fedora 36+ 39 & 40
openSUSE 15+ 15.5 & 15.6
Red Hat Enterprise Linux 7+ 8 & 9
SUSE Enterprise Linux 12 SP2 or later 15.5
Ubuntu 24.04, 22.04, 20.04 ,18.04,16.04
Azure Linux 2.0
Oracle Linux 7 and higher 8 & 9

ARM64

Debian 10+ 11 & 12
Ubuntu 24.04, 22.04, 20.04 ,18.04

Alpine x64

Alpine Linux 3.13 and higher 3.17 to 3.20

macOS

x64

macOS 10.15 "Catalina"
macOS 11.0 "Big Sur"
macOS 12.0 "Monterey"
macOS 13.0 "Ventura"
macOS 14.0 "Sonoma"
macOS 15.0 "Sequoia"

ARM64

macOS 11.0 "Big Sur"
macOS 12.0 "Monterey"
macOS 13.0 "Ventura"
macOS 14.0 "Sonoma"
macOS 15.0 "Sequoia"

Windows

Client OS

Windows 7 SP1 [ESU]
Windows 8.1
Windows 10

21H2
11 23H2, 11 22H2, 10 22H2, 11 21H2

Windows 11

10 21H2, 10 1809, 10 1607

Server OS

Windows Server 2012 or higher

Still no Windows ARM64?


jobs get stuck in running state

Describe the bug
When the worker crashes/is restarted or simply hangs, a job is never failed but stays "running" forever.
To Reproduce
Steps to reproduce the behavior:

Start a compose
Before the job has completed, restart the worker using systemctl restart osbuild-worker\@1

Expected behavior
The job is marked as failed, or possibly retried.
Additional context
I imagine we want some watchdog logic, where if the worker has not reported back within a certain timeframe we fail the job. This means needing to have a watchdog process/thread in composer, so far we did not have any long-running tasks like that in composer.
Automatically restarting a job, we could reasonably leave to upper layers, or at least get back to later.

Additional context: I think the end goal for composer is to run multiple stateless replicas of it in k8s. The watchdog logic must be able to run in such environment.

This could benefit from the job queue implemented above a DB, no? Because we could create the watchdog as a separate service (both in systemd  and openshift terms).
Also when combined with depsolv workers, there is very little work left for the composer. In the cloud API case, it would only provide access control and interface to the DB (unless I forgot something :-) ). In the Weldr API case it would keep the sources and blueprints. Otherwise, it would only serve as an interface to the DB.

I imagine we want some watchdog logic, where if the worker has not reported back within a certain timeframe we fail the job.

Do you mean a timeout for the whole build process or a periodic message from the worker to the composer?

I imagine we want some watchdog logic, where if the worker has not reported back within a certain timeframe we fail the job.

Do you mean a timeout for the whole build process or a periodic message from the worker to the composer?

The latter. The worker already calls back to check for cancellation, so composer just needs to remember that.

This could benefit from the job queue implemented above a DB, no? Because we could create the watchdog as a separate service (both in systemd  and openshift terms).
Also when combined with depsolv workers, there is very little work left for the composer. In the cloud API case, it would only provide access control and interface to the DB (unless I forgot something :-) ). In the Weldr API case it would keep the sources and blueprints. Otherwise, it would only serve as an interface to the DB.

Yeah, this would be the ideal state!

This was implemented in https://github.com/osbuild/osbuild-composer/pull/1523 using the cancel check as a heartbeat/refresh. I picked 2 minutes as a timeout. Not as a separate service however, the worker server just checks every 30 seconds, could change that in future?

I'll close this for now then, but feel free to reopen of course.


Add ref to <Input /> so that you can call focus(), 'blur(), 'clear() methods

Is your feature request related to a problem? Please describe.
At the moment there is no way to programmatically call the focus(), 'blur(), 'clear() methods on <Input />
Describe the solution you'd like
Expose the ref on <Input /> so that the above methods can be called

@therunbuddy
Currently ref is being passed as a second parameter.
See: https://github.com/GeekyAnts/NativeBase/blob/master/src/components/primitives/Input/Input.tsx
So you can pass your ref as a second parameter, as it is not currently deconstructed via props and it should work

Unable to reproduce this issue in NativeBase 3.2.2. If you are still facing this issue, please re-open it with proper snack.

is there any solution for this issue?