Add support for standard widgets

Widgets extending standard scene2d.ui:

[x] VisImage
[x] VisLabel
[x] VisList
[x] VisScrollPane
[x] VisSelectBox
[x] VisTable
[x] VisTextButton
[x] VisTree
[x] VisWindow
[x] VisProgressBar
[x] VisSlider

Those are the easy ones so I guess I will take them.
Widgets copy-pasted from scene2d.ui:

[x] VisCheckBox (extends TextButton, only draw changed)
[x] VisRadioButton (extends VisCheckBox)
[x] VisDialog (extends VisWindow)
[x] VisImageButton (extends Button, support for disabling focus border, support for auto generating disabled image)
[x] VisImageTextButton (extends Button, support for disabling focus border)
[x] VisSplitPane (extends WidgetGroup, only draw changed)
[x] VisTextField (extends Widget, input handling changed, support for disabling focus border, support for marking field as invalid)
[x] VisTextArea (nothing changed, extends VisTextField to inherit its functionality)

I might have to create base tag classes for widgets from the second group, so I'll take VisWindow as well.

I've noticed that VisProgressBar and VisSlider now extend Scene2D classes, so I've moved them to the first group.

All standard widgets supported, all example templates in tests project now use Vis actors. Closing.


Actions.currentRouter.currentRoute throwing 'undefined is not an object'

Version
Tell us which versions you are using:

react-native-router-flux ^3.37.0
react-native 0.43.3

Expected behaviour
Actions.currentRouter.currentRoute returning the current active Scene
Actual behaviour

Steps to reproduce
I'm trying to use in conjunction with react-native-popup-menu to open a user list of each Chat scene, but I'm getting the above error.
Chat scene is defined as
<Scene
  key="chat"
  component={Chat}
  leftButtonIconStyle={{ tintColor: '#825c12' }}
  animationStyle={animationStyle}
  titleStyle={styles.navbarTitleStyle}
  sceneStyle={{ paddingTop: (Platform.OS === 'ios') ? 65 : 54 }}
  renderRightButton={MoreMenu}
/>

MoreMenu:
import React from 'react';
import { Menu, MenuTrigger, MenuOptions, MenuOption } from 'react-native-popup-menu';
import { Icon } from 'native-base';
import { Actions } from 'react-native-router-flux';

const MoreMenu = () => (
  <Menu>
    <MenuTrigger>
      <Icon ios='ios-more' android='md-more' style={{ color: '#825c12', marginTop: -3 }} />
    </MenuTrigger>
    <MenuOptions>
      <MenuOption onSelect={() => console.log(Actions.currentRouter.currentRoute)} text='Group Users' />
    </MenuOptions>
  </Menu>
);

export default MoreMenu;

Thanks in advance for the help.

Yeah, that dosnt work

you should use redux and this example


Fix #95 : Add CC to sender for email file sharing

@vayan : perhaps it's an idea to also add a checkbox in the Email settings page to allow enable/disable of this feature? If not, sys admins will get spammed without being able to control this behaviour :)

@remie Yeah you're right ! Doing that :+1:

Cool stuff! Thanks for also including the UI test


fix bad link in design.md documents.

img directory was relocated from / to / docs/static/.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.movon seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


feat(chains): add Fantom chain

https://docs.fantom.foundation/tutorials/set-up-metamask

Network Name: Fantom Opera
RPC Url: https://rpc.ftm.tools/
ChainID: 250
Symbol: FTM
Block Explorer URL: https://ftmscan.com/

https://docs.fantom.foundation/tutorials/set-up-metamask-testnet

Network Name: Fantom testnet
New RPC Url: https://rpc.testnet.fantom.network/
ChainID: 0xfa2
Symbol: FTM

Greetings!
Thank you for your Pull Request and interest in this package.

Do you use addChains method? With this method you can add custom chains to your project.
Use this example structure in your project to add method:
import { ConnectWallet } from '@amfi/connect-wallet';

const connectWallet = new ConnectWallet();
const chains = [
    {
      name: 'fantom',
      chainID: 250,
      hex: '0xfa',
    },
    {
      name: 'fantom-testnet',
      chainID: 4002,
      hex: '0xfa2',
    }
  ];

// Add chains
this.connectWallet.addChains(this.chains);
// Init connect
connectWallet.connect(provider, network, settings).then(
  (connected: boolean) => console.log('connect wallet: ', connected),
  (err: any) => console.log('connect wallet error: ', err)
);

@amaryfilo
Thanks for advice! I've used this method to extend the library's default chains. Works perfectly!


Pyspark  timestamps cast issue when reading MySQL DB & writing to Redshift

Python 2.7
Pyspark 2.2.1
JDBC format for MySQL->Spark DF
For writing Spark DF-> AWS Redshift i am using the `Spark-Redshift` driver from Databricks.

I am reading data into Spark from MySQL tables for my application, due to the context and depending on the input arguments i need to get either all records that were updated before today OR only the records that were updated until the requested date (included).
spark.read.format("jdbc")
            .option("url", "url")
            .option("driver", driver)
            .option("dbtable", query)
            .load()

and the query is
if days > 0:
    get_date = date.today() - timedelta(days)
    query = "(SELECT * FROM {} WHERE CAST({}.updatedAt AS date) >= DATE('{}') " \
            "AND CAST({}.updatedAt AS date) < CURDATE()) AS t".format(table, table, get_date, table)
elif days == 0:
    query = "(SELECT * FROM {} WHERE CAST({}.updatedAt AS date) < CURDATE() " \
            "OR updatedAt IS NULL) AS t".format(table, table)

This timestamp column is discarded as soon as the data are read into Spark dataframes and the ETL contains no other timestamp-related manipulations. The final step is to write the manipulated records to AWS Redshift tables.
My problem is that SOMETIMES the application crashes with a
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.sql.Timestamp when writing to Redshift, but i guess the issue comes from converting when reading and is just Spark lazy execution that gives the exception when writing to Redshift (there are no timestamp or date columns in the target Redshift tables whatsoever)
In the last month and for 4 different jobs that run daily i got this exception in the logs about 15% of the time and then the jobs failed, but it runs fine most of the time which is making it impossible to reproduce the issue or debug further.
I suspect the String-> Timestamp casting within the SQL query creates the problem, but i am not sure how i can achieve the same in another way that will not throw this exception. Any help greatly appreciated!
More stacktrace info:
py4j.protocol.Py4JJavaError: An error occurred while calling o827.save.
: org.apache.spark.SparkException: Job aborted.
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1.apply$mcV$sp(FileFormatWriter.scala:213)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1.apply(FileFormatWriter.scala:166)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1.apply(FileFormatWriter.scala:166)

and
at org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:135)
at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:116)
at org.apache.spark.sql.execution.QueryExecution.toRdd$lzycompute(QueryExecution.scala:92)
at org.apache.spark.sql.execution.QueryExecution.toRdd(QueryExecution.scala:92)
at org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:609)
at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
at py4j.Gateway.invoke(Gateway.java:280)
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
at py4j.commands.CallCommand.execute(CallCommand.java:79)
at py4j.GatewayConnection.run(GatewayConnection.java:214)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: Task 601 in stage 93.0 failed 4 times, most recent failure: Lost task 601.3 in stage 93.0 (TID 5282, url, executor 5): org.apache.spark.SparkException: Task failed while writing rows
at org.apache.spark.sql.execution.datasources.FileFormatWriter$.org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask(FileFormatWriter.scala:270)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1$$anonfun$apply$mcV$sp$1.apply(FileFormatWriter.scala:189)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1$$anonfun$apply$mcV$sp$1.apply(FileFormatWriter.scala:188)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:108)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:338)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.sql.Timestamp
at com.databricks.spark.redshift.RedshiftWriter$$anonfun$7$$anonfun$apply$3.apply(RedshiftWriter.scala:234)
at com.databricks.spark.redshift.RedshiftWriter$$anonfun$7$$anonfun$apply$3.apply(RedshiftWriter.scala:233)
at com.databricks.spark.redshift.RedshiftWriter$$anonfun$8$$anonfun$apply$5.apply(RedshiftWriter.scala:252)
at com.databricks.spark.redshift.RedshiftWriter$$anonfun$8$$anonfun$apply$5.apply(RedshiftWriter.scala:248)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$SingleDirectoryWriteTask.execute(FileFormatWriter.scala:324)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:256)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:254)
at org.apache.spark.util.Utils$.tryWithSafeFinallyAndFailureCallbacks(Utils.scala:1371)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$.org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask(FileFormatWriter.scala:259)

