Dynamic require of "fs" is not supported

Bug description
Hello everyone,
I'm encountering the error "Dynamic require of 'fs' is not supported" when starting my project.
Here's the scenario:
I am setting up a repository that uses Prisma to manage two database connections. For this, I have two clients in my project: one located in the default Prisma folder (@prisma/client) and another within the repository itself, located at @shared/infra/database/prisma-second.

Currently, the project is built with esbuild using the "esm" format, which I cannot change. When switching to cjs, the project runs fine. However, when set to "ES modules [esm]", it fails because the files generated by the Prisma client for the second schema dynamically import modules using require.
It is worth noting that the client generated in the default path does not require such dynamic imports, as it does not generate an index.js with a require("fs") statement. Thus, it doesn’t cause any issues. The problem only arises with the client generated for the second database.
The question is: how can I generate the client in an ESM format without dynamic imports?
My generator client

The default prisma client generated (without the require("fs"):

The Client generated to the second schema with that command: npx prisma generate --schema=./src/shared/infra/database/prisma-second/schema.prisma

How to reproduce

Expected behavior
I expected the Prisma client to be generated in the same way as the default one, without any changes, without dynamic requires or anything that could break the ESM format.
Prisma information

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator docs {
  provider              = "node node_modules/prisma-docs-generator"
  includeRelationFields = false
}

generator dbml {
  provider            = "prisma-dbml-generator"
  output              = "erd"
  outputName          = "erd.dbml"
  projectName         = "Template"
  projectDatabaseType = "PostgreSQL"
  projectNote         = "Consequat aliqua laborum aliquip amet dolore aliquip. Culpa mollit nulla quis quis. Culpa pariatur culpa mollit commodo minim officia anim ea nostrud. Labore in eiusmod minim minim magna laboris laborum tempor nulla culpa culpa. Nisi non eu laborum culpa consequat nisi incididunt aute aute. Exercitation ea duis mollit cillum."
}

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl-openssl-3.0.x", "rhel-openssl-1.0.x"]
  output        = "./client"
}

datasource db {
  provider = "postgresql"
  url      = env("DB_DIRECT_1")
}

/// Account
model Account {
  id   String @id @default(uuid())
  name String
}

import { logger } from '@/shared/application/logger';
import { PrismaClientOptions } from '@prisma/client/runtime/library';

import { PrismaClient } from './prisma-second/client';

const shouldDebug = process.env.PRISMA_DEBUG == 'true';

const options = {
    datasources: {
        db: {
            url: process.env.DB_URL_2,
        },
    },
    log: [
        {
            emit: 'event',
            level: 'query',
        },
    ],
} satisfies PrismaClientOptions;

if (!shouldDebug) Reflect.deleteProperty(options, 'log');

export const prismaSecond = new PrismaClient(options);

if (shouldDebug)
    prismaSecond.$on('query', async (e) => {
        logger.info(`${e.query} ${e.params}`);
    });

Environment & setup

OS: Ubuntu
Database: PostgreSQL
Node.js version: 20.10.0

Prisma Version
5.17.0

Hey guys! Today, while studying this error, I managed to fix it!
Basically, we need to add the folder with the generated files (client) to the "external" parameter in esbuild:
esbuild
    .build({
        entryPoints: splitStdout,
        allowOverwrite: true,
        minify: true,
        sourcemap: true,
        outdir: 'dist',
        platform: 'node',
        logLevel: 'silent',
        external: [
            ...Object.keys(dependencies),
            ...Object.keys(devDependencies),
            '@internal/client',
        ],
        target: ['node20.10.0'],
        bundle: true,
        resolveExtensions: ['.ts', '.js', '.json'],
        format: 'esm',
    })

In my case, I changed the Prisma generator client output to the node modules, then added the path to the external parameters. After doing this, the error stopped.

@Pablo-Conte Are you still using 2 separate clients? What does @internal alias to?

man, sorry for the delay.
I've used that alias to work with different connection on different databases.
because of that I needed to work with two different clients, each one with its models.


Prevent tabbing away from composer if text is present

This gives a bit nicer experience when jamming on the tab key for autocomplete while still allowing users to tab to another element when the composer is empty.

\o/

Nice!!
On Tue, Apr 28, 2015 at 1:28 AM Mathias Buus<EMAIL_ADDRESS>wrote:

\o/
—
Reply to this email directly or view it on GitHub
https://github.com/moose-team/friends/pull/34#issuecomment-96972235.


Use Self hosted Renovate instead of Whitesource Renovate

What
Use Self hosted Renovate instead of Whitesource Renovate
Problem to solve
Currently, Self hosted Renovate often stops working due to API rate limiting.

https://app.renovatebot.com/dashboard#github/aquaproj/aqua-registry/1074940570
DEBUG: No repository returned
{
  "res": {
    "errors": [
      {
        "type": "RATE_LIMITED",
        "message": "API rate limit exceeded for installation ID ***."
      }
    ]
  }
}

Once GitHub App reaches API rate limiting, GitHub App stops working until we suspend and unsuspend the App.
https://github.com/apps/renovate

What I tried
To avoid API rate limiting, I tried several things.

Restrict prConcurrentLimit

https://github.com/aquaproj/aqua-registry/blob/bb7be1affda722caa50f2fd0d77538f0ece61b91/renovate.json5#L10-L12

Restrict schedule

https://github.com/aquaproj/aqua-registry/blob/bb7be1affda722caa50f2fd0d77538f0ece61b91/renovate.json5#L15-L32

Change rebaseWhen to conflicted

https://github.com/aquaproj/aqua-registry/blob/bb7be1affda722caa50f2fd0d77538f0ece61b91/renovate.json5#L14
But the issue couldn't be solved.
What I'll try
I'd like to try GitHub Actions.
https://github.com/renovatebot/github-action
https://docs.renovatebot.com/self-hosted-configuration
The experience of GitHub Actions is worse than Whitesource Renovate, but we have no choice.

So I use the cli to invoke for Azure DevOps repos. The github app might still be possible for you with the caveat of modifying some behavior. I'd suggest that before flipping to using actions.
This may be a problem again in the future if the package size grows even with the self-hosted, so consider app behavior modification.

On the GitHub hosted app Mend checks each active repository roughly every three hours, if no activity has been seen before then (merged PRs, etc). source

Additionally the docs talk about only one merge occurs at a time due to needing to make sure conflicts don't occur.
These are just ideas because moving away from the app might result in a less optimal experience.

Scheduling. I think it's perfectly legitimate to not have near realtime PR's being created for tooling. Consider throttling to a schedule like hourly, and make sure you setup   prHourlyLimit: 0 to something reasonable to help protect against over loading your tokens.
PR Creation, consider not-pending as it won't create the pr till the status checks pass. I prefer immediate, but maybe that would help. This might cut down dramatically on your api calls just by doing every 2-3 hours as a schedule instead of what might be every merge resulting in new PR's being created.

After that, if it still persists, I'd also suggest opening a discussion on renovate's github since there's some interesting posts about caching and other general improvements. Maybe you are hitting a unique scale issue that will help them if they are making excessive calls that a schedule change doesn't fix.
quick observations on the status checks
This is just me reading through the check and giving some feedback, so unlikely to help with the main issue. I can move this off into a separate issue if you like some of the ideas.
Probably works great as is, but maybe there's something useful in here.

The status checks run on every push that impacts the registry, right? If I'm reading the test.yaml correctly that means every single cli tool == full test runs. Maybe consider adding your tibdex/github-app-token that exports a cross job secret env variable that other tasks like earthly use IF those api calls go against the GITHUB_TOKEN that might use.
First if you have your github status checks setup, you could cut out the need for gh merge via command line (only one call perhaps but still)... Enabling renovate's automerge and if the status checks pass and renovatebot-autoapproves then it will automerge with no extra code.
In fact, as I'm typing I see this and while the github app token generator is pretty cool, I don't think you need this if you just the platform native automerge. This cuts out more calls by tooling. example from something i setup.
The key is to just do branch protection with status checks passed and one approval required, which can be renovatebotapprove. I do like your approach, just giving you another idea.

PR Creation

test is triggered by pull_request event, so I think the prcreation must be immediate (default) because until pull request is created status check hasn't completed.
To set prcreation: not-pending, we should change the trigger to push event, but I don't want to do it.

quick observations on the status checks

We face the API rate limiting of Renovate GitHub App, but this app is different from GitHub App we use in GitHub Actions.
So GitHub API call in GitHub Actions has nothing to do with this issue.

In fact, as I'm typing I see this and while the github app token generator is pretty cool, I don't think you need this if you just the platform native automerge.

We set up our GitHub Actions based on the guide.
We know Renovate's platformAutomerge but we don't use it intentionally (ref).
Furthermore, platformAutomerge consumes Renovate GitHub App's API rate limiting so the situation gets worse.

Disable dependency dashboard. I love that feature, but with your scale I see it's truncated. I bet updating that issue also costs more api calls and not sure it's useful for you as it is.

Good suggestion. I'll try to disable the dashboard. Thanks.

🤔 I disabled the Dashboard and closed the issue, but Renovate reopened.
https://github.com/aquaproj/aqua-registry/issues/1#event-9293288459

If my understanding is correct, even if we limit branchConcurrentLimit and prConcurrentLimit Renovate seems to check all dependencies, which consumes many API rate limiting unnecessarily.

Limit prHourlyLimit to 50.

https://github.com/aquaproj/aqua-registry/pull/12313

We are working on updating packages by aqua-registry-updater instead of Renovate.

aqua-registry-updater starts working!
https://github.com/aquaproj/aqua-registry/actions/workflows/update.yaml

Memo

https://github.com/aquaproj/aqua-registry/pull/12456

https://github.com/aquaproj/aqua-registry/pull/12533

Resolved.

This deserves a blog post. Great example of creative solving of issues with Go and a fresh look. Would love to hear more when you get time.


Proposal details UI upgrade

Closes #768 , #717, #749

@fabiolalombardim The issue says there should be a Download CSV button on LITE daos but can't see it there - #717
Other then this all looks good
@Man-Jain
There is a different PR specifically for LITE: https://github.com/dOrgTech/homebase-app/pull/813


[RFC] create directory for flowtype tests

This would allow us to build out much higher quality flowtyped interfaces for our components.

Warnings

:warning:

Please add a changelog.md entry for your changes.

  Generated by :no_entry_sign: dangerJS

