Memory leak in addTapAction

In file UIView + TapAction.swift
you are using objc_setAssociatedObject
when the keyboard is restarted - all buttons remain in memory. we have to force removeTapAction and objc_removeAssociatedObjects to remove an object from memory, every time the keyboard needs to be updated

Oh, that's not good! I'll look into it. If you have a nice solution for it, feel free to post a snippet here och create a pr :)

Hi again @fullhousetihon
I just wanted to check if this is a problem with the built-in logic, or do you also use the extension yourself? All occurrences that I find in the code base use [weak self] and shouldn't hold strong references to anything.

As I understand it, all objects that are added using runtime are not tracked by ARC.
You can check this on your demo by clicking on changing the font size several times (.shift). in the debug memorial count you can see many objects UIView

I can see if the keyboard api can have a new function that connects the button to the action handler, instead of adding a tap action like that.

Thanks, that's a great catch! I can see if the keyboard api can have a new function that connects the button to the action handler, instead of adding a tap action like that.

Hello @danielsaidi @fullhousetihon. I also experienced this memory leak
Is there any quick fix for this? I have forked the KeyboardKit repository but I need guidance on how to fix this as I need to release my app soon. I would apply the quick fix in my repository for now while waiting for v2.8.0

I have solved this in 2.8.0. I'll release it tomorrow.

2.8.0 is out now. Please give it a try and let me know if the leak is fixed.

Hi @danielsaidi, I tried using 2.8.0 and KeyboardKit demo for the test, yesterday.
However, it seems the memory leak still happened. CMIIW
In the beginning, the memory consumption is about 30 MB

But after changing the keyboard type several times, especially after scrolled through emojis in the collection view, the memory consumption keeps increasing significantly. In the end, it reached 103.2 MB.

It won't make the keyboard crash in the simulator, but when I tested it on my device, it crashed once the memory reached 53 MB.
I don't know if the fact that I forked this repo and change minimum deployment target to iOS 10.0 will make any differences

Hmmm...ok, but since I've removed all calls to these extensions, the leak must be happening elsewhere...or do you still see that addTapAction is the cause of this?

Before the 2.8.0 is out, I tried to confirm the issue by commented out super.setup() in DemoButton.swift. Also tried to commented out tapAction and longPressAction variable assignment in UIView+TapAction and UIView+LongPressAction, and it seems to fix the issue. So it's safe to say that the objc_setassociatedobject is the culprit.
However, in 2.8.0, I don't know which code that caused memory leak since the above codes no longer called. I will trace the codes again and commented out some codes who may be the suspects and let you know about my finding. @danielsaidi

That's amazing, thank you for taking the time to investigate this further. There can probably be more memory leaks in the code. I will look for non-weak self-based completion blocks and other potential leaks. However, I am rather busy so any help is welcome.

Do you think we should open a new issue for the remaining leaks?

I'm just wondering about button.gestureRecognizers?.forEach { button.removeGestureRecognizer($0) } in addKeyboardGestures(to:) function.
Yes, we remove gestureRecognizers from the buttons, but isn't it only applied to newly added buttons only, since addKeyboardGestures is called when super.setup() is called from DemoButton.swift(when we create button)
Shouldn't we remove gesture recognizers from previous keyboard type buttons too? before we remove allArrangedSubviews from keyboardStackView and setup new keyboard buttons, to be exact. Or it's done automatically when the buttons being removed from its supervises? I might be wrong tho. CMIIW

I think it's ok to open a new issue for the remaining memory leaks, since this one doesn't seem to related with objc_setassociatedobject @danielsaidi

@fullhousetihon Do you also still see the leaks in 2.8.0?

@dianseptianabl I don't think that the gesture recognizers are to blame - everything should be cleared up when the buttons are no longer on screen and there are no more references to the old buttons. But it may be another part of the keyboard that is still hacking around after removing the buttons. So I'm looking for places where I have forgotten using weak self in completion blocks.

@dianseptianabl and @fullhousetihon We can continue the discussion in #76  👍


'SwifterSwift/withoutDate' subspec

Some users prefer to use other libraries for Date extensions
How about a new subspec that lets them have all the great extensions without Date ones by adding the following line to Podfile
pod 'SwifterSwift/withoutDate'

I think adding something like this is a slippery slope. The withoutDate subspec is also vague and confusing. I think a better approach would be to recommend users to control what they import type by type. This results in the same solution without the need for subspecs. I'll add writing documentation on how to do this to my todo list.

Why don't just separate date extension and get them with SwifterSwift/Date ?

@Alex293 The problem is some users are using the entire library without DateExtensions, maybe they have a UI framework (like a calendar) that has Date extensions which conflicts with SwifterSwift, we are looking for a way to prevent this, possible solutions:

pod 'SwifterSwift/withoutDate'
I'm working with @SD10 on another solution in #201


Make the enabled FeatureFlags more visible to developers

