小编vin*_*ent的帖子

在 aws-sdk (js) 中使用transactWriteItems我们得到一个TransactionCanceledException。该异常中的原因作为TransactionConflict给出。有时事务中的所有操作都失败，有时只有几个或只有一个。我们确实并行运行多个可以对相同项目进行操作的事务。文档没有提到这个特定的错误。可能的原因摘录：

1. 不满足条件表达式之一中的条件。
2. TransactWriteItems 请求中的表位于不同的账户或区域中。
3. TransactWriteItems 操作中的多个操作针对同一项目。
4. 没有足够的容量来完成交易。
5. 项目大小过大（大于400 KB），或本地二级索引（LSI）过大，或因事务更改发生类似验证错误。
6. 存在用户错误，例如无效的数据格式。

这些都不适用，当重试事务时，它似乎最终有效。有人知道这个例外吗？我找不到任何文件记录。

我们使用 DynamoDB UpdateItem。

正如我们可以从文档中了解到的那样，这充当“更新插入”

编辑现有项目的属性，或者将新项目添加到表中（如果尚不存在）。[...]

当我们发出请求时，为了确定是否创建了某个项目或更新了现有项目，我们请求ALL_OLD。这非常有效，可以让我们区分update和create。

作为附加要求，我们还想返回ALL_NEW，但仍然知道所执行的操作类型。

问题：这可以在单个请求中完成吗？还是我们必须发出第二个（获取）请求？

我正在尝试在JScrollPane中编码可缩放图像.

当图像完全缩小时,它应该水平和垂直居中.当两个滚动条都出现时,相对于鼠标坐标应始终进行缩放,即在缩放事件之前和之后图像的相同点应位于鼠标下方.

我几乎实现了我的目标.不幸的是,"scrollPane.getViewport().setViewPosition()"方法有时无法正确更新视图位置.在大多数情况下,调用该方法两次(黑客!)克服了这个问题,但视图仍然闪烁.

我没有解释为什么会这样.但是我相信这不是数学问题.

以下是MWE.要查看我的问题,您可以执行以下操作:

• 放大直到你有一些滚动条(200%缩放左右)
• 单击滚动条滚动到右下角
• 将鼠标放在角落并放大两次.第二次你会看到滚动位置如何向中心跳跃.

如果有人能告诉我问题所在,我真的很感激.谢谢!

package com.vitco;

import javax.swing.*;
import java.awt.*;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseWheelEvent;
import java.awt.image.BufferedImage;
import java.util.Random;

/**
 * Zoom-able scroll panel test case
 */
public class ZoomScrollPanel {

    // the size of our image
    private final static int IMAGE_SIZE = 600;

    // create an image to display
    private BufferedImage getImage() {
        BufferedImage image = new BufferedImage(IMAGE_SIZE, IMAGE_SIZE, BufferedImage.TYPE_INT_RGB);
        Graphics g = image.getGraphics();
        // draw the small pixel first
        Random rand = …

目前正在致力于优化库的速度。我已经通过 Webstorm 使用V8 CPU 和内存分析大幅缩短了执行时间。这主要是通过将核心方法从递归改为迭代来实现的。

现在自我时间分布分解为

我假设第一个条目“节点”正在计时内部函数调用，这很棒。其他条目也有道理。我是 Nodejs 分析的新手，但 GC 的 31.6% 似乎很高，所以我决定进行调查。

我现在已经通过 Webstorm 创建了一个堆转储，但不幸的是，这并没有给我提供太多信息。

这些似乎主要是系统内部存储器引用。再次单步查看核心迭代代码逻辑，似乎也没有很多显式分配内存的地方（以此作为参考）。

问题

• GC开销可以减少吗？
• 这个分配量是预期的吗？
• 是否可以获得更好的内存分析信息？

设置说明

如果有人想尝试调试这个，我将提供设置说明。

下载或克隆对象扫描并运行

yarn install --frozen-lockfile
yarn run test-simple --verbose

test.js现在在项目根目录中创建一个包含此内容的文件，并运行node --trace_gc test.js或通过 Webstorm 运行它以进行高级分析。

我正在尝试确定针对我们拥有的几个不同用例使用哪个匹配器。最重要的是，我们想要复制 gitignore 解析器的行为。

我们正在考虑使用globby fast-glob或node-glob。但它们似乎都具有 .gitignore 默认解析不提供的扩展功能。

即，globy 使用 fast-glob，而 fast-glob 使用 micromatch，它公开了自定义功能。并且 node-glob 似乎也扩展了默认语法。因此我开始调查链条的下游。

我有点困惑为什么有这么多的软件包似乎都在做相同/非常相似的事情。

• 迷你比赛
• 多重匹配
• 任意比赛
• 皮科匹配
• 纳米匹配
• 微匹配

观察/问题：

1. 它们似乎都以一种或另一种方式进行文件路径通配符匹配（预计任何匹配可能更通用）
2. Minimatch 显然比 Micromatch 慢，但具有相同/相似的功能？
3. 多重匹配似乎是迷你匹配的简单包装，允许多种模式。不确定这是否以任何方式优化。
4. Anymatch 似乎很通用。好像不知道文件路径匹配？
5. Picomatch“完全支持标准和扩展的 Bash glob 功能”。我认为这与 gitignore 处理密切匹配？
6. Nanomatch 似乎扩展了 Picomatch 的功能。这比 gitignore 处理器提供的功能更多吗？
7. Micromatch 似乎扩展了 Nanomatch 的功能，并且似乎是 Minimatch 的替代品？它声称是“直接”替代品，但从它们公开的功能来看，情况似乎并非如此？
8. Anymatch、Picomatch、Nanomatch 和 Micromatch 均在 github 组织 Micromatch 下发布（有人命名混乱吗？）
9. “Micromatch 组织”套件似乎没有与 Multimatch 相当的东西？还是我只是没找到？

要回答的第一个问题是标准 git 实际使用什么来处理它的 gitignore。然后找出哪个包最匹配。