Default time encoding of nanoseconds is NOT good.

What happened?
When you call to_netcdf() on a Dataset without an encoding for the time variable set, you get: "nanoseconds since ..."
This is not good, as nanoseconds aren't support by a lot of downstream software, e.g. cftime, etc. (I'm not sure if it's CF compliant).
I see that this was changed somewhere after #3942
It is an improvement over integer days, that's for sure, but not the best option.
I understand that the internal panda datetime64 type is ns -- and this preserves any precision that may be there, but:
"practicality beats purity"
And this is not practical. Frankly, I wonder why pandas chose nanoseconds as the default, but it seems like the common xarray (and netcdf) use cases, ns is completely unneeded precision.
I'd suggest integer milliseconds, or, frankly even seconds.
Alternatively, use, say, floating point hours, which would buy you a lot of precision for small values -- I can't imagine who is using nanoseconds and also cares about years of timespan.
What did you expect to happen?
No response
Minimal Complete Verifiable Example
No response
MVCE confirmation

[ ] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
[ ] Complete example — the example is self-contained, including all data and the text of any traceback.
[ ] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
[ ] New issue — a search of GitHub Issues suggests this is not a duplicate.
[ ] Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output
No response
Anything else we need to know?
No response
Environment

@ChrisBarker-NOAA could you provide a minimal working example?  While there are select circumstances where xarray will do this, I do not think this should be the case in general.

@ChrisBarker-NOAA In general xarray tries to encode times to the lowest possible resolution.
So if the wanted resolution is say days and the data itself can't be represented like that, then the next fitting resolution is calculated (eg. hours).
This also works if no resolution is given. Xarray tries to calculate that resolution where all data can be represented in.
There might have been changes in these parts of the code or other changes in behaviour due to dependency updates. I second @spencerkclark here, a MCVE would help to debug.

To add a little more context, @ChrisBarker-NOAA you are right to point out that my comment (https://github.com/pydata/xarray/issues/3942#issuecomment-966264200) ignores considerations such as downstream (non-xarray or even non-Python) use-cases and (possibly) CF compliance, which I think may have been additional (perhaps more fundamental) reasons that xarray did not support encoding units finer than seconds previously (https://github.com/pydata/xarray/issues/4183#issuecomment-651404825).  If I were to write it again I would probably not have been as absolute.
As @kmuehlbauer notes, for NumPy arrays of times we still try to use the coarsest possible resolution that enables exact encoding with int64 values.  To me this represents a reasonable compromise.  For users whose dates do not need nanosecond precision, times continue to be encoded with coarser units, but for users whose dates do need it, times are encoded with finer units such that they can be exactly round-tripped to / from disk (https://github.com/pydata/xarray/issues/4045, https://github.com/pydata/xarray/pull/4684).
For chunked arrays—and maybe this is what you are running into—there was a recent change to use "nanoseconds since 1970-01-01" as the default units if no encoding is specified (https://github.com/pydata/xarray/pull/8575).  The rationale there was that to infer the coarsest possible units that would enable an exact round trip would otherwise require a full compute (enabling lazy encoding was the primary premise of that PR).  Even though this is an advanced use-case, I understand that this could be surprising and/or inconvenient depending on the application.  Does the time data you are writing to netCDF happen to be chunked?

@spencerkclark: yup, that's probably it.
We've been bitten by this a fair bit lately -- always(?) when loading a Dataset from some kind a remote dataset: OPeNDAP, Zarr (via kerchunked data on AMS), or MFDataset, etc.
Then the time encoding gets lost or a new time array is created for one reason or another, and we end up with the nanosecond-based-encoding.
So yes, chunked.
Another issue is that it's all too common for folks to use a float datatype in the time variable, which means you get essentially arbitrary precision. (would you even get nanoseconds? not sure, I haven't done the math.)
So what to do?

looking at the past issues I see, folks did want milliseconds, but has anyone asked for nanoseconds? (i know, if it works, folks could be using them without us knowing it). I do think that defaulting to seconds was probably too coarse. So we could simply change the default to miliseconds, and I think that would solve the problem at hand.

Why do we get datetime65[ns] be default when decoding a netcdf file? I'm guessing that's inherited from Pandas, and  maybe isn't easy to change, but if it could be changed, we could use [us] or even [s] (or some kind of smart decoding) instead - and then we're good to go.

-CHB

Hmm -- if this is right (from a random unrelated issue on some other project):
"Since 2.0.0 [pandas] actually supports timestamp precisions other than nanoseconds"
Looks like it:
https://pandas.pydata.org/docs/whatsnew/v2.0.0.html#construction-with-datetime64-or-timedelta64-dtype-with-unsupported-resolution
So maybe there's the solution :-)

@ChrisBarker-NOAA One reason to use datetime64[ns] internally is that we can keep the int64 representation in memory (and on disk) also in the presence of NaT. np.datetime64('nat') and the netcdf default fillvalue for int64 are the same -> -9223372036854775808 (see netcdf.h).
In case of encoded _FillValue/missing_value we can use int64 throughout instead of having to convert to float (to represent the nan values). The latter has lead to a bunch of issues in the past, where ns precision was lost. See #7817 and #7872.
Please also see https://github.com/pydata/xarray/issues/7493 where the new pandas non-nanosecond datetimes are discussed.
I did not look deeper into this new behaviour, but it should be possible to make xarray aware of non-nanosecond datetime resolution. I fear this will be a major undertaking, though.

One reason to use datetime64[ns] internally is that we can keep the int64 representation in memory (and on disk) also in the presence of NaT. np.datetime64('nat') and the netcdf default fillvalue for int64 are the same -> -9223372036854775808

Which is a good reason to use datetime64 -- (and 64 bit integers in general) -- but numpy's datetime64 can choose what "unit" you want, so datetime64[ms] or datetime64[s] satisfies these same criteria.

The latter has lead to a bunch of issues in the past, where ns precision was lost. See https://github.com/pydata/xarray/issues/7817 and https://github.com/pydata/xarray/issues/7872.

Very good reasons not to covert to float -- so yes, but I'm not suggesting that.
Frankly, numpy's datetime64 was not all that thoroughly reviewed before it was implemented, and has been trouble ever since :-( -- but that's water under the bridge.
As for nanoseconds: I suspect that was chosen by pandas originally, because "why not" -- i.e. lots of extra bits to use.
But whether xarray continues to use ns internally is another question -- has ANYONE ever asked for ns?
But a breaking change is a breaking change, which is not good.

I did not look deeper into this new behaviour, but it should be possible to make xarray aware of non-nanosecond datetime resolution. I fear this will be a major undertaking, though.

An easier option would probably be to go to datetime64[ms] instead, though somewhere out there is someone actually using nanoseconds that might complain :-(
But it may not be THAT major an undertaking -- grepping the code, there are indeed a lot of references to datetime64[ns]. but when you remove the tests and docstrings -- not all that many.
so. maybe a lot to change, but mostly boilerplate :-(
The first question is -- would this be a welcome change? If so, maybe I can take a look ...
Option 1) Change [ns] to [ms] as the static xarray datetime.

that would be easier, solve the problem at hand, and probably work for 99.9% or users.
But
a) are there any users out there that  SO actually need nanoseconds?
b) it would break (or at least be confusing) a lot of demos, docs, etc.

So:
Option(2) is probably the way to go -- let it be settable -- and then we can decide where to change the default -- e.g. I would suggest using [s], or maybe [ms] for default netcdf decoding, for instance.
How good do we think the test coverage is ?
Finally: option (3) -- just change the default behavior for encoding netcdf (or other similar formats (zarr) -- essentially any time you are doing a "units since datetime" encoding, use milliseconds.
That would be relatively easy, and I suspect break very little -- and anyone that does need nanoseconds could specify that.

@spencerkclark: yup, that's probably it.

Thanks @ChrisBarker-NOAA, that's good to know.  For this issue, my first thought was something along the lines of your option (3) for chunked arrays.  The idea would be to switch to using default units of "seconds since 1970-01-01" or "milliseconds since 1970-01-01" in that context and continue using a default dtype of int64.  If finer precision were required to encode the times for a faithful round trip, we would raise an error, recommending explicitly specifying the units encoding.  While this would lead to a slightly worse user experience for those who might want / need nanosecond encoding units in the chunked array context[^1][^2], it would be a better user experience for those who do not, at least in the context of downstream uses.
Indeed as @kmuehlbauer notes, we are aware of the new flexibility in pandas.  I agree that it would be a nontrivial amount of work to enable that flexibility in xarray.  There probably is a lot of boilerplate, but I think there are a few things we'll need to think carefully about too.  It is likely best to separate that from this issue.
[^1]:  We have had some users ask for nanosecond-precision decoding before (#4183), and it is important for faithfully roundtripping some times (#4045 (comment)).  It is admittedly rare, however.
[^2]: pandas-dev/pandas#7307 (comment) provides some historical context for why nanosecond precision was initially chosen in pandas.

Should we keep this open or move the pandas impl to a new issue?

I'd like to keep it open:
There are two (maybe separate) issues here:

should xarray support pandas' new ability to specify the time unit?
what should be the default "CF style" encoding?

Granted, if (1) is done, then (2) could be whatever the user specified (though there would still be a default to decide)...
But it will take a while to get (1) done -- so I still advocate for changing the default for the "CF style" time encoding.
@spencerkclark: thanks for the link to the Panda's discussion -- very enlightening. A key take-away from from me:
"realize that pandas's plurality use case (if we were truly omniscient) nowadays is in the analysis of data generated by business processes occurring since the advent of computers."
That was true then, and may still be true now for Pandas -- but it's likely not true for xarray, and particular not true for folks using the CF-style encoding. Those users would rather a cftime compliant encoding, and don't need nanoseconds. (we know they don't because it's not actually supported anyway!)
So I still think that xarray should change its default CF-style encoding to microseconds sooner than later, regardless of how (1) proceeds.

For sure, @ChrisBarker-NOAA, I am in agreement that we should switch away from specifying nanoseconds units by default for datetime64[ns] data stored in dask arrays.  The one thing I want to make sure of when we make that switch is that we never silently truncate precision when writing chunked data to disk (i.e. we at least warn or raise an error), which is not currently the case, e.g. https://github.com/pydata/xarray/issues/9134#issuecomment-2191446463.  Nanoseconds at least have the virtue that we are never at risk of that.
Note that in the meantime xarray uses microseconds by default for chunked arrays of cftime.datetime objects, so if you open data with use_cftime=True this will already be the case regardless of the calendar of the data.

I'm a bit confused about dask vs chunked vs netcdf or ???.
I would assume that you can use dask arrays themselves with the native numpy datetime64? yes?
Anyway, my use case is saving out a xarray Dataset to netcdf4, when a time variable does not have unit defined -- it has been saving out in (nanoseconds since ...) which then breaks code that tries to read the resulting file (e.g. cftime python lib).
But:
https://github.com/pydata/xarray/blob/20cde77f3e39a6656116dd50fb78ef02e3fe4dc2/xarray/coding/times.py#L834-L836
seems to indicate that it woule use microseconds -- did that code change recently?
I'll go test now ....

I want to make sure of when we make that switch is that we never silently truncate precision when writing chunked data to disk (i.e. we at least warn or raise an error)

Agreed -- silent data loss is bad. However, that would require actually checking all the values -- which may not be available, yes?
Anyway, if it can be checked, then Error or Warning?
Warning seems right to me, though people do tend to ignore them, particularly if it's running on some service, rather than interactively.
But Error is a problem because then code that has worked fine with all the test data, etc, might then raise when passed some new data. (and if time was converted (or computed) from, e.g. floats, might have spurious sub-microseconds in it.)
So: if there's going to be an Error, then it would be good to have a flag that you can set to turn it off:
allow_truncation_to_microseconds
or some such -- not sure where that flag would go though.
Thanks,
-CHB

OK -- did some more experimenting, and I think I get it now why this is about chunked data -- if not chunked, xarray seems to examine the values and choose a reasonable encoding -- nice! Thanks to whoever write that code!
But I presume with chunked arrays, you can't examine all the values at once, so can't follow that precident.

if you open data with use_cftime=True (and the time encoding gets lost) this will already be the case regardless of the calendar of the data.

I'm trying to remember where we had this problem, because that was not our experience. I'll have to poke about some more, but I think it may have been:

wonky, non cf-compliant time in a file

in fact, part of the goal of this workflow was to fix the time :-)
because of this, we had to open it without use_cftime=True

So when written out, the nanoseconds default was used.

My proposal:
Define a flag (somewhere -- not sure where) along the lines of:
truncate_to_microseconds
When True, then microseconds would be the minimum unit used.
When False, use current behavior.
I would prefer True be the default, but if we do think we'll break folks' code, then False is OK. At least we'll have an easy fix when this comes up.

Agreed -- silent data loss is bad. However, that would require actually checking all the values -- which may not be available, yes?

While we indeed cannot infer the appropriate units to choose without examining the entire variable, we should be able to determine whether the a priori chosen units allow for exact encoding of each chunk independently and warn or raise accordingly within each subtask.

I'm trying to remember where we had this problem, because that was not our experience. I'll have to poke about some more, but I think it may have been:

wonky, non cf-compliant time in a file

in fact, part of the goal of this workflow was to fix the time :-)
because of this, we had to open it without use_cftime=True

So when written out, the nanoseconds default was used.

I see—with this workflow I believe it would still be possible to ensure cftime.datetime objects are used—I'm assuming you are opening the data with xr.open_dataset(..., decode_times=False), fixing the time encoding units, and then running xr.decode_cf on the Dataset?  In this case use_cftime=True would be passed to xr.decode_cf instead of xr.open_dataset.
The other workaround of course is to load / compute all the time-like variables before saving to disk—it is not that common that time arrays in climate datasets require a lot of memory or are computationally expensive to produce, so this generally is not so bad (for many years xarray happened to do this automatically—i.e. it did not lazily encode chunked time-like arrays).
Up to you though whether these implicit workarounds are more intuitive than the explicit workaround of manually specifying the time encoding units, which is generally what I do if I know a downstream application is sensitive to the choice, even if the times are in memory :).