I think these tests are great, but would love to see them co located with the actual components themselves. The test directory is more of a hangover from ghost more than anything else. Any plans on how to run an execute them?


crypto: document that the GCM AEADs are safe for concurrent use if the underlying cipher.Block is

This is a follow-on to #25882.
That issue is about documenting which cipher.Block implementations are safe for concurrent use.
Similarly, the cipher.AEAD created by NewGCM and friends ought to be documented as safe for concurrent use if the underlying cipher.Block is. In particular, AES-GCM should be safe.
/cc @FiloSottile

Sounds good, send a CL with a test if you'd like! Thank you!

chacha20poly1305 should also either be documented as concurrent safe or not.


why frame interpolate will  make the ori video blur

sorry, i refer to the target video instead of ori video


No rendering after drop

Description
There were various memory leaks which caused the scene to stay around which tries to render after the GUI has been dropped.
There were 1500+ leaked objects. The first few commits by @Procrat tackle the actual leaks. The last commit of him tries to reduce the cloning of Application across the codebase, so debugging leaking references will be easier. @farmaazon then added fixes for last leaks and cleaned up the code.
Additionally, the message about visualization failing to attach is displayed in pop-up instead of status bar, so it will disappear after some time. Fixes #6976
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

These changes look OK, but I'm missing info how this PR really works. Even if we are cloning world and scene in different places, all of these objects should get dropped if we drop the main app instance. Even if FRP closures keep reference to them, these networks should be dropped, so how this PR really fixes the mem leaks problems and more importantly, what is the guideline for future code to not create leaks? Also, are we able to create automated test for it?

There were two causes I'm aware of

ApplicationData FPR network was taking ApplicationData itself, making a reference cycle.
Our garbage collector: it often took FRP and model of various components, possibly containing reference to Application, or World. Of course, it should be removed a couple of frames later, but it's hard to say what exactly was dropped and what not (maybe handlers for GC were?).

