There should be a single way to provide widget options in uiSchema

We currently have two distinct ways to provide custom widget options in uiSchema:

Through the object format for the ui:widget directive,
Through the ui:options one.

I'm in favor of using the latter, and deprecating support for the former. Thoughts?

Agreed, I have a few "wi-elds" that work with objects, arrays, base types. I like the ui:options structure a bit more myself. It's easier to work with adding options in some cases and not in others.

I'm also in favor of the ui:options format. Few reasons to add:

It's easier to carry around if you have nested fields/widgets (I have deeply nested fields/widgets).
It's easier to define in PropTypes and therefore simplifies error detecting.
It makes the namespace more easy to handle with.

Sorry for this dumb question, but I only see ui:options mentioned under Array items ordering.
Is exposing ui:options from the uiSchema to custom widgets a new feature in an upcoming release?
If yes, is the plan then to expose the uiSchema options to the custom widgets (through a new prop?) like this;
const uiSchema = {
	"ui:options": {
		"someOtherModel": someOtherModel,
		"onUploadDone": Actions.addAsset,
	},

	images: {
		items: {
			guid: {
				"ui:widget": {
					"component": "customUploadWidget",
				}
			}
		}
	},

	videos: {
		items: {
			guid: {
				"ui:widget": {
					"component": "customUploadWidget",
				}
			}
		}
	}
}

Instead of;
const uiSchema = {
	images: {
		items: {
			guid: {
				"ui:widget": {
					options: {
						"someOtherModel": someOtherModel,
						"onUploadDone": Actions.addAsset,
					},
					"component": "customUploadWidget",
				}
			}
		}
	},

	videos: {
		items: {
			guid: {
				"ui:widget": {
					options: {
						"someOtherModel": someOtherModel,
						"onUploadDone": Actions.addAsset,
					},
					"component": "customUploadWidget",
				}
			}
		}
	}
}

@matiaslarsson It would look like this:
const uiSchema = {
    images: {
        items: {
            guid: {
                "ui:widget": "customUploadWidget",
                "ui:options: {
                        "someOtherModel": someOtherModel,
                        "onUploadDone": Actions.addAsset,
                 }
            }
        }
    },

    videos: {
        items: {
            guid:
                "ui:widget": "customUploadWidget",
                "ui:options: {
                        "someOtherModel": someOtherModel,
                        "onUploadDone": Actions.addAsset,
                 }
        }
    }
}

@olzraiti Got it, thanks!

