Allow to filter statements by dataset and upload

It would be very nice to be able to filter statements by "datataset" and "upload":
The "dataset" is a set of statement (usually distinguished by source) like "Freebase" or "X and Y research project".
The "upload" is the id of the upload process in order to be able to rollback it.
An "upload" would add data to one "dataset" but a "dataset" may be uploaded in more than one "upload"
Use cases

Cancel the upload of a dataset if too many bad data have been imported
Allows to output statistics for only one dataset
Allows the user to display only statements from one dataset

Possible implementation
Data structure

"dataset" is a string like "freebase" that identifies the dataset
"upload" is a unique identifier which is assigned by the backend during the upload process and then returned to the user. We could use the timestamp of the upload beginning as id.

Backend
In the database two field are added to the 'statement' table, 'dataset' and 'upload' which contain the "dataset" and the "upload" ids.
Change the /import action to be able to specify a dataset and make it choose and return an upload id.
Edit the /delete action to allow to remove the statements from a specific upload.
Add to /entities/, /entities/any and /statements/any action a dataset parameter to filter by dataset.
Frontend
Add somewhere a selector to only display one specific dataset.
@tomayac @wastl What do you think about it?

So far, we didn't consider it too important. But if there is a good use case, we should implement it. However, rather than using char columns that consume a lot of space, I would create a separate table "datasets" like
CREATE TABLE dataset (
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
name VARCHAR(32)
)
and add to the statement table only a column with a foreign key reference to the dataset table. Upload could simply remain an integer ID. I thought about timestamps, but they are more expensive.
There's a problem with cleaning up "bad" data and this is that a statement stores much of its data in the snak, source and qualifier tables. When deleting statements, it would also be necessary to clean up snaks that are no longer referenced, and this is a very expensive operation (kind of a NOT IN). If we really want this feature, I'll try coming up with a usable way. Perhaps we would need to delete statements individually, though.

We're getting a lot of interest for using this for a number of other datasets as the way to get them into Wikidata properly. Being able to tell the data apart seems important.

Implemented, rolling it out. When importing statements, it is now necessary to add a &dataset= argument to the REST call, or a -d  to the inject command line tool.

FYI(tomyac): when returning the envelope JSON format, the JSON now also contains for each statement the dataset identifier and the upload ID. Use it in any way you want in the UI ;-)

Thank you! :)


Address Book encryption follow up tweaks