UPDATE
I tried a lot of things with casting etc, my problem still persists and interestingly enough i got a more informative stacktrace at some point
Caused by: java.lang.RuntimeException: Error while encoding: java.lang.RuntimeException: java.sql.Timestamp is not a valid external type for schema of string
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 0, formid), StringType), true) AS column1#2498
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 1, formtitle), StringType), true) AS column2#2499
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 2, responserate), FloatType) AS column3#2500
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 14, languageid), IntegerType) AS column4#2512
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 16, answer), IntegerType) AS column5#2514
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 18, userid), IntegerType) AS column6#2516
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 19, inviteid), StringType), true) AS column7#2517
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 20, daterequested), StringType), true) AS column8#2518
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 21, dateanswered), StringType), true) AS column9#2519
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 30, customproperty9), StringType), true) AS customproperty9#2528
if (assertnotnull(input[0, org.apache.spark.sql.Row, true]).isNullAt) null else staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 31, customproperty10), StringType), true) AS customproperty10#2529
staticinvoke(class org.apache.spark.unsafe.types.UTF8String, StringType, fromString, validateexternaltype(getexternalrowfield(assertnotnull(input[0, org.apache.spark.sql.Row, true]), 32, updated), StringType), true) AS updated#2530
at org.apache.spark.sql.catalyst.encoders.ExpressionEncoder.toRow(ExpressionEncoder.scala:290)
at org.apache.spark.sql.SparkSession$$anonfun$3.apply(SparkSession.scala:582)
at org.apache.spark.sql.SparkSession$$anonfun$3.apply(SparkSession.scala:582)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at scala.collection.Iterator$$anon$11.next(Iterator.scala:409)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$SingleDirectoryWriteTask.execute(FileFormatWriter.scala:324)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:256)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:254)
at org.apache.spark.util.Utils$.tryWithSafeFinallyAndFailureCallbacks(Utils.scala:1371)
at org.apache.spark.sql.execution.datasources.FileFormatWriter$.org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask(FileFormatWriter.scala:259)
... 8 more
Caused by: java.lang.RuntimeException: java.sql.Timestamp is not a valid external type for schema of string
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.evalIfFalseExpr20$(Unknown Source)
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.apply_8$(Unknown Source)
at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.apply(Unknown Source)
at org.apache.spark.sql.catalyst.encoders.ExpressionEncoder.toRow(ExpressionEncoder.scala:287)

It  looks like it comes down to issue with encoding the last timestamp column, but why are the TIMESTAMP columns parsed as StringType().
Spark dataframe schema that is being written:
root
|-- column1: string (nullable = true)
|-- column2: string (nullable = true)
|-- column3: float (nullable = true)
|-- column4: integer (nullable = true)
|-- column5: integer (nullable = true)
|-- column6: integer (nullable = true)
|-- column7: string (nullable = true)
|-- column8: timestamp (nullable = true)
|-- column9: timestamp (nullable = true)
|-- customProperty9: string (nullable = true)
|-- customProperty10: string (nullable = true)
|-- updated: timestamp (nullable = false)

and the target Redshift table has the equivalent schema data types, anyone an idea of where this issue might come from?

UPDATE #2
As a workaround i write the timestamps as strings instead, however looking at the temp files of the intermediate results it looks like there is an issue with the timestamp format, more specifically:

The source MySQL timestamps in column8&9 have format "2014-12-22 08:32:56"

Spark timestamps add a fraction part like "2014-12-22 08:32:54.000" even if i specify the format to be ""yyyy-MM-dd hh:mm:ss". This was hard to spot as even df.show() omits those.

Using AVRO temp file format i indeed see in the schema specification that Spark timestamp columns are parsed as strings, even though in the df schema they appear as timestamps as above.
AWS Redshift documentation says the default format accepts fraction up to 5 digits, however this proved not to be true in this case at least
Setting TIMEFORMAT 'auto'  in the extraCopyOptions appears(?) to solve the issue locally, but since i am using AWS Glue for my Spark job i cannot be sure as i cannot load all the data locally to see if a malformed record creates the problem. I wouldn't bet on it though as i tried to cast all 3 columns to the same format with
withColumn('column', F.to_timestamp('column', format="yyyy-MM-dd hh:mm:ss"))
and this also didnt work, as the fraction milliseconds remain as well. What is strange is that the columns containing the timestamps in string format after the workaround do not look to maintain the fraction.
Does this issue ring any bell to someone with more knowledge in the internals of the spark-redshift data source?

Me Too
My problem is that SOMETIMES the application crashes with a
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.sql.Timestamp

Facing the same issue.
The error I'm getting is
Timestamp format must be yyyy-mm-dd hh:mm:ss when reading data from redshift through pyspark


fixed log function

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! :smile:

Coverage decreased (-0.39%) to 95.67% when pulling 682916c6532bcb47755d44a80fad5a09bc406bb6 on reggi:master into 20790d69c22fe5dba08dd18f6626e875d29cbabd on yahoo:master.

Coverage decreased (-0.39%) to 95.67% when pulling 682916c6532bcb47755d44a80fad5a09bc406bb6 on reggi:master into 20790d69c22fe5dba08dd18f6626e875d29cbabd on yahoo:master.

I signed the CLA :)

You are correct that this shouldn't be this - it is a bug. However, if the log method is moved to the prototype, then code that depends on the log method will break since it expects the method to be on the constructor instead of the prototype. I will close this PR and use PNGImage.log to call the log method. This will make sure that the behavior doesn't change and that the bugfix is backwards compatible.
Thank you for submitting this bug report and PR.
If you are wondering why the log is on the constructor instead of the prototype: It is there to make it possible to listen-in on non-'instance' calls like loadImage that is defined on the constructor.

Very fascinating! Thanks for the detailed description @marcelerz!


BR: allow user to specify how many buffers to allocate

Currently the BR allocated 1024 buffers in the free pool, and each socket tries to grab 32. This means that at 32 sockets, all buffers are taken by default. When there are more than 32 sockets, depending on the traffic pattern it's possible for a socket to end up with zero buffers. In this case it will block waiting for free buffers to be available, but it's non-deterministic when it will succeed.
The BR allocates the free buffer pool at start. While in theory this could be relative to the number of sockets it will use, that number isn't fixed as config reloading may add (or remote) interfaces. Also from an operational perspective a simple multiplier factor isn't a good solution, a given BR may need a higher or lower number depending on traffic patterns/historical usage/etc.
The proposal is to add a cmdline flag to the BR to specify how large the free buffer pool should be. If not specified we can default to 1024. We should also calculate a minimum value of buffers that is reasonable, something like (64 * num_sockets) + 512), and fail to load a topology file if the new value would be larger than the flag-specified value.

This is from the legacy router, does not apply anymore.


Sorting of tiles with new TileSet editor is unpredictable when using atlas

Godot version:
3.1 Alpha 5
OS/device including version:
mac OS High Sierra
Issue description:
Sorting of tiles with new TileSet editor is unpredictable when using atlas.
Steps to reproduce:

Add a TileMap
Set a TileSet and edit
Add a texture with all the tiles
Create a "New Atlas"
Select all tiles
Return to TileMap

-> Order of tiles seems to be completely randomised. Tiles should be processed left to right and top to bottom or even better, ordering should be configurable.
Quick video showing the problem: https://www.youtube.com/watch?v=OMxrGUmZgTk
Minimal reproduction project:
https://github.com/Krumelur/GodotTesting/tree/godot31_issue_24751
Open the project and go to res://Helpers/LevelConverter/Importer.tscn and select the "TemplateTileNode" node in there.

Just noticed that this might be a duplicate of https://github.com/godotengine/godot/issues/24517

@Krumelur I think I'll keep this issue as it clearly outlines a bug.

I think what it's doing is prioritizing columns first, and displaying them as rows. I looked at my atlas and the first row, at size x, was the first tile of the first x columns in my texture. So when I adjusted the view so that the row was as long as the number of columns, suddenly I was seeing full rows as columns and vice versa.
Seems like some for loops probably got flipped around somewhere, if I had to guess lol.

You guessed right. The coordinates given in Vector2 variables throughout the TileSet class are associated to column x and row y. That way the sorting algorithms of the Vector and Map class as used for filling the TileMap selection window are prioritizing the columns x. But filling it rows-first then swaps the order and makes it hard to use.
I got a fix for this symptom by using a custom sorting in editor/plugins/tile_map_editor_plugin.cpp line 524 (of the latest revision) or line 486 (of release 3.1.1-stable):
// replace
entries2.sort();
// by
struct SwapComparator {
	_FORCE_INLINE_ bool operator()(const Vector2 &p_l, const Vector2 &p_r) const {
		return p_l.y != p_r.y ? p_l.y < p_r.y : p_l.x < p_r.x;
	}
};
entries2.sort_custom<SwapComparator>();

This works as a quick workaround for those using the source version of the engine. Until there is someone more familiar with the plugin to tell whether the row-column-swap could be fixed in the tileset itself without confusing other systems.

Column x, row y actually makes some sense if you look at it from the perspective of the column and row numbers representing position on the x and y axes, it's just that it doesn't draw them the way it reads them, I think.

Right. The order in the TileSet makes sense then. And as the tiles fetched from it are filled into the widely used ItemList control that draws rows-first, the suggested fix may be the best place to intervene. I could try a PR then.


stream endpoint doesn't return integer/floats values

logs/recent returns things appropriately:
[...]
{
    "job_data": {
      "aborted": false,
      "bytes_downloaded": 239880,
      "items_downloaded": 1,
      "items_queued": 34,
      "finished_at": null,
      "queued_at":<PHONE_NUMBER>,
      "started_at":<PHONE_NUMBER>,
      "delay_min": 250,
      "delay_max": 375,
      "note": null,
      "r1xx": 0,
      "r2xx": 1,
      "r3xx": 0,
      "r4xx": 0,
      "r5xx": 0,
      "runk": 0
    },
    "type": "stdout",
    "ts":<PHONE_NUMBER>,
[...]
  },
[...]

