jdk_container left files owned by root

jdk_container left files on the host machine that are owned by root. These files cannot be cleaned by Jenkins job. It causes Jenkins job to fail.
12:05:52  ERROR: Cannot delete workspace :Unable to delete '/home/jenkins/workspace/Grinder/aqa-tests/TKG/output_17113857837219/jdk_container_0/work/scratch/2/jdk-sharedtmp/.com_ibm_tools_attach/_controller'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
[Pipeline] echo
12:05:52  Exception: hudson.AbortException: Cannot delete workspace: Unable to delete '/home/jenkins/workspace/Grinder/aqa-tests/TKG/output_17113857837219/jdk_container_0/work/scratch/2/jdk-sharedtmp/.com_ibm_tools_attach/_controller'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
[Pipeline] sh
12:05:53  + rm -rf /home/jenkins/workspace/Grinder/aqa-tests/TKG
12:05:53  rm: cannot remove '/home/jenkins/workspace/Grinder/aqa-tests/TKG/output_17113857837219/jdk_container_0/work/scratch/2/jdk-sharedtmp/.com_ibm_tools_attach/_controller': Operation not permitted
12:05:53  rm: cannot remove '/home/jenkins/workspace/Grinder/aqa-tests/TKG/output_17113857837219/jdk_container_0/work/scratch/2/jdk-sharedtmp/.com_ibm_tools_attach/_notifier': Operation not permitted

@sophia-guo @smlambert do you also see a similar issue at Adoptium Jenkins? Is there a better way to resolve this?

These tests were added around one and half years ago. As it's dev level may not run frequently. I didn't notice there is this issue. Check recent jdk21 seems no this issue.
https://ci.adoptium.net/view/Test_openjdk/job/Test_openjdk21_hs_dev.openjdk_x86-64_linux/

We should mark the node offline when there is an error Cannot delete workspace: Unable to delete ...

Is there any other way to clean up the crash files in the test code itself instead of marking it offline @llxia

Is there any other way to clean up the crash files in the test code itself instead of marking it offline @llxia

llxia is on vacation
Related:
https://stackoverflow.com/questions/42423999/cant-delete-file-created-via-docker

I think we also need to know why this happens. Does it only happen when impl=openj9|ibm as no issue reported  with jdk_container running against impl=hotspot.
Normally this permission issue happens if you run things as root inside the container while using a mapped volume from the host inside the container. The jdk_container tests map volumes options are like --volume /home/jenkins/workspace/jenkinsjobname/aqa-tests/TKG/output_***/jdk_container_0/work/classes/2/...., which is not the workdir. So shouldn't have this issue. Is there something specific to openj9|ibm caused this?

Is there any updates on this issue?
Is @llxia back from vacation?

I think we also need to know why this happens. Does it only happen when impl=openj9|ibm as no issue reported with jdk_container running against impl=hotspot.

If I had to guess, it happens when a testcase fails and doesn't cleanup after itself, then the workspace can not be deleted.  So @AswathySK perhaps check if that is the case and exclude the failing testcases.
Lan is not back from vacation and no one is pursuing this issue further at this time.  I suggest you dig in to answer some of the questions in this issue if you are interested in a different approach than taking the machine offline.

Just a note that PR of making the node offine has also been reverted, which might help @AswathySK your investigation?

@smlambert , when a test case fails it is not able to clean up after since the files created when it crashes are owned by root user. And yes I will do some more investigation on which all test cases we are seeing this issue.

So my point is, the reason we do not have a cleanup problem for Temurin is that there is not a failing/crashing testcase.
So your first task would be to see which testcase is crashing/failing, triage it by gathering any extra data you can, report the issue in the openj9 repo if it doesn't already exist, and exclude the test in the ProblemList files while the issue is being investigated and fixed by the openj9 team.

cleanWs() (at groovy level) happens after the jdk_container is exited. jdk_container is a openjdk tests which does not belong to us.

Has anyone tried removing the files as the jenkins user via any random container as the root user? As much as that could be a hack workaround, it is probably easy to add a step to our cleanup scripts to remove everything inside the workspace dir via a container. cc @AswathySK


main.bb

main documentation in french

I hope I am doing right.

Looks correct to me. Nice work.  It seems like you are learning git well.
Don't close these. Just wait for someone to merge them.

I did that with the webinterface.


Decouple Twig from Adroit

It might be worthwhile to decouple Twig from Adroit and create an separate adroit-twig package just for the TwigResponder.

I'd suggest to decouple them. The TwigResponder is yet another unnecessary dependency and bloat up the framework. From my point of view the JsonResponder should be enough.

Decouple but don't delete it. I'm using it.

@cookiekiller What about a adroit-twig package (I'd suggest to call it bitexpert/twigastic)?
@shochdoerfer Was there any decision made?

Id love to do it but I am not sure if right now is a good time to do it as we havent gained much experience to understand if the Responder interface makes sense. I do not want to constantly change the interface and change the dependant packages as well. That would be way too much effort.
Ideally we would be able to find an agreement with @pmjones (and others) on a standard interface for actions, responders and the domain payload object to drive forward the collaboration between the different ADR implementations.

Twig integration has been moved to bitexpert/adrenaline where it will possibly become a separate package in near future (to discuss).
For Adroit this one is closed by #23


Forward, backward data and backward weight convolution solver with fp8/bfp8 compute datatype.

Enable the support of forward, backward data and backward weight convolution solver with fp16->fp8/bfp8 compute type in MIOpen.
The original input, weight and output tensors are fp16 datatype. Then the tensors are casted to the proper compute type to do the convolution operation utilizing CK kernels. More specific, the following fp16->fp8/bfp8 convolutions are enabled as requested from framework and the current kernels support of CK teams:
Forward: input fp16->fp8, filter fp16->fp8, output fp32->fp16.
Backward data: filter fp16->fp8, output fp16->bf8, input fp32->fp16.
Backward weight: input fp16->fp8, output fp16->bf8, filter fp32->fp16.

@iq136boy

the following fp16->fp8/bfp8 convolutions are enabled as requested from framework...
...
Backward data: filter fp16->fp8, output fp16->bf8, input fp32->fp16.
Backward weight: input fp16->fp8, output fp16->bf8, filter fp32->fp16.

Do they really want to reduce backwards pass precision down to f8 types? For speed?

Do they really want to reduce backwards pass precision down to f8 types? For speed?

@atamazov Yes. I also have the same concern before starting this task and has talked with Jehandad about it. Both forward and backward are requested by framework. They asked CK team to add the kernels and then asked us to integrated these kernels into MIOpen.


WFLY-5685 Deployment-specific caches do not expose management metrics operations

https://issues.jboss.org/browse/WFLY-5685

Tests?

retest this please


How to list api gateway apis ??

Good morning, guys, all right?
I'd like to know if there's this "aws apigateway get-rest-apis" feature (https://docs.aws.amazon.com/cli/latest/reference/apigateway/get-rest-apis.html), in russian, because I didn't find .
thankful.

@dialMForMonkey this is what you're looking for: https://docs.rs/rusoto_apigateway/0.43.0-beta.1/rusoto_apigateway/trait.ApiGateway.html#tymethod.get_rest_apis. Let me know if a code example will suffice.

Thank you. It's resolved here


Add local dev steps to the README

It would be nice to add a few steps for people who want to run the use-contractkit monorepo locally.

While minimal, there are instructions here: https://github.com/facebook/create-react-app/pull/11764

I think its just  yarn and  yarn dev from the root directory


Improve user interface for the dask dashboard

Thank you for contributing! 🎉
Summary of the most important changes
This pull request introduces:

[x] a new module for managing the Dask cluster and integrates it with the existing codebase and adds a function to set the dashboard link for the Dask cluster and updating the cmorizer module to use this new function.
[x] Reports the pymorize ssh-tunnel command that you need to run in your laptop

New module for Dask cluster management:

src/pymorize/cluster.py: Added a new module containing the set_dashboard_link function to manage the Dask cluster's dashboard link, including handling errors when the cluster is not launched from JupyterHub.

Integration with existing codebase:

src/pymorize/cmorizer.py: Imported the set_dashboard_link function from the new cluster module and used it in the _post_init_create_dask_cluster method to set the dashboard link for the SLURMCluster. [1] [2] in this PR.

Checklist

[x] I have tested the changes in this PR.
[x] I have updated the documentation.
[ ] If I have made a new step which requires new arguments, these are added to the validate.py file
so that the user can see documentation for the arguments.

For some reason I cannot explore right now, the tests are broken. Other than that, I think is ready to be reviewed.

Thanks @pgierz for the fixes!!!


Where to go after designing your app UI with Glade?

I have experience with GUI applications done with PySide (Qt bindings for Python). But with these bindings I have no idea what should I do after designing the application's interface with Glade.

Load the glade file with a gtk.Builder. check out its API for more info.
On Jan 1, 2015 2:16 PM, "Jorge Araya Navarro"<EMAIL_ADDRESS>wrote:

I have experience with GUI applications done with PySide (Qt bindings for
Python). But with these bindings I have no idea what should I do after
designing the application's interface with Glade.
—
Reply to this email directly or view it on GitHub
https://github.com/conformal/gotk3/issues/99.

Load the glade file with a gtk.Builder. check out its API for more info.
On Jan 1, 2015 2:16 PM, "Jorge Araya Navarro"<EMAIL_ADDRESS>wrote:

I have experience with GUI applications done with PySide (Qt bindings for
Python). But with these bindings I have no idea what should I do after
designing the application's interface with Glade.
—
Reply to this email directly or view it on GitHub
https://github.com/conformal/gotk3/issues/99.

Oh, I see!
Thank you!
weberc2 writes:

Load the glade file with a gtk.Builder. check out its API for more info.
On Jan 1, 2015 2:16 PM, "Jorge Araya Navarro"<EMAIL_ADDRESS>wrote:

I have experience with GUI applications done with PySide (Qt bindings for
Python). But with these bindings I have no idea what should I do after
designing the application's interface with Glade.
—
Reply to this email directly or view it on GitHub
https://github.com/conformal/gotk3/issues/99.

Reply to this email directly or view it on GitHub:
https://github.com/conformal/gotk3/issues/99#issuecomment-68497110

--
Pax et bonum.
Jorge Araya Navarro.
ES: Diseñador Publicitario, Programador Python y colaborador en Parabola GNU/Linux-libre
EN: Ads Designer, Python programmer and contributor Parabola GNU/Linux-libre
EO: Anonco grafikisto, Pitino programalingvo programisto kai kontribuanto en Parabola GNU/Linux-libre
https://es.gravatar.com/shackra


Style Search page and 3 tab components

Summary
This code styles the Search page and its 3 tab components: Background, Mentorship, and Interests.
Updates
Mockup:

Feature branch:

Testing Instructions

In the main branch, run git pull in your terminal to retrieve all updates, then switch to feature branch with git checkout lc80-fe-styleSearchPage
Start the dev environment with npm start
In your browser, navigate to the /search route to view the build of the hi-fi mockup. Click between the 3 tabs to see each component.

Hey Jenny before you merge, what is the css folder for?


Homebridge returns an error despite config.json validating

Really love the sounds of this but can't seem to fathom what is going wrong. My homebridge setup is running fine with my LIFx bulbs but for some reason this will not work. Here is the error that homebridge returns:
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::51826
    at Object.exports._errnoException (util.js:1026:11)
    at exports._exceptionWithHostPort (util.js:1049:20)
    at Server._listen2 (net.js:1257:14)
    at listen (net.js:1293:10)
    at Server.listen (net.js:1389:5)
    at EventedHTTPServer.listen (/usr/local/lib/node_modules/hap-nodejs/lib/util/eventedhttp.js:60:19)
    at HAPServer.listen (/usr/local/lib/node_modules/hap-nodejs/lib/HAPServer.js:158:20)
    at Bridge.Accessory.publish (/usr/local/lib/node_modules/hap-nodejs/lib/Accessory.js:496:16)
    at Server._publish (/usr/local/lib/node_modules/homebridge/lib/server.js:111:16)
    at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:88:10)
    at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:40:10)
    at Object.<anonymous> (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)