Merge strategy (This function mixes the merge with the rest of the store logic. I would factor the merge out, since that's a pure function. Maybe also add a test for the merge.)

Merge strategy O(n*n)

Error handling in UI (TODOs in the code)

merge strategy enhancements

Deletion of a contact and sync between local vs. remote

redundancy in store of local contacts optimization

Copying some comment threads.
Concerning the call to storeContacts from allLocalContacts: :
@daira:

I read your comment https://github.com/Electric-Coin-Company/zashi-ios/pull/1409#discussion_r1843528714 and I agree it's necessary to call syncContacts (with storeAfterSync: true), but given that change, I don't understand why we need to also call storeContacts. syncContacts should correctly handle the case where the remote file doesn't already exist.

@LukasKorba replied:

I agree it's redundant in some scenarios but syncContacts is done in a way that it could throw an error and terminate the store completely. The current code ensure there is at least local store done and sync "can" fail. We might want to improve the order and robustness of the solution but I put it to follow up work in #1408

@daira:

If we want syncContacts to always store locally, there's an easy way to do that: set cannotUpdateRemote = true in those error cases (i.e. treat them the same way as RemoteStorageError.containerURL), rather than propagating the error directly. If we want to record the reason then that can be done as well. Anyway this has been merged as-is now, but please consider that approach for #1408.

and in deleteContact: :
@daira:

Non-blocking but please document this on #1408:
If the remote store fails here but a previous store containing the deleted contact succeeded, then the remote file will still contain that contact, and so on the next sync, we'll restore it contrary to the user's intent.
I think the best way to fix this is probably for the deletion to fail if we can't store remotely. That would mean that we should try to delete the contact from the remote store first, so that there's no partial failure case where we delete it locally but then report failure.

Also we should probably record the reason for failure (i.e. the exception object) in the .failure case of RemoteStoreResult.


The demo website not working

The demo website is down: https://particles-demo-dedqzqdvns.now.sh/

thanks. the link has expired, I'll provide another one asap.

Link updated!


Changing Interval Causes the Playback to Become Buggy

This was an issue manually escalated to me. It seems like changing the ping interval causes the playback to occasionally skip. I'll see if I can reproduce this.

Ah yes this is trivially reproduce-able, I'll see if I can figure out what's going wrong.

This only seems to happen for intervals < 500ms


[NETBEANS-1074] Module Review php.project

Add the license header to binalies-list
Change the license header of Bundle.properties
Add the template files to licenseinfo.xml
Choose CDDL as a license of phpsigfiles.zip

To me, looks great, thanks for this work.

@matthiasblaesing Thanks for catching it. Fixed.


ScriptNode : Save version metadata in serialiseToFile().

This can be used for informational purposes and also to assist in providing backwards compatibility with old files. This mechanism has been in use for some time in the Box/Reference export code - this just generalises it for all serialised files. At the time we introduced it for Boxes I was unsure if it should apply elsewhere, but we now have a use case for it on ScriptNodes (Hugh's #1444). Since serialising to file implies later reloading that file, it seemed worth providing this information everywhere a file is saved, rather than just in ScriptNode::save().
When importing a file into an existing ScriptNode, the values of the version metadata are potentially a little confusing, since the import overrides the existing value. The metadata is therefore best viewed as "the version of gaffer used to write the last file that was loaded or imported". Since our primary use case is during loading, hopefully this is acceptable for now.
Fixes #1436.

What will this metadata be set to when a script is opened with no serialised metadata? It should, I think, default to the last version before this code was added.
You mentioned that it would be set to "the version of gaffer used to write the last file that was loaded or imported". So what happens in the following situation:
Gaffer <IP_ADDRESS> is opened (version metadata is set to <IP_ADDRESS>)
Loads a script created in <IP_ADDRESS> (version metadata changes to <IP_ADDRESS>)
Work is done (version metadata is still <IP_ADDRESS>?)
Script is saved (which version is written to the script?)
If the final step saves a script that claims to have been saved from <IP_ADDRESS>, then any updates that are checking the version will change the script every time it's loaded. On save, the version should certainly, I would think, be set to the actual version we're running in.
It feels to me that there should be a post-load call that resets the version metadata to the actual version of Gaffer that we're in. The whole point of this would be to update anything in the script to the new version conventions. So during load, the old conventions are in place, and once loaded, everything should have been converted to the new conventions, and so the version should be updated too.

Having just been having a look at it a bit closer, would I be right that the metadata not being persistent would mean that it wouldn't remain after the script has been loaded?
So any code that needs to check the version during normal running should use Gaffer.About.*Version(), which will always be the actual version, and Gaffer.Metadata.nodeValue( parent, "serialiser:*Version" ) will be the script version? If so, that all sounds great to me

When a script is opened with no serialised metadata, the metadata simply won't be available (the query will return None). All that we know at that point is that the version is <= 0.15 - we don't know that it is 0.15, and it would be misleading to say that it was.
The version saved is always the current version though, as you stipulate - I've pushed an extra commit with a test asserting that.
As for changing the value after loading, I intentionally didn't do that, and I intentionally prefixed the metadata with "serialiser:" in an attempt to make it clear that the version refers to a previous serialisation and has nothing to do with the current state. My thinking is as follows :

We need the version available after loading for use in #1437.
The current version is available at all times via Gaffer.About in Python and Version.h in C++.
Nodes should always be in a valid state for the current version, and users of the API should never be expected to deal with anything else.

I see our messages have passed each other in the ether. It's exactly as you say - the current version is available already, and the new metadata is purely about the version that was used to do the saving in the past. And with persistent=False we take care that the only version that will ever be written out is the one we explicitly write (and which takes the current version).

I think I get it. All here looks good to me, then.
Also, fortunately, (None, None, None, None) is less than (0, 15, 0, 0), so there's no need to check for that exactly...

Actually, hit a bit of an issue here with relation to #1444.
In the tests, or any python, if a ScriptNode() is created, it won't have the serialiser version, meaning that the formatCompatibility module will adjust the bounding box. This means that any time a FormatPlug's setValue() is called in a python script, the max value will be incremented by 1.
What're the possibilities of setting the serialiser:*Version metadata values when a ScriptNode is created? If a script is being loaded, it will immediately overwrite them with the values in the script, otherwise it will correctly do the formatCompatibility modification.
Also, if ScriptNode.serialise() is called on a ScriptNode that was created in Python, it doesn't appear to have this metadata set.
This has all come up as an issue in python/GafferImageTest/FormatPlugTest.py. As an example, one of the tests (with my comments for annotation)
def testReadOnlySerialisation( self ) :

	s = Gaffer.ScriptNode()
	s["n"] = Gaffer.Node()
	s["n"]["p"] = GafferImage.FormatPlug( flags = Gaffer.Plug.Flags.Default | Gaffer.Plug.Flags.Dynamic )
	s["n"]["p"].setValue( GafferImage.Format( IECore.Box2i( IECore.V2i( 0 ), IECore.V2i( 10 ) ), 2.0 ) )

	# Because s doesn't have the metadata, formatCompatilibity changes the max value to 11

	s["n"]["p"].setFlags( Gaffer.Plug.Flags.ReadOnly, True )

	s2 = Gaffer.ScriptNode()
	s2.execute( s.serialise() )

	# Because the serialised script doesn't have the metadata, formatCompatibility changes the max value to 12

	self.assertEqual( s2["n"]["p"].getValue(), GafferImage.Format( IECore.Box2i( IECore.V2i( 0 ), IECore.V2i( 10 ) ), 2.0 ) )

	# By this stage, the max value is 2 more than it should have been

	self.assertTrue( s2["n"]["p"].getFlags( Gaffer.Plug.Flags.ReadOnly ) )

I thought the idea was that formatCompatibility.py would only do anything during loading, and we were going to use inspect or traceback to determine if we were inside a ScriptNode.load() call. That would deal with this case wouldn't it?

Yeah, I think I could do that - I was thinking that the stack inspection you suggested was only to get the scriptNode when registering a format.
Let me have a look now.


Evaluate adoption of Jakarta Core Profile

The Jakarta EE Core Profile 10 support is planned for MicroProfile 6.0

For older versions, the parent POM included the Jakarta Annotations, and Jakarta Interceptors is being pulled transitively by CDI. There is not much we can do there.
We now list Jakarta Annotations as being part of the platform. For Jakarta Interceptors, it is required by CDI, so we need to include it as well.
The Jakarta Core Profile adoption was added in https://github.com/eclipse/microprofile-parent/pull/62/, so I think this is complete.


Upgrade leak_tracker.

To prepare for https://github.com/flutter/flutter/pull/125063.

@polina-c not sure which dependency you're interested in, but I'm guessing this might already have it? https://github.com/flutter/flutter/pull/125225

@polina-c not sure which dependency you're interested in, but I'm guessing this might already have it? #125225

True. Closing.


Update sbt-converter to 1.0.0-beta37+17-715edaf5-SNAPSHOT

Updates org.scalablytyped.converter:sbt-converter from 1.0.0-beta36+41-906a0cad-SNAPSHOT to 1.0.0-beta37+17-715edaf5-SNAPSHOT.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalablytyped.converter", artifactId = "sbt-converter" } ]

labels: sbt-plugin-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Superseded by #80.


Dont serialize new call requests under the server test lock

Agreed and LGTM. This work does not belong under the lock.


Main

<EMAIL_ADDRESS>Market Index (CMI): 1,103  +0.9%
Bitcoin (BTC): $23,000  +0.7%
Ether (ETC): $1,643  +0.9%
S&P 500 futures: 4,127.25  +0.1%
FTSE 100: 7,873.78  +0.5%
Treasury Yield 10 Years: 3.63%  +0.1

Do you guys have any wings so I can't let the floor go up

<EMAIL_ADDRESS>Market Index (CMI): 1,103 +0.9% Bitcoin (BTC): $23,000 +0.7% Ether (ETC): $1,643 +0.9% S&P 500 futures: 4,127.25 +0.1% FTSE 100: 7,873.78 +0.5% Treasury Yield 10 Years: 3.63% +0.1

🤣🤣🤣😡


Desktop access

Hi.
Thanks for all the hard work that has gone into rainchasers.
Is there any possibility of restoring the website to allow desktop access.  I (and a few others) prefer using a desktop in the morning/evening to plan ahead.
The app is great, especially the navigation integration with Google maps, its just not as easy to use  to get the big picture.
Thanks again
Chris

Hi @CJMountford --
Thanks for getting in touch. I'm afraid while restoring web desktop access is possible, it's not practical for me to do. The web version of rainchasers was built before the existence of the APIs this repo uses, and so it scapes EA, NRW, SEPA web pages which obviously change and are fragile to scrape. For example, NRW changed the web frontend recently which broke all the welsh levels and this was the last straw that prompted it's closure.
If there is anyone who wants to build a web frontend themselves, this repo provides all the backend gauge polling and processing required, but this is now too much for me to manage.


jf gradle error in bom resolution since 2.46.3

Describe the bug
Sinceand the
Since the release of CLI version  2.46.3  and the use of the artifactory-gradle-plugin 5+, errors have appeared in dependency resolution for a project that has BOM dependencies and has declared a flatdir repository in its build.gradle.
Current behavior
With a project with the following minimalist build.gradle :
plugins {
    id 'org.springframework.boot' version '2.6.1'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

sourceCompatibility = '11'

repositories {
    flatDir {
        dirs 'libs'
    }
}

dependencyManagement {
    imports {
        mavenBom 'org.springframework.cloud:spring-cloud-dependencies:2021.0.0'
        mavenBom 'org.springframework.boot:spring-boot-dependencies:2.6.1'
    }
}

If i run jf gradle clean assemble --info then the following error happens :
* What went wrong:
Execution failed for task ':bootJarMainClassName'.
> Could not resolve all dependencies for configuration ':detachedConfiguration1'.
  The project declares repositories, effectively ignoring the repositories you have declared in the settings.
  You can figure out how project repositories are declared by configuring your build to fail on project repositories.
  See https://docs.gradle.org/7.2/userguide/declaring_repositories.html#sub:fail_build_on_project_repositories for details.
   > Could not find org.springframework.cloud:spring-cloud-dependencies:2021.0.0.
     Searched in the following locations:
       - file:/home/greg/git/gradle_tu/libs/spring-cloud-dependencies-2021.0.0.pom
       - file:/home/greg/git/gradle_tu/libs/spring-cloud-dependencies.pom
     Required by:
         project :
   > Could not find org.springframework.boot:spring-boot-dependencies:2.6.1.
     Searched in the following locations:
       - file:/home/greg/git/gradle_tu/libs/spring-boot-dependencies-2.6.1.pom
       - file:/home/greg/git/gradle_tu/libs/spring-boot-dependencies.pom
     Required by:
         project :

BOM dependencies are not retrieved from artifactory but only searched in the flatdir repository
Reproduction steps

Copy the following in build.gradle file :

plugins {
    id 'org.springframework.boot' version '2.6.1'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

sourceCompatibility = '11'

repositories {
    flatDir {
        dirs 'libs'
    }
}

dependencyManagement {
    imports {
        mavenBom 'org.springframework.cloud:spring-cloud-dependencies:2021.0.0'
        mavenBom 'org.springframework.boot:spring-boot-dependencies:2.6.1'
    }
}

With JFROG CLI 2.46.3+
Use gradle wrapper 7.2 and java 11/17
Run jf gradle-config to resolve dependency from artifactory (proxy to maven-central required)
run jf gradle clean assemble

Then the error will appears.
Then try the same with JFROG CLI 2.46.2 and the bom are well fetched from artifactory
Expected behavior
The expected behaviour is that the BOM as well fetched from remote as before 2.46.3
JFrog CLI version
2.46.3+
Operating system type and version
Ubuntu
JFrog Artifactory version
7.55.10
JFrog Xray version
3.79.11

Hi, any news about this ?


Command health

When using HealthCheck with protocol=COMMAND generates HTTP 400. That is because command is not accepted as a string but rather it needs to be an object. See https://mesosphere.github.io/marathon/docs/health-checks.html .
Versions tried
Marathon Client: 0.4.14
Marathon: v1.2.0-RC5, v1.1.0, v1.0.0-RC1, v0.15.3, v0.11.1

This is fixed. Yet to be merged. Fix is available in my local repo if you want to use.

@sumannewton Is the fix merged?

@pijusn  Not yet. Mohit hasn't accepted the merge request yet. @mohitsoni  Review & merge this request - https://github.com/mohitsoni/marathon-client/pull/37/commits

Let's link these two together so either state can be visible easily:
https://github.com/mohitsoni/marathon-client/pull/37


Remove out-of-date versioneer import

Hi!
I might just be thick, but I'm getting ModuleNotFoundError: No module named 'projectname._version' when loading a new project in a Python interpreter or Sphinx. I think this line is just left over from the versioneer -> versioningit transition, but I'm surprised no one has reported it in nearly a month!

I think the migration from versioneer to versioningit was merged only two days ago, so not a month :)
Thanks for finding!

I think I was looking at the commit date, not the merge date 🤦 that makes more sense

So the _version.py file is now only generated on package install. VersionInGit will auto-generate this file anytime the package is installed through pip install ..., and if the package is ever bundled for release, it will generate the static version of the file to load into the package.
What I suspect happened is you attempted to run the code without first installing it, so the file wasn't there and wasn't imported. If this is a use case for you, then its an edge case we should support.
I think the solution here would be to create try...except around that import in case the file isnt found. Either way, I feel this line needs to remain intact.
Thoughts?

Good to know, thanks for the explanation! Yes, we should document or explain this. We can add a try except with a comment explaining what's happening.

Note that the file is generated in several other instances in which versioningit is invoked, such as when building the package, even as an sdist, or (possibly) when using the versioningit command line tool to check the version.
I'm not sure I agree with a try: ... except block around the import. I think a comment with a link to the versioningit docs would be more useful.


Uninstall setup files ... a lot

Same as https://github.com/CenterForOpenScience/waterbutler/pull/178 but for MFR.

@felliott I forgot to at you in this one, but ... same h/t

Thanks, @cwisecarver!  Merged as hotfix 0.18.2: f52c16f55c7260236218f57b1671a5f230527e4c


feat: add boost.integer

add boost.integer
need skip url stability check

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (boost.integer) have been updated in this PR. Please review the changes.


Update to Angular 15.2

FIxes group of dependencies that cannot de merged individually by dependabot

Codecov Report

Merging #2006 (6e99fda) into master (fb00cae) will increase coverage by 8.93%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master    #2006      +/-   ##
==========================================
+ Coverage   33.00%   41.94%   +8.93%
==========================================
  Files          52       52
  Lines         821      801      -20
  Branches      103       59      -44
==========================================
+ Hits          271      336      +65
- Misses        457      461       +4
+ Partials       93        4      -89

see 33 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


npm create<EMAIL_ADDRESS>errors out, but npm create<EMAIL_ADDRESS>works fine

Current Behavior
I stood up a little playground project a few weeks ago using npm create skeleton-app@latest and it worked great. Just tried to do a new one today, and it did not. Changed the version back to 0.0.21 and it worked fine.
Unfortunately, the error itself seems to be throwing an error:
node:internal/errors:484
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received undefined
    at Object.writeFileSync (node:fs:2211:5)
    at out (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/creator.js:269:5)
    at createSkeleton (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/creator.js:108:2)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async main (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/index.js:26:2) {
  code: 'ERR_INVALID_ARG_TYPE'

edit: I had to downgrade Skeleton to 0.92.2 to get it working. Was getting an error wrt to theme.cjs.
Steps To Reproduce

run npm create<EMAIL_ADDRESS>using<EMAIL_ADDRESS><EMAIL_ADDRESS>Windows_NT 10.0.19044

Anything else?
I love Skeleton so hard.

Works fine for me @riziles, could you provide a bit more context on where the error occured?
During the scaffolding with the CLI or during npm run dev?
Considering that it works when you downgrade to 0.92.2 I feel like you did not actually use the latest CLI but did grab the newest Skeleton which is going to conflict because the tailwind plugin hat a lot of breaking changes and your tailwind config now needs to look something like this:
/** @type {import('tailwindcss').Config} */
module.exports = {
	darkMode: 'class',
	content: ['./src/**/*.{html,js,svelte,ts}', require('path').join(require.resolve('@skeletonlabs/skeleton'), '../**/*.{html,js,svelte,ts}')],
	theme: {
		extend: {},
	},
	plugins: [require('@tailwindcss/forms'),require('@tailwindcss/typography'),require('@tailwindcss/line-clamp'),...require('@skeletonlabs/skeleton/tailwind/skeleton.cjs')()],
}

The ... spread operator and the () brackets are essential so that we can keep making changes to the plugin without breaking it for end users.

@Sarenor ,
The error occurs during scaffolding if I use @latest. The comment about downgrading to 0.92.2 was in reference to using 0.0.21. Here is the full error message I receive when using @latest. I'm a little puzzled by the Unable to download settings file for VSCode message. I am not running this inside of VS Code:
(node18) C:\LocalTemp\Repos\GitHub>npm create skeleton-app@latest skeleton9

create-skeleton-app version 0.0.23

Welcome to Skeleton 💀! A UI tookit for Svelte + Tailwind

This is BETA software; expect bugs and missing features.

Problems? Open an issue on https://github.com/skeletonlabs/skeleton/issues if none exists already.

√ Add type checking with TypeScript? » Yes, using TypeScript syntax
√ Add ESLint for code linting? ... No / Yes
√ Add Prettier for code formatting? ... No / Yes
√ Add Playwright for browser testing? ... No / Yes
√ Add Vitest for unit testing? ... No / Yes
√ Enable Svelte-Kit experimental inspector http://bit.ly/3Hu0BGf ? ... No / Yes
√ Pick tailwind plugins to add: »
√ Select a theme: » Skeleton
√ Which Skeleton app template? » Skeleton Welcome
Working: Creating base SvelteKit install.
Working: Installing project dependencies.
Unable to download settings file for VSCode, please read manual instructions at https://skeleton.dev
node:internal/errors:484
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received undefined
    at Object.writeFileSync (node:fs:2211:5)
    at out (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/creator.js:269:5)
    at createSkeleton (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/creator.js:108:2)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async main (file:///C:/Users/riziles/AppData/Local/npm-cache/_npx/ed0f586322dee443/node_modules/create-skeleton-app/src/index.js:26:2) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Node.js v18.12.1
npm ERR! code 1
npm ERR! path C:\LocalTemp\Repos\GitHub
npm ERR! command failed
npm ERR! command C:\windows\system32\cmd.exe /d /s /c create-skeleton-app skeleton9

npm ERR!      C:\Users\riziles\AppData\Local\npm-cache\_logs\2023-01-27T14_51_10_444Z-debug-0.log

I have the same error.
Creating my-skeleton-app with a theme.
The dependencies in package.json are not filled for some reason

"devDependencies": {
		"@playwright/test": "^1.28.1",
		"@sveltejs/adapter-auto": "^1.0.0",
		"@sveltejs/kit": "^1.0.0",
		"@typescript-eslint/eslint-plugin": "^5.45.0",
		"@typescript-eslint/parser": "^5.45.0",
		"eslint": "^8.28.0",
		"eslint-config-prettier": "^8.5.0",
		"eslint-plugin-svelte3": "^4.0.0",
		"prettier": "^2.8.0",
		"prettier-plugin-svelte": "^2.8.1",
		"svelte": "^3.54.0",
		"svelte-check": "^3.0.1",
		"tslib": "^2.4.1",
		"typescript": "^4.9.3",
		"vite": "^4.0.0",
		"vitest": "^0.25.3"
	},

These are what I get, where is skeleton dependency?

^ Above was the output with the example app template
Creating a Bare Bones project does give me the dependency's.


includedir in pkgconfig is error if install_headers() has subdir argument.

meson.build has below code:
install_headers('single_include/nlohmann/json.hpp',  subdir: 'nlohmann')
It install header file into subdir, such as
~/.local/nlohmann
but pkgconfig file nlohmann_json.pc has below code:
includedir=${prefix}/include
It should be:
includedir=${prefix}/include/nlohmann
You can fix this bug by installing header without subdir:
install_headers('single_include/nlohmann/json.hpp')
Otherwise you can change pkgconfig file nlohmann_json.pc, but I don't know how to do that.

Is this related to #3248?

This seems to be incorrect, because as per the documentation at https://github.com/nlohmann/json#integration you should be using:
#include <nlohmann/json.hpp>

and as such, it is correct to install it to an "nlohmann/" subdirectory but not add that to the include paths.
Conversely, you appear to instead be using:
#include <json.hpp>

Which is a bad idea for several reasons -- scoping, particularly, because it's hardly as though "json.hpp" is an uncommon header name. And indeed, if you use this then it will not be found in ${prefix}/include.
If you use the cmake config files instead of the pkg-config files, you will still get ${prefix}/include, not ${prefix}/include/nlohmann/, so it is not a pkg-config issue either. Nor is it anything to do with meson, because cmake also installs a pkg-config file, and that pkg-config file points to the same path (${prefix}/include) that meson's generated pkg-config file uses.

@eli-schwartz is correct.  It is expected that nlohmann/ be part of your #include.  It doesn't make a lot of difference if you install the single include header and decide to put nlohmann in your include path and do the include without it, but it's mandatory that you use the expected form if you use the multiple headers, as they include each other using the #include <nlohmann/...> form.  For that reason, it's best to always include it with the nlohmann/ prefix and have the nlohmann directory inside a directory in your include path.

Anything to do here?

@eli-schwartz is correct. We should code as below:
#include <nlohmann/json.hpp>


Unable to install this Github master branch as library to Databricks environment

Hi,
I was trying to use pred_contrib_col parameter of SparkXGBRegressor, and I found this issue here mentioning the similar problem https://github.com/dmlc/xgboost/issues/9175
It seems that this issue has been fixed in the current master branch, but not for the latest PyPi release (1.7.5). I tried to install python-package of this github repo as a library to my Databricks environment, but the CMake version is not compatible.
This feature is very important to us because we want to calculate the SHAP value for this model and the current SHAP library doesn't support SparkXGBRegressor.
Can you please help with this issue? Appreciate any guidance on installation.
Thanks!!!

Have you tried installing the nightly version? https://xgboost.readthedocs.io/en/stable/install.html#id1

Thank you for your reply!
To install the latest version, should I download the xgboost-2.0.0.dev0+c2f0486d376df882d7aac2096be1dcaf9edb7188-py3-none-manylinux2014_x86_64.whl and replace the previous pypi xgboost? Thanks!

Yes, that's the right one.

Thanks, but using this whl file, I cannot import SparkXGBRegressor.
Can you please help with this issue?

Hey @Yutong-Gao506 👋
I honestly don't know where to ask these questions but since they're based on this one I'll go ahead and ask them here. Sorry for hijacking this thread.
How did you "I tried to install python-package of this github repo as a library to my Databricks environment"? What were the commands? Did you do them in a python notebook?

@hcho3 How to know which package to use from the nightly builds at https://s3-us-west-2.amazonaws.com/xgboost-nightly-builds/list.html?prefix=master/. How are the system identifiers collected for the file names of these nightly build packages?

@jaceklaskowski You should look for the git commit hash. You can get it by running command git log.


Add support for outputting results to a file

Description
We support JSON and (coming-soon) Junit and SARIF formats. These reporter formats are generally more useful saved as file output rather than stdout. Currently users would be required to redirect the stdout of these formats to a file themselves but it'd be much easier if the config-file-validation supported that as a built-in feature

@kehoecj
Hi, I'm interested in take on this issue. Please let me clarify the specifications.

Manage the output of results to a file when the "output-dest" flag is provided with the value "the path to a directory or a file."
Currently, config-file-validator only supports JSON and the standard format. When the reporter flag with the JSON format is provided, output the results to a file. For the standard (default) format and when the -output-dest flag is provided, simply ignore it.
Create a new file named "result.json" at the current working directory when the -output-dest flag with no value or empty string is provided.
Overwrite the file when an existing file is specified as the value of the output-dest flag.
Create a new file named "result.json" when an existing directory is specified as the value of the output-dest flag.
Create a new file named after the value of the output-dest flag when a non-existing file is specified as its value.
Return an error when a non-existing directory is specified as the value of the output-dest flag.

Do the above specifications meet your requirements? Your feedback is valuable. Thank you for your attention.


Deploy to Firebase Hosting

https://firebase.google.com/docs/hosting/deploying

Is deploying the code in current state possible? Anything that needs to be addressed that isn't currently documented?
Sorry fi this is the wrong place to ask this question :)

@cawlin I don't know exactly because I never tried firebase hosting. Can you give me your thoughts why do you think this is a good idea? Right now we are using github pages and as far as I know it is working pretty well, and it is free.

@Glauberamos oh I thought this was for hosting the distributed app (like self hosting a version on firebase).
I am looking to host my own instance of distributed and saw this before trying!

Oh I see, this could be as well for self hosting, but I think it was created for hosting the current online tool that we have hosted on github pages right now.


Can tfvc branches be renamed/moved in Azure DevOps without losing history?

This was a problem for on-premise TFS servers, where fixing an incorrectly named branch would disassociate that branches history.
Does this limitation still exist in AzDO?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9ae5caab-7948-1d23-3f63-94b33cf980bd
Version Independent ID: 26c7fd0e-b821-2b58-dc3b-8c4c2eeebc31
Content: Rename or move files and folders - Azure Repos
Content Source: docs/repos/tfvc/rename-move-files-folders.md
Product: devops
GitHub Login: @steved0x
Microsoft Alias: sdanie

@StingyJack -- you may find answers here:

Azure DevOps Support Bot
Azure DevOps on Stack Overflow

I am closing this issue now.  You are welcome to @ mention me for any followup.
We hope to hear from you again.
My apologies for the delay in responding.


LSPS6: LSP meta-data.

I've expanded /.well-known/bitcoin a bit to make it attractive for other use-cases beyond LSPS. (since the URI is proposed with /.well-known/bitcoin and not something like /.well-known/lightning-lsp)
But if nobody can envision any value for a generic bitcoin named well-known URI, we can change it.

I like the idea and think this is going in the right direction.
I just have a few questions.
Why do we need multiple public-keys in the .well-known file? I understand the client is interested in the node_id of the LSP. Why add more? What should a client do if multiple public-keys are advertised?
What is the purpose of lsp6.get_lsp_info?
Can you provide a few motivating examples?
We can always at the method at a later point in time, should we add it in the first iteration or could we wait until an LSPS is actually using the method.

Why do we need multiple public-keys in the .well-known file?

Assuming my LSP's website is https://acme.com I could have an LDK node ACME-LDK and an CLN node ACME-CLN.
Both lightning network nodes could support LSPS1. Both nodes are from the same company (so same website)
The purpose of  the .well-known file is to confirm the public key of the LSP as one of the nodes of the company.

What is the purpose of lsp6.get_lsp_info?

When we add LSPS1 to Torq.co workflows then pricing will be very dynamic. So it would be hard to understand why the fee for the same channel details is different between different nodes because for example node capacity or public channel count or historic activity might drive the fee.
With lsp6.get_lsp_info  you can explain this dynamic fee schedule. Explorers could also use this information in listings.


optimize: move global code to minimize

Fixes #482.
Please take a look.

This is just a straight cut and paste. Leaving GlobalSettings in global, because that makes sense, but I suspect the file will go away with #677


Cannot build for iOS

Building for iOS fails with
ld: library not found for -lZSDK_API
Version: 0.0.31

There is libZSDK_API.a file in the ios folder for this repose. Please open your Xcode project add manually this library to your Xcode.

Thank you. It worked

There is libZSDK_API.a file in the ios folder for this repose. Please open your Xcode project add manually this library to your Xcode.

I added libZSDK_API.a file through 'Link Binary With Libraries' and it still doesn't work. I am using 0.0.32

We were able to get this working by simply right clicking on "Runner" at the top of the solution explorer, and selecting "Add File to Project Name". This added the file to the correct location in the project for it to be referenced properly.

Found the issue in plugin. Need to add '.a' extension as like ( s.vendored_libraries = 'libZSDK_API.a' ) in zebrautility.podspec

There is libZSDK_API.a file in the ios folder for this repose. Please open your Xcode project add manually this library to your Xcode.

How exactly does one go about doing this ?


CDPCP-4195. Allow invoking user sync against non-existent users

Partial user sync failed to retrieve the UMS state if a specified
user or machineUser does not exist in UMS. This could be a problem
if a user sync invocation races against deletion of the actor. This
commit fixes this issue by reverting to retrieving users and
machineUsers individually if we receive a NOT_FOUND exception retrieving
the actors as a group. The missing actor will be recorded in the
warnings for the user sync.
Along with this change, parameter lists for some methods have been
simplified. Whether a user sync is a full sync or partial sync is dependent
upon the parameters in the UserSyncRequestFilter. I've removed
the "full sync" boolean parameter from methods that include the
request filter as a parameter. I've also changed methods that
include user and machine user crn lists to include the request
filter instead.
See detailed description in the commit message.

@hsheinblatt Let's discuss this approach here.
The benefit of this change is that we can sync some of the users specified in the partial sync request. This change also provides us information about which CRN failed to sync.
The old behavior did fail fast, but would not provide any information about which actor is missing when multiple actors are included in the sync.
From the WorkloadIAM standpoint, we'd eventually like to use the failure details to respond in a more precise manner. We aren't there yet, and will have to treat the success or failure as a whole anyways for the time being.

@handavid Since this change looks quite big and makes the user sync even a little bit more complex, I would approach this issue from another point of view, for example in case of partial user sync, when users/machine users specified, we could check for those users in UMS before the actual usersync as a validation and throw a bad request if some of the user missing. Is it possible?

@horadla23 I think that rejecting the request would also be a valid approach to improving this behavior. However, the current behavior will already fail early in the user sync. We will work around this in workload iam once we improve our error handling codepaths so we could also just leave the behavior as-is and wait for the overall automated user sync story.

I'm discarding this PR in preference for keeping current behavior.


Add function-package-url support in function cli add url support to function cli

Motivation
Pulsar-Function supports package-url from which worker can download and load function package. But right now, cli tool is not having a way to pass url arguments while calling function api.
Modifications
add cli support for function url.
Result
User can submit function with url.

@jerrypeng @srkukarni can you review the latest change?

@jerrypeng @srkukarni made the change with server-side validation.


Angle does not allow use sampler2D in transform feedback in some cases, WebGL2

Godot version:
3.1.1 stable
OS/device including version:
Windows 7 (Chrome/Firefox latest)
Issue description:
Angle does not allow use sampler2D in transform feedback shader(particle/etc)
Steps to reproduce:

Create particles, make particle material as shader
Bind any texture(or viewport) as sampler2D - it will work
Create viewport, bind viewport texture to second sampler2D - all sampler2D are lost

check this web build link (left is texture, right is texture+viewport) they should be equal, they equal only with Angle-disabled(or in native build).
Minimal reproduction project:
https://danilw.github.io/godot-utils-and-other/BUG_Angle_trf/BUG_Angle_trfeedback.zip

Looks still valid in 3.2.3

this is not godot bug, this is WebGL2 ANGLE-only bug
Godot4 drop WebGL2 support so this bug can be closed I think... as you wish ofc

I report this bug to Chrome 30 days ago https://bugs.chromium.org/p/chromium/issues/detail?id=1139633
so this can be closed


using ./ vs CWD

Consider using ./ vs CWD keyword for specifying current working directory

Actually, I have been thinking about this option and I have a different idea.  The project path should be defined as the directory containing the project settings file. I actually feel a little silly not having thought of it that way sooner.
This then leads to one other change in the tool. There needs to be a cli option to specify the path to the settings file instead of the project path. When not specified it looks in ./ for the settings file name and if it doesn't find it, errors out. When specified the tool uses the directory where the settings file is as the project path.
Ultimately, this means we remove the project path from the settings.

So, I kept pondering this thread and thought of something else...  M30ml uses data from the package.json in the model generation process to pick up details like project name, version, and author.
What if we moved the tools settings into a custom subsection of the package.json file?  It appears to be perfectly valid for npm and would consolidate our config files (later Sliderule could leverage the same approach).
https://stackoverflow.com/questions/10065564/add-custom-metadata-or-config-to-package-json-is-it-valid

I think it could be both; the project path, by default, could be relative to where the package.json is located, but you could override the default path by specifying a new relative path in package.json

Ah, good call, yes I think that is the way to go.

OBE with mono-repo and CLI approach


[BUG] Overlapped entities when tagging

Stacktrace and Code to create the bug
ValueError: [E1010] Unable to set entity information for token 1 which is included in more
than one span in entities, blocked, missing or outside.

Expected behavior
Spacy doesn't allow overlapping entities. Argilla should check for and remove them before start training.
Environment:

Argilla (1.13.2)
argilla==1.10.0

@dmartincc I have also thought about this before. Do you feel that something like this makes sense?
https://spacy.io/api/top-level#util.filter_spans


can you provide appium-flutter-finder?

hello,  when i import the java example, i find i can't find appium-flutter-finder in pom.xml. so can you provide it ? thanks!

@LDouble Please refer the below link.
https://github.com/truongsinh/appium-flutter-driver/issues/29

ok,  i find it, thanks!


fix(heartbeat): stop heartbeat if connection is not active

Fixed https://github.com/amqp-rs/lapin/issues/401
If you stop your RabbitMQ cluster with a grace period 0, it will still say it is connected.
By sending a readable event it returns:
2024-04-22T16:23:32.570945Z ERROR Socket was readable but we read 0. This usually means that the connection is half closed which marks it as broken.

validate the connection state while sending a heartbeat
validate that the socket is readable

We shouldn't emit a readable event ourselves, it really should come from the socket itself.
It can be a good lead for investigation though (and I have plan for an overhaul of all of this btw).
Do you use TLS or plain tcp ?

We shouldn't emit a readable event ourselves, it really should come from the socket itself.
It can be a good lead for investigation though (and I have plan for an overhaul of all of this btw).
Do you use TLS or plain tcp ?

plain TCP, lemme update the pr

@Keruspe PR is updated.

I like that last commit. When dumping #404 and letting it rest in my head I thought of something similar.
There's a couple of things that should be updated though.
I think we should have a dedicated error for this.
The check should be done at the very beginning of the self.timeout.map block, we should use cancel there and return None. We should check for 4*timeout (see comment in #404)


Set up documentation building from docstrings

This PR introduces docs building from docstrings in code:

sets up docs building using Sphinx & a loooot of postprocessing
fixes the docstring formatting for a lot of docstrings so they would render properly
adds __init__.py for all the subfolders with the right exports (necessary for Sphinx to work properly)
adds required packages for the docs building

I've also attached some other small changes & fixes:

updates outdated packages
adds a default me user ID to the UserClient, representing the user belonging to the token

Thanks, guys! I've taken the texts from the JS clients, but I agree they're not 100% ideal, I incorporated the suggestions.


Feature request

I hope that UI  like joplin !

Thank you for your interest! Yes, several UI revamps are planned, but we want to keep things as simple as we can.


[Dubbo-1693] Enhance the test coverage part-14

add unit test
#1693
dubbo-remoting/dubbo-remoting-mina
dubbo-remoting/dubbo-remoting-netty
dubbo-remoting/dubbo-remoting-netty4
Brief changelog

add unit test for netty4
modified some test code

Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[x] If this contribution is large, please follow the Software Donation Guide.

Please check the ci fail

@lovepoem ok，i'll check it .

Codecov Report

Merging #1832 into master will decrease coverage by 0.28%.
The diff coverage is 0.93%.

@@             Coverage Diff              @@
##             master    #1832      +/-   ##
============================================
- Coverage      40.9%   40.62%   -0.29%
+ Complexity     4592     4447     -145
============================================
  Files           638      629       -9
  Lines         31224    30196    -1028
  Branches       5501     5347     -154
============================================
- Hits          12773    12266     -507
+ Misses        16452    15996     -456
+ Partials       1999     1934      -65

Impacted Files
Coverage Δ
Complexity Δ

...libaba/dubbo/examples/version/VersionProvider.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...m/alibaba/dubbo/examples/merge/MergeConsumer2.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

.../com/alibaba/dubbo/examples/rest/RestConsumer.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...libaba/dubbo/examples/version/VersionConsumer.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...om/alibaba/dubbo/examples/merge/MergeConsumer.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...s/rest/impl/facade/AnotherUserRestServiceImpl.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ba/dubbo/examples/merge/impl/MergeServiceImpl.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ibaba/dubbo/examples/version/VersionProvider2.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...ibaba/dubbo/examples/generic/api/IUserService.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...bo/examples/callback/impl/CallbackServiceImpl.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

... and 76 more

Continue to review full report at Codecov.

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

why coverage rate is -0.29%?


Cant completely remove wine-common

hi i need winehq-staging but i cant manage to remove wine-common
i already did rpm-ostree override remove wine-common but nothing changes
[gb@fedora gb]$ sudo rpm-ostree install winehq-staging -y
Inactive base removals:
  wine-common
  winetricks
Checking out tree e259d32... done
Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular updates-modular updates fedora rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree-updates rpmfusion-nonfree copr:copr.fedorainfracloud.org:jc141:DwarFS WineHQ updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2023-03-14T10:56:46Z solvables: 4
rpm-md repo 'fedora-modular' (cached); generated: 2023-04-13T20:30:47Z solvables: 1082
rpm-md repo 'updates-modular' (cached); generated: 2023-08-19T01:34:25Z solvables: 1086
rpm-md repo 'updates' (cached); generated: 2023-08-31T02:35:34Z solvables: 22475
rpm-md repo 'fedora' (cached); generated: 2023-04-13T20:37:10Z solvables: 69222
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2023-08-26T15:09:45Z solvables: 176
rpm-md repo 'rpmfusion-free' (cached); generated: 2023-04-14T11:37:11Z solvables: 468
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2023-08-26T15:38:13Z solvables: 81
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2023-04-14T12:02:51Z solvables: 235
rpm-md repo 'copr:copr.fedorainfracloud.org:jc141:DwarFS' (cached); generated: 2023-02-07T17:00:49Z solvables: 4
rpm-md repo 'WineHQ' (cached); generated: 2023-08-21T15:01:02Z solvables: 234
rpm-md repo 'updates-archive' (cached); generated: 2023-08-31T02:59:34Z solvables: 33505
Resolving dependencies... done
error: Could not depsolve transaction; 1 problem detected:
 Problem: conflicting requests
  - package winehq-staging-1:8.10-1.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.10-1.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.11-2.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.11-2.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.12-3.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.12-3.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.13-1.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.13-1.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.14-1.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.14-1.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.7-1.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.7-1.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.8-1.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.8-1.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.9-2.1.i686 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System
  - package winehq-staging-1:8.9-2.1.x86_64 from WineHQ conflicts with wine-common provided by wine-common-8.14-1.fc38.noarch from @System

You would also need to remove winetricks.
Working on making this the default here:
https://github.com/ublue-os/bazzite/pull/241

There's an unknown ostree error when layering winehq packages, my recommendation at this point is to use Lutris if you need newer wine for something.


How can I decode event timestamp ?

I try to get the
msg.pkth.ts.tv_sec and msg.pkth.ts.tv_sec but it's always at the wrong value,
and then I try to get the timestamp inside the 'event'
msg.event.ref_time.tv_sec' and msg.event.ref_time.tv_usec is not the correct value either
(I already convert them from unix timestamp)
Any clue how to decode the alert timestamp ? so you know this library is helping me a lot to do my project and I need it so much

I realize it's been a couple of years since you wrote this, but I'm leaving this comment here in case someone else stumbles across this problem. The code as written assumes that the machine you're running Snort on will record each timestamp field as four bytes apiece, and that it's in big endian format. However, I found that in my environment (Snort <IP_ADDRESS> on a 64-bit docker container), I was getting each timestamp field as eight bytes and it was in little endian format. So I had to make some modifications to the unpacking code to get this working.

What changes did you make exactly?

@mukulRajSharma Here's a link to a modified version if this helps! https://github.com/kevin-hogan/blackbox/commit/bef070389989691d1ceac2d391796e783a181287


render empty window

I'm trying to render the sample dragon_with_xform vdb file but got a black window
here is the log info. looks like bound volume is incorrect
thank you.

number of vdbs: 1

Grid: density float
Dense Grid:
Memory footprint:        3.355 MB
Dimensions of grid  :   141 x 99 x 63
Number of voxels:       879,417
Bounding box of voxels: [-70, 1, -31] -> [70, 99, 31]
Memory layout:          XYZ (dissimilar to VDB)
value count: 879417
max density: 1.000000
0.079540 0.074172 -0.050714 0.000000
-0.054848 0.093727 0.051058 0.000000
0.071170 -0.010663 0.096027 0.000000
-0.200000 0.200000 -0.200000 1.000000
Number of volumes: 1
Computing volume bounding boxes... done! Computation took 0.180896 ms.
Computing scene bounding box... done! Computation took 0.249856 ms.
Total pre-computation time for scene was 0.430752 ms.
Scene boundingbox:
pmin: 3.40282e+38, 3.40282e+38, 3.40282e+38
pmax: -3.40282e+38, -3.40282e+38, -3.40282e+38
Computing Morton codes... done! Computation took 0.059232 ms.
Sort volumes... done! Sorting took 0.20448 ms.
Building radix tree... done! Took 0.0656 ms.
Building BVH... done! Took 0.076704 ms.
Total BVH construction time was 0.406016 ms.
Root node bounds
pmin.x:<PHONE_NUMBER>38528859811704183484516925440.000000, pmin.y:<PHONE_NUMBER>38528859811704183484516925440.000000, pmin.z:<PHONE_NUMBER>38528859811704183484516925440.000000
pmax.x: -340282346638528859811704183484516925440.000000, pmax.y: -340282346638528859811704183484516925440.000000, pmax.z: -340282346638528859811704183484516925440.000000
num volumes for child 3-0 is 0  max extinction: 0.000000
num volumes for child 3-1 is 0  max extinction: 0.000000
num volumes for child 3-2 is 0  max extinction: 0.000000
num volumes for child 3-3 is 0  max extinction: 0.000000
num volumes for child 3-4 is 0  max extinction: 0.000000
num volumes for child 3-5 is 0  max extinction: 0.000000
num volumes for child 3-6 is 0  max extinction: 0.000000
num volumes for child 3-7 is 0  max extinction: 0.000000

Octree root still seems to be at -M_INF and M_INF. Looking into it.

I'm not seeing a problem. Can you pull the latest commit, I've added some file extension checking

thanks sergeneren! it works now after sync.

good to hear that. closing this issue now.


feat: add function workspaceStorage in interface backend, and implement it in local/mysql/oss/s3

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

12 of 21 (57.14%)  changed or added relevant lines in 5 files are covered.
11 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.1%) to 71.372%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/workspace/storages/util.go
0
9
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/watch.go
1
85.93%

pkg/engine/operation/parser/parser.go
3
75.61%

pkg/cmd/destroy/options.go
7
82.55%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
7003

Relevant Lines:
9812

💛  - Coveralls


0.0.z not compatible with 0.0.z+1

@eddyb brought this up in #rust-internals today. If y != 0, any z is compatible, but if y == 0, they're not. This feels wrong.
I haven't reproduced yet, though.

Having 0.0.z not compatible with 0.0.(z+1) is consistent with npm.

In that case we should discourage publishing these or ban it fully. 0.0.x is useless because you simply can't give users a fix if a bug was discovered.

0.0.x is useless because you simply can't give users a fix if a bug was discovered.

My impression that there's a good intention behind this, as 0.x is "unstable", and 0.0.x is "ultra unstable".
Subsequently, I think the use for 0.0.x is for people who are still rapidly changing their project early in the development cycle, where there should be no expectation of inter-compatibility.
Just the communication around this isn't loud enough, so people may either mis-use this version range for their published crates when they aught to migrate to 0.(>=1).*.
And further, people depend on 0.0.x crates expecting some degree of stability that isn't there, and people depending on 0.0.x should not expect to receive updates, as any updates are likely to also come with API breaking changes.
Sure, as-is, it is surprising behaviour, but the surprise comes from a missmatch between what you've learned and what is true.
I'd probably argue in favour of better warnings or documentation regarding the use of 0.0.x ( both in publishing the package, and in the consumption of the package ), than argue 0.0.x to be banned outright.
( It would be especially useful if you're developing a small gaggle of interdependent crates, and rapidly changing their APIs, being able to develop and test them efficiently via cargo, without being forced to promise users a support level you're not ready for )

And further, people depend on 0.0.x crates expecting some degree of stability that isn't there, and people depending on 0.0.x should not expect to receive updates, as any updates are likely to also come with API breaking changes.

The problem isn't in normal usage, but when a 0.0.x crate has a bug that can be fixed with a backwards-compat release, except there's nothing like 0.0.x.1 to actually release it as.
This could even be a Rust soundness bug which can only be fixed with a breaking change in the compiler, so being able to release fixed versions of crates can be useful.

Subsequently, I think the use for 0.0.x is for people who are still rapidly changing their project early in the development cycle, where there should be no expectation of inter-compatibility.

You can use 0.x in exactly the same way. 0.0.x is redundant with that, but is strictly worse because you can't release a patch when other crates (inevitably) depend on yours.

I believe the current behavior matches the description of caret requirements in https://github.com/semver/semver/blob/efcff2c838c9945f79bfd21c1df0073271bcc29c/ranges.md, and matches Cargo's intended behavior, so I'll go ahead and close this.


Marriage Abroad - One outcome per path for Cambodia

In order to simplify the maintenance of marriage abroad smart answers, we are going to create one outcome per path for Cambodia.
Trello: https://trello.com/c/GbsqRWXv/728-marriage-abroad-create-one-outcome-per-path-for-cambodia
Factcheck
https://smart-answers-preview-pr-3200.herokuapp.com/marriage-abroad/y/cambodia

@ikennaokpala ok, I am using the partial "contact-method" in
<%= render partial: 'contact_method.govspeak.erb',
           locals: { calculator: calculator } %>

is that wrong?

@mgrassotti Partials like _contact_method.govspeak.erb are not required as part of the flattening.
See https://github.com/alphagov/smart-answers/pull/3045/files

@ikennaokpala yes I see, but as the "contact the embassy..." part is repeated in almost every partial, I was wondering if it could be good to leave that...

@mgrassotti The long term goal is to remove/reduce dependency on partials like _contact_method.govspeak.erb  that contain view country logic and allow content designer freedom to edit. There partials like _consular_fees_table_items.govspeak.erb that don't contain country logic and are derived from rates data.
Other partials like _you_have_been_divorced_or_widowed.govspeak.erb don't contain logic and hence can be ignore and may be removed by the content designer later.

@ikennaokpala 👍


Chainsaw, part 2

Chainsaw, part 2!
This one is probably best reviewed commit by commit.

069f35a9: [WIP] Chainsaw: Restore IRErrorResponse imports since the code that needs it wasn't removed yet. Sigh.
I was a little hasty in Chainsaw, part 1, when I ripped out a bunch of imports related to the error-rewriting code that's not supported in Emissary 4 without actually ripping out the code using those imports -- d'oh. This puts the imports back so that unit tests have a hope of running. (Ripping out the feature code will come in part 3 of the chainsaw commits).

092d98b7: [WIP] Chainsaw: Rip out tons of docker.mk stuff.
This takes the chainsaw to the rest of the Docker build system and uses Goreleaser to build our ancillary Docker images instead. I'm not delighted by this, since it makes Goreleaser take five minutes to run on my Mac, but it's a starting point.

f0d598ad: [WIP] Chainsaw: rip out vestiges of Edge Stack
This takes the chainsaw to all the "if edgestack" stuff in Emissary, including (at least most of the) stuff related to the intercept agent, Edge Stack gofilters, Edge Stack's built-in internal auth & ratelimit services, and the concept that Emissary called a sidecar and was really arbitrary binaries that could be included in the image and  would get started at boot time.
This commit does not entirely rip out the ACME holepuncher, because we might want that later.

6f30e3b7: [build] Make the Envoy image a build arg defined in .goreleaser.yaml
Defining build variables in .goreleaser.yaml to me makes more sense than having them hardcoded in the Dockerfiles.

c7a37908: Use the correct Docker image for the Gateway API transform test -- but disable it on Mac because Docker networking is annoying.
Putting the Envoy base image in .goreleaser.yaml makes it pretty simple for the Gateway API transform test, which wants to run Envoy in Docker, to find the right image. Unfortunately the test doesn't work on my Mac because of Docker networking madness, so skip it on Mac for the moment.

5c3f40c2: Switch away from setuptools over to importlibs for finding schemas and templates, so Python unit tests can run.
Finally, we used to be using a deprecated setuptools API to let the Python code find out where to look for schemas and templates at runtime. Switch to the supported importlib alternative.

After all that, Python and Go unit tests pass. To verify that for yourself:
make pytest-unit
make gotest

My basic functional test also passes, so this PR probably leaves us in mostly-tolerable shape to go after E2E tests locally and in CI.
(Note that there's at least one more chainsaw PR coming, to finish ripping out all the stuff related to error rewrites and header casing, and to do a closer review of things I commented out rather than deleting in this PR.)

LGTM as well. For historical reasons I'll voice a concern that the CI is just completely wrekt here, but I ran that past @kflynn and it's (currently) a known and expected state of affairs that is slated to be rectified in the next pass of chainsawing.
tl;dr 👍✅

To be clear, I think CI is going to take more than just a chainsaw. 😉 But I think that this round of chainsawing gets us to a place where it's sane to rebuild CI.


Avoiding the Use of Exceptions in Python and Considering Alternatives

I would like to propose a change in our error handling approach in Python. Please refrain from creating new exceptions (i.e., using the raise statement).
In languages where it is not possible to declare what exceptions a function might throw, the use of exceptions should be avoided. Otherwise, there's always a risk of uncaught exceptions. Wrapping each function call with try{}, can make the code structure unpleasantly complex.
In fact, exceptions should not be used as a regular error-handling mechanism. 90% of exceptions should lead to a program stop and facilitate easy debugging.
I appreciate the design of Result in Rust. Perhaps we can build a similar facility in Python. In the meantime, using traditional error code logic (0 for success, non-zero for errors) or True/False logic would make our code more readable and stable.
I look forward to hearing your thoughts on this proposal.

Exceptions seem to be the accepted error handling method in Python. All third-party libraries I have seen use exceptions. The advantage of exceptions is that users only focus on the errors they care about, and errors that they don't care about are thrown directly upward. Okay, this is similar to rust. If a python exception is not handled, it will crash the program, but it will output the call stack information of the error. This is easier to locate than rust.
If the return value method is used, countless codes for handling error values must be written in all codes. Most of these codes simply return error values upwards and do not add special error handling logic, but each call All must be written. It is very uncomfortable to write this way and it is easy to forget. The problems caused by this method may be more difficult to deal with. I don’t think it is a good method.

While I don't object to the correct use of exception handling, it's unfortunate that most third-party libraries do not use exceptions correctly, particularly when distinguishing between errors and exceptions. Errors are predictable and occur under normal circumstances, while exceptions are unusual. For parsing libraries and network libraries, format errors and network issues should be anticipated and handled as errors rather than exceptions.
Using exceptions in Python is fine if we're scripting, but if we're planning to build 24*7 services with Python, it would be unwise to have those services stupid interrupted  by what should be errors treated as exceptions.
What I hope for us is to avoid making the same mistakes. We should not use exceptions as a substitute for error handling. For third-party libraries, we need to carefully discern which exceptions are errors that we need to catch correctly, and which are standard exceptions that should lead to a crash.
Let's ensure our code is robust and resilient by treating errors and exceptions appropriately.


Please for the love of GOD add a mod menu.

I have not gotten a mod to work with Denpa. Seeing that it's a fork of Psych, Psych mods SHOULD work, right? Well they don't! I've tried loading SMB Funk Mix Advance, nothing. I know damn well everything is where it should be, yet Denpa shows nothing. Best of all, there's absolutely nothing in the engine that can help me turn on/off any mod I add to it.  Until you fix your mod loader I'm sticking to actual Psych. See you in 0.8.3.

Denpa actually uses a WAY different file hierarchy than Psych, so as far as I'm aware to get a Psych mod going you'll need to rearrange the files to fit the way Denpa handles them. I don't know about the mod menu, though; it would certainly be good to have that, but right now it isn't there, so you'll just have to probably have a script or something that works like a mod manager for Denpa Engine.

I cba to learn how Denpa works at this point. I'll just use Psych instead.

Psych mods aren't compatible with Denpa. If you get a Psych mod to work be my guest but we aren't responsible for supporting another engine's mod system. And for the mods menu, just use file explorer. Move the folder out of the mods folder to disable and move it in to enable, it's that easy!

 Talking down to me as if I weren't tech savvy. Smfh I'm not a grandma.

 Talking down to me as if I weren't tech savvy.  Also, if it were that easy, the mods would work. Also 2, if it's a fork of Psych, it's a fork of Psych. Changing absolutely everything will never change the fact that Denpa is a Psych fork. It's like basic biology but for programs.  As for the mods, yeah, I will be using Psych. And this behaviour is exactly why your Discord server is toxic af. People like you shouldn't even be touching games like this.

  I don't care if you changed a string called "abcdefg" to "skibideeznuts" or whatever, if Denpa started off as a Psych fork, it is a Psych fork, different functionality or not. Plus who asked you?

As an outsider who has not worked on this engine's source code but is able to read and understand how the mod infrastructure works, the infrastructure of a Denpa Engine mod is drastically different. As two quick examples, weeks are stored in the data folder, and song-specific scripts are stored in scripts/songs/, not in the song's data folder.
Also a fork does not necessarily mean "expansion of features." Whilst forks are often used to expand upon a repository, forks can also often be about using another project as a starting point for one's own ideas, which means differences in how the code works or how assets - such as mods - are loaded.
This ultimately means that I can, for example, make a fork of Psych Engine and call it something like Space Engine for example, and make completely different architectures for how assets are used. Whilst it would be a neat feature to support base Psych Engine mods, it's ultimately not my responsibility to do so and that I can choose to do it if I feel the need to. Just like it isn't UmbratheUmbreon's responsibility to do so either.
Again, just an outsider who has not worked on this engine commenting here. I personally don't care if you use Denpa or Psych, but I just wanted to throw my two cents into the ring about engines, since I get emails for this because I watch this repository to watch how this engine develops.

 Literally the only other person who responded reasonably here was 2schoolhouse (AT/UtU gave a "just do this, ez" response at the end and then moxie just butted in and went keyboard warrior mode, so I blocked him). Thanks for the response, but I'm still gonna be sticking to Psych.

Psych mods aren't compatible with Denpa. If you get a Psych mod to work be my guest but we aren't responsible for supporting another engine's mod system. And for the mods menu, just use file explorer.  Its probably frustrating that my response is just a "use File Explorer" and "Psych mods aren't Denpa mods" response, but that doesn't mean you have to go and act like I'm being internationally disrespectful and mean for no reason. As for why I didn't even mention adding a mod menu, it is due to the very simple reason of the File Explorer working perfectly fine for managing mods, because mods are just folders of assets. The only time a mod menu would be necessary is if either the engine didn't natively support mods (to which it does), or if the mod menu did something more than just enable and disable mods (for example, browsing and downloading mods from Gamebanana).
In the future please be more respectful when using this repository, thank you.

I never said you were being disrespectful. It was moxie who was being toxic so I blocked him. Simple as that. If he kept his mouth shut none of what happened after his response would have happened. I'm unfollowing this thread now.


Not able to write ome-zarr without msgspec

Hello everyone,
I just wanted to ask if the tests include a setting without msgspec? I just got a serialization error that I could fix by installing msgspec.
Maybe it should just go into required? This happened with an acquisition, where the grid was activated. I don't have time at the moment unfortunately, but can give a little more detail later if needed.
pymmcore-plus           0.11.1
pydantic                      2.9.2
psygnal                       0.11.1
useq-schema              0.4.7
Traceback (most recent call last):
  File "f:\python_env\lib\threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "f:\python_env\lib\site-packages\pymmcore_plus\mda\_thread_relay.py", line 144, in run
    emitter.emit(*args)
  File "f:\python_env\lib\site-packages\psygnal\_signal.py", line 1176, in emit
    self._run_emit_loop(args)
  File "f:\python_env\lib\site-packages\psygnal\_signal.py", line 1213, in _run_emit_loop
    raise loop_err from cb_err  # emit() call ABOVE || callback error BELOW
  File "f:\python_env\lib\site-packages\psygnal\_signal.py", line 1196, in _run_emit_loop
    self._run_emit_loop_inner()
  File "f:\python_env\lib\site-packages\psygnal\_signal.py", line 1225, in _run_emit_loop_immediate
    caller.cb(args)
  File "f:\python_env\lib\site-packages\psygnal\_weak_callback.py", line 453, in cb
    func(obj, *self._args, *args, **self._kwargs)
  File "f:\python_env\lib\site-packages\pymmcore_plus\mda\handlers\_5d_writer_base.py", line 157, in frameReady
    self.position_arrays[key] = ary = self.new_array(key, frame.dtype, sizes)
  File "f:\python_env\lib\site-packages\pymmcore_plus\mda\handlers\_ome_zarr_writer.py", line 279, in new_array
    ary.attrs["useq_MDASequence"] = to_builtins(
  File "f:\python_env\lib\site-packages\zarr\attrs.py", line 89, in __setitem__
    self._write_op(self._setitem_nosync, item, value)
  File "f:\python_env\lib\site-packages\zarr\attrs.py", line 83, in _write_op
    return f(*args, **kwargs)
  File "f:\python_env\lib\site-packages\zarr\attrs.py", line 102, in _setitem_nosync
    self._put_nosync(d)
  File "f:\python_env\lib\site-packages\zarr\attrs.py", line 150, in _put_nosync
    self.store[self.key] = json_dumps(d)
  File "f:\python_env\lib\site-packages\zarr\util.py", line 69, in json_dumps
    return json.dumps(
  File "f:\python_env\lib\json\__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "f:\python_env\lib\json\encoder.py", line 201, in encode
    chunks = list(chunks)
  File "f:\python_env\lib\json\encoder.py", line 431, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "f:\python_env\lib\json\encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "f:\python_env\lib\json\encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "f:\python_env\lib\json\encoder.py", line 405, in _iterencode_dict
    yield from chunks
  File "f:\python_env\lib\json\encoder.py", line 438, in _iterencode
    o = _default(o)
  File "f:\python_env\lib\site-packages\zarr\util.py", line 64, in default
    return json.JSONEncoder.default(self, o)
  File "f:\python_env\lib\json\encoder.py", line 179, in default
    raise TypeError(f'Object of type {o.__class__.__name__} '
psygnal.EmitLoopError:

  Signal emitted at: f:\python_env\lib\site-packages\pymmcore_plus\mda\_thread_relay.py:144, in run
    >  emitter.emit(*args)

  Callback error at: f:\python_env\lib\json\encoder.py:179, in default
    >  raise TypeError(f'Object of type {o.__class__.__name__} '

    Local variables:
       o = <OrderMode.row_wise_snake: 'row_wise_snake'>

good catch, looks like there's not a test.  it's also annoying that the standard library json doesn't know how to serialize a standard library enum :joy:
i'm fine with adding msgspec to the default requirements if you guys are.  i think it's a generally superior library for serialization.  two alternatives would be:

add a test to make sure that anything in the metadata is serializable with the standard json serializer
add a custom json serializer that all the writers must use if msgspec isn't available.

preference?  just using msgspec is certainly the easiest and probably the fastest, if you don't mind the dependency

Seems at least not worth it testing both, so I vote adding the dependency.

just uninstalled msgspec locally and the tests still passed actually.  So there's something more subtle going on here (a missing test case)

Hm, okay I will try to reproduce then with the DemoConfig and deliver more info.

figured it out, and found a better fix, will post PR in a moment


Justification of the SPIFFS.format() instruction when initializing WiFi credentials with OTA web server ?

Hello David,
in the case of WiFi credentials and other parameters being initialized by Web server, before writing these parameters in the setup.json file, you have an instruction SPIFFS.format() in the case of the ESP32 and nothing similar for the ESP8266 (see line 528 in WifiManager.cpp).
What is the aim of this instruction and why isn't it implemented for the ESP8266 ?
Also this format instruction is a bit annoying for me, because it erases my other configuration files when I want to change credentials through Web .
I would prefer a solution with a dedicated BootstrapManager.eraseFileSystem() instruction that could be called if required by the application code rather than automatic formatting.
However to avoid any change to existing code, a setup option parameter extern bool autoEraseFileSystem could be added in Helpers.h with its value set by default to true in Helpers.cpp (in the same way as extern bool fastDisconnectionManagement.
I have already added in this way a parameter extern bool forceWebServer to manage activation on demand of the Web server as a response to issue #9.
I will provide soon after some testing, a pull request with these modifications, if you agree.

OK, perfect.
I have already prepared the modifications to implement the BootstrapManager.eraseFileSystem() function (quite simple).
I will test it in the coming days after having forked the last 1.12.7 release.

Hello,
release v1.17.7 has suppressed the unnecessary SPIFFS.format() instruction for the ESP32 and I have tested this modification and this is OK now.
I think now that the creation of a specific BootstrapManager.eraseFileSystem() is unnecessary because a simple SPIFFS.format() or LittleFS.format() instruction can do the job in the application code.
So I have closed this issue.


How to use briefkasten cloud?

Describe the bug
I would like to try Briefkasten and I understand there is a cloud instance at https://briefkastenhq.com and a beta one for v2 at https://dev.briefkastenhq.com, but I fail to see how to create an account. I tried the "email magic field" link but I got:

Then I tried through the GitHub button and accepted the third-party OAuth app on GitHub, but then I simply got redirected to the instance page and that's it.
The documentation is mute about it:

Briefkasten Cloud
If you want to use the cloud version of Briefkasten, v2 is available in beta at dev.briefkastenhq.com. v1 is still available at briefkastenhq.com.

Reproduction
Go to briefkastenhq.com and try anything
System Info
N/A

Used Package Manager
n/a
Validations

[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

@pH142857 on both instances you simply signin with your provider of choice, and then you land at the main screen of the application, as you mentioned, and can begin using it.
I see that email login might be broken in v1 (briefkastenhq.com), ill check that out.

Thanks for your answer. v2 looks also broken because I am not redirected to the application but to a blank page instead (when I created the ticket I was redirected to the login screen. So both versions are not usable for me.

@pH142857 interesting, can you provide any additoinal context? Are there any errors in our console? I've been using v2 myself without issue almost daily :thinking:
Am I understanding this correctly?  Can you share the URL?) and it's just a white page?

You understood correctly. Exact redirection URL is https://dev.briefkastenhq.com/.
Console says:
Uncaught (in promise) TypeError: (intermediate value)(...) is undefined
    Immutable 94
    <anonymous> https://dev.briefkastenhq.com/:77
    promise callback* https://dev.briefkastenhq.com/:76
CommandBar.CNK0Q_fw.js:1:90188

Network says everything is code 200 except for:


RedissonRemoteService ideas

Here, two things that would be great additions (I think) to the RedissonRemoteService.
1) Be able to choose the remote service interface prefix
Right now its hardcoded to redisson_remote_service:.
The use case is simple: for example I want to be able to deploy the same worker application (that expose the same service) on two types of instances (say some AWS m3-* for standard use, and some c4-* for hardcore use).
So on the server side I would call:
String servicePrefix = System.getProperty("SERVICE_PREFIX"); // whatever where this come from
RRemoteService remoteService = client.getRemoteSerivce(servicePrefix);
remoteService.register(...) // as usual

And on the client side:
String servicePrefix = /* whatever code that decide if its a standard call or an hardcore one */;
RRemoteService remoteService = client.getRemoteSerivce(servicePrefix);
remoteService.get(...) // as usual

2) Be able to issue one-way call (ie: wait for the ack, but not the actual response)
This could be a client side only change, for example, by having a new set of RRemoteService.get(...) methods, that takes a boolean waitForResponse...
Or, maybe, re-use the RRemoteService.get(...)'s long executionTimeout, where a value of executionTimeout < 0 would indicate to the client to wait for the ack, but not the actual response.

point 1 was not to hard to code.
I can create the PR if you want.

I can create the PR if you want.

:+1: I want :)

I would like to implement an asynchronous way of RemoteService object methods invocations. Need to think about it more deeply

I would like to implement an asynchronous way of RemoteService object methods invocations. Need to think about it more deeply

@mrniko Yeah, my point 2 is more like, as @jackygurui suggested, a fire and forget.
But asynchronous RemoteService would be great too, though I do not know how one would implements this.
A thought: if the client side detect that the a service interface method has a return value class Future , it then could magically switch in async mode.
So the programmer that make the interface can choose which methods he would like to be asynchronous:
public interface Greeter {

    String greet(String name);

    Future<String> greetAsync(String name);

}

I think to start from implementation of async calls support. I suggest follow way to make it.
We have some interface:
public interface MyService {
     String someMethod1(String name);
     String someMethod2(String name);
}

To make an async call of someMethod1 method all you need is to create an interface which repeats those methods which need to be called in async way.
public interface MyServiceAsync {
     Future<String> someMethod1(String name);
}

and finally get those methods:
MyServiceAsync asyncService = remoteService.getAsync(MyService.class, MyServiceAsync.class);

The reason why MyService.class is required because we need to check methods signature matching.
What do you think? @jackygurui @pierredavidbelanger

One thing I see:
With your suggestion, given that one would not be able to do something like that (because of the incompatible return type):
public class MyServiceImpl implements MyService, MyServiceAsync {}

this will make refactoring harder (or code harder to follow).
Imagine changing a signature in MyService  but not in MyServiceAsync
public interface MyService {
     String someMethod1Renamed(String name);
     String someMethod2(String name);
}
public interface MyServiceAsync {
     Future<String> someMethod1(String name);
}

This will make the code compile, execute, but fail at runtime when MyServiceAsync.someMethod1 is called.

This will make the code compile, execute, but fail at runtime when MyServiceAsync.someMethod1 is called.

Redisson will check it during get() operation invocation

This is what I am thinking:
public class MyClass {
      String someMethod1(String name);
      String someMethod2(String name);
      void someMethod3();
}

RRemoteService remoteService = redisson.getRemoteSerivce();
remoteService.register(MyClass.class);
MyClass instance = remoteService.get(MyClass.class)
remoteService.registerAsyncExec(instance, "someMethod2", new FutureListener<String>() {
            @Override
            public void operationComplete(Future< String > future) throws Exception {

            }
        });

remoteService.registerAsyncExec(instance, "someMethod3", new FutureListener<Void>() {
            @Override
            public void operationComplete(Future< Void > future) throws Exception {

            }
        });

Now calling someMethod2 and someMethod3 will return straight away, with null or void.

What do you think of something like that:

RRemoteService remoteService = Redisson.create().getRemoteSerivce();

RRemoteServiceAsync<MyClass> myClassAsync = remoteService.getAsync(MyClass.class);

myClassAsync.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result = future.get();
    }
}).someMethod1("HelloWorld");

All method future goes to the same listener?

In my last snippet, yeah, indeed, one should not re-use the return value of myClassAsync.with(...), or else, every invocation future will be listened by the same FutureListener.
If one want to call many methods, he would have to do this:
myClassAsync.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result1 = future.get();
    }
}).someMethod1("HelloWorld");

myClassAsync.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result2 = future.get();
    }
}). someMethod2("HelloWorld");