getopt completion

Description

Motivation and Context

How Has This Been Tested?
Completion tested manually inside interactive Bash session.
Screenshots (if appropriate):

Types of changes

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

Checklist:

[ ] My code follows the code style of this project.
[ ] If my change requires a change to the documentation, I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
[ ] I have added tests to cover my changes, and all the new and existing tests pass.

Hi @EmilySeville7cfg !
So this looks interesting but I'm not quite sure its really useful?
getopt isn't a command that people usually enter on the command line, is it?
Isn't it mostly used within your script to parse your script's arguments?
Do you use this completion as a testing tool when configuring getopt in your scripts?
I'm not sure how completion against the getopt command line options themselves is useful?
I'm not rejecting this PR, but just wanting to have more conversation about how its used

Isn't it mostly used within your script to parse your script's arguments?

Yes, but sometimes it can be used from interactive session to test something. ;)

Do you use this completion as a testing tool when configuring getopt in your scripts?

Yes, because it's convenient to see available option values for getopt while typing. I don't want to run any other command to see available functions for instance, I can use just -n|--name option complete to explore them.
I don't know where to better send such PRs: here or to bash-completion repo.

$0.02: I would like having this available. Should note that it requires modern Bash, not the old v3.2 on Mac (😞).

Isn't it mostly used within your script to parse your script's arguments?

Yes, but sometimes it can be used from interactive session to test something. ;)

Do you use this completion as a testing tool when configuring getopt in your scripts?

Yes, because it's convenient to see available option values for getopt while typing. I don't want to run any other command to see available functions for instance, I can use just -n|--name option complete to explore them.
I don't know where better send such PRs: here or to bash-completion repo.

I think bash-completion would be a better parent for this, but IMHO I'm alsö happy to have it here until it goes there 😃


Change RayCast3D gizmo to arrow

Fixed #19793
Changed gizmo to arrow shape as @QbieShay suggested in the issue and @Calinou suggested in #33103.
Arrow looks the same like for directional light. Small ray cast length (less then 1 unit) scale whole gizmo. For gizmos with length greater than 1 unit arrow head is not scaled.
My only concern is if it is still usable for long ray casts (like 50 and more).
It it is ok (or would be after review) maybe would it be a good idea to move this code to EditorNode3DGizmo than we could reuse it for directional light.

@Mielek I don't know about this one. If it's as wide as the arrow for the directional light, people might assume the raycast has some kind of radius. In my opinion a simple line is the best representation for a raycast (it could be a bit thicker tough) because you can see the exact point where it's colliding. Assume for example, that the ray head is inside an object: now you would have to eyeball the center of the arrow body to determite the collision point.
Maybe i'm wrong and it looks fine. Could you post some screenshots in action?

@mbrlabs Thanks for the remarks!
Arrow is not as big as for directional light. Here you have a comparison.
I see your point. I think it would be a problem in super-precise cases. Here you have a screen where I ray cast from inside one box to the inside of another.

I have done some resizing and gizmo could look like in the following screens.

Still, if you zoom into the arrow shaft you will see

I have prepared another variant that uses a cylinder mesh but does not contain an arrow tip.

Please let me know which of these propositions is the best one.

I like the thin arrow as it helps see the raycast from afar without making it too large, but I think you should also keep the central line for more precise visualisation. I would avoid the cylinder mesh as its diameter could become a problem depending on the zoom level.
I vote for the thin arrow + the current line (maybe slightly thicker).

Very nice, thank you! I prefer the cylinder because it looks cleaner than the arrow variants. If you go for the arrows a would choose a size in between the arrow in your first screenshot and the very thin one.
@Calinou What do you think?

Superseded by https://github.com/godotengine/godot/pull/46529 (which provides more features). Thanks for the contribution nonetheless!


Documentation updates

Problem description
Two issues:

lastLocationTime added in VerifyLocationResponse schema needs to be reflected in the examples.
When maxAge conditions fail, it can result in UNKNOWN location response as discussed in here. However, it is better to capture the conclusion in the specification

Expected action
Spec update

@sfnuser please review PR #104


Platform-specific builds via Platformio

Supercedes #28, #30, and #31, which I left stale and for some reason.
For the third (and last) time, this PR introduces platform-specific parts of the runtime that PlatformIO knows to link in for specific frameworks and boards. It probably also changes a bunch of other stuff. I'll self-review and make note of any other important changes.

Codecov Report

Merging #32 (b2689ff) into main (63e72c5) will decrease coverage by 0.20%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #32      +/-   ##
==========================================
- Coverage   58.92%   58.71%   -0.21%
==========================================
  Files           4        4
  Lines         280      281       +1
  Branches       67       67
==========================================
  Hits          165      165
- Misses         97       98       +1
  Partials       18       18

Impacted Files
Coverage Δ

src/ssm-scheduler.c
76.82% <0.00%> (-0.52%)
:arrow_down:

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