And here is my config.json file:
{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "031-45-154"
    },

    "description": "This is a configuration file with platforms and accessories for my home automation system.",

    "accessories": [
	{
	  "accessory": "SkyPlusHDBox",
	  "name": "BSkyB",
	  "ipAddress": "<IP_ADDRESS>",
	  "region": "granada"
	}
     ],

    "platforms": [
        {
            "platform" : "LifxLan",
            "name" : "LiFx"
        }
    ]
}

Hey there,
From the error it looks as though homebridge is trying to run twice on the same port. If you remove the Sky plugin do you see the same error message?
If so, you'll need to kill whatever other homebridge process is running. You can do this by typing: pkill homebridge
On 14 November 2016 at 15:36:41, Aaron (notifications@github.com(mailto:notifications@github.com)) wrote:

Really love the sounds of this but can't seem to fathom what is going wrong. My homebridge setup is running fine with my LIFx bulbs but for some reason this will not work. Here is the error that homebridge returns:
events.js:160 throw er; // Unhandled 'error' event ^ Error: listen EADDRINUSE :::51826 at Object.exports._errnoException (util.js:1026:11) at exports._exceptionWithHostPort (util.js:1049:20) at Server._listen2 (net.js:1257:14) at listen (net.js:1293:10) at Server.listen (net.js:1389:5) at EventedHTTPServer.listen (/usr/local/lib/node_modules/hap-nodejs/lib/util/eventedhttp.js:60:19) at HAPServer.listen (/usr/local/lib/node_modules/hap-nodejs/lib/HAPServer.js:158:20) at Bridge.Accessory.publish (/usr/local/lib/node_modules/hap-nodejs/lib/Accessory.js:496:16) at Server._publish (/usr/local/lib/node_modules/homebridge/lib/server.js:111:16) at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:88:10) at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:40:10) at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22) at Module._compile (module.js:570:32) at Object.Module._extensions..js (module.js:579:10) at Module.load (module.js:487:32) at tryModuleLoad (module.js:446:12)
And here is my config.json file:
{ "bridge": { "name": "Homebridge", "username": "CC:22:3D:E3:CE:30", "port": 51826, "pin": "031-45-154" }, "description": "This is a configuration file with platforms and accessories for my home automation system.", "accessories": [ { "accessory": "SkyPlusHDBox", "name": "BSkyB", "ipAddress": "<IP_ADDRESS>", "region": "granada" } ], "platforms": [ { "platform" : "LifxLan", "name" : "LiFx" } ] }
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub(https://github.com/shauncampbell/homebridge-sky-plus-hd/issues/2), or mute the thread(https://github.com/notifications/unsubscribe-auth/AAw1MxIs2UUqgGp7xqX0ivGU5B2ZIsqDks5q-IAJgaJpZM4KxdAw).

@shauncampbell that makes sense, I have homebridge set to boot on startup. Any idea if killing the other homebridge process would have the desired effect?

It should do.
On 14 November 2016 at 16:15:16, Aaron (notifications@github.com(mailto:notifications@github.com)) wrote:

@shauncampbell(https://github.com/shauncampbell) that makes sense, I have homebridge set to boot on startup. Any idea if killing the other homebridge process would have the desired effect?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub(https://github.com/shauncampbell/homebridge-sky-plus-hd/issues/2#issuecomment-260380562), or mute the thread(https://github.com/notifications/unsubscribe-auth/AAw1M_hlVEeKQ6dg5QOOtSk1_yAhFO63ks5q-IkUgaJpZM4KxdAw).

@shauncampbell just tried:
pkill: killing pid 534 failed: Operation not permitted

If you've got it set to run on start up it's probably running as root. Try running:
sudo pkill homebridge
Instead
On 14 November 2016 at 16:19:22, Aaron (notifications@github.com(mailto:notifications@github.com)) wrote:

@shauncampbell(https://github.com/shauncampbell) just tried:
pkill: killing pid 534 failed: Operation not permitted
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub(https://github.com/shauncampbell/homebridge-sky-plus-hd/issues/2#issuecomment-260381730), or mute the thread(https://github.com/notifications/unsubscribe-auth/AAw1M0Z1AUWy-CjylVJQz3-RkHs_9PMPks5q-IoKgaJpZM4KxdAw).

@shauncampbell of course, yeah. Completely forgot haha.
I've just run that, it seemingly killed the process but running homebridge returns the same error.


feat: use stacked component in nft card

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3708

PR #3709

PR #3710

PR #3711

PR #3712

PR #3713   👈

This comment was auto-generated by Graphite.

@wraeth-eth started a stack merge that includes this pull request via Graphite.

Graphite rebased this pull request as part of a merge.

@wraeth-eth merged this pull request with Graphite.


updated recipe

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged) 0 --> 1
[x] Reset the build number to 0 (if the version changed) NA
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@raivivek Would you like to be added to the maintainers list here?
SUMMARY:
The three recipes (seqlike, weblogo, python-codon-tables) were managed by bioconda channel. Since the maintainers of seqlike wanted it on conda-forge, we ported all three libraries from bioconda channel to conda-forge channel, with permission from bioconda-core-team. The other two libraries (weblogo, python-codon-tables) are dependencies of seqlike.
NOTE: Once the transfer happens, the bioconda recipes of the three packages will cease to exist.
See (here) and (here)
cc: @dpryan79 (from bioconda team)

bioconda:seqlike recipe: https://github.com/bioconda/bioconda-recipes/blob/d41cdd4ae1ee428c612b12a52c96d530d238bb4e/recipes/seqlike/meta.yaml#L52-L53

Hi @sugatoray, yes sure. Please add me as a maintainer. Thanks!


[Task]: Deduplicate components & Grayscale/theming support in template details page

Issues with template details page:

Space required after Note:

Modal isn’t getting dismissed as expected https://www.loom.com/share/d7030d113b694edfa33e7eca9a4d343b

Change View Templates to sentence casing

Button component is used instead of link for Go back and View Templates


README: Buildkite badge should show status of the master branch; Codecov badge does not require token

If the repo is public, you don't need a token for the Codecov badge.
cc: @maleadt (I don't think you are "Watching" this repo?)

Merged, thanks!

Merged, thanks!


mTLS gateway automated test

Description
Created automated test and add it to GH action. Test should create httpbin, mTLS gateway with cacert and expose it with Istio VS. Calls with cert and w/o cert to the httpbin should be tested. Test should be part of regular integration tests as well as upgrade integration tests.

[ ] integration test added to GH Action
[ ] documentation
[ ] green pipeline

Reasons
Test automation
DoD:
- [ ] Create a follow-up issue.
- [ ] Provide unit tests.

[ ] Provide integration tests.
[ ] Provide documentation.
[ ] Test on a production-like environment.
- [ ] Verify if the solution works for both open-source Kyma and SAP BTP, Kyma runtime.
- [ ] Check the outcome of all related pipelines.
- [ ] Verify resource limits.
[ ] As a PR reviewer, verify code coverage and evaluate if it is acceptable.
- [ ] Create a release.
- [ ] Add release notes and What's New notes for Kyma customers.

Attachments
https://github.com/kyma-project/application-connector-manager/blob/main/application-connector-dependencies.yaml

we decided that this test will not bring any value


ModPowL may entry a loops when set exponent to "0L"

Description
When set exponent and modulus to 0L, in the source code, the function ModPowL should not enter the loop and return 1L. However, in the following test case, there is a Unhandled exception which indicates there is a divide by zero operation.
source code
https://github.com/microsoft/qsharp-runtime/blob/f56539bd799c5f47e01a9baf648b63a063b21a88/src/Simulation/QSharpFoundation/Math/Math.qs#L327
Testcase
namespace NISLNameSpace {
	open Microsoft.Quantum.Math;
	open Microsoft.Quantum.Intrinsic;

	@EntryPoint()
	operation main() : Unit {
		let value = 1L;
		let exponent = 0L;
		let modulus = 0L;
		let NISLModPowL = ModPowL(value,exponent,modulus);
		Message($"{value}");
		Message($"{exponent}");
		Message($"{modulus}");
		Message($"{NISLModPowL}");
	}
}

Environment
operating system : Windows 10 and Ubuntu 18.06
dotnet version : 6.0.400
QDK : 0.25.228311

The real running code is here.
https://github.com/microsoft/qsharp-runtime/blob/1ac2e3cd154145536fab030b728b4439526d2bb3/src/Simulation/QSharpFoundation/Math/Math.cs#L105
It raises an exception correctly because this program tries to make the divisor 0. Moreover, I'd like to know when this code will execute, because this may decide whether it is necessary to add more operation for the situation that modulus=0.


Annoying "defined 'protocol' as 'http'" for every consul_prepared_query resource

Fix related to #410

added 'protocol' variable to the 'nprepared_queries'
changes compatibile to the 'consul_acl' and 'consul_key_value'

Hi @bastelfreak I will change my email and put some tests ...

Thanks. It also needs to be rebased after https://github.com/solarkennedy/puppet-consul/pull/437 got merged?


feat: add Auto member_order option

This PR adds a member_order argument to Auto that decides how members should be sorted. There are two options:

"alphabetical": sorted alphabetically (e.g. a first, z last)
"source": in order they appear in the source code

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.65%. Comparing base (5ed1430) to head (04c1b17).

Files with missing lines
Patch %
Lines

quartodoc/builder/blueprint.py
80.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #373      +/-   ##
==========================================
+ Coverage   88.63%   88.65%   +0.02%
==========================================
  Files          37       37
  Lines        2939     2953      +14
==========================================
+ Hits         2605     2618      +13
- Misses        334      335       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Enforcing Style

Enforcing style
Example case
The output of the following command can be used as reference for this section's comments.
atlas generate model --help
The following message should not appear in the output.

Note: Model name should be singular and lowercase.

It should be Atlas' responsibility to ensure that the generated model names are always lowercase (given that this is a style constraint that can be checked with your linter). The comment clutters the terminal view.
Desired feature
You should not be suggesting style, you should be enforcing it. Your cli should only be able to generate properly linted code (right now it allows rule breaks).

f15a26fc0c09b9dc8c8039f141461bd9ad567f53


Claudio/rust alloc ghaction

Closing in favour of #4223 (change to master)

Closing in favour of #4223


Node Unresolved Conflicts and Doc Clarifications

We are trying to improve our AEM development practices. The first step of that for us is to determine the best path for an initial sync to local development environments. The biggest barrier has been, predictably, the time required to sync "/content" and, more specifically, "/content/dam."
What I've done so far is install Grabbit v3.0.5 on our AEM 6.0 SP3 server and v.3.0.5 on a clean, local AEM 6.2. I don't know if the versions need to be matching or not (I've had mixed results), but that may be a secondary concern. For POC purposes, I am using the Grabbit shell knowing that it's just curl-ing the servlets.
I have two issues:

For this run, I am disabling all workflows through JCR properties instead of specifying them in the configuration JSON. Using a very basic config file of (sensitive information replaced):

{
    "serverUsername" : "****",
    "serverPassword" : "****",
    "serverHost" : "someserver",
    "serverPort" : "8081",
    "deltaContent" : true,
    "pathConfigurations" :  [
        {
            "path" : "/content/dam"
        }
    ]
}

What I find during this run is that I receive no errors while syncing, yet the job seems to end prematurely with a "COMPLETED" status. Is this expected behavior based on "deltaContent" or some batch/job/other configurations in the Grabbit code?

For this run, I have all out-of-the-box AEM 6.2 workflows enabled via JCR properties. The configuration JSON specifies workflows to skip, based on the documentation:

{
    "serverUsername" : "****",
    "serverPassword" : "****",
    "serverHost" : "someserver",
    "serverPort" : "8081",
    "deltaContent" : true,
    "pathConfigurations" :  [
        {
            "path" : "/content/dam",
            "workflowConfigIds" :
                [
                    "/etc/workflow/launcher/config/update_asset_mod",
                    "/etc/workflow/launcher/config/update_asset_create",
                    "/etc/workflow/launcher/config/dam_xmp_writeback"
                ]
        }
    ]
}

What I've noticed with this configuration is a couple things... First, I'm knowingly not ignoring as many workflows as I would really want to (eg. workflow to pull images from .doc files). The issue with this configuration is that I often get JCR exceptions of "Unresolved conflict at /content/xyz/etc..." I'm having issues recreating the stack trace as I write this out and will update when I can do so. Part of the issue is that it's not predictable behavior. My gut tells me it's an issue of a DAM asset being added, a workflow doing something like creating renditions or parsing images, then trying to save to the JCR while Grabbit's session hasn't saved its batch to the JCR.
As I get reproducible stack traces and errors, I can update the issue. Not sure if these are config issues, workflow issues, or v.3.0.5 issues. Happy to provide any additional details as well!

Hey @dscirto!
I'm actually super surprised you were able to install Grabbit 3 on an AEM 6.2 instance. I've never tried, and I haven't heard of anyone else who has tried either. I would be careful on that - it may produce some undefined behavior.  https://github.com/TWCable/grabbit/blob/master/docs/AEMSupport.adoc defines our support for various versions of AEM. Grabbit support for AEM 6.0 was fairly short lived, so it may be a bit better; but it hasn't gotten a ton of attention.
In general, we support any configuration where servers share the same common major Grabbit version, on the same AEM platform. Grabbit has been known to be used for syncing between AEM versions, and certain Grabbit versions (e.g CQ5.6 -> AEM 6.1 w/ Grabbit 3 -> Grabbit 4), but it is sort of off-the-record, because it comes with big gotchas. The biggest of which are node definition incompatibilities between AEM versions (some I believe are with DAM content); Grabbit does not have any sort of data transformation behavior; It's simply a data sync tool.
For number 1, did the jobs status say it wrote any nodes? It is certainly possible that if you had synced that path previously; that with the delta sync option, you would see quick completion. I would take a look at the logs and see if you see anything suspicious if you think something abnormal is going on.

Hey, thanks for the response!
As far as I can tell, minus the issues above, using a previous version on a newer instance of AEM 6.2 hasn't run into any problems! I did run into issues with deprecated JCR node types -- but we have deprecated our use of them so I'm just manually ignoring those paths. No harm done.
For number 1, all of the output points to a successful sync. I'm going to spin up a fresh AEM 6.2 instance (to be synced from AEM 6.0, as described previously) and turn on DEBUG log level for Grabbit and post what I find.
While that runs, I'll expand on the issue. Grabbit seems to traverse the JCR at "content/dam" normally with no exceptions. I see normal log output for assets being added properly up until the same point of the JCR (arbitrarily "content/dam/m"). At this point (and always at the same point), I get log output that the job has successfully finished with a "COMPLETED" status. The problem is that it doesn't sync "content/dam/n-z," which doesn't seem to be expected behavior.
What's funnier is that if, right after the "successful" sync, I can run the exact same job. I get minimal output, which I expect because it doesn't need to sync "content/dam/a-m." Refreshing the JCR in the target AEM, however, shows the missing "content/dam/n-z" JCR nodes. Those nodes, however, have no content in them (just the JCR tree structure) and there is no log output.
So number 1 is really two separate issues... First is that the job abbending (lack of a better term) but returning successfully. Second is that a second call to the same job seems to write the skelecton for the missing JCR nodes, but not the content. I suspect "deltaContent" may be a factor for the second issue, but not the first.
Once this sync with debugging wraps up, I'll post some logs and maybe we can get to the bottom of it.

Here's some follow-up information.
Sync run from AEM 6.0 => AEM 6.2 both running Grabbit v3.0.5. All workflows on AEM 6.2 instance disabled via JCR properties.
config.json
{     "serverUsername" : "****",     "serverPassword" : "****",     "serverHost" : "****",     "serverPort" : "8081",     "pathConfigurations" :  [         {             "path" : "/content/dam"         }     ] }
Job status upon completion
{     "jobExecutionId":<PHONE_NUMBER>744243000,     "jcrNodesWritten": 64157,     "exitStatus": {       "exitDescription": "",       "exitCode": "COMPLETED",       "running": false     },     "endTime": "2016-10-11T14:58:46+0000",     "timeTaken": 607566,     "path": "/content/dam",     "startTime": "2016-10-11T14:48:39+0000"   }
As I expected, the job finished at the same JCR node as I mentioned before and did not traverse the rest of the tree. Note that this time I removed "deltaContent" to see if it was possibly miscalculating whether or not to sync these missing nodes. Unfortunately, I did not see anything worthwhile in the DEBUG logs on either AEM server.
I ran the exact same job again to see if, as I described above, a second run would populate a skeleton of the missing JCR nodes. What I found is that, probably because I removed "deltaContent," it simply repeated the behavior of the first run.
{     "jobExecutionId":<PHONE_NUMBER>017628700,     "jcrNodesWritten": 64157,     "exitStatus": {       "exitDescription": "",       "exitCode": "COMPLETED",       "running": false     },     "endTime": "2016-10-11T15:36:20+0000",     "timeTaken": 524495,     "path": "/content/dam",     "startTime": "2016-10-11T15:27:35+0000"   }
I ran the job a third time with "deltaContent" added for only the third run. This time, I got what I expected -- the missing JCR nodes now present, but without the actual content. Here is the resulting job status:
{     "jobExecutionId":<PHONE_NUMBER>116302000,     "jcrNodesWritten": 29548,     "exitStatus": {       "exitDescription": "",       "exitCode": "COMPLETED",       "running": false     },     "endTime": "2016-10-11T17:30:04+0000",     "timeTaken": 92767,     "path": "/content/dam",     "startTime": "2016-10-11T17:28:31+0000"   }

I decided to cherry pick a couple of files and look through the logs with DEBUG on -- one file that came in from the successful runs (1) and one file that had the JCR structure but no content (2):

nav_aboutus2.jpg
Google.pdf

What I found is that files that had their content synced successfully had two outputs in the log files (ellipses manually used to obfuscate JCR structure):
*DEBUG* [clientJobLauncherTaskExecutor-1] com.twcable.grabbit.jcr.ProtoNodeDecorator Added mixin mix:versionable for : nav_aboutus2.jpg.
and
*INFO* [pool-6-thread-5] com.adobe.cq.creativecloud.filesync.impl.events.SyncEventGenerator Asset added at /content/dam/.../nav_aboutus2.jpg.
However, "Google.pdf" is absent from the logs entirely.

"While that runs, I'll expand on the issue. Grabbit seems to traverse the JCR at "content/dam" normally with no exceptions. I see normal log output for assets being added properly up until the same point of the JCR (arbitrarily "content/dam/m"). At this point (and always at the same point), I get log output that the job has successfully finished with a "COMPLETED" status. The problem is that it doesn't sync "content/dam/n-z," which doesn't seem to be expected behavior.
What's funnier is that if, right after the "successful" sync, I can run the exact same job. I get minimal output, which I expect because it doesn't need to sync "content/dam/a-m." Refreshing the JCR in the target AEM, however, shows the missing "content/dam/n-z" JCR nodes. Those nodes, however, have no content in them (just the JCR tree structure) and there is no log output"

I would try just syncing the path in question to see what happens. It could be that after the first run, the session just wasn't done persisting changes. In some configurations, you can find statements in the log like "[session-149] Saving 100 nodes..", etc. If that's not it, I would be more suspicious of the AEM 6.2 side of things (maybe a bad node definition, etc), than delta sync - just because delta sync is pretty straightforward functionality, and pretty well vetted at this point. But if there is a bug in delta sync, we definitely want to know about it! Delta sync is designed to be pessimistic; In other words, if it can't determine that a path is already up-to-date, it syncs it anyway.

"As I expected, the job finished at the same JCR node as I mentioned before and did not traverse the rest of the tree. Note that this time I removed "deltaContent" to see if it was possibly miscalculating whether or not to sync these missing nodes. Unfortunately, I did not see anything worthwhile in the DEBUG logs on either AEM server.
I ran the exact same job again to see if, as I described above, a second run would populate a skeleton of the missing JCR nodes. What I found is that, probably because I removed "deltaContent," it simply repeated the behavior of the first run."

Cool, yeah, without delta sync it should send all of the nodes previous across.

"I decided to cherry pick a couple of files and look through the logs with DEBUG on -- one file that came in from the successful runs (1) and one file that had the JCR structure but no content (2):

nav_aboutus2.jpg
Google.pdf

What I found is that files that had their content synced successfully had two outputs in the log files (ellipses manually used to obfuscate JCR structure):
DEBUG [clientJobLauncherTaskExecutor-1] com.twcable.grabbit.jcr.ProtoNodeDecorator Added mixin mix:versionable for : nav_aboutus2.jpg.
and
INFO [pool-6-thread-5] com.adobe.cq.creativecloud.filesync.impl.events.SyncEventGenerator Asset added at /content/dam/.../nav_aboutus2.jpg.
However, "Google.pdf" is absent from the logs entirely."

I don't think we log out all of the nodes we sync, but I could be wrong - too much log. You lost me a bit with the note about one having no content. Are you saying an asset node sync'd without it's binary data?
If you see what appear to be strange things happening for certain paths, I would create a configuration for just that path (to drown out noise, and eliminate side effects), then test to see what happens. I would also keep an eye on your normal error.log too; If the stack gets popped outside of a Grabbit stack frame it may end up in there instead of the batch logs. Let me know if you get better luck!

I would try just syncing the path in question to see what happens. It could be that after the first run, the session just wasn't done persisting changes. In some configurations, you can find statements in the log like "[session-149] Saving 100 nodes..", etc. If that's not it, I would be more suspicious of the AEM 6.2 side of things (maybe a bad node definition, etc), than delta sync - just because delta sync is pretty straightforward functionality, and pretty well vetted at this point. But if there is a bug in delta sync, we definitely want to know about it! Delta sync is designed to be pessimistic; In other words, if it can't determine that a path is already up-to-date, it syncs it anyway.

Yeah at this point, "deltaSync" doesn't seem to be the cause of any issues. It looks like it works entirely how it's supposed to. Always good to eliminate one possibility! What I've done in the interim is write a script to retrieve every child node of "content/dam" and generate the config.json dynamically. So I end up with a config.json that looks more like this:
{     "serverUsername" : "****",     "serverPassword" : "****",     "serverHost" : "myserver",     "serverPort" : "8081",     "pathConfigurations" :  [       {         "path": "/content/dam/a"       },       {         "path": "/content/dam/b"       },       {         "path": "/content/dam/c"       },       {         "path": "/content/dam/d"       },       {         etc... etc...       }     ] }
The good news is that, at least for assets in the DAM, it seems to work as intended. Note that I still need to manually disabled all workflows, otherwise "Unresolved conflict" still gets thrown.

I don't think we log out all of the nodes we sync, but I could be wrong - too much log. You lost me a bit with the note about one having no content. Are you saying an asset node sync'd without it's binary data?

If you see what appear to be strange things happening for certain paths, I would create a configuration for just that path (to drown out noise, and eliminate side effects), then test to see what happens. I would also keep an eye on your normal error.log too; If the stack gets popped outside of a Grabbit stack frame it may end up in there instead of the batch logs. Let me know if you get better luck!

As far as I can tell, turning the log level to DEBUG for Grabbit does give output for each node that is synced... But because there are so many, I can't say with certainty. As for the bit of confusion, I might be using too many words to describe the problem. Sorry!
For example, let's say we have an arbitrary JCR such as:
/content/dam/a
/content/dam/b
/content/dam/c
...
/content/dam/z
Specifying a path in a config.json of "content/dam" and running a job works great... up until around "content/dam/m." At this point, the job stops and returns a completed status such as posted previously. It doesn't reach n-z when syncing.
Changing absolutely nothing and simply running the same exact job, it skips a-m (which is good!) and syncs nodes n-z... But yes, without its binary data.
Manually specifying each child node under "content/dam" syncs nodes a-z exactly as intended, so there are no issues of mismatched node definitions between versions, etc etc...

Yeah at this point, "deltaSync" doesn't seem to be the cause of any issues. It looks like it works entirely how it's supposed to. Always good to eliminate one possibility! What I've done in the interim is write a script to retrieve every child node of "content/dam" and generate the config.json dynamically. So I end up with a config.json that looks more like this:

{ "serverUsername" : "****", "serverPassword" : "****", "serverHost" : "myserver", "serverPort" : "8081", "pathConfigurations" : [ { "path": "/content/dam/a" }, { "path": "/content/dam/b" }, { "path": "/content/dam/c" }, { "path": "/content/dam/d" }, { etc... etc... } ] }

This method, unfortunately, does not seem to work outside of the DAM. When attempting to sync the rest of the nodes under "/content" in a similar configuration as above, I end up with quite a few javax.jcr.InvalidItemStateException:
13.10.2016 12:45:06.468 *ERROR* [Thread-184] com.day.cq.wcm.msm.impl.RolloutManagerImpl Exception during process of event {} com.day.cq.wcm.api.WCMException: javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /content/somepath/home/blahblah/something/jcr:content 	at com.day.cq.wcm.msm.impl.RolloutManagerImpl.save(RolloutManagerImpl.java:1059) 	at com.day.cq.wcm.msm.impl.RolloutManagerImpl.access$1200(RolloutManagerImpl.java:106) 	at com.day.cq.wcm.msm.impl.RolloutManagerImpl$PageEventProcessor.call(RolloutManagerImpl.java:1198) 	at com.day.cq.wcm.msm.impl.RolloutManagerImpl$PageEventProcessor.call(RolloutManagerImpl.java:1152) 	at java.util.concurrent.FutureTask.run(Unknown Source) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 	at java.lang.Thread.run(Unknown Source) Caused by: javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /content/somepath/home/blahblah/something/jcr:content 	at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:237) 	at org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) 	at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:594) 	at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:461) 	at org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:435) 	at org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.perform(SessionImpl.java:432) 	at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:216) 	at org.apache.jackrabbit.oak.jcr.session.SessionImpl.perform(SessionImpl.java:140) 	at org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:432) 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 	at java.lang.reflect.Method.invoke(Unknown Source) 	at org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:113) 	at com.sun.proxy.$Proxy8.save(Unknown Source) 	at com.day.cq.wcm.msm.impl.RolloutManagerImpl.save(RolloutManagerImpl.java:1053) 	... 7 common frames omitted Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved conflicts in /content/somepath/home/blahblah/something/jcr:content 	at org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:84) 	at org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyChanged(ConflictValidator.java:60) 	at org.apache.jackrabbit.oak.spi.commit.CompositeEditor.propertyChanged(CompositeEditor.java:91) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyChanged(EditorDiff.java:93) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:596) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:456) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:531) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:487) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:583) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:418) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:583) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:418) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:583) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:418) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:583) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) 	at org.apache.jackrabbit.oak.plugins.segment.MapRecord.compare(MapRecord.java:418) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:583) 	at org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) 	at org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54) 	at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61) 	at org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.prepare(SegmentNodeStore.java:405) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.optimisticMerge(SegmentNodeStore.java:428) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.execute(SegmentNodeStore.java:484) 	at org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore.merge(SegmentNodeStore.java:162) 	at org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.merge(ProxyNodeStore.java:43) 	at org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247) 	at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:313) 	at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:459) 	... 18 common frames omitted
This is the behavior that I was experiencing in my original post, number 2. It looks like over large node sets, Grabbit runs into JCR concurrency issues.
This is the behavior that I'm most concerned about and would like to understand.