With my suggestion, you will need to introduce in the API:
This new signature in RRemoteService:
<T> RRemoteServiceAsync<T> getAsync(Class<T> remoteInterface);

And this new class:
public interface RRemoteServiceAsync<T> {
    T with(FutureListener futureListener);
}

The problem is you effectively have two independent instances. Not going to be suitable for every case.
How about this as a compromise:
myClassAsyncBuilder.with("someMethod1", new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result1 = future.get();
    }
});

myClassAsyncBuilder.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result2 = future.get();
    }
});

MyClass myClass = myClassAsyncBuilder.build();
myClass.someMethod1("HelloWorld"); //returns null immediately
myClass.someMethod2("HelloMe"); //returns null immediately

Maybe we can have both?
Have to say your proposal is neater than mine, since you don't have to mess with method names in string format.

I like the idea of a builder to register multiple listeners 👍
But I am not a fan of hardcoding method name as string.
This is what I was trying to escape with my suggestion.

Totally understand, your concern.
My worry is people can forget to swap instances:
MyClass mc1 = myClassAsync.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result1 = future.get();
    }
});
MyClass mc2 = myClassAsync.with(new FutureListener<String>() {
    @Override
    public void operationComplete(Future<String> future) throws Exception {
        String result2 = future.get();
    }
})

