Convert everything to new inline scheme (#57)

As per @DanielGibson's suggestions in #57, most functions in Handmade Math are now static inline and do not have separate prototype and implementation. Longer functions like HMM_Rotate are not marked as inline.
Resolves #57.

@StrangeZak The diff is way too big to make sense of on Github, so I recommend just checking the whole thing out for yourself.

Removing the Prototypes will break the single-header style format of the library. i.e: the #define the implementation in one location then just include the file in every other location.

Also i assume this would create a TON of linker errors. If you include handmademath.h in multiple files

I don't think this will break anything, the prototypes have been replaced with inline implementations that are in the header-part (i.e. not behind #ifdef HANDMADE_MATH_IMPLEMENTATION), so they will be available in every file that includes handmademath.h

Right. The problem is that it is not possible to inline a function if the implementation is not present in the header file, which is why it is now structured this way.
I would recommend just swapping out HandmadeMath.h for yourself and seeing what happens. The intent of this update is to improve performance and inlining without requiring any changes to the way it is included (except, perhaps, for removing HANDMADE_MATH_NO_INLINE).
I am about to push another commit that makes a few more of the big functions extern instead of inline, since they were really too bulky to be inlining.

@DanielGibson I made some judgment calls on what I thought would be "big enough" to mark as extern. Let me know if you think I have misjudged any of them.

Right. The problem is that it is not possible to inline a function if the implementation is not present in the header file, which is why it is now structured this way.

Is this really true? I had no idea.

@bvisness will look at it some time
@StrangeZak: yeah, inline means that the compiler has to know the function implementation while compiling the callers of the function, so it can "inline" the function there - kinda like copy&paste it there and optimize it depending on the surrounding code. that way you don't only lose the function call overhead but the optimizer can also make assumptions that it can not in the general case (when compiling the function as part of a .c file where it doesn't know anything about the callers)

yeah i understand how inlining works, i guess i just didn't understand what parameters makes the compiler inline functions. "inline" is just a hint to the compiler at the end of the day, it can choose to not inline if it wants to.

Yes, but it absolutely cannot inline the function when the body of the function is not available in that translation unit.

Thanks for clarifying

@DanielGibson I would like to get this merged soon, so I would appreciate if you offered your thoughts on which ones I chose to make extern. You can find them down at the bottom of HandmadeMath.h, but here is a list as well:

HMM_Power
HMM_Transpose (non-SSE version)
HMM_AddMat4 (non-SSE version)
HMM_SubtractMat4 (non-SSE version)
HMM_MultiplyMat4
HMM_MultiplyMat4f (non-SSE version)
HMM_MultiplyMat4ByVec4
HMM_DivideMat4f (non-SSE version)
HMM_Rotate
HMM_LookAt
HMM_InverseQuaternion
HMM_Slerp
HMM_QuaternionToMat4
HMM_QuaternionFromAxisAngle

The matrix ones I chose not to inline because of the amount of looping required and the variables associated with that. Functions like HMM_LookAt. Many of the others were externalized because of the number of variables as well. Please let me know if that logic makes sense or if you would do anything differently.

Looks sane to me :)
But why is it HINLINE and HEXTERN and not HMM_INLINE and HMM_EXTERN (or maybe HMMINLINE)?
This is probably not very important, but using the proper HMM prefix everywhere makes clashes with other libs less likely.

Ah, good point. Just a leftover from when this was implemented in the first place.

@StrangeZak I'm shipping this thing!


Please give me more confidence in the integrity of the releases

As an operator deploying rkt -- an application container built on a spec that takes security seriously -- it is immensely frustrating that I cannot reliably validate the source and integrity of releases with GPG.  The rkt releases are not signed with an organizational key; they're signed by "Iago López Galeiras<EMAIL_ADDRESS>who I happen to recognize as an active developer, but really have no reason to trust him beyond that.  His public key is not published in a manner that is easy to acquire: I had to attempt to verify the signature of a rkt release and then go rooting around in a key server to find the id.  Most recently, the filename of the detached signature changed from .asc to .sig, which broke my automation when I upgraded to v1.1.0
This is actually a problem with CoreOS as an organization.  etcd releases are signed by someone else.  fleet releases aren't signed at all.  For a company founded on such strong security principles, I find this confounding.
I would like to see CoreOS systematically adopt the methodology used by Hashicorp:

create an organizational GPG key
publish the GPG key, a la https://www.hashicorp.com/security.html
use the GPG key to sign all of your releases
use consistent filenames so I know I only have to change the version number

For example, here's a snippet I use to download and verify Vault, and the pattern works for Consul, Packer, and Nomad:
PRODUCT="vault"
VERSION="0.5.1"

curl -sfSLO https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_linux_amd64.zip
curl -sfSLO https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_SHA256SUMS
curl -sfSLO https://releases.hashicorp.com/${PRODUCT}/${VERSION}/${PRODUCT}_${VERSION}_SHA256SUMS.sig
gpg --verify ${PRODUCT}_${VERSION}_SHA256SUMS{.sig,}
egrep '_linux_amd64\.zip$' ${PRODUCT}_${VERSION}_SHA256SUMS | sha256sum -c

There is no such consistency for any of CoreOS' products.  rkt would be a good starting point.

#971, coreos/etcd#3472, coreos/fleet#1408

You're totally right.

Most recently, the filename of the detached signature changed from .asc to .sig, which broke my automation when I upgraded to v1.1.0

This was my fault, for some reason I signed v1.0.0 with .asc instead of the usual .sig as it's stated in the release guide, sorry about that.
Your methodology makes total sense, we'll discuss it and try come up with a good solution.
Thanks!

Thank you!

Thanks for pushing us on this, this is definitely something we have been slacking on for too long and for which we need a solution.

As an update: we have a plan in process and are working on proper distribution of keys etc. Next release should be signed by a well-known key.

👍

As of https://github.com/coreos/rkt/releases/tag/v1.2.0 releases are signed with https://coreos.com/security/app-signing-key/


Implement marker animation loop?

I work on an animation loop marker.
I cannot find the style that animates the marker.

There is no style for animated markers, but PRs are welcome.

@777CC Do you have examples of the kind of functionality you want in other components?


ExceptionLayoutRenderer - Added support for strange conversion from Exception-class to string-value

Scaler string value is no longer a key-value-pair-property, but just a simple value without key-name. Doesn't make sense to include in Properties-output.


Update retrieval/India parsing functions: (1) based on case schema changes; (2) to use the upsert API

 Update the India parser to the ~finalized line list schema


compatibility for dbt-core v1.6.0

Per the adapter maintainer upgrade guide for v1.6.0, this PR includes the following:
Bugs fixed:

Fixed a bug causing the dateadd macro to fail its tests when handling DATETIME type fields. The updated sqlite__dateadd.sql macro now adequately handles both DATE and DATETIME types per ISO-8601 and passes its tests now.

Changes made:
[BtS] Adapter zone tests

Added four new tests in test_utils.py and all tests passed without overrides.

No changes required:
[BtS] Drop support for Py 3.7

Support for Py 3.7 was already removed in dbt-sqlite 1.2.0rc1.

[BtS] new arg for adapter.execute()

We use SQLConnectionManager.execute() directly. No changes required.

No changes made:
[FEATURE] Materialized Views:

Materialized views are not supported in sqlite3. No changes made.

[FEATURE] dbt clone

Clone objects are not supported in sqlite3 because it is a simple in-process database.

[BtS] revamp of dbt debug

No new warnings or errors in tests. No changes made.

Possible remaining todo

Left out tests related to Contracts as they aren't being implemented as a feature. I had created a test and ran it only to see the test failed, which was expected, so the unit test needs to be overridden in order to make that passing criteria instead of failing.

Hi @codeforkjeff , here are my proposed updates for dbt-sqlite v1.6.0. Let me know if you'd like anything else here.
I will get to work on v1.7.0 next. We can still plan to deploy both together under 1.7.0 after 1.5.0 is out.

The commit history got messed up on my end. I'll resubmit a new PR with a simplified history.

Closing this PR -- new one opened here with a cleaner history.


Fix VS2017 project win32 config

For some reason win32 configuration was broken. There were no include paths and other stuff were just set to their defaults.

Thank you for your PR!


Enforcement e-mail missing from CONTRIBUTING.md

Easy to fix but worth addressing early on in the project. Located here.

The Code of Conduct has been split out of the Contributing into its own document., That new document does include email addresses.


fix: parse dml with returning as a query

Resolve issue #140
Fix a typo
Local test has passed:

I don’t feel we are doing this correctly. Consider using https://docs.rs/postgres/latest/postgres/struct.Client.html#method.query_raw instead of matching how many rows will be returned by finding keywords in the query statement.

Well, given we are using simple protocol here, probably the logic should be changed to:

If there is at least 1 row in the result set, return DBOutput::Row.
Otherwise, return CommandCompleted.

Which I guess could avoid matching the keywords.

I don’t feel we are doing this correctly. Consider using https://docs.rs/postgres/latest/postgres/struct.Client.html#method.query_raw instead of matching how many rows will be returned by finding keywords in the query statement. (For extended protocol)

Seems #142 can be fix together in this PR.


new Database ( incorrectPathToDB, { fileMustExist: true } ) does not throw error (while readOnly misspell does)

Unless I’m too sleep deprived and missing something obvious, I can’t find any logic to throw an error on incorrect DB file path (there’s only a partial check for directory existence "Cannot open database because the directory does not exist").
So the new class inst code proceeds to attempt to create a temp DB and look for a non-existent table inside. No error caught:
Does not work — no error caught
try {
  let db = new betterSQLite3( incorrectPathToDB, {
    readonly: false,
    fileMustExist: true,
  } );
}
catch ( error ) {
  console.log( 'Disaster. All is... Wait... we didn’t catch anything?' ) // not shown in the console
  console.log( error ); // nothing... silence
}

Proceeding to:
node_modules/better-sqlite3/lib/methods/wrappers.js:5
	return this[cppdb].prepare(sql, this, false);
	                   ^
SqliteError: no such table: test_table

Works — error caught
try {
  let db = new betterSQLite3( correctPathToDB, {
    readOnly: false,
    fileMustExist: true,
  } );
}
catch ( error ) {
  console.log( 'Disaster. All is lost. But we have the details:' )
  console.log( error ); // Misspelled option "readOnly" should be "readonly"
}

