maven-publish combined with artifactory-publish doesn't publish marker artifacts

Expected Behavior
When I configure my project to use the Gradle Artifactory Plugin with a project that also uses the java-gradle-plugin I would expect that the plugin markers get deployed to Artifactory.
Current Behavior
When running the artifactoryPublish task, nothing is published to Artifactory, other than the build info.
Context
When building internal plugins within our organization, we can't use the plugins DSL because our in-house-built plugins don't have valid plugin markers deployed.
Steps to Reproduce (for bugs)
Here is a sample build file
plugins {
    id 'java-gradle-plugin'
    id 'maven-publish'
    id 'com.jfrog.artifactory' version '4.7.0'
}

group 'com.mycompany.groupid'
version '<IP_ADDRESS>'

sourceCompatibility = 1.8

gradlePlugin {
	plugins {
		sample {
			id = 'my-sample-plugin'
			implementationClass = 'org.gradle.mavenpublish.SamplePlugin'
		}
	}
}

repositories {
	mavenCentral()
}

artifactory {
	contextUrl = 'http://my.artifactory.server/artifactory'

	publish {
		repository {
			repoKey = 'artifactory-publish-repo'
			username = 'user'
			password = 'pass'
		}

		defaults {
			publications 'pluginMaven', 'samplePluginMarkerMaven'
			properties = ['Deployed By': System.properties['user.name']]
			publishBuildInfo = true
			publishArtifacts = true
			publishPom = true
			publishIvy = false
		}
	}

	resolve {
		repository {
			repoKey = 'artifactory-resolve-repo'
			maven = true
		}
	}

	clientConfig.includeEnvVars = true
	clientConfig.envVarsExcludePatterns = '*pwd*,*password*,*PWD*,*PASSWORD*,*Password,*secret*,*SECRET*,*key*,*KEY*,sonar.login'
	clientConfig.info.buildName = 'test-publish'
	clientConfig.info.buildNumber = version
}

task printPubs {
	doLast {
		project.publishing.publications.each { publication ->
			println "Publication [name: $publication.name, groupId: $publication.groupId, artifactId: $publication.artifactId, version: $publication.version"
		}

		def pluginMaven = project.publishing.publications['pluginMaven']
		println "pluginMaven [name: $pluginMaven.name, groupId: $pluginMaven.groupId, artifactId: $pluginMaven.artifactId, version: $pluginMaven.version"
	}
}

When you run the artifactoryPublish task (substituting a valid Artifactory URL/username/password/publish repo name), you get this:
./gradlew artifactoryPublish

> Task :artifactoryDeploy
Deploying build descriptor to: http://my.artifactory.server/artifactory/api/build
Build successfully deployed. Browse it in Artifactory under http://my.artifactory.server/artifactory/webapp/builds/test-publish/<IP_ADDRESS>

BUILD SUCCESSFUL in 2s
2 actionable tasks: 2 executed

What's interesting though is if you run the printPubs task that I wrote, you get this
 ./gradlew printPubs