Did you try just syncing the problem paths in isolation? e.g ('content/dam/m' from your example)?
I know your script for creating subpath configs from a path is probably just for testing, but I don't know...I just wouldn't go there. It's probably a deep, dark rabbit-hole. I would find out why it's failing when giving Grabbit a parent level config, and go from there. It looks like your stacktrace issue occurs within msm - there might be workflow nastiness associated with saving a bunch of close paths in different sessions, or something.
Also, did you already mention why you are not turning off all workflows within Grabbit?

Yeah, you got it. The script to derive child nodes is just a way of testing different configs. In a perfect world, I'd love to essentially specify "/content" and call it a day. But we aren't quite there yet.
Somewhere in all of the words from above, I think I mentioned that syncing the problem paths in isolation works fine. It's a little bit of a stream of consciousness in previous posts. Using the test script to generate all child nodes in the config.json so that "/content/dam/a" through "/content/dam/z" also works... Leading me to believe that there aren't any issues with the nodes themselves.

Also, did you already mention why you are not turning off all workflows within Grabbit?

I don't think I explicitly mentioned why I am not turning off workflows within Grabbit, sorry. I actually remove the nodes under "/etc/workflow/launcher/config" to be synced from PROD later. Sledgehammer to drive a nail.

It looks like your stacktrace issue occurs within msm - there might be workflow nastiness associated with saving a bunch of close paths in different sessions, or something.

