refactor: remove aspect_rules_js.npm. repo-name logic

This seems unused now?

Type of change

Refactor (a code change that neither fixes a bug or adds a new feature)

Test plan

Covered by existing test cases

Hmm.. This was added when bzlmod was first added and it was needed at the time. Maybe that was in Bazel 6 and things changed in Bazel 7.

Looks like this repository name format dates back to the early days of bzlmod. This no longer applies.


Propagate log of Categorical distribution parameters?

@bartvanerp

We now propagate vectors with elements in [0, 1], but what if we would instead propagate the log of these elements for better robustness? I think this might also get rid of having to clamp the variables.

@bartvanerp  https://github.com/cjdoris/LogarithmicNumbers.jl

Seems interesting, thanks for sharing!

https://github.com/biaslab/RxInfer.jl/issues/94


[BEAM-11105] Add docs + CHANGES.md entry for Go Watermark Estimation

Now that all work required for watermark estimation has been added, we can update the docs + changelog to let people know how to use it!
Completed prs - #17267, #17374, #17475, #17476 (technically #17476 isn't in as of the publishing of this PR, but it has an LGTM pending fixed merge conflicts
Associated design doc - https://docs.google.com/document/d/1DqCYJ-J1YGNelCRIcN5v6BQsZxJB2l5uWBmN4ti--Ew/edit?usp=sharing

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

R: @jrmccluskey since Ritesh is taking the day off

R: @lostluck

Run GoPortable PreCommit


SyntaxError when running mitmproxy

I get this error when running mitmproxy.
Not sure of what's wrong.
abc@abc-virtual-machine ~ $ mitmproxy
Traceback (most recent call last):
  File "/usr/local/bin/mitmproxy", line 2, in <module>
    from libmproxy.main import mitmproxy
  File "/usr/local/lib/python3.4/dist-packages/libmproxy/main.py", line 73
    except ProxyServerError, v:
                           ^
SyntaxError: invalid syntax

Hi there,
Please use Python 2.7 to run mitmproxy.
Cheers,
Max
Nanda Kumar<EMAIL_ADDRESS>schrieb am Mi., 6. Mai 2015 17:33:

I get this error when running mitmproxy.
Not sure of what's wrong.
abc@abc-virtual-machine ~ $ mitmproxy
Traceback (most recent call last):
File "/usr/local/bin/mitmproxy", line 2, in
from libmproxy.main import mitmproxy
File "/usr/local/lib/python3.4/dist-packages/libmproxy/main.py", line 73
except ProxyServerError, v:
^
SyntaxError: invalid syntax
—
Reply to this email directly or view it on GitHub
https://github.com/mitmproxy/mitmproxy/issues/573.

Thanks Max. But I already seem to be using python 2.7.6 as my default.
abc@abc-virtual-machine ~ $ python --version
Python 2.7.6

Am I missing something else ?

I installed mitmproxy using pip-2.7 and used
> python2.7 /usr/local/bin/mitmproxy

to run mitmproxy. I got it running.
Thanks.


Annotation table updates (MVP without dividers)

Revamp of annotation table to improve data discoverability:

[ ] Annotation table to include 8 columns:

1.Annotation ID - new column, this is replacing the original annotation name column
2.Deposition date - new column
3.Annotated Object - existing column
4.Object Shape Type - existing column
5.Method Type - new column
6.Precision - existing column
7.Recall - existing column
8.No header - space used for "Info" and "Download" links

[ ] Default Sorting: Ground Truths on top followed by the latest deposition date

[ ] Ground Truth Tag: update to the lighter blue color

[ ] 3 locations within table that will open the metadata panel:

"+n more" under Annotation ID column
the text field under Method Type column (i.e., Hybrid, Manual, Annotated)
Info button in last column

Link to design

As a part of this revamp, we should also group the records by object shape type such that there is only one record for Segmentation Mask as opposed to the Zarr and MRC records that we currently display.


Error when reading a .pbn file created by Dealer V1

I'm trying to read a .pbn file and create a .lin file.  The .pbn file was created by Dealer V1 with entries that have [Declarer "?"], [Contract "?"], [Result "?"] lines that your code does not handle correctly.
Here's an example:
[Event "Hand simulated by dealer with file P:\dlr\Dealer-Leaping-Michael-E.dlr, seed<PHONE_NUMBER>"]
[Site "-"]
[Date "2024.06.07"]
[Board "1"]
[West "-"]
[North "-"]
[East "-"]
[South "-"]
[Dealer "N"]
[Vulnerable "None"]
[Deal "E:A95.4.AKQ432.T62 KQJT74.93.987.98 63.AQJ87.5.AKQ74 82.KT652.JT6.J53"]
[Declarer "?"]
[Contract "?"]
[Result "?"]

hopefully this has been solved by Thorvald's latest pull request, I will confirm and then push to pypi


HHH-10995 Add support for Firebird 2.5 and 3.0