> Task :printPubs
Publication [name: pluginMaven, groupId: com.mycompany.groupid, artifactId: gradle-maven-publish-artifactory, version: <IP_ADDRESS>
Publication [name: samplePluginMarkerMaven, groupId: my-sample-plugin, artifactId: my-sample-plugin.gradle.plugin, version: <IP_ADDRESS>
pluginMaven [name: pluginMaven, groupId: com.mycompany.groupid, artifactId: gradle-maven-publish-artifactory, version: <IP_ADDRESS>

BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed

Your Environment
I can't give a build scan due to legal reasons, but here is my environment:
------------------------------------------------------------
Gradle 4.6
------------------------------------------------------------

Build time:   2018-02-28 13:36:36 UTC
Revision:     8fa6ce7945b640e6168488e4417f9bb96e4ab46c

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          1.8.0_131 (Oracle Corporation 25.131-b11)
OS:           Mac OS X 10.12.6 x86_64

I'm having this issue too, any update?

Can you please enabled --debug and run artifactoryPublish again?

I think you need to configure valid publications in artifactry plugin
Like this: https://github.com/lavcraft/huntbugs-gradle-plugin/blob/master/build.gradle#L75

Here is my output with --debug:
artifactoryPublishDebug.txt
It does publish something to artifactory, but it's missing the marker artifacts. My config looks something like:
artifacts {
    archives jar
}

artifactory {
    contextUrl = "${contextUrl}" /
    publish {
        repository {
            repoKey = 'maven'
            username = "${user}"
            password = "${password}"
            maven = true
        }
        defaults {
            publishConfigs('archives')
        }
    }
    resolve {
        repository {
            repoKey = 'maven'
            maven = true
        }
    }
}

@ashtynmo The marker artifacts are not part of the archives configuration. You have to use publications 'samplePluginMarkerMaven' (assuming your use sample in  gradlePlugin { plugins { sample { ... } } }) instead of publishConfigs('archives').

@edeandrea The reason is that the Artifactory plugin's ProjectEvaluationListener applies the defaults before the MavenPublications have been added.
When enabling the debug logging, you see:
16:17:32.992 [DEBUG] [org.jfrog.gradle.plugin.artifactory.task.helper.TaskHelperPublications]
Publication named 'pluginMaven' does not exist for project ':' in task ':artifactoryPublish'.
16:17:32.992 [DEBUG] [org.jfrog.gradle.plugin.artifactory.task.helper.TaskHelperPublications]
Publication named 'samplePluginMarkerMaven' does not exist for project ':' in task ':artifactoryPublish'.

As a workaround, you can configure publishing manually:
gradlePlugin {
    automatedPublishing = false
	plugins {
		sample {
			id = 'my-sample-plugin'
			implementationClass = 'org.gradle.mavenpublish.SamplePlugin'
		}
	}
}

publishing {
    publications {
        pluginMaven(MavenPublication) {
            from components.java
        }
        samplePluginMarkerMaven(MavenPublication) {
            groupId gradlePlugin.plugins.sample.id
            artifactId gradlePlugin.plugins.sample.id + ".gradle.plugin"
            pom.withXml {
                def dependency = asNode().appendNode('dependencies').appendNode('dependency')
                dependency.appendNode('groupId', group)
                dependency.appendNode('artifactId', name)
                dependency.appendNode('version', version)
            }
        }
    }
}

FWIW here's a complete sample project:
https://github.com/marcphilipp/gradle-sandbox/tree/master/4783-artifactory-plugin-publishing

The artifactory plugin tries to access the publications immediately when you mention them, even if you just refer to them by their name. It should instead do this lazily. Also it should support passing a DomainObjectContainer<Publication> so that users can do convenient things like telling it to upload all publications without having to list each individually.
This can't be fixed on the Gradle side, please let the artifactory team know. We're happy to assist if they need guidance.

Hi @oehme ,
My name is Alexei and I'm one of the developers that maintaining the Artifactory Gradle plugin.
I wanted to thank you for your suggestions and indeed we are working on fixing the issue when the evaluate is running to early. The implementation would be that in the afterEvaluate method to set the finalizedBy for all the projects but only if the configure on demand is configured, we will run the projectEvaluated for the needed projects.
If the configure on demand is not passed, we then do the projectEvaluated in a later stage when all the projects were evaluated (projectsEvaluated method). Any suggestion from you regarding this would be appreciated.
One thing I've came across that I do want to consult with you:
I've created a project and configured also the following within the build.gradle:
project.afterEvaluate { proj ->
proj.configure(proj.publishing) {
publications {
mainJava(MavenPublication){
from components.java
artifact(file("$rootDir/gradle.properties")) {
extension "txt"
}
}
}
}
proj.configure(proj.tasks['artifactoryPublish']) {
publications 'mainJava'
}
}
When running without the flag of configure on demand, all is working and the pom-default.xml file is being created and uploaded to Artifactory.
However, when running with the flag of configure on demand, the pom file is not being created and therefore the artifactoryPublish fails since the plugin expecting the file.
I've created a sample task hello that just prints hello to the terminal and when I run this task with configure on demand, still the pom is not being created.
Therefore, this specific scenario is not related to the Artifactory Gradle plugin since in the above scenario the Artifactory Gradle plugin is not being invoked.
It seems that configure on demand skipping the creation of the pom. Is this the desired behaviour from Gradle to skip this and not to create the file?
If needed I can send you a sample project.

Hey @AlexeiVainshtein,
what you referred to looks like a different issue. I'm happy to help of course, but can we discuss that one separately?
The problem here has nothing to do with your ProjectsEvaluatedBuildListener. Instead, the problem here is that your publications() method tries to eagerly resolve all publications, even if the user just passes Strings. The method needs to be improved in two ways:

If the user passes a String, remember that String and only look up the publication when you actually need it later.
Add an overload publications(DomainObjectCollection<? extends Publication> publications) and use publications.all {} to listen to additions to that container. This will allow users to conveniently specify that they want to publish all publications or publications matching certain criteria.

Once that is fixed we can look into your usage of afterEvaluate to make the Artifactory plugin play together better with a wider range of other plugins.

Hi @oehme
I just wanted to ask if you had a chance to go over what I've send previously?
Thanks

Not yet, I'll get back to you next week.

Great thanks appreciate this @oehme

I'm figuring the same issue, I don't understand what fix I have to apply.
Do I have to configure publishing manually?

The fix was incorporated into a newer version of the plugin (see jfrog/build-info#86).

I'm using
id "com.jfrog.artifactory" version "4.15.1"

but have the issue with markers not published.

I would bring it up with the JFrog team.

@RoRoche  can you share your build.gradle?

plugins {
id 'groovy'
id 'java-gradle-plugin'
id "com.jfrog.artifactory" version "4.15.2"
id 'maven'
id 'maven-publish'
}
group 'com.myCompany.myPackage.gradle'
version '1.0.0-SNAPSHOT'
project.description = 'A description'
project.group = 'com.myCompany.myPackage.gradle'
project.version = '1.0.0-SNAPSHOT'
project.ext.pluginId = 'com.myCompany.myPackage.gradle.myPackage-myPlugin'
dependencies {
compile gradleApi()
compile 'org.codehaus.groovy:groovy-all:2.5.4'
testCompile group: 'junit', name: 'junit', version: '4.12'
}
gradlePlugin {
plugins {
myPlugin {
id = project.pluginId
implementationClass = 'com.myCompany.myPackage.gradle.MyPlugin'
}
}
}
artifactory {
contextUrl = "${artifactoryHost}"
def snapshotsRepoKey = "libs-snapshot"
def releasesRepoKey = "libs-release"
publish {
repository {
repoKey = version.endsWith('SNAPSHOT') ? snapshotsRepoKey : releasesRepoKey
username = "${artifactoryUser}"
password = "${artifactoryToken}"
maven = true
}
defaults {
publications 'pluginPublication'
publishBuildInfo = true
publishArtifacts = true
publishPom = true
}
}
}
publishing {
publications {
pluginPublication(MavenPublication) {
from components.java
groupId project.group
artifactId project.name
version project.version
}
}
repositories {
maven {
def snapshotsRepoUrl = "${artifactoryHost}/libs-snapshot"
def releasesRepoUrl = "${artifactoryHost}/libs-release"
url = version.endsWith('SNAPSHOT') ? snapshotsRepoUrl : releasesRepoUrl
credentials {
username "${artifactoryUser}"
password "${artifactoryToken}"
}
}
}
}

For those lost; here is a simple build.gradle that works -- it publishes markers as well as plugin.   a more recent version of the jfrom artifactory plugin (I'm using 4.16.1) is required. thanks @edeandrea for upstream efforts there.
plugins {
    id 'com.jfrog.artifactory' version '4.16.1' // https://www.jfrog.com/confluence/display/rtf/gradle+artifactory+plugin

    id 'java-gradle-plugin'
    id 'maven-publish'
}

group = 'com.acme.ci'
version = '0.0.1'
sourceCompatibility = '11'

gradlePlugin {
    plugins {
        platorm {
            id = 'com.acme.ci.platform'
            implementationClass = 'com.acme.ci.PlatformGradlePlugin'
        }
    }
}

repositories {
    mavenLocal()
    maven {
        url 'https://packages.acme.com/artifactory/acme-maven'
        credentials {
            username = "${artifactory_user}"
            password = "${artifactory_password}"
        }
    }
}

artifactory {
    contextUrl = "https://packages.cofense-tools.com/artifactory"
    publish {
        defaults {
            publications 'pluginMaven', 'platormPluginMarkerMaven'
            // 'platformPluginMarkerMaven' comes from gradlePlugin defs line 14
        }
        repository {
            repoKey = 'acme-maven'
            username = "${artifactory_user}"
            password = "${artifactory_password}"
        }
    }
}

compileJava.finalizedBy publishToMavenLocal

be sure to change platormPluginMarkerMaven to yourPluginNamePluginMarkerMaven as needed

I'm still having this problem in jfrog plugin v4.18.0.
Setting --configure-on-demand to true helps, but it breaks something else on our project.
Please take a look at this answer: https://github.com/gradle/gradle/issues/4783#issuecomment-393184042


Bump up onnx version

to eb139446590ad631b7e6b6782ddf620ac9240295
For new functions and ops

/test

Seems to fail in protobuf error:
[libprotobuf ERROR /home/travis/build/pfnet-research/chainer-compiler/third_party/protobuf/src/google/protobuf/descriptor.cc:3597] Invalid proto descriptor for file "chxvm.proto":
[libprotobuf ERROR /home/travis/build/pfnet-research/chainer-compiler/third_party/protobuf/src/google/protobuf/descriptor.cc:3600]   chxvm.proto: Unrecognized syntax: range
[libprotobuf FATAL /home/travis/build/pfnet-research/chainer-compiler/third_party/protobuf/src/google/protobuf/generated_message_reflection.cc:2355] CHECK failed: file != NULL:

Somehow invalid range string is exposed

Sorry I should have mention this earlier, but I think this is due to menoh. It wrongly expose all symbols publicly. As the result, there are multiple protobuf implementations. Could you check if temporarily disabling run_onnx_menoh fixes the issue?

/test

Seems shape inference of  Resize is failing

/test

/test

/test


Support arbitrary code snippets

It seems like trying to keep the default snippet up-to-date will be a bit of a challenge, and a bit unnecessary. This PR supports the inclusion of an arbitrary code snippet to allow the consumer to specify the snippet themselves as Segment updates and/or changes. I also updated the Segment code to the current version.
It also adds some dev experience things:

Linting
Moves build output to the /dist directory
Adds a prepare script to build things before publishing

very nice @newhouse ! you're legend for these changes. much appreciated! 🙏🏽

Thanks and happy to help!
I tried to move everything to a /dist folder, but I think Gatsby does some weird/non-standard things with regards to packages/plugins, so it broke it and I moved them back.
Gonna merge now and would love a publish when you can, thanks!

bump @benjaminhoffman ...still waiting for you to merge and cut a release....thanks!

@newhouse do you not already have the perms to do this?  I'm happy to but prefer to unblock you for future PRs.  I will check your permissions.

@TomPridham any issues or concerns with this before I merge and re-deploy?
@newhouse are you interested in helping maintain this lib? No specific requirements or time commitment but would love if you could be a bit more involved for future changes.

@TomPridham any issues or concerns with this before I merge and re-deploy?
@newhouse are you interested in helping maintain this lib? No specific requirements or time commitment but would love if you could be a bit more involved for future changes.

@benjaminhoffman I'm fine with being a collaborator/contributor on this to help out if/when I can. In order to merge this, I need write access to this repo. In order to also release things on NPM, I'd need access there, too.

this looks good to me! thanks for adding linting

@newhouse done and done

@newhouse done and done

Thanks! I updated the README and CHANGELOG, then merged and published on npm as v.3.7.0.


update regexp to 11.1 to pass maven-verifier-plugin

Otherwise, build won't pass
Can you review ? @n1hility

Fixed by https://github.com/wildfly/wildfly/pull/10594


Attestation check for Protected Audience failed

Hello,
I am trying to get the demo running locally on Chrome Beta. However, I run into the following issue for the advertiser website.
Attestation check for Protected Audience on https://protected-audience-demo-dsp.web.app failed.
I encounter the same problem on https://protected-audience-demo-advertiser.web.app/ as well.
I have set the flag #privacy-sandbox-ads-apis as Enabled.
Can you please provide some insights as to what is missing?
Best regards,
Mini

Hello,
I am facing the same problem here, even when I disable attestation and k-anonymity checks by executing chrome using --disable-features=EnforcePrivacySandboxAttestations,FledgeEnforceKAnonymity
Did you find any solution to this ?
Thanks!


Add llm-ollama package

I'd like to have package llm-ollama in nixhub.io (which is ollama plugin for llm) so I can install it with existing llm package.
https://github.com/taketwo/llm-ollama

I could be wrong, but I'd assume it needs to be in nixpkgs first: https://github.com/NixOS/nixpkgs

@glennpratt do you know easy way how to add it to nixpkgs?


ANSI C and flags

First of all, great project!
When using the cflag -ansi, commenting by using // can't be used so the code won't compile and standard error is produce.
The code for test:
//%cflags:-ansi -Wall -pedantic

#include <stdio.h>

int main()
{
   printf("Hello, World!");
   return 0;
}

The Error:
/tmp/tmpuzigbjpm.c:1:1: error: C++ style comments are not allowed in ISO C90
 //%cflags:-ansi -Wall -pedantic
 ^
/tmp/tmpuzigbjpm.c:1:1: error: (this will be reported only once per input file)
[C kernel] GCC exited with code 1, the executable will not be executed

Screenshot for additional information:

Thanks!

Propose to fix this issue in - PR-56


Fragments don't import scalars correctly

scalars don't seem to be imported by fragments, unless part of a nested type.
Very excited about 0.9.x btw, looking forward to reworking graphql-to-io-ts to use the template helpers 👍

@micimize I'm considering to deprecate the multiple files generators. What do you think? is there any special usage you can't do with the single template?

Not that I can think of off the top of my head. It's convenient for viewing generated definitions in editors that don't handle large files well, but if it's a maintenance pain point then it's probably not worth it.
Is this only a problem because it's a multiple-file edge case?

@micimize It's hard to maintain and we find a lot of bugs (usually related to missing imports or missing data).

@dotansimha Ok, let me try refactoring to single-file and get back to you, although I don't think it'll be a problem for typescript. It's harder to think about the possible problems across all languages, but I think even "convenience directory structuring" could be solved by allowing multiple top level templates

Hi @micimize , any update?
I've been thinking a lot about that, and in every project that we initially started with multiple files template, we eventually refactored it and used the single file, since it's easier to use and easier to import from.

@dotansimha finally got around to implementing single-file, no problems so far. I think we can safely close this and commit to deprecating multi-file outputs.


HRESULT static fields not easily usable in switches

Actual behavior
switch(...)
{
-   case HRESULT.S_OK:
    default:
        throw new NotImplementedException();
}

Error CS9135 A constant value of type 'HRESULT' is expected

Expected behavior
Naturally switch on HRESULT values against compile-time statics.
Context

CsWin32 version: 0.3.49-beta
Win32Metadata version (if explicitly set by project):
Target Framework: net8.0-windows10.0.19041.0
LangVersion (if explicitly set by project): [e.g. 9]

Oh boy, I wish we could.
But C# doesn't allow defining constants typed as a custom struct. That as you see in the error precludes them from being used in a switch statement. If HRESULT was an enum it would work, but after a long discussion it was decided that HRESULT should not be expressed as an enum for a few reasons, including:

Enums convey an idea of an exhaustive list of allowed values. This isn't actually true, but it almost always is.
Enums do not support custom members such as methods or conversion operators, which would make HRESULT much less user friendly in some cases. Extension methods can be defined, but this cannot adequately fill the gap.

So I'm afraid C# forces code to use if statements instead.

Of the two arguments I can agree with 2. but 1. looks weak to me, as CsWin32 is already used to create an incomplete list of HRESULT values. Also, other than not providing a fast path for switch scenarios, generating values as readonly properties waste a little memory at runtime. So why not combine the best of two worlds? For example:
public struct HRESULT
{
    public enum Values : int
    {
        S_OK = 0,
        // ...
    }

    public static implicit operator Values(HRESULT value) => (Values)(int)value;
}

generating values as readonly properties wastes a little memory at runtime

These are static fields, so we're losing 4 bytes of memory each. We could avoid that by making them property getters instead, but I really wouldn't worry about saving 4 bytes of memory per specially requested HRESULT value.
Your nested enum approach means a lot more casting. Not just in the generated code but in user code, because HRESULT will be the type used in all the APIs not HRESULT.Values. Especially for users that have to declare their own HRESULT values, enums will be a significant step backward in usability.

Your nested enum approach means a lot more casting.

Are you concerned more about cost of casting in CPU cycles or requiring manual casting in the user code (or both)? Implicit casting certainly reduces the hassle of having the values being in another type, but as you say HRESULT is "open" so there's should be not much fear about castling implicitly an integer to HRESULT (currently the cast is explicit).  Also I have no specific technical knowledge about the ability of the compiler to trim trivial operator conversions, but I'm hoping it can do a good job in release builds (won't it?). enum as I was suggesting may be overkill: have you also considered for example having the values to be just const integers? Something like the following:
public struct HRESULT
{
    int value;

    public const int S_OK = 0;

    public const int S_FALSE = 1;

    public HRESULT(int value)
    {
        this.value = value;
    }

    public static implicit operator int(HRESULT hres) => hres.value;

    public static implicit operator HRESULT(int value) => new HRESULT(value);
}

class Program
{
    public static int Main(string[] _)
    {
        var rc = Foo();
        switch (rc)
        {
            case HRESULT.S_OK:
            {
                break;
            }
            case HRESULT.S_FALSE:
            {
                break;
            }
        }

        return 0;
    }

    static HRESULT Foo()
    {
        return HRESULT.S_FALSE;
    }
}

Sorry to keep arguing about this topic again, but I think you've kind of overlooked the switch scenario and the fact that some C rooted developers really want to use it.

I assure you I haven't overlooked the switch scenario.
I'm not concerned at all with the runtime cost of casting. I'm trying to optimize the C# experience.
There are pros and cons each way, and as we've already evaluated it, and nothing has changed in the C# language that would alter the points we considered, I am not interested in spending time reevaluating it.


Set miner username and password

A user should be able to set the username/password for the miner via the HASS interface.  This could be passed as an initial configuration parameter to the config flow.  It would also be nice to be able to change it after the miner is created via the UI, and just have it edit the config entry, although I'm not sure what would be required to do this.
Once set via HASS, the miner.pwd and miner.username attributes can be updated.

v1.0.1 allows setting of user/pass now


Add troubleshooting note about high fees failing 'buildroute'

Description
We came across this issue in one of our ring groups that has us stuck for a while because a few folks used 1,000,000 ppm defensive fee rates.
When rings are first set up high defensive fees are set to prevent routing until circular rebalancing is done. If the ring leader tries to test that all nodes are properly connected using $ lncli buildroute before doing the rebalance, they can sometimes incorrectly come up on a route failure if combined fees along the route are too high.

Merged, will use the opportunity to add more info on defensive fee policies as well 👌


Add the column_name_case option

Should close https://github.com/simolus3/drift/issues/1068
Add the column_name_case option to the builder
The possible options are

preserve
camel_case
CONSTANT_CASE
snake_case
PascalCase
lowercase
UPPERCASE

I wonder if this should also apply to table names? E.g. if I have class UserGroupMemberships extends Table class in Dart, should the option affect the table's SQL name too?

Sure, would it be better to create another option for that? Or do you think I should reuse the same one (and then, rename it) ?

Sure, would it be better to create another option for that? Or do you think I should reuse the same one (and then, rename it) ?

I can't think of a case where the table and columm name casing should be different. If it turns out to be something that users want, we can still introduce a separate option for it later.

@simolus3 I renamed to option into case_from_dart_to_sql in 🚚 Rename column_name_case into case_from_dart_to_sql and applied it to tables in ♻ apply the recase option to table name
However, the test file I create is drift_dev/test/analysis/resolver/dart/column_test.dart, but it is now also testing the names of the tables. Do you want me to rename it and/or move it somewhere else?

For the CI / sqlparser, I see those logs 🤔
Run dart analyze --fatal-infos --fatal-warnings
Analyzing sqlparser...
The analysis server timed out while shutting down.
No issues found!
The analysis server shut down unexpectedly.
Please report this at dartbug.com.
Error: Process completed with exit code 1.

And I don't think I'm allowed to re-run the job

And I don't think I'm allowed to re-run the job

I just re-ran it, it's probably a rare bug in the analysis server and not our fault.


12062024 NSC2223 tSQL Merge.sql

Updated to account for new column name changes because it was getting confusing.

I hope this works.


Unseeable missing operand secrets

v2.23.32
?- C= + + + .
Error: syntax error, missing operand, user:1
   false.

?- C= + + + ,true .
   C = + +(+).

Can it be true that ",true"  is the missing operand?

No, bug.
On Fri, Jul 28, 2023 at 12:15 PM flexoron @.***> wrote:

v2.23.32
?- C= + + + .
Error: syntax error, missing operand, user:1
false.
?- C= + + + ,true .
C = + +(+).
Can it be true that ",true" is the missing operand?
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/286, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSEVMAAF6PT3ARPCHHDTXSMODTANCNFSM6AAAAAA223577Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Side effect:
?- C= + + + .
Error: syntax error, missing operand, user:1
   false.
?- C= + + + ,true .
   C = + +(+).
?- C= + + + .
Error: syntax error, missing operand, user:1
?-
"false." not printed


edge-simplified-installer pr #1654 failed to build edge-installer image

This bug is against #1654 , but not the main branch.
Describe the bug
I tried to build an edge-installer image with pr #1654 , but failed. The output of osbuild-worker is:
Aug 24 21:49:12 85iso2 osbuild-worker[35529]: Waiting for a new job...
Aug 24 21:54:32 85iso2 osbuild-worker[35529]: Running 'osbuild' job a1b51e13-edf8-4182-b7bc-5904c68e6c89
Aug 24 21:54:51 85iso2 osbuild-worker[35529]: Traceback (most recent call last):
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:   File "/usr/bin/osbuild", line 11, in
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:     load_entry_point('osbuild==30', 'console_scripts', 'osbuild')()
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:   File "/usr/lib/python3.6/site-packages/osbuild/main_cli.py", line 141, in osbuild_cli
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:     output_directory=output_directory
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:   File "/usr/lib/python3.6/site-packages/osbuild/pipeline.py", line 348, in build
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:     source.download(store, libdir)
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:   File "/usr/lib/python3.6/site-packages/osbuild/sources.py", line 54, in download
Aug 24 21:54:51 85iso2 osbuild-worker[35529]:     raise RuntimeError(f"{source}: " + reply["error"])
Aug 24 21:54:51 85iso2 osbuild-worker[35529]: RuntimeError: org.osbuild.curl: curl: error downloading {'url': 'http://download.eng.bos.redhat.com/rhel-8/nightly/RHEL-8/latest-RHEL-8.5.0/compose/BaseOS/x86_64/os/Packages/glibc-langpack-en-2.28-162.el8.x86_64.rpm'}: error code 22
Aug 24 21:54:51 85iso2 osbuild-worker[35529]: 2021/08/24 21:54:51 Job a1b51e13-edf8-4182-b7bc-5904c68e6c89 failed: error decoding osbuild output: unexpected end of JSON input
Aug 24 21:54:51 85iso2 osbuild-worker[35529]: the raw output:
Aug 24 21:54:51 85iso2 osbuild-worker[35529]: Waiting for a new job...
I checked this url, it is 404. Seems osbuild is trying to get this package from a wrong place. Maybe this problem is related to the files under /etc/osbuild-composer/repositories?
Environment
As same as #1660
To Reproduce
Steps to reproduce the behavior:

Build an edge-installer image
[root@85iso2 workspace]# composer-cli compose start-ostree installer edge-installer --ref rhel/8/x86_64/edge --url http://<IP_ADDRESS>/repo/
Failed.

Expected behavior
Should be able to build edge-installer image successfully.
Additional context
Add any other context about the problem here.

This is caused by nightly sync issue, after changed to rpmrepo, it works now.
Closing this bug.


Play a voice message via web interface

Add the ability to play a selected voice message from a caller via the web interface.

Voice mail messages (in v0.3) are stored in a folder and are identified by the call_no embedded in the file name. (In v0.4, will look at storing the messages in blobs in the sqlite database)
Consider adding a Messages  menu item that displays a formatted list of the .wav files coupled with the call data from the call log.
Consider using the HTML5 <audio> element to play the message.


How to Paginate?

I can't seem to find anyways to obtain the last_evaluated_key in the high level api.
Looking at the Model code, the last_evaluated_key is never passed back to the caller of Model scan, query, or rate_limited_scan. And as a result, I can't do pagination. How are people doing manual pagination with the high level api? Isn't this needed for most applications, especially mobile app? I am so confused.
Thanks.

There's a Google Group dedicated to asking questions:
https://groups.google.com/forum/#!forum/pynamodb
Here are a few issues asking exactly the same question:
https://github.com/jlafon/PynamoDB/issues/231
https://github.com/jlafon/PynamoDB/issues/207
And here is a PR trying to implement it:
https://github.com/jlafon/PynamoDB/pull/226
So to answer your question: you have to implement it yourself.

Can we except an official implementation to get access to the last evaluted key value ?

a quick solution is to simply reconstruct a last key base on the last item fetched.
and use that directly. Its a dict. But it doesn't seem to work on index query, I tried to reconstruct one base one the index keys but it does not work on the index query. I can only get default keys to works with scan

For anyone who happens upon this looking for an answer, last_evaluated_key is of the form:
last_evaluated_key={'my_hash_key': {'S': 'afsdfasdfasdf'}, 'my_range_key': {'S': 'afsdfasvdfvxz'}}

Assuming your hash key and range key are both strings.

This doesn't work for hash keys in global secondary indexes

Fixed in #379


CLI freeze if dump file is too big

At current realisation, dumper write trace/dump content into stdout.
Then CLI read log from job pod and write it into local file.
If trace/dump file is too big, then Docker at k8s node rotate log files, CLI freezes, no files copied at the local FS.
See - https://docs.docker.com/config/containers/logging/json-file/
Sample configuration at k8s node:
{
 "live-restore": true,
 "log-driver": "json-file",
 "log-opts": {
   "max-size": "50m",
   "max-file": "5"
 }
}

Some suggestions:

Send files into blob
Send files into PVC
Use kubectl cp mechanism to copy file from pod to local FS.

fixed by #6


 Recently one of my colleagues found this error and some of the files went missing after stashed. My colleagues sometimes lose their unstaged files (the files got stashed, normally the index also at 1 instead of index 0). I manage to restore it for them, but this could be stressful for both me and them.
Steps to reproduce
Couldn't find a way to reproduce this
Debug Logs
error-log-lint.txt
npm.txt
Environment

OS: Windows 10, Windows 10 with Debian WSL
Node.js: v12.18.2
lint-staged: 10.3.0
git: 2.20.1

Also is there an option to silently write debug output to file without showing on console? I'm thinking of creating a file that get ignored by git for each user

Hello,
the npm.txt shows an error that indicates the git commit would've been empty. This is expected behaviour. I do not see any errors in the error-log-lint.txt, however.
What files were lost? In the npm.txt it seems files were restored:
[SUCCESS] Reverting to original state because of errors...

For what it's worth, you can disable the stash loging by setting the --no-stash cli flag. With the stash disabled, failures will leave linter changes in the git working tree (not staged).
For debugging, we use the debug library. I don't think it supports logging to a file. Maybe you can open a feature request there?

Hi @iiroj thx for the reply. Seems like I didn't manage to log the output when the files when missing after getting linted (it was in stash index). I'll check the debug library for the logging feature.
I'm trying to debug this from lint-staged file, will re-open this if I couldn't fix this.

Hi @Qix-, thanks for the reply, do you mind telling me how log the output into file without actually showing it on console?

command > file.txt isn't working?

I'm trying to save a log whenever this ran without actually showing too much stuff on the console, is it possible?

Anything is possible, but it's not clear what you've tried and what isn't working.

I don't see anything that has to do with debug (for context, I'm here because you opened an issue at visionmedia/debug and then pinged me here).
I am not a collaborator on this package, nor do I have any control over any of the output you have shown here. I don't see any output from debug. I do not maintain 'all debug output' and thus have no idea how to help you with your problem.


Minor refactor to remove redundant test class

There were two WeightNormLSTMCellTest classes that differed in formatting only.  Removed the (original) one at end of file since based on history, the version above it contained latest formatting updates.

This PR was small subset of changes since addressed in PR 16647 which handles all recent sanity issues..


Improve behaviour during network failure / downed nodes

I noticed a few things on the behaviour for network issues that could simplify / improve the system in such situations and wanted to share them to start a discussion on the topic.
The first thing I noticed is that RaftNetworkFactory::connect returns Network not Result<Netowrk> this prevent's the runtime from gracefully handling downed nodes.
The second thing I noticed is that when network errors occur, there is no backoff, meaning that in the case of an error, the system just keeps hammering the other side relentlessly.
This gave me the thought to perhaps treat the networking bit somewhat like erlang does for servers, meaning all calls become available, and errors will lead to eventual reinitialization and backoff.
This would allow moving the downed node behavior into the runtime and saving people from needing to implement reconnects etc., for themself.
So as a first thought:
If we make RaftNetworkFactory::connect failable, the raft engine can keep track of successful and unsuccessful connections. Unsuccessful connections can be re-initialized using a backoff strategy (exponential backoff with a limit, perhaps eventually a trait that could be passed to fine-tune this).
All errors in the network lead to the network state being set to downed, forcing a reconnect. (Not sure about this, this could also lead to problems perhaps some level of escalating grace period x errors for downed, or X errors in N time for downed would be betteR)
With those two things, the network becomes quite a bit easier to write, and a lot of the more complicated (and more error-prone) logic could be hoisted into the engine.

If we make RaftNetworkFactory::connect failable, the raft engine can keep track of successful and unsuccessful connections. Unsuccessful connections can be re-initialized using a backoff strategy (exponential backoff with a limit, perhaps eventually a trait that could be passed to fine-tune this).

By design, RaftNetworkFactory::connect() is not meant to let an application make a real TCP connection at once, but instead, it is meant to let an application create an instance that will actually build a TCP connection when one of send_append_entries(), send_vote() or send_install_snapshot() is called.
Thus the error handling such as backoff should be implemented inside send_append_entries() and is application specific.
Is this a way that will solve your problem?
You are right; the method name connect() is slightly misleading.

All errors in the network lead to the network state being set to downed, forcing a reconnect. (Not sure about this, this could also lead to problems perhaps some level of escalating grace period x errors for downed, or X errors in N time for downed would be betteR)

Like the above, an application can track network issues inside their implementation, such as inside an implementation of send_append_entries().
Is this OK for you?

Oh, that connect just initializes a stand-by network makes a lot of sense for the signature. I still would prefer a Result to be honest for nothing else as it allows other things to be available (for example, address parsing) or allowing for perform validation on the Network to ensure it's sensible configured but that's really a low priority preference :)
As to having logic in the implementation I'm honestly torn, I mean it's OK but I am conflicted if it's "good" or "optional".
The conflicting thoughts on that I have are.
On one side complex applications will probably want a high degree of control - so they will want to do a lot of the logic themsefls.
On the other side, much of network connection handling logic will be very similar and the raft engine knows more about the state than the application (i.e. it could optimize for long-lasting vs one-off connections from knowledge of ring state and how nodes communicate). Also for new applications, I totally see a big benefit in abstracting part of that away, but perhaps the solution here is not make the engine do it to provide something like rocks-store just as tcp-network, or websocket-netowrk that is a bit of a drop in networking for people that deem it as "good enough"?

Oh, that connect just initializes a stand-by network makes a lot of sense for the signature. I still would prefer a Result to be honest for nothing else as it allows other things to be available (for example, address parsing) or allowing for perform validation on the Network to ensure it's sensible configured but that's really a low priority preference :)

If a function returns an error, it assumes the caller can handle it appropriately.
But openraft can not deal with an application error(it could be any error), the only thing it can do is to stop running.
Thus from this point, the application can just panic() if it encounters an error when building a network instance, IMHO.

On the other side, much of network connection handling logic will be very similar and the raft engine knows more about the state than the application (i.e. it could optimize for long-lasting vs one-off connections from knowledge of ring state and how nodes communicate).

Hmm... I'm afraid I can not agree that the raft engine knows more than the network implementation. Everything about the network raft knows can only be reported by the network implementation. Thus a decision can just be made by the implementation itself.
Actually in one of my project there is an Arc<ConnectionPool> in the RaftNetwork implementation. This way it can create a persistent connection or just one-shot connection by its need.
BTW, extracting common logic from these 3 RaftNetwork methods into a separate function does not look like difficult to me. :DD

After a night, it feels RaftNetworkFactory::connect() returning a Result would be better.
As you said, there may be misconfigured node addresses being used. In such cases, the raft has a chance to discover it early. But still, the raft can do nothing about such an error, except print an error log.
Using Result instead of panic() will let the cluster keep working even when there is only a minority of misconfigured nodes.

Yay :)
Looking more into the second part of it, I don't think backoffs can be implemented in the application, if a request takes too long I get these errors:
[2022-07-21T09:23:12Z ERROR openraft::replication] error replication to target=3141107818908514662 error=timeout after 50ms when AppendEntries 0->3141107818908514662

The timeout is controlled by the heartbeat interval, i.e, an RPC to send entries or to send a heartbeat(an empty send-entries request) should not take longer than the interval between two heartbeats:
https://github.com/datafuselabs/openraft/blob/d40dabe684d86b7e1b30807cba7f8bd5c8464493/openraft/src/replication/mod.rs#L326
It's possible to add another config to control the max timeout for an RPC to solve this problem. This way an application can have a backoff algorithm that takes a long time.
But this will introduce another problem: a follower that does not receive an RPC from the leader will switch to a candidate state and starts to elect.
In other words, no matter what the backoff algorithm is, a send-entries or heartbeat RPC that can not finish in heartbeat interval will always break the cluster and result in a new round of election.

(why they take too long is a different question :P)

(I do not care:D)

but since it timeouts after 50ms the backoff for failure can't be done in the application, any backoff would simply be overruled by the timeout. So that is something where extending the engine seems to be required?

As I explained, a backoff should never exceed the heartbeat interval or the leadership will lose

Oh yes a timeout to a "functioning" node is not the scenario I'm concerned about, I'm thinking about a scenario where for (reason) a node in a cluster (or two) are down. Let me draw the worst case scenario to illustrate.
We have a 7 node cluster. All set up and running smoonthy.
Now we encoutner one of those dreaded network partitions (Oh no!), and split the cluster in two, for simplicities sake lets say side A (1,2,3,4) and and side B (5,6,7)
On both sides at least one of the nodes will now start hammering the network every heartbeat_interval trying to reach the other nodes getting network failures over and over again.
A should to re-elect, a leader (yay!) but B won't (that's fine). But even after the leader election we still have the problem that said leader will keep trying to connect 5-7  every 50ms (default) or in other words, try to open 60 (3x1000/50) network connections every second which will not help the system health and potentially make the failure situation worse. 60 new connections per second aren't terrible, but the problem gets worse with every new member in the cluster (and I'm not sure how it behaves on the B side where no leader is elected, I suspect all nodes will try to reach out?).