I still need to thoroughly document the Zephyr-related stuff, but that also requires some reorganization of the documentation. I'm going to forego this for now in favor of merging this now so that I can unblock some other PRs.


[Suggestion]: Package and repo name

I have a minor suggestion to be consistent with other PixiJS ecosystem extensions:

Module name @pixi/react-pixi to be @pixi/react
https://github.com/pixijs/pixi-react to be https://github.com/pixijs/react
Project name "React Pixi" to be "PixiJS React"

Hey @bigtimebuddy, we had a bit of discussion on slack about this cc @GoodBoyDigital @Zyie .
My thoughts were:

If we use @pixi/react this looks like it's a fork of react
If we use pixi-react rather than react-pixi it implies that we're rendering react inside of pixi whereas we're actually rendering pixi inside of react
It's standard terminology for react related libraries to be named with the react- prefix

What do you think?

I see your points. That said, I still am in favor of the original proposal above for a few reasons:
In my opinion, the goal of this project should be primarily to serve the PixiJS community, and probably secondarily the React community. We have Node.js, Canvas, Webworker and OffscreenCanvas rendering... the goal for PixiJS is to expand environments where PixiJS can run. That has always been consistent with our mission (maximizing the devices, browsers and runtimes that can render PixiJS content). I look at this project as inline with that mission.
PixiJS is not in the business (and shouldn't be) of forking React. Similarly, we also have a @pixi/node package and no one is confusing with us forking Node.js. That is not something that I'm overly concerned about.
Lastly, in terms of the react- prefix... again, we are building this project for the PixiJS community first. I don't feel a need to use the naming conventions the React community has adopted if they have no functional benefit (as opposed to maybe babel, eslint, etc that use the convention for a configuration shorthands).
I respect the final decision of the folks here to determine what's best for the project, but I thought that this context might be helpful to how I think about the goal, mission, reach and opportunity of this project relative to the large PixiJS project.


Merge control requests

This PR is part of an effort to improve control request latencies by implementing proposal 4 and 5 in the design doc https://docs.google.com/document/d/1PZAOwpw09tVDeuSP0OBVhB6dbgz7C7dQU6bRkePQ8qg/edit#
Below are the list of changes

adding a new control RPC type with LiCombinedControlRequest and LiCombinedControlResponse, which is used to merge the 3 different types of control requests

adding logic on the controller side to merge 2 out of the 3 types of control requests: LeaderAndIsr and UpdateMetadata requests.
As for the StopReplica requests, each request either has or does not have a callback depending on the deletePartitions field. Triggering the callback properly requires differentiating the partitions based on their deletePartitions field in the response. I'm leaving that as future work.

adding logic on the broker side to decompose the LiCombinedControlRequest into a LeaderAndIsr request and an UpdateMetadata request

adding logic on the controller side to decompose the LiCombinedControlResponse into a LeaderAndIsrResponse and a UpdateMetadataResponse and trigger the proper callbacks.

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Closing this PR as it's being broken into smaller ones for easier review.


build: allow Node 10 to push to codecov

Allow Node 10 builds to push to codecov

Codecov Report

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

@@           Coverage Diff           @@
##           master     #396   +/-   ##
=======================================
  Coverage   98.05%   98.05%
=======================================
  Files           5        5
  Lines         617      617
  Branches      145      145
=======================================
  Hits          605      605
  Partials       12       12

Continue to review full report at Codecov.

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


InfluxDB Cloud: email notification endpoint for alerts

Proposal:
Provide new notification endpoint type for alerts: email address.
Current behavior:
Only HTTP, Slack and Pagerduty endpoints allowed.
Desired behavior:
Sending alerts to specified email address allowed.
Use case:
Email address is simplest and widely used way to receive alerts and notifications.

@melanchall thanks for the issue. Makes total sense. A very hacky short term workaround is to use an API based email service and make an http post request to them.

@russorat, thanks for answer. I'll wait for new endpoint :)

Would make life easier if SMTP email was available out of Influx2!

Update?

Check out or docs on how to send email from the platform for common api based email services: https://docs.influxdata.com/influxdb/cloud/monitor-alert/send-email/


memory leak

when passing a long text, like 20MB long, the script will soon run out of the computer's memory. My machine has 16GB of RAM, it takes about 5 minutes to freeze.

I notice this as well, huge memory leak that does not improve by invoking python's garbage collector

Hi @fbarrios ,
I've noticed the memory leak if you attempt to summarise/extract keywords from many small documents. It seems that it might be retaining in memory things that it shouldn't (previous graphs maybe?).
Attempt it yourself, get an extensive corpus of small articles (like news articles) and extract keywords from all of them, and you'll very quickly see the used memory jumping to +16GB.
Cheers

Profiling with cProfile, when the issue occurs for me, execution seems to be stuck in graph.py:159:edge_weight(), with tons of calls. The relevant edge_weight call is in pagerank_weighted.py:50:build_adjacency_matrix().
My guess is that it is due to there being too many sentences and/or too many connections between sentences, and since the adjacency matrix runtime is O(n^2) relative to number of sentences, this can blow up if there's lots of sentences.
A quick, dirty fix is to limit the number of sentences to some maximum in the keywords() method, though of course then you won't be analyzing the whole text anymore.
Switching over to a sparse adjacency matrix and estimating likely candidates, as described on https://cran.r-project.org/web/packages/textrank/vignettes/textrank.html might make it feasible for larger documents. But I don't know your codebase or the textrank algorithm well enough to implement it myself.


Feature Suggestion: Total Bitcoin by the TheTotalConnector

With my Bitcoin Only-Podcast-Show (Keyvan Davani-TheTotalConnector / Total Bitcoin), I have been doing many interviews and/or panel-discussions with prominent Bitcoiners and rational (Austrian) Economists since April 2019.
My main-podcast-platform is: anchor.fm/keyvandavani.
(Directly to be listened on my website: keyvandavani.com/podcast or as Video-Version on my channel: youtube.com/c/keyvandavani
or: TheTotalConnector.com).
Other Podcast-Platforms:
Apple Podcast: https://apple.co/2IA2dhV
Google Podcast: https://bit.ly/31rSymq
Spotify: https://spoti.fi/2wOfq1k
Breaker: https://bit.ly/2IzhiQO
Overcast: https://bit.ly/2R4nnbJ
Castbox: https://bit.ly/34DbM97
Pocket-Casts: https://bit.ly/2XElbKv
Radio Public: https://bit.ly/2I86iuH
Here are my Articles on Bitcoin vs. the (criminal) State/Govs./Central Banks etc.
medium.com/@keyvandavani
Since June 2019, I have organizing small Bitcoin-Only-Meetups in Vienna and surrounding areas, where German-speaking and international Bitcoiners or people with a focused curiosity for Bitcoin came to the meetings for sharing knowledge and asking concrete questions (technical, Hodling, Hardware Wallet, monetary-economical aspects etc.).
Bitcoin & Austrian Economics Meetup-Group Vienna:
https://www.meetup.com/de-DE/Wien-Bitcoin-Meetup-Gruppe/
In order to educate to reach and educate more German-and English-speaking people on Bitcoin, the integration of my Bitcoin only Podcast & Meetup (in Vienna/ Austria,  and beyond) into
bitcoin-only.com is really overdue and would be extremely important and effective.
Thank you for all your work and ethos in Bitcoin!
Best wishes
Keyvan Davani

Added

Hey, please, correct my podcast link (TheTotalConnector).
anchor.fm/keyvandavani
Thank you!
Keyvan

fixed


bug: config differences in cli subcommands | "Failed to read genesis file..."

Bug Report
Madara version:
branch: main
version: 0.4.0
Current behavior:
With default arguments, the run and setup subcommands read and write from separate locations, respectively. This is caused by different default behavior if the chain id is omitted. This results in confusing errors on mismatched paths if a developer follows the documentation steps.
As a side note: the expected behavior occurs if the user passes in --chain dev for the setup subcommand, but this isn't mentioned in the --help for setup but it should be.
Expected behavior:
Both commands should accept reasonable defaults, and I think the reasonable default is dev for local development. Documentation including readmes and CLI help cmds should reflect this as well as any overrides. Tests should confirm the behavior.
Steps to reproduce:
Attempt the setup function. It should place the files in a location which the filesystem lookups in the run subcommand won't expect:
cargo run --release -- setup --from-remote
Run it:
cargo run --release -- --dev
``
This should panic with:
====================

Version: 0.4.0-5003054b326

   0: backtrace::capture::Backtrace::new
   1: sp_panic_handler::set::{{closure}}
   2: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/alloc/src/boxed.rs:2021:9
      std::panicking::rust_panic_with_hook
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:733:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:621:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/sys_common/backtrace.rs:170:18
   5: rust_begin_unwind
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:617:5
   6: core::panicking::panic_fmt
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/core/src/panicking.rs:67:14
   7: core::result::unwrap_failed
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/core/src/result.rs:1652:5
   8: madara::chain_spec::load_genesis
   9: madara::chain_spec::development_config::{{closure}}
  10: sc_chain_spec::chain_spec::GenesisSource<G>::resolve
  11: <sc_chain_spec::chain_spec::ChainSpec<G,E> as sp_runtime::BuildStorage>::assimilate_storage
  12: sp_runtime::BuildStorage::build_storage
  13: madara::genesis_block::MadaraGenesisBlockBuilder<Block,B,E>::new
  14: madara::service::new_full
  15: tokio::runtime::park::CachedParkThread::block_on
  16: tokio::runtime::runtime::Runtime::block_on
  17: sc_cli::runner::Runner<C>::run_node_until_exit
  18: madara::command::run
  19: std::sys_common::backtrace::__rust_begin_short_backtrace
  20: std::rt::lang_start::{{closure}}
  21: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/core/src/ops/function.rs:284:13
      std::panicking::try::do_call
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:524:40
      std::panicking::try
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:488:19
      std::panic::catch_unwind
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panic.rs:142:14
      std::rt::lang_start_internal::{{closure}}
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/rt.rs:148:48
      std::panicking::try::do_call
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:524:40
      std::panicking::try
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panicking.rs:488:19
      std::panic::catch_unwind
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/panic.rs:142:14
      std::rt::lang_start_internal
             at /rustc/249595b7523fc07a99c1adee90b1947739ca0e5b/library/std/src/rt.rs:148:20
  22: _main

Thread 'main' panicked at 'Failed to read genesis file. Please run `madara setup` before opening an issue.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', crates/node/src/chain_spec.rs:157

Reproduced on macbook T2 macos Ventura Version 13.0 (22A8380)
Related code:
Default behavior for running the node, which defaults a chain id dev for the path
vs.
The setup code's fallback to an empty string.
Other information:

Ah, yeap I was looking at an old doc page which caused the confusion. Thanks for checking


feat(annotate): support injection of @ function parameters in CoffeeScript 1.9

With the release of CoffeeScript 1.9, they changed the strategy for the
generation of internal compiler variable names. This means using
function parameters prefixed with an @ no longer are injected
properly due to CoffeeScript converting them to an _at_. (ie. @myVal
becomes _at_myVal). This commit adds support to the Angular
annotator for this.

Huh, I am actually not a big fan of angular accomodating compile to js languages. Isn't there a way to escape this inside Coffescript?

Ya, I'm not a fan either. It was a very nice convenience to have this shortcut for testing. At this point, I'll probably just have to lock it down to CoffeeScript 1.8 for existing code and quit using @vars in injected functions on future tests. I didn't see a way to configure or escape this in CoffeeScript itself.

Made an issue. (jashkenas/coffeescript/issues/3856)

Ok, I'm blind. Found this: https://github.com/jashkenas/coffeescript/issues/3816
Turns out a future release should fix our issues.


Added Moderation/Fun category

Moderation - Purge
Fun - 8ball, choice

APPROVE: // isn't a comment, # is, commits look good


Nested msubs

Issue Summary - Please see the attachment. Eq 34 shows the problem. There’s a nested m:msub w/in m:sub. The second “2” should be sub to the first “2”, not at the same level. The same sort of thing worked just fine in the nested m:msup w/in m:msup case (eq 33).
Steps to Reproduce
This is a bug because...
nested msubs.docx
Technical details

MathJax Version: master - latest commit:  MathJax.js v2.7.5
Client OS: Windows
Browser: Chrome v89.0.4389.114

MathJax uses TeX's layout for superscripts and subscripts, and in TeX, there is very little difference between the heights of the two subscripts.  Here is TeX's output:

and this is MathJax using the MathJax TeX fonts:

These are nearly identical.  Using the STIX fonts (as you appear to be), MathJax produces:

This is admittedly fairly close to the same vertical position, but not quite.  In any case, TeX does not produce the large vertical difference that you are requesting, so MathJax doesn't either.
If you want to get more space, you could use something like {R_{2\mathstrut}}_2, which could be coded as
<math xmlns="http://www.w3.org/1998/Math/MathML">
  <msub>
    <msub>
      <mi>R</mi>
      <mrow>
        <mn>2</mn>
        <mphantom>
          <mpadded width="0">
            <mo stretchy="false">(</mo>
          </mpadded>
        </mphantom>
      </mrow>
    </msub>
    <mn>2</mn>
  </msub>
</math>

in MathML.  This produces

I would discourage you from using such constructs, however, as these are visually ambiguous:  Does it represent {R_2}_2 or R_{2_2}.  The visual distinctions between these two are very small, and can lead to confusion about what you are presenting.  The usual reading of the last diagram would be as R_{2_2}, and one usually includes parentheses for the other one, as in \left(R_2\right)_2.  The same goes for R^{2^2} versus \left(R^2\right)^2.

Thank you, that was helpful. I appreciate you responding. I think this example was just sort of a silly, non-real-life example that we had in one of our test files. Looking through a few other examples we had, they look totally fine to me in MathJax, e.g.,
@.***D72BC8.70F92A30]
<m:msub><m:mrow><m:mo stretchy="false">⟨</m:mo><m:msub><m:mrow>
<m:mi>R</m:mi></m:mrow><m:mrow><m:msub><m:mrow><m:mn>1</m:mn></m:mrow>
<m:mrow><m:mi>X</m:mi></m:mrow></m:msub></m:mrow></m:msub><m:mo
stretchy="false">⟩</m:mo></m:mrow><m:mrow><m:mn>1</m:mn><m:mo

/</m:mo><m:mn>2</m:mn></m:mrow></m:msub>

@.***D72BC8.70F92A30]
… <m:msubsup><m:mrow><m:mi>A</m:mi></m:mrow><m:mrow><m:msub><m:mrow><m:mi

