[Doc][Improve] support chinese

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
support chinese
Please pick file you want to translate it!

File
Contributer
Status
PR

faq.md
@baicie

#6349

Connector-v2-release-state.md
@baicie

#6349

about.md
@baicie

#6349

connector-v2/Config-Encryption-Decryption.md

connector-v2/Error-Quick-Reference-Manual.md

concept/config.md
@JueLance

concept/JobEnvConfig.md
@JueLance

concept/connector-v2-features.md
@JueLance

concept/speed-limit.md
@JueLance

concept/schema-feature.md
@JueLance

contribution/coding-guide.md
@wineternity

contribution/setup.md
@wineternity

contribution/contribute-transform-v2-guide.md
@wineternity

contribution/contribute-plugin.md
@wineternity

contribution/new-license.md
@wineternity

transform-v2/filter.md
@lihjChina

transform-v2/split.md
@lihjChina

transform-v2/jsonpath.md
@lihjChina

transform-v2/replace.md
@lihjChina

transform-v2/sql.md
@lihjChina

transform-v2/sql-udf.md
@lihjChina

transform-v2/sql-functions.md
@lihjChina

transform-v2/filter-rowkind.md
@lihjChina

transform-v2/field-mapper.md
@lihjChina

transform-v2/copy.md
@lihjChina

transform-v2/common-options.md
@lihjChina

seatunnel-engine/checkpoint-storage.md

seatunnel-engine/local-mode.md

seatunnel-engine/tcp.md

seatunnel-engine/savepoint.md

seatunnel-engine/cluster-mode.md

seatunnel-engine/cluster-manager.md

seatunnel-engine/deployment.md

seatunnel-engine/engine-jar-storage-mode.md

seatunnel-engine/about.md

seatunnel-engine/rest-api.md

connector-v2/formats/cdc-compatible-debezium-json.md

connector-v2/formats/ogg-json.md

connector-v2/formats/avro.md

connector-v2/formats/kafka-compatible-kafkaconnect-json.md

connector-v2/formats/debezium-json.md

connector-v2/formats/canal-json.md

other-engine/spark.md
@JueLance

other-engine/flink.md
@JueLance

connector-v2/source/kafka.md

connector-v2/source/Snowflake.md

connector-v2/source/FtpFile.md

connector-v2/source/Http.md

connector-v2/source/Iceberg.md

connector-v2/source/Rabbitmq.md

connector-v2/source/Jira.md

connector-v2/source/Postgre-CDC.md

connector-v2/source/MongoDB-CDC.md

connector-v2/source/Hive.md
@silenceland

connector-v2/source/Kingbase.md

connector-v2/source/OneSignal.md

connector-v2/source/Hudi.md

connector-v2/source/Doris.md

connector-v2/source/Greenplum.md

connector-v2/source/OpenMldb.md

connector-v2/source/Redis.md

connector-v2/source/DB2.md

connector-v2/source/InfluxDB.md

connector-v2/source/AmazonSqs.md

connector-v2/source/FakeSource.md

connector-v2/source/Oracle-CDC.md

connector-v2/source/Mysql.md
@silenceland

connector-v2/source/Github.md

connector-v2/source/Vertica.md

connector-v2/source/AmazonDynamoDB.md

connector-v2/source/Oracle.md

connector-v2/source/Notion.md

connector-v2/source/OssJindoFile.md

connector-v2/source/Pulsar.md

connector-v2/source/MySQL-CDC.md

connector-v2/source/Socket.md

connector-v2/source/MyHours.md

connector-v2/source/OceanBase.md
@silenceland

connector-v2/source/StarRocks.md

connector-v2/source/Phoenix.md

connector-v2/source/Kudu.md

connector-v2/source/Klaviyo.md

connector-v2/source/SqlServer.md

connector-v2/source/Clickhouse.md

connector-v2/source/OssFile.md

connector-v2/source/TDengine.md

connector-v2/source/S3File.md

connector-v2/source/Paimon.md

connector-v2/source/Lemlist.md

connector-v2/source/SftpFile.md

connector-v2/source/Persistiq.md

connector-v2/source/Hive-jdbc.md
@silenceland

connector-v2/source/PostgreSQL.md

connector-v2/source/SqlServer-CDC.md

connector-v2/source/Cassandra.md

connector-v2/source/IoTDB.md

connector-v2/source/Elasticsearch.md

connector-v2/source/Jdbc.md

connector-v2/source/GoogleSheets.md

connector-v2/source/common-options.md

connector-v2/source/HdfsFile.md
@CallMeKingsley97

connector-v2/source/Neo4j.md

connector-v2/source/LocalFile.md

connector-v2/source/Gitlab.md

connector-v2/source/MongoDB.md

connector-v2/source/RocketMQ.md

connector-v2/source/CosFile.md

connector-v2/source/Maxcompute.md

connector-v2/sink/Kafka.md

connector-v2/sink/Snowflake.md

connector-v2/sink/Enterprise-WeChat.md

connector-v2/sink/FtpFile.md

connector-v2/sink/Http.md

connector-v2/sink/Email.md

connector-v2/sink/Iceberg.md

connector-v2/sink/Tablestore.md

connector-v2/sink/Rabbitmq.md

connector-v2/sink/Feishu.md
@CallMeKingsley97

connector-v2/sink/Hive.md
@silenceland

connector-v2/sink/Kingbase.md

connector-v2/sink/Doris.md

connector-v2/sink/Greenplum.md

connector-v2/sink/Redis.md

connector-v2/sink/DB2.md

connector-v2/sink/InfluxDB.md

connector-v2/sink/AmazonSqs.md

connector-v2/sink/Slack.md

connector-v2/sink/Mysql.md
@silenceland

connector-v2/sink/Vertica.md

connector-v2/sink/AmazonDynamoDB.md

connector-v2/sink/Oracle.md

connector-v2/sink/OssJindoFile.md

connector-v2/sink/Pulsar.md

connector-v2/sink/Socket.md

connector-v2/sink/OceanBase.md
@silenceland

connector-v2/sink/StarRocks.md

connector-v2/sink/Sentry.md

connector-v2/sink/Hbase.md

connector-v2/sink/Phoenix.md

connector-v2/sink/SelectDB-Cloud.md

connector-v2/sink/Kudu.md

connector-v2/sink/SqlServer.md

connector-v2/sink/DingTalk.md

connector-v2/sink/Clickhouse.md

connector-v2/sink/Datahub.md

connector-v2/sink/OssFile.md

connector-v2/sink/GoogleFirestore.md

connector-v2/sink/TDengine.md

connector-v2/sink/S3File.md

connector-v2/sink/Paimon.md

connector-v2/sink/SftpFile.md

connector-v2/sink/PostgreSql.md

connector-v2/sink/Cassandra.md

connector-v2/sink/IoTDB.md

connector-v2/sink/ClickhouseFile.md

connector-v2/sink/Elasticsearch.md

connector-v2/sink/Console.md

connector-v2/sink/Jdbc.md

connector-v2/sink/S3-Redshift.md

connector-v2/sink/common-options.md

connector-v2/sink/HdfsFile.md
@CallMeKingsley97

connector-v2/sink/Neo4j.md

connector-v2/sink/Assert.md

connector-v2/sink/LocalFile.md

connector-v2/sink/MongoDB.md

connector-v2/sink/RocketMQ.md

connector-v2/sink/CosFile.md

connector-v2/sink/Maxcompute.md

start-v2/docker/docker.md

start-v2/locally/quick-start-flink.md

start-v2/locally/quick-start-seatunnel-engine.md

start-v2/locally/deployment.md
@dzygoon

start-v2/locally/quick-start-spark.md
@dzygoon

Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please assign me the "HdfsFile.md" and "Feishu".md.Thanks

please assign contribution/

Please assign me the transform-v2/split.md、transform-v2/replace.md、transform-v2/sql.md
transform-v2/sql-udf.md、transform-v2/sql-functions.md、transform-v2/filter-rowkind.md、
transform-v2/field-mapper.md、transform-v2/copy.md、transform-v2/common-options.md。Thanks

Please assign me for folder ./docs/concept/ and ./docs/other-engine/. Thanks!

Please assign me for folder ./docs/concept/ and ./docs/other-engine/. Thanks!

My PR is: #6373

Please assign me the connector-v2/source/Mysql.md、connector-v2/sink/Mysql.md、connector-v2/source/OceanBase.md、connector-v2/sink/OceanBase.md、connector-v2/source/Hive.md、connector-v2/sink/Hive.md、connector-v2/source/Hive-jdbc.md. Thx!

Please assign me the "HdfsFile.md" and "Feishu".md.Thanks

My pr is : #6379

start-v2/locally/deployment.md  和  start-v2/locally/quick-start-seatunnel-engine.md   给我吧。

start-v2/locally/deployment.md 和 start-v2/locally/quick-start-seatunnel-engine.md 给我吧。

pr : #6393

start-v2/locally/quick-start-flink.md  也分给我吧

seatunnel-engine/local-mode.md
seatunnel-engine/cluster-mode.md
seatunnel-engine/checkpoint-storage.md
seatunnel-engine/rest-api.md
请分给我

please assign contribution/

pr: #6441