So is this api design change to ui:options instead of ui:widget { options final? I would like to help making 0.40 final so I will look into this then. How about backwards compatibility?

I thought about it and I think I have a clean solution here with backwards compatibility.
So there are three ways to set options now, depending on which option you want to set:

directly with ui:{optionName} (already used in production, quite good syntax)
with ui:options object (not yet used in production, but better syntax?)
and with ui:widget.options object (already used in production, but awkward syntax).

To align them all, a getUiOptions(uiSchema) function could be added in utils.js, which should be called in this way from each field for all options:
// in a Field
const {uiSchema} = this.props;
const {widget, barable, fooable} = {
  widget: defaultWidget,
  barable: true,
  fooable: true,
  ...getUiOptions(uiSchema)
};

So the options syntax is abstracted away from the fields into one util function. This makes the field files cleaner and more consequent immediately.
In getUiOptions(), all 3 syntaxes could be accepted for every option, and for one or two syntaxes, a deprecation warning could be logged:
// in utils
export function getUiOptions(uiSchema) {
  // get all passed options from ui:widget, ui:options, and ui:<optionName>
  return Object.keys(uiSchema).filter(key => /^ui:/.test(key)).reduce((options, key) => {
    const value = uiSchema[key];

    if (key === "ui:widget" && typeof value === "object") {
      // potential DEPRECATED warning can be called here
      options["widget"] = value.component;
      if (value.options) {
        setOptions(options, value.options);
      }
    } else if (key === "ui:options" && typeof value === "object") {
      // potential DEPRECATED warning can be called here
      setOptions(options, value.options);
    } else {
      // potential DEPRECATED warning can be called here
      options[key.substring(3)] = value;
    }

    return options;
  }, {});

  function setOptions(dest, src) {
    Object.keys(src).forEach(option => {
      dest[option] = src[option];
    });
  }
}

I would like to know what you think about this. I will PR if you think that this is the right approach.

This indeed sounds like a very good plan, and I think that's the best compromise we could possibly come with :)
We'll probably have to officially deprecate the two other approaches and only document the ui:options one, and when tagging 1.0 we'll remove support for the old ways. Would that work for you folks? If so, I'll be happy to review a PR!

I will try to put together a PR in the next days. It is not trivial, I already saw this approach has some overlap with other util functions like getAlternativeWidget() and I need to understand what's going on in every field and widget with all the passing around of options.

First observation: there appears to be something wrong with current implementation of merging defaultProps.options of custom widgets with custom options from uiSchema, according to a test case I added in my branch. Custom options provided for one instance of a custom widget are applied to all instances of that custom widget, both when that widget is referenced as string and when it is referenced as function.
Two of the four tests fail; which tests fail, depends on the order of the tests...

Although my pull request #378 still has a test error, could someone already give some feedback on my changes? Especially for my question about the failing test. :) Thank you!


chore(package.json): update version to v0.3.2

Codecov Report

Merging #78 (8851206) into dev (926ed52) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               dev       #78   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          422       422
  Branches        29        29
=========================================
  Hits           422       422


Add type coercion/validation for Is[Not]True and similar statements

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Once https://github.com/apache/arrow-datafusion/pull/3301 and https://github.com/apache/arrow-datafusion/pull/3222 are merged, let's add type validation for IsTrue/False/Unknown to ensure that the left expr is a boolean.


Allow fetching the raw window handle of a window by it's iced::window::Id.

This is useful for specific platform code that the user may want to integrate with iced.

The ecosystem is moving to raw_window_handle::WindowHandle<'a> type, which has a lifetime parameter, analogous to BorrowedFd<'a>. (This is necessary since raw window handles contain pointers in some cases, and there's a desire to offer safe APIs.)
Not sure how this would work. It could still provide a raw handle, but that would make it unsafe to work with. Or it could return Arc<winit::Window> or some wrapper around things like that. https://github.com/rust-windowing/raw-window-handle/issues/158 is relevant.
(https://github.com/iced-rs/iced/pull/2191 has a WIP update to the latest raw-window-handle with the safe handle types.)

@ids1024 We could allow providing a callback impl FnOnce(WindowHandle<'a>) on Command construction.

Because winit is unsound anyway, either method is technically introducing unsound code, and if winit rectifies the issue you would be unlikely to be able to Arc the window since the lifetime is tied to the windows and windows outlive the event loop.
I'm open to any approach FWIW that allows me to get the native handle from the window and manipulate it as it's necessary to fill a lot of issues with winit in general.

Closing because wgpu 0.19 is out and it will be easier to use RWH 0.6.


Resting Demo User And Password Hourly?

Can we reset server hourly ?

As it is based on laravel we can migrate:refresh hourly by using cron jobs :)


Tailscale_1.42.0-1_x86_64.qpkg - The digital signature is invalid.

[App Center] Failed to install Tailscale. The digital signature is invalid. To proceed with installation, go to App Center > Settings > General, and then select "Allow installation of applications without a valid digital signature".
The previous release is installing without such problems.

Same here. I was able to upgrade from 1.40.0 by allowing applications without a valid digital signature and when I look in the app center Tailscale 1.42.0 shows as not having a digital signature.

Ditto here. Previous versions did not have a signature issue. Hope this can be resolved.

Do you plan to publish properly signed build? That shouldn't be a big problem once you succeeded with previous builds.

New version has been released, 1.46.1, now signed.
I think we can close this issue now


The running jobs can not be stopped correctly in HA environment

When users try to stop running jobs on the instance A,  the jobs that are running on the instance B cannot be stopped.

Reassign to Steven as he will responsible to Jobservice refactor.

As the job service will be refactored for HA, this problem will be considered in the new design, so close this issue.


General Issue: use newer version of styler

Background Information
The renv.lock specifies styler 1.8.0. and will soon specify styler 1.9.1. Identify and fix any files which would require changes to satisfy this new version of styler.
Definition of Done
Latest version of styler is specified in renv.lock and styler::style_pkg() shows all files as unchanged.

PR #252 successful; this branch no longer needed.


remove "Input Container" demo link

@mmalerba I think this was already fixed with #2922, but it's not merged yet.

@dahaupt ah, my bad


⚠ Bofrost.at has degraded performance

In 16e2597, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1032 ms

Resolved: Bofrost.at performance has improved in 3cb7b72 after 48 minutes.


jdee-mode some colours are off

Hey,
some colours, .e.g the link, breakpoint (bright green line) seem off in jdee-mode; see below.

I've added jdee faces and fixed the link (among other things), but I couldn't find the face for the breakpoint. Do you know what face that is? If you don't, place your cursor over it and run the following:
(or (get-char-property (point) 'read-face-name)
    (get-char-property (point) 'face))

It should tell you what face is applied there (turn off hl-line-mode first, if you use it). That should tell me where to look.

Thanks a lot! It seems to be jdee-db-spec-breakpoint-face.

Alright, round two. That should fix the breakpoints, hopefully. The way jdee initializes its breakpoint faces is a little... strange, so please test it and let me know if it worked.

I am afraid the breakpoint changes broke the whole mode, I get File mode specification error: (invalid-function #1B2229). Commenting out the three jdee-db unbreaks it.

My bad, this revealed an unrelated issue with doom-common-variables as the cause. It should be fixed now.

I am still getting the File mode specification error: (invalid-function #1B2229) error.
Debugger entered--Lisp error: (invalid-function "#1B2229")
  ("#1B2229" . "#3B3F46")
  eval(("#1B2229" . "#3B3F46"))
  custom-initialize-reset(jdee-db-spec-breakpoint-face-colors (cons "black" "green"))
  custom-declare-variable(jdee-db-spec-breakpoint-face-colors (cons "black" "green") "*Specifies the foreground and background colors used to highlight\nthe line at which you have specified that a breakpoint to be set." :group jdee-project :type (cons :tag "Colors" (string :tag "Foreground") (string :tag "Background")) :set (lambda (sym val) (make-face (quote jdee-db-spec-breakpoint-face)) (set-face-foreground (quote jdee-db-spec-breakpoint-face) (car val)) (set-face-background (quote jdee-db-spec-breakpoint-face) (cdr val)) (set-default sym val)))
  byte-code("[...]" [custom-declare-variable jdee-db-spec-breakpoint-face-colors (cons "black" "green") "*Specifies the foreground and background colors used to highlight\nthe line at which you have specified that a breakpoint to be set." :group jdee-project :type (cons :tag "Colors" (string :tag "Foreground") (string :tag "Background")) :set (lambda (sym val) (make-face (quote jdee-db-spec-breakpoint-face)) (set-face-foreground (quote jdee-db-spec-breakpoint-face) (car val)) (set-face-background (quote jdee-db-spec-breakpoint-face) (cdr val)) (set-default sym val)) jdee-db-requested-breakpoint-face-colors (cons "black" "yellow") "*Specifies the foreground and background colors used to highlight\nthe line at which you have requested a breakpoint to be set." (cons :tag "Colors" (string :tag "Foreground") (string :tag "Background")) (lambda (sym val) (make-face (quote jdee-db-requested-breakpoint-face)) (set-face-foreground (quote jdee-db-requested-breakpoint-face) (car val)) (set-face-background (quote jdee-db-requested-breakpoint-face) (cdr val)) (set-default sym val)) jdee-db-active-breakpoint-face-colors (cons "black" "red") "*Specifies the foreground and background colors used to highlight\na line where an active breakpoint exists." (cons :tag "Colors" (string :tag "Foreground") (string :tag "Background")) (lambda (sym val) (make-face (quote jdee-db-active-breakpoint-face)) (set-face-foreground (quote jdee-db-active-breakpoint-face) (car val)) (set-face-background (quote jdee-db-active-breakpoint-face) (cdr val)) (set-default sym val)) defalias jdee-db-breakpoint-marker-p eieio-make-class-predicate jdee-db-breakpoint-marker jdee-db-breakpoint-marker--eieio-childp eieio-make-child-predicate jdee-db-breakpoint-marker-child-p make-obsolete "use (cl-typep ... 'jdee-db-breakpoint-marker) instead" "25.1" put cl-deftype-satisfies eieio-defclass-internal nil ((marker :initarg :marker :documentation "Overlay in Emacs, extent in XEmacs")) (:documentation "Indicates the location of breakpoints in a source buffer. This class\nuses overlays as markers in Emacs and extents in XEmacs.")] 10)
  require(jdee-db)
  byte-code([...]" [require cl-lib eieio jdee-classpath jdee-db jdee-dbo jdee-files tree-widget custom-declare-variable jdee-bug-sio-connect-delay 1 "Length of time in seconds that the JDE waits\nbefore attempting to connect to the\ndebuggee application's standard I/O. This delay\nis intended to give JDEbug time to create the\nSIO socket. Try increasing this variable if JDEbug\nhangs while launching an application. If your\nsystem never hangs, you can reduce this setting\nto 0 to eliminate the connection delay." :group jdee-bug :type integer] 8)
  require(jdee-dbs)
  byte-code("[...]" [require cl-lib jdee-files jdee-parse jdee-dbs jdee-dbo jdee-db jdee-run efc semantic/util-modes custom-declare-group jdee-bug nil "JDEbug General Options" :group jdee :prefix "jdee-bug" custom-declare-variable jdee-bug-debug "*IMPORTANT!!!! Leave this switch in its default state (off) unless\nyou need to modify the *JDEbug* Java source code. Setting this switch\non causes the JDE to load *JDEbug* from its java/classes directory\ninstead of from jde.jar. It also causes the JDE to run the debugger in\ndebug server mode. This allows you to use *JDEbug* to debug itself." :type boolean jdee-bug-jpda-directory "" "*Pathname of the directory containing Sun's Java Platform Debug Architecture\ndistribution. You need to set this variable only if this project uses a JDK 1.2 vm."  Let me know if it does the trick.

That seems to have done the trick. Many thanks!


Fix build error due to wrong parameter

Description
JavaScriptInterface was receiving one more parameter when its constructor only accepts 2, to fix build this PR remove the unused parameter
Issues Resolved
List any existing issues this PR resolves
Check List

[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable.

Thank you @GabriellCosta !


Needs example of sociable unit testing/integration testing using WebApplicationFactory

I've been unable to figure out how to mock authenticate in my existing sociable unit tests that use CustomWebApplicationFactory<Startup> to create a TestServer. They were working fine with role based authorization.
I tried following example 2 in Unit Test your AuthP app, and while that was working for getting services from factory.Services, it is not working when using factory.CreateClient().GetAsync("url").
I thought I could use a token created like in TestGenerateJwtTokenAsyncOk as a bearer token, but once I finally got the token generated, I got status code Unauthorized, WWW-Authenticate: Bearer error="invalid_token", error_description="The signature key was not found"
My Startup is applying the following configuration for this service:
            services.RegisterAuthPermissions<Permissions>()
                .AzureAdAuthentication(AzureAdSettings.AzureAdDefaultSettings(true))
                //... database method left out

After that my CustomWebApplicationFactory is applying the following configuration for this service:
                services.RegisterAuthPermissions<Permissions>(opt => opt.ConfigureAuthPJwtToken = CreateTestJwtSetupData())
                        .UsingInMemoryDatabase()
                        .SetupForUnitTestingAsync();

First thing: the exception in Microsoft's code, not AuthP code but I do wonder if its because AuthP code uses the recommended SecurityAlgorithms.HmacSha256Signature and not SecurityAlgorithms.HmacSha256. Worth a check.
Yep, this code is complex and any way you can simplify is going to help.
I'll close this for now, but if you want to reopen it again I happy to help.


I am getting strange characters in the results

When running the scraper some fields on the csv appear broken picture bellow.

The text here seems that its missing or the scraper fails to get the correct text, or it fails to translate the text in to UTF-8.
As you can see on the image the description of the first place is corrupted:
***n*rvino è*i* lu*go*i**a** **r**li***p*s*i******di v*no**i**u*****!****n*s*ra*****z**** escl***v* ** v*n* ita*ia*i** *n*e*******al* t**a*p*tta nel*no*t*o nego*** *n **A DA*****3 ** *****a*o**O*fria***una*va**a*ga*ma d* *t***et*e **r **dd*s*a***ogni **st** d*i *i*i c*assici * **ell****ù *s*l**iv*:*****s*r* **ss** ****chi******l*ci***ti*****ui**e**n*o c****a*******c*e*iona*e**ualit*.**n***re,*i****t***espe**i ** v*** s**o s*m**e*a******s**i*** *e* con****i*e **pporto nell* sce*** ****a b****g**a***rf*t****e* ogn***cc*s**ne* M* n** **nisc**qui, Si***rvin**è a**he u* r****r**** **ve*potrai d*g*s*ar*** nost***v*ni***comp***a*i da*****i**te*ze c***n*r**,*p*r **'*s*e**enza **n**r*al* *n*ca."

Is this an known issue or i messed up the set up on my computer?

Free versions shows only a limited set of data points, the fields are hidden with "*". To access additional datapoints, you will need to upgrade to the Pro Version.
Let me know if you further questions!


feat: add privacy icon

i added a conditional max-width, because otherwise the last item in the list of links is on a line by itself and it looks weird at larger font sizes/smaller screen sizes
screenshots
with Your Privacy Choices

without

testing
the theme demo doesn't have Osano, so the link we're adding the icon to doesn't show up normally. in GlobalFooter.js, change the hasOsano function to always return true. then the "Your Privacy Choices" link and the new icon will show up
the behavior of the icon (invert on hover) should match the behavior on newrelic.com. clicking the link will throw an error since Osano isn't defined

Looks good!
I did notice that when i click on it in mobile emulation, if i dismiss the error box, the icon stays highlighted. Not sure what that behavior will be like on actual mobile.

hmm i wasn't getting this in Firefox. but i think it's okay if it's highlighted while it's focused on mobile, it should unhilight whenever the user taps somewhere else. i'm pretty sure that matches behavior i've seen before on buttons etc on mobile


Collected issues with Volumes

[ ] #3639 - Volumes don’t work for base images
[ ] #2259 - Setting permissions on bind mounted volumes
[ ] #3949 #5229 - Build-only data
[x] #1992 - docker cp doesn’t work with volumes
[x] #3782 - recursive bind mounting (--rbind instead of —bind)
[x] #3634 #4356 - volume garbage collection (last comment) # can be handled with named volumes and external volume drivers
[x] #4023 - Mount remote volumes (client is remote, path is local to client)
[ ] #2045 - dynamically change volumes
[x] #6504 - Volume recovery (after corrosponding container removed) # named volumes resolves this
[x] #6556 - Backup/restore volumes
[x] #6698 - Volumes need data-containers to be useful - # hanlded by named volumes and external volume drivers
[ ] #7054 - Expand perm handling of volumes

This is very out of date. I rather not maintaining an out of date list, specially since the issues described here are already in other issues.
Closing.

Wasn't really out of date, I just touched last week, but ok :)

Perhaps this would be a good case for a label like area/volumes.


model optimization

I finished model optimization by using PCA and feature importance value in RF

@tangyl92 It looks great. Just that I think the pd.readcsv is not working since the csv file is inside the data folder.
Also in order to make our analysis reproducible I think we could use import in python? (https://archive.ics.uci.edu/dataset/697/predict+students+dropout+and+academic+success)
Install the ucimlrepo package
pip install ucimlrepo
Import the dataset into your code
from ucimlrepo import fetch_ucirepo
fetch dataset
predict_students_dropout_and_academic_success = fetch_ucirepo(id=697)
data (as pandas dataframes)
X = predict_students_dropout_and_academic_success.data.features
y = predict_students_dropout_and_academic_success.data.targets

@billwan96 Hi Bill, thank you for noticing that. Actually I have change the path as following:
"student_df = pd.read_csv('../data/student.csv')"
'.. ' means go to parent directory


utilize unity time results

This PR makes use of the test time functions in unity and makes it so the base usecases of Ceedling will work with it.
Currently if UNITY_INCLUDE_EXEC_TIME is defined, the Ceedling sanity check will fail. After this PR, the sanity check will pass and the junit plugin will take advantage of the new outputs.

@aschlicht yeah that was a debug print that can be removed. There's some other things I'd like to dig into with this plugin as I forgot I made manual changes on my local gem to allow for more unique characters in parameterized test's name (for example an ampersand in a test parameter string) .

See  #425

Thank you for making the changes so quickly! I'm glad you know what you are
doing with all the escape characters. I'm a C, C++, C# and Python guy. I
can figure my way through Ruby, but it takes awhile. Good to see Mark
already merged your changes too.
Aaron
On Wed, Nov 13, 2019 at 5:22 PM art-of-dom<EMAIL_ADDRESS>wrote:

See #425 https://github.com/ThrowTheSwitch/Ceedling/pull/425
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ThrowTheSwitch/Ceedling/pull/419?email_source=notifications&email_token=AD3AUXDSPPCHUIQSF3ZGGIDQTSK2TA5CNFSM4JI425QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEAEOJY#issuecomment-553666343,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3AUXHNRT5AYR6IGF2WNZDQTSK2TANCNFSM4JI425QA
.


Add rx and tx in netp screen

Task/Issue URL: https://app.asana.com/0/42792087274227/1205846464751252/f
Description
See task description
Steps to test this PR
See task description

Current dependencies on/for this PR:

develop

PR #3788   👈

This stack of pull requests is managed by Graphite.


broken in 2024.08?

The Fallback Agent stopped working after the last major HA-update. The dropdown-menu in the "Assist" chat box is completely empty and the box states "this agent can not control your smart home".

Here is the fix explanation:
https://github.com/acon96/home-llm/issues/198#issuecomment-2285005038

Plus one for the issue but I'm a dummy and don't know how to fix

I'll look into this this weekend. Sorry for being slow on this, I have yet to update my Home Assistant to 2024.08, so I wasn't aware of an issue, and I haven't been available to look at Github this month until now.

No worries, no rush.  Thanks for taking a look!

Glad to know this turned out to be a known issue. I was trying this for the first time in 2024.8 and didn't understand why it wasn't working for me.

Any update on the timeframe for this?  Was super helpful when it was working!  I'd roll back just to get this working again, but since all my automatons changed from 'Services' to 'Actions' in the last monthly update I can't really roll back.  :/

I am having issues with replicating the changes, and my time to work on it is limited, but I am working on it. Hopefully soon, but I can't give an exact timeline

No worries at all, thanks for the update, please take your time.  Again, I appreciate the time you spent creating this project!

I just released a beta release that should fix it. If people are willing to test to verify (as it working for me doesn't guarantee anything).
Note: You may need to go in and "Edit" the Fallback Conversation Agent and not change anything, just save the changes. I am not 100% sure. If people are willing to validate that and let me know as well, that would be appreciated.
I am sorry for the delay, being able to work on this lately has been limited and the change required was much larger than expected.

Thanks for your work! The beta release has fixed the original error for me.
However when I set HomeAssistant as the default agent, it responds with "Sorry, I couldn't understand that" even for things that it should be able to - and my logs then show this error:
No intents were loaded for language: *

It works for me and you're awesome and I love you.
@conorod1992 - I had to go to the 'integrations' page and delete my current fallback conversation agent and create another one.  After that it worked with Home Assistant Assist primary and home-llm secondary.
Works great!  @m50 please add a tip jar somewhere on your profile if you haven't already!

I had to go to the 'integrations' page and delete my current fallback conversation agent and create another one. After that it worked with Home Assistant Assist primary and home-llm secondary.

Ok, sounds similar to what I described here:

Note: You may need to go in and "Edit" the Fallback Conversation Agent and not change anything, just save the changes. I am not 100% sure.

Glad it worked, I will officially release it with a note in the patch notes to edit, and if that doesn't work, re-create the Fallback Conversation Agent.

I am on 2.0.0;
I reinstalled, Restarted, REmoved and re-added the integration.
I still get: Home Assistant failed with response: Sorry, I couldn't understand that  for basic requests


Clear selection?

When you have a selection of text, then click away blurring the component, then click back focusing the component again, the same selection remains. A second click must then be performed to clear the selection and place the cursor under the mouse.
This is bazaar and not the way textareas normally behave.
Normally when you blur a textarea, the selection is lost, and when you focus a textarea, the cursor is placed at the point in which you clicked.
I am trying recreate the normal textarea behavior and nothing I try seems to do the trick.
Since this only happens if there is a current selection. And it behaves correctly if there is no selection. My thought is to clear the selection on blur.
I have tried various combinations of using moveSelectionToEnd, and forceSelection and acceptSelection with SelectionState.createEmpty but nothing I try actually clears the selection. The previous selection is always there when I focus the component.
What is the appropriate way to clear the selection on blur and place the cursor at the correct spot on focus, the way a generic textarea behaves?

If you've found the solution to this, that'd be great. This is extremely unintuitive and I'd love to disable this on my inputs... not even Facebook nor Instagram does this with their inputs.

I think we may have a fix for this. Looking into it with @spicyj right now.

This was originally done to work around a different bug in Chrome actually:
https://github.com/facebook/draft-js/blob/9414ad5c9c8e07fc565257653d2318c260e355f8/src/component/handlers/edit/editOnFocus.js#L35
I just noticed the bug seems fixed in Canary though! I ran the Chrome bisect script and found this:
You are probably looking for a change made after 467121 (known bad), but no later than 467132 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/fbf6b2dedcd7bd30dd82cdfd768ee5279d309721..45c1839662be78d913edb5c87bfaf9abc66bd9e5

In particular it looks like https://chromium.googlesource.com/chromium/src/+/feafc2de2c3e515247b5f45ab9ac9a4139b6cd46 is the likely fix and is in Chrome 60.0.3081.0 which is scheduled to hit stable channel in August. I think we can switch that back to acceptSelection if we no longer need to work around the bug.

We are testing the change internally now, will land a fix on Github once we verify that it doesn't cause any problems.

Is there any update on this? I've just encountered the same exact problem.

I have a commit on the way that will add the fix under a feature flag, and we can do a follow-up to enable it by default. It looks like no issues have come up in our testing.

Hi thanks for the fix, do you have any idea when this fix will be released ?

The fix is under a Feature Flag here on master:
https://github.com/facebook/draft-js/blob/master/src/component/handlers/edit/editOnFocus.js#L37-L39
The comment there explains things.
We have been testing this internally, and need to decide if this is stable enough to make the default behavior.
I'll add it to the agenda for this week's Draft.js discussion. Thanks for checking in!

Another update - the fix seems to be stable in Chrome v60, and that should go out in a month or so. The release calendar is online here: https://www.chromium.org/developers/calendar

We have unflagged the fix internally and now on the master branch on Github, and so this will be fixed in the next release of Draft.js. See https://github.com/facebook/draft-js/commit/19b9b1c5007bcb3a4111ea31f8d9a8cda629a1ff
Thanks everyone for keeping this on the radar! :)

getting the same issue with Chrome Version 74.0.3729.169 (Official Build) (64-bit).
Can be easily reproduced on facebook.com

Hello, I have been working with this library for a few days and I have the same error, it is supposed to be fixed here, but I found that even on the official site this error persists, does anyone have any solution for this problem, thanks

I am still seeing this happen as well. Is there a way to programmatically clear the selection?


add insecure SMTP (protonmail)

Currently sending a test email via protonmail- bridge fails (and consequently email does not work), because kuma uses self-signed certificates.
Please allow additional options in SMTP settings to turn off SSL.
Depending on email client usually these settings need to be considered:
SYMFONY__ENV__MAILER_ENCRYPTION=null
or
DIUN_NOTIF_MAIL_SSL=false
DIUN_NOTIF_MAIL_INSECURESKIPVERIFY=true
Is proxy in front an answer too?

#19 is it related to your issue?

Commented in #19.
Yes, this takes care of it. Thanks.


Crashes often when switching to another VConsole on nixos

When i switch to another virtual console and then come back to hyprland, it often crashes, but not systematically, even with an empty config file.
I'm using the nixos package (not from nixpkgs but the flake of this repo) so i don't know if it is specific to nix or not (i can't figure out how to compile from source, i get the error  Cannot find source file: itab.c and don't know much about compiling C)
by the way, I tried launching from both greetd and a console, and get the same behavior, even when switching from one hyprland to another
Here is the crash report:
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
This was an accident, I swear!

Hyprland received signal 11 (Segmentation fault)

Version: cc01550aff70a0cbee5b62db5f4a08789244998f

System info:
	System name: Linux
	Node name: apollo
	Release: 6.3.1-zen1
	Version: #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan  1 00:00:00 UTC 1980

GPU:
	00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller])

os-release:
	BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
	BUILD_ID="23.05.20230506.897876e"
	DOCUMENTATION_URL="https://nixos.org/learn.html"
	HOME_URL="https://nixos.org/"
	ID=nixos
	LOGO="nix-snowflake"
	NAME=NixOS
	PRETTY_NAME="NixOS 23.05 (Stoat)"
	SUPPORT_URL="https://nixos.org/community.html"
	VERSION="23.05 (Stoat)"
	VERSION_CODENAME=stoat
	VERSION_ID="23.05"

Backtrace:
	#0 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x824) [0x56f264]
			#1 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_Z25handleUnrecoverableSignali+0x3f) [0x548edf]
			#2 | /nix/store/0z5kcds7b6qmm373s3b5w9ykvqbgw87i-glibc-2.37-8/lib/libc.so.6(+0x38d60) [0x7eff25a52d60]
			#3 | /nix/store/q59v4qicdn7idbxnnif16mks288l1xrq-libinput-1.23.0/lib/libinput.so.10(libinput_device_config_calibration_has_matrix+0) [0x7eff26464d10]
			#4 | /nix/store/q59v4qicdn7idbxnnif16mks288l1xrq-libinput-1.23.0/lib/libinput.so.10(libinput_device_config_calibration_set_matrix+0x11) [0x7eff26464d41]
			#5 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_ZN13CInputManager21setTouchDeviceConfigsEv+0x127) [0x4a4767]
			#6 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_ZN13CInputManager14newTouchDeviceEP16wlr_input_device+0x17c) [0x4acb1c]
			#7 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_ZN6Events17listener_newInputEP11wl_listenerPv+0x133) [0x4db5b3]
			#8 | /nix/store/jy6dg2nibz7lafac4x29nrrmpwhyhq23-wayland-1.22.0/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7c) [0x7eff2675fa0c]
			#9 | /nix/store/jy6dg2nibz7lafac4x29nrrmpwhyhq23-wayland-1.22.0/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7c) [0x7eff2675fa0c]
			#10 | /nix/store/9868immj1hcfifqy0hxqxw5wkngfxxih-wlroots-hyprland-2023-04-25_6830bfc/lib/libwlroots.so.12(+0x5abae) [0x7eff2669bbae]
			#11 | /nix/store/9868immj1hcfifqy0hxqxw5wkngfxxih-wlroots-hyprland-2023-04-25_6830bfc/lib/libwlroots.so.12(+0x59e5b) [0x7eff2669ae5b]
			#12 | /nix/store/jy6dg2nibz7lafac4x29nrrmpwhyhq23-wayland-1.22.0/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x7eff267618e2]
			#13 | /nix/store/jy6dg2nibz7lafac4x29nrrmpwhyhq23-wayland-1.22.0/lib/libwayland-server.so.0(wl_display_run+0x25) [0x7eff2675f445]
			#14 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(main+0x488) [0x46d438]
			#15 | /nix/store/0z5kcds7b6qmm373s3b5w9ykvqbgw87i-glibc-2.37-8/lib/libc.so.6(+0x23ace) [0x7eff25a3dace]
			#16 | /nix/store/0z5kcds7b6qmm373s3b5w9ykvqbgw87i-glibc-2.37-8/lib/libc.so.6(__libc_start_main+0x89) [0x7eff25a3db89]
			#17 | /nix/store/1xpdf32lbmqrbl5v7g3nc4nf8z9nhndk-hyprland-0.25.0+date=2023-05-12_cc01550/bin/Hyprland(_start+0x25) [0x47c605]

Log tail:
[LOG] Set the keyboard layout to fr, us and variant to , colemak_dh_iso for keyboard "SIGMACHIP Trust Keyboard System Control"
[LOG] New keyboard created, pointers Hypr: 26e1880 and WLR: 2798b28
[LOG] Attached a keyboard with name Logitech G502
[LOG] Registered signal for owner 28396e0: 252fd90 -> 28396e8 (owner: Keyboard)
[LOG] Registered signal for owner 28396e0: 252fd80 -> 2839750 (owner: Keyboard)
[LOG] Registered signal for owner 28396e0: 252fc60 -> 2839820 (owner: Keyboard)
[LOG] Registered signal for owner 28396e0: 252fda0 -> 28397b8 (owner: Keyboard)
[LOG] ApplyConfigToKeyboard for "logitech-g502", hasconfig: 0
[LOG] Attempting to create a keymap for layout fr, us with variant , colemak_dh_iso (rules: , model: , options: )
[LOG] Set the keyboard layout to fr, us and variant to , colemak_dh_iso for keyboard "Logitech G502"
[LOG] New keyboard created, pointers Hypr: 28396e0 and WLR: 252fc48
[LOG] Attached a mouse with name Logitech G502
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 2 (2)
[LOG] Applied config to mouse sigmachip-trust-keyboard-consumer-control-1, sens 0.00
[LOG] Applied config to mouse logitech-g502-1, sens 0.00
[LOG] Registered signal for owner 364e4c0: 252fde0 -> 364e580 (owner: Mouse)
[LOG] New mouse created, pointer WLR: 252fdc8
[LOG] Attached a keyboard with name USB PnP Audio Device
[LOG] Registered signal for owner 253f9c0: 253f5d0 -> 253f9c8 (owner: Keyboard)
[LOG] Registered signal for owner 253f9c0: 253f5c0 -> 253fa30 (owner: Keyboard)
[LOG] Registered signal for owner 253f9c0: 253f4a0 -> 253fb00 (owner: Keyboard)
[LOG] Registered signal for owner 253f9c0: 253f5e0 -> 253fa98 (owner: Keyboard)
[LOG] ApplyConfigToKeyboard for "usb-pnp-audio-device", hasconfig: 0
[LOG] Attempting to create a keymap for layout fr, us with variant , colemak_dh_iso (rules: , model: , options: )
[LOG] Set the keyboard layout to fr, us and variant to , colemak_dh_iso for keyboard "USB PnP Audio Device"
[LOG] New keyboard created, pointers Hypr: 253f9c0 and WLR: 253f488
[LOG] Attached a mouse with name MSFT0001:02 06CB:7F8F Mouse
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 2 (2)
[LOG] Applied config to mouse sigmachip-trust-keyboard-consumer-control-1, sens 0.00
[LOG] Applied config to mouse logitech-g502-1, sens 0.00
[LOG] Applied config to mouse msft0001:02-06cb:7f8f-mouse, sens 0.00
[LOG] Registered signal for owner 3642070: 24d0270 -> 3642130 (owner: Mouse)
[LOG] New mouse created, pointer WLR: 24d0258
[LOG] Attached a mouse with name MSFT0001:02 06CB:7F8F Touchpad
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 2 (2)
[LOG] Applied config to mouse sigmachip-trust-keyboard-consumer-control-1, sens 0.00
[LOG] Applied config to mouse logitech-g502-1, sens 0.00
[LOG] Applied config to mouse msft0001:02-06cb:7f8f-mouse, sens 0.00
[LOG] Applied config to mouse msft0001:02-06cb:7f8f-touchpad, sens 0.00
[LOG] Registered signal for owner 3651710: 24d0a10 -> 36517d0 (owner: Mouse)
[LOG] New mouse created, pointer WLR: 24d09f8
[LOG] Attached a tablet tool with name Wacom HID 50EE Pen
[LOG] Attaching tablet to cursor!
[LOG] Registered signal for owner 24737d0: 24d13c0 -> 2473970 (owner: Tablet)
[LOG] Registered signal for owner 24737d0: 24d13f0 -> 2473838 (owner: Tablet)
[LOG] Registered signal for owner 24737d0: 24d1410 -> 24737d0 (owner: Tablet)
[LOG] Registered signal for owner 24737d0: 24d1420 -> 24738a0 (owner: Tablet)
[LOG] Registered signal for owner 24737d0: 24d1400 -> 2473908 (owner: Tablet)
[LOG] Setting calibration matrix for device wacom-hid-50ee-pen
[LOG] Attached a touch device with name Wacom HID 50EE Finger

(@fufexan it seems i have to ping you for nix issues)

I don't know where the issue stems from, but to compile manually you can run this inside the cloned repo:
$ nix develop
$ meson setup build
$ ninja -C build

After it compiles, you can run Hyprland from within the build directory.

That's what i did (also tried with make all)
but i get this
| Building itab.c/itab.h...
| -- Configuring done
| CMake Error at libudis86/CMakeLists.txt:30 (add_library):
| Cannot find source file:

| itab.c

| Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
| .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc

| CMake Error at libudis86/CMakeLists.txt:30 (add_library):
| No SOURCES given to target: libudis86

I also tried with nix-shell -p udis86, same error

That will not work. You need to use the flake devshell, otherwise you're just making things hard for yourself.

Yes that's what i did, i ran nix develop first, then meson

should be fixed with 7c207243e41b5b4f35d790767ad2e21eba1b7a0b

Hmm it's still happening :(
hyprlandCrashReport7943.txt
I tried several times, and there is no consistency at all, sometimes i can switch to tty and back to hyprland up to 10 times to have a crash, and sometimes it happens the first time

what if you unplug your wacom

That's gonna be hard, since the "wacom" is actually the touch screen of my laptop... (lenovo yoga 720)

That's gonna be hard, since the "wacom" is actually the touch screen of my laptop... (lenovo yoga 720)
Is it possible as a workaround for the moment to disable the input from this device ? i rarely use the touchscreen, and even less the stylus

@MininuxDev you could try blacklisting the kernel module responsible for wacom, if there's any.

Thanks it worked, it was i2c_hid_acpi, and now that i unloaded it it works. But i don't know if it is the "finger" device or the "stylus" device that causes the issue (and i can't find how to disable only one of them, i don't have the stylus to test anyway), at least it is confirmed it's because of the wacom
Should i rename the issue accordingly ?

Still a thing?


Add link to your plugin from Reveal.js wiki

Added a link to your project on https://github.com/hakimel/reveal.js/wiki/Plugins,-Tools-and-Hardware in the tools section.

The Tools sections now looks like this :+1:
Tools

Useful tools for working with reveal.js.

    slides.com Visual editor for reveal.js, create presentations without knowing how to code.
    runnable.com Live editable example of the source code.
    prez Generate Reveal.js slideshows from a set of markdowns.
    deck2pdf Command-line tool for converting decks to PDF
    uncloak Reveal.js theme editor to tweak colors and font styles in a live GUI.
    cleaver Reveal-cleaver-theme enables you to easily create a very easy way reveal.js slideshow from a dummy markdown file.

Cool, thanks, I'm flattered :blush:


I suggest to Create .net's "Spring Framework" by Microsoft.

I suggest to Create .net's "Spring Framework" by Microsoft.
Because Dot Net Core Require Bussiness Framework to fly in the cloud world.
General
Provide Framework 、Interface and Implement document, and then Many coder to implement this.

Look into ASP.NET Core - it has many parts of similar framework and other goodies.


Add templates to var and vari

Summary
This is the first PR for static matrices which will actually be reviewed for merge. It creates var_value<T>, vari_value<T>, and vari_base classes templated with a type T. For backwards compatibility, aliases for var and vari are set as var_value<double> and vari_value<double>.

vari_value<T> inherits from vari_base, where vari_base is a virtual base class used in AutodiffStackSingleton's var_stack etc. This has some issues I'll discuss below. When T is an integral type (int, char, bool, size_t, etc), the val_ and adj_ in vari_value will be of type double since we want the types in vari to be floating point. vari_value<T> should now support any floating point type!

The definition of grad is now:

template <typename Vari>
static void grad(Vari* vi)

This is because in grad we call vi->init_dependent();. If we don't template grad then we need the argument type to be vari_base, which then requires that init_dependent is also a virtual function.

var_value<T> has type traits value_type and vari_type. For integral types value_type will be double and T otherwise. vari_type is defined as vari_value<value_type>. Constructors exist to make var_value<T> from var_value<S> and vari_value<S>* where the value_types of each class differ. Because a vari_value<Integral> type has the same representation as a vari_value<double> the constructor var_value(vari_value<S>*) pointer convertible T and S use a reinterpret_cast to avoid making a new copy.

var_value's operators are templated to support operations where the value_types for the operator argument's value_type can be converted to this's value_type. i.e.

template <typename S, require_convertible_t<S&, internal::floating_point_promoter<T>>* = nullptr>
inline var_value<T>& operator-=(const var_value<S>& b);

The value_type type trait now has a specialization for var_value so that it goes down one level and pulls out the value_type. This required going through and removing some instances of requires_vt_var.

The operators for var now have const var& arguments instead of var arguments (I found when adding vari_base there was a small noticeable difference in performance)

final was added to all the vari operator classes in core so that the compiler has a slightly better chance at allowing devirtualization when using the -flto flag.

Modified some definitions in std_iterator_traits.hpp  and std_numeric_limits.hpp so that they worked for any var_value<T> and conformed to the C++11 definitions.

added is_vari to check whether a type inherits from vari_base and changed the definition of is_var to check if the type is var_value<T>.

Tests
The main change in tests here is the ctor overloads tests for var. This now checks that the type of vari_value<T> and it's value is preserved for different floating point types and that integral types are still of type double.
Tests have also been added for is_vari and is_var to handle multiple template instantiations
Side Effects
Yes very much

Can we not make a copy for var_value<double>(new var_value<long double>(5.0))?

When we call something like
var_value<double>(var_value<long double>(2.0));

The vari_type of the object being constructed is vari_value<double> but the argument's vari_type is vari_value<long double>. This is setup right now to do a copy like
template <typename S, typename K = internal::floating_point_promoter<S>,
          require_not_vari_convertible_t<K>* = nullptr>
var_value(vari_value<S>* vi) : vi_(new vari_type(*vi)) {}  // NOLINT

This only applies to other floating point types since any integral type will actually have a value_type of double. It would be cool to not make a copy here though idk if that's possible.

set_zero_adjoint as a virtual function is bad

set_zero_adjoint is now a virtual function since we call set_zero_adjoint() from the elements in var_stack (which are vari_base objects). This is bad on multiple levels. Since a virtual function is a function pointer it increases the size of var_value<double> by 4 bytes (to 28 bytes) and cannot be inlined. Because our vari_value pointers go on a global stack gcc and clang will not by default ever try to devirtualize these functions (see here for more info). This regression effects the SIR model (and any model that uses the coupled_ode_system) and causes a performance regression of about 15% (yikes!!!). But! This regression can sometimes be mitigated by turning on full link time optimization in the compiler (-flto) and a few other compiler flags. On older compilers this trick will probably not work. If anyone has ideas on how to avoid having set_zero_adjoint as a virtual function I'm very very open to that. But otherwise I suggest that we turn on the -flto flag by default. We used to not be able to turn on flto because of some bugs in Eigen 3.3.3, (see  #1383) but since upgrading to Eigen 3.3.7 all of the performance tests pass when turning on flto.
The tests below use gcc-9 on linux with the "old results" (aka devleop branch) with flto turned off vs the "new result" (aka this branch) with and without the following flags enabled
-flto -fuse-linker-plugin -fdevirtualize-at-ltrans -fipa-pta
Without Flags

Name
Old Result
New Result
Ratio
Performance change( 1 - new / old )

gp_pois_regr
2.35
2.37
0.99
-0.74% slower

low_dim_corr_gauss
0.01
0.01
0.93
-8.06% slower

eight_schools
0.05
0.05
1.02
2.42% faster

arK
1.49
1.29
1.15
13.37% faster

irt_2pl
4.28
4.3
1.0
-0.44% slower

performance.compilation
69.52
65.61
1.06
5.62% faster

low_dim_gauss_mix_collapse
5.45
5.43
1.0
0.47% faster

pkpd
13.4
13.41
1.0
-0.09% slower

sir
71.02
80.85
0.88
-13.85% slower

pkpd
0.23
0.23
0.98
-2.44% slower

low_dim_gauss_mix
2.0
1.97
1.01
1.26% faster

gp_regr
0.1
0.1
1.01
1.15% faster

arma
0.35
0.35
0.99
-1.22% slower

gp_regr
0.03
0.03
1.05
5.16% faster

garch
0.34
0.34
1.0
0.46% faster

Mean result: 1.00547342208

With Flags
We can see that with flto the performance tests for sir fall within a reasonable margin of error (about 1%)

Name
Old Result
New Result
Ratio
Performance change( 1 - new / old )

gp_pois_regr
2.53
2.5
1.01
1.11% faster

low_dim_corr_gauss
0.01
0.01
0.95
-4.85% slower

eight_schools
0.05
0.05
0.99
-1.16% slower

arK
1.56
1.6
0.97
-2.8% slower

irt_2pl
4.7
4.74
0.99
-0.78% slower

performance.compilation
75.7
76.49
0.99
-1.04% slower

low_dim_gauss_mix_collapse
5.41
5.42
1.0
-0.26% slower

pkpd
13.78
14.05
0.98
-1.94% slower

sir
83.14
84.23
0.99
-1.31% slower

pkpd
0.22
0.23
0.98
-2.14% slower

low_dim_gauss_mix
2.0
2.05
0.98
-2.49% slower

gp_regr
0.1
0.11
0.98
-2.33% slower

arma
0.44
0.43
1.01
1.42% faster

gp_regr
0.03
0.03
0.99
-0.66% slower

garch
0.41
0.4
1.01
1.29% faster

Mean result: 0.988427908156

I'm going to run these for gcc-4.9 and clang 6 (or is our latest supported clang clang 7?). In order to check that this works we need to enable flto in compiler_flags for gcc and clang, then run the custom cmdstan performance jobs for windows, mac, and linux to see where these compiler flags help mitigate this virtual function issue.
Release notes
Add types var_value and vari_value so that autodiff can use multiple floating point types.
Checklist

[x] Math issue #1875

[x] Copyright holder: Steve Bronder
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
dependencies checks pass, (make test-math-dependencies)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

When T is an integral type (int, char, bool, size_t, etc), the val_ and adj_ in vari_value will be of type double

var_value<T> has type traits value_type and vari_type. For integral types value_type will be double and T otherwise. vari_type is defined as vari_value<value_type>. Constructors exist to make var_value<T> from var_value<S> and vari_value<S>* where the value_types of each class differ. Because a vari_value type has the same representation as a vari_value<double> the constructor var_value(vari_value<S>*) pointer convertible T and S use a reinterpret_cast to avoid making a new copy.

That seems quite weird to me. Would it not make more sense to have a requirement for T to be floating point type and just add constructor(s) for integral types?

The value_type type trait now has a specialization for var_value so that it goes down one level and pulls out the value_type. This required going through and removing some instances of requires_vt_var.

That is unfortunate. I think we should have two different type traits for getting scalar from container and a base type from autodiff type. Than we would not have such problems.

That seems quite weird to me. Would it not make more sense to have a requirement for T to be floating point type and just add constructor(s) for integral types?

That is much more sensible

The value_type type trait now has a specialization for var_value so that it goes down one level and pulls out the value_type. This required going through and removing some instances of requires_vt_var.

That is unfortunate. I think we should have two different type traits for getting scalar from container and a base type from autodiff type. Than we would not have such problems.

Yeah I was kind of confused on what to do here, because we said we want value_type to always go down one level in #1913 but I think what we really want it to do is stop at the least upper bound of {Arithmetic, var_value<T>, complex<T>}.

So this is just for getting a var_value vari_value that replace the current var and vari functionality, right? There's no var_value<Eigen::MatrixXd> stuff yet?

set_zero_adjoint is now a virtual function since we call

I wonder if another solution is another stack?
Like, chain() is really associated with operations, but set_zero_adjoints() is associated with values.
So the stuff on the chaining autodiff stack really is just a list of function calls that will do the adjoint^T * Jac operations.
set_zero_adjoints() is why we have to maintain the non-chaining varis stack. Any vari that doesn't represent an operation still needs its adjoint set to zero.
We could break this stack into two, one for vari* s and one for vari_base*.
So if we did:
std::vector<vari_base*> chain_vari_base; // stack for varis representing operations, used only by grad
std::vector<vari*> adj_vari; // stack for varis, used only by set_adjoints_zero()
std::vector<vari_base*> adj_vari_base; // stack for non-vari vari_base things, used only by set_adjoints_zero();
std::vector<vari_base*> allocating_varis; // for varis that need their delete operators called

And the constructors to everything can be written to put things in the right spot. Varis that get chained get put on the chain_vari_base stack as well as the appropriate adj_vari stack.
And then set_zero_adjoints is something like:
for(auto v : adj_vari) {
  v->set_adjoints_zero();
}
for(auto v : adj_vari_base) {
  v->set_adjoints_zero();
}

And only the second things do virtual function calls. Presumably this matters less, because anything that isn't a vari is presumably larger (and more time is spent assigning the adjoints themselves).
This spends more memory on vari* s, and adds a stack, but would be easier to control than LTO.

The issue here is another chain would only work for vari_value no?

Certainly one stack would only work for vari s, but there is another stack for everything else (vari s and vari_value<T> s push themselves onto the stack on construction, so they could put themselves in the right place).

I'm not sure I'm following here. I goofed my comment above which was to ask whether this would only work as an optimization for var_value<double>. imo if the flto stuff works here then I'm not sure we need to have another stack.

imo if the flto stuff works here then I'm not sure we need to have another stack.

If flto works everywhere and it's easy, yeah, we lean on all sorts of compiler optimizations so I don't see it as a problem either.
But the instant it got brought up there was a gotcha wrt Windows. I dunno about old/weird compilers or whatever easy.
Anyhow there's a way to just code around this. That's the argument for the 4th stack and then we don't have to do any compiler prayers etc. etc.

Anyhow there's a way to just code around this. That's the argument for the 4th stack and then we don't have to do any compiler prayers etc. etc.

What I'm getting confused by is, is this just an optimization for var_value<double>?

What I'm getting confused by is, is this just an optimization for var_value

Yeah, vari_value<double>. These are the types of things where the overhead is going to hurt the most.

I wonder if there is some way to use boost::variant here, since we know the types are going to be
vari_value<double>
vari_value<float>
vari_value<long double>

Then for Eigen we'd write out the Eigen::Matrix<Arithmetics, -1/1, -1/1> yadayada. It'd be kind of a bother but then we could do something like the example below
https://stackoverflow.com/a/41658696

It can be very high overhead to write functors over variant types.
Why do we need to explicitly enumerate the possible types in the code?  Why not allow anyhting that works with the operations, so we could support even more extended math, or even nest reverse in reverse.

@bob-carpenter The description of the problem starts under the section labeled "set_zero_adjoint as a virtual function is bad" in the pull description
Doing type-specific things to avoid virtual function calls starts here.
That's the background at least.

Since a virtual function is a function pointer it increases the size of var_value by 4 bytes (to 28 bytes) and cannot be inlined.

I'm a bit confused.  Any class with a virtual function gets a vtable pointer, but isn't that 8 bytes?  And there's only one for the class no matter how many virtual functions there are.  And isn't something like chain() going to have to remain virtual?
The rest of the argumnt about not inlining, etc. is correct.  So it's definitely better to make this non-virtual if possible, even if it means a few more instances get called.  Two stacks also makes sense.  It adds a bit of constant overhead to manage more stacks, but no big deal in the big autodiffs we really care about.

@serban-nicusor-toptal is this error a me thing for this PR? Or could this be something with the instance?
https://jenkins.mc-stan.org/job/Stan/job/downstream_tests/1652/consoleFull
[GNU C Compiler] Sleeping for 5 seconds due to JENKINS-32191...
[GNU C Compiler] Parsing console log (workspace: '/Users/Shared/Jenkins/gelman-group-mac/workspace/Stan_downstream_tests')
[GNU C Compiler] [-ERROR-] Can't resolve absolute paths for some files:
[GNU C Compiler] [-ERROR-] - /home/jenkins-slave/jenkins-slave-files/workspace/Stan_downstream_tests/src/stan/io/array_var_context.hpp
[GNU C Compiler] [-ERROR-] - /home/jenkins-slave/jenkins-slave-files/workspace/Stan_downstream_tests/src/stan/io/empty_var_context.hpp
[GNU C Compiler] [-ERROR-] - /home/jenkins-slave/jenkins-slave-

Hey, looks like a test failed: https://jenkins.mc-stan.org/blue/organizations/jenkins/Stan/detail/downstream_tests/1652/pipeline

Having some combinations we dont need is a price I am willing to pay for trait system making more sense.

I like this choice, too.  Rather than trying to tailor everything too tightly, just enable the right combinatorics.
For me, what I want to do is pull out the lowest level real type to make up the basis of a return type.

if promote_args_t gets a {var, double, complex} should the return type be complex<var>?

complex<var<double>>

And for {var<Matrix>, double, complex} what would be the return type?

var<Matrix<complex<double>>
The general idea is that promote_args_t should return the least type (in the assignability ordering) to which all of the contained types are assignable.
Building up a Stan type consists of either starting with an integer or real type.  Let's just look at real types here, as that's where the action is.  We first have a choice of underlying real type, either primitive, reverse mode, forward mode, nested forward in forward, and nested reverse in forward types:

R = double | var<double> | fvar<double> | fvar<fvar<double>> | fvar<var<double>>

The only assignability is of double to any other type.
There's then a choice of scalar, which can be either real or complex

S = R | complex<R>

Here, reals are assignable to complex.  And of course, assignment is transitive so that if A is assignable to B and B is assignable to C, then A is assignable to C.
Then there's the choice of basic shape:

B = S | vector<S> | row_vector<S> | matrix<S>

Here, assignability should be by covariance when container types match, so that containers of U are assignable to containers of V if U is assignable to V (e.g, vector<double> should be assignable to vector<var<double>> and to vector<complex<var<double>>>).
Then a choice of number of array dimensions (0 or more)

T = B | B[ ,* ]

Again, assignability is by covariance when array dimensions match (which we need to make happen in the language).
This should probably go in the doc somewhere!
All I've ever felt I needed for return types is something that takes an arbitrary type in and returns the underlying real type (in above notation, starts with T and returns R) You can see from APIs like std::complex that there's no way to actually anticipate a return type.  For example, in our densities, no matter what the inputs are, we extract all the underlying real types then join them (compute least uppper bound, i.e., least type to which they're all assignable).

Having some combinations we dont need is a price I am willing to pay for trait system making more sense.

I like this choice, too.  Rather than trying to tailor everything too tightly, just enable the right combinatorics.

I think we are all in agreement then at least enough for me to go make a PR for that stuff today

For me, what I want to do is pull out the lowest level real type to make up the basis of a return type.

if promote_args_t gets a {var, double, complex} should the return type be complex<var>?

complex<var<double>>

And for {var<Matrix>, double, complex} what would be the return type?

var<Matrix<complex<double>>

Cool! I'm not sure if promote_args_t can handle the case of sometimes having complex within the var and other times having it outside the var, we may have to do something special to account for that

A lot of very informative things I didn't inline

This should probably go in the doc somewhere!

Yes!!! That's very useful for thinking about the type trait levels we want to inspect. Though removing the condition that var only has a type double seems to complicated things a bit especially with the above promote_args_t switching complex to and fro and var_value<Matrix<double>>. But I think what I have below makes sense
So say we had basic primitives BP

BP = double | float | long double

These are just the lowest level primitives we can use that have assignability from each other. And then "primitives" P

P =  BP | complex<BP>

where all BP can be assigned to complex<BP>. We'll assume for the rest of this that any A has a valid assignment operator B<A> = A. For containers this would be like B<A> = replicate(A);
So now we get to our real types

R = P | var<P> | fvar<R | P>

Same thing as what you had with a slight redefinition. var just accepts P because idt we ever want var<var<double>>
Though a little weird to think of complex<var<complex<double>>> we'll leave S the same

S = R | complex<R>

Now we will do something odd and have containers C as

C = S | Container<S> | var<Container<S>> | fvar<Container<S>>

I think this can still use the assignability by covariance since we can do stuff like var<Matrix<double>> = Matrix<double>. Though it's weird because now we think of var sort of as a container and as a real type. but imo that feels like what we want
Then dimensions

T = C | C[ ,* ]

So thinking about this, maybe we need the following type traits that stop at the lub of each level
container_type -> C
scalar_type -> S
real_type -> R
base_type -> P
base_primites -> BP

And recursive versions of those as well. That's way more than we need but I'd rather have more than less. And worse case the ones we don't use we can just toss out or they will be ignored

All I've ever felt I needed for return types is something that takes an arbitrary type in and returns the underlying real type (in above notation, starts with T and returns R) You can see from APIs like std::complex that there's no way to actually anticipate a return type.  For example, in our densities, no matter what the inputs are, we extract all the underlying real types then join them (compute least upper bound, i.e., least type to which they're all assignable).

So for thinking about containers in var it seems like we need to traverse this hierachy to get the end result of something like
 return_type<{var<Matrix<double>>, double, complex<double>}> = `var<Matrix<complex<double>>`

We would need something that extracts the container type var<Matrix<S>> and then searches the types for the scalar type so we end up with var<Matrix<complex<double>>>

sometimes having complex within the var and other times having it outside the var

Won't we also still have Matrix<var<double>> (what we have now) as well as var<Matrix<double>> (for immutable matrices)?  Only the latter will be really inefficient for some applications.
I don't like complex<var> coming out.  It could actually work as far as type instantiation goes, so maybe it's not so bad.  It's just a complex number where the value type is complex (and autodiff).

Won't we also still have Matrix<var> (what we have now) as well as var<Matrix> (for immutable matrices)? Only the latter will be really inefficient for some applications.

Yep!

I don't like complex coming out. It could actually work as far as type instantiation goes, so maybe it's not so bad. It's just a complex number where the value type is complex (and autodiff).

Yes I think we can make that work. Might take a little elbow grease but certainly possible

I agree with what @bob-carpenter said with return types.
Specifically there's some incorrectness in the adj_jac_apply stuff here.
For the multiply matrix by scalar op, the matrix part can actually be an Eigen::VectorXd, an Eigen::RowVectorXd, or an Eigen::MatrixXd.
Right now I just take in a derived type and always return an Eigen::MatrixXd:
template <std::size_t size, typename Derived>
  Eigen::MatrixXd operator()(const std::array<bool, size>& needs_adj,
			     const Eigen::MatrixBase<Derived>& x,
			     double b)

And the result of this is that in the chain I need to accept adjoints that have a different type than what came in:
template <int R1, int C1, int R2, int C2>
  inline void accumulate_adjoints_in_varis_impl
  (vari_value<Eigen::Matrix<double, R1, C1>> *vi, const Eigen::Matrix<double, R2, C2>& y_adj_jac) {
    if(y_adj_jac.size() > 0)
      vi->adj_ += y_adj_jac;
}

I don't know how much of a problem this is, but I could imagine it results in some unnecessary copying or something.
A return_type_t that did something like:
VectorXd, scalar -> VectorXd
RowVectorXd, scalar -> RowVectorXd
MatrixXd, scalar -> MatrixXd

Would be nice. If we have a weird return type that return_type_t doesn't work for, then I think the pattern is just: WeirdReturnType<scalar_type_t<return_type_t<T_args...>>>.
I don't know how to write this for Eigen::Derived types since the underlying thing could be any manner of wild types (in this case we're getting Eigen::Map objects from the var_value<MatrixXd> types).

Oh yeah the simple solution to the input/output argument type situation does not work. By simple I mean this:
template <std::size_t size, int R, int C>
  Eigen::Matrix<double, R, C> operator()(const std::array<bool, size>& needs_adj,
			     const Eigen::Matrix<double, R, C>& x,
			     double b)

It doesn't work because x needs to accept Eigen::Map objects from var_value<Eigen::Matrix<double, R, C>> inputs.

Oh another thing, I like the two type traits over here.
require_scalar_t<T> will allow anything where T is the same type as scalar_type_t<T>. This isn't the same as require_stan_scalar_t<T> for some reason that I forget (presumably I wouldn't have written this if they were the same). I think it was more than require_stan_scalar_t specifically looks for var, double, and int types.
require_matrix_t<T> should allow anything that could be a matrix (the list of which is expanding in Stan lol). So that would beEigen::Matrix<double, R, C>, Eigen::Map values, Eigen::Expressions, any Eigen object filled with vars or any other autodiff type, or a var_value of any  Eigen::Matrix<double, R, C> type.

@SteveBronder I think get rid of the P level. We don't define var<std::complex> or fvar<std::complex> on the R level. Complex defined on the S level makes sense.
Also get rid of fvar<Container<S>> because we don't have that defined yet. Otherwise this looks good.

it seems like we need to traverse this hierachy to get the end result of something like

The thing that isn't clear to me from this is what we want to happen if we have std::vector inputs.
My personal preference is that we handle this with traditional C++ery:
template <typename T, typename R>
auto myfunc(const std::vector<T>& vec, const R& arg) {
  ...
  return return_type_t<T, R>(...);
}

as compared to type traits for extracting std::vector types:
template <typename V, typename R>
auto myfunc(const V& vec, const R& arg) {
  ...
  using T = get_std_vector_t<V>;
  return return_type_t<T, R>(...);
}

or type traits that see through std::vector types:
template <typename V, typename R>
auto myfunc(const V& vec, const R& arg) {
  ...
  return return_type_t<V, R>(...);
}

I think it's fine to be explicit about std::vector types here because the old stuff works fine. There aren't ambiguities like we have with Matrix types (expressions vs. values vs. maps).
And then the question is back to what to do with std::vector types. We could just error I suppose and not allow them? I don't suppose we can do compile time asserts because SFINAE.

I don't know how to write this for Eigen::Derived types since the underlying thing could be any manner of wild types (in this case we're getting Eigen::Map objects from the var_value types).

plain_type_t might help for this.

It doesn't work because x needs to accept Eigen::Map objects from var_value<Eigen::Matrix<double, R, C>> inputs.

Use templates and require to restrict to eigen types.

or type traits that see through std::vector types:

I prefere this option - we have ~10 traits that will need to handle this. This is simple than separate overloads for hudereds of functions.

Reading over all this I realized that the actual thing here is that we just need to get rid of require_vt_var style requires. So like there's two roads here

Rewrite the entire type traits system
remove the require_vt_* requires

imo I'd much rather just do (2) is there any reason we absolutely have to do (1)?

Also it feels like the type traits convo has gotten to the point it needs a design doc as I'm confused on a few fronts on what we want. I just wanted specialized value_type style type traits but it seems like there is something else now as well?

I just wanted specialized value_type style type traits but it seems like there is something else now as well?

In my mind templating in Stan used to be:
template <typename T1, typename T2, typename T3, int R, int C>
auto myfunc(const Eigen::Matrix<T1, R, C>& arg1, const std::vector<T2>& arg2, T3 arg3) {
  ...
  return SomeStructure<return_type_t<T1, T2, T3>>(...);
}

So T1, T2, and T3 were all expected to be scalar types (in the math sense) and return_type_t figured out if the return scalar should be a var or not. value_of got us the non-autodiff version of whatever the input argument was.
The most exotic type trait was checking if any of T1, T2, or T3 were vars if this was a reverse mode specialization.
Now we need to deal with matrices that are bunches of different things, and so we can no longer lean on the type deduction around Eigen::MatrixXd<T, R, C>, which means moving to more exotic function definitions that look more like:
template <typename T1, typename T2, typename T3,
          require_matrix_t<T1>...>
auto myfunc(const T1& arg1, const std::vector<T2>& arg2, T3 arg3) {
  ...
  return return_type_t<T1, T2, T3>(...);
}

And since T1 is no longer a scalar type return_type_t (or how we use it) needs adjusted as well.

Sure, but I'm not following why this conversation needs to be in this PR?

I have comments about this, but I think this PR is getting very side tracked

I looked briefly at various places to put my responses, and I thought Bob's comments from yesterday were the most relevant, so I put my response near it.

We're introducing the type traits changes because of the var_value<T> design doc which this pull request is part of. It's on topic here as much as anywhere, though I am having trouble tracking the conversation across all the different pull requests and whatnot.

We're introducing the type traits changes because of the var_value design doc which this pull request is part of.

At one point I brought the convo from #1913 over here because I thought we would have to do all this type trait stuff for this PR to work so I'm the one that side tracked the PR in the first place. But last night I realized this PR just needs to to remove the require_vt_var style requires. And idt the var<eigen> pr will need anything beyond another type trait to inspect the value_type of a var and vari_type of vars.

It's on topic here as much as anywhere, though I am having trouble tracking the conversation across all the different pull requests and whatnot.

Yes I agree but having one large PR with everything and all the conversations is hard as well because then you have a bunch of out of order conversation as one person replies to one comment and another person replies to another in a different conversation.

At one point I brought the convo from #1913 over here

I guess this is inception pull requests. We keep making a new world to talk about type traits and then end up branching to a new world to talk about type traits.

lol yeah there's a lot of intertwined minutia! But I think we can hold off on the value_type conversation till after this PR. Once we start more seriously working on the var<Eigen> stuff it should become apparent whether or not that stuff will break

@bbbales2 would you mind giving this a review? It passed tests locally so should be good to go

I've double-checked and found out that the custom branch wasn't following cmdstan develop and was referencing an old hash.
Refactored to ensure that now, before any build it makes sure we're always on the latest develop hash.
I've started a new job that should work as it should. Cmdstan pointer got updated and points to the correct hash.

Much appreciated!

Yeah I'll go through this later today.

@serban-nicusor-toptal is the windows box down rn? Getting this error on the downstream tests
https://jenkins.mc-stan.org/blue/organizations/jenkins/Stan/detail/downstream_tests/1688/pipeline
Recording test results
Remote call on JNLP4-connect connection from <IP_ADDRESS>/<IP_ADDRESS>:49677 failed
Remote call on JNLP4-connect connection from <IP_ADDRESS>/<IP_ADDRESS>:49677 failed

Hey @SteveBronder seems like one instance went down during the execution of the tests. A new agent is spinning up and will resume the build. I Will let you know when it's done. Sorry for the inconvenience.

Ugh so I went down such a rabbit hole with this. idt we can get rid of the performance costs without using flto.
For a refresher, the whole issue here is that we need to be able to reset all of the adjoints to zero in between .grad() calls. Currently that involves going over the var_stack_ and var_nochain_stack_ and calling the set_zero_adjoint() member function of each vari type.
At first this PR set the var_stack_  and var_nochain_stack_ to hold a type of vari_base that vari_value<T> is derived from. But with the var_stack_ and var_nochain_stack_ holding a vari_base that set_zero_adjoint() member function has to be virtual. This low down in Stan, virtual functions have a pretty considerable cost (for SIR it's about a 20% regression). I've played with about 5 different ways to handle this, right now this code is setup to use a var_stack_ that's an std::vector<vari_base*> and a var_zeroing_stack_ that is a tuple of vectors of specific vari types.
std::tuple<std::vector<vari_value<double>*>,
                                  std::vector<vari_value<float>*>,
                                  std::vector<vari_value<long double>*>>

Then adjoints are reset to zero by running over each element of the tuple with a for_each function
static in void set_zero_all_adjoints() {
  for (auto& xx : ChainableStack::instance_->var_stack_) {
    xx->set_zero_adjoint();
  }
  // these are just the no chain stacks
  for_each(
      [](auto& x) {
        for (auto& xx : x) {
          xx->set_zero_adjoint();
        }
      },
      ChainableStack::instance_->var_zeroing_stacks_);
}

This style avoids the virtual call but this really doesn't fix the slowdown on sir, I think it just ends up trading off complexity in a different way.
tbh I think we should just go back to the plain virtual method style and use flto to optimize those out. I have a branch with the flto stuff, but the issue is that gcc 4.9.3 and clang 6 both need special archivers (gcc-ar and llvm-ar respectively). If we want to continue supporting both of those compilers we need a way to tell if the user is using either of them and then either turn flto off or find whether they have the correct ar tool. @bgoodri do you know what adoption is looking like for Rtool 4.0? Since that comes with gcc-8 people with Rtool 4.0 don't need anything special to turn on flto.
Also why do we support clang 6 still? Is there an OS that still uses it as the default? I think macs are onto 7 at this point, even our old imac machine runs clang 7 by default.

Also with the virtual method style we can also add compiler flags like the below for gcc 4.9.3+ which totally remove the slowdown as well without flto
-fweb -fivopts -ftree-loop-linear -fstrict-aliasing -funroll-loops -floop-block -floop-nest-optimize

We could include these here in stan math or leave it to cmdstan/rstan/pystan to include them

@bgoodri do you know what adoption is looking like for Rtool 4.0? Since that comes with gcc-8 people with Rtool 4.0 don't need anything special to turn on flto.

LTO was never working with Stan / RTools35 on Windows (it worked great on Mac and Linux). Having RTools40 makes it easier to turn LTO on and it has a more mature implementation, but you get linker errors from Boost on Windows. If we can get those worked around, then IMHO it is fine if R 3.x users on Windows get slowed down ~20% in some cases.

I think it just ends up trading off complexity in a different way.

RIP time -- let's go back then.
Out of curiosity, is LTO + any of the new variants faster than polymorphism + LTO?

But with the var_stack_ and var_nochain_stack_ holding a vari_base that set_zero_adjoint() member function has to be virtual.

Yes, and I have to fight the urge to think CRTP can fix this.  I've lost a lot of time thinking about this specific problem.

-fweb -fivopts -ftree-loop-linear -fstrict-aliasing -funroll-loops -floop-block -floop-nest-optimize

Should we be using some of these any way?  I'd want to make sure things like strict-aliasing are safe, but otherwise, nothing looks dangerous here.  Does it take a lot more compile time?

Also with the virtual method style we can also add compiler flags like the below for gcc 4.9.3+ which totally remove the slowdown as well without flto

Actually I reread that. Are they figuring out how to handle the polymorphism better? Or is this optimizing something somewhere else in the code?

Yes, and I have to fight the urge to think CRTP can fix this. I've lost a lot of time thinking about this specific problem.

I tried thinking about how we could so some CRTP trickey because at the end of the day we really do know what types we are adding to the stack! The main issue for me is that the stacks are defined as std::vector<vari_base*> and ChainableStack is
using ChainableStack = AutodiffStackSingleton<vari_base, chainable_alloc>;

The stacks are vectors so they need to hold a specific type. I think any other method of doing this either via CRTP or something else would either need a heterogenous container or to throw away the whole stack and do something where each var knows the vari/var it's derived from and we go up the expression tree through grad(). Enoki does do something like this, but there stuff is very complex. I wish they had speed tests as I'd be pretty interested in seeing how their graph simplification and reverse mode hold up

Should we be using some of these any way? I'd want to make sure things like strict-aliasing are safe, but otherwise, nothing looks dangerous here.

Maybe we could have like an optimize option that would add these flags. I'd run all the performance tests through build-scan and they seem safe. Though -fstrict-vtable-pointer in clang++ can throw because of something I think in sundials.

Does it take a lot more compile time?

I never looked but can check

Actually I reread that. Are they figuring out how to handle the polymorphism better? Or is this optimizing something somewhere else in the code?

I didn't look at the assembly for the models. It's possible/probable they are optimizing in other places that make up for the virtual function call cost

@bgoodri could you send me a link to an issue somewhere about the flto and boost thing? I can find some time to write a patch for that though my google-fu is failing me atm

I didn't look at the assembly for the models. It's possible/probable they are optimizing in other places that make up for the virtual function call cost

I don't think it's worth the time to investigate. Let's just stack up these compiler flags and roll with that.

@bbbales2 @t4c1 can you give this another look over? I think everything should be good to go at this point

The implementation looks good. I didn't really inspect the comments or tests (or benchmark it, since that's been an outstanding issue here).

I think everything should be good to go at this point

Yeah I think once comments/tests/performance are double checked this would be good to merge, but that'll wait on the matrix stuff downstream anyway. So I'm happy to leave this and line those pulls up to this unless you want the comments/test/performance stuff outta the way now.
Either way I'm mostly AFK until Tuesday (moving) so probably slow to respond.

Yeah I think once comments/tests/performance are double checked this would be good to merge, but that'll wait on the matrix stuff downstream anyway

We talked about this in the Math meeting, and the vague plan was to try to merge this into Math after 2.24 if it looks like it will be possible to finish one of the following pulls (static matrices or sparse matrices) by 2.25.

We talked about this in the Math meeting, and the vague plan was to try to merge this into Math after 2.24 if it looks like it will be possible to finish one of the following pulls (static matrices or sparse matrices) by 2.25.

Yes I think that's the best thing. It gives math and upstream a full release to test out flto stuff as well
If people ever want to take a stab at optimizing this I have a godbolt with everything here
https://godbolt.org/z/knDvui
Though it will only generate the assembly since static linking of libraries is not supported by godbolt
https://github.com/compiler-explorer/compiler-explorer/issues/1475

If you try to create a heterogeneous container, say of pointers, then you just push the dereferencing cost to there.  If you think there's a way to get around that, I'd love to hear about it no matter how complex it is.  I can imagine some really complex variant type thing might work if the set of types that go on the stack is a known finite set.

If you try to create a heterogeneous container, say of pointers, then you just push the dereferencing cost to there. If you think there's a way to get around that, I'd love to hear about it no matter how complex it is. I can imagine some really complex variant type thing might work if the set of types that go on the stack is a known finite set.

The variant has the same issue where you end up hitting a function lookup table which is similar to the virtual method.
Let me brew on this, I'm still reading through the Enoki code, which is pretty confusing but is interesting

The variant has the same issue where you end up hitting a function lookup table which is similar to the virtual method.

D'oh.  Of course it does.  No free pointer chasing just because it's buried where you can't see it!

Uhm... I have only loosely following along such that my comment may be off. What always worries me when seeing the performance reports is the super slow SIR example which is due to the rapid evaluation of a Jacobian. This hits the weak point of this implementation of requiring a virtual function call for set_zero_adjoint... which is supposed to be remedied by the use of lto compile time optimisation as I understand.
Would it be possible to enable these optimisations for the performance benchmarks so that we do not see any more these nasty slowdowns?
Also: Is there any hope that we can remedy the SIR case? I mean, this use case is a repeated Jacobian calculation; if it would be possible to store the adjoints on a contiguous chunk of memory, then we could simply zero that chunk of memory (given one knows where to start and stop zeroing, just like we know that for nested parts of the AD tape). Has this train of thought already followed?
Don't waste time on these suggestions if these are really not tailored to this; just some food for thought.

Would it be possible to enable these optimisations for the performance benchmarks so that we do not see any more these nasty slowdowns?

So I'm able to get flto working on the gelman mac, it needs to know that it has access to llvm-ar since it uses clang-6 which is the last version to need llvm-ar (and it uses a custom CXX flag). But for some reason when I had flto all setup on this branch when Jenkins would use that mac it would fail. I need to dive in and figure out what's going on in the Jenkins instance

Also: Is there any hope that we can remedy the SIR case? I mean, this use case is a repeated Jacobian calculation; if it would be possible to store the adjoints on a contiguous chunk of memory, then we could simply zero that chunk of memory (given one knows where to start and stop zeroing, just like we know that for nested parts of the AD tape). Has this train of thought already followed?

I never thought of that! Do we have a way to know where to start and stop zeroing?

(I'm not terribly familiar with the diffeq solver part of stan math)

if it would be possible to store the adjoints on a contiguous chunk of memory

If the vari were contiguous, then we could do it efficiently by zeroing every other element.  But there's no way to guarantee contiguity.

If the vari were contiguous, then we could do it efficiently by zeroing every other element. But there's no way to guarantee contiguity.

Yup, that's what I have in mind. Maybe there is a way to make the adjoints contiguously saved? We anyway throw a lot of stuff into the air. The thought is that we linearly allocate the memory for things that go with Vari's. Thus, the memory in a nested block can be tracked (which is what we do when recovering nested memory). Why not do the same for adjoints?

Maybe there is a way to make the adjoints contiguously saved?

I don't think this is so easy, but would be very happy if you could figure out how to do it.

As I understand it there are still the --lto things to figure out. What was the plan on that?

I've been thinking about where to put the flto flag. One issue is that if we set flto to be on by default and someone is using clang++ <= 6 or gcc < 5.0 then they have to also specify the AR makevar variable to be ar-gcc or ar-clang. And if someone is using Rtools < 4 we can't use flto because their version of gcc has a broken flto implementation.  And we can't drop gcc 4.9.3 support till CRAN also drops it.
It's actually kind of hard to detect what compiler version someone is using (for instance calling gcc in mac actually calls clang by default!). @bgoodri would know more than I, but I think it would be easier to figure out the compiler version in R/Python and set the flags there in the packages makevars. We can also suggest to the user flags they can turn on. For instance we could have a function stan_makevar_setup() that looks at the compiler and OS version and adds flags like the ones I have here

Yeah, we can check whether the R version is >= 4 on Windows, which would
imply RTools40. However, LTO is still causing multiple definition errors
from Boost.
On Mon, Jul 20, 2020 at 7:01 PM Ben Bales<EMAIL_ADDRESS>wrote:

Can we always specify the AR makeflag to be ar-gcc or ar-clang?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/1915#issuecomment-661414087, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZ2XKXVJIVCKLKUOTYVGL3R4TEFLANCNFSM4NOP32GA
.

However, LTO is still causing multiple definition errors
from Boost.

Is that just on windows or everywhere?

@SteveBronder I remember at some point you added a bunch of flags to something without lto and it was also as fast as it was previously. Is that an option?

Just Windows
On Mon, Jul 20, 2020, 10:06 PM Steve Bronder<EMAIL_ADDRESS>wrote:

However, LTO is still causing multiple definition errors
from Boost.
Is that just on windows or everywhere?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/1915#issuecomment-661560593, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZ2XKQYQVAHTDY3V62KHSLR4TZ3VANCNFSM4NOP32GA
.

@SteveBronder I remember at some point you added a bunch of flags to something without lto and it was also as fast as it was previously. Is that an option?

Yes (the ones from here) tho' those are only for gcc. clang-6.0 is, limited in functionality. I've found that turning on some compiler passes can even lead to clang-6.0 segfaulting

Is the release freeze over? aka once these tests pass is this good to finally merge?

Hey Steve, the feature freeze is over. Tagging @rok-cesnovar just to be entirely sure.

I think so.
Is squishing gonna confuse the other branches?

Is squishing gonna confuse the other branches?

Hmm, yeah it might. We can either:

Merge all those branches down into this one
Not squish this branch
Squish this branch and rebase the other ones

(3) is annoying but doable. I think for (1) I just squished #1967 (matrix_cl) into #1952 (eigen). We could wait till we approve #1970 (operands_and_partials) and then merge that to #1952 (eigen). Then if all that is approved we can merge #1952 (eigen) into this branch and then squash and merge this branch in

(2) I'd rather not do because this branch also has all the commits where I tried all the other ways to do this and is going to put a lot of stuff we don't really care about on the commit log

Can you try 3 locally and see how difficult the rebase/merge/whatever you do is and report back? If it's easy that sounds like what we want.

tbh I think the hassle of (3) is not worth it. I'll handle the rebase of the other two branches and we can squash this one.
@t4c1 and @bbbales2 can yinz approve so we can rock and roll?

Word, done!

Sorry I missed that you tagged me. Yes feature freeze is over as Ben said. Lets get this static adjapply party started :)

Let's do it!


Flutter web dropdown not suggesting item when i type keyboard keys.

I used dropdown list in flutter web,
after opening dowpdown when I type any character on keyboard, it should suggest item based on typing characters.

Hi @Dhana2513
I am not sure just a dropdown list suppose to provide suggestion?
can you please provide your flutter doctor -v and flutter run -d Chrome --verbose?
Also, to better address the issue, would be helpful
if you could post a minimal code sample to reproduce the problem
Thank you

I came here to open this same issue.
On web, it is expected that when you are filling a form and there is a dropdown, that you can type and get the item that matches what you type.
I don't think this is a bug but a feature request.

@jlubeck
Thanks for clarifying

Deduplicating with https://github.com/flutter/flutter/issues/46824

@yjbanov why did you close this ticket? Not sure what you meant by "deduplicating", but this is definitely not a duplicate of that ticket


Run Virus Faild,Show:"pyi_rth_certifi",Like zhe pictrue

Compile the payload with “-t python” without the quotes. Then run the payload as a Python file and send me an error message or a screenshot

there is no -t option


How to set color of dialog(dark mode)?

I want to set color of dialog at light and dark mode
How to do this?

Hello, you just have to provide the different theme, in this case, the dark theme. Simply wrap the views, dialogs, popups, etc., into the theme, as you would normally do when supporting a dark theme in your app.


Persona 3: Dancing in Moonlight (PCSE01274) Stage Finish Error

App summary

App name: Persona 3: Dancing in Moonlight
App serial: PCSE01274
App version: 1.00

Vita3K summary

Version: v0.16
Build number: 3002
Commit hash: https://github.com/vita3k/vita3k/commit/4dfc3911
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: ?
OS: Windows 11
CPU: AMD
GPU: NVIDIA
RAM: 16 GB

Issues
When I try to finish a stage, a whole bunch of misses pop up right as the song fades out.
Screenshots
https://imgur.com/gallery/pn2vJtQ

refer to updating the report in https://github.com/Vita3K/compatibility/issues/316. only one issue per title id should be open

refer to updating the report in #316. only one issue per title id should be open

Sorry about that, will do.


IE 9 assigns width and height attribute after src change

Similar to what's being described here: https://github.com/mootools/mootools-core/issues/2129
Assigning a value (width: auto or height: auto) in css appears to alleviate the issue.

I feel like we sorted this one out a while back, yeah @aFarkas? Please reopen if not.


atproto firehose throws errors

When trying to connect to the firehose and read some events from it, I sometimes get errors, which look for me like this:
#<Faye::WebSocket::API::ErrorEvent:0x0000000106d44318>

This is even after I started receiving some data - events are coming, then they stop, nothing happens for a bit, and then error, maybe more errors, and then after a while it continues printing events.
I inspected the details of the error, and it looks like the server is sometimes returning status 502:
@message="Error during WebSocket handshake: Unexpected response code: 502",
@pathname="/xrpc/com.atproto.sync.subscribeRepos?cursor=124415",
@status=502

@headers={
      "content-type"=>"text/html; charset=UTF-8",
      "referrer-policy"=>"no-referrer",
      "content-length"=>"332",
      "date"=>"Fri, 17 May 2024 20:35:11 GMT",
      "connection"=>"close"
    },

@buffer="\n\n<meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\">\n<title>502 Server Error</title>\n\n\n
Error: Server Error
\n
The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds.
\n

\n\n"

Ugh, thanks, not ideal. Will look.

I've made some significant infra improvements over the last couple days, including to the (outgoing) firehose's stability. I'm not seeing it serve these 502s any more. @mackuba hopefully you're seeing the same thing now?

Hmm! That's surprising. My logs show that BF was serving them pretty consistently for a while, but they stopped altogether a few days ago. The last time I see that we served a 502 to `subscribeRepos was 5/21 07:39:04 UTC.

Could it be served by something before your app (Nginx or whatever) when it can't get a response from your app?

Yup, definitely. It currently restarts about once a day (for reasons 😐), and any open connections when that happens get 502ed. Looks like you caught it at one of those restarts. Try again? Apart from those, it's not serving many/any other 502s as far as I can tell.

Hmm… looks good at the moment, but I'll try a few more times at different times :)

Btw, what's the buffer size for your firehose? It looks like it goes back <24h?

5000 seqs, but now that it's behaving better I should probably drop that limit and allow full history.

Hi again! I fixed #1091 today, which should stop the daily restarts, so I think these 502 errors should be fully gone now. Websocket subscriptions will still close with HTTP 101 after 1 hour, but that seems reasonable, clients should hopefully handle that and reconnect ok.
Let me know if you still see this problem!


fix: patient get contact phone numbers / email

Hi @staffoleo! Thanks for the PR.
Would you have an example of an HPD resource that would have 0, 2 or more colons in its telecom?

We are expecting the telecom as a URI because that's what HL7v3 requires: see URL and TEL in https://www.hl7.org/documentcenter/public/wg/inm/datatypes-its-xml20050714.htm#dtimpl-URL
Your real case scenario is invalid, but we could make an extra effort to detect common formats of email addresses and phone numbers.

discussion: detect email (@ symbol) otherwise don't set the system type

@staffoleo could you update the changelog too? https://github.com/i4mi/MobileAccessGateway/blob/master/docs/changelog.md


docs: improve smv_released_pattern section

It says Everything except master branch, so, it should include tags.
The colon in the negative regex match was probably a typo, as it prevents matching of the master branch. With that colon, none of the refs in my repo match and hence all refs are treated as not-released.
The example sed-s away the refs/ prefix, but, it seems like smv_released_pattern is evaluated against the full refspec, i.e., with refs/. Avoid the confusion, or, fix the docs, respectively.

fixes https://github.com/Holzhaus/sphinx-multiversion/issues/66

Thanks!


Chore #139349607 cover test

What does this PR do?
Implement all the changes requested by facilitator
Description of Task to be completed?
Setup a check to prevent users to create the same documents twice
How should this be manually tested?
clone the repository, do an npm install in the root directory and then npm start` to start the api
What are the relevant pivotal tracker stories?
#139349607 Refactor code based on checkpoint defence feedback

Coverage remained the same at 92.857% when pulling c5ecf30f7e48a1941835e25f50bd6b47f351c20b on chore/139349607/cover-test into 9262feabf081f622b780c6e2daf337433439eec3 on development.