This is where I feel a backoff strategy would make a lot of sense, it is what I would implement in a client library to save the upstream service from being overflooded with errors or the requesting system to get clogged up with network problems.
I don't think this would make short term worse, as the current timeout already equals the heartbeat interval so if it is hit we're in re-election territory anyway so missing one or five heartbeats doesn't make much of a difference at that point

A should to re-elect, a leader (yay!) but B won't (that's fine). But even after the leader election we still have the problem that said leader will keep trying to connect 5-7 every 50ms (default) or in other words, try to open 60 (3x1000/50) network connections every second which will not help the system health and potentially make the failure situation worse. 60 new connections per second aren't terrible, but the problem gets worse with every new member in the cluster.

An application could record the last several failures to send out RPC, and if the application believes there are too many errors, it could sleep for every to stop sending out any RPC.
Then the raft will timeouts this RPC, and will retry later around. E.g.:
impl RaftNetwork for AppNetwork {
  fn send_vote(&mut self, vote) {
    if self.failures > 3 {
      sleep(10000000).await;
    }
    let res = self.tcp.send(vote).await;
    if res.is_err() { self.failures+=1; ) else { self.failures = 0; };
    res
  }
}

This way, you do not have to set heartbeat_interval or other configs to an insane value to implement a backoff behavior.