Please assign me source/*, except for those already done

Please assign me the remains of  seatunnel-engine/*

Please assign me the connector-v2/sink/Kafka.md 、connector-v2/sink/Http.md、connector-v2/sink/Email.md、connector-v2/sink/Elasticsearch.md、connector-v2/sink/Console.md	、connector-v2/sink/Jdbc.md。Tks！

Please assign me the connector-v2/sink/Kafka.md 、connector-v2/sink/Http.md、connector-v2/sink/Email.md、connector-v2/sink/Elasticsearch.md、connector-v2/sink/Console.md 、connector-v2/sink/Jdbc.md。Tks！

my pr：#6563

Please assign me connector-v2/formats/* , except for those already done. Thanks

Please assign me connector-v2/formats/* , except for those already done. Thanks

I also did this part, in the pr above.:< just mentioned today，I think we need to discuss it (:

Please assign me connector-v2/formats/* , except for those already done. Thanks

@xxzuo I also did this part, in the pr above :< just mentioned today. I think we need to discuss it.:)

Please assign me connector-v2/formats/* , except for those already done. Thanks

@xxzuo I also did this part, in the pr above :< just mentioned today. I think we need to discuss it.:)

Thank you for your updates and reminders. I will provide some suggestions for this PR.

Sorry, I didn't see this issue before submitting the PR #6656, I have already translated these documents.

Please assign me the connector-v2/Config-Encryption-Decryption.md,  connector-v2/Error-Quick-Reference-Manual.md, Thx.

Please assign me the remains of seatunnel-engine/*

give up, conflict with zuo

Please assign me the remains of seatunnel-engine/*

give up, conflict with zuo

@xxzuo 不讲武德

Please assign me the remains of seatunnel-engine/*

give up, conflict with zuo

@xxzuo 不讲武德

Sorry, I didn't see this issue before submitting the PR .  Orz

please assign connector-v2/sink/Pulsar.md  and  connector-v2/sink/Hbase.md  and connector-v2/sink/Clickhouse.md give me ,thanks

please assign me the connector-v2/sink/Doris.md，Thx.

Please assign it to me :
connector-v2/sink/DingTalk.md
connector-v2/sink/IoTDB.md
connector-v2/sink/LocalFile.md
connector-v2/sink/Redis.md
connector-v2/sink/MongoDB.md
connector-v2/sink/RocketMQ.md
connector-v2/sink/PostgreSql.md
connector-v2/sink/DB2.md
connector-v2/sink/SqlServer.md
connector-v2/sink/Iceberg.md
connector-v2/sink/Enterprise-WeChat.md
connector-v2/sink/FtpFile.md
thx!

Please assign it to me :
connector-v2/sink/Rabbitmq.md
connector-v2/sink/StarRocks.md
connector-v2/sink/Phoenix.md
connector-v2/sink/ClickhouseFile.md
connector-v2/sink/Maxcompute.md
thx!

Please assign it to me :
start-v2/docker/docker.md
Thanks !

Please assign it to me :
connector-v2/Error-Quick-Reference-Manual.md
Thanks !

Please assign "connector-v2/sink/Assert.md" to me.
Thanks!

Please assign "connector-v2/sink/SftpFile.md" to me.
Thanks very much!


Updating Android embedding dependencies causes build failure

Running the steps in https://github.com/flutter/engine/tree/master/shell/platform/android/embedding_bundle even with no new dependencies causes the android engine build to fail with:
../../flutter/shell/platform/android/io/flutter/app/FlutterFragmentActivity.java:35: error: cannot access ActivityCompat
public class FlutterFragmentActivity extends FragmentActivity
       ^
  class file for androidx.core.app.ActivityCompat not found

cc @blasten

After working with @blasten, this seems to be a local issue with my setup. Closing.


ClassCastException in Executable model

I am trying to prepare a reproducing case for this. As it's a complex case and the java classes of the model being evaluated are runtime-generated by byte-buddy, it's not easy...
When loading an Excel decision table with executable model (or the equivalent generated DRL from the Excel decision table), we are getting this exception:
Caused by: java.lang.ClassCastException: class sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to class java.lang.Class (sun.reflect.generics.reflectiveObjects.TypeVariableImpl and java.lang.Class are in module java.base of loader 'bootstrap')
	at org.drools.model.codegen.execmodel.generator.drlxparse.SpecialComparisonCase.typeNeedsCast(SpecialComparisonCase.java:71)
	at org.drools.model.codegen.execmodel.generator.drlxparse.SpecialComparisonCase.specialComparisonFactory(SpecialComparisonCase.java:56)
	at org.drools.model.codegen.execmodel.generator.drlxparse.ConstraintParser.handleSpecialComparisonCases(ConstraintParser.java:900)
	at org.drools.model.codegen.execmodel.generator.drlxparse.ConstraintParser.parseBinaryExpr(ConstraintParser.java:712)
	at org.drools.model.codegen.execmodel.generator.drlxparse.ConstraintParser.compileToJavaRecursive(ConstraintParser.java:317)
	at org.drools.model.codegen.execmodel.generator.drlxparse.ConstraintParser.compileStart(ConstraintParser.java:269)
	at org.drools.model.codegen.execmodel.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:164)
	at org.drools.model.codegen.execmodel.generator.visitor.pattern.ClassPatternDSL.findAllConstraint(ClassPatternDSL.java:188)
	at org.drools.model.codegen.execmodel.generator.visitor.pattern.PatternDSL.buildPattern(PatternDSL.java:62)
	at org.drools.model.codegen.execmodel.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:132)
	at org.drools.drl.ast.descr.PatternDescr.accept(PatternDescr.java:278)
	at org.drools.model.codegen.execmodel.generator.visitor.AndVisitor.visit(AndVisitor.java:52)
	at org.drools.model.codegen.execmodel.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:70)
	at org.drools.model.codegen.execmodel.generator.ModelGenerator.processRule(ModelGenerator.java:204)
	at org.drools.model.codegen.execmodel.generator.ModelGenerator.processRuleDescr(ModelGenerator.java:185)
	at org.drools.model.codegen.execmodel.generator.ModelGenerator.lambda$processRules$0(ModelGenerator.java:158)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
	at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)

I will update this issue with more details when I can reproduce isolated... but decided to report early as it may be useful already:
here
    private static Optional<Class<?>> typeNeedsCast(Type t) {
        boolean needCast = isObject((Class<?>)t) || isMap((Class<?>) t) || isList((Class<?>) t);
        if (needCast) {
            return of((Class<?>) t);
        } else {
            return Optional.empty();
        }
    }

and here
    static SpecialComparisonCase specialComparisonFactory(TypedExpression left, TypedExpression right) {
        if (isNumber(left) && !isObject(right.getRawClass()) || isNumber(right) && !isObject(left.getRawClass())) { // Don't coerce Object yet. EvaluationUtil will handle it dynamically later
            Optional<Class<?>> leftCast = typeNeedsCast(left.getType());
            Optional<Class<?>> rightCast = typeNeedsCast(right.getType());
            if (leftCast.isPresent() || rightCast.isPresent()) {
                return new ComparisonWithCast(true, left, right, of(Number.class), of(Number.class));
            } else {
                return new NumberComparisonWithoutCast(left, right);
            }
        }
        if (!isComparable(left.getRawClass()) && !isComparable(right.getRawClass())){
            return new ComparisonWithCast(left, right, of(Comparable.class), of(Comparable.class));
        }
        return new PlainEvaluation(left, right);
    }

it is assumed any TypedExpression refers to a Type that is a Class.

I (sort of) see what you mean and we probably cannot give for granted that the Type is always a Class in that point, but at the moment I don't understand under which conditions it could be something else, and I really need a reproducer of this problem since I don't want to just develop a blind fix. Can you please just paste here the drl of a sample rule in your knowledge base that is causing this issue so I could try to create the isolated reproducer on my own?

I understand not wanting to fix blindly unless the scenario is clear.
The DRL is this:
package com.mycompany.myproject.engine.rules.model;
//generated from Decision Table
import com.mycompany.myproject.engine.rules.model.*;
global com.mycompany.myproject.engine.rules.model.ServerCodeRuntimeService serverCode;
dialect "mvel"
// rule values at B13, header at B8
rule "Tank Rules-SmartBIN_13"
	salience 65535
	when
		$asset: Sbtanknew_1_0_6($asset.devices.tank_device.properties.tanklevel_status != "Nearing Empty", $asset.devices.tank_device.readings.tank_level < $asset.properties.empty_fill_level_threshold)
	then
		$asset.getDevices().getTank_device().getProperties().setTanklevel_status("Nearing Empty");
		$asset.getDevices().getTank_device().getProperties().setTanklevel_color("Red");
		$asset.getProperties().setTank_level_status("CRITICAL");
		AlertMessage message = new AlertMessage("Nearing Empty");
		message.withParam("value", $asset.devices.tank_device.readings.tank_level);
		message.withParam("alias", "sb_device_tank_level");
		message.withParam("field", "Tank Level");
		message.withParam("is_required", "Required");
		insert(message);
end

if I drop $asset.devices.tank_device.readings.tank_level < $asset.properties.empty_fill_level_threshold, the above error goes away and a different one appears, but this one I need to investigate further. It also seems related to the fact that a generic class is involved. (I understand $asset inside the condition is redundant).
the model classes (eg:Sbtanknew_1_0_6) are derived from base classes and are runtime generated with byte-buddy, overriding several generic parameters of the parent class. I think this is where the issue comes from, and why it's not easy to isolate. I will try.

I have the feeling this could be related: https://issues.redhat.com/browse/DROOLS-7197, which I reported long time ago and was assumed to become a known issue partially documented in https://docs.drools.org/latest/drools-docs/drools/migration-guide/index.html

if I drop $asset.devices.tank_device.readings.tank_level < $asset.properties.empty_fill_level_threshold, the above error goes away and a different one appears, but this one I need to investigate further. It also seems related to the fact that a generic class is involved. (I understand $asset inside the condition is redundant).

Is there any reason why you're keeping that $asset inside the condition? Does it change anything if you remove it (I don't expect so, but just in case).

the model classes (eg:Sbtanknew_1_0_6) are derived from base classes and are runtime generated with byte-buddy, overriding several generic parameters of the parent class. I think this is where the issue comes from, and why it's not easy to isolate. I will try.

If the executable model generator can access the runtime classes generated by byte-buddy and introspect them during the code generation phase I believe that there shouldn't be any problem. My wild guess is that the executable model generator is introspecting the original classes before byte-buddy instrumentation and if so of course that's wrong and the root cause of the problem. Another (in my opinion more remote) possibility is that byte-buddy is rewriting the bytecode of the domain model classes in a way that for some reason prevents the introspection necessary for the executable model generation, but if so we would also need a reproducer for that.

Thanks for answering!

Is there any reason why you're keeping that $asset inside the condition? Does it change anything if you remove it (I don't expect so, but just in case).

I'm keeping because the original DRL had it and I wanted to reproduce exactly - but no, it doesn't change anything. I mentioned in:

(I understand $asset inside the condition is redundant).

If the executable model generator can access the runtime classes generated by byte-buddy and introspect them during the code generation phase I believe that there shouldn't be any problem.

I believe so too. I use the correct strategy in byte-buddy (ClassLoadingStrategy.Default.CHILD_FIRST_PERSISTENT) and expose the right class-loader to drools... so everything is there for drools to access.
update
I just reproduced it, you can find the failing version here: https://github.com/flozano/drools-issues/blob/main/src/test/java/drools/issues/DynamicClassTest.java
The changes to reproduce:
After properly subclassing in byte-buddy with the generic type descriptor instead of the raw Vehicle class,
and using the property getter defined in the parent item (motor instead of engine), I expected to find same issue as in #5932 (https://issues.redhat.com/browse/DROOLS-7197), but I didn't, I reproduced this.

I will try to give a look at that reproducer asap, but what I don't understand is why it is not possible to create the same reproducer in a more isolated why and without byte-buddy. I mean once you have done the byte-buddy instrumentation those generated classes should be indistinguishable from classes generated by a normal compilation. In essence what I'm suggesting is that it should be possible to also reproduce the same problem with a plain Java domain model that incorporates in its source the changes made at bytecode level by byte-buddy. Am I making sense? Do you think it would be possible to create such a reproducer?

I agree with you that it should be possible, but if you look at what my byte-buddy does, it should be the same.
Base
public abstract class Vehicle<TEngine extends Engine> {

public abstract class Engine {
// ...

"Diesel" model, 'normal' java compilation-generated classes
public class DieselCar extends Vehicle<DieselEngine> {
// ...
	public DieselEngine getEngine() {
		return engine;
	}
// ...

public class DieselEngine extends Engine {

"Gasoline" model, byte-buddy generated classes
			engineClass = new ByteBuddy()
					.subclass(Engine.class).name("drools.issues.model.vehicles.GasolineEngine") //
					.method(ElementMatchers.named("isZeroEmissions")) //
					.intercept(FixedValue.value(false)) //
					.defineProperty("highOctane", boolean.class) //
					.defineProperty("maxTorque", int.class) //
					.defineProperty("serialNumber", long.class) //
					.make().load(classLoader, ClassLoadingStrategy.Default.CHILD_FIRST_PERSISTENT).getLoaded();

				TypeDescription.Generic generic = TypeDescription.Generic.Builder.parameterizedType(Vehicle.class, engineClass).build();
				vehicleClass = (Class<? extends Vehicle>) new ByteBuddy() //
						// .subclass(Vehicle.class) //
						.subclass(generic)
						.name("drools.issues.model.vehicles.GasolineVehicle") //
						.defineField("engine", engineClass, Visibility.PRIVATE) //
						.defineConstructor(Visibility.PUBLIC) //
						.withParameters(String.class, String.class, engineClass) //
						.intercept(MethodCall.invoke(Vehicle.class.getDeclaredConstructor(String.class, String.class))
								.withArgument(0, 1) //
								.andThen(FieldAccessor.ofField("engine").setsArgumentAt(2)) //
						) //
						.defineMethod("getEngine", engineClass, Visibility.PUBLIC) //
						.intercept(FieldAccessor.ofField("engine")) //
						.defineProperty("frameMaxTorque", long.class) //
						.make().load(classLoader, ClassLoadingStrategy.Default.CHILD_FIRST_PERSISTENT).getLoaded();

the byte-buddy generated class is legal JVM code that can be executed. I can dispatch invocations to parent class (Engine) methods, subclass (DieselEngine) methods... as per the JVM this should be legal code, I believe.

from byte-buddy, it very explicitly supports subclasses of generic parents:
    /**
     *

     * Creates a new builder for subclassing the provided type. If the provided type is an interface, a new class implementing
     * this interface type is created.
     *

     *

     * When extending a class, Byte Buddy imitates all visible constructors of the subclassed type and sets them to be {@code public}.
     * Any constructor is implemented to only invoke its super type constructor of equal signature. Another behavior can be specified by
     * supplying an explicit {@link ConstructorStrategy} by {@link ByteBuddy#subclass(TypeDefinition, ConstructorStrategy)}.
     *

     *

     * Note: This methods implements the supplied types as is, i.e. any {@link TypeDescription} values are implemented
     * as raw types if they declare type variables.
     *

     *

     * Note: Byte Buddy does not cache previous subclasses but will attempt the generation of a new subclass. For caching
     * types, a external cache or {@link TypeCache} should be used.
     *

     *
     * @param superType The super class or interface type to extend. The type must be a raw type or parameterized type. All type
     *                  variables that are referenced by the generic type must be declared by the generated subclass before creating
     *                  the type.
     * @return A type builder for creating a new class extending the provided class or interface.
     */
    public DynamicType.Builder<?> subclass(TypeDefinition superType) {
        return subclass(superType, ConstructorStrategy.Default.IMITATE_SUPER_CLASS_OPENING);
    }