while /stream does not:
{
  "ts":<PHONE_NUMBER>,
[...]
  "type": "stdout",
  "job_data": {
    "url": "http:\/\/www.akiba-online.com\/",
    "fetch_depth": "inf",
    "log_key": "5ohl1t1n3kxqsu91r59dnatkf_log",
    "user_agent": "",
[...]
    "started_in": "#archivebot",
    "delay_min": "500",
    "delay_max": "1000",
    "settings_age": "53",
    "concurrency": "3",
    "queued_at": "1416228497",
[...]
    "started_at": "1416241857.683523",
    "log_score": "6874508",
    "r1xx": "0",
    "r2xx": "3950439",
    "r3xx": "987828",
    "r4xx": "319099",
    "r5xx": "25377",
    "runk": "212860",
    "error_count": "238237",
    "last_analyzed_log_entry": "6874507.0",
[...]
  }
}

where everything is a string.

Yeah, /stream is just dumping stuff out of Redis -- the program providing its data feed has no knowledge of the job data format.  I wanted to minimize parsing.
The program providing the data feed could probably send its data through jq to present numbers as numbers.


Update bug report template

Some proposed changes after combing through the backlog

Going to merge this as we're getting a big influx


CarouselView: onTap != null checked to avoid override of children's onTap (if any)

onTap in CarouselView overrides the children onTap even if its value is null
The onTap method in CarouselView overrides the onTap of any button widget or GestureDetector in the children. Hence, this should only override if the value is not null.
Before
Can't click through any of the tappable in the children although the onTap is null.
https://github.com/user-attachments/assets/e78eee17-4d19-43bf-8d0f-0904a23be2d1
After
If the onTap is null, it will click through. If its not null it will override
https://github.com/user-attachments/assets/2c8fddb2-c344-438e-8e30-3cfda87eb7d4
Issue Fixed
#155199 Has been fixed in this PR in better way
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Closing the PR as per duplication with https://github.com/flutter/flutter/issues/154701


Detect exporting a constant integer that is too big

This is an attempt to fix https://github.com/NationalSecurityAgency/ghidra/issues/5592

We'll take a closer look at the code, but this functionality is a reasonable addition to the sleigh compiler.
We have both a java and a c++ sleigh compiler that we keep in sync:
https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Decompiler/src/decompile/cpp/slgh_compile.cc
Are you interested in making the changes there too?  If not I can add them.

I think I don't have time available to work on that anymore, If you could add those changes will be great.


Rosdep keys could not be resolved

Bug report

rosdep install --from-paths src --ignore-src --rosdistro foxy -yr
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
rmf_demos_panel: Cannot locate rosdep definition for [python3-flask-cors]
building_systems_visualizer: Cannot locate rosdep definition for [rmf_schedule_visualizer_msgs]
rmf_demos: Cannot locate rosdep definition for [rmf_rviz_plugin]
rmf_visualization: Cannot locate rosdep definition for [rmf_visualization_fleet_building_systems]
Continuing to install resolvable dependencies...
#All required rosdeps installed successfully

Required information:

Operating system and version:

Ubuntu 20.04

OpenRMF installation type:

Following the README in https://github.com/open-rmf/rmf

OpenRMF version or commit hash

eee95cf

ROS distribution and version:

ROS2 Foxy

ROS installation type:

From source

Package or library, if applicable:

N/A

Description of the bug
While following the README in https://github.com/open-rmf/rmf, in the Download the Source Code section, during the rosdep install --from-paths src --ignore-src --rosdistro foxy -yr, I got a rosdep key error. I attached the console printout in the bug report.
Expected behavior

rosdep should finish without error
Actual behavior

ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
rmf_visualization: Cannot locate rosdep definition for [rmf_visualization_fleet_building_systems]
rmf_demos_panel: Cannot locate rosdep definition for [python3-flask-cors]
building_systems_visualizer: Cannot locate rosdep definition for [rmf_schedule_visualizer_msgs]
rmf_demos: Cannot locate rosdep definition for [rmf_rviz_plugin]
Continuing to install resolvable dependencies...
#All required rosdeps installed successfully
Screenshots

Additional information

Hi there,
You should have still been able to build your workspace without any build errors. The expectation that rosdep should execute without flagging any errors is not accurate. There may be dependencies that rosdep is unable to install (eg python3-flask-cors) but the installation guide has steps to install these manually. Having said that, there were some packages with incorrect dependencies that have been fixed. You can pull in the latest changes in rmf_visualization and rmf_demos. Now running rosdep should only return an error for python3-flask-cors which can be ignored as you will manually install this package as stated in the installation guide.

That would be great. There are other python3 packages that we manually install as well https://github.com/open-rmf/rmf#additional-dependencies. Should we consider adding rosdep keys for those as well?

Roger, will open a separate ticket to address this.


Cleanup unused code in psl-native

PR Summary
Related #6874

Remove unused files.
Clean up #if SILVERLIGHT

PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] User-facing Documentation needed

[ ] Issue filed - Issue link:

Testing - New and feature

[x] Not Applicable or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[x] Add [feature] if the change is significant or affects feature tests

Did you build the libpsl-native after changing this? CI build doesn't build it as we pull the existing package. Do a search with the method name or file name, you will find more references to them.
[C:\PowerShell]
PS:17> dir * -Recurse | sls -SimpleMatch 'GetComputerName()'

src\libpsl-native\src\getcomputername.cpp:17:char* GetComputerName()
src\libpsl-native\src\getcomputername.h:10:char *GetComputerName();
src\libpsl-native\src\getfullyqualifiedname.cpp:21:    char *computerName = GetComputerName();
src\libpsl-native\test\test-getcomputername.cpp:33:    ASSERT_STREQ(GetComputerName(), expectedComputerName);
src\libpsl-native\test\test-getfullyqualifiedname.cpp:16:    char *hostname = GetComputerName();

[C:\PowerShell]
PS:18> dir * -Recurse | sls -SimpleMatch 'GetCurrentProcessId()'

src\libpsl-native\src\getcurrentprocessorid.cpp:8:pid_t GetCurrentProcessId()
src\libpsl-native\src\getcurrentprocessorid.h:11:pid_t GetCurrentProcessId();
src\libpsl-native\test\test-getcurrentprocessid.cpp:10: const int32_t currentProcessId = GetCurrentProcessId();
src\libpsl-native\test\googletest\src\gtest-death-test.cc:723:      StreamableToString(static_cast<unsigned
int>(::GetCurrentProcessId())) +

[C:\PowerShell]
PS:19> dir * -Recurse | sls -SimpleMatch 'GetComputerName.cpp'

src\libpsl-native\src\CMakeLists.txt:12:  getcomputername.cpp
src\libpsl-native\test\CMakeLists.txt:9:  test-getcomputername.cpp

[C:\PowerShell]
PS:20> dir * -Recurse | sls -SimpleMatch 'GetCurrentProcessId.cpp'

src\libpsl-native\test\CMakeLists.txt:7:  test-getcurrentprocessid.cpp

[C:\PowerShell]
PS:21> v .\src\libpsl-native\src\CMakeLists.txt
[C:\PowerShell]
PS:22>
[C:\PowerShell]
PS:22> dir * -Recurse | sls -SimpleMatch 'getcurrentprocessorid.cpp'

src\libpsl-native\src\CMakeLists.txt:10:  getcurrentprocessorid.cpp

@daxian-dbw I've collected a few commits, all of which are in different places in code. I tried to split this into a few small PR but it seems I started in the wrong direction. I guess the right direction is to clean C# code and then clean and republish the psl package.


InteractionManager Proposal

I can't remember if I brought this up somewhere else, if I did, sorry for the reiteration. I have tried to create this issue to be a more standard proposal conveying my thoughts on pixi.js's InteractionManager.
Currently it does allow for interactivity, which is pretty much what a name like InteractionManager means. What this doesn't mean is that it should be coupled with DOM events and cross platform compatibility. It should instead take a more hands-off approach to handling interactivity from different input devices.
API
PIXI.Stage (refactor)
The Stage can be simplified by removing much of the current InteractionManager logic it contains, but it may instead provide direct access to methods such as:

PIXI.Stage.prototype.getDisplayObjectAtPoint(x, y)
PIXI.Stage.prototype.getInteractiveDisplayObjectAtPoint(x, y)

Doing this, the logic within the stage can be much more focused on pixi.js's display list, and optimization. Such as what display object should dispatch events, etc..
PIXI.InteractionManager (refactor)
The InteractionManager does not need to contain the platform compatibility code that it does now, and can be much more decoupled from everything, which means basically it becomes completely optional. This doesn't mean the cross platform code can't be moved to another optional module. A new API may look more like this:

new PIXI.InteractionManager(stage, view)

stage is optional, set InteractionManager.prototype.stage to value passed
view is optional, set InteractionManager.prototype.view to value passed

PIXI.InteractionManager.prototype.handleStart([interaction], stage, view)

stage and view are optional. Default to properties that may be set, throw error if no valid references.

PIXI.InteractionManager.prototype.handleMove([interaction], stage, view)

stage and view are optional. Default to properties that may be set, throw error if no valid references.

PIXI.InteractionManager.prototype.handleEnd([interaction], stage, view)

stage and view are optional. Default to properties that may be set, throw error if no valid references.

PIXI.InteractionManager.prototype.handleCancel([interaction], stage, view)

stage and view are optional. Default to properties that may be set, throw error if no valid references.

The [interaction] argument is specified as an array to handle simultaneous interactions. Each interaction object should adhere to an interface of something like this:
{
    id: 123,        // For tracking the total interaction between 'start', 'move', 'end', and 'cancel'
    timeStamp: 123, // To check whether to handle or drop this event
    pageX: 123,     // Converted to PIXI.Stage coordinate space (relative to renderer.view), then used to get the pixi interactive target
    pageY: 123      // Converted to PIXI.Stage coordinate space (relative to renderer.view), then used to get the pixi interactive target
}