mc1.someMethod1("HelloWorld");
mc1.someMethod1("HelloWorld");
mc1.someMethod1("HelloWorld");
mc1.someMethod1("HelloWorld");
mc1.someMethod1("HelloWorld");
mc2.someMethod2("HelloMe");
mc2.someMethod2("HelloMe");
mc1.someMethod1("HelloWorld");
mc2.someMethod2("HelloMe");
mc2.someMethod2("HelloMe");
mc1.someMethod1("HelloWorld");
mc2.someMethod2("HelloMe");
mc1.someMethod1("HelloWorld");
mc2.someMethod2("HelloMe");
mc2.someMethod2("HelloMe");
mc1.someMethod1("HelloWorld");
mc1.someMethod2("HelloMe"); // oops !!

And imaging you have this situation:
public void doSomeStuff(MyClass mc) {
    mc.someMethod1("HelloWorld");
    mc.someMethod2("HelloMe");
    mc.someMethod3("Hello3");
    mc.someMethod4("Hello4");
    mc.someMethod5("Hello5");
}

It will end up like this:
public void doSomeStuff(MyClass mc1, MyClass mc2, MyClass mc3, MyClass mc4, MyClass mc5, ) {
    mc1.someMethod1("HelloWorld");
    mc2.someMethod2("HelloMe");
    mc3.someMethod3("Hello3");
    mc4.someMethod4("Hello4");
    mc5.someMethod5("Hello5");
}