superType The super class or interface type to extend. The type must be a raw type or parameterized type. All type variables that are referenced by the generic type must be declared by the generated subclass before creating the type.

(just pushed a small fix for another unrelated method which was declared package-private but public in the byte-buddy. it has no effect on this specific test and case).

Fixed by https://github.com/apache/incubator-kie-drools/commit/785ef86a9a774db20f8610a1b73f4d5cdb635eb4

Thanks a lot! I will verify once the SNAPSHOT is built.
The same test incidentally raised #5943, will check that one too.


Removing promises, adding more functionalities

Updated Readme
Added getCounty() function
Added ability to filter by part of the name(county, constituency, ward)
Filter wards by county code
Removed promises
code formatting and clean up

@michaelnjuguna see this

@manuelgeek Hey there currently we are not on yarn and we do not support import statements we only support require, I am working on supporting import statements. Your code on index.js has errors you could work on them. Anyway I am really grateful for your effort contact me on LinkedIn and we will talk about my plans.


Analyzer doesn't catch conflict between static member and constructor names.

Example:
class C {
  C.foo();
  static int foo() => 42;
}

This class should have an error because you're not allowed to have a named constructors with the same identifier as the basename of a static member.

\item The identifier of a named constructor cannot be
 the same as the name of a static member declared in the same class
 (\ref{classMemberConflicts}).

(@eernstg, I think it should say "basename" instead of "name", otherwise you could have a C.foo constructor and a static foo= setter, and nobody wants that!)
The analyzer does not give any warning or error.
The front-end provides:
badclass.dart:2:3: Error: Conflicts with member 'foo'.
  C.foo();
  ^
badclass.dart:3:14: Error: Conflicts with constructor 'C.foo'.
  static int foo() => 42;
             ^

I do see an error from the analyzer in dart-pad, which version of the analyzer did you use when there was no error?

I think it should say "basename" instead of "name", otherwise you could
have a C.foo constructor and a static foo= setter, and nobody wants that!

Right, we do have that in the normative text, 'Class Member Conflicts', but the commentary that you mention should be corrected. Cf. https://github.com/dart-lang/language/pull/1676.

I can't reproduce this either.  Closing, please re-open if I've missed something.


Peek view is empty although test output shows errors

When running a test that fails, peek view will be empty. The output has the information though. It just doesn't end up in peek view.
Screenshots

Environment

macOS
VSCode 1.86.1
Vitest 1.2.2 darwin-arm64 node-v20.11.0
Vitest plugin 0.2.43

Vitest plugin Config
{
  "vitest.enable": true,
  "vitest.commandLine": "yarn vitest",
  "vitest.exclude": [
    "**/node_modules/**",
    "**/dist/**",
    "**/e2e/**",
    "**/.{nuxt,git,cache,output,temp}/**"
  ],
  "vitest.showFailMessages": true,
}

I am experiencing this as well

Extension was not updated to properly work with vitest >= 1.0.0. Fixed by https://github.com/vitest-dev/vscode/pull/213.


How to do anamoly detection for the specific host

How to string value in filter
I can filter only value fields / boolean fields from indices. i am unable to choose the string filter from index.
This is very much important for the case of anomaly detection for an host.
Is it possible to do the anomaly detection for the specific host.ip ?
Opendistro seems good to use and have more features related to siem  , kindly assist to get the above use case in filter.
I have  pasted the code used for my network infrastructure,
{
"bool": {
"filter": [
{
"range": {
"system.network.out.bytes ": {
"from": 500,
"to": null,
"include_lower": false,
"include_upper": true,
"boost": 1
}
}
},
{
"range": {
"system.process.cpu.total.value": {
"from": 600,
"to": null,
"include_lower": false,
"include_upper": true,
"boost": 1
}
}
},
{
"range": {
"system.process.cgroup.memory.mem.usage.bytes": {
"from": 500,
"to": null,
"include_lower": false,
"include_upper": true,
"boost": 1
}
}
},
{
"range": {
"system.process.cpu.total.pct": {
"from": 0.08,
"to": null,
"include_lower": false,
"include_upper": true,
"boost": 1
}
}
},
{
"term": {
"system.cpu.system.pct": {
"value": 9.81,
"boost": 1
}
}
}
],
"adjust_pure_negative": true,
"boost": 1
}
}
For this usecase , I like to add string value of  specific hostname / agent.name.
By the way I will filter out the machine which is really affected, otherwise it is simply a measurement.

Hi Ganesh, I'd recommend asking this question in the repo for the Anomaly Detection plugin itself, over here: https://github.com/opendistro-for-elasticsearch/anomaly-detection/issues


makefile fails to execute a.out file

I am new to TensorFlow. At the moment, I am learning TensorFlow for C code on my Macbook. I follow the instructions by Google and manage to run the 'hello world' in C.
I set the paths on my bash_profile as follows:
export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/tensorflow/lib
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/tensorflow/lib.
My makefile is as follow.
tensorlib = -L/usr/local/tensorflow-1.15.0/lib/
tensorlnk = -I/usr/local/tensorflow-1.15.0/include/
task:
mpicc -c hello.c $(tensorlnk)
mpicc    hello.o $(tensorlib)
run:
mpirun -np 4 ./a.out
I can compile the program and generate the executable, a.out. In my terminal, I can run the program using 'mpirun -np 4 ./a.out' to execute. But the command 'make run' fails. Here is the error message
dyld: Library not loaded: @rpath/libtensorflow.1.dylib Referenced from: /Users/usr/Documents/code/dev/TensorFlow/c/./a.out Reason: image not found
Could anyone tell me what the problem is?
Many thanks in advance.

I am running Catalina 10.15.3. Tensorflow runs on my Mac. But I am unable to run it using 'make run'.

This question is better asked on StackOverflow since it is not a bug or feature request. There is also a larger community that reads questions there.
Thanks!


Forgot PDB in the source code

https://github.com/furious-luke/django-xauth/blob/d4ff8ca4ee0445dfcf7e2d9c13f919a6be517816/xauth/views.py#L70

Lol. Sorry!


Performance Example Application: [ 0] INTERNAL - No valid requests recorded within time interval. Please use a larger time window.

hi all, I am running the perf_client example applications and getting the below errors:
Server: 4xT4 GPUs
Docker image used for the server:  nvcr.io/nvidia/tensorrtserver:19.02-py3
Command used to run the client: nvidia-docker run -it --rm --net=host --shm-size=1g --ulimit memlock=-1 --ulimit stack=67108864 tensorrtserver_clients
Example 1:
root@R7425-T4:/workspace# /opt/tensorrtserver/bin/perf_client -m resnet50_netdef -p3000 -t4 -v
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 3000 msec

Request concurrency: 4
[ 0] INTERNAL - No valid requests recorded within time interval. Please use a larger time window.
Thread [0] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'
Thread [1] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'
Thread [2] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'
Thread [3] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'