PIXI.Interaction (new)
There can be a helper PIXI.Interaction that provides methods like:

PIXI.Interaction.fromMouseEvent(event) returns Array of objects
PIXI.Interaction.fromTouchEvent(event) returns Array of objects
PIXI.Interaction.fromPointerEvent(event) returns Array of objects
PIXI.Interaction.fromAutoDetectEvent(event) as a really nice-to-have

Interaction Events
The InteractionManager can then tell display objects to dispatch events for 'click', 'start', 'move', 'end', and 'cancel' respectively.
The event passed to a listener added to a display object could look like this:
{
    type: 'start',   // 'click', 'start', 'move', 'end', 'cancel'
    interaction: {}, // interaction passed
    target: {},      // The PIXI.DisplayObject interacted with
    stageX: 123,     // The PIXI.Stage x coordinate the interaction was converted to
    stageY: 123,     // The PIXI.Stage y coordinate the interaction was converted to
    x: 456,          // The event.target coordinate the interaction was converted to
    y: 456           // The event.target coordinate the interaction was converted to
}

This I'm not certain of. It would be much easier, and maybe a more simple approach to just let the manager dispatch these events, and leave the display list to handle what is actually interactive.
Usage
Please review the following gist:
https://gist.github.com/drkibitz/6127080
Conclusion
pixi.js is a great rendering engine, but I don't believe a rendering engine should try to handle DOM events directly. It should instead provide an API that allows an efficient, abstracted, and standard approach to interactivity that any platform's specific event implementation can hook into.

@englercj Why reinvent the wheel when there are good mouse/interaction functionality designed in other libraries?
Take a look for instance at Qt library's implementation (QWidget is like a DisplayObject):
http://qt-project.org/doc/qt-4.8/qwidget.html#mouseMoveEvent
http://qt-project.org/doc/qt-4.8/qmouseevent.html

Closing this for now. InteractionManager has been rebuilt for v3 and  is now optional as it is 100% separate from the core. Thanks all!

Hello, got an alert upon closing this issue so thought I'd look at the progress of the dev branch. I see the direction taken within the interaction/ directory, and very impressed with the amount of work going into the next version of this lib, great job! I have to be honest though, the interaction direction is a bit confusing out of the gate.
Also just saw a typo here:
https://github.com/GoodBoyDigital/pixi.js/blob/dev/src/interaction/interactiveTarget.js#L6
Sorry, this was just quick perusal, no time for any official contribution at this time, but hopefully in the future. Good luck on v3!


Making -static conditional based on libtype config

static breaks shared library builds

@zet23t thanks for the review!


No config accepting in Sublime 3 or 2

Good morning.
FTPSync > Found no config for {C:\Users\li_morgan\AppData\Roaming\Sublime Text 2\Packages\FTPSync\FTPSync.sublime-settings}
FTPSync > Found no config for {C:\Users\li_morgan\AppData\Roaming\Sublime Text 2\Packages\FTPSync\FTPSync.sublime-settings}
FTPSync > Config not found for: C:\Users\li_morgan\AppData\Roaming\Sublime Text 2\Packages\FTPSync\FTPSync.sublime-settings
This is in my console on starting sublime (3 and 2) and when me saving config for FTPSync. When I change any configuration in Settings for FTPSync it doesn't take any effect. I need to change "max_threads" from 4 to 3 and I can't do this. What should I do for it to work?
Thanks!

Hi,
this is understandably confusing ... it only says that FTPSync detected file being saved, but found no related ftpsync.settings file and thus will not sync it via FTP. It does not mean that the change of settings would be ignored.
I'm sure you tried restarting sublime ... beside that, the implementation is currently imperfect in that this option is only limiting the threads for transfer, but the actually number of connections (which I assume you're after) can be higher (e.g. during the transfer there's another connection made while handling some even like file save) ... so please try using 2 or 1 if you're having troubles with too many connections to the server

My hosting doesn't support more than 3 connections by one user. But when FTPsync sees the error  http://joxi.ru/GrqyDoQFE99Krz
FTPSync.lib3.ftplib.error_temp: 421 I can't accept more than 3 connections as the same user
and stops to download the folder. This is the one problem of your plugin i see:)

workerLimit = settings.get('max_threads') printMessage("This is work limit - " + str(workerLimit))
This is what I insert in code of FTPsynd
"max_threads":2,
This is in user config for ftpsync (even in default config)
reloading Packages/FTPSync/FTPSync.sublime-settings b'FTPSync > This is work limit - 5'
This is what I see in  console. Config doesn't work!


Remove threaded_*_minimum_instances project settings

Unifies them under a single WorkerThreadPool::should_multithread() function, since adding a project setting for every use of multithreading isn't scalable. This also makes it possible to completely override all multithreading behavior by setting threading/worker_pool/max_threads to 1.[^notworking]
[^notworking]: This setting currently doesn't work since it's initialized before project.godot is loaded, but that's a separate issue.
I've set the minimum number of instances per thread to 4 for now,[^logic] but this almost certainly needs to be tuned by people more familiar with those areas of the codebase.
[^logic]: Assuming the previous minimum threshold of 32 was tuned for a standard 4c8t systems, every logical core would have received a batch size of 32/8=4

I like the idea of scaling based on number of threads available, but this PR also takes a lot of flexibility away from the user and fixes the instances-threads ratio at a much lower number than previously. For example, for a user with 16 available threads (typical for a gaming setup), multithreaded culling will now kick in at 64 instances instead of 1000 instances. I'm not sure that we would actually see the benefits of multithreading with only 64 instances.
At the very least, I think we need to be queuing up more than 4 tasks per thread. But there still may be room for user settings here.

At the very least, I think we need to be queuing up more than 4 tasks per thread. But there still may be room for user settings here.