Interesting callout. I completely overlooked com.day.cq.wcm.msm in the stacktrace, but I suspect you're exactly right. It would at least explain the javax.jcr.InvalidItemStateException with "/content/a" syncs and not "/content/dam/a" syncs. I'll dig into that right now, but I bet you're 100% correct.
So let's ignore javax.jcr.InvalidItemStateException when syncing "/content/a-z" for now. I'd like to focus on the odd behavior with the DAM syncs.

Small update:
The javax.jcr.InvalidItemStateException when syncing "/content/a-z" was, in fact, a result of MSM. Good catch on that.
So really, the only outstanding thing is the DAM syncing quirk.

Hmm, yeah, the empty content issue is curious. I presume you found nothing of interest in the logs?
The tricky part is you mentioned it only seems to happen if n-z are synched as part of a larger dam sync. If you sync them individually it works, correct? and by empty content, you mean that the nt:file/jcr:content jcr:data property is empty on your 6.2 instance? All the other properties, and supporting nodes seem normal? I think the biggest area of suspect is the detail of syncing 6.0 -> 6.2 with Grabbit 3. Something funny might be happening in that realm.
I would first try installing the problem dam nodes into 6.2 via the package manager, and see if the package manager has to do any finagling with differing node definitions. Does it look like the dam nodes you are trying to sync are represented the same way between 6.0 and 6.2?
One more thing you could try if you want to get deeper into debugging is examining the stream that comes back from your 6.0 server.  For 3.0.5, you can actually do something like this :
GET /grabbit/job?path=/content/dam/problempath
and download the stream directly to your browser. Now, our protocol basically streams binaries as-is - it says, "expect this many bytes", and "here you go" -  so you should be able to find your raw jcr:data binaries embedded in the stream. You could try to find the raw binary from one of n-z within the stream, and then find a binary from a-m (which you should find). If you can't find the binary from n-z, then we know it's a problem with Grabbit even sending the binary from 6.0. If we find it within the stream, the binary is getting passed to 6.2, but something is getting lost in translation from the client-side of things, either with writing the node, a property, or etc.