Example 2:
root@R7425-T4:/workspace# /opt/tensorrtserver/bin/perf_client -m resnet50_netdef -d -c8 -l200 -p5000 -b8
*** Measurement Settings ***
  Batch size: 8
  Measurement window: 5000 msec
  Latency limit: 200 msec
  Concurrency limit: 8 concurrent requests

Request concurrency: 1
[ 0] INTERNAL - No valid requests recorded within time interval. Please use a larger time window.
Thread [0] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'

Example 3:
root@R7425-T4:/workspace# /opt/tensorrtserver/bin/perf_client -m resnet50_netdef -p3000 -d -l50 -c 3
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 3000 msec
  Latency limit: 50 msec
  Concurrency limit: 3 concurrent requests

Request concurrency: 1
[ 0] INTERNAL - No valid requests recorded within time interval. Please use a larger time window.
Thread [0] had error: [inference:0 0] INVALID_ARG - unable to parse request for model 'resnet50_netdef'

On another hand, the TensorRT Inference Server is throwing these messages:
[libprotobuf ERROR external/protobuf_archive/src/google/protobuf/text_format.cc:307] Error parsing text-format nvidia.inferenceserver.InferRequestHeader: 1:79: Message type "nvidia.inferenceserver.InferRequestHeader" has no field named "id".

What version of the inference server are you using. It appears that you are likely using a version of the perf_client that is not compatible with the server. Tycially, because we are still in beta, you must use a perf_client with the same version as the server.

@deadeyegoodwin I am using the tag nvcr.io/nvidia/tensorrtserver:19.02-py3, where I can set up the perf_client version that matches the server version?

Where did you get the perf_client executable?

I downloaded the TRTIS master branch to my server and built the tensorrtserver_clients docker image from there:
docker build -t tensorrtserver_clients --target trtserver_build --build-arg "BUILD_CLIENTS_ONLY=1" .

The master branch is far ahead of 19.02. You should use the r19.02 and build the clients on that branch (since that matches your server).
The documentation has recently been made more explicitly about using the correct branch. You can see in the master branch docs: https://docs.nvidia.com/deeplearning/sdk/tensorrt-inference-server-master-branch-guide/docs/client.html#building-the-client-libraries-and-examples

Issued solved!.  @deadeyegoodwin thanks for updating the doc


add build file for robot pattern from messages

Integrate https://github.com/Azoyalabs/RobotCodeGen

Initial integration done with<PHONE_NUMBER>1f946c9b06fcc4d082d573d619c740


Consider generating value classes with AutoValue.

We could probably generate a significant number of the classes under core/java/com/google/instrumentation/ using AutoValue.  It would reduce boilerplate, but it might complicate the build.

I'm pretty happy with auto-value, it also has a memoized feature which
could come in handy

#132 applied AutoValue to two classes, but I'm leaving this open until we convert the rest of the value classes.

We've already switched a lot of the classes and this become a common thing. No need to keep this issue around.


Merge pull request #153 from dmh23/develop_version_3

Develop version 3

I tried to import log but stuck at importing, do you have any solution for that?

Apologies for the delay, please try today's new release 3.2.4 which loads logs correctly for the newest "Vivalas" tracks


Support for custom target files

Fixes #177
Changes:

Support --target=target-name.json to be passed to cargo chef, by fixing the target location that is used during dummy cleanup in this case.

The PR does not yet contain a test for this functionality. I was not entirely sure where to start with writing such a test case if desired.
Since it is an unstable nightly feature, do we want a test or not?

This is fine as is, happy to merge it.

This is fine as is, happy to merge it.

Great! Thank you!
I have pushed two new commits that should make rustfmt and clippy happy with the PR as well 😊

There is one more lint error, but I can take care of it. Thanks for the PR!


Add "opt" passes.

Fixes #11!

Should be on PyPI in a few minutes.

Thanks, works well! One less CI job installing OSS CAD Suite. :)

Glad it helps. I'm probably going to evaluate at least the opt benefits in more detail when working on resurrecting cxxsim this quarter.


Add mechanism for listening to LISTEN messages without having to execute anything

Currently, Notification messages only get read from the input buffer after having sent a message to the server first.
One use-case for listening for messages is to have a dedicated thread and/or connection that subscribes to channel(s) and then dispatches based on the messages that are received. This is a primary reason why the impossibl pg jdbc driver exists: unlike the "official" jdbc driver, this one does not require busy-looping a SELECT 1 query to actually receive the notify messages.
I played around with a new method on Connection called listenLoop that would block on just reading from the server, without having to first issue a query:
    public Future<?> listenLoop () {
        flush();
        try (TryLock ignored = lock.get()) {
            return Agent.soloExecutor.submit(() -> {
                    while (!Thread.currentThread().isInterrupted()) {
                        try {
                            final IServerMessage msg = readMessage(false);
                            if (Debug.isON) {
                                Debug.debug(" -> %s", msg);
                            }
                            handleMessage(msg, null);
                        } catch (PGError e) {
                            Debug.debug(" IO issue %s", e);
                            if (isClosed()) { break; }
                        } catch (Throwable caught) {
                            break;
                        }
                    }
                    return true;
                });
        }
    }

But there are few issues with this:

It doesn't allow thread interruption for blocking IO, instead having to wait for socket timeout before the interruption would be seen
The details of connection-sharing across threads is murky at best.

What do you think about this?

Maybe, it could be even simpler with java.util.TimerTask. In both cases, the idea is simple: there is Class that accepts a pool/connection, and spawns a regular job that performs an empty select of that connection/pool. There is an API/method to stop the object.

As far as I understand, between two scheduled calls, a connection or a pool will be free (not used by any thread) and thus can be reused in other threads.

A very draft:
package org.pg.pubsub;

import org.pg.Connection;
import org.pg.Pool;

import java.util.Timer;
import java.util.TimerTask;

public class Pub implements AutoCloseable {
    private final TimerTask task;
    private final Timer timer;

    private Pub (final TimerTask task, final Timer timer) {
        this.task = task;
        this.timer = timer;
    }

    private Pub start () {
        timer.schedule(task, 5000);
        return this;
    }

    public static Pub create(final Pool pool) {
        final Pub pub = new Pub(new TimerTask() {
            @Override
            public void run() {
                final Connection conn = pool.borrowConnection();
                conn.query("select");
                pool.returnConnection(conn);
            }
        }, new Timer());
        return pub.start();
    }

    @Override
    public void close() {
        this.task.cancel();
    }
}

What do you think?

My idea is to have a "hub" object with .subscribe, .unsubscribe, .send methods and similar. One should pass a pool, a minimum config (like what to listen) and then use it for cross-communication.

It has some difficulties though. For example, since connections are constantly re-created, that object should automatically subscribe them on a given list of topics.
In general, I have an outline idea but will deliver it a bit later. At the moment, I'm working on a prepared statement case (see the better-ps-cache branch)

One other thought here. What about providing a low-level polling method so that user's could decide how/when to set up notification polling. Something that would be lighter weight than the typical execute methods:
    public boolean pollNotification() {
        try (TryLock ignored = lock.get()) {
            sendSync();
            sendFlush();
            if (IOTool.available(inStream) < 1) {
                return false;
            }
            final IServerMessage msg = readMessage(false);
            handleMessage(msg, null);
            return true;
        }
    }

This would return true when a notification was dealt with, false otherwise.
As an example use-case from a user's perspective, then, you might set up a thread with either a dedicated connection, or one that checks out from a pool, and then runs this continuously until it returns false (in case of many notifications), then sleeps for some amount of time when false.

That method looks interesting, let me check out. I'll try to simulate this in integration tests and post my updates.
In general, I'm thinkig about building a message queue based on PG2. It should be like Kafka (topics + offets) or SNS/SQL (queues). The problem with listen/notify is, a client won't receive messages until he or she subsribes to a channel. Thus, if someone produced messages 1, 2, 3, and you've subscribed afther the 2, you'll get only 3, and 1 and 2 will be lost. This is a real issue with listen/notify.


Semi-automated emacs package updates

What is the tool you are using to generate these files?
Would it be possible to add a header in generated files with a bit of information regarding the tool?

@lewo Did you try to read the headers of said files?

@oxij ok, I got it.
Thanks.


Implement stepsize cap

We need to implement the possibility for users to provide a max_stepsize argument to the stepsize object like we do in FESTIM1

Will work on this


Proxy not forwarding POST requests to primary

Setup
NodeJS+Express backend with 3 fly machines.
Standard configuration of LiteFS described here: https://fly.io/docs/litefs/getting-started-fly/
fly.toml
[http_service]
internal_port = 8081
force_https = true
auto_stop_machines = false
auto_start_machines = true
min_machines_running = 0

[[services]]
internal_port = 8080
protocol = "tcp"

[[services.ports]]
port = 80
handlers = ["http"]
force_https = true

[[services.ports]]
port = 443
handlers = ["tls", "http"]

[services.concurrency]
type = "requests"
hard_limit = 200
soft_limit = 150

[[services.tcp_checks]]
interval = "15s"
timeout = "2s"
grace_period = "10s"
restart_limit = 6

# https://community.fly.io/t/edge-headers/9278
[services.ports.http_options.response.headers]
Access-Control-Allow-Origin = "*"
Access-Control-Allow-Methods = "*"
Access-Control-Allow-Headers = "*"

litefs.yml
# The fuse section describes settings for the FUSE file system. This file system
# is used as a thin layer between the SQLite client in your application and the
# storage on disk. It intercepts disk writes to determine transaction boundaries
# so that those transactions can be saved and shipped to replicas.
fuse:
    dir: "/litefs"

# The data section describes settings for the internal LiteFS storage. We'll
# mount a volume to the data directory so it can be persisted across restarts.
# However, this data should not be accessed directly by the user application.
data:
    dir: "/var/lib/litefs"

# This flag ensure that LiteFS continues to run if there is an issue on starup.
# It makes it easy to ssh in and debug any issues you might be having rather
# than continually restarting on initialization failure.
exit-on-error: false

# This section defines settings for the option HTTP proxy.
# This proxy can handle primary forwarding & replica consistency
# for applications that use a single SQLite database.
proxy:
    addr: ":8080"
    target: "localhost:8081"
    db: "db"
    passthrough:
        - "*.ico"
        - "*.png"

# This section defines a list of commands to run after LiteFS has connected
# and sync'd with the cluster. You can run multiple commands but LiteFS expects
# the last command to be long-running (e.g. an application server). When the
# last command exits, LiteFS is shut down.
exec:
    # Only run migrations on candidate nodes.
    - cmd: "npm run migrate"
      if-candidate: true

    # Then run the application server on all nodes.
    - cmd: "npm run start"