using the:
if ('readOnly' in options) throw new TypeError('Misspelled option "readOnly" should be "readonly"');

Related to:
#220

This works as expected for me:
const fs = require('fs');
const betterSQLite3 = require('better-sqlite3');

const incorrectPathToDB = 'nope.db'

try {
  console.log(fs.existsSync(incorrectPathToDB));
  let db = new betterSQLite3( incorrectPathToDB, {
    readonly: false,
    fileMustExist: true,
  } );
}
catch ( error ) {
  console.log( 'Disaster. All is... Wait... we didn’t catch anything?' ) // not shown in the console
  console.log( error ); // nothing... silence
}

> node index.js
false
Disaster. All is... Wait... we didn’t catch anything?
SqliteError: unable to open database file
    at new Database (/tmp/sql/node_modules/better-sqlite3/lib/database.js:51:26)
    at Object.<anonymous> (/tmp/sql/index.js:8:12)
    at Module._compile (internal/modules/cjs/loader.js:1068:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47

Maybe your path is an empty string and you're creating a temporary database? Turns out this is not documented that an empty string does that (it's SQLite behavior) https://github.com/JoshuaWise/better-sqlite3/blob/02c9c250bc77311b08bec574d3d40890c0b17256/lib/database.js#L33

@JoshuaWise arguably if(fileMustExist && anonymous) should throw because they contradict and are incompatible options?

I think if(fileMustExist && readonly) should also throw. Because if readonly is set, then fileMustExist is ignored
https://github.com/JoshuaWise/better-sqlite3/blob/02c9c250bc77311b08bec574d3d40890c0b17256/src/objects/database.lzz#L164-L166

Also can't reproduce this. As @Prinzhorn said, probably incorrectPathToDB is an empty string or undefined, both of which cause SQLite3 to open a new temporary database (which means whatever table you're trying to access doesn't exist, because the database is empty).

@JoshuaWise arguably if(fileMustExist && anonymous) should throw because they contradict and are incompatible options? Around here somewhere
https://github.com/JoshuaWise/better-sqlite3/blob/02c9c250bc77311b08bec574d3d40890c0b17256/lib/database.js#L39-L44

Perhaps that could be a helpful error message.

@Prinzhorn & @JoshuaWise — Yes, if path is passed through a incorrectPathToDB var which is undefined, causes the "creation of a new temporary database (which means whatever table you're trying to access doesn't exist, because the database is empty)".
Exactly. 😀
In my view, that’s not the behavior described by fileMustExist: true.
IMO:

at the very least — we’d want to log a Creating new empty DB message.
better — with the fileMustExist: true, we would need to throw an error in any case except correct file found. Using, as @Prinzhorn suggested:

fs.existsSync(str_PathToDB)

OK, I drilled in a bit further down my commits… it turns out it is rather an edge case.
To very quickly test a try/catch, I add an inline or outside + 1 to a param (which might mess JS truthy/falsy, var type etc). Somehow, here, it does not throw an error.
To reproduce:
const correctPathToDB = '/Users/johndoe/Applications/GoodApp/perfect.db'
const incorrectPathToDB = correctPathToDB + 1;

  console.log( `Incorrect path is: ${incorrectPathToDB}` );
  console.log( `Var type is: ${typeof incorrectPathToDB}` ); // string, passing a 'Expected first argument to be a string' check

  try {
    console.log( fs.existsSync( incorrectPathToDB ) );
    let db = new betterSQLite3( incorrectPathToDB, {
      readonly: false,
      fileMustExist: true,
    } );
  }
  catch ( error ) {
    console.log( 'Disaster. All is... Wait... we didn’t catch anything?' ) // not shown in the console
    console.log( error ); // nothing... silence
  }

This silently creates a /Users/johndoe/Applications/GoodApp/perfect.db1 and then complains about inexisting tables.
My suggestion, at a minimum: add a Creating new DB perfect.db1 message. That would help.

If you were able to reproduce the problem with a non-empty path argument, it sounds like this is a bug in your operating system. The fileMustExist option simply causes us to pass SQLITE_OPEN_READWRITE instead of (SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE) to SQLite's sqlite3_open_v2() C function. SQLite then converts those flags to filesystem flags. It looks like that's the part that's failing.

Woha! Thanks for the clear-up of the logic behind the fileMustExist option. Lemmy test from the SQLite command line tool when I get a second.
Meanwhile, would you be interested to add an if (fs.existsSync(str_PathToDB) ) check as @Prinzhorn suggested above? That would bomb-proof the arg even further and avoid relying on SQLite’s C interface.

好的，我在我的提交中更深入地研究了......事实证明这是一个边缘案例。
为了非常快速地测试 try/catch，我在参数中添加了内联或外部+ 1（这可能会弄乱 JS 的真/假、var 类型等）。不知何故，在这里，它不会引发错误。
重现：
const correctPathToDB = '/Users/johndoe/Applications/GoodApp/perfect.db'
const incorrectPathToDB = correctPathToDB + 1;

  console.log( `Incorrect path is: ${incorrectPathToDB}` );
  console.log( `Var type is: ${typeof incorrectPathToDB}` ); // string, passing a 'Expected first argument to be a string' check

  try {
    console.log( fs.existsSync( incorrectPathToDB ) );
    let db = new betterSQLite3( incorrectPathToDB, {
      readonly: false,
      fileMustExist: true,
    } );
  }
  catch ( error ) {
    console.log( 'Disaster. All is... Wait... we didn’t catch anything?' ) // not shown in the console
    console.log( error ); // nothing... silence
  }

这会默默地创建 a/Users/johndoe/Applications/GoodApp/perfect.db1然后抱怨不存在的表。
我的建议

添加一条Creating new DB perfect.db1消息……这将有助于理解沉默
为 DB 文件位置参数添加路径格式要求

就我而言，相对路径不起作用，我使用 Nodepath和url.
假设fantastic.db位于应用程序文件夹的根目录中：
import * as path from 'path';
import * as url from 'url';

/**
 * - The import.meta object exposes context-specific metadata to a JavaScript
 *   module. It contains the module's URL.
 * - url.fileURLToPath() converts a URL into a OS-independent absolute path
 * - path.dirname() returns the directory of a path without a trailing slash
 */
const correctPathToDB = path.dirname( url.fileURLToPath(
  import.meta.url ) ) + '/' + 'perfect.db';

try{
const db = new Database('D/todolist/foobar.db', {
readonly: false,
fileMustExist: true,
});
}
catch ( error ) {
console.log( 'Disaster. All is... Wait... we didn’t catch anything?' ) // not shown in the console
console.log( error ); // nothing... silence
}
is not work for me not foorbardb not create tables.

@JoshuaWise would love this to be solved?
i'm using better-sqlite3 with docker & its very confusing which folder does not exist.
i would love a better description of the error message than this one. having seen this error 100x today.

// Make sure the specified directory exists
if (!anonymous && !fs.existsSync(path.dirname(filename))) {
	throw new TypeError('Cannot open database because the directory ' + path.dirname(filename) + 'does not exist');
}

wouldn't this be enough here?


Another install issue

After installing curl:
i5 pihentagy # wget -qO- https://git.io/getlyp | bash
Detecting latest lyp version...
Downloading https://github.com/noteflakes/lyp/releases/download/v1.3.1/lyp-1.3.1-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   605    0   605    0     0   1030      0 --:--:-- --:--:-- --:--:--  1030
100 6735k  100 6735k    0     0  1710k      0  0:00:03  0:00:03 --:--:-- 2109k
Extracting /tmp/lyp-release-installer/release.tar.gz
Could not find rugged-0.23.0 in any of the sources
Run `bundle install` to install missing gems.

I updated the release files to remove the rugged dependency. Please check again and let me know if it works.

I will test this at my home PC. The newer issue reported just now occurred in another machine.

Reported as fixed in #43.

Yes, it worked on my home PC.


Toggle Properties Panel Errors When Toggling Error Panel

Notable changes:

all lint errors are shown in the properties panel
toggling the error panel toggles the properties panel errors
property panel errors are shorter versions of errors from error panel