Removing clones was rather for reducing noise when debugging (the reports said about 1500+ references to App), and I think removing reference which is not needed is a good idea anyway.
How to mitigate it? Here we have another example of FRP network taking itself. Almost all leaks I encounter in our codebase are like that. I think the FRP could be changed a bit, to make clear that FRP should own the model (maybe special "model" behavior node, which gives mutable references to Model?

QA :yellow_circle:
This looks mostly good, there are no errors after dropping the app. But when I press tab with focus in the empty window, I see the following error:
8pkg.js:3934 Uncaught Error: closure invoked after being dropped
    at imports.wbg.__wbindgen_throw (eval at <anonymous> (index.ts:296:37), <anonymous>:18716:11)
    at wasm_bindgen::throw_str::hd5a1e55c1ad9682d (pkg-opt.wasm:0x2179bdc)
    at <dyn core::ops::function::Fn<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hde034fa7641b5b81 (pkg-opt.wasm:0x216c679)
    at __wbg_adapter_80 (eval at <anonymous> (index.ts:296:37), <anonymous>:16975:8)
    at real (eval at <anonymous> (index.ts:296:37), <anonymous>:16936:14)

Could this indicate there is still some Enso event handling active? @farmaazon

Could this indicate there is still some Enso event handling active? @farmaazon

Both yes and no: it means that the closure was dropped in rust successfully, but JS still had reference to it. See https://rustwasm.github.io/wasm-bindgen/api/wasm_bindgen/closure/struct.Closure.html
Tracking the offending closure may be tricky, but I'll try to find it.

Added more serious tracking of Scene and SceneData, and it turns out there still are many leaks:

init_webgl_2_context is called with Scene as an argument, which is captured to lambdas, whose handlers are in turn kept inside Scene.
CachedShapesPass keeps scene while being also kept inside Renderer.
font::Registry::init_and_load_embedded_fonts clones scene and put it into structure returned as an extension - and the extensions are also kept inside scene
Finally, the scene is stored in SCENE global variable but never removed from there.

I still don't know why only keydown handlers raises an error, but those Scene leaks are serious.

Because the problems are not actually regressions (there were before this PR) and this PR improves things, I will merge it, but won't close the task #6505.


Protocols not properly loaded?

I’m not sure if I’m doing something wrong, but if I try to render an address in a .leex template (eg. <%= @record.address %>), I get this error:
protocol Phoenix.HTML.Safe not implemented for %Postgrex.INET{address: {206, 22, 87, 1}, netmask: 32} of type Postgrex.INET (a struct). This protocol is implemented for the following type(s): Decimal, Phoenix.LiveView.Comprehension, Phoenix.LiveView.Rendered, Time, Integer, Tuple, List, DateTime, NaiveDateTime, Float, Atom, Phoenix.HTML.Form, BitString, Date

Changing it to <%=<EMAIL_ADDRESS>%> yields a slightly different error:
protocol String.Chars not implemented for %Postgrex.INET{address: {216, 24, 57, 1}, netmask: 32} of type Postgrex.INET (a struct). This protocol is implemented for the following type(s): Postgrex.Copy, Postgrex.Query, Decimal, Float, DateTime, Time, List, Version.Requirement, Atom, Integer, Version, Date, BitString, NaiveDateTime, URI

If I change the code to <%=<EMAIL_ADDRESS>%>, it does render correctly, so I have a usable workaround.
I see the protocols defined here: https://github.com/adam12/ecto_network/blob/master/lib/ecto_network/inet.ex#L102 - so I’m a bit confused. I tried adding require EctoNetwork.INET to my view, but that makes no difference as far as I can tell?
Is there some step I missed to get the protocol implementations to load correctly? I have a umbrella app, if that makes any difference, and the relevant package versions are:
  db_connection 2.1.1
  ecto 3.2.1
  ecto_network 1.1.0
  ecto_sql 3.2.0
  phoenix 1.4.10
  phoenix_ecto 4.0.0
  phoenix_html 2.13.3
  postgrex 0.15.1

I’m using Elixir 1.9.2, Erlang/OTP 22.1.3 on macOS 10.15.

I'll have to look into this and get back to you. Are you able to make a cloneable example that demonstrates the issue to save me some time?
I thought we were testing the protocol implementations for String.Chars and Phoenix.HTML.Safe but it looks like were not.

Very strange, I cannot reproduce this in a simplified example. I have the exact same versions of everything important, yet one project loads the protocols just fine, and the other one just doesn't, very confusing 😞

I'll try to reproduce as well but everything looks right as far as I can tell.
Let me know if anything changes on your end.

I'm going to close this for now. If you're able to reproduce it for me to debug, please re-open.


Product page

Fixes Issue #613

Changes proposed
Added products page

Screenshots
https://github.com/codervivek5/VigyBag/assets/58663564/ccc735e8-5a4b-41c9-88c7-886d30437c38
Note to reviewers

@07jasjeet please review

kindly solve the conflict

hello @07jasjeet
kindly review this PR asap so that they can get their if this PR will merge.

@07jasjeet wdym by number 3? and thank you for the corrections.


limit order with market on close persistence type get filled even when exposure is less than £10.

Does it error on the request or lapse when the market turns inplay?
From memory this only required for lay bets or is it both?

In live, it showd order lapsed. It is a limit order with market on close persistence. I need to look for details in betfair about the rule on this.

Can I request to ‘Take SP’ on an unmatched lay bet if my liability is less than £10? (Minimum liability)
Yes, but at the off if the liability on the bet is less than £10 the bet will be cancelled and will not be included in the SP reconciliation.
For example:  As an Exchange layer I decide to lay a horse for £5 @ 2.0. It is trading at 3.0 so my bet is unmatched. I then request to ‘Take SP’ at the off if my bet is still unmatched at 2.0. The system will allow this request but if unmatched at the off it will lapse.  Also, if a customer for example asks to lay £50 at 1.5, convert to SP if unmatched, and £40 gets taken leaving £10 lay at 1.5 the balance will cancel at the off. It will not convert into an SP lay bet as the revised balance at the off was less than the minimum £10 liability allowed for SP bets.

Great, and back bets work fine?

No. Backtest still shows the ordered matched.

I mean live, I was under the impression back limit orders will still enter the auction even if its below the min bet size

I don’t know about back bet but from the betfair q and a it seems the £10 exposure rule covers both back and lay orders.

Is it possible to check with betfair about back bet rule?

Works fine with back bets

Ok Thanks.good to know.


Add ability to copy ssh/http urls for repository

It would be nice to have a way to copy clone urls for a repository, so you don't have to open the the repo in the browser before you can get the clone url.

I have added this feature to release v1.1.0. The following key combinations can be used on a repository to copy the clone URLs:
• ⌘ ⇧ + ⏎ will copy SSH clone URL.
• ⌥ ⇧ + ⏎ will copy HTTP clone URL.


Question: Method for support features that is not available in all supported hardware

I am looking at #33 as the key method to support newer features that is present in some hardware but not in all supported hardware. Is this understanding correct ?
Would it be possible to query the BLEDevice to know the current hardware and its supported feature set ?

Hi @daviddedwin,
#33 is a bit unrelated, the root topic there is about no public API's to read the battery level and temperature.
Do you have specific new features in mind?

Would it be possible to query the BLEDevice to know the current hardware and its supported feature set ?

It would be possible, however right now supported features on nRF8001 and nRF51822 are consistent.

I'm closing this due to lack of activity.

Will re-post issue when I have have proposal.


Ability to rename K-9 unread widget

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.710
Problem you are trying to solve
When creating several K-9 unread widget the name always begins (or is) the account name. This is confusing after creating several widgets for differents folders, they all look identical.
Suggested solution
It would be useful to have the default name match the folder name and be able to rename it.
Screenshots / Drawings / Technical details
No response

This would be a nice feature to have. However, it's unlikely that we'll find the time to work on this ourselves anytime soon.
If someone is interested in implementing this functionality, please let us know. We'll then work together on a design for the widget configuration screen, so that the name of the widget can be changed by the user. Please don't start working on an implementation before we've agreed on a design.


[Feature]: Return to importer after adding device

NetBox version
v3.4.5
Feature type
Add a function
Proposed functionality
When importing a device or module type. It immediatly goes to the device-type/moduletype overview.
But when you want to add more devices this might be unhandy as you need to switch back and forth.
Use case
Nice to  have  more a user experience.
External dependencies
None

I'm not sure how good this would be, as I personally like to be redirected so that I can access the types which have been imported


Tindetheus only works with Tensorflow 1.15 mac OSX

Wanted to make a quick callout. I was only able to get tindetheus working on a mac using tensorflow1.15 which has GPU support.
pip install --pre "tensorflow==1.15.*"

Facenet currently doesn't support tensorflow 2.0 on all systems. I'll eventually bring it up to 2.0, but I first wanted to clean a few things up. I started this in my facenet fork, but it will take some time.
In the meantime I changed the tensorflow requirement to < 2.0.0.


Arlec Grid Connect Smart Desktop Bar Lights - Twin Pack - Dump

Arlec Grid Connect Smart Desktop Bar Lights - Twin Pack
deskrgb.zip

Profile added as Arlec ALP223HA Desktop Bar Light Twin Pack, however, I don't expect the features of this device to be very well supported, if at all on 3rd party firmware.


Browser centers when   is on the page

Hello,
I have the ngTagsInput directive on my page, along with some text fields. When i update one of these text fields the browser centers itself, which should not happen. If i remove the  from the HTML, this strange behaviour not happen.
Is this a known issue?
The HTML:
<tags-input  ng-model="exp.tags" ng-if="vm.editable"
replace-spaces-with-dashes='false'
add-on-comma="false"
class="ko-tag"
on-tag-clicked="vm.tagClicked($tag, exp)"
min-length="1"
                                vt-tag-input-changed
                                onafterblur="vm.updateResume()"
                    >
                        <!--on-tag-added="vm.updateResume()"-->

                        <auto-complete source="vm.loadTags($query)" min-length="2"
                                       select-first-match="false"></auto-complete>

Thanks!

This issue was selected to be spring-cleaned by a script. More information can be found here.
If anyone thinks this was a mistake and this issue should be reopened, please leave a message below explaining why. Before doing so, please consider reading the CONTRIBUTING file.


How do you implement the predict module and where do you use it in spark?

Hello,
I'm very interested in this project, and have read you paper. And I'm very interested in your MinFrag algorithm based on DRR and the predict module. But I got some trouble when I try to implement the schedule algorithm, I can't understand the input and the output about the predict algorithm SVR and I did not find you use the predict result in spark code.
thanks,
liuzhangmin

Thanks for your interests. The input is the configurations for the submitted Spark applications, which includes input data size, resource requirements (CPU and Mem) for each executor, the number of executors, application type, and so on, which are stated in our paper exactly. And the output is the peak resource requirements (e.g., CPU) of each stage for executors and is configuration files to be used for placement calculation and resource allocation of the resource allocation module. You can check resource allocation submodules' logic to see that. If you focus on the scheduling algorithm and want to use the resource profiles as inputs, you can contact me later.

Thanks for your answer, Libin.
Can I get a example file of "resprofile"? Because the file for RUD I generated is the pure csv file like "resprofile.csv", and the file can't used to predict. Sorry for bothering you，if it is possible，could you show me the scheduling algorithm and how to use the resource profiles?
Thanks.

If you mean the file used to report resource utilization from worker to RUD, the resource utilization for CPU is like 200, 200, 200, 200, 200, 100, 100, 100, 100, 100, 100, 150, 150, 150, which includes these stages. This is an example and not the real application's resource utilization. If it is for the scheduler, it is stage1: 200, stage2: 100, and stage3: 150. I don't exactly understand your questions. Do you mean the implementation and real profiles used to do the scheduling? Could you send me your errors of your implementation or the problems reported when you run the codes? Please do not paste them here and send them by email. You can find my email from my github page. Thanks.


⚠ Cioos National CKAN has degraded performance

In 43c7762, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 6260 ms

Resolved: Cioos National CKAN performance has improved in ab2d328 after 5 minutes.


Default Tensor type fix

There is a bug if you set the default tensor type to CudaTensor. For example:
 local display   = require 'display'
torch.setdefaulttensortype('torch.CudaTensor')

-- then call
display.image(torch.randn(16, 3, 32, 32)

The display.image would call image.compressJPG(img) which in turns calls image.clampImage(..). There, these two lines cause problem:
init.lua165: from image package
local a = torch.Tensor():resize(tensor:size()):copy(tensor)
a.image.saturate(a) -- bound btwn 0 and 1

Here a is a default type tensor and if that is set to CudaTensor it won't have the field image.
This PR is fixing the bug by setting the default tensor type to DoubleTensor and then restoring to the original state.

I have also changed the image button to bolder arrow and add the image button only to ImagePanes.


How to install parity without upgrading postgresql package?

I have postgresql 13.3 installed via Homebrew. It works great and I have some other packages (postgis) that have postgresql as its dependency. I also have several databases that I don't want to mess up.
I want to install parity and have it use current postgresql 13.3. I don't want to upgrade postgresql just so I can install parity.
Please note that I had parity installed earlier today and it was working with current postgresql 13.3 just fine.
How can I install parity, without upgrading postgresql package? Thanks!
What command did you execute?
brew install parity
What did you expect to happen?
It install parity and uses existing (homebrew installed) postgreql package.
What actually happened?
I got the following error:

Error: You must brew unpin postgresql as installing thoughtbot/formulae/parity requires the latest version of pinned dependencies

Some information about your installation

What's your operating system? macOS Big Sur 11.6
What's the output of which development, which staging, which production? development not found, staging not found, production not found
Parity has had multiple installation channels, and it's not uncommon for an
old version to be somewhere else in your path.
If installed via Homebrew, what does brew list parity output? N/A
If installed via Rubygems, what's the gem version? N/A

Got it, this works:
brew install thoughtbot/formulae/parity --ignore-dependencies

It might be time to stop making PG a dependency, there's a lot of value in parity IMO even if you don't use the DB features.


boilerplate readme update - additions : gitlab - obsidean - ubuntu-desktop

Checklist:

[x ] My pull request has a descriptive title. (unlike Update index.md). Check this guide regarding titles.
[ x] If applicable, I have tested these changes.

Closes #XXXXX

will review as requested in smaller pull req's.


Fix compile with address sanitizer

Scope & Purpose
sizeof is different in such case

[x] :hankey: Bugfix
[ ] :pizza: New feature
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification

Checklist

[ ] Tests

[ ] Regression tests
[ ] C++ Unit tests
[ ] integration tests
[ ] resilience tests

[ ] :book: CHANGELOG entry made
[ ] :books: documentation written (release notes, API changes, ...)
[ ] Backports

[ ] Backport for 3.11: (Please link PR)
[ ] Backport for 3.10: (Please link PR)

Related Information
(Please reference tickets / specification / other PRs etc)

[ ] Docs PR:
[ ] Enterprise PR:
[ ] GitHub issue / Jira ticket:
[ ] Design document:

[ ] https://jenkins01.arangodb.biz/job/arangodb-ANY-linux-san.x86-64/2104/


Dropzone component + fixes

closes: #333

ready for review cc @nicolaskruchten

Dancer!
On Sat, Mar 17, 2018 at 11:18 VeraZab<EMAIL_ADDRESS>wrote:

[image: screen shot 2018-03-17 at 11 09 35 am]
https://user-images.githubusercontent.com/4257572/37557036-e41b8b32-29d4-11e8-82af-0f06397314f6.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/plotly/react-chart-editor/pull/418#issuecomment-373927856,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbA0iW_ejXoQbSakkGRot4II1hHUeZks5tfSk8gaJpZM4SuJu0
.


fix/typos in 10_craigslist_ad.html

PR fix for #12.
Description

This PR addresses two typos identified in the provided HTML code:

The comment character --> within the <h1> tag has been removed, fixing the first issue.
The typo in the list item within the <ul> element has been corrected. The word "offerse" has been changed to "offers."

Changes Made

Removed --> from the <h1> tag.
Corrected the typo in the list item within the <ul> element.
Removed an extra space at the end of the sentence within h1 for cleaner code.

Testing

I have tested the HTML code after making these changes, and the issues have been resolved. The <h1> heading now contains only the text "Didgeridoo. Needs work," and the typo in the list item has been fixed.

Related Issues:

This PR closes #12.

WELL. FREAKING. PLAYED. 👏 +4


Installing dependency from URL and specify version

Headroom.js have unregistered the package from Bower and suggests the users to install the package this way instead:
bower install<EMAIL_ADDRESS>--save

This installs the specified version. In bower.json this line is added:
"headroom.js"<EMAIL_ADDRESS>
If a co-worker runs bower install the installer gives an error. (ENORESTARGET URL sources can't resolve targets). Bower don't like the version added to the end of the URL.
I have to manually delete the added version at the end for it to work as expected:
"headroom.js"<EMAIL_ADDRESS>
The author of headroom.js tried this with an earlier version of Bower (v1.7.7) and in that version, Bower did not add the version to the end of the url. He continues and says that this is a problem with bower itself, since it used to work in earlier versions and the URL<EMAIL_ADDRESS>behaves as expected if you visit in a browser.
Bug or feature?

I was able to reproduce this issue as well (bower --version 1.7.9).
Steps:

bower init
bower install<EMAIL_ADDRESS>--save
Confirmed that<EMAIL_ADDRESS>is recorded in the bower.json
Ran bower install
Observed bower ENORESTARGET  URL sources can't resolve targets

Possible solution:
Looks like the UrlResolver throws an error if the target specified is not "*". By removing this constraint I was able to still successfully run bower install
i.e. remove
    // If target was specified, error out
    if (this._target !== '*') {
        throw createError('URL sources can\'t resolve targets', 'ENORESTARGET');
    }

Does anyone know why we were throwing this error?

I think this was never intended as the error itself reads. If you resolve via URL you were not supposed to specify a version. For example installing a zip archive from dropbox or similar not versioned storage is what the URL resolver is for. However I'm pretty sure this still worked for GitHub URLs, as a different resolver would kick in. I'm also curious why the people behind Headroom.js are making this change in the first place. Having the project on GH and then installing via URL seems a strange 😀

Indeed, you can't specify versions when you download dependencies via simple url.

Hey. I'm the author of headroom.js
I believe this is a bug with bower. The URL itself is valid, npmcdn has no problem responding to the URL, but bower chokes on it.
It is bower that adds the hash fragment to the end of the URL, which seems to be causing the problems.
The URL specifies the version number, but that shouldn't have any effect on bower. It's just a URL after all, nothing special about it.
My reasoning for going with this approach is because I do not want build artefacts committed to my repos. Build artefacts cause endless confusion in PRs, because people accidentally submit them as PRs. Then I have to go through a cycle of back and forth explaining why they shouldn't be committed and how to remove them. Creating extra work for me, and additional friction for contributors.

Hey, I agree with you @WickyNilliams, it's too bad for bower.
I have a workaround  for you which is better than nothing. Instead of specifying a tag, you can give the zipball link.
For example:
    "dependencies": {
        "headroom": "https://github.com/WickyNilliams/headroom.js/archive/v0.9.3.zip"
    }

It won't evolve but you'll be able to set the wanted version.
:(


Potential memory leak in BloomFilterWrapper

The BloomFilterWrapper doesn't clean up the BloomFilter it allocates on init. As best I can tell, this is mostly a theoretical leak—in the app, the BloomFilterWrapper is currently retained for the lifetime of the program. If this ever were not the case though (as is the case in the test suite), the allocated BloomFilter would be leaked.
If you'd like, I can submit a pull request for the (tiny) fix.

Sorry for the delay in replying.  Yes, feel free to submit a PR.  As you say the filter is tied to the the lifetime of the app anyway so no rush.  Thanks!

Tracking internally here: https://app.asana.com/0/392891325557410/1199935106721785

Closing this as #833 was merged, thanks @s3cur3!


error: Broken pipe (os error 32)

When I ran cargo tarpaulin -v I got a broken pipe error:
› cargo tarpaulin -v
Jan 05 16:41:24.411 DEBUG cargo_tarpaulin: set up logging
Jan 05 16:41:24.411  INFO cargo_tarpaulin::config: Creating config
Jan 05 16:41:24.442  INFO cargo_tarpaulin: Running Tarpaulin
Jan 05 16:41:24.442  INFO cargo_tarpaulin: Building project
   Compiling sorting-benchmarks v0.1.0 ( <path> )
error: Broken pipe (os error 32)
warning: build failed, waiting for other jobs to finish...
thread 'main' panicked at 'already borrowed: BorrowMutError', src/tools/cargo/src/cargo/util/config/mod.rs:307:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Jan 05 16:41:24.862 ERROR cargo_tarpaulin: Failed to compile tests! Error: an inner attribute is not permitted in this context
Error: "Failed to compile tests! Error: an inner attribute is not permitted in this context"

After running cargo clean I realized there was a build error in my code. Resolving this error allowed tarpaulin to run properly.
The issue here is 2-fold: 1) there's an unhandled non-descriptive OS error and 2) the rustc build errors aren't displayed to the user.

Update: The problem may be within cargo. Here's the stack trace:
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5
   1: core::panicking::panic_fmt
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/panicking.rs:92:14
   2: core::option::expect_none_failed
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:1268:5
   3: cargo::core::compiler::job_queue::DrainState::drain_the_queue
   4: std::panic::catch_unwind
   5: crossbeam_utils::thread::scope
   6: cargo::core::compiler::job_queue::JobQueue::execute
   7: cargo::core::compiler::context::Context::compile
   8: cargo::ops::cargo_compile::compile_ws
   9: cargo::ops::cargo_compile::compile
  10: cargo::ops::cargo_test::compile_tests
  11: cargo::ops::cargo_test::run_tests
  12: cargo::commands::test::exec
  13: cargo::cli::main
  14: cargo::main

That being said, other cargo commands (build, run, test) provided the actual build error where cargo tarpaulin did not.

Yeah I've started seeing this sometimes with issues that can be solved by a clean or more fundamental project issues. I need to did more into it and find a minimal reproduction but I've been very busy with my day job recently :weary:

Yeah I've started seeing this sometimes with issues that can be solved by a clean or more fundamental project issues. I need to did more into it and find a minimal reproduction but I've been very busy with my day job recently :weary:

We ran into what is probably the same error. For us it appears to fail when trying to compile tests. The error messages are the same as above. Here's a trace:
$ cargo --verbose tarpaulin
Feb 01 13:50:55.267  INFO cargo_tarpaulin::config: Creating config
Feb 01 13:50:55.430  INFO cargo_tarpaulin: Running Tarpaulin
Feb 01 13:50:55.430  INFO cargo_tarpaulin: Building project
   Compiling test_macros v0.1.0 (/home/kk/repositories/openmls/test_macros)
   Compiling openmls v0.3.0 (/home/kk/repositories/openmls)
error: could not compile `test_macros`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
thread 'main' panicked at 'already borrowed: BorrowMutError', src/tools/cargo/src/cargo/util/config/mod.rs:307:20
stack backtrace:
   0:     0x5640baed88e7 - std::backtrace_rs::backtrace::libunwind::trace::h8bc78f7bc1f75bdb
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x5640baed88e7 - std::backtrace_rs::backtrace::trace_unsynchronized::ha4c961c9576f95ba
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x5640baed88e7 - std::sys_common::backtrace::_print_fmt::hc20cfdc233d6eb02
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x5640baed88e7 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h04bea14549780a0f
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x5640baeffbac - core::fmt::write::h3868db8542c90941
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/core/src/fmt/mod.rs:1096:17
   5:     0x5640baecfe32 - std::io::Write::write_fmt::h55dd75636eef6a5c
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/io/mod.rs:1568:15
   6:     0x5640baedb905 - std::sys_common::backtrace::_print::h6439e8525077c7da
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x5640baedb905 - std::sys_common::backtrace::print::h02b685f728ce3931
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x5640baedb905 - std::panicking::default_hook::{{closure}}::h7c29625065fafae1
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:208:50
   9:     0x5640baedb463 - std::panicking::default_hook::hba441710bb71f4d5
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:225:9
  10:     0x5640baedc0a1 - std::panicking::rust_panic_with_hook::ha936eb00e51bc4d9
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:591:17
  11:     0x5640baedbbe7 - std::panicking::begin_panic_handler::{{closure}}::hcd15140e0238536e
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:497:13
  12:     0x5640baed8dac - std::sys_common::backtrace::__rust_end_short_backtrace::hb13a021bb64823a1
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x5640baedbb49 - rust_begin_unwind
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:493:5
  14:     0x5640baefe291 - core::panicking::panic_fmt::h20225113c4a2f8fd
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/core/src/panicking.rs:92:14
  15:     0x5640baefe0b3 - core::option::expect_none_failed::hc6d6d4cea4fdc285
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/core/src/option.rs:1300:5
  16:     0x5640ba710c68 - cargo::core::compiler::job_queue::DrainState::drain_the_queue::h9448af63c9843ee6
  17:     0x5640ba6d9213 - std::panic::catch_unwind::hc8462636a07549c3
  18:     0x5640ba62488b - crossbeam_utils::thread::scope::h1fe7947c436372ad
  19:     0x5640ba70c65f - cargo::core::compiler::job_queue::JobQueue::execute::h209714f0746fa115
  20:     0x5640ba64decb - cargo::core::compiler::context::Context::compile::hd36e8fbd49055cf5
  21:     0x5640ba87fbae - cargo::ops::cargo_compile::compile_ws::hb31345317a1d6cb4
  22:     0x5640ba87f8fd - cargo::ops::cargo_compile::compile::h8fe1bc4431b54241
  23:     0x5640ba9239f2 - cargo::ops::cargo_test::run_tests::h4371f3ed04f093ab
  24:     0x5640ba524e44 - cargo::commands::test::exec::h11092a6f06a3e23f
  25:     0x5640ba521772 - cargo::cli::main::hb0dcf6a220434198
  26:     0x5640ba589e48 - cargo::main::h1fafcf8100afffbd
  27:     0x5640ba57b2f6 - std::sys_common::backtrace::__rust_begin_short_backtrace::h6ab7fd8c80e69f14
  28:     0x5640ba57b31c - std::rt::lang_start::{{closure}}::h2a94ab97e0a8ec08
  29:     0x5640baedc5b7 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7c92107c3c98a949
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/core/src/ops/function.rs:259:13
  30:     0x5640baedc5b7 - std::panicking::try::do_call::h7454c57e8fbf0cc1
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:379:40
  31:     0x5640baedc5b7 - std::panicking::try::he71cdc15ed83b5ec
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panicking.rs:343:19
  32:     0x5640baedc5b7 - std::panic::catch_unwind::hfc08ddb043e6e18c
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/panic.rs:396:14
  33:     0x5640baedc5b7 - std::rt::lang_start_internal::he4958117ec6901fd
                               at /rustc/a2f8f6281817d430e20726128b739d3c6708561c/library/std/src/rt.rs:51:25
  34:     0x5640ba58c195 - main
  35:     0x7f51ad952152 - __libc_start_main
  36:     0x5640ba515071 - <unknown>
Feb 01 13:51:10.518 ERROR cargo_tarpaulin: Failed to compile tests! Error: linking with `cc` failed: exit code: 1
Error: "Failed to compile tests! Error: linking with `cc` failed: exit code: 1"

It also happens on our CI: https://github.com/openmls/openmls/pull/328/checks?check_run_id=1805332325

Okay so I've improved the error message by adding the name of the target that failed before the message contents. That way you can see the crate in your project (or dependency tree) that has caused the compilation issue.
For the crate i tested it on the actual message printout was a linker error and insanely large so I figured the target name was a nice compromise between all possible error printout and enough to start diagnosing the issue

I'm not very familiar with the architecture of cargo, but it seems that shell (in the cargo config) is borrowed at some point before drain_the_queue is called. I searched cargo for calls to shell, but I didn't see anything suspicious pop up. I also did a superficial search of tarpaulin, but couldn't find any calls to shell. Generally, shell seems to be borrowed only very briefly to print some message and is then dropped again. Any ideas on where else to look?

Same issue.

Same issue, the basic command cargo tarpaulin doesn't work, this is a very terrible experience.

cargo clean works for me.

This should be fixed in the next cargo release hopefully https://github.com/rust-lang/cargo/issues/9220

No more reports of it so closing this issue.


Test all the services in the consistent way

We currently have 5 repos (+ deploy) (in Python) with several different ways of running tests.
Acceptance criteria

[x] metastore is tested with tox

Bonus:

[x] able to install with pip
[x] we have Makefile for test and install
[x] versioned

Tasks

[ ] refactor tests for metastore
[ ] update README

FIXED


allow find build script by repo component

Signed-off-by: Junqiu Lei<EMAIL_ADDRESS>Description
At dashboards-maps repo, it has two OSD plugins, raising this PR in order to allow find correct plugin  build script.
Issues Resolved
https://github.com/opensearch-project/dashboards-maps/issues/83
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks @zelinh's help, I know the working_directory is work for plugin directory, but not sure for the build script directory, can I know what directory we need put build scripts to for the plugin in the plugin repo? Currently we have custom_import_map, and will release another maps_dashboards plugin at 2.5.0 also under this repo root path.

I don't think this is actually needed. We could specify the working directory in the input manifest so the build workflow would know where to find each plugin directory even for a single repo. e.g.
https://github.com/opensearch-project/opensearch-build/blob/d5b79bc4fd63a1e6cd6f7f29587916eb7493c827/manifests/2.4.0/opensearch-dashboards-2.4.0.yml#L26

We need this, the build script calling is not controlled by working directory as the working directory is just a param to the build script.

This was merged too fast.
In 2.5 we agreed to https://github.com/opensearch-project/opensearch-plugins/issues/142 whereas all projects that ship multiple plugins from a monorepo are splitting them to avoid this and a series of other problems. Please don't create more nonorepos and revert this change @junqiu-lei.

This was merged too fast.
In 2.5 we agreed to #2188 whereas all projects that ship multiple plugins from a monorepo are splitting them to avoid this and a series of other problems. Please don't create more nonorepos and revert this change @junqiu-lei.

Hi @dblock.
The reason I merged this change is due to 3.0/2.4.1 would get blocked in maps, and this change does not seems to alter the initial behavior while adding a new way to allow repo owners to customize their scripts.
If there is much concern on the approach, I am happy to approve the revert once @junqiu-lei raise it.
Thanks.

Hi @dblock , I just raised the PR to add tests and docs to it, thanks! https://github.com/opensearch-project/opensearch-build/pull/2952


Hi @abhishek-appana, installing the IDAKLU solver on Windows is tricky and we haven't added instructions to do so, yet – but we plan to do so with #4242 and other follow-ups. A short guide is as follows:

Hi @abhishek-appana, installing the IDAKLU solver on Windows is tricky and we haven't added instructions to do so, yet – but we plan to do so with #4242 and other follow-ups. A short guide is as follows:

Set up a C++ compiler: we use a recent version of MSVC, which you can get using Build Tools for Visual Studio Code 2022. Note that you won't need Visual Studio 2022 entirely, just "Desktop development with C++" should be enough.
Next, you'll need the vcpkg package manager for C++. You may get it here: https://vcpkg.io/en/. vcpkg should set up all of the prerequisite dependencies for you.
You can then do pip install -ve . inside a git clone of the PyBaMM repository. Before that, you'll need to set a bunch of environment variables as follows: https://github.com/pybamm-team/PyBaMM/blob/48b4e48d776ad2c254e5fae8db94706c57a8cc38/.github/workflows/publish_pypi.yml#L78-L83

In any case, the easier method, if you have elevated privileges on your machine, is to use WSL2: https://docs.pybamm.org/en/stable/source/user_guide/installation/windows-wsl.html and follow the instructions for GNU/Linux after that.
Originally posted by @agriyakhetarpal in https://github.com/pybamm-team/PyBaMM/discussions/4296#discussioncomment-10166112

Sorry, opened by mistake


0x7F and 0x08 control characters leak out in UI - cause app to easily crash.

I was using Hex Fiend to check up on  a bug I've experienced for years and found HF #to be particularly affected.

This is an OS X bug that I've experienced on all my Macs since 10.5. Hex Fiend is somewhat useful to simply demo the bug, but does not respond well compared to other apps and and crashes quickly
Hit left shift + up arrow and than press backspace/delete (in the position above the enter key) whilesstill pressing the first two keys/in Hex Fiend. . Something gets confused in the deletion behavior while the state is kind of unstable and it seems an interanlly used character gets left behind. You can see them in Hex Fiend. 7F7F7F. Chnage to the left window panel and repeat thsi to to clear that text away and it crashes.

This happens in lots of cocoa text input fields that are roughly supposed to be single-line vies of text and not multi-line ones. People who have a habit of using this key combo to clear buffers/fields have lots of strange unlucky things happen. For some reason get 0x7F from Hex Fiend. I also got 0x7F in the earlier 10.5, 10.6 days of this bug.  But most modern apps today actually give me 0x08 chars, like the Safari Smart Search Field.
Easy to witness there with Google because Google receives the chracters as part of your query. It renders them a "?"s.
Instead  command-A to select all. You can't see these, now, but it will oddly display this empty input area like the entire "nothing" is selected. Can copy and paste them anywhere.

Pasting these bytes from the Safari text field into HF can also cause an instant crash.

Hex Fiend_2016-03-16-034455_AaronBook.hang.zip
Apple rdar://5288750 & rdar://21783531

Also can crash it in the Find window with a text search + that key combo.

What version of Hex Fiend are you using?

Built from HEAD.

I couldn't reproduce this, probably because I'm doing it wrong.

I'm having trouble reproducing this (probably due to an inability to following instructions).

Anything obvious I'm doing wrong here? Maybe upload a similar video to help me out? :|

That looks right based on what I see flashing on the keyboard there. How are you getting it to flip to a full layout like that? I wonder if it has to do with the fact that on the Macbook Pro my "delete" key is the backspace key is the delete key. On the other layout what if you try the actual delete key? Is this on a MBP? Here's me doing it:
https://drive.google.com/open?id=0B9nS3wSv15QjZWdqUWRnVVoySVk
And here is what is recorded by the free "Key Codes" app on the Mac App Store if I press left shift, up key, delete. (then release delete, release shift, up, release shift).
Modifier Change
	Keys:		⇧
	Key Code:	65535 / 0xffff
	Modifiers:	196866 / 0x30102

Key Down
	Characters:	
	Unicode:		63232 / 0xf700
	Keys:		⇧↑
	Key Code:	126 / 0x7e
	Modifiers:	10682626 / 0xa30102

Key Down
	Characters:
	Unicode:		127 / 0x7f
	Keys:		⇧⌫
	Key Code:	51 / 0x33
	Modifiers:	2294018 / 0x230102

Key Up
	Characters:
	Unicode:		127 / 0x7f
	Keys:		⇧⌫
	Key Code:	51 / 0x33
	Modifiers:	2294018 / 0x230102

Key Up
	Characters:	
	Unicode:		63232 / 0xf700
	Keys:		⇧↑
	Key Code:	126 / 0x7e
	Modifiers:	10682626 / 0xa30102

Modifier Change
	Keys:
	Key Code:	65535 / 0xffff
	Modifiers:	65792 / 0x10100

I'll note that in the past I have found that installing https://pqrs.org/osx/karabiner/ and having it active remapping anything makes the issue go away FWIW.

You called it, I have Karabiner. I can get the 7Fs in HexFiend / 08s in Safari with it disabled. Seems kinda like the up+shift+backspace combo confuses Quartz into sending ASCII delete (or backspace?) as text.
I'm still not managing to cause a crash though :/
One difference I'm noticing: in your video, your shift+up selection is relocating the selected region without growing it (moving it back one line at a time), whereas when I try this my shift+up selection grows backwards one line at a time (eventually selecting the whole region). Maybe this is more related to the crash than the 7Fs themselves?
Thanks for the detailed info!
Also: The keyboard viewer flipping was just because I tried both my built-in MacBook keyboard and also a USB keyboard.

Okay, just managed to get an (unreliable) crash via some combination of shift and mashing arrow keys.
An Applescript or something to reproduce your crash would still be useful, if it's not too difficult... the arrow-key spamming worked for me once and hasn't yet again :|.
Hopefully these crashes are related, I'll take a look into fixing this soon.

I remember frrom last night it was a LOT harder to crash the builds I made myself in xcode. OTOH the one hosted at  http://ridiculousfish.com/hexfiend/ was very easy - I'm actually unsure if that is the debugger or some kind of instrumentation changing things or if it's just been partially worked around in git since then.

Crashes it every time for me: paste 7F7F7F or 080808 from somewhere else (for some reason cut from hexfiend and pasted back in can't cause it. Maybe encoding? HF has some richer format than bytes with  some metadata?) and paste it into the hex view on the left AFTER switching to overwrite mode.

Ah, great. The binary at http://ridiculousfish.com/hexfiend/  looks/works/crashes for me exactly as you've been describing. Thanks for the help, I should be able to repro fine now.

(What causes the chunking you see above is just caused by the fact the initial key repeat delay hadn't occurred yet. I don't know if that's part of the actual crashing.

Yeah, the selection thingy is weird. It seems to exhibit odd behavior in specific cases, such as "Opened a blank document, did the shift+up+backspace thing to generate 7Fs, and then do a shift+up to select stuff". I think this odd behavior corresponds with some unusual internal state, which was leading to the crash.
I think I just fixed that crash, so the issues remaining are:

Fix slightly wonky (but harmless now, hopefully) selection behavior in rare cases
Workaround rdar://21783531

I suppose it would be surprising if this code were not involved Shift! Arrow keys! Messing with modifiers! Anchoring!: https://github.com/ridiculousfish/HexFiend/blob/aebb7df93d99963fb9e04c7d1bbdf42176e86ed0/app/sources/DiffDocument.m#L286-L299
But I never played with diffs.

By golly I think they did it!
The bug itself with the strange behavior I haven't been able to reproduce in 10.12 for like 5 seed releases.
And the problem that was on HF's end that would have otherwise plagued users of other OS X releases you already fixed. Probably could close this up. Thanks!

Nice! Thanks for all the help.

I was a bit premature. I'm not seeing 0x08/0x7Fs in my clipboard anymore and e.g. the single-line Find field cannot select the non-existent line above the current line, but Hex Fiend isn't actually acting much differently. I'll recompile it and see if maybe the fix only occurs after a recompile or uses the 10.12 SDK.

Is there still an issue here with the latest changes in master?

v2.4 was just released. I'll close this for now. If there are still bugs specific to this please reopen or create a new issue.


Bump to 2.0.0-beta1.

Coverage remained the same at 99.722% when pulling f6a3682b6905d9d1b78d9f57a0d52275005d622b on mng/bump-2.0-beta1 into cdb8d48c0dc7e2f208db8a43ceb75b8c6067d167 on master.


Unexpected reordering after keyed removal

Per this example using current unstable picodom @2.0.0
https://jsfiddle.net/4eunk2um/
Click to remove elements from the list, and note how the removed element always ends up at the bottom of the range - because it doesn't get destroyed until 2 seconds later.
Keyed updates presumably exist, for one, so you can do this sort of thing?

@mindplay-dk It seems this demos the problem you were having or am I looking at something else?

Nevermind, I see the elements are correctly removed, but I admit there's something funny going on.

@mindplay-dk @JorgeBucaran this is just how the algorithm works. We can't leave the to-be-removed-elements in their original place, because that messes up the indexes mapping vdom to DOM. So the elements go to the bottom of the list, outside the range of the vdom.
I don't think I'd consider it a bug so much as the only reasonable way to handle delayed element removal. More like a "known limitation"
Incidentally, this behavior is precisely the reason I have to do position tracking in hyperapp-transitions.

We can't leave the to-be-removed-elements in their original place, because that messes up the indexes mapping vdom to DOM.

I think maybe we just discovered why some libs (petit-dom, snabbdom, etc.) implement diffing and patching in two separate passes.
To me, this is by no means a "limitation" - it makes onremove not useful for the one thing I'd want to use it for: transitions.

@mindplay-dk What would you suggest?

One option is promises, like I suggested earlier - so that you can actually know when an update has finished. Not completely convinced that would even solve it necessarily though, since another update could be triggered indirectly by another DOM event (click, input, etc.) before the update is complete - you'd have to control the updates at a higher level to address that, e.g. something like snabbdom's patch(container, vnode) which "cheats" by injecting historical state into the vnode, which seems really dirty; it wouldn't be my preferred approach... there is surely another way to factor the same functionality though, without relying on side-effects, but anyhow...
I'm not sure there are any simple answers here.
Perhaps supporting an onremove event is kind of the problem in the first place - encouraging you to defer the actual destruction of the element appears to be the root cause of this issue. I mean, you could argue that we're enabling deferred removals, but the library actually doesn't really support deferred removals - it doesn't really work, just leads to broken UI.
Arguably, for things like animation, there are likely better/simpler/more explicit ways to achieve animation, besides intercepting the removal of an element from the DOM. Like, what does removal mean? If removal means removing the element from the DOM, clearly that's the wrong time to decide you're not ready to remove the element from the DOM, because the DOM and the VNode model ends up out of sync.
You could argue you just shouldn't remove elements from the VDOM before you're ready to remove them from the DOM. On the other hand, it's terribly convenient, because removals are usually in response to changes that have already happened in the model, and (with e.g. the SAM pattern) that means, by the next render, you no longer have the information that was removed from your model.
Sorry for the stream of consciousness here, but... I think the bottom line is, either we support a feature like this and make it work, or we remove a partial feature that isn't really going to be useful.
I'd really like to see it work of course.
Well, here's one idea, maybe... what if you passed the resolve function of a Promise to the onremove handler, and that way made it responsible for signaling back to the framework when it's ready for the actual element removal? Okay, so that's not really different from what we're doing with the remove callback now, but, if at the same time, you were to attach this Promise to the VNode itself, so that, during the next call to patch, you could look at the old VNode, see if it's carrying one of these previously-issues promises, and check if it's been resolved - and if it hasn't, we'll consider the old VNode as still valid; let it participate in that update exactly as if it were still in the list of new VNodes, at the location we're currently processing in the old list of VNodes. I don't know, would that work??

What if we make onremove function like ondestroy, which is actually necessary and we can implement (@4lejandrito already did!) and just get rid of the current behavior. For animation I would prefer CSS.

For animation I would prefer CSS

In theory, so would I - in practice, as said, the data as already been removed from your model, unless you build your model with something like an array of elements_being_removed, which would just be tremendously awkward. Animation is a detail I don't want to concern my model with.
The promise idea might work... this part:
      var oldKey = getKey(oldChild)
      if (keyed[oldKey]) {
        i++
        continue
      }

Here we skip to the next old index, potentially skipping an element that's actually still alive, right?
So, something like this:
      var oldKey = getKey(oldChild)
      if (keyed[oldKey]) {
        i++
        continue
      } else if (oldChild.is_being_removed) {
        keyed[oldKey] = oldChild
        oldKeyed[oldKey] = [oldElement, oldChild]
        i++
        continue
      }

That is, if we encounter an old keyed node, and it's not present in the keys of the new nodes, if it's been flagged as is_being_removed, we make it carry over to the next update even though it's missing. The Promise, when resolved, will clear the flag.
Obviously this code is wrong/incomplete, we'd also have to actually inject the missing VNode from old nodes into new nodes to make sure it carries over not only for the next update, but for every future update, until the flag is cleared.
The point is, by the first update where we find an old keyed node has been removed, we still have the order information in the old list of nodes - that hasn't been lost yet! We just need to somehow make that information carry over from this update to future updates, until we find that the actual removal has happened.
(we don't necessarily need promises for that, we could also just check if the DOM element we encounter still has a parent node - if it doesn't, it's been removed.)

i'm not too familiar with the picodom's reconciler, but all too familiar with these implementation details. domvm has a 2-pass reconciler:

oldVtree <-> newVtree is resolved and attrs/textcontent is patched, dom element is re-linked to new vtree
the dom reconciler reorders the dom children

part 2, if any element must be removed and willRemove or willUnmount hooks return a Promise, it hooks up a deferred removal and sets a ._dead = true flag so that any followup redraws can skip over it in part 2 again.
this is certainly not the whole story, so i dunno if that helps.

For starters, I've modified the onremove test-case (#69) to provide a clear illustration of the problem.
This modified test-case defers the removal by hoisting the remove callback to the test-scope - then makes assertions after patching but before invoking the deferred/hoisted remove callback.
In my opinion, we should get this working before attempting to add the ondestroy feature - these life-cycle events are closely related, and likely fixing the issue with onremove will affect the dispatch of ondestroy handlers. Also, just, one thing at a time, right? ;-)
I don't have a concrete idea how to fix this, just the clues posted above, so I will leave it here for now, in the hopes that someone else can figure it out maybe. The test should help, right? :-)

I think something like you guys suggested, passing forward "dead" nodes at their current index, might do just the trick. And now I'm curious to investigate it (no promises though, I'm a bit busy at the moment)
I feel like I've kind of been the "transistions" guy in the hyperapp/picodom sphere. And yet this hasn't been a pressing issue for me. That's because I've also been doing FLIP animations, which requires movement/layout tracking the elements. And once you've already paid that price, you get properly laid out remove transitions for almost free.
But if you don't care about FLIP animations then I agree that layout tracking & compensation is too steep a price to pay for such a simple thing as a remove transition. So I'd like to see this solved.
Still, I'm not familiar with any other vdom engines, so I'm still wondering if we're sure this is not also a problem in for example snabbdom? (@leeonya, you seem to suggest this issue is solved in vmdom?)
At least... I know Vue is based on snabbdom, but it ships with its own transitions library, which might indicate transitions are not so straightforward there either...
@mindplay-dk have you by chance checked (like with a similar jsfiddle) if any other vdom engines have the desired behavior?

@zaceno https://github.com/leeoniya/domvm/issues/159 & https://jsfiddle.net/cup40vu7/

What does preact do here?

@mindplay-dk By the way, I forgot to ask probably the most important question. What's the desired result? Like, how would you expect the animation to play out?

I would assume it's that the elements keep their current place in the list until they're actually removed. Like in @leeoniya s example with vmdom

What @zaceno said :-)

It's hard to understand @leeoniya's example, I mean not his code (well, that's another story haha), but the concept we under discussion. I'll try looking at it again.
@mindplay-dk So, you want the element to remain on the DOM, but you changed the state and the DOM is built according to the state.

@JorgeBucaran not just remain in the dom, but remain at the same place in the dom (so they don't jump to the bottom before animating out)

So, you want the element to remain on the DOM, but you changed the state and the DOM is built according to the state

It is, but not according to how onremove supposedly works.
So either the specification is wrong, in which case onremove likely shouldn't exist at all - or the specification is right, and onremove needs to meet the spec.
I'd argue the latter - there's a reason we have the VDOM as an intermediary before the real DOM, and enhancing the life-cycle vs that supported by DOM itself, is arguably one of the more useful advantages that VDOM provides over traditional DOM.
If we don't take advantage of having a VDOM at our disposal, why do we have it at all? It's one reason I actually prefer the VDOM approach over libraries of late using patching strategies that directly patch the DOM with no intermediary model at all.
We could make do with just an ondestroy, but without the enhanced life-cycle, as with plain DOM, things like animation would not be directly possible without substantially displacing picodom and pushing that responsibility elsewhere by some other mechanism. The VDOM is absolutely suitable for this feature, and I hope we're not looking for excuses to forego this feature because it's hard? ;-)

(I'd love to help solving this problem, I just don't know when I'll have time.)

@mindplay-dk I am not looking for excuses to forego this feature, but I first need to understand what we want. 😄

in fewest words: during any redraw, the lib should never move elements that have been queued for removal by a prior ondestroy/promise.
the code in the jsfiddle i linked wasn't mine, heh :)

@JorgeBucaran what leeoniya said.
You are aware, of course, that when we see that a keyed node is removed from the vdom, and we go to see if there's an onremove handler to call.
Then if there is we don't immediately remove the element.  So the element is still in the dom for a while - but where in the dom? At the bottom of the sibling list.
The effect of that is, if you naively use a css-transition to fade out the element,  the element will first skip to the bottom of the list, and from there start fading out.
What @mindplay-dk is asking for, is that the element fades out from it's original position.

But!
... I'm not entirely sure I want that behavior @mindplay-dk is suggesting.
I think I'd perfer to keep the current behavior, and just document it better. Just state in the docs, that when you use onremove, and don't immediately remove the element, it will be moved somewhere else in the dom, outside the reach of the patching algorithm.
The reason I'd like to keep the current behavior is that I may not want to wait until a slowly fading element is done, before the surrounding elements react to the removal of their sibling.
Take another look at that Toasts example I posted earlier (here it is again: https://codepen.io/zaceno/pen/QOYOZd) - and notice how, when you click a toast somewhere in the middle of the list, the surrounding elements don't wait for the animation to finish. They immediately start sliding up, during the transition.
I honestly have no idea how I'd implement that behavior, if to-be-removed elements keep their place in the DOM as @mindplay-dk is suggesting.

I deleted my previous comment of why I want to keep the current behavior, because just after posting I realized a solution to the thing I was saying would be impossible with @mindplay-dk 's suggested behavior. 🤦♂

@zaceno right on the money! 😄
@JorgeBucaran what he said 😉

I attempted a fix but I'm out of time, and I had to give up.
I can provide some clues as to what won't work.
My idea was to flag the old node for preservation inside removeElement:
function removeElement(parent, child, element) {
  var props = child.props

  if (
    props &&
    props.onremove &&
    typeof (props = props.onremove(element)) === "function"
  ) {
    child.preserve = true
    props(function () {
      child.preserve = false
      remove()
    })
  } else {
    remove()
  }

  function remove() {
    parent.removeChild(element)
  }
}

Note that I change the function signature from (parent, element, childProps) to (parent, child, element) so as to get access to the VNode.
Inside the main loop I figured I'd then splice the preserved node back into the list of new nodes:
    while (j < len) {
      var oldElement = oldElements[i]
      var oldChild = oldNode.children[i]
      var newChild = node.children[j]

      if (oldChild && oldChild.preserve) {
        node.children.splice(j, 0, oldChild)
        i++
        len++
        continue
      }

From doing a lot of console.log() statements to try to understand the order of events, I can say though, this approach is not going to work, because, by the time we flag the node for preservation, it has in fact already been removed.
I think what needs to happen is we must somehow preserve the node as soon as we encounter it - like that means removeNode needs to return a flag indicating whether or not the node in question may actually be removed.
function removeElement(parent, child, element) {
  var props = child.props

  if (
    props &&
    props.onremove &&
    !child.destroying &&
    typeof (props = props.onremove(element)) === "function"
  ) {
    child.destroying = true // flag to avoid triggerin onremove handler again
    props(function () {
      child.destroy = true // flag for actual destruction in main loop
      remove()
    })
    return false // not removed yet
  } else {
    remove()
    return true // directly removed
  }

  function remove() {
    parent.removeChild(element)
  }
}

Unfortunately there are three different calls to removeElement which may all need to act differently depending on whether or not the node was actually removed.
Note that we can't simply pass the list of new nodes to this function, because the len in the main loop will also change if we carry over an old removed node.
That's all I got, and I won't get to this again until next week most likely, so...

@mindplay-dk @JorgeBucaran yes I made a brief attempt at it too, but I think this requires a bit of a rethink of the algorithm, at least for me. Unfortunately I don't quite have the time either, at the moment. But IIRC Jorge was planning a makeover anyway, to optimize it somewhat. Maybe look into this at the same time?

@zaceno Maybe look into this at the same time?

If this is not resolved by then, I'll definitely look into it when I get to rewrite patch. Maybe in 2 or 3 months if I can use my time well. I really wish it could be sooner! 😞

Tested this issue again with<EMAIL_ADDRESS>and it still doesn't work 😢
https://jsfiddle.net/mindplay/5vkfqg8x/

@mindplay-dk Well, obviously, I didn't fix it for this release. I hope to tackle this when I rewrite the diff algo in Hyperapp.

I've run into the same issue discussed in this thread. I'm trying to start an animation when an element is removed, but the animation is asynchronous, so the DOM might get patched before the asynchronous operation completes. This will mean the patcher corrupts the DOM, as the patcher's "truth" of the world is a future DOM where removed elements have been destroyed. The fix, or potentially hack, I'm using to resolve the issue, is to first mark a DOM element as "removing" before the asynchronous remove operation is called:
element["removing"] = true

Then, when patching, these zombie DOM elements are filtered out as follows:
var active = Array.from (node.childNodes).filter(x => x["removing"] !== true) // consider perf + browser support
for (var i = 0; i < oldChildren.length; i++) {
   oldElements[i] = active[i]

The basic idea is that the patcher should act as if zombie elements don't exist. So long as there's a mapping function whereby the patcher's truth (i.e. the future world) can be translated to the current reality (the DOM that still includes the zombie elements), then we're OK. The issue will be that this mapping function is actually by definition not a function, because information is lost when something is removed. However, in many practical cases (e.g. to get our typical animations working) this might not matter. In addition, the patcher can get that lost information by inspecting the actual DOM elements, or potentially via an extension to the vdom API to express intent (much like we do by specifying keys).
I'm now trying to figure out issues with such an approach.
Suppose we represent dom nodes with letters, with uppercase letters indicating an ordinary element, and lowercase letter indicating that element is being asynchronously removed, and brackets indicating child elements. The current vdom only knows of uppercase letters, while the real dom knows of both uppercase and lowercase letters.
So a simple unproblematic removal of an item in a list would be:
start -> async remove B -> destroy b
ABC -> AbC -> AB

But here's some potential issues:
Ambiguous insertion order issue (i.e. should we insert X to the left or right of b?):
start -> async remove B -> insert X -> destroy b
ABC -> AbC -> AXbC -> AXC
ABC -> AbC -> AbXC -> AXC

Parent deletion issue (i.e. should we prematurely destroy b before its async remove complete?)
start -> async remove B -> remove Y -> destroy b
X(Y(ABC)) -> X(Y(AbC)) -> X -> X

Wondering how the other virtual DOM libraries deal with this.
Thoughts?

https://github.com/jorgebucaran/ultradom/releases/tag/3.0.0 🎉

@mindplay-dk What does preact do here anyway? 🤔

Per the docs, lets you specify the parent-node and optionally a child-node to replace - if no child-node is specified, it appends a new one to the container and returns the newly created node.
Again, this seems to be geared towards convenience, like a framework - I think a more library-like approach would be to set aside convenience concerns, just do the heavy lifting; if ultradom does all the hard work of creating the DOM tree, it's already very easy (and much more versatile) to place it yourself using standard DOM methods like appendChild(), insertBefore(), replaceChild(), etc.
I expect a library to do the difficult stuff - I never find it helpful or convenient when a library tries to make things that are already easy even "easier", because they always miss corner cases.
I would much prefer it if we could just go back to the much simpler API we settled on earlier - where the element argument is the target node, rather than it's parent, and is optional, and it always returns either the created/replaced or updated node.
It was simpler and more flexible, and makes it possible to built either the Preact-like or Hyperapp-like API yourself, or a mount() function as before, or probably any API you could dream up.
Alternatively, stop managing the previous state and just export patch() - I liked the new render() function at first sight, but it is once again less flexible than what we had before.
Bottom line is that the current approach blocks certain patterns - and the other approach doesn't prevent any of the patterns/usages that the new approach favorizes; those can still easily be implemented, it just happens to be your own choice. That layer is so small, it's definitely not the primary reason why you'd use ultradom in your framework.
Typically, your framework is going to have one or maybe two calls to this library - why would you abstract away the longer patch() signature to save somebody two minutes of thinking when they integrate the library? Just doesn't make sense to me.
If somebody wants those 3 lines of code in render() they can just copy/paste them from the README 😆

@mindplay-dk We were talking about an edge-case with render, this convo has nothing to do with the API. I asked what does preact do to avoid the bug you found.

Sorry, I'm getting mixed-up between two different issues 🙄

Does preact present the same issue (or not) of "unexpected reordering after keyed removal"?

It doesn't support deferred removals, so... I have no idea.
I've never managed to implement animation in either React or Preact yet. I understand there's a whole big add-on library to do that, so it's probably non-trivial.
The unexpected reordering isn't really the issue anymore though, I think?
The new problem is done() sometimes fails during deferred removals.
Did you see this other, more aggressive example?
https://jsfiddle.net/mindplay/omovhf25/
It randomly adds one and removes another keyed element from a randomized set.
Look in the console - everytime it errors, an extra element gets stuck at the end of the range, forever - done() for that element has already been called, so an additional element reference gets "lost" every time it fails to remove one, and the elements start to pile up, one for every error in done().
Change the timing (in the last line of the script) from rand(..) to e.g. 1100 and you will see it never errors, and the order is always perfectly preserved. That part is solved 😄👍

@mindplay-dk It doesn't support deferred removals, so... I have no idea.

I think React/Preact's equivalent of ondestroy is componentWillUnmount, so are you saying there is no equivalent of onremove?

Yeah, for components, sure - but not for elements, as far as I know.
For elements, there's the ref-attribute, which as far as I know is the only element-level life-cycle feature - it gets called with the element after creation, and again with null after the element gets removed, hence (to my knowledge) no direct way of animating addition/removal of elements.
So if I had to port this example to P/React and get animation, I'd have to implement a component for the individual notifications - even then, I'm not completely sure how to defer removals, and tbh I'd prefer not to find out at this time.
In other words, I'm interested in animation if it's "low hanging fruit" only - if it was as easy as it promises to be in ultradom :-) ... if it's going be complicated, I can forego animation, which is what I concluded when I finally caved and decided to use Preact at work...

@mindplay-dk What is Preact's equivalent of onremove for components?

The example you made is very useful to diagnose and play with this bug. It's actually fun. It's also frustrating haha.

What is Preact's equivalent of onremove for components?

I don't think they have one.
I think you'd have to wrap the component in another component that controls the inner component's life-cycle, but I honestly have no idea how they do it. All I know is it's not straight-forward. I think nobody hand-rolls their own animations, most people use this or something similar.

But I am also considering to simply remove onremove for good.

Okay, your example helped me confirm that this definitely can be fixed by storing the element in the node. When I console the element and the node, I can see that every time an element is "forgotten" the node and the element don't match, so they're getting mixed up.

But I am also considering to simply remove onremove for good

😱

Okay, your example helped me confirm that this definitely can be fixed by storing the element in the node. When I console the element and the node, I can see that every time an element is "forgotten" the node and the element don't match, so they're getting mixed up

😌
This is what I tried to explain to you repeatedly, what I was trying to show you in the (broke ass) implementations I came up with - making the DOM itself the "source of truth" is the only way to approach this. the implementation will be completely hardy against external modifications from custom DOM manipulations or third-party libraries; it'll recover from any state to the desired state, at any time! 😄
You actually only need to inject the last-applied props into the DOM node for prop-updates - you don't even need or want the list of child vnodes.
See this in the main loop of my last failed attempt: isManaged() checks if a DOM node is one that we created - and simply ignores any un-managed DOM nodes, including (!) those left behind during deferred removals. Unmanaged nodes are regarded in terms of order when positioning new/old nodes, but only managed nodes actually receive updates.
(As you can see from the first lines in that file, I inject __type into every managed node, including text-nodes, and I inject __key and __props into every Element node - and likely __props would have been enough, since the key is in there too, it just made it a little easier to check if nodes are keyed or not...)
Well, imma lean back and see where this goes - we're definitely getting very close 😃👍

At least the way it works in petit-dom (the only vdom I’ve played much with besides Ultradom), as far as I can tell, the way you do any lifecycle events is to provide a component in the form of an object which defines the mount, unmount and patch methods.
When you do that, how the tree is handled from that point on is entirely up to you, including removing or deferring removal of the element.
As such, petit-dom’s “unmount” is closer to ultradom’s onremove than ondestroy.
I suspect it works similarly in React - or how else would exit transitions even be possible?

@mindplay-dk @zaceno @pickle-ts I'm glad to report this bug is fixed in https://github.com/jorgebucaran/superfine/tree/store-elem-in-vnode. I still need to iron out some details, but it appears the infamous Rasmus' Bug has come to an end.

This is great @jorgebucaran! Are you going to incorporate this version of superfine into Hyperapp 1.x?

Thanks, @jimfranke! I'm planning to integrate these changes to Hyperapp 2.x.

it appears the infamous Rasmus' Bug has come to an end

it's the end of an Era 😃


Windows Build Tools Required for Windows without Python

Expected Behaviour
Plugin installation happens by following the docs
Actual Behaviour
Plugin installation does not happen if python is not installed in windows
Reproduce Scenario (including but not limited to)
Installing migration plugin in Windows without python
Steps to Reproduce

Remove python from windows if already installed.
Install Node 10+
Install aio cli
Install aio-cli-plugin-aem-cloud-service-migration
We get an error regarding python error and also windows tools

Platform and Version
aio version - @adobe/aio-cli/6.0.0 win32-x64 node-v10.16.3
Sample Code that illustrates the problem
Logs taken while reproducing problem
The issue was fixed after running this
npm install --global --production windows-build-tools
I am not sure whether anybody has tested this. If Windows require this, then we might have to document this in the docs.

I was having the exact same issue but the "npm install --global --production windows-build-tools" command gets stuck after printing the message "Successfully installed Python 2.7".
Afterwards I still can't install the plugin.  Same error message "Error: Could not find any Python installation to use"

I was having the exact same issue but the "npm install --global --production windows-build-tools" command gets stuck after printing the message "Successfully installed Python 2.7".
Afterwards I still can't install the plugin. Same error message "Error: Could not find any Python installation to use"

Try running the cmd as administrator.

I am already running it as administrator. I have also tried running it from cmd or PowerShell but both get stuck.
Status from the installers:
---------- Visual Studio Build Tools ----------
Still waiting for installer log file...
------------------- Python --------------------
Successfully installed Python 2.7

I added the "--vs2015" option and got it working.
Full command:
npm install --global --production windows-build-tools --vs2015

I added the "--vs2015" option and got it working. Full command: npm install --global --production windows-build-tools --vs2015

Great. Good to know! Thanks for the update


[MM-37233] CRT:fix two scrollbar issue in threads view

Summary
CRT:fix two scrollbar issue in threads view
Ticket Link
https://mattermost.atlassian.net/browse/MM-37233
Related Pull Requests
NONE
Screenshots
Release Note
NONE

Hello @AshishDhama,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Cherry pick is scheduled.

/cherry-pick cloud

Cherry pick is scheduled.


Form Validation and responsiveness

validation added for login and sign-up form.
added hamburger menu for mobile and tablet view.
bug fix for toast notification.
[User Story: #456 #457 #439 ]
Signed-off-by: shreyas<EMAIL_ADDRESS>

Conflicts resolved.


rustup crashes (detects wrong cpu?) on Scaleway ARM7 server

% curl https://sh.rustup.rs -sSf | sh -s -- --help
info: downloading installer
Illegal instruction
rustup: command failed: /tmp/tmp.AJc37brj9i/rustup-init --help

The cpu here is a ARMv7 Processor rev 2 (v7l) but apparently without NEON extensions, so that may be the problem.

It seems to be detecting armv7-unknown-linux-gnueabihfbut https://users.rust-lang.org/t/rust-web-development-hosting/5975/3 suggests that it needs arm-unknown-linux-gnueabihf instead.

arm-unknown-linux-gnueabihf does work here so it sounds like the shell script is just detecting the wrong thing.

I think it would work to look at the flags in cpuinfo and see if the cpu has neon.

cpuinfo contains
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 50.00
Features        : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0x584
CPU revision    : 2

I'll send you a patch for this.


Warning about epochs is confusing

We have a warning like this now if epochs aren't set:
2020-03-12 13:35:57 WARNING  rasa.nlu.classifiers.diet_classifier  - Please configure the number of 'epochs' in your configuration file. We will change the default value of 'epochs' in the future to 1.

This makes it look like it's always referring to the DietClassifier component, when it could be coming from e.g. the ResponseSelector as well. We should mention which component the issue is with

@tttthomasssss since you're working on making the warnings about inability to train to include class names, this is related

fixed via https://github.com/RasaHQ/rasa/pull/5443

https://github.com/RasaHQ/rasa/pull/5444


Issue with Krita crashing when changing plugin settings

I am using Krita 4.2.8 on Windows 11 and installed a plugin. When I tried to change the backend URL from the plugin settings by pressing "sd plugin config", Krita crashed. After that, I was unable to launch Krita.
Steps to reproduce:
Launch Krita.
Install the plugin.
Open the plugin settings.
Select "sd plugin config" and try to change the backend URL.
This action causes Krita to crash, and it fails to launch after a restart.
Expected behavior:
I expect Krita to not crash when changing the plugin settings and to function normally.
Environment:
Krita version: 4.2.8
Operating system: Windows 11
Additional information:
Plugin download source: [https://github.com/JasonS09/comfy_sd_krita_plugin]
I have thoroughly read and followed all the settings mentioned in redmanu.
Any other relevant information or comments can be added here.
I would appreciate any assistance in resolving this issue. Thank you.

I have the same problem. Running Comfy on a Server within local network. After changing the URL, Krita no longer starts as long as the links are in pykrita. I have deleted the repo and reloaded it. No change
Krita version: 5.2.2
Operating system: Windows 10
Any advice would be highly appreciated
Thanks

This worked for me:

delete krita_diff_plugin.ini in Roaming\krita
krita started again with the plugin activ
changed to server IP


Twitter links

For some still unclear reasons, the Twitter handle URLs started failing htmlproofer with a 400 error code.
As this is preventing website releases, this is updating the htmlproofer command to ignore the Twitter URLs. I can add a follow-up issue to review.

Perhaps due to "...does not use Twitter's API, thus, I'm limited to 150 requests per hour, per IP address. " (stackoverflow)
A compromise in a potential follow-up might be to exclude these URLs that we know to be safe (and have substantial overhead for loading) and instead only check explicit tweets (if we even have any).
Otherwise, :+1:

Perhaps due to "...does not use Twitter's API, thus, I'm limited to 150 requests per hour, per IP address. " (stackoverflow)
A compromise in a potential follow-up might be to exclude these URLs that we know to be safe (and have substantial overhead for loading) and instead only check explicit tweets (if we even have any).
Otherwise, :+1:


onUploadSuccess callback (S3) missing?

Hi,
This callback onUploadSuccess doesn't seem to exists right now or am I missing something?  When using S3 and the uploadSuccess endpoint option, after the url gets called is it possible to bind a callback to access that success response?
Many thanks!

You can contribute an onComplete event handler to deal with the result of any upload attempt.
From the S3 server-side documentation:

You can also pass any data to your Fine Uploader complete event handler, client-side, by including it in a valid JSON response to the uploadSuccess.endpoint POST request. In fact, the S3 demo server-side code on FineUploader.com is passing a signed URL to the complete handler which allows you to view the file you've uploaded.


separate lib_ unit tests from other unit tests

Run lib_utils and lib_openshift tests as a separate step, with a separate coverage directory.

Thanks @detiber


AttributeError: 'VideoWidget' object has no attribute 'getImageItem'

I installed the package according to the instructions. The GUI opens and connects to the camera. However, neither compiled version (tofcam660.EXE) nor development version allow to save png or raw with the following message:
Traceback (most recent call last):
File "C:\Python311\Lib\site-packages\epc\tofCam_gui\gui_tofCams.py", line 64, in _save_png
self.imageView.getImageItem().save(filePath + '.png')
^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'VideoWidget' object has no attribute 'getImageItem'
Traceback (most recent call last):
File "C:\Python311\Lib\site-packages\epc\tofCam_gui\gui_tofCams.py", line 59, in _save_raw
test = self.imageView.getImageItem().image
^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'VideoWidget' object has no attribute 'getImageItem'
Could it be due to incompatibility between Python (I'm using 3.11) and PySide6 (I'm using 6.6.2)?

Hi and sorry for the late reply.
This is currently a known bug and will be fixed in the next release.


Activity indicator

Activity indicator using binary semaphore -> LED is illuminated when typing through UART

Add activity indicator with binary semaphore


[REG2.068a] Issue 14844 - __traits(allMembers) must not visit yet not instantiated template members

https://issues.dlang.org/show_bug.cgi?id=14844

Rest LGTM.

Thanks.


SchemaModel's index doesn't store the name

Describe the bug
When creating a SchemaModel, if you specify an Index and try to retrieve its name, the name is set to None instead of the field name.

[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of pandera.
[ ] (optional) I have confirmed this bug exists on the master branch of pandera.

Code Sample, a copy-pastable example
class MySchemaModel(SchemaModel):
    my_index: Index[pa.String] = pa.Field(coerce=True)

MySchemaModel.to_schema().index
#> <Schema Index(name=None, type=DataType(str))>

Expected behavior
I would expect the Index to set its name as the field name from the SchemaModel:
MySchemaModel.to_schema().index
#> <Schema Index(name='my_index', type=DataType(str))>

Desktop (please complete the following information):

OS: Mac OS Big Sur
Browser: Chrome
Version N/A

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

You need to use check_name:
import pandera as pa
from pandera.typing import Index

class MySchemaModel(pa.SchemaModel):
    my_index: Index[pa.String] = pa.Field(coerce=True, check_name=True)

print(MySchemaModel.to_schema().index)
#> <Schema Index(name=my_index, type=DataType(str))>

The reason is that naming a pandera.Index will automatically activate name validation. In a SchemaModel, you have to name the class attribute to satisfy python's syntax. check_name is there to not force users to name the index of the DataFrames they want to validate.


Tetra and Mgui not marked as mod dependencies

literally a 3 minute fix

Done

Fastest fix to an issue WR speedrun?