lease:
  type: "consul"

  # Specifies if this node can become primary. The expression below evaluates
  # to true on nodes that are run in the primary region. Nodes in other regions
  # act as non-candidate, read-only replicas.
  candidate: ${FLY_REGION == PRIMARY_REGION}

  # If true, then the node will automatically become primary after it has
  # connected with the cluster and sync'd up. This makes it easier to run
  # migrations on start up.
  promote: true

  # The API URL that other nodes will use to connect to this node.
  advertise-url: "http://${FLY_ALLOC_ID}.vm.${FLY_APP_NAME}.internal:20202"

  consul:
    # The URL of the Consul cluster.
    url: "${FLY_CONSUL_URL}"

    # A unique key shared by all nodes in the LiteFS cluster.
    # Change this if you are running multiple clusters in a single app!
    key: "${FLY_APP_NAME}/primary"

Reproduction
Log lines below show the issue, and indicate that the POST request was successful after a few tries. ** 2023-08-13T18:06:16Z app[6e82d392c7d5e8] ** below is to indicate the replica change (OR successful write forwarding), which resulted in a success.
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]level=INFO msg="fuse: write(): wal error: read only replica"
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]Error while adding story likes SqliteError: disk I/O error}
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]SqliteError: disk I/O error
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Object.run (/usr/src/app/dist/db.js:7:28)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Object.create (/usr/src/app/dist/services/storyLikes.js:54:33)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at /usr/src/app/dist/routes/storyLikes.js:30:43
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/route.js:144:13)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Route.dispatch (/usr/src/app/node_modules/express/lib/router/route.js:114:3)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at /usr/src/app/node_modules/express/lib/router/index.js:284:15
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:346:12)
2023-08-13T18:06:10Z app[32874699b19e48] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/index.js:280:10)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]level=INFO msg="fuse: write(): wal error: read only replica"
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]Error while adding story likes SqliteError: disk I/O error}
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]SqliteError: disk I/O error
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Object.run (/usr/src/app/dist/db.js:7:28)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Object.create (/usr/src/app/dist/services/storyLikes.js:54:33)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at /usr/src/app/dist/routes/storyLikes.js:30:43
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/route.js:144:13)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Route.dispatch (/usr/src/app/node_modules/express/lib/router/route.js:114:3)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at /usr/src/app/node_modules/express/lib/router/index.js:284:15
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:346:12)
2023-08-13T18:06:12Z app[e784e046fd6718] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/index.js:280:10)
**2023-08-13T18:06:13Z app[32874699b19e48]** sjc [info]level=INFO msg="fuse: write(): wal error: read only replica"
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]Error while adding story likes SqliteError: disk I/O error}
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]SqliteError: disk I/O error
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Object.run (/usr/src/app/dist/db.js:7:28)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Object.create (/usr/src/app/dist/services/storyLikes.js:54:33)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at /usr/src/app/dist/routes/storyLikes.js:30:43
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/route.js:144:13)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Route.dispatch (/usr/src/app/node_modules/express/lib/router/route.js:114:3)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at /usr/src/app/node_modules/express/lib/router/index.js:284:15
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:346:12)
2023-08-13T18:06:13Z app[32874699b19e48] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/index.js:280:10)
**2023-08-13T18:06:16Z app[6e82d392c7d5e8]** sjc [info]{"level":30,"time":1691949976874,"pid":335,"hostname":"6e82d392c7d5e8","msg":"2a02:26f7:c344:8014:0:10da:1728:37ec, 2a09:8280:1::24:3997 Successfully liked story 853c1402-fe8a-40a4-86ad-c30dec36ad12}"}

P.S. Was not sure what other details I should be submitting here. Please let me know if there is more information I can/need to share. Thanks in advance.

@harshav17 Thanks for submitting the issue. Do you know what version of LiteFS is running? It should show when the machine starts up. We made a fix recently (#373) that changes how POSTs are handled when a primary is not known by the replica.

Thanks for responding.
0.5.2. Should I upgrade to 0.5.4 and see if the POST calls start returning 503 error codes?

@harshav17 Sorry, I missed your reply. Yes, it's worth a try with v0.5.4. Let me know if you still see an issue.

Upgrade to 0.5.4 did not help, I still see the issue.
2023-08-21T05:17:42Z app[e784e046fd6718] sjc [info]{"level":30,"time":1692595062389,"pid":335,"hostname":"e784e046fd6718","msg":"Successfully got 28 stories"}
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]level=INFO msg="fuse: write(): wal error: read only replica"
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]Error while adding story likes SqliteError: disk I/O error}
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]SqliteError: disk I/O error
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Object.run (/usr/src/app/dist/db.js:7:28)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Object.create (/usr/src/app/dist/models/storylikes.js:9:33)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Object.create (/usr/src/app/dist/services/storylikes.js:54:33)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at /usr/src/app/dist/routes/storylikes.js:30:43
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at next (/usr/src/app/node_modules/express/lib/router/route.js:144:13)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Route.dispatch (/usr/src/app/node_modules/express/lib/router/route.js:114:3)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at /usr/src/app/node_modules/express/lib/router/index.js:284:15
2023-08-21T05:17:51Z app[e784e046fd6718] sjc [info]    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:346:12)
2023-08-21T05:18:19Z app[6e82d392c7d5e8] sjc [info]{"level":30,"time":1692595099276,"pid":336,"hostname":"6e82d392c7d5e8","msg":"Successfully got The Enchanted Forest Adventure story"}
2023-08-21T05:18:23Z app[6e82d392c7d5e8] sjc [info]{"level":30,"time":1692595103109,"pid":336,"hostname":"6e82d392c7d5e8","msg":"2a02:26f7:c344:8013:0:69e1:4c50:8210, 2a09:8280:1::24:3997 Successfully liked story a1205ac8-a7af-4d35-9630-c89b202bca4e}"}

Hi @harshav17
You have two different services that listen on 80/443 defined in your config:

http_service, that forwards to port 8081 (your app)
service, that forwards to port 8080 (LiteFS proxy).

I'm not sure which one takes precedence in fly-proxy in this case. Try to remove http_service part of the config to make sure that all requests are processed by LiteFS Proxy.

yep, that fixed it! Thank you both!

This is it! Wow this took me a solid 16 hours of debugging to find this solution. I couldn't figure out why 50% of my POST requests were failing (being sent to a read only replica) instead of the primary. This solved my issue. Thanks a ton.


Pixi v3.0.0

Current Status
Active Phase: Phase 6
Phase Progress: 0% complete
Phase Progress Notes: N/A
Total Rewrite Progress: 52% complete
Reminders for myself:

DOC has circular dep on Sprite for "cacheAsBitmap"

This needs to be redone, very spread around. Some code in DOC, some in renderer, ...

Should RenderTexture and VideoBaseTexture be moved out of core?
PolyK should be replaced, it has a few bugs.
Remove usages of loader caches from core lib.
Factor common renderer base (between Canvas/WebGL Renderers) to reduce duplication

Proposal
Introduction
Hello all, I decided to write this up to inform the community what I am working on and to gather some feedback. The biggest thing to realize about what follows is that I am working on it right now, and that it is no longer theoretical. Also, keep in mind this has not yet be "blessed" by the rest of the Pixi team so this may not make it in, I am just looking for feedback from the team and the community.
You can watch the work being done in a branch on my fork: https://github.com/englercj/pixi.js/tree/dev-rewrite
If you read this proposal and want to help, fork my branch and submit PRs to the dev-rewrite branch and lets get this done!
That being said, v3.0.0 will be a rewrite of PIXI. I have it split into distinct phases with clear goals to accomplish a clean, modular library that will make it easier for us to maintain and for others to contribute.
Rewrite Phases
Phase 0 - Cleanup/Meta
Status: Completed
Phase 0 is to cleanup the code repository, removing things that shouldn't be in the main repo. For example: examples/, docs/, trim/. Each of those should be separate and maintained on their own. It also converts the project to use gulp, reorganizes the tasks for the project, and generally prepare the project for the coming rewrite.
Phase 1 - Code Modularization
Status: Completed
Related issues: #307
Phase one is to convert the codebase to use browserify, remove dead code, convert yuidoc to jsdoc comments, and cleanup some style inconsistencies. This is perhaps the most time consuming phase because it requires combing through every source file in pixi and changing a lot. This phase will make it much easier to refactor the library and accomplish later phases.
Phase 2 - Component Modularization
Status: Completed
Once the library has been revamped from a code-quality standpoint the next step is to remove circular dependencies and split the core library into multiple discrete modules. Each module will be in a separate folder within the src/ directory of the project, but should be split into separate repos at a later date.
The modules I have in mind are:

core - Core renedering and display (math, DO, DOC, Sprite, SpriteBatch, Graphics, textures, renderers).
spine - Adds spine support.
loader - Adds loaders for the different things pixi supports.
filters - Adds a pack of different filters.
text - Adds text support.
extras - Adds TilingSprite, and MovieClip support (could use a better name).
interaction - Adds user interaction support.

Phase 3 - Decoupling and API Normalization
Status: Completed
At this point the project has been split into multiple "modules" within the repo, but are still interdependent on each other. That is, even though the code is separated you couldn't have a custom build that leaves out pieces because they are too tightly coupled. This phase is to decouple modules from each other and let them be standalone. Core should work fine on its own, and other modules should just extend core and add support. There are also leaky functions and a lot of dependence on global state, that should also be removed in this stage.
This phase also includes modifying strange inconsistencies in the API to unify it a bit. For example, sprites have properties for filters/masks but to set the texture you use a method. Fixing some of these evolution in the code will result in easier integration and maintenance.
Phase 4 - Prefer dependencies and create custom builds
Status: On Hold
Related issues: #1283
Now that modules exist, and are decoupled, we can create custom builds that include only subsets of the pixi functionality that users can tailor to their needs. This phase will also take this opportunity to try and refactor out custom code in favor of more mature modules in the npm ecosystem.
Some modules we can start using (thanks @mattdesl):

point-in-polygon, gl-vec2, point-circle-collision, gl-mat4 for geom package
polyline-normals, bezier, adaptive-bezier-curve, arc-to for 2D graphics
glslify or brfs for managing shader code
mouse-position, scroll-speed, mouse-event-offset, wheel for interaction
img, events, webgl-context, prefix-style, texcoord, gl-shader-errors, etc.