Adds new dialects for Firebird 2.5 and Firebird 3.0 (https://hibernate.atlassian.net/browse/HHH-10995)
Minor change to InterbaseDialect for improved sequence support in Interbase and Firebird 2.1 and earlier

Wait wait wait, I did a whole bunch of work on FirebirdDialect on my branch.

@gavinking By the looks of it, your changes are based on the wip/6.0 branch. Would it be possible to take this in on master, and reworking them for 6.0 later? Or are you looking to get rid of version-specific dialects?

@mrotteveel

your changes are based on the wip/6.0 branch.

Yeah, that's right, but I'm thinking of adapting them to the master branch. But I'm kind of in limbo waiting to hear news on what's going to happen with wip/6.0.

Would it be possible to take this in on master, and reworking them for 6.0 later?

Well, yeah, it's possible, and I can see that your work includes some stuff that mine doesn't, though there is quite some overlap. But I was hoping to not multiply the number of version-specific dialects right at the point where I think they should all be deprecated.

Or are you looking to get rid of version-specific dialects?

Yes, absolutely; it was always a bad design, though it was a bit justifiable back in the day when some JDBC drivers didn't support JDBC metadata at all.

@gavinking

Would it be possible to take this in on master, and reworking them for 6.0 later?

Well, yeah, it's possible, and I can see that your work includes some stuff that mine doesn't, though there is quite some overlap. But I was hoping to not multiply the number of version-specific dialects right at the point where I think they should all be deprecated.
And plus we need to take the bits of your work that are missing from mine and merge them into my FirebirdDialect.

That sounds reasonable. In that case it might be better to close this PR, and consider it as a source of inspiration for further changes to FirebirdDialect. If you need more information or help, let me know.

Or are you looking to get rid of version-specific dialects?

Yes, absolutely; it was always a bad design, though it was a bit justifiable back in the day when some JDBC drivers didn't support JDBC metadata at all.

I'm interested how you will solve the issue with version difference. With the current setup of dialects, version differences are hard (or impossible) to do in a single dialect (eg introducing BOOLEAN in Firebird 3, extended NUMERIC/DECIMAL precision and new decimal floating point type (DECFLOAT) in upcoming Firebird 4, new functions per version, etc).

That sounds reasonable. In that case it might be better to close this PR, and consider it as a source of inspiration for further changes

Well if you don't mind me just copy/pasting some of your work into my own branch I will go ahead and do that. But let's not close this pull request just yet, until we see what the Hibernate team thinks.

I'm interested how you will solve the issue with version difference. With the current setup of dialects, version differences are hard (or impossible) to do in a single dialect

Sure, but that's one of the issues that is already fixed on my branch.

Well really that was fixed in the work before your branch
On Wed, Jul 3, 2019 at 12:23 PM Gavin King<EMAIL_ADDRESS>wrote:

That sounds reasonable. In that case it might be better to close this PR,
and consider it as a source of inspiration for further changes
Well if you don't mind me just copy/pasting some of your work into my own
branch I will go ahead and do that. But let's not close this pull request
just yet, until we see what the Hibernate team thinks.
I'm interested how you will solve the issue with version difference. With
the current setup of dialects, version differences are hard (or impossible)
to do in a single dialect
Sure, but that's one of the issues that is already fixed on my branch.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hibernate/hibernate-orm/pull/2934?email_source=notifications&email_token=AABZIE3TSFEWN5FACZTRMEDP5TN7FA5CNFSM4H4KLEK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFEI6A#issuecomment-508183672,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABZIE36G4ZDF5EOQMM4LQ3P5TN7FANCNFSM4H4KLEKQ
.

That sounds reasonable. In that case it might be better to close this PR, and consider it as a source of inspiration for further changes

Well if you don't mind me just copy/pasting some of your work into my own branch I will go ahead and do that. But let's not close this pull request just yet, until we see what the Hibernate team thinks.

Go ahead, copying some of my code is fine by me.

I'm interested how you will solve the issue with version difference. With the current setup of dialects, version differences are hard (or impossible) to do in a single dialect

Sure, but that's one of the issues that is already fixed on my branch.

Good to know, I'll take a closer look in the future.

Well really that was fixed in the work before your branch

To clarify: the difference is that whereas previous to my work there was a Dialect subclass for each version of each database, there's now a single Dialect subclass per database, and the old version-specific dialects like Postgres57Dialect etc are now just empty classes marked @Deprecated. Which is why I'm suggesting it would be best not to add Firebird25Dialect and Firebird30Dialect at this moment in time.

Good to know, I'll take a closer look in the future.

The most relevant change is in DialectFactoryImpl.constructDialect(), which now passes a DialectResolutionInfo to the constructor of the Dialect (if there is an appropriate such constructor).

@mrotteveel would you please take a look at this code:
https://github.com/gavinking/hibernate-orm/blob/MERGED/hibernate-core/src/main/java/org/hibernate/dialect/FirebirdDialect.java
which is supposed to be a merge of your work with mine, and tell me if there's anything I missed, or anything you don't think is quite right?
Thanks!!

@gavinking Some notes:

Line 105: Firebird does have real as a datatype (it isn't documented in the Firebird Language Reference though), and is a 32 bit single precision. In theory, Firebird has float(p), but its behavior for the precision parameter is undocumented (and not conforming to the SQL specification), so it is normally only used as an alias for real (or in practice: real is used as an alias for float).

Line 115: I suggest adding registerColumnType( Types.CHAR, 8_191, "char($l)" ) as well

Line 112: TIMESTAMP_WITH_TIMEZONE support will be introduced in Firebird 4 (as type TIMESTAMP WITH TIME ZONE)

Lines 123-125: Jaybird prefers to handle Firebird blobs (text and binary) as LONGVARCHAR/LONGVARBINARY and will report it as type information for blob columns. My pull requests contained definitions for this:
registerColumnType( Types.LONGVARBINARY, "blob sub_type binary" );
registerColumnType( Types.LONGVARCHAR, "blob sub_type text" );

Line 182: I suggest using (0<>?1) instead of (?1<>0) as Firebird versions 2.5 and earlier have problems with type inference with parameters in the left-hand-side of an expression

Line 204: Timestamp precision is actually 100 microseconds, so 100_000 nanoseconds

Line 383: The use of SEQUENCE instead of GENERATOR in FirebirdSequenceSupport.LEGACY_INSTANCE will restrict compatibility to Firebird 2.0 and higher. It is my experience that there is a group of Firebird users that are still using Firebird 1.5 for various reasons. It might be a good idea to add a condition on getVersion() < 200 to return InterbaseSequenceSupport .INSTANCE to provide backwards compatibility there.

Line 416: Using for update will force Firebird to return a single row per fetch (its primary purpose is for positioned updates/deletes with named cursors), the use of for update of <aliases> doesn't do anything different from a normal for update (it is only provided for syntactic compatibility); it might be better to just use plain with lock here as well.

Firebird does have real as a datatype (it isn't documented in the Firebird Language Reference though)

Hrm. But if it's undocumented, should we be generating DDL that uses it?

In theory, Firebird has float(p), but its behavior for the precision parameter is undocumented (and not conforming to the SQL specification)

What precisely is the behavior? Decimal precision instead of binary precision? I can easily accommodate that.

I suggest adding registerColumnType( Types.CHAR, 8_191, "char($l)" ) as well

Well in other dialects we don't bother with the length limit on CHAR, since anyway the only real use of CHAR in Hibernate is for columns of type CHAR(1).

TIMESTAMP_WITH_TIMEZONE support will be introduced in Firebird 4 (as type TIMESTAMP WITH TIME ZONE)

Ah, OK, I will change that then.

Jaybird prefers to handle Firebird blobs (text and binary) as LONGVARCHAR/LONGVARBINARY and will report it as type information for blob columns.

I think what I've got here is correct as far as DDL generation goes. Look at how LONGVARCHAR/LONGVARBINARY are treated in Dialect.getTypeName().

I suggest using (0<>?1) instead of (?1<>0) as Firebird versions 2.5 and earlier have problems with type inference with parameters in the left-hand-side of an expression

OK, thanks.

Timestamp precision is actually 100 microseconds, so 100_000 nanoseconds

Yes, I know that but for dateadd() and datediff() we want to pass the argument in milliseconds. (Well spotted, BTW).

The use of SEQUENCE instead of GENERATOR... will restrict compatibility to Firebird 2.0 and higher. It is my experience that there is a group of Firebird users that are still using Firebird 1.5 for various reasons. It might be a good idea to ... provide backwards compatibility there.

Hrm, OK, you might notice that I documented this as supporting 2.5 and above, since I has understood that previous versions were EOL. But if this is the only change we need to make in order to support older versions, I might as well make it.

it might be better to just use plain with lock here as well.

OK. I will make that change.

@gavinking

Firebird does have real as a datatype (it isn't documented in the Firebird Language Reference though)

Hrm. But if it's undocumented, should we be generating DDL that uses it?

Good point. I thought it had originally been documented in the InterBase 6 documentation and had been omitted when the Firebird 2.5 language reference was written, but the only trace I have been able to find in the old documentation was for REAL in the list of reserved words.

In theory, Firebird has float(p), but its behavior for the precision parameter is undocumented (and not conforming to the SQL specification)

What precisely is the behavior? Decimal precision instead of binary precision? I can easily accommodate that.

Yes, it applies decimal precision (switching from 32 bit precision to 64 bit precision with precision >= 8), but as that behavior has never been documented (that I'm aware of), I feel hesitant to rely on it (especially as it isn't standard compliant to begin with). Using FLOAT (or REAL) vs DOUBLE PRECISION will achieve the same effect.

I suggest adding registerColumnType( Types.CHAR, 8_191, "char($l)" ) as well

Well in other dialects we don't bother with the length limit on CHAR, since anyway the only real use of CHAR in Hibernate is for columns of type CHAR(1).

Ok!
[..]

Jaybird prefers to handle Firebird blobs (text and binary) as LONGVARCHAR/LONGVARBINARY and will report it as type information for blob columns.

I think what I've got here is correct as far as DDL generation goes. Look at how LONGVARCHAR/LONGVARBINARY are treated in Dialect.getTypeName().

Ok, that will indeed work.
[..]

The use of SEQUENCE instead of GENERATOR... will restrict compatibility to Firebird 2.0 and higher. It is my experience that there is a group of Firebird users that are still using Firebird 1.5 for various reasons. It might be a good idea to ... provide backwards compatibility there.

Hrm, OK, you might notice that I documented this as supporting 2.5 and above, since I had understood that previous versions were EOL. But if this is the only change we need to make in order to support older versions, I might as well make it.

Hmm, that is a good point. The usage of global temporary table by getDefaultIdTableStrategy will limit that to Firebird 2.1 or higher. It might be better to make a clean break here and just stop supporting versions before Firebird 2.5. Firebird 2.5 was just EOL'd last month with the release of Firebird 2.5.9, so people stuck on even older versions may just have to keep using older Hibernate versions or use the InterbaseDialect as workaround. As far as I can tell, the InterbaseDialect should still support InterBase 6 (which was the point where Firebird was forked), so should still work with current Firebird versions with the loss of support of newer features/types.
[..]

Good point. I thought it had originally been documented in the InterBase 6 documentation and had been omitted when the Firebird 2.5 language reference was written, but the only trace I have been able to find in the old documentation was for REAL in the list of reserved words.

And the only documentation for 3.0 is in Russian (FTR, it defines FLOAT as 32 bits, and DOUBLE PRECISION as 64 bits, and doesn't mention REAL).

Yes, it applies decimal precision (switching from 32 bit precision to 64 bit precision with precision >= 8), but as that behavior has never been documented (that I'm aware of), I feel hesitant to rely on it (especially as it isn't standard compliant to begin with).

But from what you're saying, Firefox is actually quite a lot closer to the ANSI standard behavior than I had understood from the docs. I'm really not sure what to do here; I mean I've migrated to use float(n) on almost all the other databases, since it seems more faithful to what the ANSI standard intends. Shrug. Not sure what's best here.

The usage of global temporary table by getDefaultIdTableStrategy() will limit that to Firebird 2.1 or higher.

Well again, if we're only talking about changing getDefaultIdTableStrategy() and getSequenceSupport() in order to support previous versions, that's almost trivial. But is there anything else that would need to change?

Good point. I thought it had originally been documented in the InterBase 6 documentation and had been omitted when the Firebird 2.5 language reference was written, but the only trace I have been able to find in the old documentation was for REAL in the list of reserved words.

And the only documentation for 3.0 is in Russian (FTR, it defines FLOAT as 32 bits, and DOUBLE PRECISION as 64 bits, and doesn't mention REAL).

Yes, there is a Russian company that sponsors writing that documentation, and the translation to English lags behind. For English it is usual a matter of referencing the 2.5 language reference + the Firebird 3 release notes.

Yes, it applies decimal precision (switching from 32 bit precision to 64 bit precision with precision >= 8), but as that behavior has never been documented (that I'm aware of), I feel hesitant to rely on it (especially as it isn't standard compliant to begin with).

But from what you're saying, Firefox is actually quite a lot closer to the ANSI standard behavior than I had understood from the docs. I'm really not sure what to do here; I mean I've migrated to use float(n) on almost all the other databases, since it seems more faithful to what the ANSI standard intends. Shrug. Not sure what's best here.

I think it is probably better to keep it as it is now, with FLOAT mapped to Types.REAL and and DOUBLE PRECISION to Types.DOUBLE. It is what most users are expecting anyway.

The usage of global temporary table by getDefaultIdTableStrategy() will limit that to Firebird 2.1 or higher.

Well again, if we're only talking about changing getDefaultIdTableStrategy() and getSequenceSupport() in order to support previous versions, that's almost trivial. But is there anything else that would need to change?

The support for built-in functions in older versions is rather limited (relying on users defining UDFs backed by a native library), but I'll need to double-check if there is anything else.
Firebird 1.5 to Firebird 2 was a big step in SQL support, but had to break some backwards compatibility (hence why some still haven't moved on), but Firebird 2.0, 2.1 and 2.5 were more incremental so most users upgraded along. Firebird 1.5 doesn't support some SQL features like derived tables, so I actually wonder if anything but the most basic Hibernate use actually works on that version.

I think it is probably better to keep it as it is now, with FLOAT mapped to Types.REAL and and DOUBLE PRECISION to Types.DOUBLE. It is what most users are expecting anyway.

Well the thing is that I changed stuff so that Java float and double both map to JDBC Types.FLOAT, with different precisions. So with what I had previously, they both mapped to SQL DOUBLE PRECISION on Firebird, which was imperfect. (Note that historically Hibernate never really used Types.REAL for anything, and instead abused Types.FLOAT to mean single precision.)
So I have gone and removed those overrides on my branch, and made FirebirdDialect use float(p) like the other dialects, but where p is decimal precision.
But it might be a good idea to get in touch with the Firebird team and ask them to commit to supporting the ANSI-style syntax in Firebird 4, given that the actual database already implements it.

But it might be a good idea to get in touch with the Firebird team and ask them to commit to supporting the ANSI-style syntax in Firebird 4, given that the actual database already implements it.

I'll do that.
I looked at the impact on earlier versions:

Sequence behavior for versions < 2.0: same as InterbaseSequenceSupport
getDefaultIdTableStrategy() for versions < 2.1 cannot use global temporary tables
getSelectGUIDString() requires 2.1 or higher
getNoColumnsInsertString() requires 2.1 or higher (no alternative available, so no impact)
DATEADD/DATEDIFF  requires 2.1 or higher (several addXXX UDFs are included with Firebird since 1.0 as an alternative, but those aren't installed by default)
supportsCommentOn() requires 2.0 or higher

I haven't checked the list of built-in functions, but things will get progressively worse for older versions.

I'll do that.

Excellent, thanks, appreciated!

I looked at the impact on earlier versions:

Thanks, I've incorporated those differences into FirebirdDialect.
Very much appreciated!

I looked at the impact on earlier versions:

Thanks, I've incorporated those differences into FirebirdDialect.
Very much appreciated!

And thank you for taking the time for this!

@gavinking

But it might be a good idea to get in touch with the Firebird team and ask them to commit to supporting the ANSI-style syntax in Firebird 4, given that the actual database already implements it.

Firebird 4 will support the standard FLOAT syntax: https://github.com/FirebirdSQL/firebird/commit/426aeb50c81e7d332868e66a84604a99c18b5e74

Hey @mrotteveel!
I'll close this PR for now since wip/6.0 should be mostly up-to-date with what you proposed. If you'd like to work on Firebird 4 support or improve parts of the new FirebirdDialect I'm open to review and integrate that on the wip/6.0 branch, but I don't think it's a good idea to add two new Dialects that will be removed/deprecated in 6.0.
For your information, we are currently discussing the way forward for Dialects that we don't maintain https://github.com/hibernate/hibernate-orm/discussions/3783
When we reach a conclusion, we might pick up this Dialect again.

@beikov  No problem. I left a comment on that discussion with my perspective, and I'll take another look at wip/6.0 now that Firebird 4 is nearing completion.


Add SwiftPM .build directory to .gitignore

We should also add Packages/.

@swift-ci please smoke test

@swift-ci please smoke test


NetworkedMultiplayerENet.create_server() listening on UDP6

Godot version:
3.1.1
OS/device including version:
Fedora 30
Issue description:
When creating a high level network server using NetworkedMultiplayerENet.create_server() Godot listens on only the UDP6 port.
Steps to reproduce:
Create a new Spatial node, attach a script:
extends Spatial

var game_server : NetworkedMultiplayerENet
func _ready():
	game_server = NetworkedMultiplayerENet.new()
	game_server.create_server(52380, 200)
	get_tree().set_network_peer(game_server)
	pass

Minimal reproduction project:
Godot_Network_Issues.zip
Edit:
I think the issue is due to the following line:
https://github.com/godotengine/godot/blob/30e8b53c380a7bc88fbea768e31bc6b64f27f0ef/modules/enet/networked_multiplayer_enet.cpp#L127-L140
It looks like when GODOT_ENET is defined it only connects on IPv6? Does that mean the build I'm using was compiled to only use IPv6 in this case?

I'm running into this same thing. @Inseighn How did you get around this issue?

I wonder if this is related to https://github.com/godotengine/godot/issues/36418.


Feedback should attach the logs

When clicking 'Feedback' grab the logs just like "Advanced Settings -> Logs", zip them, and attach them to the email

This has been in for a long time.


Update configure-replication-zones.md

Topography -> Topology

Thanks, @rmloveland. Yes, please make the changes in the other folders.

@taroface I ported the small change in this PR across the supported versions
the updated commit message has details:

Update 'cluster topography' to 'cluster topology' In the replication zone and connection pooling docs across the following versions: v24.2, v24.1, v23.2, v23.1

Prompted by internal Slack message in #docs


drawing element must be below rowBreaks according to spec or corrupt worksheet

I had an issue with adding both images and a pagebreak to a worksheet. Adding them independently was fine but adding them both together result in a corrupt document.
The issue was related to the ordering of the elements. drawing must be below rowBreaks as seen here:
https://stackoverflow.com/a/12221477/4564456
You can also see the ordering of all the other elements there in case this comes up with new features. Moving drawing and picture below rowBreaks fixes the issue.
I'm currently blocked until this is merged so please let me know if there's anything else I can do to help! :)
Thanks

@guyonroche I appreciate you're busy but do you have an ETA for the next release? I'm currently blocked by this issue.
Thanks

Appologies for the delay - will test and publish today


Rename classes to match spec and move access token restricted features under user

➤ Eric Mossman commented:
[~jason.flax]

I've finished the issue with "identifier" and isLoggedIn. There are consistently failing tests in testMongoAggregateAndCount and testDownloadRealmToCustomPath though. But these in the base v10 like https://github.com/realm/realm-cocoa/pull/6703 also. Should I move forward and get everything in a reviewable PR or wait until new v10?
"access token restricted features" which features does this refer to?
The last thing I'd like to do is this: https://github.com/realm/realm-cocoa/blob/em/identity-refactor/Realm/RLMUser.mm#L46.
But there's a chance I might miss something when trying to tell if a test is failing because of my changes vs. something in the base branch. I could create a ticket for pruning out the dead code in a different ticket and follow through with that after a new v10.

➤ Jason Flax commented:
Access token restricted features is already complete. The last two remaining changes are:
For APIKeyAuth:
apiKeyAuth -> apiKeysXXX
And on EmailPasswordAuth
Change registerEmail -> registerUser

➤ Eric Mossman commented:
For apiKeyAuth -> apiKeysXXX
Does this mean just change "Auth" to three X's in the method? Or something else?

It means to make it plural, do not worry about the X's, it was a holdover from generalising the name for the SDKs broadly.


closeButton Option Not Honored

All other options work perfectly.
I'm calling toastr via Rails app, within an AJAX sequence. My JavaScript template:
$( "#comment-<%= @comment.id %>" ).fadeOut(650);
toastr.options = {
  "closeButton": true,
  "debug": false,
  "newestOnTop": true,
  "progressBar": false,
  "positionClass": "toast-bottom-right",
  "preventDuplicates": true,
  "onclick": null,
  "showDuration": "300",
  "hideDuration": "1000",
  "timeOut": "2500",
  "extendedTimeOut": "1000",
  "showEasing": "swing",
  "hideEasing": "linear",
  "showMethod": "fadeIn",
  "hideMethod": "fadeOut"
}
toastr["success"]("It's gone for good.", "Comment Deleted!")

The toast appears just fine, but the close button never appears.
When I inspect the DOM, the <button> tag is indeed not present (unlike when I inspect the DOM on the toastr demo site).
Any ideas?

Did you find out what was causing this, I have the same issue


Showing Tachometer and Speedometer in driving view with HUD

Hi,
It would be very useful to show the speedometer and tachometer like a real car in the driving window. I guess this should not be too difficult as the info is already available in the HUD. Speaking of which, is there a way to get the HUD overlaid on the camera view and not in a separate window?
Thanks,
Sandip

I was doing something similar... But no speedometer or tackometer.
I was using pygame. It is easy to use but super slow !
I will try to organize and share here the code next week
You can see on this video exactly what I have :
https://www.youtube.com/watch?v=cFtnflNe5fM

Very cool video! I was thinking something on the lines of a realistic driving cockpit like so https://s4-frame.ozstatic.by/1000/236/108/20/20108236_2.jpg
Maybe the wheel movements could be filtered over multiple frames to reduce render processing time? Awaiting your code in any case!

We could extract the engine rotation speed from the UWheeledVehicleMovementComponent and easily display it in the HUD as number (a nicer view would be nice but it's not really a priority right now). We can consider sending it to the client too. However, I don't know how realistic are the simulated RPM and if it would be of any practical use.

Thanks, nsubiron ! I think the main benefit is to know the current speed of the car, in order to adjust the control to obey the traffic signs. The problem is that the HUD is displayed in another window (server?) but the driving window is different. So it kind of defeats the purpose of the "HUD". Unless I am missing something here?

Yes, the other window is the server window. That HUD is mostly to cross-check the info received by the client, also useful for testing in non-networking mode.
The manual control script is a sample of what you can see in the client side using pygame, the idea is that people will adapt this script to their needs. We would be happy to incorporate your changes if you find a nice display for it :)

@nsubiron @felipecode @dehabu Hello, I have been working with Carla for a few weeks and I find it very good. However, I wanted to implement a longitudinal controller taking dynamic variables such as torque in the wheels, angular velocity and RPM.
In the Carla paper published in your webpage carla.org , a modular pipeline was implemented. In this pipeline (section 3.1), there is a description about the Continuous Controller and there is a description about the PID controller that you implemented, in this section there is a reference to another paper in which you used a Roboust PID controller. According to this controller you modeled your Internal Combustion Engine using a static engine map that defines the relationship between the input throttle position and the engine speed to calculate the output torque (section 2.3 equation 8).
That is pretty much what I am trying to do here in order to implement the logitudinal controller. So, I need to find the relation between those variables. However, I need a way to acces them, specially the RPM value in order to know the torque. Can you give me a hint on how can I acces RPM, angular velocity or toque applied to the wheels and send them to the python client? I am looking forward to implement a controller but I need this variables in order to have a correct dynamic model of the vehicle to apply my controller.
I would like to thank you for your answer and for the hard work done so far..!

Closing this, we have a HUD with a lot of info already.


Disable/reduce gif quantization?

Input image: https://www.hatena.ne.jp/images/what/what-riyo-img.gif

255 colors in image
Output image: https://images.weserv.nl/?url=https://www.hatena.ne.jp/images/what/what-riyo-img.gif

254 colors in image. Visible degradation in the frog. I like quantization, but I can't find any option to change how it behaves for GIFs. (also the fact that it didn't just chose one of the lesser-used colors while quantizing bugs me slightly)

We're now A/B testing libvips 8.12 in production, which includes a new gifsave operation that doesn't use ImageMagick for saving GIF images. This particular quantization bug seems to be fixed now, but please report if you see anything strange.
There's some discussion to add indexed read/write support to libvips. This would avoid unpacking to RGB(A) and re-quantization for GIF images that are processed without performing any operations on the image (like this example), but it's not there yet.


fix(tabs): remove disabled item hover state

Closes #1921
This PR prevents mobile tab items from reacting on hover, giving the false impression that the items are actionable

@asudoh I don't think we do, but if we decide that we want to I can remove it for non-disabled items as well


[Q] How to examine correct/wrong predictions in trainer.evaluate()

Hello,
After doing "metrics = trainer.evalute()" as shown in the example code, is there a way to examine which rows in the evaluation data set were predicted correctly?
Thanks!

Currently that is not possible. However, you could call model.predict with the evaluation data to get the predictions. Alongside the known correct annotations, you can write some code to filter for only the correct/incorrect cases. That way you can manually observe the mistakes that the model is making.

Tom Aarsen

Thank you Tom.


Futures / Async support

In ScalaTest there's very handy support for Scala futures.
val f : Future[Any] = ...
whenReady(f) {
 // assertions here
}

I think we should add the same to KotlinTest. However Kotlin currently lacks a standard "Future" implementation. There is of course the stuff in the JDK, but then there's Guava, and various other things as well.
Once 1.1 drops with async / co-routines, I think we'll find Kotlin comes up to par with what Scala provides, and once that happens we should add testing hooks that make it very easy to work with async / co-routines.

FYI, I implemented a very simple wrapper around a retrofit service that returned rxjava Single and was very happy with it.
class ApiTests : RxSpec() { init {

    retrofitFeature("GET ping", service.pingServer()) {
        val map = this
        scenario("server ok") {
            map["ok"] shouldBe true
        }
    }
}

with retrofitFeature being defined like something like this
abstract class RxSpec : FeatureSpec() {
    protected fun <T> retrofitFeature(name: String, call: Single<Response<T>>>, operation: T.() -> Unit) =
        feature(name) {
            val response = call.toBlocking().value()
            var data : T? = null
            if (response.isSuccessful) {
                val body = response.body()
                body?.operation()
            } else {
                scenario("Call $name failed with a server error") {
                    "HTTP ${response.message()}" shouldBe "HTTP 200"
                }
            }
        }

Implemented in master, will be included in 3.0.0 RC2.


[Feat] - use in java

can you help me how to use this library with java

Please check https://github.com/CanHub/Android-Image-Cropper/tree/main/sample/src/main/java/com/canhub/cropper/sample/crop_image_java
Already answer this questions some time in discussion before, don't forget to search please =D
If you have any issue let me know please ^^

thank you very much    On Wednesday, September 29, 2021, 07:10:15 PM GMT+3:30, Canato @.***> wrote:
Closed #224.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


How to create a function in 'sanctuary'?

Hi, I really like this project and it's very exciting.
Although it lacks some introductory material.
I checked the documentation for "sanctuary" and "sanctuary-def".
I noticed that in "sanctuary-def", I can use the function "def" returned by "$ .create" to define a new function.
But in "sanctuary", there is an example of using a document:
  const {create, env} = require ('sanctuary');
  ...
  const S = create ({
    checkTypes: process.env.NODE_ENV !== 'production',
    env: env.concat ([IdentityType ($.Unknown)]),
  });

Where "S" is not the "def" in "sanctuary-def".
"S.def" also does not exist.
I checked the "sanctuary" source code.
  function create(opts) {
    var def = $.create (opts);
    var S = {
      env: opts.env,
      is: def ('is') ({}) ([$.Type, $.Any, $.Boolean]) ($.test (opts.env)),
      Maybe: Maybe,
      Nothing: Nothing,
      Either: Either
    };
    (Object.keys (_)).forEach (function(name) {
      S[name] = def (name) (_[name].consts) (_[name].types) (_[name].impl);
    });
    S.unchecked = opts.checkTypes ? create ({checkTypes: false, env: opts.env})
                                  : S;
    return S;
  }

The "def" obtained did not appear to be exposed.
So how do I define my own functions in a "sanctuary"?

Hello, @lsby, and welcome to the Sanctuary community. :wave:

I noticed that in "sanctuary-def", I can use the function "def" returned by "$ .create" to define a new function.

That's the way to do it. :)

So how do I define my own functions in a "sanctuary"?

Sanctuary itself does not provide this functionality; you need to depend on sanctuary-def. If you are using Sanctuary in your project, depending on sanctuary-def directly will not affect your bundle size as it is already a transitive dependency.
Here is a minimal example:
const $ = require ('sanctuary-def');

const def = $.create ({checkTypes: true, env: $.env});

//    greet :: String -> String
const greet =
def ('greet')
    ({})
    ([$.String, $.String])
    (name => `Hello, ${name}!`);

@davidchambers , I get it now, thanks!


Display (accepts multiple inputs) in the help description for Slice flags.

What type of PR is this?

[x] bug

What this PR does / why we need it:
For Slice flags, display an additional string (accepts multiple inputs) in the help description. This PR adds a support for it
and updates existing tests for accommodating this change.
Which issue(s) this PR fixes:
Fixes #1066
Testing
Updated Existing tests to accommodate the changes.
Release Notes
Display `(accepts multiple inputs)` in the help description for Slice flags.

bumping this

bumping this

Failing check is unrelated.

Failing check is unrelated.

@Madhur1997 Can you pull in the default branch to fix the failing test please 🙏🏼

@Madhur1997 Can you pull in the default branch to fix the failing test please 🙏🏼

sure, updated the PR. Thanks for the review.

sure, updated the PR. Thanks for the review.


Add BigQuery Server Implementation

Description
This PR introduces a new BigQuery server implementation in src/bigquery, providing:

New server implementation for BigQuery integration
Structured directory setup with BigQuery-specific components
Core functionality to handle BigQuery operations

This addition enables direct BigQuery integration capabilities within the server framework.
Technical Changes:

Added new src/bigquery directory with server implementation
Implemented BigQuery-specific server logic

Server Details

Server:
Changes to:

Motivation and Context

This change adds native BigQuery support to the server framework, enabling direct integration with Google BigQuery for data analysis and querying.
How Has This Been Tested?

Testing was conducted using the Claude AI desktop app as the LLM client, with the following scenarios verified:

Successfully established connection to a configured BigQuery project
Executed various BigQuery queries through the server
Verified question-answering capabilities using BigQuery data
Confirmed proper data flow between BigQuery, server, and LLM client

Breaking Changes

Yes, users will need to update their MCP client configuration to utilize the BigQuery functionality:

Add BigQuery project configuration settings
Update client settings to enable BigQuery server integration
No changes required for existing non-BigQuery functionality

The existing server features remain backward compatible; this addition only requires configuration updates for users who want to utilize the new BigQuery capabilities.
Types of changes

[x] New MCP Server
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update

Checklist

[x] I have read the MCP Protocol Documentation
[x] My server follows MCP security best practices
[x] I have updated the server's README accordingly
[x] I have tested this with an LLM client
[x] My code follows the repository's style guidelines
[ ] New and existing tests pass locally
[x] I have added appropriate error handling
[x] I have documented all environment variables and configuration options

Additional context

Thank you @jspahrsummers. I created a new PR as you suggested https://github.com/modelcontextprotocol/servers/pull/214


Suggest some clarification on some statements in the doc

You have a line in there of
AzCopy uses server-to-server APIs, so data is copied directly between storage servers. These copy operations don't use the network bandwidth of your computer.
But that makes it sound like the local computer isn’t a factor in the performance of the copy, but it is.  CPU matters. Network matters.  Memory probably matters. Maybe it isn’t much of a factor if a few large files, but if hitting thousands of small files, it is a factor.  It is technically accurate (the actual copy operation doesn’t use the network bandwidth of the computer), but initiating each of the copies does, so a bit misleading.
Thanks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 59827b34-a728-ac8d-0ba0-0b60cde2321d
Version Independent ID: 8daf39eb-e037-b5e5-874e-c9b556cc2433
Content: Copy blobs between Azure storage accounts with AzCopy v10
Content Source: articles/storage/common/storage-use-azcopy-blobs-copy.md
Service: storage
Sub-service: common
GitHub Login: @normesta
Microsoft Alias: normesta

@J-Fedor Thanks for the question! We are investigating and will update you shortly.

@J-Fedor  Firstly apologies for the delay response! I am checking with the product team! In meanwhile you may refer to this suggestion  About the best performance settings. You can run “azcopy bench” and it will tell you what the optimal numbers for the various settings are given your setup.
Optimize the performance of AzCopy with Azure Storage:https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-optimize?toc=/azure/storage/blobs/toc.json

Not applicable for storage-to-storage, that's more for to/from the machine and storage.
John Fedor
Principal Architect
Direct:
Support Desk
630.592.6240
630.592.6260
visit peters.com today!
Stay up-to-date and follow us on social media!
Don’t be a Turkey this Thanksgiving! Attend our Microsoft 365 Security workshop.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and privileged material
Unauthorized review, use, disclosure, or distribution is prohibited.
If you receive this material/information in error, please contact the sender and destroy the material/information.
From: SumanthMarigowda-MSFT @.>
Sent: Monday, November 22, 2021 9:46 PM
To: MicrosoftDocs/azure-docs @.>
Cc: John Fedor @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Suggest some clarification on some statements in the doc (Issue #83904)
@J-Fedorhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJ-Fedor&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795643915|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=rTXirHTJ1IA5vVGAa7SEr6TCXjda7YxQjWpDPRg3wWE%3D&reserved=0 Firstly apologies for the delay response! I am checking with the product team! In meanwhile you may refer to this suggestion About the best performance settings. You can run "azcopy bench" and it will tell you what the optimal numbers for the various settings are given your setup.
Optimize the performance of AzCopy with Azure Storage:https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-optimize?toc=/azure/storage/blobs/toc.jsonhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fstorage%2Fcommon%2Fstorage-use-azcopy-optimize%3Ftoc%3D%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795653909|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=g2e%2BFCuGEDu6hG%2Bbp5pVdZh8DOksWYijSLUngNXH20I%3D&reserved=0

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F83904%23issuecomment-976142772&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795653909|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=qsg3uMCV4QCj5FCEBnJ4jrwOdUqrtpaNW0CfkHbnR9E%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI7G3VJJMLRER6P4ZGG6G53UNMFAPANCNFSM5IDHCJ6A&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795663903|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=AIS0DtogqtEGiEzNgYPjGi4ynuCLe%2B2qbG%2FGS%2FVH62E%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795663903|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=jU4UIqLKHMbC%2BT4DhF%2FBXEmujCjpCYBLQBjtdaqqjsw%3D&reserved=0 or Androidhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|john.fedor%40peters.com|3fdda34a59c74b58129e08d9ae33cd4a|a9abff8932b44225826965d12401e6d9|0|0|637732359795673897|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=064Rsm70xyGkd2YFCPUZSqaIewvA94bk%2BIiEYsp1y%2BQ%3D&reserved=0.

@J-Fedor
CPU/network matters for a service-to-service copy, but they only matter to a certain extent. The bandwidth needed to orchestrate copies is not even comparable to the one required to transfer actual data. As long as the machine from where AzCopy is running can successfully make requests to the service, and can handle the concurrency, then the CPU/network makes very little impact to the overall performance. However, there are definitely cases where the machine is just so weak, or the network latency is unacceptably high so that the overall performance is impacted
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

Well, not quite accurate.  When there are millions of small files, there are a lot of API calls and we definitely see a difference between a 30Mbps Internet pipe and 100Mbps pipe and a Gigabit pipe.  And CPU/cores matter as we resize guests in Azure to throw more at it.
But if you don't feel like documenting it, so be it.
John Fedor
Principal Architect
Direct:
Support Desk
630.592.6240
630.592.6260
visit peters.com today!
Stay up-to-date and follow us on social media!
Don’t be a Turkey this Thanksgiving! Attend our Microsoft 365 Security workshop.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and privileged material
Unauthorized review, use, disclosure, or distribution is prohibited.
If you receive this material/information in error, please contact the sender and destroy the material/information.
From: SumanthMarigowda-MSFT @.>
Sent: Saturday, November 27, 2021 11:40 PM
To: MicrosoftDocs/azure-docs @.>
Cc: John Fedor @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Suggest some clarification on some statements in the doc (Issue #83904)
@J-Fedorhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJ-Fedor&data=04|01|john.fedor%40peters.com|23c241ab5ce843b515e908d9b231909c|a9abff8932b44225826965d12401e6d9|0|0|637736748228612275|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=nrL26URezEKW5LLmigPoW9lhiEO1ZoLTrGxOidqaN6E%3D&reserved=0
CPU/network matters for a service-to-service copy, but they only matter to a certain extent. The bandwidth needed to orchestrate copies is not even comparable to the one required to transfer actual data. As long as the machine from where AzCopy is running can successfully make requests to the service, and can handle the concurrency, then the CPU/network makes very little impact to the overall performance. However, there are definitely cases where the machine is just so weak, or the network latency is unacceptably high so that the overall performance is impacted
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F83904%23issuecomment-980843742&data=04|01|john.fedor%40peters.com|23c241ab5ce843b515e908d9b231909c|a9abff8932b44225826965d12401e6d9|0|0|637736748228622270|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=tduOKfqez4FSV6C2pubJI9O0KMU7wqWWktSeW6e%2BZNQ%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI7G3VLJ3WK4AQR5OESRUJDUOG6EHANCNFSM5IDHCJ6A&data=04|01|john.fedor%40peters.com|23c241ab5ce843b515e908d9b231909c|a9abff8932b44225826965d12401e6d9|0|0|637736748228622270|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=%2FeJaOXXzlHrAWMUhJI0691y5%2BiztLSexGmsJF1iVeEc%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|john.fedor%40peters.com|23c241ab5ce843b515e908d9b231909c|a9abff8932b44225826965d12401e6d9|0|0|637736748228632259|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=f%2B%2Bt%2BdeJim%2BsmE0uMb8qxVfwhvmWOkHEzsdCEe%2BVXgk%3D&reserved=0 or Androidhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|john.fedor%40peters.com|23c241ab5ce843b515e908d9b231909c|a9abff8932b44225826965d12401e6d9|0|0|637736748228632259|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=Fb3eh1naOSlP3A6MG1hO0yGjVOPH3n1PTRyr7dMP5bM%3D&reserved=0.


Make keyboard usable outside of tables

Describe the problem to be solved
note: since I'm discovering Grist, hopefully I'm not wrong about all this, sorry in advance if I'm mistaken :)
The issue is Grist is not fully usable with keyboard.
For now, Grist makes sure we can use the keyboard when using a table, making it easy to navigate through cells, enabling lots of specific keyboard shortcuts.
But current system makes anything not inside a table unreachable with the keyboard. Even on pages not containing tables at all, it seems the keyboard shortcuts system is enabled and prevents using classic browser keyboard navigation.
That means I can't use the keyboard to login, navigate through my documents, navigate through document pages, share the document, configure my table/column options, etc.
Making everything usable exclusively with the keyboard would make Grist usable by lots of people with disabilities. Some people can't use a mouse and 100% rely on the keyboard to navigate. And some people use assistive technologies (AT) that mostly rely on keyboard navigation to work. So, making keyboard navigation work also means doing a good part of making lots of AT work.
And without accessibility in mind, that would also help some power users who are just more efficient with keyboard to fully work without having to use their mouse here and there. But mostly I'm interested in this in an accessibility point of view :)
Related WCAG criterion: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html
Describe the solution you would like
My goal with this first issue is to make keyboard work on pages that don't contain a table.
On those kind of pages I figure there are no need to enable specific keyboard shortcuts and we could benefit from classic browser keyboard navigation.
I guess a good first test that this work would be to be able to login to Grist with the keyboard.
On future work after this, I imagined thinking about a way to go in and out the table with keyboard. Like maybe pressing Esc twice would allow to switch between "normal" keyboard navigation, and "table-specific" keyboard nav. But I guess this is more of a second step.
I'm open to any guideline to implement necessary changes while I dig into the code on my own anyway :)
Cheers

I see that for keyboard shortcuts handling, the code relies on having a hidden textarea where DOM focus is forced on, basically after any user interaction.
I see this article is mentioned in the code comments, explaining this technique.
I think I'll investigate to see if this kind of work-around is still needed nowadays so that every browser work. It's been 10 years since the article came out (and I actually don't know the actual time this code was added since this is the oldest I could go in the git history).
Because this trick is the main thing preventing normal keyboard usage, I'm thinking maybe we could handle keyboard shortcuts in a cleaner way now, without having to rely on a dom element where we always force focus on.
Will update this as I dive :diving_mask:

Thanks @manuhabitela . For the "always-focused hidden textarea", besides testing for typing in characters, don't forget to test pasting from other cells (or selections of multiple cells) in Grist, and also pasting plain text from other apps, and pasting selections of multiple cells, e.g. from Excel or from another Grist tab.
I know back when the textarea approach was added, it was a necessary workaround, but unfortunately no longer remember for which exact situation, and if it was for particular browsers/OS combinations.
Testing on both Chrome and Firefox would be appreciated (we also take care of fix issues reported in Safari, but Chrome and Firefox are officially supported).

I think what I have is a good basis. Not quite done yet as I need to test more use cases, in different OS, browsers and keyboard languages, but on paper it might be a good solution.
Still a couple quirks in there but the new logic looks like this:
First, have copy/cut/paste work just like before, almost no code is changed specific to this and for now it works like before.
Second, have nothing that re-grabs focus by default. This is the key point of this PR. If tab and shift+tab commands weren't there, pressing those keys would now go through "tabbable" elements normally. For now we wouldn't get far, since classic tab behavior is disabled from the start, we quickly get stuck, or don't see what we are tabbing through. But the door is now opened for more work.
The main tricky part is the removal of the logic of "force user keypresses in a hidden textarea and trigger the input command with its content". This is the tricky part: capturing user input without an actual input in the dom is not straight-forward. My current solution is to globally listen for keyboard events, and manually conclude if the user typed a printable character or a grist/system keyboard shortcut. If it's a printable character, call the input command like before.
This is the part where I need more precise testing across OS, browsers and keyboard languages :)
If this ends up well and gets merged, the idea is that we notice nothing changed in the usage. This is more of a ground-work to then allow specific work related to Tab/Shift+Tab shortcuts and others.

Thank you for the explanation, this is much clearer to me now. The main thing I'd worry about then is interpreting a keyboard event to turn it into a typed-in character. For example, if your OS is set to a different input language, like Russian / Ukrainian, typing opens a cell and works correctly.
In other cases, this is already a problem. E.g. if you type a character modifiers first (like on Mac you may type Option-E before A to type in Á), Grist doesn't do the right thing. It's worse for other languages, see https://github.com/gristlabs/grist-core/issues/891. It's OK not to fix it of course, since that's not the goal here, but it may be helpful to be aware, especially if you come across a nice general solution.

Thanks for the linked issue, that is exactly the kind of thing I want to worry about. And yeah my intent is to test with multiple languages. For now the code makes a few assumptions that I'm still not sure are enough to be reliable.

So what I have right now might be acceptable but it's not perfect, I'm a bit frustrated.
By globally listening to the keydown event (new logic), contrary to forcing every keystroke inside an actual input (current logic), I manage to catch most things but not all.
Good things:

copy/cut/paste works as intended
when not actually in a cell, but just having the focus ring visually on it, typing most characters works as before, it writes in the cell input and triggers focusing the dom input cell correctly
typing keys requiring modifiers work. Like Shift+a for A, AltGr+à for @ in French, etc. I tested in French, English, Russian, Arabic, Hindi
specific work is done to prevent collision with command shortcuts or browser/system shortcuts, so pressing Command + o wouldn't wrongfully type o in the cell
some logic was added to handle specific commands that do not stop event propagation. I actually only saw the = command for this case.

Bad things:

the IME issue currently happening when directly typing a character without pressing Enter first in a cell, is not solved. And most importantly I'm pretty sure it's unsolvable with the new logic. I'm actually not even sure that it could be solved with the current logic anyway though that's that…
dead keys, like ^, ¨, ´ are not handled when not already actually focused in a cell . With the new logic, you can't start typing in a cell with a dead key, without pressing Enter first. As you mentioned, this is currently not working as we expect with the current logic anyway either…

The thing is relying on keydown events as a "catch-all" for user input have limitations, as this technique doesn't allow us to catch actual user input but rather only the keys he types, and we see those do not match 1:1.
What do you think about those new limitations @dsagal? Well, new in a sense that, I'm pretty sure that they won't be solvable at all going forward with it, contrary to a logic similar to the current one where we might improve things.
I'm thinking of an alternative where we could stay with a logic similar to the current one for when we are in "table mode", that we could go in/out of with a keyboard shortcut, to then navigate normally across tabbable elements in the page when needed. Like having a "normal keyboard navigation" mode and having a "spreadsheet keyboard navigation" mode.

Thank you for all the research @manuhabitela! It sounds like either your approach or the alternative you describe could be made to work, with some tradeoffs. Could you describe the benefits of the new approach? Is it mainly to avoid the trickery and complexity of the current approach (with the hidden textarea)? Are there other advantages?

Sorry for the delay, I wasn't there much those last few days…
In theory the benefits were:

handle things the same way in mobile and desktop
stop using this "catch all" input that makes it cumbersome to handle screen readers or other assistive technologies

But the more I worked on this and the less I'm convinced myself.

Another approach that seems better:
Rely on the already existing Ctrl+O shortcut that allows to move between widgets. Make it so that now, other parts of the UI are regions we can cycle through. The best would be that Grist remembers the last focused element of a region so that could be used like Alt+Tab.
For an even more better experience, we can imagine direct keyboard shortcuts to go to menu, left panel, right panel, to prevent having to cycle through everything when switching between table and right-panel. Or having a "go to last section" keyboard shortcut to be able to actually just alt+tab, but maybe that is a bit weirder to understand.
Quick-and-dirty example of what it would look like to press Ctrl+O multiple times:

With this idea we would keep the current catch-all hidden input for when we are inside a table. And handle keyboard stuff with already existing FocusLayers, like used in dialogs.

If going forward with this I think it would be important to make it easily discoverable that Ctrl+O exists. As it would be an essential shortcut to know about when wanting to use the keyboard.
That's one little objection I have with how Excel and Google Sheets handle comprehensive keyboard navigation: without going in the help section, you don't know about the necessary shortcuts to do everything and you are stuck in the grid.
We could imagine a notification that comes up when we detect multiple uses of navigation keystrokes like tab or arrow keys, that says something like "Use Ctrl+O to navigate through the whole page with the keyboard".

I'm not thinking straight, combining cycling through "regions" and widgets with the same shortcut wouldn't work with the right panel, as its content depends on the focused widget. Having a different shortcut to cycle through regions works.

I like the example of navigating between the main functional areas of the app. Thanks! New shortcuts are always hard to pick, because in a browser so many shortcuts already have a meaning (even I can never remember the Ctrl+O shortcut, for example). Another idea I had, but not really worked out, is if we added a shortcut for switching between "levels", and then allowed Tab / Shift-Tab within a level. Levels are:
Grist Application
├── Left Panel
├── Main Panel
│   ├── Page Widget 1
│   │   └── Cells
│   ├── Page Widget 2
│   ├── More page widgets...
└── Creator Panel

When a level is highlighted, Tab would navigate between items at that level, and Enter may work pretty intuitively for descending into the lower level. We may just need a shortcut for going up a level.
This would make some navigation take more steps. E.g. if cursor is in a cell, then you are at the lowest level. To switch to a cell in another widget, instead of just Ctrl+O, you'd press UpLevel (whatever it is) + Tab (next widget) + Enter (swith selection from widget to cell within it). We may still want a shortcut at least for the creator panel, otherwise it would take 4 steps to "walk" to it.
So maybe not a great idea, but maybe could inspire a better one :)

New shortcuts are always hard to pick, because in a browser so many shortcuts already have a meaning (even I can never remember the Ctrl+O shortcut, for example)

I completely agree. It's hard to come up with easy shortcuts without replacing a browser one. To be sure that we have "grist-only" shortcuts we easily have to end up with complex shortcuts like ctrl + alt + shift + … and from my point of view that doesn't really fit with such an important shortcut when using keyboard only.
For example when testing locally for now I use Ctrl + i, since on most keyboards it's right next to Ctrl + o and the idea would be to use those two together often. But on Firefox that is the Page Info shortcut. Putting aside the fact the firefox shortcut now becomes unavailable, one issue is that it's easy to be in a state where the page is actually not focused (but the browser is), and if I press Ctrl + i thinking it will switch between my panels, it will open the firefox page info instead…
Maybe Ctrl + Alt + O would be acceptable, being on the same key than the existing shortcut.

So maybe not a great idea, but maybe could inspire a better one :)

Your navigation idea is interesting! The "uplevel" shortcut could be Escape?
I'm a bit concerned this would make keyboard navigation a bit tedious, or a bit hard to get at first. This go in/go out a level concept is not that common in webapps.

We may still want a shortcut at least for the creator panel, otherwise it would take 4 steps to "walk" to it.

I agree, switching between grid and creator panel would definitely be the most common global navigation when building a document. F4 is a straightforward shortcut that could be usable to quickly switch between creator panel and grid?

Continued thinking about this:
Is your "levels" idea mostly a way to prevent having to introduce a new keyboard shortcut? Do you see any other benefit of it compared to a more "straightforward" focus switch?
The idea is like introducing a modal mode in the app and the more I think about it the more I'm concerned it would be hard to get and maybe a bit cumbersome to use. At the very least it would need good user visual feedback to understand if we are in "switching mode" or "typing mode" I guess. I'm not sure really but I feel it would be a bit overkill.
Here is another idea:

Have ctrl + o and ctrl + shift + o be the shortcuts cycling through UI regions, including widgets but excluding creator panel: pressing the shortcut would move me to left sidebar, then top panel, then widget 1/2, then widget 2/2, then left sidebar again, etc.
Have a specific shortcut to alt-tab to the creator panel. Maybe ctrl + alt + o? Pressing it when not focused on the panel would lead me to it, pressing it again would put me back to the previous region I focused.

Benefits are:

we have only one level of "ui region cycling": easier to understand and use, especially for people not using the creator panel (in that usecase, having two shortcuts doesn't make much sense)
for the "builder" user specifically, the creator panel direct shortcut makes it easy to switch in/out of it

Downside is:

maybe feels weird at first that the creator panel is not in the "ui regions" cycle. The important thing would be to make sure that if the user knows about the creator panel shortcut if he knows about the "ui cycle" shortcut. Maybe just listing first the tab-creator related shortcut in the keyboard shortcuts dialog would be enough?

Yet another idea would be that, on documents having only one widget, the "UI cycle" shortcut would include the tab panel. But I feel having a behavior changing that much between documents could lead to misunderstanding.
What do you think? :)

Overall the idea seems fine. Exact shortcuts should get another review for likely conflicts. Some more questions:

When an area like left panel or top panel is focused, how does Tab behave? Does it stay in that area?
Would there be any mouse-based way to focus these UI areas (like left panel or top level)? Today, focus automatically "falls back" into the main data area, e.g. after clicking a page or a top-bar icon.
For the creator-panel shortcut: if the panel is closed, will it open it? How would the user close it with keyboard?
Within the creator panel, would users use Tab plus Enter to be able to switch between the tabs and subtabs within the panel?

When an area like left panel or top panel is focused, how does Tab behave? Does it stay in that area?

I would say when using those UI region shortcuts, tab would stay locked in those areas. Kinda like how tab is locked to a widget for now. Since a widget uses arrow keys and Tab for specific navigation in it, I guess it would feel weird to be able to tab to it from the top panel, and then being stuck in it. I feel "being stuck" in each UI region you actively select feels more understandable when going from region to region?
Before this "UI region cycle" idea I had another idea of "keyboard mode" vs "grist mode". Enabling "keyboard mode" would let you tab normally through all the UI that is not in a widget, and "grist mode" would be the current behavior, tied to the active widget. But that felt a bit weird. The fact that you can currently move from widget to widget makes me think that expanding on this idea, and move from UI region to UI region instead, is a good fit.

Would there be any mouse-based way to focus these UI areas (like left panel or top level)?

Not sure I understand this. You mean being able to click on an empty space in the top panel for example, so that pressing Tab would then tab through elements of the top panel, starting with the next one closest to where you clicked? Like classic browser behavior you mean?
I actually did not think about that. Because I'm afraid most people are used to having tab and arrow keys navigate into the spreadsheets by default. So my guess is current behavior of forcing every keyboard navigation being tied to the spreadsheet is a good idea, it just needs an escape hatch for people willingly using the keyboard to navigate entirely.

Today, focus automatically "falls back" into the main data area, e.g. after clicking a page or a top-bar icon.

My rough idea is that, when focusing a UI region that is not a widget, through the UI cycle shortcut, the whole clipboard/"any key pressed runs the input command" stuff is more or less disabled. Because it's not necessary outside of a widget (or is it maybe?).
So in those regions, navigation keys like, tab, space, enter, arrow keys, etc, would just act with their default browser behavior.

For the creator-panel shortcut: if the panel is closed, will it open it? How would the user close it with keyboard?

Good question! That needs more thoughts into it. I'd say if the panel is closed, pressing the shortcut would focus the panel toggle button? And if the panel is opened, the toggle button would be the first focusable thing of the panel. Kinda like usual modal dialog behavior.

Within the creator panel, would users use Tab plus Enter to be able to switch between the tabs and subtabs within the panel?

The idea would be to follow the Tabs ARIA pattern: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
In that case, keyboard navigation is similar to the one with radio inputs: press tab to focus the tabs area, press arrows to change the current tab. Pressing tab again moves focus to the current tab content.


Cross-site Scripting (XSS) via URI

Browsers support both lowercase and uppercase x in hexadecimal form of HTML character entity (tested on Chromium && FF).
But marked unescape only lowercase:
// https://github.com/chjj/marked/blob/master/lib/marked.js#L1096-L1108

function unescape(html) {
	// explicitly match decimal, hex, and named HTML entities
  return html.replace(/&(#(?:\d+)|(?:#x[0-9A-Fa-f]+)|(?:\w+));?/g, function(_, n) {
    n = n.toLowerCase();
    if (n === 'colon') return ':';
    if (n.charAt(0) === '#') {
      return n.charAt(1) === 'x'
        ? String.fromCharCode(parseInt(n.substring(2), 16))
        : String.fromCharCode(+n.substring(1));
    }
    return '';
  });
}

This allow attacker to create link with javascript code.
For example, this code:
var marked = require('marked');
marked.setOptions({
  renderer: new marked.Renderer(),
  sanitize: true
});

text = `
lower[click me](javascript:...)lower
upper[click me](javascript:...)upper
`;

console.log(marked(text));

Will render:

lowerlower
upperclick meupper

Browser example: https://www.buglloc.com/marked.html
Tested on Marked v0.3.6 + Chromium 60.0.3112.90 and Firefox 55.0.1

You are right. this should should be a case-insensitive match:
html.replace(/&(#(?:\d+)|(?:#x[0-9A-Fa-f]+)|(?:\w+));?/ig

unfortunately the maintainer is not longer around to push a change to npm. I will push a change to the master branch but unfortunately that may be as far as this change goes.

Hi Matt -- did this issue ever result in a pull request? Thanks!

See #937

Just tested this and it is still an issue. Why was this closed? what tests were added?

See #926


RFC: Autowiring commands to handlers in Symfony 3.3+

Based on the new service discovery coming in Symfony 3.3, I'd like to add a naming convention based locator.
The idea is that we could use config like:
services:
    App\:
        resource: '../../src/{Handler}'
        tags: ['tactician.handler']

This would autowire all handlers into the DI container using their FQCN as service id (RegisterUserHandler).
The proposed new locator would automatically route a command with a FQCN like Foo\RegisterUser or Foo\RegisterUserCommand to Foo\RegisterUserHandler. We could pull that directly from the container/service locator and presto, it works.
Pros:

The user has all of their correct mappings in 3 lines of config, much less config typing, especially since IDEs don't autocomplete the command class name in services.yml
No more worrying about updating the command names in the services.yml after doing a rename on a command.
Much simpler onboarding for those using autowiring.

Cons:

Much magic, such auto, very wow.
We definitely need to add a switch to make this optional.
Mainly works in Symfony 3.3 and up.

Thoughts:

We could add a naming inflector interface for this autowiring so folks can add in their own class name conventions.

While I'm only so-so on autowiring containers and generally avoid it, I think this is a feature that pro-autowiring folks would really enjoy.
Thoughts? Totally open to all config format/feature/implementation suggestions here. :)

It'll be great if it's also flexible enough & configurable out of the box.
In my own projects, I declare commands in a Command namespace and handlers in a Handler one (it might seem redundant, but it helps well to keep my Application layer structured and not overwhelming).
E.g: Foo\Application\Command\RegisterUserCommand should be handled by Foo\Application\Handler\RegisterUserHandler

IMO everyone have its own habits regarding stuff naming. As @ogizanagi said we need this very flexible to be used.
In our apps, we have not dedicated handlers for example, so it becomes difficult to make magic I guess ;)

Note that in the yaml configuration shown in the description:
services:
    App\:
        resource: '../../src/{Handler}'
        tags: ['tactician.handler']

the tag could also be completely removed if we introduce a marker interface, thanks to the autoconfigure capabilities of sf 3.3.
Above all, it also means you don't to write anything specific to handlers in the DI configuration, but simply keep the defaults proposed by the framework recipe using flex to PSR-4 load the whole src/ directory, and have everything configured & autowired automatically.
A similar marker is under discussion for Twig runtimes, which currently don't have any interface either.

This is the tough one.
In my project we use notation like this:
Foo\Application\User\RegisterUser\RegisterUser for command and:
Foo\Application\User\RegisterUser\RegisterUserHandler for command handler.
Plus marker interfaces.

We could add a naming inflector interface for this autowiring so folks can add in their own class name conventions.

Sounds great, with a few most popular implementations it can work really well.
If you need any help, I would be glad to.

If me add an handler interface maybe we could add a static method to it that gives the corresponding command to remove the need for an inflector.

We've experimented with marker interfaces in the early days of Tactician
and it never really worked out, so they were removed and won't return in
core, especially since a large number of folks will probably never use
autowiring.
That said, if folks want to build it themselves, I think we should make it
possible for them. (it's already possible today by writing a custom
HandlerLocator which isn't super hard)
On Jun 3, 2017 3:01 PM, "Jérôme"<EMAIL_ADDRESS>wrote:

If me add an handler interface maybe we could add a static method to it
that gives the corresponding command to remove the need for an inflector.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/thephpleague/tactician-bundle/issues/44#issuecomment-305973737,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI9TtxaBo32WT4lSoPdSPOb97LqVRD3ks5sAVkogaJpZM4Nol_P
.

I think it's slightly different here. No need to be in the core. It'll only deserve autoconfiguring purpose, which is a symfony thing, thus should only be in the bundle. This marker interface should not deserve any other means.

Besides, using a marker interface could be the best way to differentiate who wants to use autowiring or not.

I was thinking that the Command can be guessed by reflection. So If we have:
class MyCommandHandler {
    public function handler(MyCommandOrQuery $command) {}
}

We can guess the command class with:
$reflectionExtractor = new ReflectionExtractor();
$command = $reflectionExtractor
     ->getTypes($handlerClassName, $methodInflectorName)
     ->getClass()
     ->getName();

Is it possible to read the Command from:

Closing in favor of #60 and the PR #67.


Provide a way to un-sync

Long story short: We're migrating our app from Angular 1 to Vue.js.  To do that, we're building new "views" in Vue.js and hooking them into our Angular 1 app.
When our user navigates away from the portion of our app where a Vue.js root component was mounted, we destroy the Vue component:
// ($onDestroy is angular component destroy hook)
  $onDestroy() {
    console.log('DESTROYING VUE')
    this.vueApp.$destroy();
  }

Our vueApp is built in an Angular 1 component constructor and successfully mounted to the DOM.
import Vue from 'vue'
import { sync } from 'vuex-router-sync'

import store from '../store'
import router from '../router'

import Main from '../Main.vue'

class BootstrapReportsController {
  constructor () {
    sync(store, router)

    this.vueApp = new Vue({
      router,
      store,
      ...Main
    }).$mount('#reports')
  }

  $onDestroy() {
    console.log('DESTROYING VUE')
    this.vueApp.$destroy();
  }
}

Everything works as expected except when the user navigates away from this part of our app and then returns, a nasty exception gets thrown in vue-router-sync because the original store.watch (https://github.com/vuejs/vuex-router-sync/blob/master/index.js#L18) is never cleaned up when the vueApp.$destroy method is called (I'm assuming b/c vue-router-sync still retains a reference to the store).
Here is the error message:
lib_bundle.js:246653 [Vue warn]: Error in callback for watcher "function () { return getter(this$1.state, this$1.getters); }": "TypeError: Cannot assign to read only property 'path' of object '#<Object>'"

(found in <Root>)
warn @ lib_bundle.js:246653
handleError @ lib_bundle.js:246736
run @ lib_bundle.js:249148
update @ lib_bundle.js:249120
notify @ lib_bundle.js:246952
reactiveSetter @ lib_bundle.js:247174
ROUTE_CHANGED @ defense_all.js:123
wrappedMutationHandler @ lib_bundle.js:254206
commitIterator @ lib_bundle.js:253930

lib_bundle.js:246740 TypeError: Cannot assign to read only property 'path' of object '#<Object>'
    at Object.match (lib_bundle.js:244995)
    at VueRouter.match (lib_bundle.js:246014)
    at AbstractHistory.transitionTo (lib_bundle.js:245466)
    at AbstractHistory.push (lib_bundle.js:245925)
    at VueRouter.push (lib_bundle.js:246082)
    at Vue$3.store.watch.sync (defense_all.js:145)
    at Watcher.run (lib_bundle.js:249146)
    at Watcher.update (lib_bundle.js:249120)
    at Dep.notify (lib_bundle.js:246952)
    at Object.reactiveSetter [as route] (lib_bundle.js:247174)

Since the original store (the first time our component/Vue) is loaded is not destroyed when the user navigates away from our component, the watch triggers again when the user returns to the component and if route.fullPath is different than the previous currentPath variable, then it thinks TimeTraveling is occurring, that the Vuex state has changed, and tries to replace the current route.
So my "issue/bug" is that I assume vuex-router-sync was written without the idea that someone would try to destroy the root Vue component.  Is it possible to register a watch handler when scope.watch is called and then export a desync method or some way to allow the developer to "unwatch" the Vuex state.
I found this on Vuex Github: https://github.com/vuejs/vuex/issues/599
It sounds like Vuex won't naturally clean up watch elements and they should be manually unwatched but this plugin doesn't provide a method to do that.
Follow-up:
It looks like this project also hooks into router.afterEach.  Again, if there's no way to "unhook" this event registration, won't this plugin leak each time sync(store, router) is called with a new Vuex and VueRouter object?
I recognize we could not destroy our root Vue component when the user navigates away from our Angular 1 component or we could create a global Vuex state for the entire application and never destroy it, but while we "upgrade-in-place" it makes it more efficient, performant, and modular to destroy root Vue components when a user navigates back to a legacy part of our Angular 1 application.

Any update/comments/thoughts from the maintainers?

Hey,
sorry for not responding, it seems this issue slipped most people's radar - this repo is generally nor very active since it's a simple lib.
Your issue raises a valid concern. I guess the possibility of an app that uses vuex, vue-router and vuex-router-sync being destryoed and rebuilt wasn't taken into account.
My idea to solve this would be the following:
Both store.watch and router.afterEach() return callback functions that remove th hooks when called. We could rerurn those from the main function so you can  use those to remove both the watch and the navigation guard:
const unsync = sync(store, router)

// ... later:
unsync()

// when re-starting the app, call `sync()` again.

@LinusBorg Thanks for the reply! Yes, one of the things I like most about the Vue ecosystem is that most plugins/mixins are often 200 lines of code or less.
I contemplated forking this project but figure it would be better just to unsync.
Depending on your workload, I am ok submitting a PR if that would help get this capability into production sooner.  Please let me know!
Thanks!

Hey, we are always open to PRs, so go ahead if you can! :)
I guess all it would take is assigning the return from this and this line toa variable and then return a function at the end of the main function that would invoke those two when called.
Agreed?

@LinusBorg Yep agreed! Perhaps add a unit test or test case as well?
I can do the PR later Today and submit the request.

A Test case would of course be required, as would be a mention in the README of this repo.

@LinusBorg Sorry for the delay. Added a pull request.  Regarding testing, I wasn't sure exactly how best to test the registration/de-registration of the store, router, and moduleName.  I accessed some internal/private Vuex store properties (but these could obviously change as Vuex gets updated and break the tests).  If you have a better or more clever way, I'm open to suggestions (or just remove those assertions).


region quick search should not show any suggestion if nothing was entered

when user does not enter any suggestions for region quick search, the suggestion should not be populated.
Alternatively, if there are more than 5 entries satisfying the input, display "... and x more"

fixed by #1271 pending 2.8.0 release


[HeroSystem6eHeroic] Added equipment, skill, and power movers.

Submission Checklist
Required

[X] The pull request title clearly contains the name of the sheet I am editing.
[X] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[X] The pull request makes changes to files in only one sub-folder.
[X] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

New sheet line movers for player convenience and for preparation of the Hero Designer import API currently in testing.

Character Sheet Info Roll20 Internal Use only.


image scaling not reflected in layer thumbnail

🐛 Bug
The thumbnail rendering of an image layer shows the data pre-scaling

To Reproduce
import numpy as np
import napari

image = np.random.random(size=(100, 400))
viewer = napari.Viewer()
viewer.add_image(image, scale=(4, 1))
napari.run()

Expected behavior
scaled image should be shown in layer thumbnail

Good idea! I think we just need to divide the ndi.zoom scale factors by the scale... But of course there'll be some axis order bugs lurking... 😬


Fix sce context

rebased and slightly tweaked #14019

Can I merge this in the meantime or do you want this resolved first @mgol?

@Narretz Go ahead & merge, we can look into it later since it requires further investigation, apparently.

Hey, sorry, I left for a few days right when you started the conversation :/ This PR is still fine. As you spotted, there won't be a $sce context anymore for these three. I think having no sanitization there is fine since no browser will execute script there, but if you want consistency you'd just need to add them where sanitization happens: https://github.com/angular/angular.js/blob/master/src/ng/compile.js#L1631 .

@rjamet Ok, I will then re-add track and merge the PR


led.off time delay

I'm a nooby so apologies for probably asking the obvious.
My Python programme turns on an LED using  - button.when_pressed = led.on
I then want the LED to remain lit for 10 seconds or until the switch is activated a second time.
I have tried different options with no success.
Help please.

Ok sure, what you need to do is create a custom function to light the LED for 10 seconds, then set when_pressed to the custom function, rather than led.on:
from gpiozero import LED, Button
from time import sleep
from signal import pause

led = LED(2)
btn = Button(3)

def light():
    led.on()
    sleep(10)
    led.off()

btn.when_pressed = light

pause()

I'm not sure what your exact requirements for the "or until the switch is activated a second time". Do you want it to start the 10 seconds again, if pressed after 5 seconds? I'm not sure how best to interrupt the running of light with another button press. @waveform80, any ideas?
Alternatively to led.on(); sleep(10); led.off() you could use led.blink(10, 0, 1) (on for 10 seconds, run once).

from gpiozero import LED, Button
from time import sleep
from signal import pause

led = LED(4) # or whatever pin you've got it on
btn = Button(17) # again, adjust as necessary

def light_for_ten_seconds():
    led.on()
    sleep(10)
    led.off()

btn.when_pressed = light_for_ten_seconds
pause()

That's one way, but another is to use a "limited" blink:
from gpiozero import LED, Button
from time import sleep
from signal import pause

led = LED(4) # or whatever pin you've got it on
btn = Button(17) # again, adjust as necessary

def light_for_ten_seconds():
    # the n parameter limits the number of blinks to 1
    led.blink(on_time=10, off_time=1, n=1)

btn.when_pressed = light_for_ten_seconds
pause()

Hmm, let's see how else we could do this ... how about a source/values version:
from gpiozero import LED, Button
from time import time
from signal import pause

led = LED(4) # or whatever pin you've got it on
btn = Button(17) # again, adjust as necessary

def stretched(values):
    # Stretches any 1s (button presses) out for 10 seconds
    pressed = 0
    for value in values:
        if value:
            pressed = time()
        yield time() - pressed <= 10

led.source = stretched(btn.values)
pause()

These last two recipes have the advantage that button presses during the LED being lit will extend it for a further 10 seconds from the press, whereas the first won't because the handler doesn't return until 10 seconds have elapsed.
Now, let's pimp out the last one:
from __future__ import division # in case you're on py2
from gpiozero import PWMLED, Button
from time import time
from signal import pause

led = PWMLED(4) # or whatever pin you've got it on
btn = Button(17) # again, adjust as necessary

def stretched(values):
    # Stretches any 1s (button presses) out for 10 seconds
    pressed = 0
    for value in values:
        if value:
            pressed = time()
        # fade out after the press
        yield max(0, 10 - (time() - pressed)) / 10

led.source = stretched(btn.values)
pause()

Doh - @bennuttall beat me to half those ideas ;)

Here's a (slightly more complex) version of something similar I came up with the other day http://raspi.tv/2015/gpio-zero-test-drive-making-light-of-security#comment-60978
Apparently (according to the reply) it doesn't work, but I haven't yet got round to testing / debugging it myself.
But (unsurprisingly) @waveform80 's stretched approach looks like a much neater solution ;)

Neat solution @waveform80

I like @waveform80 's long blink!

To be honest, that last "fading" version is probably also more easily done with a limited blink but I had to work some source/values stuff into there somewhere :)

Many thanks to all for their quick and helpful responses.
So here's the scenario.  The RPi will be operating outdoors, powered by a power pack and not connected to the internet.
The switch will be a vibration detecting switch located on the top of a wooden upright.  When the upright is contacted either forcibly or very lightly by a ball the switch will bring on an array of 4 LEDS wired in parallel (powered separately from the RPi) and switched by a transistor.   I am happy to take guesses regarding the sport!  After 10 seconds the lights will go off and the program continue as before (ie sensitive to vibrations).    I thought I would put a regular switch in parallel with the vibration switch to turn off the LEDs before the 10 seconds were up (it might be easier to just wait 10 seconds).  I will try all of the submitted ideas and feedback in due course.  BD

I don't think a "regular switch in parallel" would work to turn the LEDs off again - even if you did get the code working to do that, you'd probably find that the vibration sensor triggers many times for each "hit" (while it's still vibrating), and so the sensor itself would cause the LEDs to switch off again!
I think if you wired up your regular switch to an additional GPIO on the Pi, then something like this might work:
from gpiozero import LED, Button
from time import time
from signal import pause

led = LED(4) # or whatever pin you've got it on
sensor = Button(17) # again, adjust as necessary
btn = Button(18) # again, adjust as necessary
pressed = 0

def stretched(values):
    # Stretches any 1s (sensor readings) out for 10 seconds
    global pressed
    for value in values:
        if value:
            pressed = time()
        yield time() - pressed <= 10

def lights_off():
    # Stop the stretched function from lighting the LED
    global pressed
    pressed = 0

btn.when_pressed = lights_off
led.source = stretched(sensor.values)
pause()

Obviously you'd need to make sure that the button attached to GPIO18 is only pressed after you're sure your sensor has stopped vibrating.

Just because I hate globals :)
from gpiozero import LED, Button
from time import time
from signal import pause

led = LED(4) # or whatever pin you've got it on
sensor = Button(17) # again, adjust as necessary
inhibit = Button(18) # again, adjust as necessary

def stretched(sensor_values, inhibit_values):
    # Stretches any 1s (sensor readings) out for 10 seconds
    for sensor_value, inhibit_value in zip(sensor_values, inhibit_values):
        if inhibit_value:
            pressed = 0
        elif sensor_value:
            pressed = time()
        yield time() - pressed <= 10

led.source = stretched(sensor.values, inhibit.values)
pause()

Incidentally that'll only work in Python 3; Python 2's zip doesn't do lazy evaluation so it'll try and enumerate the two infinite iterators ... rather unsuccessfully. If you need it to work in Python 2 bung the following at the top:
try:
    # Make Python 2's zip like Python 3's
    from itertools import izip as zip
except ImportError:
    # We're on Python 3 so nothing to do
    pass

Zip is a hugely useful function with source/values stuff as it lets you combine as many sources together as you like in a single function and synchronously read things from each of them.

@waveform80 I also hate globals.

Sorry, I was just being lazy :-/
(and I'm not as expert at using all the iterator-based functions as @waveform80 yet)
Does the for x, y in zip(xiter, yiter): syntax/notation guarantee that (as near as dammit) the xiter and yiter both get read at the same time? Or if the xiter took longer to produce its value, would that result in the yiter being read later than the xiter? And if that's the case, and you know that you have one iterator that's 'slower' than the other, should you put the slower iterator last in the call to zip? (although perhaps at the end of the day it makes little actual difference)
Not sure how well I explained that...

Ahh, the thing to remember is that the iterators don't have any pauses in them (by default) - it's the source thread which implements a minor delay between reading values from whatever it's been given. So, zip will indeed read the iterators damned near simultaneously (can't be precisely simultaneously but given that zip is C-based it'll be very close). As to what order zip actually reads its stuff in, I'm not 100% sure (haven't delved into Python's source) but I'd assume left to right.
Incidentally I said no pauses by default because you can place pauses in the iterators with the new pre_delayed and post_delayed functions, but that's just complicating matters :)

the thing to remember is that the iterators don't have any pauses in them (by default)

I was thinking specifically about the slow iterator (generator?) that you introduced back when I was first asking about generators... ;-)

Yeah, pre_delayed and post_delayed are variants on that which just position their delay before or after the yield accordingly. However, that's on the generator side of things; the new source_delay thing in 1.2 introduces the delay on the source side which adds a little more flexibility to the system and simplifies things a bit (means you don't have wrap everything you assign to a source for instance).


Influx 0.9.0 is crashing

I have followed below command to install influx
wget https://s3.amazonaws.com/influxdb/influxdb-0.9.1-1.x86_64.rpm
sudo rpm -ivh influxdb-0.9.1-1.x86_64.rpm
From UI if I execute "select * from SeriesName", Influx is crashing. SeriesName does not exist into DB. It suppose to return empty data set instead of crashing. Is there anything I am missing during installation?

@buro1983 are you running with the default configuration?

Yes

Just to be clear, InfluxDB does not panic when a non-existent series is selected:
$ curl -G http://localhost:8086/query --data-urlencode "q=CREATE DATABASE foo"
{"results":[{}]}
$ curl -G http://localhost:8086/query --data-urlencode 'q=SELECT * FROM cpu'
{"results":[{"error":"database name required"}]}
$ curl -G http://localhost:8086/query?db=foo --data-urlencode 'q=SELECT * FROM cpu'
{"results":[{"error":"measurement not found: \"foo\"..cpu"}]}

@buro1983 - if you can show a sequence similar to this that does crash, can you share it?

@buro1983 i can't reproduce this on master, so i'm going to close it out. if you're able to make it happen on v0.9.2 or higher, please let me know!