Note that there is a lot of lining logic in the editor right now. This will likely change in the context of adding annotations to the canvas (cf. https://github.com/philippfromme/linting-playground).

Requires https://github.com/bpmn-io/properties-panel/pull/160
Requires https://github.com/bpmn-io/bpmn-js-properties-panel/pull/716
Requires https://github.com/camunda/linting/pull/7

For some reason, the macOS checks won't run. 😢 They are cancelled immediately.

After #3045, a rebase should make CI happy again.

One little thing to consider: I see a pretty nice example for a bunch of linting errors in the attached screencast. Should we maybe add this file to the project fixtures? It would maybe make it easier to test the whole linting feature.

You mean an example diagram that produces these lint errors?

Yes.

@pinussilvestrus I will include an example diagram. 👍🏻

I added an example diagram: https://github.com/camunda/camunda-modeler/pull/3014/commits/7cac249aed49df640258a726b892d1f90324f267


Remake reqmgr2ms-unmerged RPM and docker image

Impact of the new feature
ReqMgr2 (MSUnmerged)
Is your feature request related to a problem? Please describe.
Yes, this is tightly coupled to the instabilities seen in MSUnmerged: https://github.com/dmwm/WMCore/issues/10713
even though it's unclear whether the change requested here is going to make MSUnmerged more stable.
Describe the solution you'd like
Change our stack of software and how we install libraries such that we avoid the dependency on system python packages (installed via yum) with other libraries that get shipped with the reqmgr2ms RPM.
In short, there are two actions to be taken here:

change the reqmgr2ms.spec file such that it depends - on a new spec yet to be created - on a COMP gfal2-python package. See: https://github.com/cern-fts/gfal2-python/issues/2
IF Alan didn't mix up things and that's the correct library and it provides the required functionality to MSUnmerged, we should then change the reqmgr2ms-unmerged Dockerfile to avoid installing things over yum and juggling with PYTHONPATH.

Describe alternatives you've considered
It could be that gfal2-python in PyPI will require further dependencies, to be investigated.
Additional context
none

As just discussed with Todor, always persisting this information here.

create py3-gfal2-python.spec file, pulling the latest version from PyPi (cmsdist)
modify reqmgr2ms.spec to depend on this spec above
build these specs (comp) privately and upload it to your private repo (e.g. "--upload-user=$USER upload comp")
we might have to deploy these rpms in your private VM (gfal2-python3 is not needed!): https://github.com/dmwm/CMSKubernetes/blob/master/docker/reqmgr2ms-unmerged/Dockerfile#L13-L20
deploy these new packages in your VM (we only care about reqmgr2ms in the end...)
test MSUnmerged (well, test the new gfal2-python package)
we might want to hard code some test paths/files hardcoded in the service .e.g.

amaltaro@lxplus714:~ $ eoscms ls /store/backfill/1/RunIISummer16DR80Premix/MonoHtautau_Scalar_MZp-500_MChi-1_13TeV-madgraph/AODSIM

PS.: if we find issues - lack of dependencies - with the gfal2 plugins, we'd better contact the cern-fts team and see if we have a way to deploy those without the need of RPMs. Or even better, if we can pull/package gfal2-python WITH those plugins all bundled in.
PPS.: Once we are happy with the PyPi version of gfal2, we need then to rework this Dockerfile:
https://github.com/dmwm/CMSKubernetes/blob/master/docker/reqmgr2ms-unmerged/Dockerfile#L13-L24


Fix sleep wake spam

Only 1 code path checked the cooldown. Still not great but stops alt-click spam.

@metalgearsloth you almost had a merg


Valgrind reports uninitialized access in (print ...) functions.

Figure that out and kill it.

Something in the last couple of commits chased it away, valgrind now runs clean.


core.mem.swap has invalid type

Errors such as this one are generated:
error: ././././Verification/Extracted.lean:159:22: type mismatch
  core.mem.swap T self.value new_right_tree1.value
has type
  T × T : Type
but is expected to have type
  Result ?m.5620 : Type

I assume this may be related to the Lean backend cleanup.

Desynchronized Charon/Aeneas + Lean's library issue.


Feature/add metainfos to itemlist

adds some metainfos (channelname, views, duration, video title) to the sidebar in the directory listing on playlists, channel and subscription activity.

@apfelsprudel I'm excited to get this duration stuff working, but I notice that it only shows the durations for videos over one hour long.  I'd like to sort that out before merging.

Thanks, I missed this in testing and I am new to python, so I appreciate your hint. I wrote a fix.


No colors for Roles

However all instances of her don’t have a color for her role and the role isn’t editable.

Verify this works in PROD2. Once you approve we can close the bug.


Unable to delete columns using Schema Builder/Migration

Describe the bug
I am attempting to write a migration to delete a column. However, in testing, I receive previousError(SQLite only supports adding columns in ALTER TABLE statements.) when I attempt to run the migration, and the database is not updated.
To Reproduce
In reduced form:
struct Migration1: Migration {
    func prepare(on database: Database) -> EventLoopFuture<Void> {
        database.schema("my_table")
            .field("field", .double, .required)
            .field("other_field", .double)
            .create()
    }
    func revert(on database: Database) -> EventLoopFuture<Void> {
        database.schema("my_table").delete()
    }
}

struct Migration2: Migration {
    func prepare(on database: Database) -> EventLoopFuture<Void> {
        database.schema("my_table")
            .deleteField("field")
            .update()
    }
    func revert(on database: Database) -> EventLoopFuture<Void> {
        database.schema("my_table")
            .field("field", .double, .required)
            .update()
    }
}

Steps to reproduce the behavior:

Define the two migrations above and attempt to run them in order.

Expected behavior
The end result for the table "my_table" should be a schema of a single column named "other_field".
Environment
Grabbing relevant sections from my Package.resolved:
     {
        "package": "fluent",
        "repositoryURL": "https://github.com/vapor/fluent.git",
        "state": {
          "branch": null,
          "revision": "855cd81cd129675dcb9adadeca2286281dbc0190",
          "version": "4.1.0"
        }
      },
      {
        "package": "fluent-kit",
        "repositoryURL": "https://github.com/vapor/fluent-kit.git",
        "state": {
          "branch": null,
          "revision": "86ebecdb98981b7a242746209b4335770bf0bd11",
          "version": "1.10.2"
        }
      },
     {
        "package": "fluent-sqlite-driver",
        "repositoryURL": "https://github.com/vapor/fluent-sqlite-driver.git",
        "state": {
          "branch": null,
          "revision": "6f29f6f182c812075f09c7575c18ac5535c26824",
          "version": "4.0.1"
        }
      },
      {
        "package": "vapor",
        "repositoryURL": "https://github.com/vapor/vapor.git",
        "state": {
          "branch": null,
          "revision": "5148f02e42149f73f6616452062cf96b64afbda6",
          "version": "4.36.2"
        }
      }

Vapor Framework version: 4.36.2
Vapor Toolbox version: Unknown; vapor --version yields Error: Unknown command '--version'
OS version: macOS 11.2.3; Xcode 12.4 (12D4e)

brew list--versions vapor says I have vapor 18.0.0 as the Toolbox version.

@grey280 as the error states, SQLite does not support deleting a column. In fact, judging by StackOverflow it's simply not possible to delete a column in SQLite. The workaround is to create a new table without the column you want to delete and copy all the data over. Unfortunately that's a little out of scope for Fluent as it doesn't have all the information it needs with just the .deleteField("field") call so you'll need to write a raw SQL migration.
As an aside, the latest toolbox is 18.3.1 so make sure you update to that. You might need to remove the Vapor tap to be able to see it


Add create_before_destroy for Customer Gateway resources

Description
When you try to change the IP for a customer gateway resource, following error is encountered:
Error: error deleting EC2 Customer Gateway (cgw-abcde): IncorrectState: The customer gateway is in use. status code: 400, request id: 1234xyz
I think adding a create_before_destroy to the customer gateway resource should fix it.

Since the aws_customer_gateway resource creation is happening outside of this module, you can do it easily.
But i agree it would make sense to extend the examples with the lifecycle attribute, and a comment why it's necessary.
i've changed one of the examples with the following, and worked as expected:
resource "aws_customer_gateway" "main" {
  bgp_asn    = 65000
  ip_address = "<IP_ADDRESS>"
  type       = "ipsec.1"

  tags = {
    Name = "complete-vpn-gateway"
  }
  lifecycle {
    create_before_destroy = true
  }
}


Uncaught Error: ENOENT,  not found in /Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/a...

[Enter steps to reproduce below:]

...
...

Atom Version: 1.0.0
System: Mac OS X 10.10.4
Thrown From: Atom Core
Stack Trace
Uncaught Error: ENOENT,  not found in /Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/atom.asar
At /Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/src/workspace.js:466

Error: ENOENT,  not found in /Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/atom.asar
    at createNotFoundError (ATOM_SHELL_ASAR.js:101:13)
    at Object.module.(anonymous function) [as open] (ATOM_SHELL_ASAR.js:156:25)
    at ReadStream.open (fs.js:1668:6)
    at new ReadStream (fs.js:1655:10)
    at Object.fs.createReadStream (fs.js:1610:10)
    at File.module.exports.File.read (/Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/pathwatcher/lib/file.js:286:27)
    at TextBuffer.module.exports.TextBuffer.updateCachedDiskContents (/Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1027:61)
    at TextBuffer.module.exports.TextBuffer.load (/Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1046:19)
    at Project.module.exports.Project.buildBuffer (/Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/src/project.js:456:21)
    at Project.module.exports.Project.bufferForPath (/Users/BesmondFoong/Downloads/Atom.app/Contents/Resources/app.asar/src/project.js:431:63)

Commands
     -0:52.5.0 window:install-shell-commands (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "archive-view"
    ]
  },
  "editor": {
    "invisibles": {}
  }
}

Installed Packages
# User
No installed packages

# Dev
No dev packages

Thanks for the report -- seems to be a duplicate of https://github.com/atom/atom/issues/6140.


Add lazy date_lut, similar to clickhouse-driver

Fixes issue identical to one in clickhouse-driver, PR changes identical to one in clickhouse-driver too

TY)


How to scroll to bottom?

I was chatting inside loaded several pages of data, trigger scrollToBottom method only rolled to the bottom of the current page. How to make it scroll to the bottom of the entire message list?

@jieatgstdev Are you using SlidingDataSource from the demo app or similar approach? If yes then it's not available out of the box.
What you can do:

Adjust your data source to provide messages from the current page to the most bottom
Trigger an update
Scroll to the bottom when the update is finished.

The thing is that currently there is no callback available at the end of the update, so you don't know when step 2 is finished. Fill free to add it to the framework.
You can try it, or implement some other solution.


[QUESTION] How to deal with volumes that point to the wrong head?

Question
I have a node that stays at home and sometimes the internet get somewhat unstable to the point where longhorn gets a bit shaky. After a few rounds fixing a few volumes that I had to manually run fsck on the .img files, I got to a stable point, but only one of the modules are pointed to the wrong head.  Should I simply edit volume.meta to point to the right one?
If you check the following image, you see that the snapshot that starts with 4a91 is the right one and the others do not have anything that points to it.

and on the UI the right one shows as deleted as you can see here (so close but so far)

Environment:

Longhorn version: 1.2.0
Kubernetes version: k3s v1.22.2+k3s1
Node config

OS type and version: Ubuntu 20.04.3 LTS
CPU per node: 16
Memory per node: 24
Disk type: ReadWriteOnce Block Device
Network bandwidth and latency between the nodes: still figuring out mtu problems between home and main servers on the cloud

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): home is a baremetal and cloud a provider (contabo with a lot of cpu steal)

Additional context
Let me know and I can upload the pack encrypted to age to your public keys on github

Related to #685

I'm going to close this issue, feel free to reopen it if there is any other question, thank you.


Migrate to ES6 modules

It will be great if we can migrate to ES6 modules like three.js did so the end user can take advantage of Webpack2/Rollup's tree shaking feature.

whom do you mean by "we"?

@buzzdecafe I am just suggesting here xD feel free to close this issue if you don't like it

The problem for now is that Ramda is also available as individual modules.  You can simply do
const map = require('ramda/src/map');

, soon to be replaced with just:
const map = require('ramda/map');

I don't see any way to maintain that -- which is important to a number of people, still, and switch to a Rollup-built ES6 module format.  If this actually is possible, I'd really like to know!

Out of curiosity, what is the benefit of doing
const map = require('ramda/map');

vs
const map = require('ramda').map