Phase 5 - Rewrite Interaction Manager
Status: Not Started
Related issues: #241, #325, #346, #785, #950, #1096, #1252, #1291
There are a lot of issues related to the interaction manager and how it works, this phase will be a rewrite of this module so clear up some of the issues people have been reporting. Hopefully when this is done we will have a clearer interaction manager along with DOM-like bubbling, and real events (instead of raw callbacks).
Phase 6 - Rewrite Asset Loader
Status: In Progress (0% complete)
Related issues: #312, #387, #776, #1290
The loader has evolved a lot over time, and some of the older components got left behind. The API for it is a little hap-hazard and awkward. This rewrite should address the issues the community has with this module, increase performance, and make it easier to maintain.
There is also still a coupling of the core code to the texture caches used by the loaders. This phase should remove that.
Phase 7 - Rewrite Stage
Status: Completed
Related issues: #1232, #1264, #1285
There is a lot of confusion over what Stage is and why it exists. Many people have asked "why can't I pass any DOC and have it rendered?" This phase will be to implement that functionality and remove the stage from the library.
Phase 8 - Optimization/Cleanup Pass
Status: Not Started
Related issues: #1097, #1238, #1260
There are a couple hot functions that could use an optimization pass. Lots of temporary variables and other things that cause GC churn that need to be fixed. This phase is to clean up those parts and help make pixi as clear and effective as possible.
I also want to cleanup some long standing issues in this phase, that should be pretty simple to solve. Most involve some "messy" code that should be simple to clean up. I will also take this opportunity and go through all the TODO comments in the code, and actually do them.
Phase 9 - Rewrite Examples
Status: In Progress (5% complete)
The examples have a ton of code duplication, and no framework for actually creating them making it tedious if not difficult to add more examples. In the new examples repo there should be a framework for easily creating new examples using a handlebars/assemble/gulp build process. Code can then be shared via browserify.
Completion
After these phases I feel that pixi will be in a good state to be extensible and maintainable by the community. If you have feedback, or questions I'd be happy to try and answer them here. This effort should go towards fixing 20+ issues in the list and make it much easier for other developers to jump into the code and fix issues on their own in the future.

Will using browsefy modules still build a PIXI object that can be used the same way people currently use pixi?

Nothing changes for users that use pixi in the way they use it now, the final built file works the same way. All it does it let other browserify users and node users have easier access, and we get access to npm modules, and the code is much cleaner.

My brain is a little concerned about phase 4 as integrating other modules as it seems like it could add layers to pixi that may not be required. But thats something we can talk about when we ya get to phase 4 :)

Not sure what you mean, this doesn't add code, it removes it. It is removing layers from pixi so that there is less code to maintain and create custom. Instead we use mature modules that are well tested and therefore reduce our complexity and bugs significantly.
I think that this is one of the most important parts of this, because pixi has a lot of bugs because we reinvent the wheel so much.

Will using browsefy modules still build a PIXI object that can be used the same way people currently use pixi?

Nothing changes for users that use pixi in the way they use it now, the final built file works the same way. All it does it let other browserify users and node users have easier access, and we get access to npm modules, and the code is much cleaner.

My brain is a little concerned about phase 4 as integrating other modules as it seems like it could add layers to pixi that may not be required. But thats something we can talk about when we ya get to phase 4 :)

Not sure what you mean, this doesn't add code, it removes it. It is removing layers from pixi so that there is less code to maintain and create custom. Instead we use mature modules that are well tested and therefore reduce our complexity and bugs significantly.
I think that this is one of the most important parts of this, because pixi has a lot of bugs because we reinvent the wheel so much.

Nice nice! I disagree with your last comment though - reinventing the wheel (to a certain degree) is what made pixi what it is and how we manage to get such good performance so far. It also lets us try new ways of doing things which is very important to me.
I know this is down to personal taste, but I'm not really a fan of the tiny little modules that pop up on npm.
That said I will certainly keep an open mind about what your are saying and as we come to that part we can discuss it.
I agree that structurally its evolved and is in need of a tidy. Pixi is very important to me (as it is to you) and I just want to be VERY careful with these big proposed changes.
Cheers!

Nice nice! I disagree with your last comment though - reinventing the wheel (to a certain degree) is what made pixi what it is and how we manage to get such good performance so far. It also lets us try new ways of doing things which is very important to me.
I know this is down to personal taste, but I'm not really a fan of the tiny little modules that pop up on npm.
That said I will certainly keep an open mind about what your are saying and as we come to that part we can discuss it.
I agree that structurally its evolved and is in need of a tidy. Pixi is very important to me (as it is to you) and I just want to be VERY careful with these big proposed changes.
Cheers!

@englercj I kind of disagree with that last comment too, for a different reason. I do not think reinventing the wheel is the reason there are bugs, but it does contribute to them popping up.

@englercj I kind of disagree with that last comment too, for a different reason. I do not think reinventing the wheel is the reason there are bugs, but it does contribute to them popping up.

I think before any of this is even started you should all try and answer a fundamental, yet basic question first: What do you actually want Pixi to be?
Although billed as a 'renderer' I think everyone here can agree it never really was just that, even from the start. It has clearly evolved as a result of how @GoodBoyDigital needed to use it on a day-to-day basis internally in their client work. This is obvious from the way features were added that it grew based on  what could be deemed a 'client led' roadmap. This isn't a bad thing necessarily, but as the popularity of Pixi grew it bought into question why some of those choices were made.
With a project like this I think it's fair to say that its structure is a direct result of the workflow that goes on within the GoodboyDigital team, who are arguably the most important Pixi user of all. If browserify was a core tool they used internally then I have no doubt you'd see Pixi using it already, but it clearly isn't. The moment they start questioning if it should be used is the moment the project will loose momentum and start mothballing.
Pixi development isn't a purely altruistic endeavour. It has to either remain a vital core part of Goodboys day to day workflow, or be so open and well adopted that the wider community can and will carry out all development instead. I believe this is a fine line.
Assuming a rewrite in this manner will suddenly open the flood-gates to developers who wouldn't otherwise have helped is wishful thinking at best. I believe the reality is that there's a very finite number of developers who have the technical ability to help anyway. If Mat were to spend time writing in detail how Pixi works, explaining about the batch process, the shaders and the rest of the internals then I can't help but think this single act could help bring in more developers in than any other actually. But that's an aside (and really could do with happening regardless)
If Pixi is to truly be a pure renderer and nothing else then it needs entirely stripping out and turning into such. From this then perhaps @GoodboyDigital could work Pixi into a new project that adds in all of the extras they actually need for day-to-day work and not even have them as part of the core library (even in module form).
However as Pixi isn't really a renderer at all right now (it's turned into a bit of a swiss army knife!) then maybe this is where the discussion should start off? I think both Mat and Chad (and everyone else!) should agree with a joint definition, which should evolve into a core features list and roadmap, before any code is touched at all.

I think before any of this is even started you should all try and answer a fundamental, yet basic question first: What do you actually want Pixi to be?
Although billed as a 'renderer' I think everyone here can agree it never really was just that, even from the start. It has clearly evolved as a result of how @GoodBoyDigital needed to use it on a day-to-day basis internally in their client work. This is obvious from the way features were added that it grew based on  what could be deemed a 'client led' roadmap. This isn't a bad thing necessarily, but as the popularity of Pixi grew it bought into question why some of those choices were made.
With a project like this I think it's fair to say that its structure is a direct result of the workflow that goes on within the GoodboyDigital team, who are arguably the most important Pixi user of all. If browserify was a core tool they used internally then I have no doubt you'd see Pixi using it already, but it clearly isn't. The moment they start questioning if it should be used is the moment the project will loose momentum and start mothballing.
Pixi development isn't a purely altruistic endeavour. It has to either remain a vital core part of Goodboys day to day workflow, or be so open and well adopted that the wider community can and will carry out all development instead. I believe this is a fine line.
Assuming a rewrite in this manner will suddenly open the flood-gates to developers who wouldn't otherwise have helped is wishful thinking at best. I believe the reality is that there's a very finite number of developers who have the technical ability to help anyway. If Mat were to spend time writing in detail how Pixi works, explaining about the batch process, the shaders and the rest of the internals then I can't help but think this single act could help bring in more developers in than any other actually. But that's an aside (and really could do with happening regardless)
If Pixi is to truly be a pure renderer and nothing else then it needs entirely stripping out and turning into such. From this then perhaps @GoodboyDigital could work Pixi into a new project that adds in all of the extras they actually need for day-to-day work and not even have them as part of the core library (even in module form).
However as Pixi isn't really a renderer at all right now (it's turned into a bit of a swiss army knife!) then maybe this is where the discussion should start off? I think both Mat and Chad (and everyone else!) should agree with a joint definition, which should evolve into a core features list and roadmap, before any code is touched at all.

@englercj

After I replace code in pixi with external existing modules, what code is left that is pixi-specific that could become agnostic?

It's hard to say, since so much of Pixi is written with side-effects and thus generally harder to "rip out" into decoupled modules. For example, the ellipse function (using quadratic curves) would be useful in a module, but not in the current way it's written.
@drkibitz

The canvas is probably the most simple in that it would be nice to circumvent the need for a canvas in general, and just provide the context directly

Do you mean like passing a CanvasRenderingContext2D to the WebGLRenderer? I would be in favour of this, and I've started doing this in my own tools. When something needs to operate on a webgl/2d canvas, I prefer passing around contexts for a few reasons:

this way there is only a single (top-level) call to getContext, which ensures the user has exact control over the context attributes (like premultipliedAlpha and failIfMajorPerformanceCaveat)
some debuggers (like Chrome Dev Tools) have trouble inspecting draw calls when you have multiple getContext calls
webgl/2d context always has a back-reference to canvas if that is needed

On the topic of re-factor, I really think that ThreeJS-style object options in constructors might be worth considering. Especially for WebGLRenderer, which has become annoying with the mix of required/optional parameters.
@GoodBoyDigital

My brain is a little concerned about phase 4 as integrating other modules as it seems like it could add layers to pixi that may not be required.

Small and focused modules will help minimize this problem. If a module is "too big" or doesn't do something quite in line with how Pixi should do it, then it might be a case where a new module can be created. The benefits:

separation of concerns. e.g. no need to maintain event emitter code inside a rendering framework
others can utilize (and improve on) the module without bringing in the entire bulk of Pixi
reduced code duplication in final browser bundle
the code can be versioned and tested independently of Pixi

--
@photonstorm I agree with your points. Ultimately everything is up to the GoodBoyDigital team since they will be the ones that continue to maintain and improve Pixi. If they don't like the browserify / small modules route then a rewrite of this magnitude would have negative effects on the future of Pixi, and a fork (new project name etc) might be a better approach.
I have stopped using Pixi for personal projects because it does not produce re-usable code, and because it's usually overkill for the work I do. Every day Pixi seems to grow exponentially (in size and complexity), with new features that 99% of the time I will never need. I still use Pixi at work because it's well documented (good for teams / juniors) and because the existing ecosystem of npm modules have not caught up to it. This will probably change in time, as stackgl and similar projects become more mature.