That does not look very neat any more.

Yeah, this is a very good point..
I guess, with my suggestion, one would need to pass around the RRemoteServiceAsync<MyClass> instance, instead. And this will be no more neat nor convenient than your last doSomeStuff  method ..
I dont know .. this is puzzling me.
I will leave this problem to others :)
Anyway, in my applications, I like to control the client side thread pool, so I will not be the one using this async remote service feature anyways.
I will probably end up doing things in the old (not Redisson managed) way:
ExecutorService executorService = ...;
MyClass myClass = redisson.getRemoteSerivce().get(MyClass.class);
Future future = executorService.submit(() -> myClass. someMethod1("HelloWorld"));

I will probably end up doing things in the old (not Redisson managed) way

And get a thread busy per call?

@mrniko indeed, with this method I will lose the great Netty nio features ..

It is a shame that in java you can't subclass a final class. This wouldn't be an issue if it could. You could just return a subclass that implements Future.

can't subclass a final class.

I guess you can remove it via reflection

Also, I think you can create such a proxy:
Object returnValue = Proxy.newProxyInstance(classLoader,
        new Class[] {method.getReturnType(), Future.class},
        handler);

The handler will need to know about that though.
Also, the user will need to cast :
MyClass myClass = redisson.getRemoteSerivce().get(MyClass.class);
String result = myClass.someMethod1();
Future resultFuture = (Future) result;