I can only think of reducing bundle size but I don't think that would be relevant when using it on nodejs like this?

Regarding having the original code as ES6 modules and still being able to have separate commonjs modules I think there are several ways to do that. One way would be to use this function in babel. The idea is to write the modules in ES6 and have babel transform them to commonjs. If the transform is applied on a per file basis I think it should be possible to require the resulting commonjs files separately like today.

I would not at all mind seeing a demonstration of these ideas if you're interested in creating a PR.
I don't know what the benefits are, except that I know a number of people do seem to want this.

I did a small POC in #1977. Only src/add.jshas been updated to use es6 style export. If the concept is accepted I could rewrite all to this style.

@CrossEye About the benefits of proper build for rollup/webpack 2. You can continue to import ramda like this:
import {map} from 'ramda'

And with rollup/webpack 2 it will work like this (roughly), because if tree-shaking:
import map from 'ramda/src/map'

So you actually bundle only the things that you import (and use).

Here follows some speculation on the need to have commonjs modules that are importable as separate files. If you are doing this in your application:
const map = require('ramda/map');

Then you are probably doing it for a reason. The only reason I can think of is that you want a smaller application bundle. So if that is true, given that bundle size probably is not a concern on the server-side, you are building something for the browser. But you are using commonjs-style require which cannot run in the browser. This implies that you are using a bundler that can handle converting this down to es5 (like webpack or jspm). Now since you are already using a bundler that is capable of converting different formats of imports/require you could be doing (as @faergeek pointed out above):
import {map} from 'ramda'

And you would not have to change your tool-chain since your bundler already supports this. And if you are using webpack 2 or rollup, your application bundle would automatically exclude everything except what is needed to run the map function.
So if all my speculation is true, then I don't think there is a high demand for a folder with separate commonjs module files. But as I said this is all speculation since I don't know the reason for wanting separate commonjs files.

BTW, I don't understand what's the problem to have both ways.

@faergeek You mean having both a folder with separate cjs files and the original src folder with es6 modules? No problem. My PR currently supports both ways :-).

@jonaskello I didn't look at it yet. But main concern here that I see here from @CrossEye is that import map from 'ramda/src/map' should still work as before. And I just don't see the reason it will not :-)

Aha, yes that would of course work. I thought @CrossEye wanted the old style commonjs require to work as before. As in const map = require('ramda/src/map'). To that end my PR creates a cjs folder with commonjs format from a src folder with es6 module format.

@jonaskello so you just need to move existing src folder to es6 or something like that, then run babel es6 --out-dir src. Then do things inside es6 using rollup or whatever :-) Paths should be saved as they are now I think, that's the concern.

Exactly, so what my PR does is this: babel src --out-dir cjs --copy-files. Then someone wanting to use the old style cjs require could do this: const map = require('ramda/cjs/map').

@jonaskello People are already use const map = require('ramda/src/map'), but you want them to rewrite it to const map = require('ramda/cjs/map') in future, that's not good :-). Everything else is ok I think

Agreed, breaking compability is not good. OTOH if you look at @CrossEye comment above:

, soon to be replaced with just: const map = require('ramda/map');

So I think the idea is to remove directly importing from ramda/src/* anyway. Could it be done in a way so we don't need to have the cjs files directly under ramda?

@CrossEye Could you explain how you wanted to transition users to short paths?

My thought -- before we started talking about changing module formats -- was that in the preparations for an NPM publish we would simply copy the relevant information from our main folders to a temporary publish folder.  The src folder would copy directly to the root, though.  Then we'd publish from there and delete this temporary folder.  For a transitional period we might also publish the src folder as well, but that's a minor concern.

Makes sense, and that approach would work with the PR too, only instead the cjs folder would be generated and then copied to the root of the publish folder.

Hi guys,
Just to be sure, tree shaking is not possible with commonjs modules as it uses static analysis which only es6 modules provide (by the spec). Only dead code elimination can be applied to commonjs modules, but it's far from ideal.
A good example on how to set this up with a minimal effort is d3.

fyi - since ramda uses currying everywhere, rollup has a hard time treeshaking efficiently.
Here's a small example using module'ified ramda code that shows 'F.js' will be bundled whether or not it's imported.
The fool-proof bundling approach seems to be how babel-plugin-ramda goes about it e.g.
// this
import { add, map } from 'ramda';

map(add(1), [1, 2, 3]);

// into
import add from 'ramda/src/add';
import map from 'ramda/src/map';

map(add(1), [1, 2, 3]);

@olsonpm when I remove export { default as F } from './F'; from ramda.modules.js, it does not get bundled. What am I doing wrong?

I think you're misunderstanding the example.  ./F.js should always export its module.  The problem is that because it calls a curried function, rollup detects it as possibly causing a side-effect and thus doesn't tree-shake it off.
The whole point is to show that tree-shaking sounds great in theory, but is not sufficient in-practice which is why Rich Harris is trying to find a better way to detect unused code.
Here's a simpler example to show the same concept using non-ramda code
And finally here's that same example without the factory, showing the tree-shaking working as expected

right! yes, it makes sense (sorry didn't catch it the first time is already late in here). Luckily, ramda is super structured so we would have options.

Not a problem - I'm not the greatest at explaining things in general -.-
And yeah if you want to see the bundle sizes in practice, you can clone my ramda branch "es6-module" to see what a single
import { add } from 'ramda'

does after rolling it up.  It's not pretty.

Since tree shaking is not possible because of currying, the only hope to tree shake would be if annotations landed: https://github.com/rollup/rollup/issues/1293 https://github.com/mishoo/UglifyJS2/pull/1448

Annotations would allow it, yes.  Personally I don't think it's a great cost/benefit considering a plugin can achieve the same result.
I was happy to read jdalton's comment

Btw, I'm taking Lodash in a different direction for v5 (just started working on it). In v5, the traditional lodash package won't ship with a monolithic build. Instead it'll enforce the cherry-picked form,require('lodash/forOwn'), as the default

Seems like the most reasonable route given the current tooling available.

I made a quick hack script that converts Ramda to support Rollup and UglifyJS2 __PURE__ annotations: ramda-rollup-hack.  Works fine in my test project and reduces bundle size (roughly half of Ramda is dead code eliminated after running the script).  You could also adapt the script to Ramda's build to publish Ramda with Rollup support.

Thank you very much.
I look forward to investigating this.  Hopefully this evening.

I still find it unfortunate that future javascript code may be littered with comment annotations - but if it serves a good purpose then I guess I'm okay with it haha.
Thanks much for putting that together.

@olsonpm Yes, I totally agree that having to use such annotations is unfortunate.  However, I find that the combination of Rollup and UglifyJS2 with /*#__PURE__*/ annotations allows library authors (like myself) to author "rich" libraries that are easy (well, as easy as using Rollup) to consume without having to pay for unused features.  At least for me it would be even more unfortunate to have to continue to be extremely conservative about adding useful helpers to libraries.

Yeah it's easier, but the alternative route lodash went is only slightly less convenient.

I haven't looked at in detail what lodash does, but the way Rollup eliminates the module overhead completely is really important.  It doesn't just help to eliminate unused stuff, but it also eliminates indirections (modules disappear) and then tools like UglifyJS can do a better job.  If lodash just allows you to separately import commonjs modules it will likely lead to bigger bundles and worse performance with additional indirections.

lodash's method is in coordination with a bundler, so I think you're misunderstanding.  Not a big deal though - this annotation is certainly providing sought-after functionality.

@CrossEye I'm wondering if you've gotten a chance to work on this; or if progress is made somewhere publicly (I dont really see a PR or a branch).

@dashed I did a small POC in #1977 but I don't know of any other work going on.

So the whole point of the tree shaking is to be able to do something like
import { add } from 'ramda';

and for a tree-shaker to eliminate all other ramda utilities.  I haven't played around with the __pure__ anotations yet, but it's possible even those don't meet the above goal.
Until the above goal is able to be met, I don't see any benefit to es modules.

@dashed: I'm afraid I've done nothing.  A PR would be welcome.

So I finally took the time to learn more about this /* #PURE */ annotation and have a working ramda repo with all the necessary annotations.
If you want a feel for how it diff'ers from just es modules without the annotations, here's my es-module branch
And finally an example repo reaping the benefits of the annotations.  Note it takes multiple uglifyjs compression passes to achieve the fully minified results.
I still don't think it's as nice a solution as the plugin - but feel free to fork and tinker to your liking.  It works as expected.

Just trying to clarify if my understanding is correct.
There are at least two issues related to creating a minimal app bundle, i.e., one that only includes code that is actually  used by the app.

Leverage ES2016 modules (i.e. import/export) that, through static analysis, enable a bundler to only include  those dependencies that are actually used (aka  tree-shaking). This is what plugins such as rollup-plugin-lambda and https://github.com/megawac/babel-plugin-ramda help achieve (it's worth mentioning that this is possible because Ramda code base if so beautifully completely modular)

Due to the very dynamic nature of JavaScript, tree-shaking ES2015 modules may still include large swathes of unused code consisting of function calls that can't be proven to be side-effect free. When using Ramda, we typically create lots of small functions by calling other functions. So we need a way to specify when a function call is side-effect free. This is where  the uglifyjs2 /* #__PURE__ */ annotations come into play.

@olsonpm if I understand correctly, the lodash approach you mentioned above only seems to address point 1.
OTOH @polytypic's very cool hack above seems to address both point 1. and point 2. in the way that's completely transparent / compatible with the current release of Ramda.
Am I missing something:?

Has anyone considered prepack in addition to tools like webpack and uglify2 (or babili)?

@dashed - I don't see how that's related to es module migration.
@teehemkay