@englercj

After I replace code in pixi with external existing modules, what code is left that is pixi-specific that could become agnostic?

It's hard to say, since so much of Pixi is written with side-effects and thus generally harder to "rip out" into decoupled modules. For example, the ellipse function (using quadratic curves) would be useful in a module, but not in the current way it's written.
@drkibitz

The canvas is probably the most simple in that it would be nice to circumvent the need for a canvas in general, and just provide the context directly

Do you mean like passing a CanvasRenderingContext2D to the WebGLRenderer? I would be in favour of this, and I've started doing this in my own tools. When something needs to operate on a webgl/2d canvas, I prefer passing around contexts for a few reasons:

this way there is only a single (top-level) call to getContext, which ensures the user has exact control over the context attributes (like premultipliedAlpha and failIfMajorPerformanceCaveat)
some debuggers (like Chrome Dev Tools) have trouble inspecting draw calls when you have multiple getContext calls
webgl/2d context always has a back-reference to canvas if that is needed

On the topic of re-factor, I really think that ThreeJS-style object options in constructors might be worth considering. Especially for WebGLRenderer, which has become annoying with the mix of required/optional parameters.
@GoodBoyDigital

My brain is a little concerned about phase 4 as integrating other modules as it seems like it could add layers to pixi that may not be required.

Small and focused modules will help minimize this problem. If a module is "too big" or doesn't do something quite in line with how Pixi should do it, then it might be a case where a new module can be created. The benefits:

separation of concerns. e.g. no need to maintain event emitter code inside a rendering framework
others can utilize (and improve on) the module without bringing in the entire bulk of Pixi
reduced code duplication in final browser bundle
the code can be versioned and tested independently of Pixi

--
@photonstorm I agree with your points. Ultimately everything is up to the GoodBoyDigital team since they will be the ones that continue to maintain and improve Pixi. If they don't like the browserify / small modules route then a rewrite of this magnitude would have negative effects on the future of Pixi, and a fork (new project name etc) might be a better approach.
I have stopped using Pixi for personal projects because it does not produce re-usable code, and because it's usually overkill for the work I do. Every day Pixi seems to grow exponentially (in size and complexity), with new features that 99% of the time I will never need. I still use Pixi at work because it's well documented (good for teams / juniors) and because the existing ecosystem of npm modules have not caught up to it. This will probably change in time, as stackgl and similar projects become more mature.

@mattdesl

Do you mean like passing a CanvasRenderingContext2D to the WebGLRenderer?

Yes.

the code can be versioned and tested independently of Pixi

:+1:

Hello all!
@mattdesl thanks for sharing so much information! That combined with a decent conversation with @englercj has really helped in my understanding of this approach.
The penny is starting to drop as it where and I'm starting to get a more excited! I still need to see and engage in this new philosophy for me to truly get to grips with it I feel, so im certainly up for giving it a go and seeing where this heads. Just be prepared for some silly questions :)
Research and playing around for me when I get home i think...
With regards to the things I do understand a lot better.. I'm 100% on board with a solid refactor of certain core parts of pixi that will make it much easier for people to only use the parts of pixi that they need to use rather than rolling it all into one big ball that includes everything. A more DRY approach and following this lovely statement:
"Make modules be standalone, defined as: they don't require extra code for their use-case to be added to core."
After driving a car for 10 hours today I had a lot of thinking time and have a few solid ideas that I am confident will get us to that goal!
I guess my question to you all is what would you consider to be core pixi? would it be as simple as:
webGLRenderer
canvasRenderer
displayObject
displayObjectContainer
Sprite
Graphics
That seems like it would be pretty nice and bare bones to you all?
And a few more thoughts..
-Whats pixi all about?
The two most important things to me for pixi are this:
1 - Its fast and has killer performance
2 - Its has a clean simple API that abstracts away all the complexities of webGL / Canvas rendering so developers of all skill sets can crack on and make the content that visually look killer! Like magic :)
How we ended up where we are..
The focus on pixi so far has always been on the end result and it performing what is required. The requirements have come from either a necessity for a project I'm working on or community feedback from its users. So its has kind of grown fairly organically. This has been a good thing in terms of finding out what pixi is actually useful for!
I am confident that what we have feature wise is strong and to be honest I don't think that there are any left that need to be added to pixi as it is. Certainly some refactoring, making existing features stronger  and moving some out of the core offering.. But not any real new ones!
I do have some higher level ideas but they will certainly be plugins and separate (A 2D dynamic lighting system "pixiLights" being one of them!)
So yup, I honestly think they are the 2 main reasons that the uptake has been so good this year! So with that in mind I think the idea of making pixi leaner and generally more module is a thing that has to happen.
That way more advanced users can pick and choose the elements from pixi that are required for their projects and new comers or people who don't wish to dabble can have the same experience they currently have when using pixi.
win win right?
Also @mattdesl out of curiosity, what are your thoughts on existing engines like three.js?

A 2D dynamic lighting system "pixiLights" being one of them!

LightSpriteBatch and stuff from http://www.goodboydigital.com/pixijs/pixilights/? It is not perfect-pixel shadows. Right?

@GoodBoyDigital
The thing to keep in mind is that the re-write is only a small step toward modularity. Pixi is never going to end up as modular as, say, stackgl. And that's OK, since most people are happy with Pixi as-is.
At a high level the goal of npm modules would be to: "use dependencies to make the codebase more manageable." Examples:

using an "events" module instead of baking one into the Pixi codebase
instead of copy-pasting chunks of code (like triangulation, point-in-polygon, webgl context detection, etc), they should be brought in via a dependency, so we can receive patch updates upstream
splitting some of the current agnostic code bits into their own modules (e.g. hex/rgb conversion)

I'm sure the options will become more clear as more work is done on the rewrite/fork.

I'm trying to figure out how to best contribute to Pixi. At the moment I'm scanning the issue tracker and finding small stuff that'll familiarize myself with the codebase. Eventually I'm going to want to start working on more in-depth issues, so I'd love if @GoodBoyDigital and @englercj could start labeling issues to make it easy to contribute to development rather than bugs. Also, can I help make this happen?

@marcusstenbeck You are 100% correct, I used to be on top of labeling everything but as the size of the code and the popularity increased I wasn't able to keep up! With the rewrite there will be new organizational strategies (the extra modules will have their own repo) which means we will better be able to deal with the volume of issues and narrow their scope.
At the same time I'm hoping we can move development to the pixi.js organization to better manage permissions across repos and me/Mat don't necessarily have to solo maintain the entire pixi ecosystem. There are definitely going to be opportunities to help going forward, try to hang in there with us as we figure out the best ways to get everyone involved!

Also, @GoodBoyDigital, on the topic of Threejs...
I think it's an awesome project that has a much larger scope than Pixi, and also deals with a much more challenging domain (3d graphics). I also think other solutions like Stackgl and Pex are still very far away from it.
That said, it has the same problems being discussed in the thread. Very hard to write reusable code with threejs (lots of existing plugins do not work after a few versions), and also very hard to pick apart pieces of Threejs to use them outside of its intended scope (like vector math and color utils). It's constantly adding new features, complexity and bloat with no real end in sight, when really those features would be better suited in user land.

This is a very good step forward. I think the project will benefit from it.
What I'd like to see is de-coulping the core from DOM related methods and make these methods pluggable (getElementsByTagName I'm looking at you :P). This would allow for simple dependency management when building for environment different then the browser (eg. WP8.1, Tizen, CocoonJS).

@wojciak That is definately one of our goals, keep in mind the fn you describe is not in what we are considering core for v3.
I guess my question to you all is what would you consider to be core pixi? would it be as simple as:

webGLRenderer
canvasRenderer
displayObject
displayObjectContainer
Sprite
Graphics

That seems like it would be pretty nice and bare bones to you all?

That is the running idea right now, everything else is a separate module/plugin.

:+1:

What about current TODOs in the code? Outdated, current, or "who knows"?

@marcusstenbeck At the end of Phase 8 I wrote:

I will also take this opportunity and go through all the TODO comments in the code, and actually do them.

👍👌
On Mon, Jan 5, 2015 at 6:12 AM, Chad Engler<EMAIL_ADDRESS>wrote:

@marcusstenbeck At the end of Phase 8 I wrote:

I will also take this opportunity and go through all the TODO comments in the code, and actually do them.

Reply to this email directly or view it on GitHub:
https://github.com/GoodBoyDigital/pixi.js/issues/1296#issuecomment-68669180

Hi, new here and just found pixi - I'm excited about this rewrite and plan on watching it closely.  I just wanted to share my 2 cents on improving maintainability, they will be generic but hopefully they will apply in most aspects of this rewrite.
Generally speaking, there are a few things that really help maintainability of projects (from my experience working on enterprise apps)

Global Design Patterns (Not graphics design, but syntactic sugar)
What I mean to say is, any development type doc that details coding patterns that should be followed.  Defining object construction patterns, module patterns, JSON patterns help the "knowledge transfer" process and improve longevity / maintainability.

Core Framework - A repository of one single module that holds items that are needed by everything else.  THe Core Framework should NOT have anything that is used by SOME of the other modules.

example pixi/framework/core/

Shared Assets Library - A repository of modules that COULD be considered part of the CORE FRAMEWORK - BUT becuase other modules do not necessarily need them, they should be put here - and can be accessed by any other module, but is only added if needed.

example pixi/framework/shared/[asset-name]/

Agnostic Modules - Modules that need core framework to run, but do not need any other Agnostic Modules ever, and should be considered completely separate, almost like separate products or applications.  Agnostic modules need core framework, and may use shared assets library or not.

example pixi/modules/[module-name]/
Just 2 cents.  I think everything already stated is 100% great and the plan as is great.  Just wanted to share my experience is all.  I would need to have more knowledge of the source code to provide anything more specific.

I've been looking into finding an npm module to handle events. I don't believe EventEmitter is what pixi is looking for (no way to signal that an event is handled). There are a few EventTarget npm modules though

@serprex What about signals https://github.com/millermedeiros/js-signals ?

@gre Too slow :)

If you're planning a massive rewrite, why not future-proof with ES6 modules using SystemJS?

@kittykatattack We had that discussion a million times now, the basic gist is:

We still want a single-file output, so there will still be a build step either way.
The polyfils for ES6->ES5 produce some pretty gross (unoptimized at times) code.
ES6 modules do nothing for letting make use of the npm registry.
Saying that browserify is "not future proof" is just FUD, it isn't going anywhere for a long time.

and many other reasons you can find by searching around the issue list.

@englercj Thanks for explaining that