Use case
First, a little background on a recent issue that I ran into. (for reference: #84347 )
Many flutter devs, and also me, use fvm for managing the flutter versions and to quickly switch between flutter versions without downloading them over and over again.
Flutter versions installed through fvm had an issue where they would not be on a valid channel.
Since the channel was unknown, the flutter tool set the enabled feature flags to the feature flags from master. (https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/features.dart#L367 )
This caused fvm users who installed a stable version to be running features that were not intended for stable versions.
Since fvm is a rather popular package on pub and nobody noticed this until recently, I think it's a reasonable claim that a lot of flutter developers are not aware of the behavior, that features get enabled based on the current channel, which is derived from the git history.
Also, when I opened an issue because of a bug that occurred to the feature flags that were enabled when they should not have been, I misunderstood the suggestion that the cause of this is that I am not on a valid channel -
I assumed that the person reviewing the issue thought that I am running some custom version of flutter with custom commits, and not that the fact that the channel is unknown caused a difference in behavior, even if you are on the same commit.
This is not only a potential issue for fvm users (fvm will fix this in a future release), but also for users who are running a custom version of flutter, for example, because they need to include a few commits who are not yet on an official release.
At least I did this in the past when I was waiting for PRs to get merged but still needed to get a new release out.
They might not be aware that by just switching to a new branch and adding a small commit, they might change the behavior of the flutter tool.
Proposal
I would like the flutter tool to display the enabled feature flags more prominently, for example when running flutter doctor --verbose.
Also, when running flutter on an unknown branch, maybe there should be a warning/info that lists all the enabled features or at least the ones that are not yet stable.
I think if there was an info message that I am running flutter with "isSingleWidgetReloadEnabled", I would have found the source of the issue with hot reload much much earlier.

For more context, FVM currently will get the proper channel using a similar behavior to the downgrade command. I believe however that this impacts any other workflows which Flutter does not run on an official branch outside of FVM

Also, when I opened an issue because of a bug that occurred to the feature flags that were enabled when they should not have been, I misunderstood the suggestion that the cause of this is that I am not on a valid channel -
I assumed that the person reviewing the issue thought that I am running some custom version of flutter with custom commits, and not that the fact that the channel is unknown caused a difference in behavior, even if you are on the same commit.

I had the exact same experience, thanks @jonahwilliams for providing that information.

@knaeckeKami Thank you for raising this, because I also ran into the exact same situation and I spend a whole day on that!


Roll gallery for device lab tests

From https://github.com/flutter/gallery/commit/03dedee4bc24878fec1c1d1338daffd5b792a29d to https://github.com/flutter/gallery/commit/221023a99dc7d4e1a6b1bd3d53e5d9551b785774
Related: https://github.com/flutter/tests/pull/132

test-exempt: rolling dependency, is a test


Add images and fix htmx how-to

Adds missing info and fixes to the htmx How-To.

One thing that would be cool is to have an image of the end result at the start of the how-to. It would make it more appealing.


Fix off page dag states

Wrapped updating DAG states and setting the checkboxes in a function. Added an event handler to the DataTable so on init, on a page event and on a search event, this function is called.

Closing this one. I'll create a new one with squashed commits.


Update eslint to 3.8.1, noms was broken at 3.8.1

Also remove roll.py (not used anymore, we use file path) and make it
pinned to a specific version (so that this doesn't happen again.

I meant that there should be no space after {.
Let me see if I can find a rule for that.


Leanback

Hi and thanks for this super library!
Do you have any plans to make the lib compatible with Leanback?

Hi, what is Leanback?

Leanback is a Google lib for developing apps for tv
https://developer.android.com/jetpack/androidx/releases/leanback
There is a similar project using using the api iframe player for Android tv here https://github.com/bertrandmartel/youtubetv
But is almost abandoned and use deprecated version (not androidx) of the leanback library

Ok, i don't know much about it, but are you sure it's not possible to use YouTubePlayerView with Leanback? it seems to be using standard android apis.

The player works great, the problem with Android tvs is that we have to handle the UI actions using a Dpad/remote control, onFocus etc...
It's not possible to grab the onclick actions because none of the controls elements can be focused. The only action that works is the onBackpress to dismiss the activity containing the player.
Anyway for mobiles the lib is awesome 👍

Ah i see what you mean. I am not sure there is a solution to this problem. As youtube does not allow overlaying views to the player and it's not possible to intercept clicks to the player web controls.


Write config file for tables having ' - ' and capital letters in their name.

Hi, I am trying to write a config file contains tables having hyphen character ' - ' and capital letters in their name. But its failed with the following error:
tegola-server | Error: could not register providers: could not generate sql, for layer(Registered_Parks_and_Gardens): ERROR: relation "registered_parks_and_gardens" does not exist (SQLSTATE 42P01).
Or:
tegola-server  | Error: could not register providers: could not generate sql, for layer(civil-parish): ERROR: syntax error at or near "-" (SQLSTATE 42601).
I search through internet but unable to find any solution. Any thoughts on this?

Please provide an obfuscated SQL statement.
My guess is that you'll have to put the table name in '.

Thankyou @iwpnd , you were right, it was only the matter of putting table names inside ''.


WIP Enable Aviso notification as trigger ECFLOW-1931

Codecov Report
Attention: 15 lines in your changes are missing coverage. Please review.

Comparison is base (b4f9b99) 83.54% compared to head (02c301f) 83.54%.

Files
Patch %
Lines

ANode/src/ecflow/node/NodeDelete.cpp
81.03%
11 Missing :warning:

ANode/src/ecflow/node/NodeChange.cpp
88.88%
4 Missing :warning:

Additional details and impacted files
@@           Coverage Diff            @@
##           develop      #72   +/-   ##
========================================
  Coverage    83.54%   83.54%
========================================
  Files          591      591
  Lines        52488    52473   -15
========================================
- Hits         43851    43839   -12
+ Misses        8637     8634    -3

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


Fix custom 404 page

This PR fixes an issue with serve v5.2.2 where a custom 404 page (ie. 404.html) wasn't being sent.
From my triaging, it seems like the issue is with this line, which checks if flags.single === undefined. Since the default value is actually false this block never gets triggered and we never end up sending the custom 404 page.
This change doesn't seem to introduce regressions even with different options, but it's hard to actually tell without automated tests 😢

@leo Is there anything I can do to help get this merged in? This seems like it'll fix my custom 404 page issues and also my service worker on my website

The problem is that we need to ensure that this doesn't happen again. I've recently merged this and it brought the problem back after it was fixed. Since your PR looked similar, I thought it might create the same problem again.

@leo What exactly is that issue? I can't find any details about it other than that:

The issue was associated with the usage of the send middleware without supplying a root option.

If you let me know more (eg. what kind of request can cause the issue, how it's related to the 404 page), I'm happy to manually test this PR to ensure that there's no regression.
Also, would you be open to a PR introducing automated testing? Seems like a good way to ensure that kind of regression never happens again.

From what I see there's exactly the same code few lines below - https://github.com/zeit/serve/blob/master/lib/server.js#L138 - so one way or another there's a bug!
I've been trying to figure out what the security issue is and how that change could reintroduce it. From what I see in next.js changes in 2.4.1 version there is only one change related to security and I'm afraid I'm not that knowledgeable in internals of both next.js and this library to guess how those two are connected :(
@leo it would be massively helpful if you provided more info on what the security issue in this case was and if there's some way of mitigating it. I'm happy to dive into it and provide necessary patch but I need more info, POC, description, anything :)

Sweet! I checked it manually and everything seems to work correctly. Thanks! 😊


Remove xvfb for saucelabs. Use wct instead of polymer-cli

Applying the change in skeleton.

This change is

@web-padawan I forgot to say that you can apply this change directly to master, w/o creating PR. Sorry about that!

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


@write does not work unless HDF5 is importined in main

All the documentations gives examples of usine @write file A etc.
And says that it is no longer generally required to first import HDF5.
But using @write without fist using HDF5  will throw an error as the macro is not defined.
Should be an easy fix to add @write to the things being imported. (Next to the function write)

As easy as <edit code>, git commit, and Pkg.submit("JLD") I'd say :wink:. Can you do that?

Yeah, no worries.
Though you missed the forking, pull request, and writing tests.
(Or moving the using HDF5 down the test script so stuff that doesn't depend on it explicitly can be test without it.


Cannot deploy on an alternative server

I am trying to deploy on a VPS, it needs to be that particular VPS because of server location so I cannot use Cosmic JS or heroku.
I am not able to set up a post-receive hook yet (all advices from here failed) so I am looking for an alternative way.
I have been trying to start the application directly from the DocumentRoot as well but npm start keeps crashing although I've got the dependencies all right
[xxxxx public_html]$ npm start

> @ start /var/www/xxxxxxxxx/public_html
> nuxt start

sh: nuxt: command not found

npm ERR! Linux 2.6.32-042stab123.1
npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "start"
npm ERR! node v6.10.1
npm ERR! npm  v3.10.10
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! @ start: `nuxt start`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the @ start script 'nuxt start'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     nuxt start
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls

�
{
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /var/www/xxxxxxx.net/public_html/npm-debug.log

I also understand I cannot use nuxt generate to get a static deployment into /dist/ because I would have to manually declare the permalinks for dynamically generated sites https://nuxtjs.org/api/configuration-generate/
Is there a documented step by step way to deploy nuxt app to a server manually?

Have you run npm install or yarn?
It seems that you haven't nuxt installed on the machine.

Yes ofc, npm install first.

@altcointrading in which directory you execute command?

@kodekrendel In the directory that has a clone of the whole project. I started a clean project on a clean server and got this part working.
npm install
npm build
npm start

which works with an nginx config like this
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_set_header   X-Forwarded-For $remote_addr;
        proxy_set_header   Host $http_host;
        proxy_pass         http://<IP_ADDRESS>:3000;
    }
}

However, I don't know how to run it in the background. I tried to create a script that only contains npm run build && npm start so that I can use PM2 pm2 start run.js which shows it as success ("app online") but the homepage is not there (502 bad gateway).
Do you know how to do it with PM2?

@altcointrading what is run.js?

@altcointrading I just tried pm2 start npm --name "nuxt" -- start and it works.

Also I am able to start with just pm2 start nuxt.

can you please share your package.json

Check your node version. Nuxt needs node >=6.11
If you do npm install with older release of node, we dont get any error and one will be in assumption everything went well.


fix(FrameworkConfigurationForm): improve schema errors

This is the lowest hanging fruit on improving schema validation errors for Frameworks. This commit merely improves styling, and not the content of the error.
We have talked with cosmos and data services about this general issue, and in the future someone will work on a solution to improve the contents of this error message. Currently this disappointingly obscure message is delivered by the mozilla json-schema library. Data services would like to use these json-schema clauses like oneOf, allOf - but the challenge is mapping this onto a good UX for the UI and CLI. The improved messages in the future might come directly from a "validate" endpoint in cosmos. This would be ideal because then CLI can also get good errors.
Closes DCOS-19740
It looks like this now:

Testing:

Deploy kafka from catalog
Toggle "enabled" for SSL Authentication
See the error message appear
Toggling "enabled" for transport encryption (further down the form) will remove the error.

^The reason for the error is the allOf json schema clause.
Checklist

[x] Did you add a JIRA issue in a commit message or as part of the branch name?
[ ] Did you add new unit tests?
[ ] Did you add new integration tests?
[ ] If this is a regression, did you write a test to catch this in the future?

Hey @ahoskins I think this is a huge approvement, great job 👍
I think this error looks a bit strange with the [object Object] fragment, a bit like JSON.stringify was missing

@DanielMSchmidt sadly this kind of error is just from the mozilla library we use to render json-schema forms. In the future, we will work on a solution improve this. Thanks for the reviews, guys. 👍


gpt-4 not working

Looks like you still not have access to it and have to wait longer.
See if can get gpt-4 working at:
https://platform.openai.com/playground?mode=chat&model=gpt-4

Marking the as invalid and closing this as there is no follow up


place caret at right position for search/usage/declaration

Hi,
I think it would be greate when we selected a result from search/usage dialog or using the "go to declaration" feature,
the caret could set on the matched position instead of the start of a line.
so I opened this issue for a PR.

Fixed in PR #1094

Fixed in PR #1094


Move to Spring Boot 3, making the required java version 17 instead of 11.

Quite a lot has changed;

Moved to Spring Boot 3 from Spring Boot 2
Replaced Kotlin data classes by Java records
Use Jackson for all seriliasation
Moved to Webflux + vinalla js + bulma CSS instead of Vaadin
Added Open Api

Looks of the new ui.


App Insights APM 2.1 Enablement and Representation

To add support for App Insights APM 2.1, add the option for adding a existing/new workspace when creating a new function app.

What is APM 2.1? And how is that related to "adding a existing/new workspace"? In any case, we already let users select an existing/new workspace for new projects

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


'endpoints' tests do not appear to have any basis in the ga4gh/schemas spec

These tests look to be written based on specific implementation details of the reference server, I would not expect them to pass on any other implementation. For example, a GET request to /callsets/search is interpreted by the Google API as a request for a callset with id 'search'.
To me, these looks more like server integration tests which I would expect to live in the reference server repository, if anywhere.

I agree with @calbach on this example. What are the tests checking for?

At @jeromekelleher's suggestion, I pared down the tests to a single one that checks the response to malformed POST payloads sent to search methods.
The one other useful test had been checking the response to OPTIONS, GET, and POST methods.  Arguably the schemas should specify the correct response to OPTIONS, at least, and test for it.

Closed pending merge.


[question] Should urlset protocols use https instead of http ?

This got implemented by https://github.com/ekalinin/sitemap.js/issues/164 , is there a reason is back to http again ?
      xmlns: {
        news: false,
        xhtml: false,
        image: false,
        video: false,
        custom: ['xmlns:news="https://www.google.com/schemas/sitemap-news/0.9"', 'xmlns:xhtml="https://www.w3.org/1999/xhtml"', 'xmlns:image="https://www.google.com/schemas/sitemap-image/1.1"', 'xmlns:video="https://www.google.com/schemas/sitemap-video/1.1"']
      }

helps modify specific protocols but not xmlns that remains http

namespaces are identifiers, you should not change them to https. When google or other parsers are looking at it they expect http not https. They look like urls they are not urls.

I just run into the problem that Chrome doesn't render our Sitemap correctly anymore. Doing some research I ended up finding the error: If we use xmlns:xhtml="http://www.w3.org/1999/xhtml" the page rendering is broken.

When changing this particular link to https Chrome renders the XML correct:

I'm not sure if this is a bug in Chrome.

Looking at the documentation, they are using http everywhere: https://developers.google.com/search/docs/advanced/crawling/localized-versions#sitemap
Also any sitemap validator I tried online tells me that the sitemap is correct with http:
https://www.xml-sitemaps.com/validate-xml-sitemap.html?op=validate-xml-sitemap&go=1&sitemapurl=https%3A%2F%2Fsatellytescommain-featmultilingualsitemap.gtsb.io%2Fsitemap%2Fsitemap-0.xml&submit=Validate+Sitemap

On the other hand, Firefox behaves the same. Which is an indicator for me that https is correct.

We decided to stick with http as we want to align with the documentation instead of having a nice browser rendering.


TRPC with Tanstack Query

Describe the feature you'd like to request
feature that allows for seamless integration between React Query and trpc in App dir.
Describe the solution you'd like to see
Currently, using React Query with trpc requires some manual setup and configuration. Including this in template would be more convenient for using trpc.  Would love to see how it will be integrated. Tried couple of ways and could succeed if a trpc.provider is used.
Additional information
No response

Yes!
Just need to get the proper support landed in tanstack. We're working with rhem to get nice DX while keeping the benefits from RSC and the dynamic-y of client side https://github.com/TanStack/query/pull/5598

Also really looking forward to this, keep up the good work!

Looking forward to this update. Thanks!

Looking forward to this update. Thanks!


Issue installing Bonfire: CI

$ php spark bf:install
Fatal error: Uncaught Error: Failed opening required 'C:\sites\ci4\app\Config/../../vendor/codeigniter4/codeigniter4/system\bootstr
ap.php' (include_path='C:\xampp\php\PEAR') in C:\sites\ci4\spark:75
Stack trace:
#0 {main}
thrown in C:\sites\ci4\spark on line 75
Get a few of those kind of messages, some warnings, and then the above fatal error. I checked my vendor folder. My CI4 is not in vendor/codeigniter4/codeigniter4/system but in vendor/codeigniter4/framework/system ... I installed CI4 with composer, so not sure where it goes wrong. I have installed several other packages without issues with this CI4 instance, so I am suspecting an issue with this package, but I am not sure.
Any ideas?

Hi Kenji,
Thanks for the feedback. My path in my Paths config says
public string $systemDirectory = __DIR__ . '/../../vendor/codeigniter4/framework/system';
But it looks like Bonfire2 is expecting it to be in public string $systemDirectory = __DIR__ . '/../../vendor/codeigniter4/codeigniter4/system';

Your error message:
Fatal error: Uncaught Error: Failed opening required 'C:\sites\ci4\app\Config/../../vendor/codeigniter4/codeigniter4/system\bootstrap.php' (include_path='C:\xampp\php\PEAR') in C:\sites\ci4\spark:75
spark L75:
require rtrim($paths->systemDirectory, '\\/ ') . DIRECTORY_SEPARATOR . 'bootstrap.php';

In my understanding, spark L75 loads system/bootstrap.php. If your Config\Paths has:
    public $systemDirectory = __DIR__ . '/../../vendor/codeigniter4/framework/system';

It should load C:\sites\ci4\app\Config/../../vendor/codeigniter4/framework/system\bootstrap.php.
I don't know why it tries to load 'C:\sites\ci4\app\Config/../../vendor/codeigniter4/codeigniter4/system\bootstrap.php'.

Thank you - it might then mean my original CI4 installation failed? I can't understand - but everything else works, I just can't get Bonfire installed, so I will skip bonfire until I know more.

I do not know. At least I can't imagine the cause of your error at all. Something strange is happening that is beyond my imagination.


Fix scripts for js linting and linting warnings

I've opened node_package/src files in my Atom and it started to show me eslint warnings.
That's why I've checked npm run lint scripts and this PR is the result of it.

This change is

Coverage remained the same at 82.36% when pulling 65361055ae6d7cde539cb8bc6aeeb5b18b670bb2 on AlexKVal:js-linting into ea9575985ce9518b63eb3b72dcfb55189b037273 on shakacode:master.

Good progress. Let's lock the version of the linter to use the latest, and use this config:
https://github.com/shakacode/react-webpack-rails-tutorial/blob/master/client/package.json#L99

Reviewed 16 of 16 files at r1.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

.eslintignore, line 8 [r1] (raw file):

node_package/tests/node_modules
node_package/webpack.config.js
gen-examples

we want these to pass linting

package.json, line 51 [r1] (raw file):

    "build": "node_package/scripts/build",
    "build-watch": "babel --watch --out-dir node_package/lib node_package/src",
    "eslint": "eslint .",

this is not right, as this will use the eslint that is globally installed

node_package/src/clientStartup.js, line 1 [r1] (raw file):

/* global ReactOnRails Turbolinks */

import ReactOnRails

node_package/src/ReactOnRails.js, line 1 [r1] (raw file):

/* global ReactOnRails */

Not sure about this comment

Comments from Reviewable

In process. Thanks for the hint!

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

.eslintignore, line 8 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> we want these to pass linting

`.gitignore`  ignores this folder thus I've thought it should be ignored as well.
I'll add it back and will make sure about linting.

package.json, line 51 [r1] (raw file):
I encountered this question a year ago in React-Bootstrap.
Let's check it.
change in package.json
  "eslint": "eslint -v",

run
> npm i eslint@2
> npm i -g esling@3
> eslint -v
v3.3.1 (global)
> npm run eslint
v2.13.1 (local)

As it turned out:
https://www.sitepoint.com/solve-global-npm-module-dependency-problem/

Npm scripts will look for a local copy of an executable command in the ./node_modules/.bin/ directory before checking your PATH for it

https://docs.npmjs.com/cli/run-script

In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. Any binaries provided by locally-installed dependencies can be used without the node_modules/.bin prefix.

To point out that I want to run a locally installed package I should write it with the node_modules/.bin/ prefix. And we already know that npm automatically adds this to any npm-script.
Hence eslint . - is the most popular way to run it throughout OSS libraries.

node_package/src/clientStartup.js, line 1 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> import ReactOnRails

I wasn't sure. Thank you for the help with it.

node_package/src/ReactOnRails.js, line 1 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> Not sure about this comment

Nice catch. It seems I was much more weak and unfocused than I though.
I'll fix it.

Comments from Reviewable

I have a question that arose after updating linter's versions because of additional rules.
--
The linter now "swears" about the dangled _ in _storeGenerators but I cannot just rename it to storeGenerators
because it it already defined as argument.
register(storeGenerators) {
    Object.keys(storeGenerators).forEach(name => {
      if (_storeGenerators.has(name)) {

here src/StoreRegistry.js#L12:L14
There are a handful of such occasions throughout the project.
I propose to rename all _localScopeName variables with the dangled _ to something like privLocalScopeName
What do you think ? I need help with the more appropriate naming scheme here.

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

Comments from Reviewable

@alexkval  you have a good point.  In most cases, we could do this.storeGenerators or, in Ruby, @store_generators.
We either have to change the name of the param or the closure variable.

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

.eslintignore, line 8 [r1] (raw file):
Previously, AlexKVal (Alexander Shemetovsky) wrote…
> `.gitignore`  ignores this folder thus I've thought it should be ignored as well.
> I'll add it back and will make sure about linting.

Please do so! Needs to be linted!

package.json, line 51 [r1] (raw file):
Previously, AlexKVal (Alexander Shemetovsky) wrote…
> I encountered this question a year ago in `React-Bootstrap`.
>
> Let's check it.
> change in `package.json`
> ```json
>   "eslint": "eslint -v",
> ```
> run
> ```sh
> > npm i eslint@2
> > npm i -g esling@3
> > eslint -v
> v3.3.1 (global)
> > npm run eslint
> v2.13.1 (local)
> ```
> As it turned out:
> https://www.sitepoint.com/solve-global-npm-module-dependency-problem/
> > Npm scripts will look for a local copy of an executable command in the ./node_modules/.bin/ directory before checking your PATH for it
>
> https://docs.npmjs.com/cli/run-script
> > In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. Any binaries provided by locally-installed dependencies can be used without the node_modules/.bin prefix.
>
> To point out that I want to run a locally installed package I should write it with the `node_modules/.bin/` prefix. And we already know that `npm` automatically adds this to any npm-script.
> Hence `eslint .` - is the most popular way to run it throughout OSS libraries.

Very nice! Thanks @alexkval!

Comments from Reviewable

I hesitate to enforce any sort of naming scheme like that, as it can't be enforced by linting and is often not necessary. I vote we just rename _storeGenerators to registeredStoreCreators.

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

package.json, line 51 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> Very nice! Thanks @alexkval!

I think the confusion may be coming from when you have your npm scripts run `.sh` files, then in those files I'm pretty sure you need to use `$(npm bin)/` to get the local version?

Comments from Reviewable

Review status: 4 of 19 files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

node_package/src/clientStartup.js, line 52 [r1] (raw file):

  return (typeof Turbolinks.controller !== 'undefined');
}

why the re-ordering?

Comments from Reviewable

:lgm:

Reviewed 16 of 16 files at r2.
Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

node_package/src/StoreRegistry.js, line 4 [r2] (raw file):

// value = redux store creator, which is a function that takes props and returns a store
const registeredStoreGenerators = new Map();
const hydratedStores = new Map();

nice changes!

node_package/tests/ComponentRegistry.test.js, line 8 [r2] (raw file):

import test from 'tape';
import React from 'react';
import ComponentRegistry from '../src/ComponentRegistry';

FWIW (for what it's worth), I like to leave a blank line between library and local imports.

Comments from Reviewable

Coverage remained the same at 82.36% when pulling 5d233f59115264a7d933a214c32a41596715de98 on AlexKVal:js-linting into c81fbc2949a9bb48ae705138dc79809e0c6194e4 on shakacode:master.

I've rebased it to the latest master.
All previously pointed out issues has been resolved.
I put it as another one commit to facilitate review process.

--
Thanks @robwise for the help with naming things 🍒
--
A new issue needs to be created. I'm just silencing it here because this PR is about linting.

ReactDOM.render() currently returns a reference to the root ReactComponent instance. However, using this return value is legacy and should be avoided because future versions of React may render components asynchronously in some cases. If you need a reference to the root ReactComponent instance, the preferred solution is to attach a callback ref to the root element.

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-render-return-value.md
// eslint-disable-next-line react/no-render-return-value
return ReactDOM.render(reactElement, document.getElementById(domNodeId));

src/ReactOnRails.js
The code needs to be refactored to be future-proof for next React versions.
--
Another issue needs to be created as well. It's about circular dependencies.
I cannot do this
- /* global ReactOnRails Turbolinks */
+ import ReactOnRails from './ReactOnRails';

in src/clientStartup.js
It starts to throw an error because of circular dependencies:
ReactOnRails imports clientStartup which in turn imports ReactOnRails

--
Pff.. it takes a lot of time to re-run again and again all those tests and linting even locally and even only parts of them. It seems I just have to get used to it.

Review status: 6 of 19 files reviewed at latest revision, 5 unresolved discussions.

node_package/src/clientStartup.js, line 52 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> why the re-ordering?

http://eslint.org/docs/rules/no-use-before-define

node_package/src/StoreRegistry.js, line 4 [r2] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> nice changes!

Thank you :)

node_package/tests/ComponentRegistry.test.js, line 8 [r2] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> FWIW (for what it's worth), I like to leave a blank line between library and local imports.

I reformatted node_package/* files accordingly.

.eslintignore, line 8 [r1] (raw file):
Previously, justin808 (Justin Gordon) wrote…
> Please do so! Needs to be linted!

Done

Comments from Reviewable

Coverage remained the same at 82.36% when pulling a39c99c534439e6b1a9f1e80a9a09009b7f048f9 on AlexKVal:js-linting into c81fbc2949a9bb48ae705138dc79809e0c6194e4 on shakacode:master.

Reviewed 13 of 13 files at r3.
Review status: all files reviewed at latest revision, 5 unresolved discussions.

Comments from Reviewable


♻ refactor:  GitHub例外をNetwork例外に変更してドメイン層で定義するように変更

Issue #145

Codecov Report

Merging #153 (95ddc61) into develop (a502d6e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop     #153   +/-   ##
========================================
  Coverage    99.81%   99.81%
========================================
  Files           51       51
  Lines         1083     1083
========================================
  Hits          1081     1081
  Misses           2        2

Flag
Coverage Δ

unittests
99.81% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

lib/utils/extensions.dart
100.00% <ø> (ø)

lib/domain/exceptions.dart
100.00% <100.00%> (ø)

lib/infrastructure/github/http_client.dart
100.00% <100.00%> (ø)

lib/infrastructure/github/repo_repository.dart
100.00% <100.00%> (ø)

lib/presentation/common/components/error_view.dart
100.00% <100.00%> (ø)

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 a502d6e...95ddc61. Read the comment docs.


purchase.cart-line-item.line-components.render extension point is not showing up in the customiser

Package(s) involved in the issue
@shopify/ui-extensions: 2023.10.x
@shopify/ui-extensions-react: 2023.10.x
Describe the bug
I am trying to enable a purchase.cart-line-item.line-components.render extension in the customiser after deployment of the extensions. But it keeps saying that the app block is not available. In development mode the extension is working fine. I tested this with a really clean UI extension point.
Other extension points like 'purchase.checkout.cart-line-item' are working fine.
Steps to reproduce the behavior:

Create a new checkout UI extension
Change the extension point in the toml and javascript file of the extension
Run npm run dev to check if the extension is showing in a development checkout.
Run npm run deploy to release a new version of the app
After install it is not possible to enable the extension in the customiser.

Expected behavior
When you can enable a 'purchase.checkout.cart-line-item' it should also be possible to enable 'purchase.cart-line-item.line-components.render'  in the customiser.
Screenshots

Hi @kumar303 @denislins,
Any update on this? :)

here's the related epic https://github.com/Shopify/checkout-web/issues/27685 @alxclark @denislins since the extension target is now private, is the recommendation to not build for it?

Hi @bask-code,
While exploring how we could best expose purchase.cart-line-item.line-components.render extension targets on the checkout editor, we raised a few points internally that made us reconsider how we want this target to work, and thus what the ideal editor/merchant experience would be.
In the meantime, we've made the decision to temporarily remove this extension target from our extensibility platform - we don't want partners to build extensions using an extension target we know might change, as it wouldn't benefit anyone. We understand you and a few other partners may have already built extensions using it, however - we apologize for the bumpy road here.
I will close this issue for now, but keep an eye out for updates on our docs/developer changelog - I don't have a specific timeline to share with you at this point, but I can promise you we still want to expose this target, and when we do so it will work even better than it did before.

Hi @denislins
Thanks for the explanation. At least I have something to explain to the client now :)

Thanks @denislins , to avoid confusion among the community, it would be great if the documentation is updated based on what you mentioned above.

Thanks @denislins , to avoid confusion among the community, it would be great if the documentation is updated based on what you mentioned above.


IngressClass declared instead of 'kubernetes.io/ingress.class' annotation doesn't configure Ingress status

Bug description
I am trying to deploy 'Ingress' object with 'ingressClassName: istio' flag enabled instead of kubernetes.io/ingress.class: istio annotation as per this example in Istio traffic management documentation.
I am simply trying to reproduce this on my Minikube Cluster, but 'Ingress' object without annotation just won't work as expected. While it works with annotation - it doesn't work with 'ingressClassName: istio' flag.
Strangely enough if I happen to deploy Minikube's Ingress addon - it actually starts working -  but it doesn't go via Istion Ingress Gateway anymore - I am not sure if this is expected.
[ ] Configuration Infrastructure
[X ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[X ] User Experience
[X ] Developer Infrastructure
Expected behavior
Running things on Minikube, Kubernetes version is 1.18.3 I was under impression that switching from kubernetes.io/ingress.class: istio annotation in favour of ingressClassName: istio flag won't result in any changes in terms of 'Ingress' objects not working without additional Ingress Controllers deployed. But it seems like it just won't pick-up Istio ingress controller at all... not sure if this is expected maybe I am missing the point.
Steps to reproduce the bug

Create Istio IngressClass object

apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
  name: istio
spec:
  controller: istio.io/ingress-controller

Create Ingress object

apiVersion: networking.k8s.io/v1beta1
kind: Ingress

metadata:
  name: 'ingress-hnb'
  namespace: 'istio-ingress-lab'

spec:
  ingressClassName: istio

  rules:
    - host: 'fancy.example.com'
      http:
        paths:
          - path: '/*'
            backend:
              serviceName: 'fancy-service'
              servicePort: 9999

Apply Ingress object configuration and describe it - one should see following (if minikube Ingress addon(aka kubernetes ingress controller)) has been deployed):

kubectl describe --namespace=istio-ingress-lab ingresses.networking.k8s.io ingress-hnb
Annotations:               Events:
  Type                     Reason  Age    From                      Message
  ----                     ------  ----   ----                      -------
  Normal                   CREATE  3m43s  nginx-ingress-controller  Ingress istio-ingress-lab/ingress-hnb
  Normal                   UPDATE  3m12s  nginx-ingress-controller  Ingress istio-ingress-lab/ingress-hnb

As you can see FROM is set to 'nginx-ingress-controller' I am not sure if this is correct...
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
bin/istioctl version --remote
client version: 1.6.4
control plane version: 1.6.4
data plane version: 1.6.4 (1 proxies)

kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:52:00Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:43:34Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
bin/istioctl manifest apply --set profile=default --set addonComponents.prometheus.enabled=false
Environment where bug was observed (cloud vendor, OS, etc)
minikube version
minikube version: v1.11.0
commit: 57e2f55f47effe9ce396cea42a1e0eb4f611ebbd

@vugardzhamalov we have a test for this exact case: https://github.com/istio/istio/blob/ea4f294029d67433ebf0dc9ad49ee40eb42e2aa4/tests/integration/pilot/ingress_test.go#L112.
What I think is happening here is nginx-ingress is not respecting the ingressClass field, and taking over control of the Ingress object when it should not. Based onthis, I think this is a bug in nginx (or old version?) not Istio. Does that line up with your observations?

Thank you @howardjohn !
OK, I thought I should deploy new Minikube profile and remove Kubernetes ingress-nginx controller (Minikube addon) out of equation. My actions/observations are:

Deployed new Minikube profile (same version of Minikube and same version of Kubernetes as above) without Ingress addon enabled!

Deployed Istio 1.6.7 with istioctl exactly as per my earlier post.

Deployed 'Ingress' object with single annotation: 'kubernetes.io/ingress.class: istio' - it seems as if things working as expected.

Removed earlier deployed 'Ingress' object. Deployed a new one without annotations at all - but with 'ingressClassName: istio' flag declared instead... It seems like Ingress works - I can definitely reach out to my endpoints behind the Ingress!  But I wouldn't say that it is working as expected, or maybe I just don't understand the difference.... So my current observations are:

IMHO the most important difference observed when I issue:
kubectl describe ingresses.networking.k8s.io --namespace=<your-ingress-namespace> <your-ingress>

When you are doing this against Ingress object deployed with annotations normally you'll be given 'Address' that will correspond to Istio Ingress Gateway IP address. On top of that the host name(s) declared in your Ingress rule(s) will be created for you if you've set your 'external-dns' accordingly and this will end up reflected in 'external-dns' logs!

Now if you are issuing 'kubectl describe' against Ingress object deployed with 'ingressClassName: istio' flag instead of annotations - things starting to look somewhat different. First of all I don't see 'Address' filed populated at all... it just stays empty! The next thing is even more mysterious ... 'external-dns' while does! create required DNS resource records as per host name(s) in your Ingress rule(s) it does so quietly... like there is nothing in 'external-dns' logs at all!

So I guess I could say it works for me! But I see no address assigned to it and for some reason (maybe related to missing IP address) 'external-dns' logging doesn't give any details on resource records being created (once again - these are quietly created). But maybe this is expected change in behaviour - I don't know. Also please keep in mind that I wasn't making any changes to verbosity in logging for my 'external-dns' instance.

Please let me know if you want me to make further changes/observations - happy to assist as much as I can. But again how many people will be even looking into this functionality with Ingress objects? Even documentation clearly states that we are better off with Istio Gateway and VirtualService objects instead. So if you think that this is good enough for now - I'll be happy to close the ticket.

@vugardzhamalov I see, thanks for the info! Looks like we are respecting the new ingressClassName field for the core Ingress code, which does the real logic of configuring routing, but the status code which is separate is not updated (https://github.com/istio/istio/blob/623cbcd5d7be9e0aa1e8aae8c66b74105dd9d848/pilot/pkg/config/kube/ingress/status.go#L291). So we will need to update this.

@howardjohn @ramaraochavali Hi this is a P0 for 1.8, please help to triage this issue thanks!

Dropping to P1

I wrote a failing test that covers this: https://github.com/istio/istio/compare/master...howardjohn:test/ingress-status-integ?expand=1

Fixed in #28225


Gready rendering mode

The standard behaviour of dockview is to "de-render" any hidden panels (those panels that are not active). This is and will remain the default behaviour however there are some circumstances where it would be more benifical to leave all panels rendered but hidden (display: none) to preserve certain DOM specific state such as scroll position.

Come across this library recently and really digging it. Kudos!
I got a use case for greedy rendering of all tabs within a group where the tabs' content is semi-transparent (i.e., tabs are used as "overlays" for content in the left-most tab.
If I wanted to enable this today (even if hacky) where would be the best place to get started?

Currently it would be enabled at a component level, not a indivual panel level through
<DockviewReact ... renderMode='gready'/>

although the plan would be to make this a panel level parameter.
Little confused on your use case, any chance you could explain in some more detail so I can get a better idea of what you are trying to achieve? For example currently when hidden in gready mode with display: none it wouldn't be possible for the user to interactive with panel but it seems potentially you want multiple panels visible at once within one container?

For my use case, it would be ok if the setting is on the component level.
Use case:
I have a bunch of computer vision ML models that infer segmentation masks or bounding boxes for objects in an image. To compare the different checkpoints, I would like to have a flexible layout that would allow me to arrange model outputs side-by-side or layered on top of each other in z-index. The latter is to compare model results pixel-wise.
The dockview component already provides most of the UI and interaction that I want. For example, I can arrange outputs rendered in panels side-by-side where each panel contains the input image and segmentation masks or bounding boxes on top of an image (as SVG elements).
Now, for the z-index layering, it should render the input image in one tab, and then tabs on top in the same tab group should just render the segmentation masks or bounding boxes. Maybe one way to think about this is the layers view in Photoshop (see screenshot).

So, for this to work, it needs to render contents of all tabs, with each tab having a transparent background, so it shows the contents of the tabs "underneath"

So, for this to work, it needs to render contents of all tabs, with each tab having a transparent background, so it shows the contents of the tabs "underneath"

I really think that goes about outside of scope of dockview. I personally don't want to see dockview be a full blown UI dnd framework, but keep at just being a tab-docking-framework. What you describe can easily be implemented with something like https://github.com/atlassian/react-beautiful-dnd and you can still combine that with dockview

Hello @mathuo any updates on the release of the greedy mode? We love using the library and our use case requires a greedy mode :(

The work for this PR is essentially done. I am planning to add additional unit tests before an offical release however I will aim to get out an experimental build in the next day or so for those interested in early usage.

I've published the current state of this branch as an experimental build which can be installed through the following command.
npm install<EMAIL_ADDRESS>
Variable names are subject to change however the core behaviours of what you see here are what is intended to be merged into master and released into an offical build soon.

You can specify a renderer for a specific panel through the renderer prop. When set at the panel level this information is persisted as a part of the serialized layout toJSON() which can be re-created through fromJSON(...).
api.addPanel({
     id: 'my_panel_id',
     component: 'my_component',
     renderer: 'gready' // or 'destructive'
});

If no renderer is provided the default will be used which can be specified at the component level described below. The default is destructive which is the current behaviour in existing versions of dockview.

If you want to change the default behaviour you can specify a defaultRenderer at the component level. This information is not persisted as a part of any serialized layout.
<DockviewReact {...otherProps} defaultRenderer={'gready'}/>

Refer to https://github.com/mathuo/dockview/issues/365 for beta builds and documentation of this feature.

This has been release with version 1.9.0. Docs here
I've opened another Issue for the "ovlerayed contents" idea here


Cannot declare class Opnsense\Routing\Gateways upgrading from 24.1.10 -> 24.7

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[ x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[ x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Unable to boot my opnsense after an upgrade due to the error in the title.
Name already in use /use/local/opnsense/MVC/app/library/opnsense/routing/gateways.php line 38
Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)
Unable to revert as no internet on that machine. Cannot find docs to revert manually or offline,
Steps to reproduce the behavior:
Upgrade
Expected behavior
Bootup so I am able to debug any other errors from a major upgrade,
Describe alternatives you considered
opnsense-revert but do not know how to revert when downloading files from another machine
OPNsense 24.7 (amd64).

Just move this file to /root and it should start working. It seems to be a leftover of when the package manager database crashed so it never managed to clear stale files?


reduce font size

[x] This is a question about using the theme.
[ ] This is a feature request.
[ ] I have updated all gems with bundle update.
[ ] I have tested locally with bundle exec jekyll build.
[ ] I believe this to be a bug with the theme --- not Jekyll, GitHub Pages or one of the bundled plugins.

Environment informations
i have searched for previous solution on reducing font size. Tried both methods but still the font did not change. For reference, my site is here:
https://github.com/germayneng/germayneng.github.io
I tried the reset.scss method
 @include border-box-sizing;

html {
  /* apply a natural box layout model to all elements */
  box-sizing: border-box;
  background-color: $background-color;
  font-size: 8px;

  @include breakpoint($medium) {
    font-size: 10px;
  }

  -webkit-text-size-adjust: 80%;
  -ms-text-size-adjust: 80%;
}

hope you can provide me a solution since the font is too huge. Ideally, i want to reduce the font size of posts. an example:
https://germayneng.github.io/Elastic_Net_Regularization.html

Editing the font-sizes in reset.scss is the right way. The reason it's not working for you is due to misconfiguration and the location of the CSS files.
Reference the documentation about structure and MM repo. Not sure why you moved _sass inside of assets/ but that needs to live at the root. Also assets/css/main.css shouldn't existed in your repo. That's the compiled stylesheet which is what the theme is using. That's why your changes aren't appearing.
Get rid of that and replace with assets/css/main.scss. If you make those two changes correctly main.scss will load all of the Sass partials in _sass... which you can customize and Jekyll will build a new _site/assets/css/main.css.

hello,
i have made the changes you mentioned. Now i have this error

Your site is having problems building: Your SCSS file assets/css/main.scss has an error on line 3: File to import not found or unreadable: minimal-mistakes. Load path: /hoosegow/.bundle/ruby/2.4.0/gems/jekyll-theme-primer-0.5.0/_sass. For more information, see https://help.github.com/articles/page-build-failed-invalid-sass-or-scss/.

Still looks like you don't have the _sass folder setup correctly. I would suggest starting over and fork the theme so you have all the correct files.
Then make your edits, set the config, add content, etc.


slic3r-prusa3d: 1.39.2 -> 1.40.0-alpha1

Motivation for this change
We need to fix the library installation path, as PERL_VENDORLIB and
PERL_VENDORARCH are set incorrectly. This can be seen when running cmake.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

As it is a alpha version we might want to wait for the stable version before merging. But I already created this PR for the PERL_VENDORLIB and PERL_VENDORARCH fix, so that this isn't lost.

@tweber notifying you :) Shouldn't that happen automatically?

We prefer to merge stable releases, so let's wait for it (it's 1.40.0-beta now). Marking this as WIP until then.

Package was updated in https://github.com/NixOS/nixpkgs/commit/dcb8828a8e9be79d56a38684afd9be8fb73697b5
Thanks @thorstenweber83!


cmd/compile: internal compiler error: panic: interface conversion: types.Object is nil, not *ir.Name

Go version
go version go1.22.3 linux/amd64
Output of go env in your module/workspace:
GO111MODULE='on'
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOROOT='/root/go'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/root/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/root/code/test/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1081386337=/tmp/go-build -gno-record-gcc-switches'

What did you do?
I have a project that uses ClickHouse, and it compiles successfully. However, when the pprof samples collected online service are placed in the main package of default.pgo, the compilation fails.
I apologize for not being able to provide the source code directly, but here are the pprof sample file default.pgo and the code main.go that can reproduce the compilation error.
ls

default.pgo  go.mod  go.sum  main.go

// main.go
// don't need to run
package main

import (
	"context"
	_ "net/http/pprof"

	"github.com/ClickHouse/clickhouse-go/v2"
)

func main() {
	cfg, err := clickhouse.ParseDSN("clickhouse://user:password@<IP_ADDRESS>:19000/default")
	if err != nil {
		panic(err)
	}
	conn, err := clickhouse.Open(cfg)
	if err != nil {
		panic(err)
	}
	defer conn.Close()
	b, err := conn.PrepareBatch(
		context.Background(),
		"INSERT INTO some_table (x) VALUES (?)",
	)
	if err != nil {
		panic(err)
	}
	b.Append(1)
	b.Send()
}

// go.mod
module test

go 1.22.3

require (
	github.com/ClickHouse/ch-go v0.61.5 // indirect
	github.com/ClickHouse/clickhouse-go/v2 v2.25.0
)

require (
	github.com/andybalholm/brotli v1.1.0 // indirect
	github.com/go-faster/city v1.0.1 // indirect
	github.com/go-faster/errors v0.7.1 // indirect
	github.com/google/uuid v1.6.0 // indirect
	github.com/klauspost/compress v1.17.7 // indirect
	github.com/kr/text v0.2.0 // indirect
	github.com/paulmach/orb v0.11.1 // indirect
	github.com/pierrec/lz4/v4 v4.1.21 // indirect
	github.com/pkg/errors v0.9.1 // indirect
	github.com/segmentio/asm v1.2.0 // indirect
	github.com/shopspring/decimal v1.4.0 // indirect
	go.opentelemetry.io/otel v1.26.0 // indirect
	go.opentelemetry.io/otel/trace v1.26.0 // indirect
	golang.org/x/sys v0.18.0 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
)

What did you see happen?
go build

# github.com/ClickHouse/clickhouse-go/v2/ext
/root/go/pkg/mod/github.com/!click!house/ch-go@v0.61.5/proto/col_nullable.go:20:6: internal compiler error: panic: interface conversion: types.Object is nil, not *ir.Name

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

When the PGO file is removed, i.e., when PGO is disabled, it compiles successfully.
The PGO file comes from my online service, please rename the file profile.pb.gz to default.pgo.
profile.pb.gz
What did you expect to see?
Build pass when enable PGO

Interestingly, this is fixed at tip after https://go-review.googlesource.com/c/go/+/578815
How was your default.pgo generated?

@cuonglm It was collected from my online service by using curl -o pprof.profile http://localhost:7999/debug/pprof/profile, and the file has been processed. For example, using '--focus clickhouse' on the original sample file outputs only the samples related to ClickHouse. Of course, the original sample file can also trigger this issue.
I tried writing a separate demo program to perform batch insert operations into ClickHouse and found that this issue does not occur. This problem only appears when collecting samples from the online service.

CC @golang/compiler

@cuonglm I think you mean fixed by https://go.dev/cl/581436, no?

@cuonglm I think you mean fixed by https://go.dev/cl/581436, no?

No, because go1.22.3 includes this CL but still trigger ICE.
Unless my operation was wrong, my git bisect points to https://go-review.googlesource.com/c/go/+/578815 which does fix this issue.

@cuonglm thanks for that clarification, I hadn't realized that we backported 581436. Interesting.

OK, I spent a little while debugging this.
Escape analysis is bombing in this part of initFunc:
// Initialize resultIndex for result parameters.
for i, f := range fn.Type().Results() {
	e.oldLoc(f.Nname.(*ir.Name)).resultIndex = 1 + i
}

because f.Nname is nil as opposed to pointing to the name for the function, which in this case is proto.Nullable[uint64].IsSet.
What's happening here is that at some point during the compilation of the offending package github.com/ClickHouse/clickhouse-go/v2/ext we encounter a reference to this specific generic function, and the code that reads the export data marks it for inclusion/compilation within the current package. The key bit of code here is this:
https://go.googlesource.com/go/+/5bf8c0cf09ee5c7e5a37ab90afcce154ab716a97/src/cmd/compile/internal/noder/reader.go#1123
What's supposed to happen at that point is that we'll read in the body for the function, and in fact there is a call to r.addBody later in funcExt, e.g. here.
The problem: at the  point of that call, r.curfn is nil, and as a result instead of immediately reading in the body, it gets tacked onto the todoBodies list here.
Ordinarily this would be fine, but: at the point that this happens we're not doing a "regular" read of the export data, we're looking things up as part of PGO devirtualization. Here's the stack trace:
      cmd/compile/internal/noder.(*reader).funcExt /w/go1.22/src/cmd/compile/internal/noder/reader.go:1110
      cmd/compile/internal/noder.(*reader).method /w/go1.22/src/cmd/compile/internal/noder/reader.go:1039
      cmd/compile/internal/noder.(*pkgReader).objIdxMayFail /w/go1.22/src/cmd/compile/internal/noder/reader.go:818
      cmd/compile/internal/noder.(*pkgReader).objIdx /w/go1.22/src/cmd/compile/internal/noder/reader.go:672
      cmd/compile/internal/noder.(*pkgReader).objInstIdx /w/go1.22/src/cmd/compile/internal/noder/reader.go:664
      cmd/compile/internal/noder.(*reader).obj /w/go1.22/src/cmd/compile/internal/noder/reader.go:636
      ...
      <a couple hundred similar frames elided>
      ...
      cmd/compile/internal/noder.(*reader).doTyp /w/go1.22/src/cmd/compile/internal/noder/reader.go:524
      cmd/compile/internal/noder.(*pkgReader).typIdx /w/go1.22/src/cmd/compile/internal/noder/reader.go:431
      cmd/compile/internal/noder.(*reader).typWrapped /w/go1.22/src/cmd/compile/internal/noder/reader.go:390
      cmd/compile/internal/noder.(*pkgReader).objIdxMayFail /w/go1.22/src/cmd/compile/internal/noder/reader.go:807
      cmd/compile/internal/noder.lookupMethod /w/go1.22/src/cmd/compile/internal/noder/unified.go:113
      cmd/compile/internal/noder.LookupFunc /w/go1.22/src/cmd/compile/internal/noder/unified.go:65
      cmd/compile/internal/pgo.addIndirectEdges /w/go1.22/src/cmd/compile/internal/pgo/irgraph.go:443
      cmd/compile/internal/pgo.createIRGraph /w/go1.22/src/cmd/compile/internal/pgo/irgraph.go:291
      cmd/compile/internal/pgo.New /w/go1.22/src/cmd/compile/internal/pgo/irgraph.go:192
      cmd/compile/internal/gc.Main /w/go1.22/src/cmd/compile/internal/gc/main.go:221

So essentially we wind up with some dangling references on todoBodies, and we never actually read the body of the function in question.
Not sure yet what the best overall approach is here.  I am also unsure as to why this problem would suddenly go away on tip, since as far as can see there haven't been specific changes there that would ameliorate the problem.
More work needed. CC @prattmic for additional eyeballs relating to PGO stuff.

However, the expectation is that LookupFunc would simply never find
the symbol name that appears in the profile at all because that includes
the .go.shape.blah component that doesn't exist in the high-level symbol name

Yes, this is certainly true. However what's happening here is that the pgoir stuff is looking for (and finding) the method
github.com/ClickHouse/clickhouse-go/v2/lib/column.(*Map).AppendRow
Nothing wrong there, but the body of AppendRow refers to a struct type that has a data member of generic type (proto.Nullable[uint64]) which has a method proto.Nullable[uint64].IsSet) and it is that generic method that is causing the problem.
The detailed sequence of events is as follows:

cmd/compile/internal/pgo.addIndirectEdges runs and pulls in the IR for column.(*Map).AppendRow since it is a hot indirect target.

the importing process leaves a lot of dangling functions on the todoBodies list (as described above), including 'proto.Nullable[uint64]'. In addition, the imported adds proto.Nullable[uint64] to the needWrapperTypes list.

The inliner runs, but it turns out that the top level package being compiled, github.com/ClickHouse/clickhouse-go/v2/ext is unusual and it has zero inlining opportunities. If the inliner had run, it would have made a call to readBodies, but this never happens.

Wrapper generation runs (after inlining, before escape analysis). Since proto.Nullable[uint64] is on the needWrapperTypes list, we manufacture pointer wrappers for all its methods, including proto.(*Nullable[uint64]).IsSet. This new wrapper has a direct call to proto.Nullable[uint64].IsSet (which still doesn't have a func body).

Now escape analysis runs. It processes the two IsSet methods, at which point it crashes.

So we have to have a lot of things lining up in exactly the right way for this to happen.
I am pretty sure that the right fix here is to add a cleanup call to readBodies from pgo.createIRGraph, but I am having a heck of a time trying to create a minimized test case that will reproduce the problem.
The thing I keep stumbling over in my smaller test case is that the generic type in question gets added to needWrapperTypes (which is what I want) but also at some later point gets added to haveWrapperTypes, which means we don't get the necessary wrapper. Very frustrating. I'll keep hacking away on the minimization.

@thanm I double check and the CL that changes to reflect package actually "fix" this issue.
It's very weird.


insert At Cursor

Currently the emoji is only inserted at the end of the text, would it be possible to adjust it so that the user can place it in any part of the text?
here is a solution with jquery that I found in another emoji component

util.insertAtCursor = function (text, el) {
text = ' ' + text
var val = el.value, endIndex, startIndex, range
if (typeof el.selectionStart !== 'undefined' &&
typeof el.selectionEnd !== 'undefined') {
startIndex = el.selectionStart
endIndex = el.selectionEnd
el.value = val.substring(0, startIndex) + text +
val.substring(el.selectionEnd)
el.selectionStart = el.selectionEnd = startIndex + text.length
} else if (typeof document.selection !== 'undefined' &&
typeof document.selection.createRange !== 'undefined') {
el.focus()
range = document.selection.createRange()
range.text = text
range.select()
}
}

Currently the emoji is only inserted at the end of the text

@AleDiias Actually, this library does not insert emojis, this happens in the external code. The picker responsibility ends when the user clicks the emoji and the picker emits the select event.
This is the part of the "not opinionated"" idea:

Emoji Mart doesn’t automatically insert anything into a text input, nor does it show or hide itself. It simply returns an emoji object. It’s up to the developer to mount/unmount (it’s fast!) and position the picker. You can use the returned object as props for the EmojiMart.Emoji component. You could also use emoji.colons to insert text into a textarea or emoji.native to use the emoji.

There is also related information in the Picker Usage And Native Emoji vs Images readme section.


Update RTK-Query information in comparison.md

Heyo, just adding those smaller updates to the comparison table :)

Stale Time Configuration is possible via keepUnusedDataFor, both on a per-api as well as a per-endpoint level
Window Focus Refetching and Network Status Refetching are possible by calling setupListeners(store.dispatch) once after store setup. I guess that counts as "Supported and documented, but requires extra user-code to implement"?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update build process to use kmutil rather than kextload, and add some…

… debugging commands

thanks!


transfer history not working for Nyota

reproduce:

import watch-only account Gbtn11Hno61PTwH4YwrmcbFGuhUi7ZD9uQLoAf7W3Yt2cy1
tap transfers

expected:
today:

0.2 NYT in
0.1 NYT out to HJ3kLwCfpDuHDNc72m1w8TDLhhUAi3CeuXeu29JbTMsAxTr

It looks like the indexing doesn't work in the first place, so this might not be an app bug:
https://api.encointer.org/v1/accounting/transaction-log?cid=kygch5kVGq7&start=1670000000000&end=1709150982000&account=Gbtn11Hno61PTwH4YwrmcbFGuhUi7ZD9uQLoAf7W3Yt2cy1

It also won't work for a newly created account on Leu

@brenzi fixed!

Confirmed, thx


Lxlaunch crashes on an unhandled exception in the "else" case of the RS2 check

Hiya,
Saw you updated lxlaunch, and I went to go see what the deal was with it.  Two weird things:
First, the build-number check seems to be looking for build >=15000 to launch with the new method (comments say that build >= 15000 means the build is at least redstone 2).  However, the current latest fast-ring build is 14931, so the conditional fails and we drop into the else half of the conditional.  However, as soon as that happens, it crashes.  The VS15 debugger claims that this is a result of an unhandled exception:

Exception thrown at 0x00007FF93925BBC0 (ntdll.dll) in lxlaunch.exe: 0xC0000005: Access violation writing location 0x000000000000000B.

The only thing I did that was maybe possibly questionable was building it against the 14392 SDK instead of the 10581 (iirc?) SDK, but I got a similar crash building against that too.
I also tried forcing it to use the new interface by dropping the check (>=15000) to (>=14500), but this gave another crash in basically the same place (inside of the if instead of the else, but right after the line:
 hr = ((PLX_INSTANCE_V2)*iLxInstance)->CreateLxProcess with a similar message.

By the way, as per the thread on the WSL issues page, I've got the error that's getting thrown after dropping that number from 15000 to 14500:

Unhandled exception at 0x00007FFF85718C42 (rpcrt4.dll) in lxlaunch.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. occurred

Which build are you running on, by the way? I tried on my preview build with the 14393 SDK and don't have these problems.

I'm on 14931, building with VS 15 Preview 4 against the 14393 SDK.

Fixed in c8a6696cb7a8c659816413a49ababedda3a16355


[R-package] Add explicit return statement to R functions.

Closes #3352.
Hi, @jameslamb and @Juniper-23 , and happy new year!
I noticed that the issue has been opened for quite some time and is still not fixed, so I thought I'd give it a try. You may want to merge this PR in case @Juniper-23 does not have time to create one.
There may be some code formatting issues in this PR though. I found two formatting styles in the original files when the code in return() is long (e.g., exceeding 80 characters), for example:
# style1
return(lgb.call(
  fun_name = "LGBM_BoosterGetCurrentIteration_R"
  , ret = cur_iter
  , private$handle
))

# style2
return(
  lgb.call(
    fun_name = "LGBM_BoosterGetCurrentIteration_R"
    , ret = cur_iter
    , private$handle
  )
)

Tell me which one you prefer and I'll be happy to make a few more edits!

The commits have passed all the tests on my laptop but failed many GitHub Actions checks. Do you know why?

The commits have passed all the tests on my laptop but failed many GitHub Actions checks. Do you know why?

Could you please also add return() statements to these calls?

build_r.R:
    .handle_result() should have return(invisible(NULL))
lgb.plot.interpretation.R
    lgb.plot.interpretation() should have return(invisible(NULL))

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing. Do you have any idea?

Could you please also add return() statements to these calls?

build_r.R:
    .handle_result() should have return(invisible(NULL))
lgb.plot.interpretation.R
    lgb.plot.interpretation() should have return(invisible(NULL))

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing. Do you have any idea?

Could you please also add return() statements to these calls?

build_r.R:
    .handle_result() should have return(invisible(NULL))
lgb.plot.interpretation.R
    lgb.plot.interpretation() should have return(invisible(NULL))

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing, and I don't know to read the error messages of testthat. Can you help?

Could you please also add return() statements to these calls?

build_r.R:
    .handle_result() should have return(invisible(NULL))
lgb.plot.interpretation.R
    lgb.plot.interpretation() should have return(invisible(NULL))

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing, and I don't know to read the error messages of testthat. Can you help?

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing, and I don't understand how the changes are related to test_lgb.Booster.R. Can you help?

Adding these modifications results in many GitHub Action failures. Judging from the log messages, it seems that the failures are caused by unit tests:
* checking tests ...
  Running ‘testthat.R’
   ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Length mismatch: comparison on first 0 components
  ── Failure (test_lgb.Booster.R:454:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  ret_bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:455:5): Booster$params should include dataset params, before and after Booster$reset_parameter() ──
  bst$params not identical to `expected_params`.
  Length mismatch: comparison on first 3 components
  ── Failure (test_lgb.Booster.R:723:5): params (including dataset params) should be stored in .rds file for Booster ──
  bst_from_file$params not identical to list(...).
  names for current but not for target
  Length mismatch: comparison on first 0 components

  [ FAIL 5 | WARN 0 | SKIP 3 | PASS 605 ]
  Error: Test failures
  Execution halted

However, when I run R CMD check --as-cran on my laptop (Ubuntu 20.04, R 4.0.2), it seemed to be OK:
* checking tests ...
  Running ‘testthat.R’
 OK

This is confusing, and I don't understand how the changes are related to test_lgb.Booster.R. Can you help?

I just realized that you have merged #3362, which contains the failed tests, into master. I guess that's the reason behind the failed tests, right? However, this is confusing. Why does this PR run tests from branch master instead of branch fix-3352? Can we set up GitHub Action in a way so that each branch runs its own tests?

I just realized that you have merged #3362, which contains the failed tests, into master. I guess that's the reason behind the failed tests, right? However, this is confusing. Why does this PR run tests from branch master instead of branch fix-3352? Can we set up GitHub Action in a way so that each branch runs its own tests?

CI runs against the merger of your PR and its target branch (in this case master). You can see that in the "Checkout repository" step in the CI jobs: https://github.com/microsoft/LightGBM/pull/3703/checks?check_run_id=1639476038.

/usr/bin/git checkout --progress --force refs/remotes/pull/3703/merge

This is the behavior of most CI services, and it's done to test that master would still be a working branch after your changes are merged.
This is also buried deep in the git docs, at https://git-scm.com/book/id/v2/GitHub-Maintaining-a-Project.

The eagle-eyed among you would note the head on the end of the remote portion of the refspec. There’s also a refs/pull/#/merge ref on the GitHub side, which represents the commit that would result if you push the “merge” button on the site

So those build failures are desirable. They're telling us that CI would start to fail if we merged this PR into master as-is.
Please merge master into this branch and test. Let me know if you have other questions!

CI runs against the merger of your PR and its target branch (in this case master). You can see that in the "Checkout repository" step in the CI jobs: https://github.com/microsoft/LightGBM/pull/3703/checks?check_run_id=1639476038.

/usr/bin/git checkout --progress --force refs/remotes/pull/3703/merge

This is the behavior of most CI services, and it's done to test that master would still be a working branch after your changes are merged.
This is also buried deep in the git docs, at https://git-scm.com/book/id/v2/GitHub-Maintaining-a-Project.

The eagle-eyed among you would note the head on the end of the remote portion of the refspec. There’s also a refs/pull/#/merge ref on the GitHub side, which represents the commit that would result if you push the “merge” button on the site

So those build failures are desirable. They're telling us that CI would start to fail if we merged this PR into master as-is.
Please merge master into this branch and test. Let me know if you have other questions!

It turns out that the test failures were caused by a misplaced return() statement resulted from the merge. I have fixed it in commit 1f8661a .

It turns out that the test failures were caused by a misplaced return() statement resulted from the merge. I have fixed it in commit 1f8661a .

Thanks for the changes @zenggyu . Can you please update to master again? We just merged a PR that removes the flaky GitHub Actions job R GitHub Actions / r-package (windows-latest, MINGW, R 3.6, cmake) (pull_request) , which is failing here for reasons unrelated to your code.
To replicate the linting errors you're facing on Travis, you can run Rscript .ci/lint_r_code.R $(pwd)/ from the root of this repo.

Thanks for the changes @zenggyu . Can you please update to master again? We just merged a PR that removes the flaky GitHub Actions job R GitHub Actions / r-package (windows-latest, MINGW, R 3.6, cmake) (pull_request) , which is failing here for reasons unrelated to your code.
To replicate the linting errors you're facing on Travis, you can run Rscript .ci/lint_r_code.R $(pwd)/ from the root of this repo.


I can't make it work :)

Hi, probably I'm doing something wrong.
I made a separated clean file to make sure no other js was in the way and I used your exact same example at codepen.
This is what I have and it's not working, please let me know what am I doing wrong :)

Sorry here's the jsfiddle
https://jsfiddle.net/fullofgraphics/0gwdrdf3/

You need to call the jQuery library:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>

Yep, as @Cattamer said it looks like you are just missing jQuery.


Feature a distribution compatible with Node in "type": "module".

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Hi MUI team,
Steps to Reproduce:
You can reproduce the problem using the below repository:
git clone https://github.com/garronej/mui-import-esm
cd mui-import-esm
yarn install
node index.mjs

Current behavior 😯
Node is unable to import MUI in the type: "module" environment.
We're getting Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/Users/joseph/github/mui-import-esm/node_modules/@mui/material/styles' when importing any submodule of @mui/material.
Expected behavior 🤔
MUI should be correctly imported when running under Node's ESM environment.
Context 🔦
As the publisher of modules that depend on MUI, such as tss-react and onyxia-ui, I've encountered some problems with distributing real ECMAScript Modules (ESM) due to MUI's lack of a functional ESM distribution compatible with a "type": "module" node environment. While MUI does provide an ESM distribution that works with bundlers, it unfortunately fails to do the same for node.
Proposed Solutions:
To resolve the above issue, an additional entry to<EMAIL_ADDRESS>could potentially fix the problem:
  "exports": {
    "./styles": {
      "default": "./node/styles/index.js"
    },
    "./Button": {
      "default": "./node/Button/index.js"
    }
  }

Implementing this works for import { useStyles } from "@mui/material/styles" but doesn't function correctly for import Button from "@mui/material/Button". This issue arises as Button is represented as an object, rather than as the default function.
For the above scenario, there are two possible strategies:

Adopt @Andarist's Emotion strategy: Expose a .mjs file that reexports everything from the CommonJS ESModuleInterop distribution (See an example here). This strategy allows for correct defaults. And avoiding the dual package hazard.

Publish a full, standards-compliant ESM distribution: Similar to tsafe.

The popularity of this comment based on its upvotes demonstrates that other developers are experiencing similar issues.
Regardless, I appreciate all the hard work done by the MUI team. Thank you!
Your environment 🌎
No response

Implementing this works for import { useStyles } from "@mui/material/styles"

This is true but at the same time, this is also possible in node and I'd consider this to be a problem:
import ns from "@mui/material/styles"
ns.useStyles

I'd consider this to be a problem

Really? I'm surprised that you think it's a problem.
To achieve total compliance with the standard upon importing the default from @mui/material/styles, we should encounter the following runtime error:
import ns from "@mui/material/styles"
            ^^^
SyntaxError: The requested module '@mui/material/styles' does not provide an export named 'default'

However, bear in mind that allowSyntheticDefaultImports is enabled by default in TypeScript. Thus, TypeScript won't raise any objections when you attempt to import it in this manner.

Publish a full, standards-compliant ESM distribution: Similar to tsafe.

Following further examination, I recommend not implementing this option, even if it appears to be the sensible path. @Andarist has made the correct choice. Publishing an actual Node compliant ESM distribution will result in situations where MUI is duplicated. If it helps, I can demonstrate this through a repository.

Upon conducting a thorough investigation, it appears there isn't a straightforward solution to this problem.
Not providing a distribution compatible with the "type: module" mode of Node.js isn't ideal. However, there's also no apparent way (to my knowledge) to provide this distribution without generating the potential risk of a dual package hazard.
For further illustration, I've created a repository where I demonstrate an issue present in Emotion but not in MUI. Here's the link for your reference: https://github.com/garronej/vite-dual-package-repro-repo.

This particular issue is a Vite bug, you can track the fix here: https://github.com/vitejs/vite/pull/13370

Hey guys, sorry for the late response - I was on vacation.
I'm looking forward to the day when everything will be ESM, and we won't have such problems.
I wonder what the impact would be for the community if we shipped just pure ESM. I think this is something we need to consider for the future (cc @Janpot, @alexfauquette, @flaviendelangle).
As for this particular thread, if I read it correctly, once Vite 4.4 is released, the problem will be solvable, right?

As for this particular thread, if I read it correctly, once Vite 4.4 is released, the problem will be solvable, right?

Yes, it should be solvable. Note that solving this in full on your side requires some serious package.json#exports gymnastics but it's doable - as far as I could verify it. Emotion shipped using this strategy and so far we didn't quite get any issue reports about this, apart from the mentioned Vite issue and the one that you have found here. The first one (Vite issue) is supposed to get fixed soon (in the mentioned 4.4 release) but we are still waiting for any kind of response from the Vercel team. Note that the Next.js issue isn't affecting everybody - you have to mix ESM and CJS files in a particular way to end up with that issue and it's not something that people do often.

I wonder what the impact would be for the community if we shipped just pure ESM. I think this is something we need to consider for the future (cc @Janpot, @alexfauquette, @flaviendelangle).

Likely... it could be quite severe 😅 and that's definitely not something that you can consider within the current major version. I'm also looking for ESM days ahead of us but, quite frankly, I'm rather afraid of paving the way with my libraries and I'm waiting for other people to start doing that at scale to join them at some point.

Maybe not an ideal solution, but none of them are, so for completeness: To mitigate dual package problems we could also consider adding a check at runtime and warn/error when a module is loaded that has a different format than the previous loaded ones.


Specify chrome size

How do i specify the window size that should be used by chrome headless?

You can specify it with --window-size chrome option.
For example:
const prerender = require('prerender');
const server = prerender({
    chromeFlags: ['--headless', '--disable-gpu', '--remote-debugging-port=9222',
	    '--hide-scrollbars', '--window-size=1920,1080']
});

Thanks! The flags above, are they the reccomended ones to pass along with window-size?

They are defaults:
https://github.com/prerender/prerender/blob/master/lib/browsers/chrome.js#L24

You can also pass in a different screen size on every request by setting req.prerender.width and req.prerender.height during the requestReceived lifecycle event.
Here's an example of what a plugin might look like to set the width and height based on a header you can pass in:
module.exports = {
  requestReceived: function(req, res, next) {

    if (req.headers && req.headers['x-prerender-viewport-width'] && req.headers['x-prerender-viewport-height']) {

      var newWidth = parseInt(req.headers['x-prerender-viewport-width']);
      var newHeight = parseInt(req.headers['x-prerender-viewport-height']);

      if (!isNaN(newWidth) && !isNaN(newHeight) && newWidth > 0 && newHeight > 0) {

        req.prerender.width = newWidth;
        req.prerender.height = newHeight;
      }

    }

    next();
  }
}

Thanks!


add contribution docs

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


Rename the view or add correct name to the readme

Very nice implementation of "Floating Action Button (fab)". You should make it easier to find.

Thanks!