Is this something you had in mind @jackygurui  ?

Why we can't do it like Jackson MixIn's?

@mrniko so, something like your first proposal :
public interface MyService {
     String someMethod1(String name);
     String someMethod2(String name);
}

public interface MyServiceAsync {
     Future<String> someMethod1(String name);
}

MyServiceAsync asyncService = remoteService.getAsync(MyService.class, MyServiceAsync.class);

The MyServiceAsync class act kind of like Jackson mixins.
In retrospect, I like your idea.
I guess you were right from the beginning :)

I can rewrite it in MixIn style:
public interface MyService {
     String someMethod1(String name);
     String someMethod2(String name);
}

@RRemoteMixIn(MyService.class)
public interface MyServiceAsync {
     Future<String> someMethod1(String name);
}

MyServiceAsync asyncService = remoteService.get(MyServiceAsync.class);

So you can use usual get() method. Redisson will validate MyServiceAsync during get() invocation.

Very nice 👍
I like that a lot.
The only drawback (that also exists with Jackson Mixins) is that signatures must match and no IDE can help you.

The only drawback (that also exists with Jackson Mixins) is that signatures must match and no IDE can help you.

Yep. But it's the only drawback, as I see. And minimalistic solution in terms of coding from user point of view.

Also, indeed, Redisson can help the user, during get() invocation, by validating that:
if the remoteInterface class is annotated with RRemoteMixIn, every methods in remoteInterface (ie: MyServiceAsync) exists with the same parameters in the declared @RRemoteMixIn's value (ie: MyService) and returns Future.
This way the code will fail fast in dev.