The tricky part is you mentioned it only seems to happen if n-z are synched as part of a larger dam sync. If you sync them individually it works, correct?

Yep, that's what makes it so strange. The issue occurs when syncing "/content/dam," but "/content/dam/n" works as intended -- so does specifying each "/content/dam/a" - "/content/dam/z"

and by empty content, you mean that the nt:file/jcr:content jcr:data property is empty on your 6.2 instance? All the other properties, and supporting nodes seem normal? I think the biggest area of suspect is the detail of syncing 6.0 -> 6.2 with Grabbit 3. Something funny might be happening in that realm.

I think I identified one point of confusion. Many of the nodes I'm referring to missing their "data" are of a jcr:primaryType=dam:Asset, not necessarily jcr:primaryType=nt:file... Though that doesn't change the issue.
The most accurate way to describe the state of the JCR is that "nt:unstructured" nodes get created for each path that fails to sync. Let me try to obfuscate some screenshots to show you exactly what I mean. I'll follow-up with that shortly.

I would first try installing the problem dam nodes into 6.2 via the package manager, and see if the package manager has to do any finagling with differing node definitions. Does it look like the dam nodes you are trying to sync are represented the same way between 6.0 and 6.2?

One more thing you could try if you want to get deeper into debugging is examining the stream that comes back from your 6.0 server. For 3.0.5, you can actually do something like this :

GET /grabbit/job?path=/content/dam/problempath

and download the stream directly to your browser. Now, our protocol basically streams binaries as-is - it says, "expect this many bytes", and "here you go" - so you should be able to find your raw jcr:data binaries embedded in the stream. You could try to find the raw binary from one of n-z within the stream, and then find a binary from a-m (which you should find). If you can't find the binary from n-z, then we know it's a problem with Grabbit even sending the binary from 6.0. If we find it within the stream, the binary is getting passed to 6.2, but something is getting lost in translation from the client-side of things, either with writing the node, a property, or etc.

It looks like DAM nodes are represented the same way between 6.0 and 6.2. Where I have run into hiccups elsewhere (like the deprecated "cq:Calendar" node type), Grabbit is pretty good about calling out the issue. So that's good at least.
I'll try some of your suggestions for further debugging after I post the aforementioned screenshots. Thanks for sticking with this!

Step-by-step screenshots:
Fresh AEM 6.2 DAM

testconfig.json

Resulting /content/dam after first run
RED is single "sling:OrderedFolder" --> refer to as "/content/dam/a"

Successfully synced PDF file from first run, with appropriate node properties
BLUE is "dam:Asset" --> refer to as "/content/dam/a/../one.pdf"

Same PDF, "/content/dam/a/../one.pdf" existing on the source AEM 6.0 instance

Resulting "/content/dam" after second run, same config
RED is the same "sling:OrderedFolder"
GREEN are new nodes resulting from second run

Same snapshot of "/content/dam" existing on the source AEM 6.0 instance
GREEN are the nodes that were falsely not picked up in first run, synced without node properties/data in second run (different node icon is an early tipoff)

GREEN is one parent node from the second run --> refer to as "/content/dam/b"
YELLOW is improperly synced PDF file from second run, notice missing node properties --> refer to as "/content/dam/b/../two.pdf"

GREEN is "/content/dam/b" existing on source AEM 6.0 instance
YELLOW is "/content/dam/b/../two.pdf" existing on source AEM 6.0 instance

I hope you can follow that okay -- unfortunately, I have to keep our stuff obfuscated. So with those screenshots as a visual aid, you can see that the first Grabbit run seems to only grab one "sling:OrderedFolder" and all of the assets underneath it. The second run adds all of the nodes that were "missed" or "skipped" from the first run, but only as "nt:unstructured" nodes.
The "deltaContent" attribute in the testconfig.json DOES in fact play a role in this behavior. If I replace "/content/dam" in testconfig.json with "/content/dam/b/../two.pdf" and make no further changes and run a third time, nothing happens. I expect that because, as far as the two AEMs and Grabbit are concerned at this point, it just recently synced that content.
Now if I remove the "/content/dam/b/../two.pdf" node from the target AEM 6.2 and keep the testconfig.json the same as the third run, "/content/dam/b/../two.pdf" gets replaced in the same exact manner as the second run --> "nt:unstructured"
If I remove the node "/content/dam/b/../two.pdf" once again from the target AEM 6.2 instance AND remove "deltaContent" from testconfig.json, the fifth run replaces "/content/dam/b/../two.pdf" properly.
I'm running out of time today and will have to push your debug suggestions off until tomorrow. Hopefully this sheds a little bit of clarity on the issue.

What type of nodes are the nodes in the green block? Other sling:OrderedFolder 's?
I have a partial script for how this might happen.
In a given green block can you find a node down the nt:unstructured tree that is filled in properly? One thing that could cause the plain-jane nt:unstructured nodes is if a child node is being saved without it's parent already present. With delta sync, Grabbit may only be sending child nodes from your AEM 6.0 instance for which it can't determine modified/creation/etc time; and since your parent nodes aren't present for whatever reason, Jackrabbit is creating nt:unstructured parents. Usually this wouldn't be an issue, because using delta content you would assert that the parents had already been successfully sync'd at some point, and are still present.
Maybe clear /var/grabbit (essentially Grabbit history) and try again to see if the unstructured nodes show up the same way?

Sorry for the delayed reply -- I've been off the past couple of days.

What type of nodes are the nodes in the green block? Other sling:OrderedFolder 's?

The folders in the green blocks are supposed to be "sling:OrderedFolder." In the failed syncs, they end up as "nt:unstructured."