l</m:mi></m:mrow><m:mrow><m:mi>i</m:mi></m:mrow></m:msub><m:mi>m</m:mi>
</m:mrow><m:mrow><m:mo stretchy="false">(</m:mo><m:mi
mathvariant="normal">R</m:mi><m:mo stretchy="false">)</m:mo></m:mrow>
</m:msubsup> …

It must have been something weird with both subs being the same character or something. I think we can just let that go and keep doing what we’re doing with our tagging. It seems to me that it should turn out how we’d expect in nearly all cases.
I still don’t exactly understand why the nested msups turn out differently from the nested msubs @.***D72BC8.70F92A30] and @.***D72BC8.70F92A30] ), but I guess this is just how TeX does it. Is that right?
Thanks again,
Julie Mitsdarfer
From: Davide P. Cervone @.>
Sent: Wednesday, April 7, 2021 3:33 PM
To: mathjax/MathJax @.>
Cc: Mitsdarfer, Julie @.>; Author @.>
Subject: [EXT] Re: [mathjax/MathJax] Bug: Problem with nested msubs (#2668)
[Actual Sender is<EMAIL_ADDRESS>MathJax uses TeX's layout for superscripts and subscripts, and in TeX, there is very little difference between the heights of the two subscripts. Here is TeX's output:
[TeX]https://user-images.githubusercontent.com/432782/113921638-3b50f180-97b4-11eb-94a5-a34abe0bdb4e.png
and this is MathJax using the MathJax TeX fonts:
[MJX]https://user-images.githubusercontent.com/432782/113921830-80752380-97b4-11eb-9127-6835663b1806.png
These are nearly identical. Using the STIX fonts (as you appear to be), MathJax produces:
[STIX]https://user-images.githubusercontent.com/432782/113921878-91be3000-97b4-11eb-96ce-1565a77df4b9.png
This is admittedly fairly close to the same vertical position, but not quite. In any case, TeX does not produce the large vertical difference that you are requesting, so MathJax doesn't either.
If you want to get more space, you could use something like {R_{2\mathstrut}}_2, which could be coded as

<msub>

  <mi>R</mi>

  <mrow>

    <mn>2</mn>

    <mphantom>

      <mpadded width="0">

        <mo stretchy="false">(</mo>

      </mpadded>

    </mphantom>

  </mrow>

</msub>

<mn>2</mn>

in MathML. This produces
[strut]https://user-images.githubusercontent.com/432782/113922750-acdd6f80-97b5-11eb-99fc-d7f62c053673.png
I would discourage you from using such constructs, however, as these are visually ambiguous: Does it represent {R_2}2 or R{2_2}. The visual distinctions between these two are very small, and can lead to confusion about what you are presenting. The usual reading of the last diagram would be as R_{2_2}, and one usually includes parentheses for the other one, as in \left(R_2\right)_2. The same goes for R^{2^2} versus \left(R^2\right)^2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mathjax/MathJax/issues/2668#issuecomment-815171378, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATSN4KFJQ5Z4VQ5LWNO7VMTTHSXQLANCNFSM42RBJWPQ.

In the two examples you give in your last message, the nesting is R_(1_x), while your first message had (R_2)_2, so the nesting is very different, and the positioning (and sizing) differs in those to situations.  The R_(1_x) nesting produces what you are expecting to see (successively smaller sizes and successively lower positions).  That is why these examples look good when your earlier ones don't.

OK yes, I understand it better now! I see how this could possibly affect us in more “real-life” examples!
@.***D72BCC.7E0E7B40]
<m:msub>
<m:mrow>
<m:mi>R</m:mi>
</m:mrow>
<m:mrow>
<m:msub>
<m:mrow>
<m:mn>1</m:mn>
</m:mrow>
<m:mrow>
<m:mi>X</m:mi>
</m:mrow>
</m:msub>
</m:mrow>
</m:msub>
would be similar to
@.***D72BCC.7E0E7B40]
<m:msub>
<m:mi>R</m:mi>
<m:msub>
<m:mn>2</m:mn>
<m:mn>2</m:mn>
</m:msub>
</m:msub>
We may need to do something about fixing our tagging if we think we may see things like the following slip into our XML:
<m:msub>
<m:msub>
<m:mi>R</m:mi>
<m:mn>1</m:mn>
</m:msub>
<m:mi>X</m:mi>
</m:msub>
or
@.***D72BCC.7E0E7B40]
<m:msub>
<m:msub>
<m:mi>R</m:mi>
<m:mn>2</m:mn>
</m:msub>
<m:mn>2</m:mn>
</m:msub>
Thank you for explaining this to me (twice). ☺
-Julie
From: Davide P. Cervone @.>
Sent: Wednesday, April 7, 2021 4:18 PM
To: mathjax/MathJax @.>
Cc: Mitsdarfer, Julie @.>; Author @.>
Subject: [EXT] Re: [mathjax/MathJax] Nested msubs (#2668)
[Actual Sender is<EMAIL_ADDRESS>In the two examples you give in your last message, the nesting is R_(1_x), while your first message had (R_2)2, so the nesting is very different, and the positioning (and sizing) differs in those to situations. The R(1_x) nesting produces what you are expecting to see (successively smaller sizes and successively lower positions). That is why these examples look good when your earlier ones don't.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mathjax/MathJax/issues/2668#issuecomment-815230107, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATSN4KFQSX5W57CJPN6ZLITTHS4XVANCNFSM42RBJWPQ.

Yes, it looks like you have it now!
I'm going to close this issue, then.


It does not work after Plugin

My vim is spf13-vim. And I found it does work (no highlight) after PluginInstall . How to fix it ?

maybe you have a cache issue and you need set manually set ft=vue in the relevant file


Is there any way to remove CryptoTokenExtension ?

I have just installed Ungoogled Chromium for the first time on Ubuntu MATE 20.04 from OBS Production Project, and the first thing I've noticed that, there are two extensions that cannot be removed.
1, CryptoTokenExtension
2, Chromium PDF Viewer
Now I'm OK with the PDF Viewer but would like to remove CryptoTokenExtension if there is a way. I've gone through the closed issue #944 but didn't see any way to remove the extension.
Thanks alot.

From a purely technical standpoint, yes. You can remove its files and its references from the source code and rebuild the browser.
I don't know the specifics for CryptoTokenExtension, but this is what you need to do to remove a built-in extension:

Remove the extension source code (JS and/or HTML) and its manifest.json
Remove references to the extension source code files from the GRIT (.grd) files
Remove references to the IDR_* constants from the C++ code that you just removed from the GRIT files above. To do this correctly, you'll need to remove the code that loads the extension during startup, and any other Chromium code that interacts with the extension (e.g. for CryptoTokenExtension, is there a 2FA browser interface that connects with it?)

Hopefully this answers your question.

@Eloston It turns out that ungoogled-chromium comes with built-in malware by default and I have to ungoogle it myself?

Obviously, if a person installs a browser, it means he needs a browser, not a pdf-viewer or crypto-miner. Anything not related to web browsing is malware.

It would be helpful to inform oneself before writing random nonsense. Cryptotoken has nothing to do with crypto currencies, its an early and deprecated api to communication with hardware tokens for multi factor authentication which is planned to be removed in a future version. Viewing PDFs is integrated into all major modern browsers and is a feature that users expect. Additionally malware is defined as software that causes damage to a computer by design, I don't know what drugs you need to be on to define a pdf viewer integrated into a browser codebase as that.

What this extension is for? In what situation would it be useful?
I suppose we can write a patch to remove it.

The extension is for using security hardware tokens as I already stated. Its basically only used by Google for Google Account login at this point and is planned to be removed (see the link above). In my install its not even listed in the extension page anymore and even if it was intended be used for tracking by Google it wouldn't work as it gets domain substituted like everything else: https://github.com/Eloston/ungoogled-chromium/issues/874#issuecomment-559604434

It doesn't matter what the Wikipedia says. Overloading browser with unnecessary junk is a "damage" to RAM and CPU. For example, spyware is malware. Even if I don't care if a program is spying on me, I regard the very existence of such a program as malicious because it does something I didn't ask for.

I regard the very existence of such a program as malicious because it does something I didn't ask for.

That's interesting. Your operating system is also doing tons of things you didn't ask for.

That's interesting. Your operating system is also doing tons of things you didn't ask for.

Nope. I don't have a single useless package or service on my Arch-linux machine.
I installed each of them manually and I know exactly what they do and how much memory use, unlike the built-in plugins of this browser.

@lua-rocks
Please be polite, these people that work on this project are sacrificing their own free time for people like you and me.
The least we can do is be polite and thankful.
If something is bothering you you are always welcome to write your own patches to remove whatever parts of the program you wish.
If you are not satisfied with this project you are welcome to go find yourself an alternative browser.

@codeswhite You've got me wrong. I'm not going to insult anyone here and I'm grateful to the developers for their hard work. But I also don't veil my criticism and I express my thoughts openly, even if they seem rude to somebody, because I believe that criticism is just as useful as praise.

When I speak ill of software, it does not mean that I speak ill of people. Software cannot be insulted. Especially since we're talking about plugins developed by Google.


Changes for Microsoft.DataMigration GA stable version 2018-04-19.

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-libraries-for-java

Automation for azure-sdk-for-node

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

The only big change from ARM standpoint is making some properties readonly. Since this change is made in a new api version, and the older version was preview, its fine. signing off!

one left
Executing: npx<EMAIL_ADDRESS>--validation --azure-validator --message-format=json specification/datamigration/resource-manager/readme.md --tag=package-2017-11-15-preview
{
  "type": "Error",
  "code": "RequiredReadOnlyProperties",
  "message": "Property 'taskType' is a required property. It should not be marked as 'readonly'.",
  "id": "R2056",
  "validationCategory": "SDKViolation",
  "providerNamespace": null,
  "resourceType": null,
  "sources": [
    "file:///home/travis/build/Azure/azure-rest-api-specs/specification/datamigration/resource-manager/Microsoft.DataMigration/preview/2017-11-15-preview/definitions/Tasks.json:25:8 ($.definitions.ProjectTaskProperties.properties.taskType)"
  ],
  "jsonref": "file:///home/travis/build/Azure/azure-rest-api-specs/specification/datamigration/resource-manager/Microsoft.DataMigration/preview/2017-11-15-preview/definitions/Tasks.json:25:8 ($.definitions.ProjectTaskProperties.properties.taskType)",
  "json-path": "file:///home/travis/build/Azure/azure-rest-api-specs/specification/datamigration/resource-manager/Microsoft.DataMigration/preview/2017-11-15-preview/definitions/Tasks.json:25:8 ($.definitions.ProjectTaskProperties.properties.taskType)"
}

There are also bunch of missing documentation fields. They will be used in all the auto-generated languages as hints for developers so it is highly suggested to have human readable documentation text. You can see all the doc issues in this build https://travis-ci.org/Azure/azure-rest-api-specs/jobs/372255731. They start with
{
  "type": "Warning",
  "code": "DescriptionAndTitleMissing",

@binuj please revert changes to the specs of the previous versions - no need to fix those issues in this PR.

@binuj please fix Linter errors like "Property named: 'Logins', for definition: 'ConnectToTargetSqlMITaskOutput' must follow camelCase style. Example: 'logins'.",

ignore my last comment - errors are in previous preview specs and were marked by Linter due to description change in your current pr.


Allow additional commands in script.vim

I have to issue a few more commands than are at the top of script.vim to remove things like colorcolumn and the status bar. I also need to issue nonumber twice (not sure why!).
Would you consider allowing an additional file to to included (passed via a command line arg) or if you think its generic enough we could add it to script.vim for everyone. I'm currently doing the below:
:bufdo :set nocursorline
:bufdo :set colorcolumn=
:bufdo :set nu!
:bufdo :set nu!
:set laststatus=0
:buffer 1

I think colorcolumn is an optional feature so it would need wrapping in an exists(+colorcolumn).
Thoughts?

Some more ideas here: https://github.com/aswna/vimdeck-show

@aswna this is awesome! well done! do you have an example presentation made/given using vimdeck-show?

@tybenz sure! Here: https://github.com/aswna/GNU-Linux-Tools-sessions
(Session 02 is more complete, since contains custom script.vim in its folder.)


[Android]: Database locale issues

Summary:
Trying to address: #422 #178
Those issues we've seen are related to locale changing and database connection not being closed properly. I could not reproduce it myself, so those are just preventive measures. Can't tell if this would help for sure.
The fix is to close db connection when activity is destroyed - it'll be reestablished on next startup (in case of locale change, activity is recreated).
Another one is to disable localized collators for db, which is the most suggested fix for Failed to change locale for db error.
I've moved this fix behind a flag that you need to set in gradle.properties in order to work.
This has been dropped due to possibility of unexpected behavior. More info about being consistent with locale collation in android docs.

If anyone is able to constantly reproduce the issue, please do let me know. You can try out this branch before it's released by pointing your package.json dependency to:
"@react-native-community/async-storage": "git+https://github.com/react-native-community/async-storage.git#fix/ensure-db-closed"

Would love to see this reviewed & merged soon if possible. We have many frustrated users that are receiving the issue in #422.

Thanks @tido64 for having a look 🙏
According to Android docs, one needs to be consistent with what collation rules were used when creating the database. That means, setting this flag to NO_COLLATION during runtime could lead to some unexpected behaviors/errors. Besides, the main issue in this issue is database is locked error - which is also addressed by this PR.

According to Android docs, one needs to be consistent with what collation rules were used when creating the database. That means, setting this flag to NO_COLLATION during runtime could lead to some unexpected behaviors/errors. Besides, the main issue in this issue is database is locked error - which is also addressed by this PR.

Does this mean that the problem is that we tried to open a database that was already opened in a different locale? Wouldn't restarting the app already close the database? Or is the implementation such that it is possible to leak connections?

Does this mean that the problem is that we tried to open a database that was already opened in a different locale?

I believe this is the case we see here.

Wouldn't restarting the app already close the database? Or is the implementation such that it is possible to leak connections?

This is exactly what I think is happening - changing locale restarts the activity, not the app process, so it leaks the db connection.

This is exactly what I think is happening - changing locale restarts the activity, not the app process, so it leaks the db connection.

The repro steps in #178 mentions killing the app though. I thought that would close the connection?

The repro steps in #178 mentions killing the app though. I thought that would close the connection?

This is the most confusing part of the whole issue. I also thought the connection will be closed, but apparently it's not 🤷♂ Dunno if we're not missing something here.

@tido64 I'll go ahead and merge this. Thanks for reviewing 🙏


Simplify http config

DayOfWeekService:
      auth: none
      endpoints:
        getCurrentDayOfWeek:
          method: GET
          path: /day-of-week
          response: DayOfWeek

Our opinion is that many devs will don't actually care about the method or path of the endpoint as long as they can declare inputs and outputs.
Fern should support devs not specifying method or path. It can default method to POST and path to the endpoint id. This provides the flexibility to integrate existing APIs while allowing devs to iterate faster on their APIs by reducing config required.

Closing this issue: https://github.com/fern-api/fern/pull/330


Where is index.html after npm run build?

I'm not a Svelte dev.
I ran npm run build and I saw that ./build/ was generated.
I was expecting this to be the directory to serve from my webserver.
However, I can't find index.html there.... or anywhere:
fd -uuu | rg '.html$'

src/app.html
node_modules/tslib/tslib.html
node_modules/tslib/tslib.es6.html
<EMAIL_ADDRESS>
How do I create the directory that I serve with my webserver?

Hi,
In SvelteKit with @sveltejs/adapter-node, the entry point for the server is the "index.js" file, not an "index.html" file. This is by design, and you can run the server by executing the following command in the repository directory:
node ./build/index.js

The "index.js" file handles server initialization and rendering the UI. If you have any further questions or need assistance, please don't hesitate to ask.


cursor keeps cycling forward by itself in the Scratchpad. (Windows 10, Microsoft Edge).

reported by Henry Askin
I couldn't reproduce it
Henry doesn't mind using Google Chrome, so it doesn't seem important
I invited Henry to send me a video of the bug

video here: https://drive.google.com/file/d/1_czmGWnnL7Jd8eZRCehD6dqeyU9w3K8r/view


[FEATURE] Redshift Support

Hello,
I would like to evaluate dbtvault in a AWS Redshift environment. Since Redshift support is part of the roadmap, I was wondering if you already have a some idea of what is necessary to get dbtvault to run on Redshift or maybe already started working on this.
Depending on the effort, we might be able to help reach the support of AWS Redshift.
Best regards,
Ingo

Hi Ingo. Our next platform support candidates are Big Query and SQLServer. We haven't yet investigated Redshift support. As far as I am aware Postgres and Redshift are very similar and we are planning to develop Redshift and Postgres side-by-side, but this will be Q2 2022.
In terms of contributing, we do not yet have a clear/easy contribution guideline for our community, which we are working on solving. This is because we have a large and comprehensive test suite with entirely custom execution requirements and it will require some setup and learning from the contributors side, so we're looking to make this more digestible and simpler to use so that contributing is as straightforward as possible.
We will likely be trialling a contribution approach early next year once we have settled on an approach internally and you would be a great candidate for this. Let me know if you are interested. Thanks so much for your interest!

Hi there
Any updates about Redshift support?

Redshift, Postgres and Databricks are next on our list of platforms to support. No ETA just yet.

Hope the team starting looking at it soon.

Hi there, very interested in this as well. Willing to help to speed up the development if needed.

Hi, We would like to use dbtvault with Redshift. Any update on the ETA?

@DVAlexHiggs - Any update on this feature would be highly appreciated. Thanks.

Hello team, I appreciate the excellent work you have been doing. Could you kindly provide us with an update on the status of this particular feature? If Redshift is not being considered as an option, please inform us so that we can explore other alternatives. Thank you.

Hi! We appreciate there is a lot of interest in this.
At the moment the priority is bug fixes for the platforms we currently support. We are a small team and also a consultancy ourselves, so we do have to distribute our time carefully.
Any contributions from the community are welcome and we are happy to collaborate on getting it integrated with our test suite.

Hi! Any updates on Redshift?
How can I help and contribute to accelerate the project?

Hi, we now have a team actively working on Redshift support so we will get an ETA as soon as we can!
Thank you for your patience!

Hi, at the moment we are thinking about introducing dbt in our company. Since we are currently using Amazon Redshift, possible support from automateDV for Redshift would not be an insignificant decision factor. Is there possibly a first concrete release timeframe?

Any updates?

Is there a revised ETA on a release that will support redshift?

Hi! First of all, apologies for the lack of updates - that's on us. It's been a busy few months!
We are currently collaborating with an organisation to bring Redshift support to AutomateDV and we're making steady progress. A rough estimate looks like the latter half of Q1 2023 or early Q2.
Thank you for your patience! We are very aware how eager the community is for Redshift and we are doing what we can to get it to you all as soon as we can 😄

any updates?

a.u?

any updates?

Unfortunately we had to pause development on this, however we will be restarting again soon. I'm sorry it's not better news. We were highly aware this is something the community wants and we will get it to you as soon as we can. Thanks for your patience

Can you give some rough estimates?


Adjustments for refactoring of representation of Accessors in SwiftSyntax

Companion of https://github.com/apple/swift-syntax/pull/1946

https://github.com/apple/swift/pull/67500
apple/swift-syntax#1946
https://github.com/apple/swift-format/pull/576
@swift-ci Please test


Workspace Trust doc link broken

Type: Bug
Welcome - Learn the Fyndamentals
Safely browse and edit code
Workspace Trust Link
https://github.com/microsoft/vscode-docs/blob/workspaceTrust/docs/editor/workspace-trust.md
404 - page not found
VS Code version: Code 1.91.1 (f1e16e1e6214d7c44d078b1f0607b2388f29d729, 2024-07-09T22:06:49.809Z)
OS version: Windows_NT x64 10.0.22631
Modes: Restricted

@illlust, could you please provide a screenshot of where this broken link is? Thanks!

@lszomoru Got it - issue is in the walkthrough. Fix incoming. Thanks for signaling this @illlust.

Is this a candidate? The change has been merged to the main branch but not the release branch, and so the fix is not in the latest Insiders.

IMO, it can go with the next one.


[BUG][UVerticalNavigation] Page with param doesn't get active

Environment

Operating System: Windows_NT
Node Version:     v18.12.0
Nuxt Version:     3.11.1
CLI Version:      3.11.1
Nitro Version:    2.9.6
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      runtimeConfig, app, css, ssr, routeRules, modules, devtools
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Version
v2.15.2
Reproduction
https://stackblitz.com/edit/nuxtlabs-ui-kbyuff?file=pages%2Findex.vue,pages%2Fexecutions%2Findex.vue,layouts%2Fdefault.vue,pages%2Fexecutions%2F[id].vue,package.json
Description
Steps to reproduce

Navigate to /executions
See the navigation highlighting on "Executions"
Navigate to /excutions/123 (/executions/[id])
Navigation doesn't highlight the "Executions" item

What is Expected?
The navigation should highlight on both routes
Additional context
No response
Logs
No response

You're missing the executions.vue parent page with a <NuxtPage /> inside to tell vue router that [id].vue is a child of executions.

You're missing the executions.vue parent page with a <NuxtPage /> inside to tell vue router that [id].vue is a child of executions.

I see, know it's working. But, can you explain why this it needed?
I always get confiused when using NuxtPage and the app.vue. Normally i remove the app.vue, add a default layout, put NuxtPage there, and create custom layouts, because the default layout will be incorporated with the others layout with "instantiate" it.
I have never used NuxtPage in another way. That's a thing that i could't undestand. How exacly should use the NuxtPage and when i should use it.
I'm glad if you can explain that. Thanks for Nuxt ecosystem. I love it since v2.  💚

Here is the documentation for nested pages: https://nuxt.com/docs/guide/directory-structure/pages#nested-routes 😊


If --since returns no packages, just assume all packages are needed to be rebuilt

in a scenario of being on master, and running with --since master, it'll do nothing. This is TECHNICALLY correct, but probably not what we want!

Decided that this use case isn't helpful. People should really not see different behavior is they use the --since flag.


Include full snapshot id in backup json command output

Output of restic version
restic 0.9.6 compiled with go1.13.4 on linux/amd64
What should restic do differently? Which functionality do you think we should add?
Most commands that react to the global --json switch use the full snapshot id in their output
(at least find, forget, ls and snapshots do).
One notable difference seems to be the backup command whose summary output only contains the short snapshot id.
Example output:
{
  "data_added": 25131953,
  "data_blobs": 118,
  "dirs_changed": 2,
  "dirs_new": 0,
  "dirs_unmodified": 0,
  "files_changed": 74,
  "files_new": 60,
  "files_unmodified": 11223,
  "message_type": "summary",
  "snapshot_id": "43deae25",
  "total_bytes_processed": 503143593,
  "total_duration": 1.816399114,
  "total_files_processed": 11357,
  "tree_blobs": 3
}

I would suggest to also provide a full_snapshot_id or similarly named field in the above output.
For consistency reasons identical or at least similar JSON keys would be nice to have but following restic snapshots output which uses id and short_id would be backwards incompatible.
What are you trying to do?
I'm trying to link the restic command output together for cases like:

restic backup followed by restic diff to see which exact files were just added/modified/removed compared to a previous snapshot
restic backup followed by ls to list all files that ended up in the newly added snapshot

In the above cases I don't intend to show the snapshot ids to the user but only use them internally. In that case always using the full snapshot id has a lower chance of running into collisions.
The short id is (like in git) probably meant to make life of a commandline end-user easier. When scripting or otherwise automating restic, the full id should probably be preferred.
Did restic help you today? Did it make you happy in any way?
I'm successfully using restic for three personal machines (two `$HOME  backups for desktop/laptop, one full backup for a server) by now and both the sheer speed as well as the well-documented commandline interface make it a breeze to use.
Being self-contained and only requiring sftp access for remote backups also made it easy to switch from my two old backup tools to restic :)

My non-existing Go skills (I'm more fluent in C++ & Python) came up with this.
If you feel that this is worth a pull-request just shout.
I think the most important part is naming the new JSON field without causing too much confusion.
diff --git a/internal/ui/json/backup.go b/internal/ui/json/backup.go
index ff7af18c..ba9cefe1 100644
--- a/internal/ui/json/backup.go
+++ b/internal/ui/json/backup.go
@@ -381,6 +381,7 @@ func (b *Backup) Finish(snapshotID restic.ID) {
 		TotalBytesProcessed: b.summary.ProcessedBytes,
 		TotalDuration:       time.Since(b.start).Seconds(),
 		SnapshotID:          snapshotID.Str(),
+		ID:                  snapshotID,
 	})
 }

@@ -421,18 +422,19 @@ type verboseUpdate struct {
 }

 type summaryOutput struct {
+	ID                  restic.ID `json:"id"`
 }


Why does wakaama not support UTC+13 time zone?

According to wiki page https://en.wikipedia.org/wiki/UTC%2B13:00 time zone UTC+13 is used in Samoe and Tokelau. But function prv_check_time_zone from examples/client/object_device.c perceives this time zone as erroneous.
Does ISO8601 really not support UTC+13? Or is it a bug in prv_check_time_zone?

I would assume it is a bug in prv_check_time_offset. According to https://en.wikipedia.org/wiki/List_of_UTC_time_offsets the range should be -12 to +14.

Fixed by #534.


Remove ContentValues argument from DefaultPutResolver.getIdColumnName()

Closes #178
I decided to remove ContentValues param from DefaultPutResolver.getIdColumnName() for simplicity and better performance (no unneeded parameter passing).
In 99% of cases users won't use ContentValues to resolve idColumnName, it's a work for frameworks and libs based on StorIO, so we can keep simpler API for most of our users :)
@nikitin-da PTAL