(and I'm not sure how it behaves on the B side where no leader is elected, I suspect all nodes will try to reach out?).

Yes, nodes in sub-cluster B will try to elect and will always fail.

I don't think that would work. When I read the code correctly that timeout would simply lead to a lot of them piling up and being executed later - as the vote is spawed in a new task and doesn't prevent multiple of those tasks to be spawned in parallel.
What I could see is returning an error on each call instead of sending; perhaps that's an option? Perhaps with adding something like ReplicationError::Backoff ?

I don't think that would work. When I read the code correctly that timeout would simply lead to a lot of them piling up and being executed later - as the vote is spawed in a new task and doesn't prevent multiple of those tasks to be spawned in parallel.

Right. vote request should have timeout control. This is a missing feature :(.
It should be done the same as append-entries does:
https://github.com/datafuselabs/openraft/blob/062d24cbdeb4939469a400772e494554be4232b6/openraft/src/core/raft_core.rs#L390-L409

What I could see is returning an error on each call instead of sending; perhaps that's an option? Perhaps with adding something like ReplicationError::Backoff ?

When the raft sees a BackOff error, what does it do with it?
As I can see, it is application specific. The raft could just stop calling RaftNetwork API for a while. But what if the application wants to retry sending out some data to check if the network is restored?
IMHO, it's the raft's responsibility to tell the application what should be done, and it's the application's responsibility to decide how to do it.
Raft just needs to ensure everything goes well no matter what the application's decision is, e.g., not to pile up too many unfinished tasks.

The way append-entries we're back to the problem that the ttl overrides the timeout in the application, if ttl is 50ms and the application wants to delay for 1s the delay would be canceled after 50ms bringing it to the problem of having set silly long ttl for requests :(
async-timeouts cancel the offending future if the timeout is hit so any sleep in there will simply be canceled out ahead of time :(
What I was thinking is that backoff could signal a duration for how long the raft engine shouldn't try to communicate with the node in question. That sounds like somewhat of a decent compromise, it leaves all logic related to backoffs in the application while allowing the application to truly stop the engine from trying to communicate with a node.

IMHO, it's the raft's responsibility to tell the application what should be done, and it's the application's responsibility to decide how to do it.

I kind of agree :D that's why my initial thought was that backoff could live in the engine, that way the engine tells the application when it's not OK to keep beating a dead horse bothering a dead host, the application the only would be responsible for the communication when things are fine. It sure would make it easier to get a good :tm: implementation at the cost of not allowing to super specialize it unless the strategy is trained out.

I'm following your discussion, since we have a similar problem in our project - we don't want to send unnecessary messages (and we don't even want to send empty ping messages, see below).
We have a different method for keeping "liveness" info of a link between two nodes. As long as the link is deemed "live" any consensus domains communicating via this link (we have replicas of multiple/many consensus domains hosted on the same node) we expect the message to ultimately go through. As soon as the "liveness" property is not guaranteed anymore, we can inform all affected consensus domains about the fact and thus for example let them start a new election after the timeout. I.e., instead of empty ping messages, we have external liveness check.
I didn't look into the implementation in openraft yet, but this external liveness check could be likely integrated fairly simply instead of traditional heartbeat. Then, as soon as the link is deemed down by the external agent (which can do for example its own heartbeat on behalf of multiple consensus domains), we can tell all affected local openraft replicas, so they can start their "usual" handling of replication timeout (and start an election on a follower).
@Licenser Maybe you could live with something like this as well? Not sure about your use case. But, as I wrote, this is in a concept phase and it isn't implemented yet, we wanted to start with simple openraft and initially use UDP directly to transport messages.

The way append-entries we're back to the problem that the ttl overrides the timeout in the application, if ttl is 50ms and the application wants to delay for 1s the delay would be canceled after 50ms bringing it to the problem of having set silly long ttl for requests :(

The heartbeat interval should be longer than the time a normal RPC takes. So that raft could work correctly.
If an application tries to delay 1s while the heartbeat interval is 50ms, it could just sleep for the next 20 heartbeat RPC. And raft is responsible to guarantee no piling up.

async-timeouts cancel the offending future if the timeout is hit so any sleep in there will simply be canceled out ahead of time :(

Right.
The application needs to have a global backoff sleep time. Not just a per-RPC sleep time.

What I was thinking is that backoff could signal a duration for how long the raft engine shouldn't try to communicate with the node in question. That sounds like somewhat of a decent compromise, it leaves all logic related to backoffs in the application while allowing the application to truly stop the engine from trying to communicate with a node.

If to implement such a feature, it will just be a wrapper of RaftNetwork, e.g.,:
struct BackoffNetwork<N: RaftNetwork> {
    backoff: Instant,
    inner: N,
}

impl<N> RaftNetwork for BackoffNetwork<N> {
    fn send_append_entries(&mut self, req) -> Result<> {
        if Instant::now() < self.backoff {
            sleep(100000000).await;
        }

        let res = self.inner.send_append_entries(req).await;
        if let RPCError::Backoff(sleep_time) = 7res {
            self.backoff = Instant::now() + sleep_time;
        } else {
            // no need to backoff
            self.backoff = Instant::now();
        }
        res
    }
}

And if it is just a wrapper(and it meets your need:D), it can be just implemented by an application without introducing a wrapper.

IMHO, it's the raft's responsibility to tell the application what should be done, and it's the application's responsibility to decide how to do it.

I kind of agree :D that's why my initial thought was that backoff could live in the engine, that way the engine tells the application when it's not OK to keep ~beating a dead horse~ bothering a dead host, the application the only would be responsible for the communication when things are fine. It sure would make it easier to get a good ™ implementation at the cost of not allowing to super specialize it unless the strategy is trained out.

May the network wrapper above meet your need to separate backoff and sending-rpc?

EDIT:
My main problem is that in the current implementation, timeouts and spawns make it pretty much impossible for the application to take responsibility as it's decisions will be overwritten by either a timeout or a spawn, and the engine doesn't handle backoffs either.

Right. That's why the backoff time should be global instead of per-RPC.

Sorry for the late reply, the last few days have been hectic. That's a really neat idea, I never thought about that kind of layering, and I really like it! It would still give timeout errors in the logs but it's a good stop-gap :).

We still hit the 50ms heartbeat timeout. Why would this wrapper let the app sleep? Doesn't BackoffNetwork's send_append_entries have its own 50ms timeout to deal with since it also implements the RaftNetwork trait?

If send_append_entries() does not return in 50ms, it(the Future running send_append_entries()  will be dropped, and a timeout error will occur. It's as expected IMHO, No? 🤔

Since I'm still (again) dealing with this.
I think the issue people are trying to deal with here is that if there is a node down, other nodes will create an error log every 50ms which is computationally and IO costly and also makes it really hard to understand the error as any meaningful message. Basically a single downed/incapacitated node now harms the entire cluster by spamming all logs with repeated messages.
This is where the idea of a timeout came from, for an operator there is no benefit of seeing 20 messages/second of RPCError err=timeout after 50ms when AppendEntries and for a network perspective there is no benefit of re-trying a connection 20 times a second if it's down.
The network part can be dealt with (as described above) by adding a sleep in the RaftNetwork implementation but the first problem, the spammy logs, is impossible to fix / adjust for a user of the library.
Moving the timeout into the core library would solve both problems, but if that's not the goal that's understandable too it makes it a bit harder to use but more flexible which is a fair traidoff, that said as the library exists now the spam problem is impossible to fix which makes it really hard to use it in any production capacity.

This is where the idea of a timeout came from, for an operator there is no benefit of seeing 20 messages/second of RPCError err=timeout after 50ms when AppendEntries and for a network perspective there is no benefit of re-trying a connection 20 times a second if it's down.

@Licenser
You're correct, I hadn't considered the possibility of error message flooding. In this case, the replication mod should be able to handle nodes that are unreachable.
Such an error will be returned to openraft in RPCError:
https://github.com/drmingdrmer/openraft/blob/17a658f41ba193609ee3ac626149ef50592d937c/openraft/src/error.rs#L245-L254
My initial proposal is to allow an implementation of RaftNetwork::send_append_entries() to return a designated error(Unreachable(NodeId)) that indicates a delay in retrying the operation. Openraft also enables users to define their own backoff algorithm or use a default one.
Opinion?

That sounds like a great solution, that way the implementation can return Unreachable(NodeId) if it is in "backoff mode" and then try to re-connect when it gets the next error! Brilliant :D I love it!

BTW, I'm wondering if the backoff is the right way to go. It depends on the network implementation. If you have a relatively low volume of updates and use, for instance, UDP to send the messages, then yes, this will likely work very well.
What I am worried about is when you have a lot of data to send. Then, the server will retry sending entire missing log at once. Maybe it would be better to allow the connection to report a partial success. Say, I want to send 100 entries, 50 are through and then the timeout hits. The next time, we'll try to re-send all 100 entries (and some) again, so the timeout hits after 50 entries again. And we'll never make progress. Of course, this can likely be handled in the Network implementation by noting down the last successful entry index before the send was killed by the timeout and next time just sending the rest.
But, it might be more desirable to pass the ttl to send_append_entries() instead of limiting the time to send from the outside. As long as there is progress sending individual entries, the call would not time out. I.e., instead of timeouting the entire call of sending 100 entries, you'd time out sending individual entries in the network implementation. This could be made even compatible, by invoking a default-implemented wrapper method send_append_entries_with_timeout(), which would by default just call timeout(ttl, send_append_entries(...)).await.
Any take on this?


Communication between comet actor and snippet via RequestVar

There are use cases when one wants to hand over params from CometActor to snippets via RequestVars. One example would be a SHtml.link() within a CometActor where the parameter could be passed by a RequestVar snapshot.
This issue is discussed in https://groups.google.com/forum/#!topic/liftweb/N_yNYnaErhQ

The snippet refactor I want to work on for, amongst other things, #1799, may provide some better approaches here. We're dealing with some of these issues at work and have come up with a few interesting ways to try to deal with it.


PyVRP does not want to insert optional clients when empty vehicles have high enough fixed cost

Problem
Suppose I have an instance with fixed vehicle costs and optional clients. In our local search, clients not in the solution have an insertion move evaluated in the client's granular neighbourhood. That's fine, and will re-use existing routes where possible.
When all existing routes are full, however, this effectively prevents new routes from being used for newly inserted clients, which is particularly problematic when there is a cost associated with vehicle use (since otherwise the regular local search might open up new routes, and missing clients can be inserted there in the next iteration).
I do not know what the solution should be but I do want to track this issue somewhere.
Example
Consider the following simple test case:
import numpy as np

from pyvrp import ProblemData, Solution, RandomNumberGenerator, CostEvaluator, Depot, Client, VehicleType
from pyvrp.search import LocalSearch, NODE_OPERATORS, ROUTE_OPERATORS, compute_neighbours

data = ProblemData(
    depots=[Depot(0, 0)],
    clients=[
        Client(
            0,
            0,
            delivery=1,
            prize=2,
            required=False,
        )
        for _ in range(10)
    ],
    vehicle_types=[VehicleType(2, capacity=5, fixed_cost=5)],
    distance_matrices=[np.zeros((11, 11))],
    duration_matrices=[np.zeros((11, 11))],
)

rng = RandomNumberGenerator(seed=42)
search = LocalSearch(data, rng, compute_neighbours(data))
for node_op in NODE_OPERATORS:
    search.add_node_operator(node_op(data))
for route_op in ROUTE_OPERATORS:
    search.add_route_operator(route_op(data))

cost_eval = CostEvaluator(100, 1, 1)

init_sol = Solution(data, [[1, 2, 3, 4, 5]])
improved = search(init_sol, cost_eval)
assert improved == init_sol

best = Solution(data, [[1, 2, 3, 4, 5], [6, 7, 8, 9, 10]])
assert cost_eval.cost(best) < cost_eval.cost(init_sol)

I don't necessarily consider this to be a bug, but it is a place where some performance improvement could be had.

Not sure if we should fix this in the local search, per se, or in the initial solutions. We stopped adding complete solutions to the initial solution pool a while back. We could have a look at what kind of solutions we generate there, and see if we can improve the distribution over vehicles/# clients a bit?

@leonlan you don't happen to have a BSc thesis student or anything who could have a look at the impact of initial starting solutions on, say, performance after 30s or 1min over a variety of VRP variants/instances? I might have to go look for one in Rotterdam to figure this out. Would be well-suited for a BSc thesis to investigate this a bit more rigorously.

In the example, the initial solution has 5 clients with 1 vehicle, but the best solution has all 10 clients distributed over 2 vehicles. The problem is that local search does not insert the optional clients because LocalSearch::insert only inserts positive delta cost moves and only inserts after its neighbors (and routes[0][0]), which must be in an existing route.

Not sure if we should fix this in the local search, per se, or in the initial solutions. We stopped adding complete solutions to the initial solution pool a while back. We could have a look at what kind of solutions we generate there, and see if we can improve the distribution over vehicles/# clients a bit? Having some diversity there might help a lot with ensuring valuable clients remain in a solution.

I think this is a lack of "search" by the local search. Our strategy to open new routes only based on improving moves does not work well with high fixed costs (this may also be behind HFVRP performance #558?), and inserting optional clients only if it's an improving move is also somewhat limited in search scope.
I think redistributing the initial solution distribution in terms of optional clients (none vs. all) has a reasonable chance of success and is easy to try in the short term.

@leonlan you don't happen to have a BSc thesis student or anything who could have a look at the impact of initial starting solutions on, say, performance after 30s or 1min over a variety of VRP variants/instances? I might have to go look for one in Rotterdam to figure this out. Would be well-suited for a BSc thesis to investigate this a bit more rigorously:

I don't have any bachelor thesis students, unfortunately.

I think this is a lack of "search" by the local search. Our strategy to open new routes only based on improving moves does not work well with high fixed costs (this may also be behind HFVRP performance #558?), and inserting optional clients only if it's an improving move is also somewhat limited in search scope.

Possibly. It is just hard in general. I think we should somehow look into smoothening vehicle costs, because right now there's this huge hill to climb when trying to insert a client into a new route.

What also worked in my case is to just set individual prizes that are bigger than the fixed vehicle cost. That's a practical way to work around this issue; it does not resolve the fact we have difficulty solving instances like this.


crosstool_wrapper_driver_is_not_gcc cannot find libpython2.7.so.1.0

I encountered error
python2: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
while trying to install tensorflow from source with GPU-enabled.
I can see the error command is
(cd /home/xxx/.cache/bazel/bazel_xxx/d568262eb4464bf011ab3d998aff21ac/tensorflow &&
exec env -
INTERCEPT_LOCALLY_EXECUTABLE=1
PATH=/share/software/python/2.7.10/Python-2.7.10/release/bin:/share/software/java/jdk1.8.0_66/bin:/share/software/NLP/bazel/output:/usr/local/cuda/bin:/opt/attila/:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibutils/bin:/usr/local/MATLAB/R2014a/bin
third_party/gpus/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections '-std=c++11' -iquote . -iquote bazel-out/local_linux-opt/genfiles -isystem tools/cpp/gcc3 -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE_="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' '-frandom-seed=bazel-out/local_linux-opt/bin/external/gemmlowp/_objs/eight_bit_int_gemm/external/gemmlowp/eight_bit_int_gemm/eight_bit_int_gemm.o' -MD -MF bazel-out/local_linux-opt/bin/external/gemmlowp/_objs/eight_bit_int_gemm/external/gemmlowp/eight_bit_int_gemm/eight_bit_int_gemm.d -c external/gemmlowp/eight_bit_int_gemm/eight_bit_int_gemm.cc -o bazel-out/local_linux-opt/bin/external/gemmlowp/_objs/eight_bit_int_gemm/external/gemmlowp/eight_bit_int_gemm/eight_bit_int_gemm.o)
I guess the problem is I'm using a local python version, which is installed under
/share/software/python/2.7.10/Python-2.7.10/release/bin
and path to libpython2.7.so.1.0 is not accessible.
If I add LD_LIBRARY_PATH=/share/software/python/2.7.10/Python-2.7.10/release/lib to the error command, I would be able to get rid of the error.
It seems to me bazel does not allow user to add ld_library_path(?), so what should I do in this case..?
This error has bothered me for days and I still cannot get over it.... Thank you in advance for your help and suggestions!

If building from HEAD, you should be able to use ./configure to specify the path of the python you want to use -- let us know if that works.

Hi vrv,
I have pulled the most recent version, and configure python with the local installation. However, the error is still there.
actually the lib link points to the site-package, which I assume will resolve numpy errors.
python_include -> /share/software/python/2.7.10/Python-2.7.10/release/include/python2.7
python_lib -> /share/software/python/2.7.10/Python-2.7.10/release/lib/python2.7/site-packages
I have created softlink to libpython2.7.so.1.0 under /share/software/python/2.7.10/Python-
2.7.10/release/lib/python2.7/site-packages, which doesn't help either...
thanks!

where is your libpython2.7.so.1.0?  what directory is it in?
have you tried using a virtualenv with that python, and pointing configure at that virtualenv?

Can you do something for me?  Load up the version of python you set up with config, and run:
from distutils import sysconfig
print sysconfig.get_config_vars('LIBPL')
it should return a path.  can you reply with that path?  also, for the path, type: ls -l <>  (and paste the results here as well)

@girving  we may need to point the pythonX_path to a script (copied from a template via e.g. sed) which sets the LD_LIBRARY_PATH correctly based on e.g. LIBPL output, and calls the python interpreter.

Hi ebrevdo,
libpython2.7.so.1.0 is under /share/software/python/2.7.10/Python-2.7.10/release/lib
Here is the output.
print sysconfig.get_config_vars('LIBPL')
['/share/software/python/2.7.10/Python-2.7.10/release/lib/python2.7/config']
ls -l /share/software/python/2.7.10/Python-2.7.10/release/lib/python2.7/config
total 9768
-rw-rw-r--. 1 xxxx    2200 Oct  2 15:44 config.c
-rw-rw-r--. 1 xxxx    1507 Oct  2 15:44 config.c.in
-rwxrwxr-x. 1 xxxx    7122 Oct  2 15:44 install-sh
-rw-rw-r--. 1 xxxx 9883714 Oct  2 15:44 libpython2.7.a
-rw-rw-r--. 1 xxxx   49734 Oct  2 15:44 Makefile
-rwxrwxr-x. 1 xxxx    7431 Oct  2 15:44 makesetup
-rw-rw-r--. 1 xxxx    6256 Oct  2 15:44 python.o
-rw-rw-r--. 1 xxxx   18479 Oct  2 15:44 Setup
-rw-rw-r--. 1 xxxx     368 Oct  2 15:44 Setup.config
-rw-rw-r--. 1 xxxx      41 Oct  2 15:44 Setup.local

Interesting.  Can you run the python-config associated with that python
bin?  i imagine it's something like:
/share/software/python/2.7.10/Python-2.7.10/release/python-config
can you run it separately with each of: --ldflags, --cflags, --includes,
--libs, --prefix, --exec-prefix?
thanks!
On Sat, Dec 5, 2015 at 9:40 PM, Luzy<EMAIL_ADDRESS>wrote:

Hi ebrevdo,
libpython2.7.so.1.0 is under
/share/software/python/2.7.10/Python-2.7.10/release/lib
Here is the output.
print sysconfig.get_config_vars('LIBPL')
['/share/software/python/2.7.10/Python-2.7.10/release/lib/python2.7/config']
ls -l
/share/software/python/2.7.10/Python-2.7.10/release/lib/python2.7/config
total 9768
-rw-rw-r--. 1 xxxx 2200 Oct 2 15:44 config.c
-rw-rw-r--. 1 xxxx 1507 Oct 2 15:44 config.c.in
-rwxrwxr-x. 1 xxxx 7122 Oct 2 15:44 install-sh
-rw-rw-r--. 1 xxxx 9883714 Oct 2 15:44 libpython2.7.a
-rw-rw-r--. 1 xxxx 49734 Oct 2 15:44 Makefile
-rwxrwxr-x. 1 xxxx 7431 Oct 2 15:44 makesetup
-rw-rw-r--. 1 xxxx 6256 Oct 2 15:44 python.o
-rw-rw-r--. 1 xxxx 18479 Oct 2 15:44 Setup
-rw-rw-r--. 1 xxxx 368 Oct 2 15:44 Setup.config
-rw-rw-r--. 1 xxxx 41 Oct 2 15:44 Setup.local
—
Reply to this email directly or view it on GitHub
https://github.com/tensorflow/tensorflow/issues/414#issuecomment-162272677
.

I am using /share/software/python/2.7.10/Python-2.7.10/release/bin/python in configure under tensorflow, but have that error.
There is a
/share/software/python/2.7.10/Python-2.7.10/release/bin/python2.7-config file, are you suggesting me to do anything with this file?
thanks a lot!

Here is the result (your comment was folded previously, and did not get the flags the first time)
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --cflags
-I/share/software/python/2.7.10/Python-2.7.10/release/include/python2.7 -I/share/software/python/2.7.10/Python-2.7.10/release/include/python2.7 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --includes
-I/share/software/python/2.7.10/Python-2.7.10/release/include/python2.7 -I/share/software/python/2.7.10/Python-2.7.10/release/include/python2.7
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --libs
-lpython2.7 -lpthread -ldl -lutil -lm
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --prefix
/share/software/python/2.7.10/Python-2.7.10/release
/share/software/python/2.7.10/Python-2.7.10/release/bin/python-config --exec-prefix
/share/software/python/2.7.10/Python-2.7.10/release

On my machine, libpython...so is in
/usr/lib/python2.7/config-x86_64-linux-gnu
and my python-config --ldflags adds this line:
-L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib
in contrast, on your system we can't use python-config to get the location of the so file.
In addition, while on my system I can find a copy of the .so file in my LIBPL directory, on your system it isn't there.  It's very strange.
You seem to have a fairly nonstandard installation of python 2.7.  Are you an administrator of this machine?  Perhaps you could reinstall python?  Or install a version of python in your home directory, where you have write permissions and can install a properly built version?

@vrv: Reassigning since Eugene is out.

Hi,
Here is an update. Unfortunately I don't have admin access to the machine.
I installed another python with config
./configure --prefix=$PWD/release/ --enable-shared LDFLAGS="-L$PWD/release/lib/python2.7/config -Wl,--rpath=$PWD/release/lib/python2.7/config -L$PWD/release/lib/ -Wl,--rpath=$PWD/release/lib/" CPPFLAGS="-I$PWD/release/include"
(I found these from some stackoverflow answers, though I don't fully understand how it works yet)
though libpython...so is still not under lib/python2.7/config/, nor does python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic return -L....
I was able to get pass that libpython2.7.so.1.0 not found error building tensorflow.
But I encountered error
/usr/bin/env: python2.7: No such file or directory
ERROR: /share/software/tensorflow/google/protobuf/BUILD:270:1: Linking of rule '//google/protobuf:protoc' failed: crosstool_wrapper_driver_is_not_gcc failed: ....
because the command generated by bazel seems not to set the PATH variable (I do not understand why)
(cd /home/zhiyunlu/.cache/bazel/_bazel_zhiyunlu/d568262eb4464bf011ab3d998aff21ac/tensorflow &&
exec env -
third_party/gpus/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc....)
So I fixed the problem by changing the first line of crosstool_wrapper_driver_is_not_gcc to be
#!/share/software/python/2.7.10/Python-2.7.10-tf/release/bin/python2
to run with specific python I installed.
With some other modifications to use local gcc installation version (issue649), I am able to build tensorflow successfully.
I saw many warnings, for example
warning: calling a host function from a host device function is not allowed.
But I assume it is okay...?
So I think the libpython...so problem is fixed now. Thanks a lot for helping this out!

The warnings are fine. The underlying Eigen library doesn't always mark
functions as OK to run on a gpu, even if they are. That results in many of
the warnings.
On Dec 8, 2015 7:25 PM, "Luzy"<EMAIL_ADDRESS>wrote:

Hi,
Here is an update. Unfortunately I don't have admin access to the machine.
I installed another python with config
./configure --prefix=$PWD/release/ --enable-shared
LDFLAGS="-L$PWD/release/lib/python2.7/config
-Wl,--rpath=$PWD/release/lib/python2.7/config -L$PWD/release/lib/
-Wl,--rpath=$PWD/release/lib/" CPPFLAGS="-I$PWD/release/include"
(I found these from some stackoverflow answers, though I don't fully
understand how it works yet)
though libpython...so is still not under lib/python2.7/config/, nor does
python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic return
-L....
I was able to get pass that libpython2.7.so.1.0 not found error building
tensorflow.
But I encountered error
/usr/bin/env: python2.7: No such file or directory
ERROR: /share/software/tensorflow/google/protobuf/BUILD:270:1: Linking of
rule '//google/protobuf:protoc' failed: crosstool_wrapper_driver_is_not_gcc
failed: ....
because the command generated by bazel seems not to set the PATH variable
(I do not understand why)
(cd
/home/zhiyunlu/.cache/bazel/_bazel_zhiyunlu/d568262eb4464bf011ab3d998aff21ac/tensorflow
&&
exec env - \
third_party/gpus/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc....)
So I fixed the problem by changing the first line of
crosstool_wrapper_driver_is_not_gcc to be
#!/share/software/python/2.7.10/Python-2.7.10-tf/release/bin/python2
to run with specific python I installed.
With some other modifications to use local gcc installation version (
issue649 https://github.com/bazelbuild/bazel/issues/649), I am able to
build tensorflow successfully.
I saw many warnings, for example
warning: calling a host function from a host device function is not
allowed.
But I assume it is okay...?
So I think the libpython...so problem is fixed now. Thanks a lot for
helping this out!
—
Reply to this email directly or view it on GitHub
https://github.com/tensorflow/tensorflow/issues/414#issuecomment-163113984
.


Question: Using a pretrained encoder for getting the speaker embedding.

Hi,
Did you guys experiment using a pretrained encoder for getting the speaker embedding similar to your previous work (AutoVC).
PS: Amazing work by the way!
Thanks,

@nischal-sanil did you make it work?
can you check my question please? https://github.com/auspicious3000/SpeechSplit/issues/28

@nischal-sanil did you make it work?
can you check my question please? https://github.com/auspicious3000/SpeechSplit/issues/28

I have the same question @auspicious3000
Here you use the one-hot encoded embedding with a lent of 82 (the number of speakers it was pretrained), but could you generate a zeros-shot general embedding like in AutoVC. If I am correct the size of the used embedding was larger in that, I assume you cannot use that here.
So to wrap up: this method with the pretrained weights works only on the 82 speakers it was trained and conditioned on if we consider only the timbre conversion?

@terbed Yes. Unless you retrain the model.


fix: make platform usage consistent

Noticed inconsistent patter for setting and using PlatformOS across components. This fixes it.

Codecov Report

Merging #39 (45ee80c) into main (3de08e2) will not change coverage.
The diff coverage is 66.66%.

@@            Coverage Diff            @@
##               main      #39   +/-   ##
=========================================
  Coverage     89.37%   89.37%
  Complexity      415      415
=========================================
  Files            59       59
  Lines          1779     1779
  Branches         72       72
=========================================
  Hits           1590     1590
  Misses          162      162
  Partials         27       27

Impacted Files
Coverage Δ

...hilcali/device/pool/ec2/Ec2ReservationService.java
94.87% <66.66%> (ø)

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 3de08e2...45ee80c. Read the comment docs.


Crash on startup with latest nvim from Git

Error executing vim.schedule lua callback: .../nvim/site/pack/packer/start/conjure/lua/conjure/log.lua:192: Expected Lua number
stack traceback:
        [C]: in function 'win_is_valid'
        .../nvim/site/pack/packer/start/conjure/lua/conjure/log.lua:192: in function 'display_hud'
        .../nvim/site/pack/packer/start/conjure/lua/conjure/log.lua:357: in function 'append'
        ...tart/conjure/lua/conjure/client/clojure/nrepl/action.lua:139: in function <...tart/conjure/lua/conjure/client/clojure/nrepl/action.lua:84>

Probably related to https://github.com/neovim/neovim/pull/16745/files
Nvim's own code base not immune to this change, they had to fix some of their own stuff: https://github.com/neovim/neovim/commit/36662c961244f41996720a0eec8eac67a18f2ec0
fnl/conjure/log.fnl line 165 needs to be changed to something like (when (and state.hud.id (not (nvim.win_is_valid state.hud.id))) ... ) ??

I'm seeing this too, after upgrading to the latest unstable version of Neovim.

Agreed that it's related and that'll also be the fix 😄 can't do it right now though I'm afraid, if you open a PR to develop I'll get it merged ASAP then release soon.

Hello, I have the same problem, there is any, at least, temporary solution?

@spartakos87 Until the next release of Conjure (which I think will include this fix), we can run the development branch, which I can confirm is stable at the moment.
On my system, ~/.vim/bundle is the directory where vim-plug clones plugin repos. It might be different on your system, but assuming that it's the same, you can run:
cd ~/.vim/bundle/conjure
git checkout develop --
git pull

Should be all good now! Sorry for the delay!

Thanks Ollie!


SEC-191 - Upgrade Jetty in rest-utils

9.4.14.v20181114 -> 9.4.18.v20190429

It looks like @milosimpson hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.
Once you've signed reply with [clabot:check] to prove it.
Appreciation of efforts,
clabot

[clabot:check]

@confluentinc It looks like @milosimpson just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

Should this be backported as well?


Name shows up as 'undefined' until user refreshes the page.

When someone deposits, it will put the items and prices and update everything else, but it will make their name 'undefined' until you refresh the page. Any idea how to fix it?

i work on this issues but atm its normal

check your web api key ;)

Add some if in script.js ,, if its not undefinder then ... ,,


Large front-end bundles?

Hello!
First, this is an amazing package, and makes the CMS work so much easier!
This could be a misconfiguration on my end, but it looks like the bundle sizes of the react code from the example are very large. It looks like the entire icon package is served.
Perhaps a version of this lazy loading code may be suggested instead?
          const ComponentA = dynamic(() => {
            switch (icon.provider) {
              case 'mdi':
                return import(`react-icons/md`).then((mod) => mod[icon.name!]);
              case 'fa':
                return import(`react-icons/fa`).then((mod) => mod[icon.name!]);
              default:
                return import(`react-icons/fa`).then(
                  (mod) => mod.FaMapMarkerAlt
                );
            }
          });

Thank you for writing this plugin :)

Closed, this is more of an issue with react-icons not being tree-shakeable.

What if an SVG was set as a part of the data as well to make this more front-end language-agnostic & avoid large builds?
Eg:
  const setIcon: SearchResultsOnSelectCallback = (icon) => {
    if (selected && icon.name === selected.name) return unsetIcon();

    onChange([
      setIfMissing({
        _type: schemaType.name,
      }),
      set(icon.name, ['name']),
      set(icon.provider, ['provider']),
      set(renderToString(icon.component()), ['svg']), // <-- addition
    ]);

Hi @blueputty01! Indeed it doesn't seem like there is much that can be done regarding react-icons. How ever your last proposal is actually something I've been thinking about. Might be something we can implement that could be toggled on with an option. Feel free to create a PR. I have limited time at this point but will try to find time to stay more active with this lib asap 😊

Hi @christopherafbjur! I'll look into this more and open a PR hopefully next weekend.
Reopening since I think that the link to the PR will be more clear. Thanks again for this plugin!

Tested your proposed solution @blueputty01 but it seems that it requires configuring vite with polyfills which is probably not the job for this plugin (I assume you were thinking of using renderToString method from react-dom/server dependency). But feel free to correct me if I'm wrong :)
Another solution that I tested and that seem to work is:
Plugin
import {format, plugins} from 'pretty-format';
import renderer from 'react-test-renderer';
...
...
const setIcon: SearchResultsOnSelectCallback = (icon) => {
    if (selected && icon.name === selected.name) return unsetIcon()

    const svgString = format(renderer.create(icon.component()).toJSON(), {
      plugins: [plugins.ReactTestComponent],
      printFunctionName: false,
    }).replace(/\s+|\n/gm, ' ')
    // <svg fill="none" height="1em" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" strokeWidth="2" style={ Object { "color": undefined, } } viewBox="0 0 24 24" width="1em" xmlns="http://www.w3.org/2000/svg" > <path d="M5 17H4a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h16a2 2 0 0 1 2 2v10a2 2 0 0 1-2 2h-1" /> <polygon points="12 15 17 21 7 21 12 15" /> </svg>

    onChange([
      setIfMissing({
        _type: schemaType.name,
      }),
      set(icon.name, ['name']),
      set(icon.provider, ['provider']),
      set(svgString, ['svg']),
    ])

    return setSelected(icon)
  }

Client
import SVG from 'react-inlinesvg';

const sanityResponse = {
    "_type": "iconPicker",
    "name": "arrow-down-circle",
    "provider": "fi",
    "svg": "<svg fill=\"none\" height=\"1em\" stroke=\"currentColor\" strokeLinecap=\"round\" strokeLinejoin=\"round\" strokeWidth=\"2\" style={ Object { \"color\": undefined, } } viewBox=\"0 0 24 24\" width=\"1em\" xmlns=\"http://www.w3.org/2000/svg\" > <circle cx=\"12\" cy=\"12\" r=\"10\" /> <polyline points=\"8 12 12 16 16 12\" /> <line x1=\"12\" x2=\"12\" y1=\"8\" y2=\"16\" /> </svg>"
  }
...
<SVG src={sanityResponse.svg} />

@christopherafbjur Thanks for taking a look at this! I was indeed thinking of the function from react-dom/server. Your solution is more clean.
Issue:
The sample client component works well in my tests.
Using encodeURIComponent to populate the src attribute on an img tag using the generated SVG markup doesn't seem to work as well.
It seems like the parser gets confused by the curly braces in the style attribute: style={ Object { \"color\": undefined, } }
Proposal:

A regex expression eg \{.*\} to remove objects from the final string
Removing the style key/any keys with object type values from the react-test-renderer object before passing it to pretty-format
Possibly leave it as an upstream/downstream issue...?

Issue example:
For example, the fi alert circle passed into encodeURIComponent produces the error: error on line 1 at column 120: AttValue: " or ' expected
Generated SVG:
<svg fill="none" height="1em" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" strokeWidth="2" style={ Object { "color": undefined, } } viewBox="0 0 24 24" width="1em" xmlns="http://www.w3.org/2000/svg" > <circle cx="12" cy="12" r="10" /> <line x1="12" x2="12" y1="8" y2="12" /> <line x1="12" x2="12.01" y1="16" y2="16" /> </svg>
src attr:
data:image/svg+xml;utf8,%3Csvg%20fill%3D%22none%22%20height%3D%221em%22%20stroke%3D%22currentColor%22%20strokeLinecap%3D%22round%22%20strokeLinejoin%3D%22round%22%20strokeWidth%3D%222%22%20style%3D%7B%20Object%20%7B%20%22color%22%3A%20undefined%2C%20%7D%20%7D%20viewBox%3D%220%200%2024%2024%22%20width%3D%221em%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20%3E%20%3Ccircle%20cx%3D%2212%22%20cy%3D%2212%22%20r%3D%2210%22%20%2F%3E%20%3Cline%20x1%3D%2212%22%20x2%3D%2212%22%20y1%3D%228%22%20y2%3D%2212%22%20%2F%3E%20%3Cline%20x1%3D%2212%22%20x2%3D%2212.01%22%20y1%3D%2216%22%20y2%3D%2216%22%20%2F%3E%20%3C%2Fsvg%3E

@blueputty01 Thank you for digging deeper into this. Your proposal for removing the style object before passing it to pretty-format seems like the most clean solution to me.
How ever I just discovered another problem with the parsing from pretty-format which cause inconsistencies in the original SVGs and the one saved to later be used in the client.
Issue:

Using fi alert circle
Left icon is the parsed svg string after running it through pretty-format, right icon is the original one from react-icons.
Comparison:
Left (parsed)
<svg fill="none" height="1em" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" strokeWidth="2" viewBox="0 0 24 24" width="1em" xmlns="http://www.w3.org/2000/svg"><circle cx="12" cy="12" r="10" /><line x1="12" x2="12" y1="8" y2="12" /><line x1="12" x2="12.01" y1="16" y2="16" /></svg>

Right (original)
<svg stroke="currentColor" fill="none" stroke-width="2" viewBox="0 0 24 24" stroke-linecap="round" stroke-linejoin="round" style="width: 1.5em; height: 1em;" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><circle cx="12" cy="12" r="10"></circle><line x1="12" y1="8" x2="12" y2="12"></line><line x1="12" y1="16" x2="12.01" y2="16"></line></svg>

The difference in attribute order when comparing the two made it quite difficult to see the issue, but the issue is the attribute casing for some attributes where it's using kebab casing for the original one (as it should) but using camel casing for the parsed one. As an example strokeLinecap for parsed and stroke-linecap for original.
One possible solution might be to simply convert all occurrences of camel casing to kebab casing but this might also create more problems since, for instance, attribute viewBox is using camel casing in both cases. I will have to do some research on this.

@blueputty01 Created a draft PR for this. I think this should work. Please let me know what you think and if you see any potential improvements. Not really found of having to define an array of ignores for the camel cased attributes and unaware if all of them are really required for this use case

@christopherafbjur I'll be honest, I don't know much about these libraries. However, @testing-library/react seems to avoid all the issues we identified:
import { render } from '@testing-library/react';
...
const svgString = render(icon.component).baseElement;

Generated fi alert circle:
<svg stroke="currentColor" fill="none" stroke-width="2" viewBox="0 0 24 24" stroke-linecap="round" stroke-linejoin="round" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><circle cx="12" cy="12" r="10"></circle><line x1="12" y1="8" x2="12" y2="12"></line><line x1="12" y1="16" x2="12.01" y2="16"></line></svg>

@blueputty01 Thank you for this proposal, this was a really neat idea! How ever I was unable to reproduce this using .baseElement when testing in a studio since it was returning the document.body which seem to be the expected behavior (reference).
How ever I could reproduce the same svg string if instead using
render(icon.component()).container.innerHTML. The problem however is that in both scenarios (using the render method) a div will be appended to document.body to which the icon component will be appended (reference).
And in our case this means that each time we select an icon in the picker, a div will be appended to the document.body since it's never removed.
Example of clicking between 3 different icons

@christopherafbjur Oops! That's definitely not ideal.
Took a deeper look into your PR, and I don't see any direct improvements I could recommend!
Alternatively, what if we took advantage of the existing element from the sanity UI button? This would resolve our casing issue.
Eg:
This would obviously need additional typings, but I'd be happy to open a PR to add that myself if you'd like.
IconPicker:
  const setIcon: SearchResultsOnSelectCallback = (
    icon: IconObject,
    ele: HTMLButtonElement
  ) => {
    if (selected && icon.name === selected.name) return unsetIcon();

    const svgString = ele.getElementsByTagName('svg')[0].outerHTML; // <--here

SearchResults:
  function IconButton(icon: IconObject) {
    const buttonRef = useRef<HTMLButtonElement>(null);

    return (
      <Button
        ref={buttonRef} // <--here
        key={icon.provider.concat(icon.name)}
        mode="ghost"
        onClick={() => onSelect(icon, buttonRef.current)}
        text={<icon.component />}
        style={{ marginTop: '5px' }}
        selected={
          !!selected &&
          selected.provider === icon.provider &&
          icon.name === selected.name
        }
      />
    );
  }

Also, perhaps the ignore array is unfortunately the only solution: https://github.com/lambdaisland/hiccup/pull/5/commits/29d657126f5d0757c67ababd72d5ac6ba54c72f7

@blueputty01 That looks elegant! I haven't tested this but by the looks of it, it should do the trick and should solve the attribute casing things with quite a reduced amount of lines. Feel free to create a PR 🙂

any update on it?
i really need it to reduce my frontend package.
maybe i can make the PR if it can help

@christopherafbjur Created a PR! Let me know your thoughts :)

thanks @blueputty01 looks like a smart & sharp solution

Checked this briefly and it looks great! Will have a closer look tomorrow @blueputty01


Enhance Hero Section Usability and Scroll-to-Top Button Visibility

Is your feature request related to a problem? Please describe.
The hero section isn’t very user-friendly; the black font is difficult to see against the background image. Additionally, the scroll-to-top button appears on the screen without needing to scroll.
Describe the solution you'd like.
I propose enhancing the hero section's styles by adding a translucent overlay to improve visibility, changing the font color to white, and improving the UI of the buttons for a better design. I will also ensure that this style is applied to the hero sections across all pages for a consistent UI. For the scroll-to-top button, I’d like to make it visible only after scrolling and enhance its UI to align with the current interface.
Describe alternatives you've considered.
An alternative could be adjusting the background image or using different font colors. However, these may not provide the same level of accessibility and visual appeal as the proposed overlay and consistent button styles.
Additional context.
This improvement will enhance overall user experience and accessibility, making navigation smoother and more intuitive.
Show us the magic with screenshots

Checklist

[X] I have checked the Existing Issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

@kavya410004 sure go ahead

Make sure to join the discord server for further communication
Don't forget to star the repository
Complete the task in next 2 days and kindly mention your issue # in your pr like:
Closes #IssueNumber

Note: the level of the issue may change based on the quality of the PR code

@kavya410004 sure go ahead

Make sure to join the discord server for further communication
Don't forget to star the repository
Complete the task in next 2 days and kindly mention your issue # in your pr like:
Closes #IssueNumber

Note: the level of the issue may change based on the quality of the PR code

Thank you @Apoorva57 I will start working on this.

Hi @Apoorva57 , I'm actively working on this issue and should be able to complete it within the next day. Please let me know if that is okay!

Hi @Apoorva57 , I'm actively working on this issue and should be able to complete it within the next day. Please let me know if that is okay!

@kavya410004 try to finish it by today

Its been more than 2 weeks and no pull request was made so we are closing this issue.


[TR#117] Folder Structure Documentation

Task
TR #117
Why?
In Talking with  @scriswell , we worked through how best to structure our css to both organize and make clearer where we are customizing Optics vs creating specific for a project.
What Changed

[X] Add Organization documentation page

Sanity Check

[X] Have you updated any usage of changed tokens?
[X] Have you updated the docs with any component changes?

[X] Have you tried building the css?
[X] Have you tried building storybook?
Do you need to update the package version?

Screenshots

 Folder Structure


Program: Refactor to use Token-2022 Pod types

This PR lightly refactors the program to use Token-2022's Pod types, which
should slightly enhance performance.

This PR is going to fail, since a token account initialized with &[5; 165] does not register as "uninitialized". Therefore, it's successfully being unpacked as a PodAccount and hitting a different program check (mint mismatch).
See https://github.com/solana-labs/solana-program-library/pull/6953.


Add contributing-related documentation

These files are required by dxw tech team RFC 28. The content is taken from dxw/.github@002ebd0cfe8862e741de64b9b6ee675d2eced840.
This pull request was generated by dxw’s repo-audit.

Closing this PR as this repo is a fork.


EnergiBridge Integration

This PR implements a self-measurement feature for RunnerConfig, such that a user can simply specify self-measure=True, and receive energy measurements in their results.

Currently only supports Linux (could also support other oses if needed)
Requires EnergiBridge to already be installed

Also implements customizable install location for EnergiBridge, as its user installed it might be in different locations
Added config validation for self-measure
Added an example of how to enable self-measurement.

Closing this request, its implementation was moved to the Pico CM3 PR.


Install go1.10.2 failed with errno 38 (netpoll failed)

Your Windows build number:  (Type ver at a Windows Command Prompt)

Microsoft Windows [版本 10.0.14393]

What you're doing and what's happening:  (Copy&paste specific commands and their output, or include screen shots)

I installed the go1.10.2 followed the golang official guide, but got some error. I have already report it to golang, but it seems not a Go bug.

What's wrong / what should be happening instead:

Go tools works well.

The problem is almost certainly that with Go 1.10.1 we changed from calling the epoll_wait system call to calling the epoll_pwait system call.  I bet that WSL implements the former but not the latter.  epoll_pwait has been in the Linux kernel since 2.6.19.

My kingdom for people to fill out the issue template. In which case the ENOSYS wouldn't be a speculative bet but instead show up in the requested strace log.

Build 14393 lacks many features, including epoll_pwait. When you are able to update I think you will be happy with how much better things work.