In a given green block can you find a node down the nt:unstructured tree that is filled in properly? One thing that could cause the plain-jane nt:unstructured nodes is if a child node is being saved without it's parent already present. With delta sync, Grabbit may only be sending child nodes from your AEM 6.0 instance for which it can't determine modified/creation/etc time; and since your parent nodes aren't present for whatever reason, Jackrabbit is creating nt:unstructured parents. Usually this wouldn't be an issue, because using delta content you would assert that the parents had already been successfully sync'd at some point, and are still present.

This has to be the core issue, then. Yes, I can drill down and find a child node under an "nt:unstructured" node (green block) that is synced properly. There is no color code to this screenshot -- every node except the one shown is an "nt:unstructured" node that really should be some other node type. It illustrates the behavior you're describing.

 It still doesn't explain why those parent nodes get skipped in the first place (regardless of "deltaContent").
It's as if whatever iteration/recursion over the immediate child nodes of "/content/dam" doesn't have accurate knowledge of the existence of those immediate child nodes.

Maybe clear /var/grabbit (essentially Grabbit history) and try again to see if the unstructured nodes show up the same way?

I've tried this at different points (mostly to just clear the noise when checking the status of jobs) and it doesn't seem to change any results.

Hey @dscirto any progress on this?
Have you tried eliminating the difference of platform from the equation? Maybe like using package manager to transfer over some of these nodes that Grabbit isn't syncing correctly to one 6.2 instance, and syncing to another 6.2 instance. If you see the same behavior, then we at least know it's not an issue with 6.0 -> 6.2 sync.

I haven't had as much dedicated time the past week for this exact issue, but I've done some other syncing with different environments that makes me lean towards it being an issue with 6.0 => 6.2
We have a need to sync a 6.1 => 6.2 environment and, in short, have had no issues syncing these instances. This is using Grabbit 7.0.2 for both instances, so there are a lot of different variables, but it's something.
When I have spare time, I am going to try and trigger a sync from the 6.0 instance I've been using, but sync it to a fresh local 6.0 ... Try and eliminate what the issue could be.

One more thing you could try if you want to get deeper into debugging is examining the stream that comes back from your 6.0 server. For 3.0.5, you can actually do something like this :

GET /grabbit/job?path=/content/dam/problempath

This is also high on my list to try.

Cool, just a note @dscirto if you try looking at the binary stream for 7.0.2; the resource path is a bit different. We changed the resource path to be a bit more accurate a couple versions back:
GET /grabbit/content?path=/content/dam/problempath


Terminate the function list by egress function

In the current implementation, the ipftrace doesn't understand when it should terminate the function list. As for the quick workaround, we assume the IP layer functions won't be called twice for the same flow. This becomes the problem when the packets go through the multiple network namespaces in the same kernel. Very common functions like ip_output or ip_rcv should be called multiple times in this case.
An idea to solve this problem is to mark the egress functions like ip_finish_output. When the perf event consumer sees the mark, it can terminate the function list.

It should be better to use the kretprobe of entry point functions like ip_rcv or __ip_queue_xmit.

The above idea doesn't work since we cannot see the skbs in kretprobe context. We cannot identify the packets without it.

Handled some cases in https://github.com/YutaroHayakawa/ipftrace/commit/a3a6d886c10a59a992d16ed92af0582b686b880f

It should be better to specify the egress functions in the manifest file. FTrace has similar interface.

Done in f11f0bc24c80fb8e7f5bde5da425d6be7ea93236


Does match_bucket_filter support query_string filters?

I get the error message no [query] registered for [query] if I try to use a query_string

Thanks for the report. There is some special code that handles this for filter but not for bucket filter. You can work around this by removing the top level "query"
match_bucket_filter:
 - query_string:
      query: "blah blah"

I don't think it is quite the same issue mind, the dsl for the filter aggregation appears unchanged going back to 1.x.
The query{} element is not actually a valid query clause rather it signifies search context, and not sure it was ever valid as a child element of a filter{} context.
Only leaf query clauses like match, term, query_string or compound query clauses such a bool can go directly under the filter element.
I should probably have made the docs a bit clearer  that it is not exactly the same as the main search filter.

True. I got used to starting things with query and then popping that when doing aggregations, like https://github.com/Yelp/elastalert/blob/master/elastalert/elastalert.py#L220 and  https://github.com/Yelp/elastalert/blob/master/elastalert/elastalert.py#L883 instead of encouraging people to avoid starting with query.


Style guide: how to use images in the code

PR https://github.com/kodadot/nft-gallery/pull/6707 drastically reduced bundle size thanks to offloading images from code into separated folder.
I want that developers SHOULD NOT inline images instead link them as shown in PR - #6707
Into STYLE_GUIDE.md:

Under naming conventions - other - add that images (prefferably webp should be kebab-cased)
under general conventions - images - write that images should not be inlined but referenced also make short snippet

SHOULD NOT inline images

Can we have a lint rule for this one?

👋


Add warnings color for base16 color schemes

This replaces the color-clashing orange default with something more reasonable.

thanks!


Complete all-providers GHA workflow.

@stack72 Looks like it works!  https://github.com/pulumi/ci-mgmt/actions/runs/1495789851


add custom error message on nativeEnum validation

Resolves #2919
Return invalid_type_error on nativeEnum validations instead of  Invalid enum value when the attribute is set.
const schema = z.nativeEnum({ MY_ENUM: "MY_ENUM" }, {
  invalid_type_error: "the value provided is invalid",
})

console.log("result", schema.parse("AAA"));
// returns error "the value provided is invalid"

Is there an update on this?
Currently working with a list of US States as a native enum, having Zod throw out an error "Invalid string, expected one of <list of all 50 states>" doesn't make for the greatest user experience.

My preferred solution here is the one that landed in #3169, which will land in Zod 3.23 shortly.
This is all liable to change in Zod 4 as well.


fix: Whitelist ms-dynamics-smb.al extension for Vue Hybrid Mode.

The Microsoft AL Language Extension for Microsoft Dynamics 365 Business shows up as potentially incompatible when starting VS Code and opening .vue files. These are unrelated to to the AL language plugin.
Changing hybrid mode to true does not cause any interference with Vue files as far as I can tell.

Thanks!


Open DEBUG CONSOLE when debugging starts

I'm working on a C++ project with VSCode and before starting debugging I have to build the project.
During build the OUTPUT is shown.
When starting debugging then I have to switch to DEBUG CONSOLE manually.
It would be great if it switches automatically when debugging starts.

Hi @daB0bby please use the following setting:
"debug.internalConsoleOptions": "openOnSessionStart"


request: support zoomIn & zoomOut using mouse wheel.

Operation System: all
Beaker Version: 0.5.2
The proposal is, to support zoomIn & zoomOut function with [ctrl] + mouseWheel as it's common with every other browser.
Since I don't know how the key is called on MacOS, help is needed here.
proof of concept PR will follow soon.

PR merged. so close the issue.


Need Minion Feature

I want the same Bot Gamemode which the agarlist.com having right now,please help me

@fayizan ayizanI think the creator of agarlist with Ogar Ogar combine multi Unlimited
For minions,
I'm looking minions temién for this server "MultiOgar", but found only minions that do not reappear and have no support skins and graphics RETINA

David Ali made that gamemode, and yes he won't give the code out.

Yeah I helped him make the minions a complete success. But that's not happening on MultiOgar, so this issue is just a waste.

not for share code ur self

@David1ali12  ok np,thnks for that gamemode tho in agarlist.com I love it..!! thnk u @David1ali12


Reflect recent 02-client/tendermint changes in specs and testing

Summary
Lots of major changes have occurred to the interaction of 07-tendermint with 02-client. We should take this time to update specs and add/modify testing to be more rigorous.
Proposal
See related comment from the pr that removed the last header from client state.
We should also apply the validator set -> validator hash in consensus state change in each of the the areas mentioned in the comment (specs, testing etc)

For Admin Use

[x] Not duplicate issue
[x] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

closing issue as stale


Architecture documentation

As an engineer, I would like to create documentation explaining important architecture in the project, so that contributors/maintainers and consumers understand design decisions.

[ ] Explanation of CI/CD workflow
[ ] Infrastructure testing best practices? (Can pull from terratest documentation)

This issue should include information from the Wiki:

For CI/CD task, it should include information about how we're updating the manifest file with GitVersioning. It should also include a look into how we're testing publication to the powershell gallery using a local PowerShell gallery

For the testing task, it should include information about Pester, how importing and mocking works - pulling from the wiki


RAS new job types and api

New RAS release

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: dbiguenet:x: RenaudKerivenYou have signed the CLA already but the status is still pending? Let us recheck it.


There are some errors in the document

[여기에 피드백 입력]

This document has no way how to add timer objects.
itemLabel is not used. The seconds and "Time's up" message must set the itemLable, not the timeLabel.
When the Start button is pressed, the button must be disabled.
startButton.Enable = false
must be added to the bottom of the startButton_Click method.

문서 세부 정보
⚠ 이 섹션을 편집하지 마세요. docs.microsoft.com ➟ GitHub 문제 연결에 필요합니다.

ID: af83dce0-a830-c876-e355-d9e3ca095b30
Version Independent ID: af83dce0-a830-c876-e355-d9e3ca095b30
Content: Tutorial: Add a timer to a Windows Forms app - Visual Studio (Windows)
Content Source: docs/get-started/csharp/tutorial-windows-forms-math-quiz-add-timer.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @anandmeg
Microsoft Alias: meghaanand

@sangeun-jo, thanks for your feedback. Create a timed Math quiz is a series of 4 tutorials.

The timer control is added in Tutorial Part 3: Add a Timer control to a math quiz WinForms app
The time remaining label is added in Tutorial Part 1 as timeLabel.
Disabling the Start button after click is added in Tutorial Part 2: Add math problems to a math quiz WinForms app

Hope this helps! Please let us know if we can help with anything else. Thanks.


Optional package