Yeh, it was mistake =(


raise wpsclient version fix issue that async wrapper is stuck during retries

fix #98

Awaiting feedback by Hugo before merging.

No negative feedback so far, merging.


Azure Next Generation Documentation hard to find easily

Azure Next Generation is hard to find.

If you start from here:  https://www.pulumi.com/docs/ one would have no idea about azure next gen.
The Get Started-> Azure References are all "@pulumi/azure"
The examples are old azure.
The easy way to currently get to azure next gen is
[Mikhails' Blog](via https://www.pulumi.com/blog/announcing-nextgen-azure-provider/)
https://www.pulumi.com/docs/ Next to AWS, put azure next gen, and move azure to the end of the list.
The getting started link on the left side of the page, the azure next gen needs to be above azure.
The examples need to be the ones that are in the blog, not the current one.

Dave is planning to work on the getting started guide for Azure NG, so assigning this to him to avoid duplicating effort here.

Getting started now defaults to native azure


HIP-410 ethereum transaction

Description:
Add protos for new EthereumTransaction type.

EthereumTransaction
new call in smartContractService
new initcodeBytes in CryptoCreateTransaction
nonce in crypto get info.

Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Will fix tpyos in a follow-on PR. - https://github.com/hashgraph/hedera-protobufs/pull/185


try upgrading to jquery 3.4.1

Initial smoke testing: jQuery 3.4.1 seems to work fine on most pages. The peptide details page (which includes a spectrum viewer that uses a much older copy of jQuery) behaves strangely. If you add a Ribbon Bar Message (site settings) then the dismiss hover becomes full screen width and the exclamation point (to reshow the ribbon) loses its hover completely.


Display doubles with a decimal point

This pull request is for #237

Codecov Report

Merging #246 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #246      +/-   ##
==========================================
+ Coverage   61.34%   61.35%   +0.01%
==========================================
  Files          68       68
  Lines        6327     6324       -3
==========================================
- Hits         3881     3880       -1
+ Misses       1933     1932       -1
+ Partials      513      512       -1

Impacted Files
Coverage Δ

document/value.go
73.43% <100.00%> (+0.43%)
:arrow_up:

Continue to review full report at Codecov.

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


Update scrape.py for ETL from radio station sources

This can be closed when the Python file has the ability to return structured data from the unstructured data sources below,
https://www.weather.gov/nwr/station_search
https://radio-locator.com/
https://short-wave.info/index.php

https://github.com/fluids-ai/weather_radio_locator/tree/scrape
This branch was created to track changes associated with the issue.

Currently, all NOAA stations according to the station_search are in this JSON file,
https://www.weather.gov/source/nwr/JS/xmitter.js
Using lat and lon, we can create a function that finds the nearest station ourselves

https://radio-locator.com/cgi-bin/locate?select=lonlat&geo=y&latd=40.5536768&lond=-74.30144
Replace lat and lon here

POST request to get all English stations, https://www.short-wave.info/index.php
station=Any Station
language=English
now=03
now2=43
GMT=true
submit=GO
mobile=false

Currently, all NOAA stations according to the station_search are in this JSON file,
https://www.weather.gov/source/nwr/JS/xmitter.js
Using lat and lon, we can create a function that finds the nearest station ourselves

This does not include the band information. It is available from further webscraping here, https://www.weather.gov/nwr/sites?site=KZZ31 by replacing the site variable with the index from xmitter.js. This link can be included in the metadata.

POST request to get all English stations, https://www.short-wave.info/index.php
station=Any Station language=English now=03 now2=43 GMT=true submit=GO mobile=false

Latitude and longitude are included in the data for each station. The default API does not search by location but we can use the same method that we use for the NOAA weather bands.


Express API plus CoteJS standalone services sample

Hello,
Is possible to create Express Docker Containers, exposing an API Restful that responds to
CoteJS services, but those services are in anothers Docker containers?
If I use locally, run express at 3000 port, and them run cotejs services, it works.
Expresss routes send to cotejs that responds automatically.
But and I tried use those projects using Docker as I said above, the Express router doesnt "find"
the CoteJS that are running in another Docker container.
Can you explain me for how can I make it work?
Thanks ;)

Why closed this?

@LucasBadico if you have a specific question, you can open a new issue and we can cover it there.


[Dash] Instant send support

Is this something should be done on the wallet core or blockbook node?

probably wallet core to set a flag somehow

Based on this, it appears there is no need to do anything on the sender side any more.  As receiver?
"Since Dash 0.14, all user-facing interface options to create an InstantSend transaction have been removed, because all transactions are effectively InstantSend transactions. As before, the recipient is responsible for monitoring the network for the InstantSend lock and implementing user-facing logic and interfaces to continue with transaction processing after payment has been recieved. See the InstantSend Integration documentation for more information on how to monitor for InstandSend locks."
https://docs.dash.org/en/stable/wallets/dashcore/privatesend-instantsend.html
https://docs.dash.org/en/stable/developers/integration.html#is-broadcast

@hewigovens , based on the above, it seems that no action is needed on send (every tx is treated as instantSend if possible), but action needed on atlas side to check if received tx is InstantSend locked, in which case there is no need to wait for confirmation.  But this second part is optional.
Should I transfer this issue to assets or close it?
https://github.com/dashpay/dash/blob/master/doc/instantsend.md#zmq


Add typing

Now that python supports Typing, we can Create schema for nodes so that developers get suggestions on IDE

If seems ok, assign it to me


Fix 506 - adding an open argument to expose flask

By running python main.py --open flask would open it's host to all local IPs allowing access through:
[local-ip]:5000 e.g: <IP_ADDRESS>:5000

Fixed rejections


support progress bar/marker

For continuous work on one .tsv document in different sessions, it would be handy to be able to mark the progress within that document.
This could fx be realized through an additional column which places a visual marker (e.g. arrow icon) in a selected row by clicking on it.

My current thinking is to allow the placement of ONE continue marker that can be set anywhere in the LOCATION column. Upon opening a TSV file that contains such a continue marker, it would offer to jump directly to that line. Would that be of help @snmnzl @JZinck ?

neat could also store the position at save time within the tsv file as a comment.
When that tsv file is opened again, it could jump automatically to that position.

neat could also store the position at save time

Even better idea!

Both ideas are very good. I could use the marker while revising as well, since I have to scroll up and down a couple of times and could just use the marker like a bookmark. But the risk of forgettig to put it down before saving and exiting (which I am worrried about) would be nullified by the saved position feature. So I can see the merit of combining them over each individual idea.
In case this is an either-or-situation I think the marker would be more useful to the way I use the tool (but this might differ from what other users might need).


1 editing docker file

The production.yml file had issues causing GitHub Actions to fail. To fix this, I updated the GitHub username and Docker image name. I also added environment variables, such as GITHUB_USERNAME and GITHUB_TOKEN, which resolved the problems successfully.
Docker file had issue load metadata for docker.io/library/python:3.12-slim-bookworm. Issue is solved my adding missing dependencies, and application misconfigurations.

Test passed production.yml is working


treewide: Preparation for v1.0.0, add SV macros for type definitions and refactor module parametrization

Preparation for release v1.0.0
This PR introduces a lot of breaking changes to the way the SystemVerilog modules are parametrized. The reason for this drastic change is that a lot of features have been added to FlooNoC since the beginning including the automatic generation of networks with FlooGen. Some of the design decisions taken in the beginning of the development proved to be unsuitable when generating large networks.
For instance, the flit type packages in hw were auto generated with a python script and globally imported in the modules. When using FlooNoC as a library this is quite awkward and error-prone as the those packages need to be overwritten inside the .bender folder. Therefore, the auto-generation of all the types was removed in this PR in favor of SystemVerilog macros and some helper functions in the floo_pkg.
These breaking interface changes might be annoying, but the goal is that it will result in a release v1.0.0, which should stabilize the IPs. The changes are numerous and are given below:
Added
Hardware

The floo_pkg was extended with helper functions to calculate the size of AXI payloads and mapping of AXI to Floo Channels.
Multiple configuration structs were introduced to enable a more flexible and non-verbose configuration of the FlooNoC modules.

The AxiCfg describes all the necessary parameters needed for the type definitions of a bidirectional AXI interface
The RouteCfg describes all the necessary routing information parameters required by the chimneys.
The ChimneyCfg describes all other parameters for the data path of the chimney (e.g. Mgr/Sbr port enable, number of oustanding transactions, RoB types & sizes, etc.)

The floo_test_pkg now defines default configurations for all the new configuration structs that are used by the testbenches.

FlooGen

The data_width and user_width fields for protocols are now also validated to be compatible with each other.
All the various *Cfg's is now rendered by FlooGen, either in the *_noc_pkg or in the *_noc module itself.

Changed
Hardware

The floo_narrow_wide_* modules and the corresponding testbenches were renamed to floo_nw_* to be more concise.
The flit type definitions are now implemented as SystemVerilog macros in typedef.svh.
The parametrization of the chimney modules has changed dramatically. They now use the newly introduced *Cfg's from the floo_pkg. In the narrow-wide chimneys, both datapaths now have their own configs (i.e. *CfgN and *CfgW), to reduce the verbosity of the module instantiation.
The payload field name in each *_chan_t type previously had its own name. This was unified to payload since *_chan_t already determines the type of the payload.
The input and output buffer FIFO depth of the routers were renamed to InFifoDepth and OutFifoDepth to be more consistent (previously ChannelFifoDepth and OutputFifoDepth).
The narrow-wide router wrapper now also requires the AxiCfg structs to redefine the link types internally.
The ReorderBufferSize parameters was shortened to RoBSize.
All testbenches were adapted to all changes.
All verification IPs were adapted to the new configuration structs.

FlooGen

The link typedefs are now renderd with the macros in typedef.svh instead of rendering them in pure SystemVerilog.
The template files were renamed to use the more concise nw naming scheme.
The generated modules and packages of FlooGen are now named floo_*_noc resp. floo_*_noc_pkg which is more consistent since all other modules have the floo_* prefix.
The protocols schema was adapted a bit to be more intuitive.

The type field was renamed to protocol, which currently only accepts AXI4. A new type field now is used by FlooGen to now where to attach the protocol in the network interface. Currently, FlooGen only supports the narrow-wide AXI configuration, hence only narrow|wide is allowed as type values.
The direction field in the protocol schema is no longer required, since the direction is determined when specifying mgr_port_protocol and sbr_port_protocol.
The name field must be unique now, since it is used by mgr_port_protocol and sbr_port_protocol to reference the exact protocol.
All examples were adapted to reflect those changes.

Fixed

A bug in the calcuation of the RoB offset in floo_rob was fixed. Previously, the allocation and the write process used the same counter in bursts for offset calculation, which resulted in wrong offsets.

Removed
Hardware

As the flit type definitions were moved to typedef.svh, the auto-generated floo_*_pkg packages were removed from the repository. Furthermore, all the (global) imports of those packages in the modules were replaced by parameters.
The testbench tb_floo_nw_chimney was removed since it was neither used nor maintained anymore.
The IdIsPort routing algorithm was removed since it can only be used for routes over a single router. The same functionality can be achieved with the SourceRouting algorithm.

FlooGen

The package generation was removed from FlooGen since it is now handled by the typedef.svh file. Further, the --only-pkg and --pkg-outdir flags were removed from the FlooGen CLI.
The calculation of link sizes and AXI to Floo channel mapping was removed from the FlooGen configuration file. This is now handled by the floo_pkg helper functions.

Congrats on this coming release, this is a really cool and exciting project

Thanks @kgreig87.


What is "Share Single" category ?

Hello,
when I go to the "Share Single" category in the documentation, I realize that there is a list of applications supported by the react-native-share package.
So, to start with, I was already wondering what "Share Single" meant exactly. I didn't really understand the associated example gifs.
Then, why are some applications, like FACEBOOK_STORIES, only supported on iOS and others only on Android? What's that due to ?
Does this mean that I won't be able to share an image in a facebook storie from an android phone?
Thanks for your answers
Viktor

HI @vikjovanov , thanks for sharing this with us. The purpose of Share.single is to share to a specific application, instead of calling the generic "share".
Wich may work as a "deep link".  Also, some implementation is only supported in specific platforms(Facebook Stories for example), but you still able to call Share.open to share with these platforms.
Also, sorry for the confusion with our "docs", I have been working on a newer version and I would be glad if you can check it out. 😅

Im using latest version "react-native-share": "^3.7.0"  which works fine but then Im using Share.single (according to the doc) its not working reactNativeShare.default.single is not a function.
After Some Searching  I replace Share.single with shareSingle and now its work fine.
Please Update  Doc or Guide me.

Im using latest version "react-native-share": "^3.7.0" which works fine but then Im using Share.single (according to the doc) its not working reactNativeShare.default.single is not a function.
After Some Searching I replace Share.single with shareSingle and now its work fine.
Please Update Doc or Guide me.

Thanks for sharing that. PRS updating/fixing the docs are always welcome. Let me know if there is anything that I can help you.


Testing stuff

Replace babel-tape-runner with the original tape.
babel-tape-runner uses babel-polyfill. So if a code has constructs like Object.assign which a JS interpreter (e.g. Node v0.12) doesn't, tests will run flawlessly, but actual code runs will throw.
tape can "require" external modules befor running tests now, so it's safer to use tabe -r babel-register. And I also love ditching big complex stuff for small vanilla stuff :)
The original issue: https://github.com/wavded/babel-tape-runner/issues/15 Thanks @olegskl for investigating.

Update such Node v0.12 non-compatible code.

Add tap-spec for prettifying the output.

Add helper scripts for easier test running
E.g. npm run test-rule operator-no-unspaced will run
node_modules/.bin/tape -r babel-register src/rules/partial-no-import/__tests__/indes.js | node_modules/.bin/tap-spec

(so tired of typing this all the time)

update the link to the project's NPM module in README.

Nice! I tried running npm run test-rule operator-no-unspaced, but I'm getting:
> node ./scripts/test-rule.js "operator-no-unspaced"

env: node: No such file or directory
env: node: No such file or directory

This might have something to do with how Node is being installed in the OS. Would any of these solutions work for you? Seems that calling node <script>.js is not that uncommon in the community, I doubt all those people use Windows =)