tree shaking just via static analysis of imports/exports does not work in practice.  Detecting side effects is simply too difficult to produce expected results (just look at rollup's issues labeled 'treeshaking', which is probably a 4th of the issues that are actually related to treeshaking.  Webpack2 is no better).
it seems rollup-plugin-lambda and babel-plugin-ramda aim to do the same thing babel-plugin-lodash does.  The logic behind those solutions is the following:

Take for instance my es'ified ramda index.js file.  Its job is to re-export all the ramda modules (lodash-es has the same concept).  This means any imports that are supposed to be analysed via tree shaking import { add } from 'ramda' now have to dig through all the code in index.js and determine whether any of it produces side effects.  Because tree shaking is hard, this doesn't work and includes a ton of code as a result.  So the transformer plugins say "that obviously doesn't work, so let's forego analysing 'index.js' and just modify import { add } from 'ramda' to import add from 'ramda/src/add'.  Now rollup only analyses the add module, which is what we wanted anyway.
Hopefully that clears some things up - though honestly the best way to understand would be to play around with some code.

@olsonpm Thanks for the clarification.

Uglifyjs2's /* #PURE */ annotation allows for an alternative to the transformer plugins

I came to this thread from rollup/rollup#1354 which lead me to conflate two different problems, one of which has nothing to do with the current thread. I'm sorry for the added confusion.
The two problems are conflated are:

Minimizing the amount of Ramda's code that's bundled with an app.
Imagine that you used Ramda  to write three modules. A module common.js that both module a.js and module b.js depend on but for different bits of common.js. Without, uglify /*#__PURE__*/ annotation all the functions / variables exported by common.js that where created by using calling Ramda side-effect free functions will be will be included in the bundles for a.js and b.js even if they are not actually used there.

Point 1. can be solved either by the plugins or by uglify annotation. The plugin option seems cleaner (and probably faster). But it only works because––as already mentioned––Ramda code base is beautifully modular. But the plugins are only concerned with minimizing the Ramda code.
But the annotation also works for any code (even code that is not as modular as Ramda).  And it is particularly handy for the typical, side-effect free code that Ramda allows us to write.

@teehemkay

But the annotation also works for any code (even code that is not as modular as Ramda)

Kinda.  The problem is that you will either

Have to write your code to be more modular and then write a transformer plugin to help the bundler. or
Add pure annotations in your code to achieve the same result.

I'm biased toward 1.  I can only see 2 being useful in existing code bases where refactoring to be more modular is difficult and not worth the effort.  If you can think of a scenario where annotations are useful otherwise I'd be interested in hearing.  Also - maybe we can continue this on your original issue.

@teehemkay @olsonpm The Babel plugin approach only works if you basically write one function per module.  That is not how I want to structure my libraries and applications.  I'm also not particularly fond of the idea that libraries would come with an associated Babel plugin.  YMMV.
Note that a Babel plugin that transforms import {foo} from 'bar' into import foo from 'bar/src/foo' is not generally safe: import 'bar' may have side-effects.  So, basically, a Babel plugin that performs such a transform essentially does the same kind of hack (assumes no side-effects and performs unsafe optimization) as the /*#__PURE__*/ annotations are doing.
(Speaking of structuring code.  For historical reasons most of my JS libraries are currently single file, which I don't consider as ideal either.  In the future I may structure libs as multiple modules because a bundler like Rollup can eliminate the module overhead conveniently.)
Also, splitting code into multiple modules so that there is just one function per module does not make the code fundamentally more modular.  It just means that you have a lot more source files to manage and most tools will be less effective on your project.  For example, it becomes a bit more difficult to see which definitions are unused (with a single file, a simple tool like eslint can tell you when a top-level function is unused).

The Babel plugin approach only works if you basically write one function per module
My understanding is the approach works if all the code associated with a module is included in that module.  That's hardly limited to one function.

@olsonpm If you have a module that exports more than one thing and you might only use a subset of those things then plugin approach will not eliminate the unused things.

At any rate, my only interest is to have a future Ramda that can be properly dead code eliminated.  The ramda-rollup-hack I made works for me now, but I do consider it as a temporary hack.  I don't particularly care whether Ramda uses the one export per module approach with a Babel plugin or something else.  Though... I don't particularly like the idea that in the future every library would come with a Babel plugin (shudder).  The Rollup + /*#__PURE__*/ works well enough for me.  (It would be nice if one could conveniently mark functions as pure rather than have to mark function applications as pure.  It might even allow for some tools to give more useful warnings.)

@polytypic - you're suggesting a tree-shaker that has not been created yet and probably never will due to complexity.  This is the whole reason the pure annotation exists, to allow developers a manual means of declaring side effect free code.
To give an example, let's say a module math exposes two functions 'add' and 'subtract'.  Let's say the 'math' module is exposed by ramda.
// math.js
export function add(left, right) { return left + right; }
export function subtract(left, right) { return left - right; }

// ramda.js
export * as math from './math';

As a consumer I'm expecting a magical tree shaker to turn this
import { math } from 'ramda';

console.log(math.add(1, 2));

into this
function add(left, right) { return left + right; }
console.log(add(1, 2));

The problem is that approach doesn't work in practical code bases as proven by the rollup and webpack2 issues related to tree shaking.

It would be nice if one could conveniently mark functions as pure rather than have to mark function applications as pure

This can't be done without being able to track function references.  Uglifyjs2 has an option pure_funcs which allows you to mark certain function names as pure.  I can't think of a great use-case for it, but I'm sure there is one given it exists.

@olsonpm  This can't be done without being able to track function references.

Yes and no.  First "no":  It would already be useful to have tools be able to positively determine where an export like
export const curry = fn => ...

is used and I believe that is one of the intentions behind the new module system, because a const export like that cannot mutated (AFAIU — I haven't read the JS spec in detail).   Marking curry as "pure" could then allow such a tool to further determine that a definition of add like
import { curry } from 'curry'
export const add = curry(...)

can be safely eliminated as long as add is not referenced anywhere.  This kind of "tracking" can be done quite easily given the guarantees that JS modules now give you (again AFAIU as I still haven't read the spec in detail and I don't plan to do so in the near future).
Now "yes": Being able to further effectively track aliases of curry (in order to more effectively apply dead code elimination and other optimizations) requires more sophisticated algorithms, but even those are well established techniques in optimizing compilers.
(BTW, I've have actually written a couple of compilers, including a simple optimizing compiler (based on CPS transform and optimizations in CPS form) for a simple ML style programming language.)

@polytypic Just FYI, even a mutable variable like export let curry = fn => ... can't be mutated by other modules, it can only be mutated in the module where it is defined.
So it's possible for a tool to detect when a variable isn't mutated and treat it as const
Babel automatically does this analysis, so it's very easy to detect whether a variable is mutated or not.

@polytypic - you keep mentioning very contrived examples which of course work.  The problem is library authors are having a very difficult time making these methods work with practical codebases that developers want the functionality for.

@olsonpm I'm not sure what you mean.  I'm both a developer and a library author myself and the Rollup + /*#__PURE__*/ annotation would have worked nicely in the previous production project I worked on.  That project was originally bundled with Browserify, but I later made a PR to convert it to Rollup. It reduced bundle size significantly and also had the desired dead code elimination properties. unfortunately for that project it was too late to make that switch into production. That project has been handed over and they don't want to make such changes at this point (the bundle size is not really a problem in that project).
Note that perfect dead code elimination is undecidable (it is easy to reduce to the halting problem).  This means that any approach to dead code elimination is going to be an approximation and will miss some cases.  That doesn't make simple and fairly easily understood methods I've outlined above useless.
I also disagree that my examples would be contrived.  The curried add example is pretty much precisely what the Ramda codebase is doing everywhere.  Having an effective solution for that would be very useful.
At any rate, I don't see this discussion going anywhere.  I believe I have said what I wanted to say: Rollup + /*#__PURE__*/ is an effective approach.  I'm using it in my libraries and have tried it with a production project where it also proved effective.  I also don't particularly care how Ramda will ultimately allow for proper dead code elimination, but I hope that it will soon do so.  If you must attempt to prove me incorrect, please do so without notifying me.

I think its worth mentioning that webpack is working on handling pure-module in package.json.
That still won't do good by everyone as its webpack specific for now, probably other bundlers will adopt it too over time though.
@kedashoe
I understand this is not a priority for you (ramda) right now as you are focused on pushing v1 forward. It shouldn't be too hard to get an outside contribution for this issue as its kinda a hot topic in the community, I can offer such help too ;) .
I think the only thing blocking this is establishing what should be done though. I've lately investigated and got to know this topic quite well while working on various libs and IMHO the best what can be done to satisfy everyone without much maintenance burden is:

have library written with es6 modules (include in git), specify its index.js as module in package.json
build commonjs directory (git ignore it but specify it as main in package.json) as prepublish step and publish both directories to npm
probably hoist commonjs directory content (or create proxy modules to commonjs) into the root to allow 'cherry-picking' with i.e. ramda/map - this still could be used by many with babel plugin to ease cherry-picking
mark all top level function calls (mostly calls to curry in ramda) with /*#__PURE__*/ magic comment
bundle UMD (dist/ramda.min.js) build with rollup, its use of scope hoisting and all makes it the best choice

I think @std/sem may be relevant in this discussion too. Seems lodash is going that way. I haven't had any time to try it myself yet though.

Hm, dont think its that much relevant in this discussion. From what I understand it somehow acts as an alternative module loader in node, it will certainly allow people consuming es modules, but lets face it - we (community) need to support both styles for the foreseeable future and it doesnt really matter HOW es modules will get loaded (i.e. by @std/esm).
What matters is that we have so many different tools in the ecosystem and they wont be unified any time soon and for the best developer experience we should do our best to support both styles at the moment.
Nevertheless @std/esm is great! :)

I agree with the above approach if something is to be changed today. Have ESM as base and then build a CJS version and publish both to npm, indicating in packa.json the index.js of each. Possibly add a UMD package. This is what I currently do.
However I think times will change, and I'm just thinking out loud here, so please feel free to correct any false assumptions. The two targets you can build for are the browser or node.
If you build for the browser you cannot use the CJS version unless you are using a bundler like webpack. However most (all?) bundlers support ESM natively today so you can just use that instead. So CJS is not needed for the browser target. (Global build may be needed not sure if anyone uses that anymore?)
If you build for node, then you can use the CJS version directly. However, going forward, with @std/esm you can use the ESM version directly instead. So in the near future a CJS version is not really needed here either.
So I guess what I'm thinking is that the audience for a CJS version is becoming smaller for each month and the importance of having an ESM version is becoming greater.

Also I'm under the impression that the library author could have only an ESM version, require std/esm in the library, and it would be transparent to the consumer of the library that there is no CJS version but maybe that is not true.

@jdalton posted an article on planning to use some new @std/esm thing to redo ES builds on Lodash. I haven't found a related thread over at Lodash on this, but it sounds like he knows what he's doing there. Maybe also relevant for @Andarist's current attempt to tackle this at #2254.

Yes, @std/esm would be really nice 👍 . That way we could get both ESM and CJS support without using rollup or babel. However I'm not sure @std/esm is ready for production just yet. Also if global build is needed then something like rollup is still needed. Having the original modules in ESM format is a requirement for using @std/esm. So I think the work at #2254 is useful as a first step that can be released today, and then later it can be simplified once @std/esm is ready for production.

So it seems that we have many people interested in this here, following this thread, if you want to help out with testing you can check this out:
npm install ramda@es-rc

@bahmutov I'm not getting that error using rollup (haven't tried any @std/esm stuff), however it is not actually tree shaking for me. If anyone has got it working could they post a sample rollup.config.js, package.json and input file?

@kedashoe
you didnt get tree-shaked output bundle because #__PURE__ comments are uglifyjs specific.
https://github.com/rollup/rollup/issues/1354#issuecomment-301292353
https://github.com/rollup/rollup/issues/1293
Ive created a simple example bundle:
import { add } from 'ramda'
export var getTwo = function () {
  return add(1, 1);
}

Ive used rollup-plugin-uglify. Results are way better - many things are getting tree shaken, but still some dont. Ive investigated whole output and written down 'dependency graph'. In general what Ive noticed is that any of those could be tree shaken:

_Set, XAll, XAny, XAperture, XFilter, XMap, XWrap, XReduceBy, XTake, XTakeWhile, XTap, XDrop, XDropLast, XDropLastWhile, XDropRepeatsWith, XDropWhile, XFind, XFindIndex, XFindLast, XFindLastIndex

Because they use a constructor pattern, in example:
function XAny(f, xf) {
  this.xf = xf;
  this.f = f;
  this.any = false;
}
XAny.prototype['@@transducer/init'] = _xfBase.init;
XAny.prototype['@@transducer/result'] = function (result) {
  if (!this.any) {
    result = this.xf['@@transducer/step'](result, false);
  }
  return this.xf['@@transducer/result'](result);
};
XAny.prototype['@@transducer/step'] = function (result, input) {
  if (this.f(input)) {
    this.any = true;
    result = _reduced(this.xf['@@transducer/step'](result, true));
  }
  return result;
};

I believe that those are not tree shakeable right now, because of the assignments to the prototype - the same thing happens to transpiled (by babel) es6 classes. Although they are easier to tree shake, as babel generated classes are contained in IIFEs, but the IIFE is not marked as pure at the moment. Related - https://github.com/babel/babel/issues/5632
Those mentioned exports ofc cause other things to be left out in the bundle as they reference them, i.e. this casquade:
_Set uses internal hasOrAdd which references _contains which in turn references _indexOf.
We can fix this by wrapping those usages of prototype in IIFEs and marking them as pure. Ive confirmed that when Ive wrapped them quickly like this my bundle got reduced A LOT.
This is my final bundle:
!function(global, factory) {
    "object" == typeof exports && "undefined" != typeof module ? factory(exports) : "function" == typeof define && define.amd ? define([ "exports" ], factory) : factory(global.MyBundle = {});
}(this, function(exports) {
    function _isPlaceholder(a) {
        return null != a && "object" == typeof a && !0 === a["@@functional/placeholder"];
    }
    function _curry1(fn) {
        return function f1(a) {
            return 0 === arguments.length || _isPlaceholder(a) ? f1 : fn.apply(this, arguments);
        };
    }
    function _curry2(fn) {
        return function f2(a, b) {
            switch (arguments.length) {
              case 0:
                return f2;

              case 1:
                return _isPlaceholder(a) ? f2 : _curry1(function(_b) {
                    return fn(a, _b);
                });

              default:
                return _isPlaceholder(a) && _isPlaceholder(b) ? f2 : _isPlaceholder(a) ? _curry1(function(_a) {
                    return fn(_a, b);
                }) : _isPlaceholder(b) ? _curry1(function(_b) {
                    return fn(a, _b);
                }) : fn(a, b);
            }
        };
    }
    var add = _curry2(function(a, b) {
        return +a + +b;
    }), pad = ("undefined" != typeof Symbol && Symbol, function(n) {
        return (10 > n ? "0" : "") + n;
    });
    Date;
    exports.getTwo = function() {
        return add(1, 1);
    }, Object.defineProperty(exports, "__esModule", {
        value: !0
    });
});

The only weird things left out in the final bundle which are not supposed to be there:

var pad
Date constructor

They seem to be some leftovers of _toISOString but I dont know why they are left out in the bundle like this. This is a minor thing though.

It is my understanding, from following @polytypic , that a second pass through uglify-js can yield additional tree-shaking.

Uglify dead-code elimination discussion here and here.

@kurtmilam I believe so too. I would like to understand the logic behind DCE a lot better though. Somehow I feel a little bit anxious when applying tools I do not understand to my projects, fearing subtle bugs or something ;)

New release candidate published, same command to install:
npm install ramda@es-rc

@olsonpm Your links to Rollup examples don't seem to be working anymore?
I'm very interested in understanding why currying precludes tree-shaking in Ramda. Seems to me a clear case of having a good dependency tree?

Its not that currying precludes it - its every function call at the top level of the file that precludes it. Minification process cannot guarantee that the function call is not producing any side-effects and cannot be sure that it is safe to remove it without changing the code's behaviour. I hope my other comment explains it in more details. If you have any other questions - please ask.
You can try to install ramda@es-rc and report back if it tree shakes (when using rollup + uglifyjs or webpack2+ + uglifyjs) correctly now.

I think I understand, but I'll look more into it.
I can't get it to tree shake as of today, but I also think the /*#__PURE__*/ hack isn't worth it. Compiler comments is a slippery path.

I can't get it to tree shake as of today

what do u mean?

I simply mean that whichever way I include Ramda (except the "ramda/src/map" method), the bundle size stays the same (I believe it's around 30 kB).

Have you installed ramda@es-rc instead of the latest from npm?
Could u share ur repository?

@drexkdal - the root issue is

tree shaking is hard and thus only works against very simple code (not the large, complex libraries you want it to work for)
more robust solutions such as the route lodash went (my personal preference) and this "pure" annotation are not ideal.

@Andarist - by wrapping all top level functions in a pure directive, you're not tree-shaking anything.  you could produce the same result using es5 imports.

Yes, I have. Sorry, big closed source project :/

@olsonpm I understand that tree shaking is hard, I just think that I library of small utility functions should be the ideal case for it.
I'd like to hear your comments in regard to applying currying as a helper inside each top-level function rather that as a call to a separate function transforming them.

by wrapping all top level functions in a pure directive, you're not tree-shaking anything.

Its not tree shaking library, but rather allowing tree shaking for the consumers of the library.

you could produce the same result using es5 imports.

Aint sure if I follow. Did you mean cherry-picking paths instead of accessing exports from the R itself?

Sorry, big closed source project :/

Could u try to reproduce your issue on separate repository which you could share with us?

Andarist - No, I mean you could use es5 imports, run browserify to bundle the app (which doesn't tree shake) then run uglifyjs for DCE, and the pure directives will allow all the same code to be removed.  You would end up with the exact same small bundle - I could show you an example if that would help.

I'd like to help, but I just can't find the time for something like that. I'd also like to understand your strategy for enabling tree shaking better first :)

applying currying as a helper inside each exported top-level method rather that transforming the method via passing it to a separate function at module load time.

Not sure what you mean here.  A code example would help me understand.

I have a feeling that on a general level, all calls that are blocking tree shaking could be somehow "inverted" to support it. Just one of those things.... Feels right from a pseudo-computation theoretical perspective.

Nah - Rich and JDalton already tried that

Andarist - No, I mean you could use es5 imports, run browserify to bundle the app (which doesn't tree shake) then run uglifyjs for DCE, and the pure directives will allow all the same code to be removed. You would end up with the exact same small bundle - I could show you an example if that would help.

That would certainly help!

i'll tag you when it's ready.

@olsonpm I still don't get it. It doesn't seem fair to say "they already tried that"; the way I read his post, there are specifics that get in the way of a much more general pattern, that otherwise might be successful.
From what I can gather, tree shaking fails if a module executes a function on load time, correct?
It appears to me that function execution could, in theory, be eliminated by only exporting static objects or functions; the application of higher order functions could be inverted by applying them inside the lower order function which can then be exported safely.
In practice, though, wouldn't it be enough to simply put the higher order functions in their own leaf nodes of the dependency tree and make sure that no branches import other branches?

From what I gather, tree shaking fails if a module executes a function on load time, correct?

Across many other things - yes. Assignments prevent tree shaking too, i.e.:
function MyClass() {}
MyClass.prototype.myMethod = function(){}; // this prevents tree shaking

It appears to me that function execution could, in theory, be eliminated by only exporting static objects or functions

I believe exporting objects is also preventing tree shaking in some sense:
export var obj = {
  used() {},
  unused() {},
}

I havent checked it, but im pretty confident that unused wont get tree shaken.

the application of higher order functions could be inverted by applying them inside the lower order function which can then be exported safely.

Possibly this could be possible, however in my opinion such transformation still should be performed by babel. Code creators shouldnt worry too much about re-structuring their source code so other tools can process them in some better way (in example by making them tree-shakeable) - its a superior solution imho to create a code transformation plugin, which could be applied on everybody's code with confidence to provide mentioned benefits. And while this would require babel plugin to be written I dont believe its that much superior than having a babel plugin which adds #__PURE__ annotations. However I see the gain of such solution in reduced runtime startup.

In practice, though, wouldn't it be enough to simply put the higher order functions in their own leaf nodes of the dependency tree and make sure that the tree is kept proper?

Could u elaborate? Im not sure if I know what you mean. Some example would be great.

Assignments prevent tree shaking (...) I believe exporting objects is also preventing tree shaking in some sense

Both examples involve properties/methods, which we already know will never be tree shaken, simply because they might be accessed programmatically at runtime by string lookup (Closure Compiler is supposedly able to remove them through much more advanced static analysis).
Sure, it would be great to be able to do automatic transformation of code to allow tree shaking, but it seems clear that this would either be a highly nontrivial problem or depend on certain assumptions that might fail in edge cases or need annotations.

Could u elaborate?

About the dependency tree: Modules are locally scoped, so if each and every function had its own module and the dependency graph was kept as a proper tree, my thought would be that unused code could be safely removed through static analysis, which is basically what tree shaking means, right?
There must be something I'm not getting here...

@Andarist My last comment about the dependency tree is probably related to your report here: https://github.com/webpack/webpack/issues/5654

so my point was that you have rich and jdalton trying to solve a problem that you're perceiving as fairly simple.  "couldn't we just change the code to be tree-shake'able?".  my point was that rich concluded it was not simple at all.  i mean, if lodash could have done it, it would be done by now.  you not only have rollup, but now webpack that tree shakes as part of its bundling process.  both libraries have many issues regarding tree shaking and both resort to wontfix resolutions because it is either not possible statically or requires logic too complex to warrant adding to the codebase.
so i think it's fair to say they already tried that, and if you can solve this problem then your contribution would be extremely valuable.

I'm reaching the realization that this issue is not about Ramda being inherently a hard case for tree shaking, but about wanting to achieve it without touching the structure of the code base at all.
I won't say that this approach is lazy, since Ramda isn't the smallest of libraries, but I would say that a rewrite should definitely be preferred over compiler comments targeting a specific bundler....

the comments target a minifier, not a bundler.  and it is a very new addition to uglifyjs.

Also such comments are not really tool specific - any tool could leverage them, but as its UglifyJS' invention, it's leveraged only by them (for now at least). It indeed feels a little bit sad that we have to provide hints to the tools to reach certain outcomes, but at least for me I prefer such solution than restructuring the code in unnatural way. That's ofc just my personal opinion on this.

@Andarist - had the time tonight to look into my es5 comment.  I should have realized that although the pure comments are unrelated to tree-shaking, they are dependent on scope hoisting.  In producing a minimal example to show that, I reached a bug with rollup when turning tree shaking off.  I also couldn't find a way to turn treeshaking off with webpack.
The reason it relies on scope hoisting is that uglifyjs can't remove unused properties from an object as that would be a very unsafe transformation - and module.exports is always an object.  However with hoisted scopes, everything is top level which uglifyjs can then remove via the toplevel minify option.

Is there a reason to have browserify in package.json when rollup it used?

Possibly not, could get removed.

I started using Ramda and I stumbled on a problem. After installing through Npm it works fine in the REPL:
R = require('ramda')

But it fails in the source code:
import R from 'ramda';

with the following error:
export 'default' (imported as 'R') was not found in 'ramda'

My workaround is to use the old require() syntax in the source files too, just for Ramda. Am I missing something? Is this a known bug?

@tobia, try import * as R from 'ramda';.

What are you using to run/compile the import syntax? I'm using node --experimental-modules *.mjs in Node 8.7.0 and it works. Maybe you can get that same syntax working by tweaking your loader.

@davidchambers Thank you, import * as R from 'ramda'; works splendidly. It probably does the same thing as require(), but at the very least it's more consistent with all the other imports.
I'm still a relative newbie to the modern JS world, so I wouldn't have figured that out!

@tobia you can inspect the output of your import syntax here and the ramda's entry point after transpilation here (ofc ramda's has more functions exported, but thats not the point) to get the gist of whats going out behind the scenes.
When using bare require it omits the interop step, but when using import R from 'ramda' it expects to import what's under default property of the imported exports, however such doesnt exist.

Is using the destructuring import { filter, keys } from 'ramda'  syntax working with tree shaking atm? or do we have to import each function individually to reduce dead code in our bundles?

@marcosfede library itself (ramda) is well suited for tree-shaking now. However all depends on the tree-shaking algorithm used and they differ between tools.
You will get best results with rollup, webpack@4 in produciton mode should give you acceptable results (or maybe even ideal nowadays), you can get good results with ModuleConcatenationPlugin in webpack@3, but without it you will get poor results.
You can read more here

Does tree shaking work with import * as R from 'ramda' or `import R from 'ramda'?

import * as R from 'ramda' is the appropriate form, ramda has no default export - it's a namespace

But does it have tree shaking though?

@dolanmiu not in webpack 3 (haven't tried v4)

Tree-shaking is not something to have - it's algorithm used by other tools when bundling. See my comment above - https://github.com/ramda/ramda/issues/1968#issuecomment-380700190

@Andarist Sorry, I phrased the question wrong
Does tree-shaking algorithms (such as rollup or webpack@4) work with import * as R from 'ramda', or do I have to import it like:
import {identity} from 'ramda'

import identity from 'ramda/es/identity';

Got this from: https://github.com/ramda/ramda/issues/2355#issuecomment-341513380
I would prefer to use import * as R from 'ramda', which is why I am asking

Until u pass R as argument to function call (be cautious when doing such thing) this:
import * as R from 'ramda'
R.identity(1)
`
should behave the same as `import {identity} from 'ramda`.

You can read a little bit more in [my comment above](https://github.com/ramda/ramda/issues/1968#issuecomment-380700190).


Review notes

Hi,
I've reviewed this crate using cargo-crev.
Some notes:

maybe you should not implement Debug for Seed and Mnemonic. Debug makes it easy to accidentally log them somewhere and thus leak them.
there are multiple issues that cargo clippy will point out - nothing serious, but it is a good idea to just do what Clippy says.  Too little about this project, too much about giving publicity to your tool.
Just sayin'.

@vorot93 I'm not aware of "coat rack" phrase, but if you mean that I link to the review to increase visibility to increase the awareness of it, then it's true. Shamelessly. :)
As this is a bitcoin-related crate, a review by a reasonably reputable person is a valuable thing (IMO). I've spent around 20-30 minutes going through the code and reviewing it and I'm letting the author know that i did and what I think could improve, with a cryptographic proof. Some companies would pay me money for it.
So I think it's a fair game. If somebody minds, feel free to delete/close.


Range & Format Validation for Dates

Add more complex date validation rules like checking if a date is within a specific range (e.g., before or after today, or between two dates).

Date format and ranges from, to are implemented


feat: update Notifications frontend

Initial port of Notifications FE from Janus to upstream.
For simpler review, the PR is intentionally kept small in terms of features. The original Janus version is bigger.
On top of this, there will be a serie of small PRs adding:

filter on Saved
filter on Created
pagination
sorting
severity
representatino of Saved (Pinned) notifications - new component
reduce filckering (by applying diffs only and by searching on both the FE and BE sides)

Since I have those changes +- ready, there is a bunch of commented-out code left which I am going to use for the next smaller PRs in the upcoming days.
I can remove the commented-out code if it is an issue. Or it will be cleaned by the next PRs comming in a few days.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Screencast

@mareklibra if you run it without the last argument (yarn build:api-reports) you get the warning. Sorry about that. It's probably being a bit overly optimistic in optimising the subset of things that it looks at, when you limit the scope.


[AutoPR cdn/resource-manager] [CDN] Copy changes from API version 2019-04-15 into 2019-06-15-preview.

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/7442

(message created by the CI based on PR content)


Revert "bump pulumi sdk; increase node root volume size"

This reverts commit 5cf0f267abd0ee8ca7b4d1b97f4b40e99077f251.

Yeah I noticed that as well, but reverting it will make the history cleaner -- we'll be un-reverting it at some point anyway.


Fixed problems with incorrect database schema in provided example.

fixed issues with missing values and iconsistent column types
Provide a narrative description of what you are trying to accomplish:

[ X] Are you fixing a bug?

[ ] Detail how the bug is invoked currently.
[ ] Detail the original, incorrect behavior.
[ ] Detail the new, expected behavior.
[ ] Base your feature on the master branch, and submit against that branch.
[ ] Add a regression test that demonstrates the bug, and proves the fix.
[ ] Add a CHANGELOG.md entry for the fix.

[ ] Are you creating a new feature?

[ ] Why is the new feature needed? What purpose does it serve?
[ ] How will users use the new feature?
[ ] Base your feature on the develop branch, and submit against that branch.
[ ] Add only one feature per pull request; split multiple features over multiple pull requests
[ ] Add tests for the new feature.
[ ] Add documentation for the new feature.
[ ] Add a CHANGELOG.md entry for the new feature.

[ ] Is this related to quality assurance?
The provided database schema is incorrect, has incosistent column types across tables. For example client_id and user_id being integer in one instance and varchar in another, multiple tables missing id files.

[ ] Is this related to documentation?

@sheridans
Can you explain which problems you had and why all other DBMS than MySQL should be excluded?
Thanks in advance!

Problems with the provided example file...
oauth_auth_codes.user_id is declared as INT, oauth_users has no relevant for relation
oauth_auth_codes.client_id is declared as INT, oauth_clients has relevant field
oauth_clients.user_id is declared as INT, again oauth_clients has no related field.

I've fixed the CHANGELOG entry and force-pushed back to your branch.


Definition of Device Frame for Aria Glasses

Hi,
Thanks for releasing the dataset and the tools to work with the dataset.

In the above figure, the device frame that is referenced in the ImuCalibration as well as CameraCalibrations is not defined. Could someone please update the figure or let me know where exactly it is located?

We did not define a device frame in the released conventions. Trajectory released is saved by a series of timestamped transformations of the Project Aria device's left IMU relative to the world coordinates (frames).  What do you need it for?

I was just curious because the nominal rate of left IMU (1202-2) is 800Hz, and the numbering for the SLAM (left-right) cameras and IMU (left-right) are not consistent.

That's at implementation level. At the interface level, we did not expose it. Why will you need it explicitly?


updating README & CHANGELOG to reflect the migration of...

...auxiliary scripts into a separate python package called gftools
(which stands for Google Fonts Tools) and is available at
http://pypi.python.org/gftools and https://github.com/googlefonts/tools/
This pull request addresses the problems described at issue #1639

The url is https://pypi.python.org/pypi/gftools
The one you wrote gives me 404

That's right. I'll fix it. Thanks!


fix: backport package.json ignore on windows

Backport to 6.5.x for #735
Closes: #674

:tada: This PR is included in version 6.5.2 :tada:
The release is available on:

npm package (@release-6.5.x dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


MAINT: Fix some compiler warnings (or add comments on hard to fix)

Mostly a few small compiler warnings fixes.  There are still some left, mainly about comparing signed and unsigned ints (for things like num-rows).  I also have a use_blocks uninitialized warnings in rows.c (and one more), those seems probably spurious.

Thanks @seberg, this also closes #3 , so I added macos to the CI.


Problems downloading/extracting BFD database

Are there currently any known issues with the BFD database?
The BFD archive downloads completely, but upon attempting to extract its contents, the following EOF error is generated after the first file:
bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_a3m.ffdata
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
The MD5 hash and file size for the tar.gz archive match the hash listed by https://bfd.mmseqs.com/
However, the MD5 hash for the one successfully extracted file (show above) does not match the hash listed by https://bfd.mmseqs.com/
I have tried this download 3 times with the same outcome:

The first two downloads were from https://storage.googleapis.com/alphafold-databases/casp14_versions/bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt.tar.gz
The third download was from: https://bfd.mmseqs.com/bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt.tar.gz

The other alphafold databases have downloaded without issue.
Any insights would be much appreciated.
Thank you.

This behaviour is believed to have resulted from the HPC system terminating the file expansion.

Hi @Aroids, I am having same problems as you did. May I ask you how do you solve the problem in the end? What does the "HPC system terminating the file expansion" mean? Thank you so much!

Hi @FankangMeng, I was extracting the BFD database on the login node of a high performance computing cluster. Extracting BDF on a compute note solved the problem.

Hi @FankangMeng, I was extracting the BFD database on the login node of a high performance computing cluster. Extracting BDF on a compute note solved the problem.


feat: Implement MVP for Event

Fixes part of #92

Add MVP for Event
Add thorough tests
Add logout feature

Some tests remain to add

@niranjan94 It is completed. Please merge if check passes :smile:


Add selection box movement/scaling to the animation bezier editor

Implements https://github.com/godotengine/godot-proposals/issues/3532 for the bezier editor.
Screencast_20241216_114037.webm
Sponsored By: 🐺 Lone Wolf Technology / 🍀 W4 Games.

Thanks so much for this @YeldhamDev , this will be such an improvement to the Bezier editor. I've been trying it out a bit and I did see some weird behaviour when selecting some of the bezier handles after doing a multi selection.
https://github.com/user-attachments/assets/4604c506-854b-4b8c-847b-5d0f6ed0a511

@Arnklit This appears to be a preexisting bug unrelated to the PR (it also happens on 4.3). From what I tested, it seems to happen because the handle's position is being calculated relatively to the highlighted track.

It was a single line of code using the wrong variables. Added the fix in here too, why not.

It was a single line of code using the wrong variables. Added the fix in here too, why not.

Sorry I did not realise that was a pre-existing issue, thanks for including the fix. Tested again and yeah it's great now.

I had a go at adding in the cursor changing based on what handle you are dragging. Don't know if you want to incorporate that, otherwise I can do a PR for it when this one merges :). https://github.com/Arnklit/godot/commit/071f462fb3a786dd0706f2287a384c22b724e0b2
https://github.com/user-attachments/assets/c9dfa0b3-43f4-4013-bdb9-db57d7cefed6

@Arnklit I think it's probably better to be its own separate PR.


Debian package dependencies are broken

Hi @airween,
I'm trying to install modsecurity3 latest for nginx from sid.
Apparently there is a minor fix in 3.0.12 leading to a version 3.0.12-1.1 .
However this fix has been added only to libmodsecurity3-dev and not libmodsecurity3.
So I get an error on installing
 > [linux/amd64 stage-0  9/35] RUN set -x && apt-get update                 && apt-get -t sid install -y --no-install-recommends                                libmodsecurity-dev=3.0.12-1.1                                libmodsecurity3=3.0.12-1:
6.700 Reading state information...
6.939 Some packages could not be installed. This may mean that you have
6.939 requested an impossible situation or if you are using the unstable
6.939 distribution that some required packages have not yet been created
6.939 or been moved out of Incoming.
6.939 The following information may help to resolve the situation:
6.939
6.940 The following packages have unmet dependencies:
7.205  libmodsecurity3t64 : Breaks: libmodsecurity3 (< 3.0.12-1.1)
7.211 E: Unable to correct problems, you have held broken packages.
------

IIRC 3.0.12-1.1 was available for some time, but has been removed. Could that be?
For the time being I have removed libmodsecurity-dev and changed my Dockerfile to work around this.
Can you please have a look?
Peter

https://tracker.debian.org/pkg/modsecurity
https://tracker.debian.org/news/1507893/accepted-modsecurity-3012-11-source-into-unstable/

Hi @logopk,
thanks for reporting.

I'm trying to install modsecurity3 latest for nginx from sid.
Apparently there is a minor fix in 3.0.12 leading to a version 3.0.12-1.1 .

The reason of minor fix is this (through this ticket).

However this fix has been added only to libmodsecurity3-dev and not libmodsecurity3.

I haven't had time to review the new concept (renaming libraries to t64 suffixed packages), but it seems that the development packages keep their own names, and runtime packages has renamed with t64 suffixed package names.
See this page.

So I get an error on installing
 > [linux/amd64 stage-0  9/35] RUN set -x && apt-get update                 && apt-get -t sid install -y --no-install-recommends                                libmodsecurity-dev=3.0.12-1.1                                libmodsecurity3=3.0.12-1:
6.700 Reading state information...
6.939 Some packages could not be installed. This may mean that you have
6.939 requested an impossible situation or if you are using the unstable
6.939 distribution that some required packages have not yet been created
6.939 or been moved out of Incoming.
6.939 The following information may help to resolve the situation:
6.939
6.940 The following packages have unmet dependencies:
7.205  libmodsecurity3t64 : Breaks: libmodsecurity3 (< 3.0.12-1.1)
7.211 E: Unable to correct problems, you have held broken packages.
------

IIRC 3.0.12-1.1 was available for some time, but has been removed. Could that be?

with this version the package name is libmodsecurity3t64, not libmodsecurity3. You should try:
...RUN set -x && apt-get update                 && apt-get -t sid install -y --no-install-recommends                                libmodsecurity-dev=3.0.12-1.1                                libmodsecurity3t64=3.0.12-1.1

Could you try this?

geee - this is ugly, but your suggestion works. (needed some more fixes for libgeoip1(t64)).
Thank You for your help. As always lightning fast!

Thanks, it's good to see that your problem has solved.
Please close the issue if you don't have any questions.

Hello @airween,
this is getting bigger by the day.
Currently I'm facing a similar issue with apache2 and libapache2-mod-security2 from sid on armhf.
The true problem is that I'm using the same Dockerfile for docker buildx to build my image for arm64,amd64 and armhf.
After some restructuring arm64 and amd64 build ok, but armhf for my pi 3b+ fails:
 > [stage-1 12/70] RUN set -x  && apt-get -t sid install -o APT::Immediate-Configure=false -y --no-install-recommends -o Debug::pkgProblemResolver=true -o Debug::Acquire::http=true                                libapache2-mod-security2=2.9.7-1+b1:
8.041 or been moved out of Incoming.
8.041 The following information may help to resolve the situation:
8.041
8.041 The following packages have unmet dependencies:
8.466  libdb5.3t64 : Breaks: libdb5.3 (< 5.3.28+dfsg2-5) but 5.3.28+dfsg2-1 is to be installed
8.466  libgdbm6t64 : Breaks: libgdbm6 (< 1.23-5.1) but 1.23-5+b1 is to be installed
8.466  libgnutls30t64 : Breaks: libgnutls30 (< 3.8.3-1.1) but 3.8.3-1 is to be installed
8.467  libhogweed6t64 : Breaks: libhogweed6 (< 3.9.1-2.2) but 3.8.1-2 is to be installed
8.467  libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2+b1 is to be installed
8.474 E: Unable to correct problems, you have held broken packages.

I have no idea where these dependencies come from and how I can fix them.
Do you have an idea?
Thanks.

Hi @logopk,
ahm, thank for letting know this.
Unfortunately I'm almost sure this is a Debian issue - one or more packages are broken, because of the t64 migration.
Could you open a bug on Debian tracker? That would be a huge help me - thanks!

Before you open a ticket, could you upgrade/replace the mentioned packages above?
Eg. libdb5.3 -> libdb5.3t64? Seems like packages are available, eg: libdb

@airween

Could you open a bug on Debian tracker? That would be a huge help me - thanks!

Never done this, but I will try. Is this only working via email?

Before you open a ticket, could you upgrade/replace the mentioned packages above?
Eg. libdb5.3 -> libdb5.3t64? Seems like packages are available, eg: libdb

I have added this to the install, but that did not fix it, or change the output...
 > [stage-1 12/70] RUN set -x  && apt-get -t sid install -o APT::Immediate-Configure=false -y --no-install-recommends -o Debug::pkgProblemResolver=true -o Debug::Acquire::http=true                                libdb5.3t64                                libapache2-mod-security2=2.9.7-1+b1:
7.986 or been moved out of Incoming.
7.986 The following information may help to resolve the situation:
7.986
7.986 The following packages have unmet dependencies:
8.390  libdb5.3t64 : Breaks: libdb5.3 (< 5.3.28+dfsg2-5) but 5.3.28+dfsg2-1 is to be installed
8.391  libgdbm6t64 : Breaks: libgdbm6 (< 1.23-5.1) but 1.23-5+b1 is to be installed
8.391  libgnutls30t64 : Breaks: libgnutls30 (< 3.8.3-1.1) but 3.8.3-1 is to be installed
8.391  libhogweed6t64 : Breaks: libhogweed6 (< 3.9.1-2.2) but 3.8.1-2 is to be installed
8.392  libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2+b1 is to be installed
8.400 E: Unable to correct problems, you have held broken packages.
------

What does libdb5.3 (< 5.3.28+dfsg2-5) but 5.3.28+dfsg2-1 is to be installed mean? Who is setting this requirement? Ah: armhf has only 5.3.28+dfsg2-1 in the repo?

Bugreport was sent :-)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066191


Block use of /proc/acpi from inside containers

Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

Note this is currently blocked by SELinux.

I think we will need to revendor buildah when https://github.com/projectatomic/buildah/pull/853 gets merged, to protect podman build

It doesn't seem to be protected by apparmor (in contrast to other runtimes).

Test suite seems to be exploding

Reproduced locally - Podman on master can't pull the Alpine image from any configured registry

bot, retest this please

Code LGTM

bot, retest this please

This should be good to merge, but I'll wait for travis to finish before we do.

Alright, Travis is green, merging
@rh-atomic-bot r+