Of course, I suggested that "Redisson will validate MyServiceAsync during get() invocation"

I have just finished async interface support in #513. So I think we have implemented all ideas :)

Well done. Thank you!


rendering

@conda-forge-admin, please re-render

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I rerendered the recipe in conda-forge/qhull-feedstock#6.

rerender #7


Implementation of DG in Spark; Separated code for dg-spark-example

There are lots of ^M - seems to be windows EOL, that's why there's conflicts. I'll work on fixing those.

We learned in EtlMgmt, which uses github for its core scripts, that github is not configured to automatically remove carriage returns (which are represented as ^M). Svn can be configured to remove the unix-unfriendly characters which is why they had not previously been a problem.
Jean
DMD B21
Office:<PHONE_NUMBER>
Cell:<PHONE_NUMBER>
9513 Key West Avenue, Rockville, MD 20850
From: Mohamed Ibrahim<EMAIL_ADDRESS>Sent: Thursday, January 07, 2016 11:39 AM
To: FINRAOS/DataGenerator
Subject: Re: [DataGenerator] Implementation of DG in Spark; Separated code for dg-spark-example (#267)
There are lots of ^M - seems to be windows EOL, that's why there's conflicts. I'll work on fixing those.
—
Reply to this email directly or view it on GitHub[github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FINRAOS_DataGenerator_pull_267-23issuecomment-2D169721095&d=CwMCaQ&c=XK1GVu0Y2HvWRiFNJ9Hesw&r=-6iAiZKYsqGzW8p1LxwSTiua6kIjvl5RUzqXWwLkOrA&m=0iNJ5fSClV7aJtjkA9oLHjUDjdL9tRcVNYLCVrRoRfU&s=HXdkAbwE6P3yK2qkDNzlVT_q88NwDfDfPy6bviFzs4g&e=.
Confidentiality Notice::  This email, including attachments, may include non-public, proprietary, confidential or legally privileged information.  If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited.  If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately.  You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.

I'll work on those, as well as instantiating the consumer inside the parallelize portion & some other cleanup that I see as well. Will send from my repo including @Brijeshrpatel9 additions and commits.

already merged through a different PR


Unable to edit from a phone/narrow window

When you are using a phone (or other narrow screen) and go to edit mode, the structure/content buttons disappear completely.  This means you cannot edit the structure.
Also, while you can open content to edit, often once opened the edit iframe is too large to be used - the save etc buttons are off the edge of the screen, and I can't scroll sideways to get to them.
While primarily editing via laptops etc, occasionally it is useful to be able to make a quick edit while on the go, so having the editing interface being entirely unusable on mobile is bad.
I've also tested this on the aldryn demo site and the same behaviour is there, so it's not just my site.  It seems the structure/content/publish buttons disappear below 800px width, and by 550px the pop up edit boxes have lost their Cancel/Save buttons.
Maybe putting "overflow: scroll" as a media query for narrow screens on these elements would make it workable?
As a workaround, is there any way to enable the old (2.x) way of editing pages through the Django Admin interface?

Improving the interface for mobile devices (both in terms of layout and touch support is a goal for 3.2 and beyond CMS versions)
Old placeholder admin it's no longer available as fundamentally incompatible with the revamped 3.0 frontend editor

This has been addressed in 3.2, though we aim for a proper support on tablet rather than phone. Yet there are some modifications on phones as well (for example the toolbar menu or fullscreen modal) to make it more usable for quick edits:
http://www.django-cms.org/en/blog/2015/10/09/rc1-release-of-django-cms-32/