ES6 is pretty fantastic in some ways; 6to5 produces very clean transpiling for things like arrow function, spread, default params, rest, string templating, classes, etc. It plays fine with modules and npm. :) But it's a different beast, introducing some new complexities for contributors, and brings to question what happens when some es6 code is pulled out of core into its own module.
@gre I've been on both sides of the fence with signals. On large projects signals have some advantages, but more recently I've found events play better with npm/modules as a whole, and also have potential for FRP down the road. The real selling point of events for me is code readability:
var foo = createFoo()

//is this a signal? a boolean? a jQuery-like getter function?
console.log( foo.started )

foo.started.addOnce(handler)

Compared to events which does not carry the same ambiguity, and reads almost like regular English. "Once foo is started, do handler."
var foo = createFoo()
foo.once('started', handler)

But I admit it mostly comes down to personal preference, since the differences are pretty minor. :)

It plays fine with modules and npm. :)

You still have to use CJS for npm modules, you can't just do raw ES6 and the node ecosystem suddenly works. Unless I grossly misunderstand something you are talking about compiling the ES6 then publishing that?

Yeah, but in the case of Pixi we already have a bundle step (browserify) so adding 6to5ify would be pretty transparent to end-users consuming with npm / bower / whatever. It gets a little more complicated when you have separate modules, because those might not need a bundle step (i.e. point-in-polygon is just raw source).
With that said, I don't really think ES6 is necessary for Pixi.

@mattdesl I meant us using npm modules. Even when using browserify we have to include npm modules with require using a CJS pattern anyway.

You can require stuff and still take advantage of es6 features. :)

@mattdesl Of course, I just don't think there are many worth us implementing for our use cases.

just bumping this one to say how impressed I am at the rate and work you two @englercj  @GoodBoyDigital  are pumping out in the dev branch.

+1 :+1:

Some wonderful brilliance going down here, thanks for being so awesome guys! @GoodBoyDigital @englercj

Just had a quick perusal of progress, also very impressed!
Hope it's ok to add 2 (more) ¢, probrably not the last ;)
I notice there are a couple, or few mixins now in existence, e.g. cacheAsBitmap, interactionTarget, eventTarget. I have no issues with this pattern, many times it is perferred, but having quite a bit of experience with react.js, I do like having things organized in such a way that a mixin is easy to spot, either by directory structure, module name, or both. Just a thought.

Will version 3 have a download similar to the way it is now?
Like JUST a Pixi.js file that we'll be able to grab without having to do the whole "build-on-the-command-line" kind of thing?

I'm not the owner here but I guess that's for sure. and if not, it is very easy to make one.
Keep up the great work guys

@SharpleafCC You will never have to build pixi.js yourself if you don't want to. We will definitely have a distributable that browserify will build for us.

Closing this now since we have completed the scope of this issue.

Does this mean v3 is ready? :D
On Sun, Mar 8, 2015 at 6:37 PM, Chad Engler<EMAIL_ADDRESS>wrote:

Closing this now since we have completed the scope of this issue.
Reply to this email directly or view it on GitHub:
https://github.com/GoodBoyDigital/pixi.js/issues/1296#issuecomment-77782241

:+1: great work!

@SharpleafCC No, it means the scope laid out in this issue has completed. The developer preview is out if you want to start working with the new lib, and we should be able to release the official v3 soon.

Does "developer preview" mean "whatever is currently in the dev branch", or is there some other place I'm missing?

@lucasb-eyer Developer Preview means "pre-release for developers". The dev branch is the latest bleeding edge code, the releases are the latest releases of the library (including pre-releases like our RCs).

I didn't even know about the github releases page! Thanks for the link and sorry for the noise.


XSLT writer overwrites enum values

Now, also the xslt writer overwrites enum values if provided via ABAP Doc

stuff like this is allowed by the rule,
DATA(abap_doc_of_component) = call_reader_and_decode(
  name_of_source = name_of_source
  element_name   = fullname_of_component ).

second case looks like a bug, open an issue?

Is it necessary to keep this PR open or can I merge it?


Removing the textDocumentNotebook API proposal

The textDocumentNotebook api proposal is currently not on track for finalization. See https://github.com/microsoft/vscode/issues/102091#issuecomment-865050645 for details on this
As an workaround, today you can achieve the same functionality with:
vscode.workspace.notebookDocuments.find(notebook => notebook.getCells().some(cell => cell.document === myTextDocument))

We plan to remove the TextDocument.notebook property once all consumers have moved off of it:

[x] LiveShare @alyssajotice @fubaduba
[ ] Dot net interactive @brettfo, @colombod
[ ] Copilot (and copilot nightly) @Krzysztof-Cieslak (let me know the correct owner if I got this wrong)
[x] microsoft/vscode-jupyter#9679

If you are on this list, please look into migrating off of this api and let us know if you run into any issues with the migration

Looks like we weren't really using it. I removed our usage.

Live Share is not using it. I will remove from our package.json.

Copilot (and copilot nightly) @Krzysztof-Cieslak (let me know the correct owner if I got this wrong)

Thanks for the ping! We've ticketed this to deal with next week (I'm responding on behalf of @Krzysztof-Cieslak as he's not around today)

Hey, the use of the API is removed on the Copilot side of things, but the new version of the extension hasn't been released yet.

@Krzysztof-Cieslak OK can you let me know when it is safe to remove on our side?

@mjbvz sorry we didn't update sooner: we did a release a few days ago so I think we're good for you to remove it.

@mjbvz Live Share has not released yet - I will update here once we do.

Confirmed that dot net is not using this. Will remove them from api consumers

Live Share released yeserday - you can remove us from the list of consumers.


(maint) Avoid return value confusion

The execute_request method always ensures the response body is drained so it's
not necessary to call response.body in cases where we're not streaming the
response. It also avoids confusion as to whether execute_request returns the
response body or the request.

@Magisus this is resolve the confusing execute_streaming behavior you ran into, hopefully it should be clearer? Also I submitted another PR to add better/improved yardocs for the http client (and others) https://github.com/puppetlabs/puppet/pull/8379

CLA signed by all contributors.


futures-util-preview doesn't compile on the recent nightly

It suddenly complains about Pins, maybe the upstream API has changed.
error[E0277]: the size for values of type `<&mut future::maybe_done::MaybeDone<Fut> as std::ops::Deref>::Target` cannot be known at compilation time
   --> futures-util/src/future/maybe_done.rs:110:9
    |
110 |         Pin::set(self, MaybeDone::Done(res));
    |         ^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `std::marker::Sized` is not implemented for `<&mut future::maybe_done::MaybeDone<Fut> as std::ops::Deref>::Target`
    = note: to learn more, visit <https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
    = help: consider adding a `where <&mut future::maybe_done::MaybeDone<Fut> as std::ops::Deref>::Target: std::marker::Sized` bound
    = note: all function arguments must have a statically known size
    = help: unsized locals are gated as an unstable feature

(...)

error: aborting due to 38 previous errors

$ rustc -V
rustc 1.32.0-nightly (6acbb5b65 2018-11-25)

It was okay until edaac35d6 2018-11-24.

cc @cramertj @withoutboats

Seems like a rustc inference issue, it should know that <typeof(self)>::Deref = Self here, and Self: Sized.
Here's all the commits to rust-lang/rust between those versions. I think there's some tool that can pull bors' try builds into rustup to be able to check the individual PRs?

https://github.com/rust-lang-nursery/futures-rs/pull/1351 contains a workaround.


Feature request: infer webDependencies from imports

When specifying a whitelist of webDependencies, it would be nice if the list could be inferred somehow from imports in local project source files. For one case that I am working on, I want to specify specific files in the whitelist, but there could be almost a hundred distinct modules that need to be specified.

An escape hatch that would help me here is glob patterns. If I could specify glob patterns in webDependencies, at least then I would only need 1 - 2 entries per dependency package.

Hey @cdata I had a similar idea over in #68 and didn't see your issue (whoops sorry), and there's a lot of conversation over there already if you want to join.

@cdata thanks for posting this, haven't forgotten about it! Follow up in #68: https://github.com/pikapkg/web/issues/68#issuecomment-520249855

@cdata glob matching support just merged to master


Fix manifest creation of nightly tag in Travis CI

In previous commit, tag nightly-20220722-e3eb8f4 is successfully pushed to docker hub with both amd64 and arm64 arch,
but the tag nightly failed to be updated.

Thanks all. Merging...


Remove sandbox/sweep-paired-reads.py

WTF?
https://github.com/ged-lab/khmer/blob/master/sandbox/sweep-paired-reads.py

(as simple as 'rm' :)

Claimed to work on this one.


[FEATURE REQUEST] Remember export format

After using "Export" feature, remember the type of map format used to export for the next time. Or make it possible to select preferred map format for export instead.
Maybe make it work for "Save as" too.

With 3e49407 added feature to store last chosen extension in #1.
Please report if it's working as intended.

Seems to be working. But no deep testing.


Material tag extension and texture support

material tag was extended.

Support texture image (blob handle in texture field)
metallic and smoothness fields
shader field for shader selection (standard or unlit)

PR #36


Wrong value for optional parameters

I have the following:
public void Save(string data, Action<AchievementSavedResponse> onComplete = null){

}

For the second parameter, it uses null for the name attribute instead of onComplete.
/// <summary>
///
/// </summary>
/// <param name="data"></param>
/// <param name="null"></param>

@TheColorRed Thanks for the code sample, helped me a lot :+1:


Review the french text for the 'you have not been selected' message

French text can be found here: https://014gc.sharepoint.com/:w:/r/sites/GCDevEx/Shared Documents/Change Management/Comms/TR0291 - Notification_text_FR.docx?d=w4c68e110573d44bda086ad223cf47662&csf=1&web=1&e=tj8Yup
English text can be found here: https://014gc.sharepoint.com/:w:/r/sites/GCDevEx/Shared Documents/Change Management/Comms/TR0291 - Notification_text_EN.docx?d=w4c876929c02f47f5a579dcbcf63f57e5&csf=1&web=1&e=ypu0Un

Note this text uses Notify formatting for variable names and conditional content.

Looks great! added a few little comments but nothing blocking. Great work!


fix: Use printf instead of echo in license generation

Fixes https://github.com/ZOSOpenTools/meta/issues/308
~  echo "\nView license contents at" > LICENSE
~  cat LICENSE
\nView license contents at
 ~  echo -e "\nView license contents at" > LICENSE
 ~  cat LICENSE

View license contents at
 ~ 

If using string inserts for printf, should the change be more of the format like below where the fixed string forms the first parameter and the variable inserts follow:
'''
printf "%s\nView license comments at %s\n" "${licenseName}" "${licenseUrl}"
'''

/run tests

/run tests