Overview
1Password CLI requires setting the group of the executable to onepassword-cli. This isn't possible when home-manager is installed in standalone mode (e.g. Ubuntu or other distributions). Opting out of installing the 1Password CLI
with nix allows using the system-wide installation (e.g. via apt).
This change also allows changing the package. It's beneficial when nixpkgs-unstable is mapped to pkgs.unstable via an overlay.
This is not breaking, the current behavior remains as is.
Type of change
Improved experience for nix users.
How To Test
Opting out of installing the package:
{
    imports = [ inputs._1password-shell-plugins.hmModules.default ];
    programs._1password-shell-plugins = {
      enable = true;
      package = null;
      plugins = with pkgs; [ gh awscli2 cachix ];
    };
}

Changing the package:
{
    imports = [ inputs._1password-shell-plugins.hmModules.default ];
    programs._1password-shell-plugins = {
      enable = true;
      package = pkgs.unstable._1password;
      plugins = with pkgs; [ gh awscli2 cachix ];
    };
}

Changelog
Allow nix users to change the _1password package like in home-manager modules or allow opting out from installing the package by setting it to null.

I would love to see this merged. Mostly because of standalone home-manager.


[back-end[ Configure CRUD routes for items, chapters and chapterItems.

Configure routes to handle basic CRUD ops (GET, PUT, POST, DELETE) to the following routes:
/items
/chapters
/chapters/:chapterId/items/

Closed this duplicate


RUM-3532 keep webview wireframe hidden

What does this PR do?
In order to keep webviews consistent in session replays, instead of removing them from the segments when computing a diff, we keep them and mark them as hidden.

Codecov Report

Merging #1949 (140ed18) into feature/sr-web-view-support (2027b2d) will decrease coverage by 0.04%.
Report is 16 commits behind head on feature/sr-web-view-support.
The diff coverage is 90.91%.

Additional details and impacted files
@@                       Coverage Diff                       @@
##           feature/sr-web-view-support    #1949      +/-   ##
===============================================================
- Coverage                        83.56%   83.52%   -0.04%
===============================================================
  Files                              486      487       +1
  Lines                            17439    17658     +219
  Branches                          2594     2644      +50
===============================================================
+ Hits                             14572    14748     +176
- Misses                            2143     2174      +31
- Partials                           724      736      +12

Files
Coverage Δ

...internal/recorder/mapper/WebViewWireframeMapper.kt
100.00% <100.00%> (ø)

...ssionreplay/internal/processor/MutationResolver.kt
89.41% <88.89%> (-0.07%)
:arrow_down:

... and 30 files with indirect coverage changes


[Linux] "Connecting to network..." <IP_ADDRESS>:8090 seems dead AKA "How to run it?"

After successfully building it on Arch Linux, I get never ending "Connecting to network..." and error messages complaining about <IP_ADDRESS>:8090, which seems dead when trying to connect manually with wscat or netcat.
Cross-linking:

I've posted already on Cardano Forum here
here I found another user who build it but "has to figure out how to run it"

I've poked around and find that most Linux users are really confused, while there should be clear instructions what has to be run if it's more than just "daedalus".
(btw. Some notes refer to scripts "connect-to-mainnset" etc (like here) that are in cardano-sl repository but not in package that is build...).

8090 is where the cardano node lives
mdupont@debian-build-speed:~/experiments/cardano-sl$ lsof -i:8090
COMMAND    PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
cardano-n 5183 mdupont   31u  IPv4 2991379      0t0  TCP localhost:8090->localhost:41616 (ESTABLISHED)
see https://github.com/h4ck3rm1k3/cardano-sl
./.stack-work/install/x86_64-linux-nopie/lts-9.1/8.0.2/bin/cardano-node
--web
--no-ntp
--configuration-file ./lib/configuration.yaml
--configuration-key mainnet_full
--tlscert ./scripts/tls-files/server.crt
--tlskey ./scripts/tls-files/server.key
--tlsca ./scripts/tls-files/ca.crt
--log-config ./scripts/log-templates/log-config-qa.yaml
--topology "topology-mainnet"
--logs-prefix "state-wallet-mainnet/logs"
--db-path "state-wallet-mainnet/db"
--wallet-db-path 'state-wallet-mainnet/wallet-db'
--keyfile state-wallet-mainnet/secret.key

$ git clone https://github.com/input-output-hk/cardano-sl.git
$ cd cardano-sl
$ cardano-node \
--web  \
--no-ntp  \
--configuration-file ./lib/configuration.yaml  \
--configuration-key mainnet_full  \
--tlscert ./scripts/tls-files/server.crt  \
--tlskey ./scripts/tls-files/server.key  \
--tlsca ./scripts/tls-files/ca.crt  \
--log-config ./scripts/log-templates/log-config-qa.yaml  \
--topology "topology-mainnet"	 \
--logs-prefix "state-wallet-mainnet/logs"  \
--db-path "state-wallet-mainnet/db"  \
--wallet-db-path 'state-wallet-mainnet/wallet-db'  \
--keyfile state-wallet-mainnet/secret.key

Result:
[Attention] We are in DEV mode
Asserts are ON
[Attention] Software is built with wallet part
ConfigurationOptions {cfoFilePath = "./lib/configuration.yaml", cfoKey = "mainnet_full", cfoSystemStart = Nothing}
cardano-node: ConfigurationParseFailure "./lib/configuration.yaml" (AesonException "Error in $['mainnet_staging_short_epoch_wallet_win64'].core: When parsing the record coreConfiguration of type Pos.Core.Configuration.Core.CoreConfiguration the key memPoolLimit was not present.")

(I am using cardano-node from https://aur.archlinux.org/packages/cardano-sl )
Btw. Is it reference from where have you taken command line: https://github.com/input-output-hk/cardano-sl/blob/723d55b841560fc3067a58cfcaa6861286ccadaa/scripts/launch/connect-to-cluster/default.nix#L51

ok it looks like you might have a different config file. can you compare to https://github.com/h4ck3rm1k3/cardano-sl/blob/master/lib/configuration.yaml

Good fine with the connect to cluster launch script.

It is not this...
$ diff lib/configuration.yaml h4ck3rm1k3_configuration.yaml | wc -l
0

Well can you build the latest version? or compare your configuration.yaml to the one that matches the binary version you built. I have not looked into the packaging you are using.

The guestion may be, which branch, as I've noticed that

How to Build Cardano SL and Daedalus from Source Code

points to

Switch to the latest release branch, for example, cardano-sl-1.0

Therefore I understand to try cardano-sl-1.0 branch.
(Is that correct ? Or should I try different? Or maybe sync git to specific commit?)

I am building mine from master not 1.0, but yes, if that is the version you
are using in arch then compare that version.
On Tue, Dec 19, 2017 at 6:38 AM, Grzegorz Wierzowiecki <
<EMAIL_ADDRESS>wrote:

The guestion may be, which branch, as I've noticed that

How to Build Cardano SL and Daedalus from Source Code
https://github.com/input-output-hk/cardano-sl/blob/9844854414d3ca153cc44e13783d5f90e7725efb/docs/how-to/build-cardano-sl-and-daedalus-from-source-code.md

points to
Switch to the latest release branch, for example, cardano-sl-1.0
Therefore I understand to try cardano-sl-1.0 branch.
(Is that correct ? Or should I try different? Or maybe sync git to
specific commit?)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/input-output-hk/daedalus/issues/608#issuecomment-352723952,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACIV_coedI69s6rS7yXyDjU0fw06mZSks5tB6AogaJpZM4RF3-1
.

--
James Michael DuPont

I can build from any, just give me commit hash.

ok here is what I have running but cannot get a transaction to show.
d30dd9f9184a4395d83f7e61b9f2e15efb5a966d
git@github.com:h4ck3rm1k3/cardano-sl.git
on backend
0733ef64e7ff92597501086e0dfc8b5cb6035585
git@github.com:input-output-hk/daedalus.git
on middleware
7d8746f0947fb41bf5bec5f734fdb9b954197879 git@github.com:h4ck3rm1k3/daedalus.git
for the front end.
On Tue, Dec 19, 2017 at 10:10 AM, Grzegorz Wierzowiecki <
<EMAIL_ADDRESS>wrote:

I can build from any, just give me commit hash.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/input-output-hk/daedalus/issues/608#issuecomment-352786650,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACIV_P-Jv60BVYL3PQcudHVWPxhB-mvks5tB9H-gaJpZM4RF3-1
.

--
James Michael DuPont

https://steemit.com/ada/@h4ck3rm1k3st33m/first-ada-recieved i got my first ada in my self compiled wallet and node

Please follow https://github.com/input-output-hk/daedalus/issues/492 for official support for Linux

the node is not running in Windows with
[*production*:INFO:ThreadId 3] [2018-04-17 12:03:29.63 UTC] [Attention] Software is built with wallet part
[*production*:INFO:ThreadId 3] [2018-04-17 12:03:29.63 UTC] using configurations: ConfigurationOptions {cfoFilePath = "lib/configuration.yaml", cfoKey = "default", cfoSystemStart = Nothing, cfoSeed = Nothing}
[node:ERROR:ThreadId 3] [2018-04-17 12:03:29.63 UTC] ConfigurationParseFailure "lib/configuration.yaml" (InvalidYaml (Just (YamlException "Yaml file not found: lib/configuration.yaml")))
cardano-node.exe: ConfigurationParseFailure "lib/configuration.yaml" (InvalidYaml (Just (YamlException "Yaml file not found: lib/configuration.yaml"))```

you have to pass the node a --configuration-file path/to/configuration.yaml to tell it where to find the file

The actual issue is that when I click on the Daedalus Windows shortcut link, the wallet opens but it stays at forever connecting. The error in the logs is CONNECTION RESET on <IP_ADDRESS>:8090.
So makes me think the node is not running - but I have never had to run it explicitly. This started happening about two days ago.

[2018-04-18 07:36:08:0576] [debug] Connection Lost. Reconnecting...
[2018-04-18 07:36:08:0982] [error] AdaApi::syncProgress error: {
"stack": "Error: connect ECONNREFUSED <IP_ADDRESS>:8090\n    at Object.exports._errnoException (util.js:1050:11)\n    at exports._exceptionWithHostPort (util.js:1073:20)\n    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1097:14)",
"message": "connect ECONNREFUSED <IP_ADDRESS>:8090",
"code": "ECONNREFUSED",
"errno": "ECONNREFUSED",
"syscall": "connect",
"address": "<IP_ADDRESS>",
"port": 8090
}

This is sad.
I had the same "ECONNREFUSED" error in December. I managed to run the wallet with changing the paths in the Daedalus.bat, but recently updated the wallet to the new version and the problem is back, and the wallet won't start with the bat file anymore.
If I install the old version back again I am able to run the wallet again once since the update is out and after a restart, it will install it...
A lot of time passed since you know about this error. Is this hard to do something about it?

@humanoidcreature are there any errors in the node.pub logfile?

I just noticed that when you execute $ /home/$USER/.local/bin/daedalus everything loads fine
However, when you execute $ /usr/bin/daedelus, you get:
Error: connect ECONNREFUSED <IP_ADDRESS>:8090\n
This is with Linux build 1.1.960. with Cardano 1.1.0

I had this issue for months and always hoped some new version would just fix whatever was broken.
For some reason, in the depths of my error messages, it complained about the server tls cert not being available. That seems to have lead to the node running, but the server that the Frontend connects to not actually listening on a port.
I reran build-certificates-unix.sh from within the Application bundle and now everything works.


Add missing character 萜

Ref:
https://en.wiktionary.org/wiki/萜
https://www.wikiwand.com/zh-tw/萜烯
https://www.wikiwand.com/zh-tw/类萜

Terpenes and terpenoids 💨

Great! Although it won't affect the actual outcome, should we change the encoding of this character  from big5 to utf8 to maintain encoding correctness before removing the encoding field as discussed in https://github.com/openvanilla/McBopomofo/pull/491#issuecomment-2161376260?

Sure thing, fixed! Thanks for the advice!

雖然可能不常這樣寫，但我有點好奇「萜烯烴」會不會正確地轉換出來，還是會變成「萜烯聽」或其他的組合。

@tianjianjiang
I think this special case is inherently difficult to predict the outcome, so it should be fine.
If necessary, we can also add 萜烯烴 to the list.
https://github.com/openvanilla/McBopomofo/assets/36815907/1cf8c21e-df83-4c1c-b804-be58464b623b

@tianjianjiang
I think this special case is inherently difficult to predict the outcome, so it should be fine.
If necessary, we can also add 萜烯烴 to the list.

@ChiahongHong
Thank you for the usage video, that's really helpful.
I also anticipate that difficult situation. As long as it is still acceptible to you (and hopefully the online learning algorithm will kick in soon enough), I have no strong preference for adding 萜烯烴 or not.


Update the Prompt API demo to the latest API shape

window.ai.assistant.*

This now shows session stats and allows you to tweak the session parameters. It also looks a bit better.

Obsoleted by #29


BUG in RegisterListener, wrong null check

Hello,
I identified small bug in ConsumerManager.cs.
You perform null check against config.OnEnd but is shout be config.OnAck
https://github.com/Tpessia/RabbitLight/blob/9b9c413779e48e0f1cb8000a81f94597bc5d8145/source/Consumer/Manager/ConsumerManager.cs#L190
https://github.com/Tpessia/RabbitLight/blob/9b9c413779e48e0f1cb8000a81f94597bc5d8145/source/Consumer/Manager/ConsumerManager.cs#L191
Thanks

Thanks!! Just fixed it


Nullpointer while opening PortalActivity

This happens in production code - stacktrace is delivered by crashlytics:
https://gist.github.com/kjurkovic/922152759368cb8a461a
I am using latest uservoice sdk.

Fixed in 1.2.1


Remove .env file from repo and update docs

I have removed the .env file from the repository, to ensure users manually create it and use their own credentials.
Adapted docs accordingly.

Now incorporated into #81


Creating ci for tests and linting

I# Description
I have created github actions for testing and linting. The actions will run before merging is possible.
Closes issue(s)
Resolves #84
How to test
NA
Changes include

Create workflow file
Create github action for testing
Create github action for linting

Checklist

[x] I have tested this code

Looks good!


Allow linear to be consumed by nvFuser by default

This change lowers peak memory usage of LitGPT implementations that use mlp_class_name="GptNeoxMLP" configuration (https://github.com/Lightning-AI/lightning-thunder/issues/1175, https://github.com/Lightning-AI/lightning-thunder/issues/1233, https://github.com/Lightning-AI/lightning-thunder/issues/246).

config (mlp_class_name)
Before
This PR

stablecode-completion-alpha-3b (GptNeoxMLP)
889.68 ms | 77.02 GB
892.37 ms | 74.33 GB

Llama-2-7b-hf (LLaMAMLP)
336.06 ms | 64.22 GB
340.86 ms | 64.18 GB

Better memory usage comes from simplifying the setup for Thunder's fusion rematerialization. With this change, there are fewer "producer" fusions.
cc @Priya2698, @wujingyue

There are multiple concerning CI failures:

FAILED thunder/tests/test_nvfuser.py::test_cse_rematerialization_nvfuser_cuda_None - assert 3 == 11 is likely due to a behavior change in rematerialization that should be reflected as well in the test.
FAILED thunder/tests/test_jit_general.py::test_litgpt_variants_kvcache[cuda-llama1-like] - RuntimeError: !detect_exception_in_thread_pool.load() INTERNAL ASSERT FAILED at "/workspace/Fuser/csrc/kernel_cache.cpp":1234, please report a bug with repro script to NVFuser at https://github.com/NVIDIA/Fuser/issues. Detected exception while compiling fusion segments in parallel. Error messages from all threads are printed below. sounds like a bug in nvFuser.

Error from segmentation group 4: producer->getMemoryType() == MemoryType::Global INTERNAL ASSERT FAILED at "/workspace/Fuser/csrc/device_lower/analysis/sync_information.cpp":699, please report a bug with repro script to NVFuser at https://github.com/NVIDIA/Fuser/issues. Inconsistent parallelization found between TV30 (T30_l[ iblockIdx.x284{( ceilDiv(( ceilDiv(( ceilDiv(( 1 * 16 ), 128) ), 1) ), 1) )}, iUS285{1}, iS283{1}, ithreadIdx.x281{128} ]) and TV25(T25_l[ iblockIdx.x232{( ceilDiv(( ceilDiv(( ceilDiv(( 1 * ( 1 * ( 1 * 16 ) ) ), 128) ), 1) ), 1) )}, iUS233{1}, iS231{1}, ithreadIdx.x229{128} ] ca_pos( 4 )). Producer is required to be in Global Memory based on parallelization strategy. RAW flags: (blockIdx.x threadIdx.x)

We did not run Thunder benchmarks using nvfuser linear. Should we run other benchmarks as well before enabling it by default?
Additionally, @wujingyue needed to remove support for 1D weights to facilitate DID-aware execution. We might have to add an additional check on Thunder side or use unsqueeze-squeeze operators to support it. I believe we currently do not have cases exercising 1D weights in Thunder so this should not break anything right now.

are there enable_foobars other than linear and matmul?

Yes, there's also nv_enable_sdpa. I didn't enable matmul in this PR because it leads to excessive memory usage in my tests. I haven't tried nv_enable_sdpa I thin we want to continue using the one from cuDNN for performance.

CI with torch-nightly is now passing with https://github.com/NVIDIA/Fuser/issues/3369 fixed. CI with older versions of torch (and therefore older versions of nvFuser) still fail, because we can fix a past version. @IvanYashchuk, can you up nvFuser's version and enable linear only for that?

Yes, I will do that.

I'm unsure about the lightning-thunder (ipynb) test. Is that an infra failure or indeed a regression?

For some reason, there was a timeout in the cell execution. Let's try rerunning the failed job.

@kiya00, could you please check what's going on with the Notebooks CI job?

Thank you for this PR, but if this means needing to add correctness exceptions to half a dozen models, and the savings on Llama are marginal, we should not do this by default and instead use recipes to enable it where desired.

Which correctness exceptions are you referring to, @t-vi? I agree we can't enable something by default if it causes timeouts in some models, but that's just a speed motivation.
@kiya00 Is there a bug for the slowness issue? @kevinstephano, do you think it's worth investigating?
@kshitij12345, @IvanYashchuk, @jjsjann123, should we consider requiring nv fusions have enough nodes to be valuable (2+?) and not so many nodes they might be slow (< 30?). Maybe we could develop better heuristics in the future

@kiya00 Is there a bug for the slowness issue? @kevinstephano, do you think it's worth investigating?
While there is a real issue, between 20 to 30 matmuls in a fusion that leads to an explosion in segmentation time, I am not sure how often we are going to see so many matmuls in one fusion.  It would be interesting to see if this comes up in actual models.


Remove batches if they are received after the iterator detects that t…

Closes #1177

@jlowe Note that I no longer believe this is a limit issue. I updated https://github.com/NVIDIA/spark-rapids/issues/1177. Sorry for the confusion. This change triggers in error conditions for a fact, but I am now doubting whether it is useful in other conditions.

Updated https://github.com/NVIDIA/spark-rapids/issues/1177 again. Was able to reproduce, main thing that tricked me was the coalesce batches. Not sure if that is expected, where you have a shuffle -> coalesce -> local limit X. Should coalesce only coalesce to X? Either way, it's definitely seen if coalesce is adjusted to produce small batches, such that local limit finds what it needs early.

build

build