Ideally, WorkerThreadPool::should_multithread() would accept the expected number of microseconds that it would take to process the entire group. To use this, developers would manually measure and hardcode a μs/task multiplier for every use of this function ( microbenchmarking macros would help here, see godotengine/godot-proposals#6747 ). We could then expose a "threaded_minimum_microseconds" user setting to control this.
However, I'm not convinced it's worth the effort, since we're talking about the behavior of small groups here, which by nature aren't expected to affect performance much.
For now, how does 16 sound?


cold start still shows white background color before acrylic loaded

When the application starts for the first time on Windows, there is a white background color show first then change to acrylic after 1 sec.
How can I prevent this??
I try to set MaterialApp to transparent, but no hope
import 'package:flutter/material.dart';
import 'package:flutter_acrylic/flutter_acrylic.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Window.initialize();
  await Window.setEffect(
    effect: WindowEffect.acrylic,
    color: const Color(0xCC222222),
  );
  // await Window.enterFullscreen();
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // This is the theme of your application.
        //
        // Try running your application with "flutter run". You'll see the
        // application has a blue toolbar. Then, without quitting the app, try
        // changing the primarySwatch below to Colors.green and then invoke
        // "hot reload" (press "r" in the console where you ran "flutter run",
        // or simply save your changes to "hot reload" in a Flutter IDE).
        // Notice that the counter didn't reset back to zero; the application
        // is not restarted.
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
        backgroundColor: Colors.transparent
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page')
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      // This call to setState tells the Flutter framework that something has
      // changed in this State, which causes it to rerun the build method below
      // so that the display can reflect the updated values. If we changed
      // _counter without calling setState(), then the build method would not be
      // called again, and so nothing would appear to happen.
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    // This method is rerun every time setState is called, for instance as done
    // by the _incrementCounter method above.
    //
    // The Flutter framework has been optimized to make rerunning build methods
    // fast, so that you can just rebuild anything that needs updating rather
    // than having to individually change instances of widgets.
    return Scaffold(
      // appBar: AppBar(
      //   // Here we take the value from the MyHomePage object that was created by
      //   // the App.build method, and use it to set our appbar title.
      //   title: Text(widget.title),
      // ),
      body: Center(
        // Center is a layout widget. It takes a single child and positions it
        // in the middle of the parent.
        child: Column(
          // Column is also a layout widget. It takes a list of children and
          // arranges them vertically. By default, it sizes itself to fit its
          // children horizontally, and tries to be as tall as its parent.
          //
          // Invoke "debug painting" (press "p" in the console, choose the
          // "Toggle Debug Paint" action from the Flutter Inspector in Android
          // Studio, or the "Toggle Debug Paint" command in Visual Studio Code)
          // to see the wireframe for each widget.
          //
          // Column has various properties to control how it sizes itself and
          // how it positions its children. Here we use mainAxisAlignment to
          // center the children vertically; the main axis here is the vertical
          // axis because Columns are vertical (the cross axis would be
          // horizontal).
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
      backgroundColor: Colors.transparent,
    );
  }
}

I am also facing this issue, when i click in the application, only then the effect is seen, but when i click in another window, the effect is not seen.
So, only when the window is active the effect is seen.
But i want the effect to remain always.


Separate passwords into its own table

We could probably remove some of the ugly looking "filtering" we do while we return user objects now too - don't merge until I look into it a bit more


build fails due to gpg: cannot open '/dev/tty'

Using version 11 (debian), when attempting to build the image I received the following error:
gpg: cannot open '/dev/tty': No such device or address
and the process was aborted.
I could solve it by passing the option --no-tty to the gpg command invocations on lines 31 and 67 of the Dockerfile.
Regards.

This is likely an issue with your local environment, It builds fine for us https://travis-ci.org/docker-library/postgres/builds/452492635
This is the only relevant search result for your specific error https://stackoverflow.com/questions/52900636/gpg-command-works-in-shell-but-not-in-go-exec-command
It's possibly related to https://github.com/docker-library/official-images/issues/4252
I recommend using the images we officially build/publish; for further assistance debugging your local environment the best I can recommend is trying the Docker Community Forums, the Docker Community Slack, or Stack Overflow.

So this is an issue with a recent gpg update and we are encountering it, we filed a bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913614#27

The bug appears to be due to the fix for https://bugs.debian.org/906545
-- where we applied cleaning to keys being imported.
That testing didn't try out all the variants without having access to a tty.

And we've opened a PR on it https://github.com/docker-library/postgres/pull/527
From the comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913614#27

PS i do encourage everyone who is automating the use of gpg to use
--batch everywhere, as this forces GnuPG into a mode that is expected to
be used for automation (its "API", for lack of a better term, as opposed
to its "UI", which is its normal non-batch mode).  And, FWIW, i agree
with Tianon that GnuPG should simply assume --batch if no tty exists,
but that's not the kind of change i can fit into debian stable, i think.


Data update frequency

Updating should be close to the whole hours, e.g. every minute between 13:58 and 14:02. Alternatively push updates when a new value of energy or price is available, see some info here.

Check push update with min/max sensor L249


Merge 5-6 updates to live

Docs Build status updates of commit e36b9a6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Language/Concepts/Getting-Started/writing-assignment-statements.md
:white_check_mark:Succeeded
View

Language/Concepts/Getting-Started/writing-executable-statements.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/for-eachnext-statement.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/getobject-function.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/ifthenelse-statement.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/invalid-use-of-object.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/isobject-function.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/object-variable-not-set-error-91.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/rgb-function.md
:white_check_mark:Succeeded
View

Language/Reference/User-Interface-Help/set-statement.md
:white_check_mark:Succeeded
View

Library-Reference/Concepts/what-s-new-for-vba-in-office-2016.md
:white_check_mark:Succeeded
View

access/Concepts/Data-Access-Objects/find-a-record-in-a-table-type-dao-recordset.md
:white_check_mark:Succeeded
View

access/Concepts/Error-Codes/comparison-of-data-types.md
:white_check_mark:Succeeded
View

access/Concepts/Miscellaneous/currentproject-issqlbackend-property-access.md
:white_check_mark:Succeeded
View

access/Concepts/Miscellaneous/execute-method-ado-connection.md
:white_check_mark:Succeeded
View

access/Concepts/Miscellaneous/the-number-of-columns-in-the-two-selected-tables-or-queries-of-a-union-query-do.md
:white_check_mark:Succeeded
View

access/Concepts/Miscellaneous/type-property-columnadox.md
:white_check_mark:Succeeded
View

api/Access.Application.DCount.md
:white_check_mark:Succeeded
View

api/Access.CodeProject.IsSQLBackend.md
:white_check_mark:Succeeded
View

api/Access.application.davg.md
:white_check_mark:Succeeded
View

api/Excel.LineFormat.InsetPen.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Caption.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ChildItems.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ClearLabelFilters.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.MemberPropertyCaption.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.MemoryUsed.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Name.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.NumberFormat.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Orientation.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Parent.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ParentField.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ParentItems.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.PivotFilters.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.PivotItems.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Position.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.PropertyOrder.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.PropertyParentField.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.RepeatLabels.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ServerBased.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ShowAllItems.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ShowDetail.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.ShowingInAxis.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.SourceCaption.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.SourceName.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.StandardFormula.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.SubtotalName.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Subtotals.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.TotalLevels.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.UseMemberPropertyAsCaption.md
:white_check_mark:Succeeded
View

api/Excel.PivotField.Value.md
:white_check_mark:Succeeded
View

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[PPOTrainer] A workaround for failing log_stats

Currently in the 0.7.0 version ppo_trainer.log_stats fails with the error
KeyError                                  Traceback (most recent call last)
<ipython-input-6-aac057b11b52> in <cell line: 138>()
    155     #### Run PPO step
    156     stats = ppo_trainer.step(query_tensors, response_tensors, rewards)
--> 157     ppo_trainer.log_stats(stats, batch, rewards)

/usr/local/lib/python3.10/dist-packages/trl/trainer/ppo_trainer.py in log_stats(self, stats, batch, rewards)
   1297
   1298                 table_rows = [
-> 1299                     list(r) for r in zip(batch["query"], batch["response"], batch["answer"], rewards.cpu().tolist())
   1300                 ]
   1301                 logs.update(
KeyError: ‘answer’

Introduced in #424 the fix is to create a new parameters columns_to_log, to let users have control on which column name to log in wandb. We set that value to the default so that it would work for the current PPOTrainer related code, and adapted the current code examples for textenvs
cc @lvwerra @vwxyzjn

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Add pre-configured container for a single-node Elastic deployment

Is your feature request related to a problem? Please describe.
No problem, except we are in the process of creating our own custom Elasticsearch node configuration for testcontainers-dotnet, so I figured we might as well get it integrated upstream.
Describe the solution you'd like
Similarly to how testcontainers-java has an ElasticsearchContainer, it would be great to have an ElasticsearchTestcontainer in this repository. I would be happy to contribute this.
A few things I would like to have clarified before doing this:
Support for multiple major versions
The Java implementation has a single ElasticsearchContainer intended for use across all versions of Elastic, including the OSS distribution. It already has logic tailored to version 8 (isAtLeastMajorVersion8) and the OSS distribution (withPassword()), which could get ugly in the long term. Would you prefer a single container and configuration object, with support for multiple versions, or separate ones for each major version?
Single vs. multi-node
The java version currently only supports single-node operation. I think we should limit the ElasticsearchTestcontainer for this repository to single-node operation as well, and refer people to Docker Compose (once supported) if they need a multi-node cluster.
Describe alternatives you've considered
Keeping the configuration to ourselves in our private test helper projects. But where is the fun in that?
Additional context
I think it makes sense to do this as part of testcontainers#493 right away.

I think it makes sense to do this as part of #493 right away.

Yes, it does 😀.

Dunno if we should close this yet, but we have an MVP using the classic module implementation.

Just to know...any eta for 2.2.0? we need ElasticSearch integration and I have to decide if add custom configuration to our projects or wait for a new library release.
So thanks.

I would like to include the TLS feature in the next release. Most parts are done, but I think it will take another couple of days until we are ready for a release.
You can use the latest snapshot release in the meantime: 2.2.0-beta.2835065501, this includes #523.

@HofmeisterAn i'm testing 2.2.0-beta.2835065501 version and i have problem to pull testimage:
Docker.DotNet.DockerImageNotFoundException : Docker API responded with status code=NotFound, response={"message":"No such image: testcontainers/ryuk:0.3.4"}
On command line docker pull testcontainers/ryuk:0.3.4 works like a charm.
Any advice?

Did you remove the image and try it again? I know some devs have temporary issues pulling images. If you still have problems, please create another issue. Do you use a private registry? How does your Docker config look? Any custom configurations?

Strange issue.... removed images and ran again and again without success...what I found is that elasticsearch image is pulled correctly using ElasticsearchTestcontainer class but not testcontainers/ryuk:0.3.4, If i run docker pull testcontainers/ryuk:0.3.4 everything is correct. I presume .net library uses the same approach for both images so really strange. @HofmeisterAn on your side everything run correctly? If the next days I will have the same problem I will create a new issue for sure!

Since we now have the new release that includes the Elasticsearch module, I will close this issue. While it does not currently contain all the great features of the Java implementation, we can create an issue and add them over time if anything is missing.


Implicit accounts as first-class citizen

Currently NEAR Wallet has pretty broken flow of funding. There are constant issues with users not understanding and needing to recover funds. This has affected everyone from small to large holders already.
We had this conversation previously, and it was mostly due to us wanting to push for "named" accounts that we are doing this flow. At the same time, we are building up new ways of onboarding users via implicit accounts.
I suggest we accept that implicit accounts are first class citizens.
Which means that user should be able to create and maintain accounts like that.
If they want to create named account after they already have funds in the wallet - the "Create Account" would allow that.
User flows
User doesn't have any existing account

Create Account just allows to setup seed phrase or use Ledger. Less secure option is to email / sms that same seed phrase to the user. This is the same seed phrase that is stored in local storage.
This creates an implicit account

After account gets funded, there is a prominent button appears that says "You can create a new account like .near" that leads to "Create Account".
The implicit account that they have created still in the list of accessible accounts even if named account(s) are created. And they have a way to recover it as well. That account doesn't get deleted either.
Also after account gets funded, it should suggest to improve security of the account via switching recovery key, etc.
User has already existing account in the wallet

Create Account offers two options: create "named" account or less prominent create "anonymous" account.
Select recovery / 2FA / etc.
Uses funds from the account user already have in the wallet to fund this account.

@corwinharrell I want to discuss any modifications to the current flow (and the impact on other activities in the pipeline), so we can think if we can adopt any temporary mitigations.
I see this request tangent to:
#1165 and #1297. 1297 in particular includes the functionality to save and restore the onboarding state, so we may have an opportunity to capitalize on this request for future UX improvements.
Also see:
#1188
#1130
#1131
cc @kcole16

@ilblackdragon I am in agreement for the most part. In fact, the initial design proposal for the create/fund account flow had implicit accounts being created before presenting the option to add a unique account name, which the user could choose to ignore if they wished. (This has even already been designed for the most part). Here is the flow that was created to illustrate these changes:
https://whimsical.com/create-account-2y3VYfTQXAAoPo6P2BgFBH
One question I have about a clear UX pitfall in the variant you described above:
If I sign up for a NEAR account as a new user, my goal is to acquire a single account. No user ever signs up to a service hoping to receive multiple accounts.
If the initial implicit account is not deleted after a user opts in to receive a named account, and the named account is not acting as a "replacement" to which the balance of the implicit account if transferred, we are now telling users "You have no choice but to maintain 2 accounts, sorry."
This experience is muddy and is a clear indicator of the UX being dictated by forced limitations rather than by intentional design. I'd be curious to hear some thoughts in response, and if we can think of any ways to mitigate this.

If the initial implicit account is not deleted after a user opts in to receive a named account, and the named account is not acting as a "replacement" to which the balance of the implicit account if transferred, we are now telling users "You have no choice but to maintain 2 accounts, sorry."

so my 2 cents is that this is actually quite acceptable for crypto. I probably have like 20+ different ETH addresses over the year...I dont think there is any downside have having the redundancy. If the user wants to use the name account, he could do that (since it's simple and easy). But if the relationship of the 2 accounts are somehow not easily identifiable via the explorer, it's actually great for the more privacy minded folks. For example, i would use the named acocunts for games or small transcations, but might use the implicit account for staking or anything I would like to keep some level of anonymity.
On the other hand, it's much worse if the account gets deleted and somehow funds got deposited to the old implicit account (which get recreated anyway currently...) But I could tell you there are at least 10+ cases I am aware of where users funded the deleted implicit account. The panic is real (put yourself into the position of someone just purchased 50k NEAR from Binance and whoops, money is gone.)
While this still represents a small % of the users, given the financial nature of crypto, we should aim for the safer choice.

At this point, I'm of the opinion that we should not, under any circumstances, issue a deleteAccount transaction from the wallet. It is far too dangerous, and even in the best case scenario can be scary and confusing. It will get even more dangerous once users start acquiring tokens and other assets, as we have no way to migrate/transfer these to another account.
That being said, I strongly agree with @corwinharrell  it is suboptimal to force users to create two accounts just to have a named account. We should look into ways to mitigate this (though may need to consider them longer term).

@azhang2013 I think those are valid points. I'm not arguing against the fact that keeping the implicit account is the objectively safer option. Ultimately what I am trying to point out is the differences between user expectations and reality. While it's not the end of the world, it's always going to be a little bit of a surprise and a series of inconveniences to users who go in looking to create a single account and end up with 2.
A significant factor to consider as well is the balances of these accounts. For example:

If I create a new account with the Wallet, I first create an implicit account. By necessity, this account will have a balance (regardless of the funding source)
Then, if I wish to create a named account, the new named account will, by necessity, also have a balance. I now have two accounts with 2 balances. If I want to consolidate my balances, I have to go in and move my funds from one to another.

While none of this presents a security risk, there's lots of things here that are simply inelegant and are an inconvenience for the user's original expectation and intent to sign up and create a single account with a single balance.

I agree with @corwinharrell that just giving user 2 accounts gonna be suboptimal and confusing.
I think a solid compromise here which we discussed before is to keep implicit account info, but only show it if it still has funds. Or maybe even show it specifically as "TODO item" saying "claim your funds" or smth like that if you accidentally send more tokens there.
In any case, something that we need to address is to have a flow to let user finish something they dropped off at (like creating account). We have quite a few of different tasks which often aren't completed:
https://github.com/near/near-wallet/issues/1182

We had this conversation previously, and it was mostly due to us wanting to push for "named" accounts that we are doing this flow. At the same time, we are building up new ways of onboarding users via implicit accounts.
I suggest we accept that implicit accounts are first class citizens.

@ilblackdragon another alternative is to change funding flow to send directly to .near accounts. Basically have a faucet that creates limited .near account and removes it within given amount of time if not funded. I think this is the best solution in terms of avoiding confusion, but creates mild DoS risk (attacker can lockup faucet tokens for a while).

At this point, I'm of the opinion that we should not, under any circumstances, issue a deleteAccount transaction from the wallet. It is far too dangerous, and even in the best case scenario can be scary and confusing. It will get even more dangerous once users start acquiring tokens and other assets, as we have no way to migrate/transfer these to another account.

I think what we need to do is check whether account has any other keys except the one that is "implicit":

if it has any other keys – means you actually imported it into wallet as full account and it's in use. We don't want to delete such account
if it only has default key – we can delete it safely as it will get recreated with it's implicit key once it receives funds

if it only has default key – we can delete it safely as it will get recreated with it's implicit key once it receives funds

The point is that the deletion of account is very unexpected behavior for existing blockchain users. Even if it gets recreated and there is a normal flow there. Making sure uses are not surprised and delighted is the goal here.

Basically have a faucet that creates limited .near account

Yes, if we make a faucet - that would be the best.

The point is that the deletion of account is very unexpected behavior for existing blockchain users. Even if it gets recreated and there is a normal flow there. Making sure uses are not surprised and delighted is the goal here.

Using this argument we should also revert back to using one seed phrase and key and approving every transaction through wallet – as having multiple keys, app logins, etc is also by itself surprising for existing blockchain users.
Note that I agree 100% that nobody should lose access to funds or even feel like they lost access to their funds.
But "make sure existing blockchain users not surprised" isn't a sufficient argument here, as we've consciously decided to use surprising model of accounts with multiple keys. It's always gonna keep surprising users from existing blockchains.
I have a fix here to avoid deleting accounts when they aren't exactly equivalent to not created ones:
https://github.com/near/near-wallet/pull/1461/files

Basically have a faucet that creates limited .near account

Yes, if we make a faucet - that would be the best.

Glad we have consensus here. Funding through implicit accounts is definitely at best a kludge for existing infra, not a desired experience that we need to optimize.

I think what we need to do is check whether account has any other keys except the one that is "implicit":

if it has any other keys – means you actually imported it into wallet as full account and it's in use. We don't want to delete such account
if it only has default key – we can delete it safely as it will get recreated with it's implicit key once it receives funds

That's not always correct. If someone created an account in another wallet application and then NEAR Wallet removes this account - the other wallet application may not know how to behave around that. Also that account is probably should not be drained of funds in the first place.
So I second @kcole16's point to not delete any accounts. Instead add implicit account into the list of available accounts in the NEAR Wallet.
Also note what Robert pointed out - that if someone else creates an account with the name you entered while you are funding your implicit account - user is stuck in a very weird and unexpected state (they see account they entered exists but it's not theirs).

we've consciously decided to use surprising model of accounts with multiple keys

There is surprising as new functionality (named accounts, multiple keys, contracts on accounts) which is fine and there is "I just sent $100k to this account but it doesn't show up in my wallet" surprising.

Alright so in order to move forward with design, I think we need consensus on a couple key components here. @ilblackdragon @vgrichina @kcole16 if we could achieve this by the end of the week we could work to design around this problem in the next sprint. Would be great to get answers articulated as succinctly as possible.

Account deletion: Will we ever delete an account during the create/fund flow? If so, at what point?
Faucet: Is it realistic for us to plan on designing around a faucet any time soon?
Multiple Accounts: Is it possible for us to avoid the issue of supplying the user with more accounts than they need, given our constraints?

I agree with Corwin, let's wrap this discussion.
I don't have enough elements to decide myself which hypothesis is better, but based on what I already know:

the account deletion is still useful to sweep funds from unused accounts, so I would disable it from the onboarding and the wallet in general, but be ready to keep it for very specific (and tested at every release) corner cases - e.g. decommissioning of lockup accounts

please do this temporary faucet! We also have the feature #17 in the roadmap, proposed by Nima.

it may not be KISS-compliant, but we may propose a sweep* command as a middle-ground between keeping the implicit account, and using a faucet to maintain the named account as primary.

Common Bitcoin wallets have two distinct actions: import a private key, and sweep a private key. While the first is self-explanatory (you simply add more keypairs to your wallet, along with their addresses), the latter was used to transfer funds from an old type of private key (WIF format) to a new one (BIP32). In our case, the wallet would detect funds in the original implicit accounts, and kindly ask the user to transfer them to the new main account.

Faucet: Is it realistic for us to plan on designing around a faucet any time soon?

@corwinharrell faucet is definitely realistic as long as there is will to fund it with tokens + maintain current flow as fallback if faucet is under DOS attack.

That's not always correct. If someone created an account in another wallet application and then NEAR Wallet removes this account - the other wallet application may not know how to behave around that. Also that account is probably should not be drained of funds in the first place.

If somebody has created account in other wallet application how would it end up as a funding account? If user imported it in the wallet with seed phrase –  it would have extra keys on account.
The problem with deleting account is specific to Ledger, because with same Ledger you get the same funding account ID on every device, which we didn't account for specifically.

Instead add implicit account into the list of available accounts in the NEAR Wallet.

This is very suboptimal for a happy path. First – we'd have to leave some extra tokens to keep implicit account around (why even do it when it is actually recreated when you send tokens again?), second – instead of getting questions and confusion about 2 accounts only for failure cases we now would get them for success case as well.

Also note what Robert pointed out - that if someone else creates an account with the name you entered while you are funding your implicit account - user is stuck in a very weird and unexpected state (they see account they entered exists but it's not theirs).

This is separate orthogonal issue. Your implicit account won't be removed in this case (at least after bugfix to make sure create_account doesn't fail silently )

we've consciously decided to use surprising model of accounts with multiple keys

There is surprising as new functionality (named accounts, multiple keys, contracts on accounts) which is fine and there is "I just sent $100k to this account but it doesn't show up in my wallet" surprising.

Sure, that's what I think too:

Note that I agree 100% that nobody should lose access to funds or even feel like they lost access to their funds.

Also check out https://github.com/near/near-wallet/issues/1182 – I think there is quite a few other issues with dropping off something, etc that we need to surface to user.
Like e.g. if user deposited funds again accidentally to implicit account, we should show it somewhere. But IMO it shouldn't be like having an actual account in a list. But more like "Claim funds from 343432434...342343 to what_you_wanted.near".
In any case my preferred solution would be to invest most of the time to get funding .near directly working 95% of the time. Then implicit account funding becomes a fallback and we wouldn't need to find an ideal solution for a "fallback for a fallback".

@vgrichina the idea of a faucet seems the best one, but it's also tangent to the wallet today, as we need a constant inflow of tokens and some "budgeting".
Also, providing free access to named wallets opens multiple attack vectors (see below).
So, to recap the discussion, and following the latest comments:

NEAR Wallet will not mix anymore implicit and named accounts, de-facto "forcing" new users to stay on the named account path
The onboarding flow will replace the "funding address" with a faucet, unless for fallback reasons (faucet not working or empty)
NEAR Wallet will use a faucet to fund the bootstrap storage fees and gas, providing just enough to register a named account

I am not sure if forcing the creation of named accounts will turn away privacy-savvy users, and will keep the application usage lower. I'm also worried that we are not following @ilblackdragon initial request, which was to include the implicit accounts as a viable, first-class alternative to named accounts inside NEAR Wallet. I think it's worth forking this discussion into two distinct parts:

How to remove the implicit-to-named "wallet dance" by using a faucet
How to adapt the existing wallet UX to use an implicit account instead of a named one

// Potential attacks I can think of:

create a named account, receive funds, authorize near-cli, delete account and sweep the received tokens
.near accounts name-squatting

// Mitigations (not to discuss here, just giving an idea of what we may need to do):

withhold the creation fee from the first outbound transaction, and send it back to the faucet (so it's essentially a loan, not a gift).
attach a randomly generated string to the name. E.g., I input stefano, the system would generate a random 1-2048 number, and attach the corresponding word -> the number 23 would generate stefano-actress.near (with the possibility to re-generate the random world, because, you know).

I feel sorry this is taking a bit longer than expected, happy to wrap everything into a bullet of decisions to take, and have a meeting within this Friday

@vgrichina the idea of a faucet seems the best one, but it's also tangent to the wallet today, as we need a constant inflow of tokens and some "budgeting".

We don't need constant inflow of tokens. We only need liquidity, as users either eventually fund accounts themselves or have it expire.

I am not sure if forcing the creation of named accounts will turn away privacy-savvy users, and will keep the application usage lower.

We aren't forcing anybody to create account with their name or anything else privacy revealing. Users have no problem staying anonymous on various Internet forums, Reddit, Twitter, etc.
I think it is also far better in setting actual privacy expectations. The idea that all privacy you have is a pseudonym to hide behind (like on Twitter and Reddit) is more visible here. "crypto" addresses might create expectation of privacy that is actually not there de facto.

I'm also worried that we are not following @ilblackdragon initial request, which was to include the implicit accounts as a viable, first-class alternative to named accounts inside NEAR Wallet. I think it's worth forking this discussion into two distinct parts:

I don't think we should do something just because this was initial suggestion by @ilblackdragon.
Like he himself confirmed that .near faucet would be the best:
https://github.com/near/near-wallet/issues/1453#issuecomment-779825159

How to adapt the existing wallet UX to use an implicit account instead of a named one

I think we shouldn't don't do it. There are other wallets on NEAR focusing on implicit account model. Like you can even use Trust Wallet for this.
I think it makes sense for NEAR Wallet to focus on stuff that other wallets generally wouldn't do.

create a named account, receive funds, authorize near-cli, delete account and sweep the received tokens

This is not going to be possible. User won't get full access key to account until they fund account.
It is achievable through either:

running a custodial web service that ensures this and adds full access key for user once account is funded
deploying tiny contract to account that allows to do one of these:

delete account and get funds back to faucet (access key for this held by faucet)
add full access key (access key for this held by user, only allowed if account is already funded)

.near accounts name-squatting

To protect against squatting for free we'd basically need to have following:

rate-limit (IP, attempts to claim same account name, captcha, etc)
all .near accounts are re-claimed back by faucet if not funded within e.g. 3 hours or some other grace period

Given that you only can squat for duration of grace period it isn't profitable.

withhold the creation fee from the first outbound transaction, and send it back to the faucet (so it's essentially a loan, not a gift).

yeah, there is no plan to give tokens for free in this scheme, you get loaned .near account to receive funds until you either pay for it or loan expires

All makes sense. I like the concept of using .near accounts in any case, so the user is aware that privacy comes from his behavior and not the illusion of having a difficult to remember hexadecimal string.
So to recap and unblock @corwinharrell :

narrow down the user experience to .near accounts only, replacing any temporary implicit account with this "lending faucet"
find the ideal/reasonable time-frame during which the user must fund the wallet and complete the onboarding
draft some basic behavior of the faucet in terms of messages, possible errors, and any sort of latency that could be experienced by the user, so Corwin can include them in the user flow

I prefer the idea of an on-chain contract, it makes it reusable by others in the ecosystem, it is transparent and is composable.

find the ideal/reasonable time-frame during which the user must fund the wallet and complete the onboarding

We don't have to find it right now, it is best determined experimentally
I would start with 24 hours and reduce as needed if/when system gets abused.

draft some basic behavior of the faucet in terms of messages, possible errors, and any sort of latency that could be experienced by the user, so Corwin can include them in the user flow

so obtaining account from faucet can have 3 results:

success (then it just follows through with funding flow using .near)
error because name already claimed (this one has to surface to user)
error because faucet exhausted (continue to existing implicit account funding flow as a fallback)

as for latencies I don't think there is any significant difference with existing flow

I prefer the idea of an on-chain contract, it makes it reusable by others in the ecosystem, it is transparent and is composable.

yeah, similar contract also would work for app-specific account funding

The account creation experience is much improved with a faucet in the background temporarily initiating the reserved .near account. Here is what the sequence looks like once we're able to omit the implicit address from the funding flow (With some improvements):

@vgrichina My main question is:
Once the Account ID is reserved and the user has reached the funding step, is there anything preventing us from allowing the user to resume their account setup by simply going through the recovery flow? (I think we can tweak some of the language depending on their entry point and the state of their account)

dropped priority to P1, as we are clearly not working on it as P0 de facto

@vgrichina My main question is:
Once the Account ID is reserved and the user has reached the funding step, is there anything preventing us from allowing the user to resume their account setup by simply going through the recovery flow? (I think we can tweak some of the language depending on their entry point and the state of their account)

I don't think anything is preventing us to do it. In fact we can do that even for our existing funding flow with implicit account. Maybe actually this is what we should start with before doing faucet.
I like the flow above, but I have small concern that we aren't letting user know beforehand that account will need to be funded. So we might end up in situation where way too often users claim .near account temporarily only to give up on funding stage.
I think it's worth looking for existing users on how often they drop off on funding stage. @TiffanyGYJ @icerove do we have this data for mainnet wallet?

I would expect for crypto wallets it's probably 50-90% of all accounts created never get funded (looking at bunch of random accounts I've created for ETH with 0 tokens in them). We can ask around.

I like the flow above, but I have small concern that we aren't letting user know beforehand that account will need to be funded. So we might end up in situation where way too often users claim .near account temporarily only to give up on funding stage.

@vgrichina This is good feedback. Happy to include some messaging earlier in the flow to set expectations around funding 👌

@vgrichina My main question is:
Once the Account ID is reserved and the user has reached the funding step, is there anything preventing us from allowing the user to resume their account setup by simply going through the recovery flow? (I think we can tweak some of the language depending on their entry point and the state of their account)

I don't think anything is preventing us to do it. In fact we can do that even for our existing funding flow with implicit account. Maybe actually this is what we should start with before doing faucet.
I like the flow above, but I have small concern that we aren't letting user know beforehand that account will need to be funded. So we might end up in situation where way too often users claim .near account temporarily only to give up on funding stage.
I think it's worth looking for existing users on how often they drop off on funding stage. @TiffanyGYJ @icerove do we have this data for mainnet wallet?

Yes, we have data for mainnet wallet and we can pull data around the step of funding

Closing this issue as we are now working on implementation here: https://github.com/near/near-wallet/issues/2284


Union type of an object literal type and empty object (using never as its field) not reporting type errors in some cases

Bug Report

typescript-eslint recommends the use of Record<string, never> to represent empty objects, because {} means anything but null or undefined. However, when this empty object type is used with other object literal types in a union type, TypeScript doesn't error where expected.
🔎 Search Terms

Empty object
never type
Object literal type
Union type

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about never, empty object and union.

⏯ Playground Link

Playground link with relevant code
💻 Code

type Foo = { a: { b: string } } | Record<string, never>

let value: Foo = {
    a: {
        b: 'blahblah'
    }
}

value.a.b // no error (as expected, because of type narrowing)

value = {}

value.a.b // Property 'b' does not exist on type 'never'.(2339) (as expected, because of type narrowing)

function fun1() {
    console.log(value.a.b) // no error (expecting error)
}

function bar(foo: Foo) {
    console.log(foo.a.b) // no error (expecting error)
}

🙁 Actual behavior

In the functions, accessing the union-typed variable doesn't report errors.
🙂 Expected behavior

In the functions, accessing the union-typed variable should be reporting errors.

Another duplicate of #9998.

Sorry I didn't see the template of https://github.com/microsoft/TypeScript/issues/new?assignees=&labels=Duplicate&template=types-not-correct-in-with-callback.md&title=. This seems to fall under the second category of "function calls do not reset narrowing"?
But I'm still confused. With the example below, where fun1 doesn't report an error but fun2 reports. I guess TS handles {} differently from other types ({ [key: string]: never })?
type FooWithNever = { a: { b: string } } | Record<string, never>
type FooWithEmptyObj = { a: { b: string } } | {}

function fun1(foo: FooWithNever) {
    foo.a.b // No error
}

function fun2(foo: FooWithEmptyObj) {
    foo.a.b // Property 'a' does not exist on type '{}'.(2339)
}

I guess TS handles {} differently from other types ({ [key: string]: never })?

The type { [key: string]: never } basically means: Whatever property you access, it will/should throw an error. It does not mean properties must not exist. You can't represent such types in TypeScript. I guess TypeScript falls into unsound behavior here, accessing a it creates a union of all a properties from the types (string | never), and never is an empty union type, so it gets reduced to string.
The type {} just means: not null or undefined, otherwise fair game.

Also worth noting is that, despite ESLint’s objections, {} isn’t unique in allowing primitives - that’s just a consequence of structural typing.  Primitives are also assignable to { toString(): string }, for example.

I completely skipped reading the part about ESLint. Bad defaults, confusing developers since forever.

That explains. Thanks guys. Will close the ticket now


fix PermissionsFor returning incorrect result when using @everyone overrides in channel

this kills the programmer

hello are you gonna merge this

Damn it, it's weekend. I have a life you know.


feat(frontend): enhance IC wallet worker to support balance only

Motivation
If an IC token is defined without an Index canister, we want to initiate a web worker that fetches only the balance using the Ledger canister.
Changes

Make newTransactions optional in the post-message (result) data.
Handle and add a TODO for the possibility of new transactions not being provided on the UI side.
Implement a new IcWalletBalanceScheduler that extends the same IcWalletScheduler as transactions but only checks for balance. Essentially similar, except it does not need a "clean up" post-process.
Adapt icrc-wallet.worker to initiate a scheduler with or without transactions—i.e., to use either the Index or Ledger canister.

Relates to https://github.com/dfinity/oisy-wallet/issues/2883


add impact description EN and FR

Added a short impact description in EN and FR. Mostly based on annexes 1 to 2 of PEF but I tried to synthetize, complete when necessary. Proof reading requested from Pascal

Tests :

Simulator page: https://wikicarbone-pr60.osc-fr1.scalingo.io/#/simulator
Examples page: https://wikicarbone-pr60.osc-fr1.scalingo.io/#/examples

Sources for the description :
en: https://ecochain.com/knowledge/impact-categories-lca/
fr: https://doc.agribalyse.fr/documentation/methodologie-acv
With added explanation on units, often found on "EF indicator description.pdf" on this page
with some adjustments when there is missing data.


Update and rename docker-compose.yaml to compose.yaml

The official Docker Compose documentation suggests using a compose.yaml file name for the purposes of clarity
Removed compose file version information that is not needed
Included a wait for ClickHouse and Prometheus to be resolved before running the coroot, rather than attempting to start them immediately

Please don't rename the file. This makes the documentation incorrect.

@def returned the file name as it was, but it is better to use the recommended name

The default path for a Compose file is compose.yaml (preferred) or compose.yml in working directory. Compose implementations SHOULD also support docker-compose.yaml and docker-compose.yml for backward compatibility. https://github.com/compose-spec/compose-spec/blob/master/spec.md#compose-file


Fixed #26785 -- Set BaseSpatialField.empty_strings_allowed to False.

https://code.djangoproject.com/ticket/26785

buildbot, test on oracle.

For the commit message, I usually try to describe the issue that's fixed rather than the implementation.

merged in ea4665066b651e0e2730f2e2d85fcef9d7ac7966, thanks!


remove cancellation check from retry policies

fixes: #1064
Bases on the related issue comments and conclusion, this PR is updating the places where cancellation is checked.
Note how BodyStream is now offering the cancellation checking by default for any Read() operation.
All derived classes can still access the context and check again if they want, but now we are making sure all derived class will always check as the first thing.

Not related to MQ :)

Not related to MQ :)

Feel free to update this whenever you see it. It would be faster if you see it and act on it. I don't really care too much about the milestone records.  I don't really know if we really should add a milestone to the PRs, I just do it because you asked me for it once and I don't mind XD

I would keep current behavior. It feels very bad to me to sleep just to throw.
Jeffrey Richter (watch Architecting Distributed Cloud Apps)

From: Victor Vazquez<EMAIL_ADDRESS>Sent: Monday, January 4, 2021 5:19:46 PM
To: Azure/azure-sdk-for-cpp<EMAIL_ADDRESS>Cc: Jeffrey Richter<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-sdk-for-cpp] remove cancellation check from retry policies (#1196)
@vhvb1989 commented on this pull request.

In sdk/storage/azure-storage-common/src/storage_retry_policy.cpphttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-sdk-for-cpp%2Fpull%2F1196%23discussion_r551662650&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882962753|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=sQxhLq%2FW9rPqfcRgeYZxEPlMMEe7WWZJG2a65Ok%2BNy0%3D&reserved=0:

@@ -124,7 +122,9 @@ namespace Azure { namespace Storage { namespace Details {

     if (retryDelayMs != 0)
     {

     std::this_thread::sleep_for(std::chrono::milliseconds(retryDelayMs));

     auto delay = std::chrono::milliseconds(retryDelayMs);

Sure.
Question: We can make this function to behave in 2 ways:
Imagine this case:

Create context C with 100ms time out.
Send request, then reach to a point where we are going to sleep for 500 ms.

First result: Since we know the context will throw, we just do it early and before reaching 100ms. (this is the actual implementation)
Second result: Sleep for exactly the time left for cancelling the request. ThrowIfWillCancelledAfter will call sleep for any time left to only reach the time out and then it throws. This way we wouldn't throw early and we won't also wait for more than the requested time (when the sleep time is greater than that, like this example)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-sdk-for-cpp%2Fpull%2F1196%23discussion_r551662650&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882962753|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=sQxhLq%2FW9rPqfcRgeYZxEPlMMEe7WWZJG2a65Ok%2BNy0%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAARLJP63L3SDOQGAJQDU6STSYJSLFANCNFSM4U6VWOUQ&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882972706|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=vDs%2FJoCsCjfbDBVtZWWz%2F4pBOYFpb%2BGC0aV1jukbQPE%3D&reserved=0.

I would keep current behavior. It feels very bad to me to sleep just to throw.
Jeffrey Richter (watch Architecting Distributed Cloud Apps)

From: Victor Vazquez<EMAIL_ADDRESS>Sent: Monday, January 4, 2021 5:19:46 PM
To: Azure/azure-sdk-for-cpp<EMAIL_ADDRESS>Cc: Jeffrey Richter<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-sdk-for-cpp] remove cancellation check from retry policies (#1196)
@vhvb1989 commented on this pull request.

In sdk/storage/azure-storage-common/src/storage_retry_policy.cpphttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-sdk-for-cpp%2Fpull%2F1196%23discussion_r551662650&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882962753|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=sQxhLq%2FW9rPqfcRgeYZxEPlMMEe7WWZJG2a65Ok%2BNy0%3D&reserved=0:

@@ -124,7 +122,9 @@ namespace Azure { namespace Storage { namespace Details {

     if (retryDelayMs != 0)
     {

     std::this_thread::sleep_for(std::chrono::milliseconds(retryDelayMs));

     auto delay = std::chrono::milliseconds(retryDelayMs);

Sure.
Question: We can make this function to behave in 2 ways:
Imagine this case:

Create context C with 100ms time out.
Send request, then reach to a point where we are going to sleep for 500 ms.

First result: Since we know the context will throw, we just do it early and before reaching 100ms. (this is the actual implementation)
Second result: Sleep for exactly the time left for cancelling the request. ThrowIfWillCancelledAfter will call sleep for any time left to only reach the time out and then it throws. This way we wouldn't throw early and we won't also wait for more than the requested time (when the sleep time is greater than that, like this example)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-sdk-for-cpp%2Fpull%2F1196%23discussion_r551662650&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882962753|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=sQxhLq%2FW9rPqfcRgeYZxEPlMMEe7WWZJG2a65Ok%2BNy0%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAARLJP63L3SDOQGAJQDU6STSYJSLFANCNFSM4U6VWOUQ&data=04|01||b3463b86e2964e67d4c208d8b117fd9a|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637454063882972706|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=vDs%2FJoCsCjfbDBVtZWWz%2F4pBOYFpb%2BGC0aV1jukbQPE%3D&reserved=0.