Nope, that's not it. The error is coming from { env: { FORCE_COLOR: "always" } }.

Sorry, didn't have an opportunity to look into this.
Good thing is I fixed that, at least works in Ubuntu 16.
And bad news: Node.js 0.12 tests started to fail. At first it was stylelint's table dependency that adopded babel compiling for Node >=4. Using its fixed version helped, but now this module strikes a pose:
/home/travis/build/kristerkari/stylelint-scss/node_modules/stylelint/node_modules/cosmiconfig/index.js:3
const path = require('path');
^^^^^
SyntaxError: Use of const in strict mode.

I suppose stylelint guys don't want anything below v4 anymore. So, not that I want to, but do we have an option beside doing the same since 1) this project havily uses stylelint, 2) it's by it nature won't be used without stylelint?

Yeah I think that it's a good time to drop 0.12 support already. At least it seems that everyone else is doing that too.

I suppose we don't have to wait until the next major release? because stylelint is already 0.12-incompatible

Hmm.. good point. If we don't do it in a major release, then we could break projects and builds for some people. It is possible that someone uses an older version of Stylelint and the current version of stylelint-scss if they need to still use 0.12

But won't our dependency of "stylelint": "^7.0.3" break their code? And not just that, but stylelint's dependencies. E.g. table did that breaking change in a minor release.

You are right, stylelint has already dropped 0.12 support in that version, so we should do it too.

@dryoma I opened a PR to drop 0.12 support https://github.com/kristerkari/stylelint-scss/pull/77

@dryoma Now that you are changing some things related to tests, how about also adding test coverage? I think that it would be useful for us to know if there are untested things or unused code.
stylelint's coverage PR:
https://github.com/stylelint/stylelint/pull/1279

I also went and added coverage reporting, so you need to rebase against master.

Coverage increased (+0.005%) to 94.343% when pulling 377a0f125271860398103cf3151b9b64c406b146 on use-tape into 66b2c5e21f2504e64930f8accb01b5e155708ee6 on master.