text:
Resources / Learning section

@CreaturesInUnitards suggestion per #1809

@pygy I requested the review due to this comment.

IMHO if you're going to include my screencasts — which is very flattering, and thank you — it might be better to just link to the playlist, rather than to the individual parts. There are at least 10 more to come!

@cavemansspa I'd suggest changing your PR to this one link: https://scrimba.com/playlist/playlist-34

@CreaturesInUnitards sounds good.  let's see where @pygy and co. decide on the learning materials location and i'll adjust accordingly.
just wanted to nudge this one along so that your efforts on putting together the scrimbas can be accessed from the main mithril site.

@cavemansspa thanks so much! I really appreciate it. TBH I thought about doing this PR myself, but it's WAY better that someone else do it 😃

@pygy @tivac any further thoughts on adding a "Learning" section to the docs?

@cavemansspa I'm good with this as a start, but having more resources later would be really nice. 😄

@cavemansspa Let's just do a single link to his screencasts at the beginning of the "Getting Started" section of the homepage.

FWIW the Scrimba folks are in the middle of updating their authoring tools; I have a bunch more content waiting for that update.

@isiahmeadows -- just wanted to bounce back an "are you sure" you want to put under "Getting Started"? after having a look at reverting this pr and looking at adding to "Getting Started", i'm thinking maybe the separate "Learning" section might be easier for newcomers to see.
i believe others (@JAForbes) were considering adding some mithril learning content so expecting it's a section that will grow.
happy to proceed either way but just wanted to double check.

echoing @cavemansspa I think a Learning section is a good idea but for different reasons.
I think "Getting Started" should be completely encapsulated.  Linking to other content (particularly at the beginning) creates the impression that those links are required in order to follow the getting started, whereas I think the current content is probably self contained as it is.
I want to avoid Analysis Paralysis / Paradox of Choice
I think the exception is environment stuff, like setting up npm.  But for usage, I think it'd be helpful to keep "Getting Started" as self contained as possible.  A link (or links) at the end of "Getting Started" on the other hand isn't as overwhelming because by that point they've probably completely the tutorial and feel quite confident to tackle more content.

i believe others (@JAForbes) were considering adding some mithril learning content so expecting it's a section that will grow.

I don't have any plans to do any "How to Mithril" sort of videos, but I am working on a streams series (that features mithril) and but that should definitely be tackled after resources like @CreaturesInUnitards series, and certainly after the "Getting Started".  So I can see a Learning section being valuable for that.
Whenever I've updated my mithril blog posts ( e.g. How I use Mithril ), it'd be a good place to link to them too (if no-one would be opposed).
So I'm 👍 for a separate Learning section.

If there's an expectation for the "Learning" section to grow, then let's go ahead and have a dedicated one. (My request was under the assumption it wouldn't likely grow anytime soon, but if I'm wrong, then having a new section makes more sense.)

@pygy Ping?

Looks good to me, we can always reshuffle later if things change.

authors: CreaturesInUnitards JAForbes cavemansspa isiahmeadows tivac


text:
Failure to build libharfbuzz_la-hb-ft.lo

Trying to build using regular make (no docker, no buildah). Fails when compiling HarfBuzz.
Tried popping back to 4.1.0, 4.0.0, same issue. What am I doing wrong?
make: make -j 16 install-libLTLIBRARIES install-pkgincludeHEADERS install-pkgconfigDATA
make[1]: Entering directory '/<PATH_OMITTED>/JavascriptSubtitlesOctopus/build/lib/harfbuzz/src'
  CXX      libharfbuzz_la-hb-aat-layout.lo
  CXX      libharfbuzz_la-hb-aat-map.lo
  CXX      libharfbuzz_la-hb-blob.lo
  CXX      libharfbuzz_la-hb-buffer-verify.lo
  CXX      libharfbuzz_la-hb-buffer-serialize.lo
  CXX      libharfbuzz_la-hb-buffer.lo
  CXX      libharfbuzz_la-hb-draw.lo
  CXX      libharfbuzz_la-hb-common.lo
  CXX      libharfbuzz_la-hb-face.lo
  CXX      libharfbuzz_la-hb-fallback-shape.lo
  CXX      libharfbuzz_la-hb-font.lo
  CXX      libharfbuzz_la-hb-map.lo
  CXX      libharfbuzz_la-hb-number.lo
  CXX      libharfbuzz_la-hb-ot-cff1-table.lo
  CXX      libharfbuzz_la-hb-ot-cff2-table.lo
  CXX      libharfbuzz_la-hb-ot-color.lo
  CXX      libharfbuzz_la-hb-ot-face.lo
  CXX      libharfbuzz_la-hb-ot-font.lo
  CXX      libharfbuzz_la-hb-ot-layout.lo
  CXX      libharfbuzz_la-hb-ot-map.lo
  CXX      libharfbuzz_la-hb-ot-math.lo
  CXX      libharfbuzz_la-hb-ot-meta.lo
  CXX      libharfbuzz_la-hb-ot-metrics.lo
  CXX      libharfbuzz_la-hb-ot-name.lo
  CXX      libharfbuzz_la-hb-ot-shaper-arabic.lo
  CXX      libharfbuzz_la-hb-ot-shaper-default.lo
  CXX      libharfbuzz_la-hb-ot-shaper-hangul.lo
  CXX      libharfbuzz_la-hb-ot-shaper-hebrew.lo
  CXX      libharfbuzz_la-hb-ot-shaper-indic-table.lo
  CXX      libharfbuzz_la-hb-ot-shaper-indic.lo
  CXX      libharfbuzz_la-hb-ot-shaper-khmer.lo
  CXX      libharfbuzz_la-hb-ot-shaper-myanmar.lo
  CXX      libharfbuzz_la-hb-ot-shaper-syllabic.lo
  CXX      libharfbuzz_la-hb-ot-shaper-thai.lo
  CXX      libharfbuzz_la-hb-ot-shaper-use.lo
  CXX      libharfbuzz_la-hb-ot-shaper-vowel-constraints.lo
  CXX      libharfbuzz_la-hb-ot-shape-fallback.lo
  CXX      libharfbuzz_la-hb-ot-shape-normalize.lo
  CXX      libharfbuzz_la-hb-ot-shape.lo
  CXX      libharfbuzz_la-hb-ot-tag.lo
  CXX      libharfbuzz_la-hb-ot-var.lo
  CXX      libharfbuzz_la-hb-set.lo
  CXX      libharfbuzz_la-hb-shape-plan.lo
  CXX      libharfbuzz_la-hb-shape.lo
  CXX      libharfbuzz_la-hb-shaper.lo
  CXX      libharfbuzz_la-hb-static.lo
  CXX      libharfbuzz_la-hb-style.lo
  CXX      libharfbuzz_la-hb-ucd.lo
  CXX      libharfbuzz_la-hb-unicode.lo
  CXX      libharfbuzz_la-hb-ft.lo
  CXX      libharfbuzz_subset_la-hb-number.lo
  CXX      libharfbuzz_subset_la-hb-ot-cff1-table.lo
  CXX      libharfbuzz_subset_la-hb-ot-cff2-table.lo
  CXX      libharfbuzz_subset_la-hb-static.lo
  CXX      libharfbuzz_subset_la-hb-subset-cff-common.lo
  CXX      libharfbuzz_subset_la-hb-subset-cff1.lo
  CXX      libharfbuzz_la-hb-ot-shaper-use.lo
  CXX      libharfbuzz_la-hb-ot-shaper-vowel-constraints.lo
  CXX      libharfbuzz_la-hb-ot-shape-fallback.lo
  CXX      libharfbuzz_la-hb-ot-shape-normalize.lo
  CXX      libharfbuzz_la-hb-ot-shape.lo
  CXX      libharfbuzz_la-hb-ot-tag.lo
  CXX      libharfbuzz_la-hb-ot-var.lo
  CXX      libharfbuzz_la-hb-set.lo
  CXX      libharfbuzz_la-hb-shape-plan.lo
  CXX      libharfbuzz_la-hb-shape.lo
  CXX      libharfbuzz_la-hb-shaper.lo
  CXX      libharfbuzz_la-hb-static.lo
  CXX      libharfbuzz_la-hb-style.lo
  CXX      libharfbuzz_la-hb-ucd.lo
  CXX      libharfbuzz_la-hb-unicode.lo
  CXX      libharfbuzz_la-hb-ft.lo
  CXX      libharfbuzz_subset_la-hb-number.lo
  CXX      libharfbuzz_subset_la-hb-ot-cff1-table.lo
  CXX      libharfbuzz_subset_la-hb-ot-cff2-table.lo
  CXX      libharfbuzz_subset_la-hb-static.lo
  CXX      libharfbuzz_subset_la-hb-subset-cff-common.lo
  CXX      libharfbuzz_subset_la-hb-subset-cff1.lo
  CXX      libharfbuzz_subset_la-hb-subset-cff2.lo
  CXX      libharfbuzz_subset_la-hb-subset-input.lo
  CXX      libharfbuzz_subset_la-hb-subset-plan.lo
  CXX      libharfbuzz_subset_la-hb-subset-repacker.lo
  CXX      libharfbuzz_subset_la-hb-subset.lo
hb-ft.cc:790:5: error: cast from 'int (*)(const FT_Vector *, hb_draw_session_t *)' (aka 'int (*)(const FT_Vector_ *, hb_draw_session_t *)') to 'FT_Outline_MoveToFunc' (aka 'int (*)(const FT_Vector_ *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    (FT_Outline_MoveToFunc) _hb_ft_move_to,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hb-ft.cc:791:5: error: cast from 'int (*)(const FT_Vector *, hb_draw_session_t *)' (aka 'int (*)(const FT_Vector_ *, hb_draw_session_t *)') to 'FT_Outline_LineToFunc' (aka 'int (*)(const FT_Vector_ *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    (FT_Outline_LineToFunc) _hb_ft_line_to,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hb-ft.cc:792:5: error: cast from 'int (*)(const FT_Vector *, const FT_Vector *, hb_draw_session_t *)' (aka 'int (*)(const FT_Vector_ *, const FT_Vector_ *, hb_draw_session_t *)') to 'FT_Outline_ConicToFunc' (aka 'int (*)(const FT_Vector_ *, const FT_Vector_ *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    (FT_Outline_ConicToFunc) _hb_ft_conic_to,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hb-ft.cc:793:5: error: cast from 'int (*)(const FT_Vector *, const FT_Vector *, const FT_Vector *, hb_draw_session_t *)' (aka 'int (*)(const FT_Vector_ *, const FT_Vector_ *, const FT_Vector_ *, hb_draw_session_t *)') to 'FT_Outline_CubicToFunc' (aka 'int (*)(const FT_Vector_ *, const FT_Vector_ *, const FT_Vector_ *, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    (FT_Outline_CubicToFunc) _hb_ft_cubic_to,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hb-ft.cc:1005:73: error: cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
  if (unlikely (!ft_face->generic.data || ft_face->generic.finalizer != (FT_Generic_Finalizer) hb_ft_face_finalize))
                                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./hb.hh:248:46: note: expanded from macro 'unlikely'
#define unlikely(expr) (__builtin_expect (!!(expr), 0))
                                             ^~~~
hb-ft.cc:1011:34: error: cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    ft_face->generic.finalizer = (FT_Generic_Finalizer) hb_ft_face_finalize;
                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hb-ft.cc:1274:32: error: cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
  ft_face->generic.finalizer = (FT_Generic_Finalizer) _release_blob;
                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7 errors generated.
em++: error: '/<PATH_OMITTED>/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -fignore-exceptions -DEMSCRIPTEN -I/<PATH_OMITTED>/emsdk/upstream/emscripten/cache/sysroot/include/SDL --sysroot=/<PATH_OMITTED>/emsdk/upstream/emscripten/cache/sysroot -Xclang -iwithsysroot/include/compat -DHAVE_CONFIG_H -I. -I.. -I/<PATH_OMITTED>/JavascriptSubtitlesOctopus/dist/libraries/include -I/<PATH_OMITTED>/JavascriptSubtitlesOctopus/build/lib/freetype/build_hb/dist_hb/include/freetype2 -fno-rtti -DHB_NO_MT -O3 -flto -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -MT libharfbuzz_la-hb-ft.lo -MD -MP -MF .deps/libharfbuzz_la-hb-ft.Tpo -c hb-ft.cc -o libharfbuzz_la-hb-ft.o' failed (returned 1)
make[1]: *** [Makefile:2702: libharfbuzz_la-hb-ft.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/<PATH_OMITTED>/JavascriptSubtitlesOctopus/build/lib/harfbuzz/src'
emmake: error: 'make -j 16 install-libLTLIBRARIES install-pkgincludeHEADERS install-pkgconfigDATA' failed (returned 2)
make: *** [Makefile:88: /<PATH_OMITTED>/JavascriptSubtitlesOctopus/dist/libraries/lib/libharfbuzz.a] Error 1

Starting from Emscripten 3.1.25

Clang's function pointer cast warnings (enabled with -Wcast-function-type)
are now stricter. This warning is intended to help with CFI errors but also
helps wasm builds since wasm traps on such type mismatches in indirect calls.
We recommend that users enable it to prevent such errors (which can be hard to
debug otherwise). The older (less strict) behavior is also still possible with
-Wcast-function-type -Wno-cast-funtion-type-strict (or
-Wno-error=cast-function-type-strict if you want the warnings to be visible
but not errors). See https://reviews.llvm.org/D134831

Fixed by https://github.com/harfbuzz/harfbuzz/pull/3859 (in harfbuzz 6.0.0)

source: gharchive/issue

authors: dmitrylyzo jimbojw

repo: libass/JavascriptSubtitlesOctopus

license: MIT

license_type: permissive

license_source: github-api


text:
[GWT] HttpResponse.getHeaders() returns null

The goal was to connect to a server from the GWT backend and to exchange some data using HTTP call: https://github.com/libgdx/libgdx/issues/1639
At the step 5: Http call was successfully executed, data submitted to the server from the GWT backend and the code "200 OK" received back.
Code:
public class GDXMessageTransport implements HttpResponseListener {
	private static final String GDX_API_PROXY_URL = "http://localhost:18080/gdx-entry-point-proxy/";

//CALL:
	public void establishConnection() {
		HttpRequest httpRequest = new HttpRequest();
		httpRequest.setMethod(HttpMethods.GET);
		httpRequest.setUrl(GDX_API_PROXY_URL);
		Gdx.net.sendHttpRequest(httpRequest, this);
	}

	@Override
	public void handleHttpResponse(HttpResponse httpResponse) {
		L.d("httpResponse", httpResponse);
		HttpStatus status = httpResponse.getStatus();
		L.d("status", status);
		int statusCode = status.getStatusCode();
		L.d("statusCode", statusCode);

		byte[] result = httpResponse.getResult();
		L.d("result", result);
		if (result != null) {
			L.d("result.length", result.length);
		}
		String string_result = httpResponse.getResultAsString();
		L.d("string_result", string_result);

		String header_set_cookie = httpResponse.getHeader("Set-Cookie");
		L.d("header_set_cookie", header_set_cookie);

		Map<String, List<String>> headers = httpResponse.getHeaders();
		print_map("map", headers);
		throw new Error("EXIT HERE");
	}

	private static void print_map(String name, Map<?, ?> value) {
		Set<?> keys = value.keySet();
		Iterator<?> i = keys.iterator();
		L.d("---" + name + "[" + value.size() + "]---");
		int k = 0;
		while (i.hasNext()) {
			Object key = i.next();
			Object val = value.get(key);
			L.d("   [" + k + "] " + key + " :-> " + val);
			k++;
		}
	}

	@Override
	public void failed(Throwable t) {
		t.printStackTrace();
	}

	@Override
	public void cancelled() {
		L.d("cancelled()");
	}

}

DesktopOutput:
G: httpResponse > com.badlogic.gdx.net.NetJavaImpl$HttpClientResponse@2e6f1b1c
G: status > com.badlogic.gdx.net.HttpStatus@32e920bb
G: statusCode > 200
G: result > [B@7f15be32
G: result.length > 0
G: string_result >
G: header_set_cookie > JSESSIONID=dfe2e46d4bde2683e774d984d4e0; Path=/gdx-entry-point-proxy; HttpOnly
G: ---map[8]---
G:    [0] Transfer-Encoding :-> [chunked]
G:    [1] null :-> [HTTP/1.1 200 OK]
G:    [2] Server :-> [GlassFish Server Open Source Edition  4.0]
G:    [3] Access-Control-Allow-Origin :-> [*]
G:    [4] Set-Cookie :-> [JSESSIONID=dfe2e46d4bde2683e774d984d4e0; Path=/gdx-entry-point-proxy; HttpOnly]
G:    [5] Date :-> [Sun, 15 Mar 2015 15:12:20 GMT]
G:    [6] Access-Control-Allow-Headers :-> [Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With, Access-Control-Allow-Origin]
G:    [7] X-Powered-By :-> [Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition  4.0  Java/Oracle Corporation/1.8)]

GwtOutput:

GDX version: 1.5.3
L.d() - is a logger class.

You seem to have CORS misconfigured. Your server should send the "Access-Control-Expose-Headers" header in the response, and list the headers that it is allowing to be read.

Here is the exact line of code that need to be fixed: https://github.com/libgdx/libgdx/blob/master/backends/gdx-backends-gwt/src/com/badlogic/gdx/backends/gwt/GwtNet.java#L82
I don't think that re-configuring my (or any other) server would somehow do this.

It works when you don't use CORS, or when you expose the headers. Sorry the browser doesn't work to your liking.

In the line 80 com.google.gwt.http.client.Response returns bad headers. Ok, this is external and has nothing to do with Gdx.
Then gdx-scope starts.
GwtNet receives external object "Header[] responseHeaders". Then at the line 82  it calls .getName() method without checking if the received object is valid.
String headerName = responseHeaders[i].getName();

Drops exception because of a missing null-check.

Well, arguably - there should be no null items in the array. That is a side-effect of misconfiguration. But we can add a null check.

Ok.
Probably there should be also something like:
if (header == null) {
Log.e("Failed to receive headers from com.google.gwt.http.client.Response.");
}

So that wouldn't be a mystery of missing headers in the future.

I don't really see any need to differentiate between getting no headers and getting no headers because some underlying library failed to return them.

Well there are two different situations:

Server didn't return any headers. So it is ok, and the fixed code works as planned.

com.google.gwt.http.client.Response returned garbage output. Something is wrong.

I think here we should form an Exception and pass it to the HttpResponseListener calling the failed() method. So gdx-user can print it and to see the problem:
 @Override
    public void failed(Throwable t) {
        t.printStackTrace();
    }

Otherwise people will spend lives wondering about empty headers.

Now we are elevating a missing header (due to the browser following the
spec) to failing the entire request? I definitely don't think that's the
right thing to do.

Ok.

authors: JFixby MobiDevelop

repo: libgdx/libgdx


text:
Inaccurate Collisions when using Bullet.obtainStaticNodeShape()

Ok, so I've recently been trying to create collision shapes using models that I've exported from Blender. I am using the Bullet Physics engine and libGDX 1.9.2. Whenever I run this test with a collision shape that is created as a btBoxShape, everything works as it should. Whenever I use the Bullet.obtainStaticNodeShape() with the nodes of my model, which is a cube, I can see that the shape is generated properly through the Debug Drawer. The physics of the object only seem to work in a small area located in the center of the shape, everywhere else, objects simply fall through. The model is Blender's default cube with a scale of 24 on the X and Y axes, and a scale of 0.3 on the Z axis. I export as a fbx with a scale of .01 and -Z being Forward and Y Being Up in the export settings. I then use fbx-conv to generate a .g3db file.
Here is the class for the simple test that I've created that shows the issue.
package com.imackshun.tests.customcollisionshape;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.PerspectiveCamera;
import com.badlogic.gdx.graphics.g3d.Model;
import com.badlogic.gdx.graphics.g3d.loader.G3dModelLoader;
import com.badlogic.gdx.graphics.g3d.utils.CameraInputController;
import com.badlogic.gdx.math.Vector3;
import com.badlogic.gdx.physics.bullet.Bullet;
import com.badlogic.gdx.physics.bullet.DebugDrawer;
import com.badlogic.gdx.physics.bullet.collision.btBoxShape;
import com.badlogic.gdx.physics.bullet.collision.btBroadphaseInterface;
import com.badlogic.gdx.physics.bullet.collision.btCollisionConfiguration;
import com.badlogic.gdx.physics.bullet.collision.btCollisionDispatcher;
import com.badlogic.gdx.physics.bullet.collision.btCollisionObject;
import com.badlogic.gdx.physics.bullet.collision.btCollisionShape;
import com.badlogic.gdx.physics.bullet.collision.btDbvtBroadphase;
import com.badlogic.gdx.physics.bullet.collision.btDefaultCollisionConfiguration;
import com.badlogic.gdx.physics.bullet.collision.btDispatcher;
import com.badlogic.gdx.physics.bullet.dynamics.btConstraintSolver;
import com.badlogic.gdx.physics.bullet.dynamics.btDiscreteDynamicsWorld;
import com.badlogic.gdx.physics.bullet.dynamics.btDynamicsWorld;
import com.badlogic.gdx.physics.bullet.dynamics.btSequentialImpulseConstraintSolver;
import com.badlogic.gdx.physics.bullet.linearmath.btIDebugDraw;
import com.badlogic.gdx.utils.UBJsonReader;

public class CustomCollisionShape extends ApplicationAdapter {
	public PerspectiveCamera cam;
	// For the ground collision... The player shouldn't fall through the ground.
	private btCollisionShape groundShape;
	private btCollisionObject groundCollision;
	private Model collisionModel;
	//Objects to fall
	private btCollisionShape boxShape;
	private Object boxCollision1;
	private Object boxCollision2;
	private Object boxCollision3;
	private Object boxCollision4;
	private Object boxCollision5;
	// Used for collisions.
	private btCollisionConfiguration collisionConfig;
	private btDispatcher dispatcher;
	private btBroadphaseInterface broadphase;
	private btDynamicsWorld dynamicsWorld;
	private btConstraintSolver constraintSolver;
	private DebugDrawer debugDrawer;
	//For controlling the camera.
	public CameraInputController camController;
	@Override
	public void create() {
		//Initialize the camera...
		cam = new PerspectiveCamera(67, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
		cam.position.set(0f, 25f, 30f);
		cam.lookAt(0, 0, 0);
		cam.near = 1f;
		cam.far = 300f;
		cam.update();
		//Camera controller.
		camController = new CameraInputController(cam);
        Gdx.input.setInputProcessor(camController);
		// Initialize the physics engine!
		Bullet.init();
		//Physics Stuff
		collisionConfig = new btDefaultCollisionConfiguration();
		dispatcher = new btCollisionDispatcher(collisionConfig);
		broadphase = new btDbvtBroadphase();
		constraintSolver = new btSequentialImpulseConstraintSolver();
		dynamicsWorld = new btDiscreteDynamicsWorld(dispatcher, broadphase, constraintSolver, collisionConfig);
		dynamicsWorld.setGravity(new Vector3(0, -30f, 0));
		debugDrawer = new DebugDrawer();
		debugDrawer.setDebugMode(btIDebugDraw.DebugDrawModes.DBG_MAX_DEBUG_DRAW_MODE);
		dynamicsWorld.setDebugDrawer(debugDrawer);
		//Load the model.
        UBJsonReader jsonReader = new UBJsonReader();
        G3dModelLoader modelLoader = new G3dModelLoader(jsonReader);
        //collisionModel = modelLoader.loadModel(Gdx.files.internal("ArenaCollisionCube.g3db"));
        //This works just fine.
        groundShape = new btBoxShape(new Vector3(20f, 1f, 20f));
        //This is inaccurate everywhere but the center.
		//groundShape = Bullet.obtainStaticNodeShape(collisionModel.nodes);
		groundCollision = new btCollisionObject();
		groundCollision.setCollisionShape(groundShape);
		groundCollision.setUserValue(0);
		groundCollision.setCollisionFlags(groundCollision.getCollisionFlags() | btCollisionObject.CollisionFlags.CF_CUSTOM_MATERIAL_CALLBACK);
		dynamicsWorld.addCollisionObject(groundCollision);
		//Boxes
		boxShape = new btBoxShape(new Vector3(2f, 2f, 2f));
		// Initialize the Rigidbodies.
		boxCollision1 = new Object(new Vector3(0f, 10f, 0f), boxShape, dynamicsWorld, 1);
		boxCollision2 = new Object(new Vector3(-18f, 10f, 0f), boxShape, dynamicsWorld, 2);
		boxCollision3 = new Object(new Vector3(18f, 10f, 0f), boxShape, dynamicsWorld, 3);
		boxCollision4 = new Object(new Vector3(0f, 10f, -18f), boxShape, dynamicsWorld, 4);
		boxCollision5 = new Object(new Vector3(0f, 10f, 18f), boxShape, dynamicsWorld, 5);
	}

	@Override
	public void render() {
		Gdx.gl.glViewport(0, 0, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
		Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT | GL20.GL_DEPTH_BUFFER_BIT);
		//Update the camera controller!
        camController.update();
		// Update the physics engine!
		final float delta2 = Math.min(1f / 30f, Gdx.graphics.getDeltaTime());
		dynamicsWorld.stepSimulation(delta2, 5, 1f / 60f);
		// Physics debugging.
		debugDrawer.begin(cam);
		dynamicsWorld.debugDrawWorld();
		debugDrawer.end();
	}
}

Here is the Object.class file. Just to make it easier to create the rigidbodies.
package com.imackshun.tests.customcollisionshape;

import com.badlogic.gdx.math.Vector3;
import com.badlogic.gdx.physics.bullet.collision.btCollisionObject;
import com.badlogic.gdx.physics.bullet.collision.btCollisionShape;
import com.badlogic.gdx.physics.bullet.dynamics.btDynamicsWorld;
import com.badlogic.gdx.physics.bullet.dynamics.btRigidBody;

public class Object {
	private float Mass;
	// The actual collision objects...
	public btRigidBody rbody;
	// Used to construct a rigidbody.
	public btRigidBody.btRigidBodyConstructionInfo constructionInfo;
	// Uh...Hmmm. IDK lol? Takes in mass... Like...Resistance?
	private static Vector3 localInertia = new Vector3();

	// Constructor
	public Object(Vector3 Position, btCollisionShape CollisionShape, btDynamicsWorld dynamicsWorld, int userValue) {
		Mass = 10;
		if (Mass > 0f) {
			CollisionShape.calculateLocalInertia(Mass, localInertia);
		} else {
			localInertia.set(0, 0, 0);
		}
		this.constructionInfo = new btRigidBody.btRigidBodyConstructionInfo(Mass, null, CollisionShape, localInertia);
		constructionInfo.setFriction(10f);
		rbody = new btRigidBody(constructionInfo);
		rbody.setCollisionShape(CollisionShape);
		rbody.setLinearFactor(new Vector3(1f, 1f, 0f));
		rbody.setUserValue(userValue);
		// Determines how this object ineracts with other objects.
		rbody.setCollisionFlags(rbody.getCollisionFlags() | btCollisionObject.CollisionFlags.CF_CUSTOM_MATERIAL_CALLBACK);
		// Add the collision objects to za warudo.
		rbody.translate(new Vector3(Position.x, Position.y, Position.z));
		dynamicsWorld.addRigidBody(rbody);
	}
}

Here is a link to the exact model that I am using.
https://www.dropbox.com/s/696dk3gk2etge4t/ArenaCollisionCube.blend?dl=0

Problem solved. Scaling the model Edit Mode did the trick.

I realize this thread is pretty old but would either of you be able to go into more detail on how you solved this? I'm running into the same problem and setting the scaling/subdividing in Blender hasn't made any changes :x

Okay, finally we used btCollisionShape mapShape = Bullet.obtainStaticNodeShape(model.nodes);
The problem with the big polygons was not the only thing (in fact, most of the polygons weren't that big in our case).
The other thing was that we didn't use the correct FBX export settings in Blender.
I'm not sure which combination was the right one, since I did this a few months ago, but I think it had to do something with one of the checkboxes '!EXPERIMENTAL! Apply Transform' or 'Custom Properties'.
In January, I was actually too lazy to look up the exact definitions of those flags, but I remember that I played around with them and it worked with a certain combination of them.
Hope that helps...

All right, I will try that. For future reference, how big is "too big?" A certain number of units?

Sorry, I don't have any measures for this. Our procedure was modeling the map and trying it out. If something weird happened, we tried to subdivide the polygons.

just stumbled across this same problem again and I'm pretty sure that the option in the Blender FBX exporter you are searching for is named "Tangent space".
Without it, the player falls through the map, checking the box results in ecpected behavior.

Hello. I am currently facing the same issue. I know this post is 2 years-old, but I have not found any solution anywhere else.
I would like to create a complete interior decor with walls and doors. All the objects I create with Blender can be easily imported into libgdx. But it only works for btBoxShape. If I need a concav shape like a wall with a door hole, I need to use obtainStaticNodeShape if I want my character to go through the hole.
Thanks for your help.

To solve this problem you should

choose your object in Blender in Object Mode
Click the button "Object" (near the "Object Mode") -> "Apply" -> "Scale" (scale X 1.000, Y 1.000, Z 1.000).
When you export your scene via .fbx you should mark checkboxes "Apply Transform" and "Tangent Space". Also in transform set scale 0.01

In addition, you can export your object via .obj and then convert it via https://asneakyfox.github.io/libgdx-fbxconv-gui/ . There're no problems with Scaling.

authors: DimaL-cloud DragoniteSpam cpfr fgermane iMackshun


text:
LWJGL3: Window positioning fixes.

Fixes #5845 on Windows.
Fix position for maximized window when specifying maximizedMonitor.
Center default window on primary monitor's working area.

Has issues on windows that need figured out before merging. See https://github.com/libgdx/libgdx/issues/5845#issuecomment-559021982

Any chance this can get merged? I think current implementation makes maximizing windows on Windows virtually useless.

Are the issues mentioned above sorted out?

Whoops, I guess I forgot to add a comment after those got resolved.

source: gharchive/pull-request

authors: PokeMMO crykn


text:
GWT - Calculate MD5 hash while copying file to avoid errors on very large files

For GWT, we calculate an MD5 hash of the file contents of each asset to assist browsers with caching. The current implementation reads the file fully into a byte array, calculates the MD5, adds it to the destination file name, then copies the source file to the output path. While this is fine for small files (albeit inefficient as we read each file multiple times), it can cause problems with large files.
This proposed implementation instead calculates the MD5 while reading the source InputStream for the copy operation, then renames (moves) the file to include the MD5 hash.
Refer to #4314 for the original addition, and #6848 for the problem this solves.

@MobiDevelop amazing! Have you noticed any gain on speed during GWT build?

A note on the build failure, oddly it has started picking up the emulation of File which doesn't have the getPath() method. Weird that it never did that while I was coding it, and now it is. I wouldn't think the compile time generator would be using the emulation classes - but GWT magic is the darkest of magic.

Thank you for the PR @MobiDevelop! I will try to test this new logic with the asset I was trying before and check how it performs.

authors: MobiDevelop yuripourre


text:
Does libP2P support authentication?

Does libP2P support CA(Certificate Authority)?(For example, I want to use libP2P to create a coalition that requires an access mechanism to enter)

Please redirect questions to the forums, https://discuss.libp2p.io/. There's a broader community there to help answer, and this repo isn't the place for general questions.

authors: itachiliu jacobheun


text:
chore: release main

:robot: I have created a release beep boop
autonat: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

bootstrap: 10.0.1
10.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1

circuit-relay-v2: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-record bumped from ^6.0.10 to ^6.0.11
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

crypto: 3.0.1
3.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

dcutr: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11

fetch: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

floodsub: 8.0.15
8.0.15 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/pubsub bumped from ^8.0.11 to ^8.0.12

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

identify: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-record bumped from ^6.0.10 to ^6.0.11

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

interface: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

add status property (#2269) (a32e70b)
restore lost commits (#2268) (5775f1d)

interface-compliance-tests: 5.0.1
5.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/multistream-select bumped from ^4.0.7 to ^4.0.8
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

interface-internal: 0.1.11
0.1.11 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10

kad-dht: 11.0.1
11.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
@libp2p/peer-store bumped from ^9.0.10 to ^9.0.11

keychain: 4.0.1
4.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

logger: 4.0.1
4.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

devDependencies

@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

mdns: 10.0.1
10.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

mplex: 10.0.1
10.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1

multidim-interop: 2.0.1
2.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/circuit-relay-v2 bumped from ^1.0.0 to ^1.0.1
@libp2p/identify bumped from ^1.0.0 to ^1.0.1
@libp2p/mplex bumped from ^10.0.0 to ^10.0.1
@libp2p/ping bumped from ^1.0.0 to ^1.0.1
@libp2p/tcp bumped from ^9.0.0 to ^9.0.1
@libp2p/webrtc bumped from ^4.0.0 to ^4.0.1
@libp2p/websockets bumped from ^8.0.0 to ^8.0.1
@libp2p/webtransport bumped from ^4.0.0 to ^4.0.1
libp2p bumped from ^1.0.0 to ^1.0.1

multistream-select: 4.0.8
4.0.8 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1

peer-collections: 4.0.10
4.0.10 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

peer-id: 4.0.1
4.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

peer-id-factory: 3.0.10
3.0.10 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

peer-record: 6.0.11
6.0.11 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

peer-store: 9.0.11
9.0.11 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
@libp2p/peer-record bumped from ^6.0.10 to ^6.0.11

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1

perf: 3.0.1
3.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1

ping: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1

plaintext: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

prometheus-metrics: 3.0.1
3.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

pubsub: 8.0.12
8.0.12 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

tcp: 9.0.1
9.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1

upnp-nat: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

utils: 5.0.1
5.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10

webrtc: 4.0.1
4.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/circuit-relay-v2 bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
@libp2p/websockets bumped from ^8.0.0 to ^8.0.1
libp2p bumped from ^1.0.0 to ^1.0.1

websockets: 8.0.1
8.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/logger bumped from ^4.0.0 to ^4.0.1

webtransport: 4.0.1
4.0.1 (2023-11-30)
Bug Fixes

restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1

devDependencies

@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
libp2p bumped from ^1.0.0 to ^1.0.1

libp2p: 1.0.1
1.0.1 (2023-11-30)
Bug Fixes

add status property (#2269) (a32e70b)
restore lost commits (#2268) (5775f1d)

Dependencies

The following workspace dependencies were updated

dependencies

@libp2p/crypto bumped from ^3.0.0 to ^3.0.1
@libp2p/interface bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-internal bumped from ^0.1.10 to ^0.1.11
@libp2p/logger bumped from ^4.0.0 to ^4.0.1
@libp2p/multistream-select bumped from ^4.0.7 to ^4.0.8
@libp2p/peer-collections bumped from ^4.0.9 to ^4.0.10
@libp2p/peer-id bumped from ^4.0.0 to ^4.0.1
@libp2p/peer-id-factory bumped from ^3.0.9 to ^3.0.10
@libp2p/peer-store bumped from ^9.0.10 to ^9.0.11
@libp2p/utils bumped from ^5.0.0 to ^5.0.1

devDependencies

@libp2p/bootstrap bumped from ^10.0.0 to ^10.0.1
@libp2p/circuit-relay-v2 bumped from ^1.0.0 to ^1.0.1
@libp2p/floodsub bumped from ^8.0.14 to ^8.0.15
@libp2p/identify bumped from ^1.0.0 to ^1.0.1
@libp2p/interface-compliance-tests bumped from ^5.0.0 to ^5.0.1
@libp2p/kad-dht bumped from ^11.0.0 to ^11.0.1
@libp2p/mdns bumped from ^10.0.0 to ^10.0.1
@libp2p/mplex bumped from ^10.0.0 to ^10.0.1
@libp2p/plaintext bumped from ^1.0.0 to ^1.0.1
@libp2p/tcp bumped from ^9.0.0 to ^9.0.1
@libp2p/websockets bumped from ^8.0.0 to ^8.0.1

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/multidim-interop-v2.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/crypto-v3.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-internal-v0.1.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/libp2p-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/logger-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/prometheus-metrics-v3.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/multistream-select-v4.0.8 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-collections-v4.0.10 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/bootstrap-v10.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/mdns-v10.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-id-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-id-factory-v3.0.10 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-store-v9.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/autonat-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/dcutr-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/fetch-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/identify-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/ping-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/pubsub-v8.0.12 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/floodsub-v8.0.15 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/circuit-relay-v2-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/tcp-v9.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webrtc-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/websockets-v8.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webtransport-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/upnp-nat-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/multidim-interop-v2.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/plaintext-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/crypto-v3.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-compliance-tests-v5.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/interface-internal-v0.1.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/kad-dht-v11.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/keychain-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/libp2p-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/logger-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/prometheus-metrics-v3.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/multistream-select-v4.0.8 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-collections-v4.0.10 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/mdns-v10.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-id-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-id-factory-v3.0.10 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-record-v6.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/peer-store-v9.0.11 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/autonat-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/dcutr-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/fetch-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/identify-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/perf-v3.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/ping-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/pubsub-v8.0.12 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/mplex-v10.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/circuit-relay-v2-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/tcp-v9.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webrtc-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/websockets-v8.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/webtransport-v4.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/upnp-nat-v1.0.1 :sunflower:

:robot: Release is at https://github.com/libp2p/js-libp2p/releases/tag/utils-v5.0.1 :sunflower:


text:
[docker] Add initial documentation / framework for public full node support

Checkpointing this work as we make progress on opening up our full node access.
This docker compose and node config has been verified to work on a swarm
instances. Will update it once we have testnet publicly available.

Are there any issues that folks see with this? :D

@christinacelee, mind taking a look and stamping it if it seems sensible enough?

/land

repo: libra/libra


text:
Check for protocol in Webhook URLs

This prevents an error when a user submits a webhook URL without a
protocol such as www.example.com or 192.0.2.0.

:+1:

authors: akahn obfuscurity

repo: librato/librato-services

license: mit

license_source: bigquery


text:
Issue pfls event to metadata pipe when pausing, stopping or changing tracks

Is your feature request related to a problem? Please describe.
Can you issue a pfls command to the shairport-sync style metadata pipe when either pausing, stopping or changing track. This enables forked-daapd to immediately pause as opposed to a significant delay or 4-5 seconds before the command is observed in forked-daapd due to the audio stream ending. I have requested @ejurgensen to implement this feature in forked-daapd which has been done (see issue 295). Many thanks.
Describe the solution you'd like
Issue a 'pfls' event to the configured metadata pipe when pausing, stopping or changing track.
Describe alternatives you've considered
None
Additional context
The command required to be issued is <item><type>73736e63</type>70666C73<length>0</length></item>

What is <item><type>73736e63</type>70666C73<length>0</length></item> for? Pause, stop or track change?

It's the pfls command. It instructs forked-daapd to drop the content on the audio buffer (which removes the lag). So the same command can be issued for all of them.
Thanks for looking at this.

Got it. Let me know if it works

This is working exactly as expected. Thank you for the quick fix. When using librespot-java with forked-daapd, the controls are really responsive.
I will close the ticket.

authors: aleszczynskig devgianlu

repo: librespot-org/librespot-java


text:
adds some tests to CORS functionality

depends on #190
relates to #188
@spocon I could not let that go, without tests ;)
Tests are not that difficult.

clever move with the CorsHandler. I had the problem with merging RoutingHandler and the HttpHandler with Origin config. I believe that works. Good work


text:
cmake: build .m files as objective-c

Attempt to address https://github.com/libsdl-org/sdl2-compat/pull/9#issuecomment-1331528664
After this pr, .m sources should be explicitly compiled with -x objective-c.

Let's rebase this to current master so that it goes through CI runs.

Looking good. No issues in CI runs either. This is in.

authors: madebr sezero

license: Zlib


text:
Struct fields

Make internal struct fields private and no accessible externally except throught the right functions.

See branch v2

repo: libsv/go-bt

license: ISC


text:
unix,win: harmonize buffer checking

For any API that takes a buffer and size pointer, check both pointers and the pointed-to size and return UV_EINVAL in case of error.
Example:
int uv_foo(char* buffer, size_t* size) {
  if (buffer == NULL || size == NULL || *size == 0)
    return UV_EINVAL;
  ...
}

In order to "peek" the necessary size for dynamic allocation, the following pattern can be used:
char *buf;
char scratch[1];
size_t len = sizeof(scratch);
int r;
r = uv_foo(scratch, &len);
assert(r == UV_ENOBUFS);
buf = malloc(len);
r = uv_foo(buf, &len);
...

LGTM but for your consideration: we could also make a NULL buffer and a non-NULL size pointer mean: "tell me how much I, the caller, should allocate"

I considered it! But upon closer inspection that pattern would require us to change how almost all functions following the pattern do it, and most were already checking for a NULL buffer and returning an error, so this felt like a better change :-)

@libuv/collaborators can I haz an extra pair of eyeballs?

repo: libuv/libuv


text:
Memory leak when using {{create-ref}}

Something is leaking when using {{create-ref}}. When running a memory snapshot after running tests I see an application hanging around. I was able to pinpoint it to this addon and {{create-ref}} usage.

The way I use it (source):
<span {{create-ref "FavouriteNode"}}>Lorem ipsum</span>

Steps to reproduce:

I created a minimal repo for reproduction. Please clone it -> https://github.com/tniezurawski/ember-ref-bucket-memory-leak

The repo is bare-bone. All I did was:

creating a new Ember app
adding ember-ref-bucket
creating a test component (you can check there's no leak at this point)
adding {{create-ref}} to that component

Run tests with this command: ember test -s -f "Integration | Component | tomek-test". No more tests there but you'll be sure that you are running only the one.
Open Chrome devtools > Open Memory > click "Take snapshot"
Search for "Container" as this indicates an application instance hanging around
Select "Container" as on the screenshot and look at "Retainers". You'll find references to this addon

I didn't check yet why this is happening as I don't have knowledge about internals but I hope we can get it fixed together :)

Hey @tniezurawski! Thank you for report! Likely it's related to global ref workaround https://github.com/lifeart/ember-ref-bucket/blob/master/addon/utils/ref.js#L17
there is no cleanup logic for it. We could try to register app destructor to null this ref

@tniezurawski we have global ref for few cases:

If there is no context on template.
If we need to have access to DOM element from different parts of application.

Ideally, we need to set globalRef in application initializer (once), and create application level destructor to null it once application destroyed.
But, I don't remember why we don't have it in app instance initializer.. (maybe I'm lazy ass to write it initially).
That's why we set it in modifier, because once anybody use this addon, modifier will exist anyway.
Proposed fix looks good (binding cleanup to modifier cleanup, but may have side effects with multiple modifiers - first removed will null global ref and may cause runtime erros)
We could try do few things:

register destructor inside modifier, but binded to app instance (getOwner(this)).
implement app-initializer flow to register / remove globalRef

authors: lifeart tniezurawski

repo: lifeart/ember-ref-bucket


text:
Any output by diff tool will cause build failure

@gamerson lmk what you think

Closing see comments, thanks!

authors: gamerson lawrence-lee

repo: liferay/liferay-blade-samples


text:
Don't depend on num's default features; removing rand requirement

requirement for rand comes from num's default features which are all unused in chrono
not including the default features means that that build no longer requires rand (and hence does not pass it on to others importing chrono)
Not quite sure why cargo test still wants rand, but it's to do with the serde_json dev-dependency

Good observation. I never thought that Chrono transitively depends on rand until this point. Thank you for the PR!

authors: dten lifthrasiir

repo: lifthrasiir/rust-chrono


text:
项目里经常textview placehoder处理，字数限制，UITextField字数限制

期待field的作品，项目里试用FSTextView，有问题第一时间提交issue

storyboard中生成textview没效果，不解

你设置了Class为FSTextView了吗 ?

@lifution 设置了，在你demo上直接从xib sb中生成也不行，我给textview设置了背景色，填 fstextview背景色都没了

@songxing10000 已经修复了, 刚更新, 你重新下载替换一下就行.

@songxing10000 现在可以使用CocoaPods的方式引入FSTextView了, 你可以看看项目下的说明.😁

@lifution 期待textField

很完美，右下角那个输入剩余提示，有时还是有需要的，可以考虑加入此功能，默认不显示，有需求时设置成YES，即可显示

@songxing10000 谢谢你的建议, 到时候会加入这个提示.

请问下载swift中怎么纯代码使用
let textView = FSTextView(frame: CGRect(x: 0, y: self.navIV.bottom, width: screen_width, height: 200))
self.view.addSubview(textView)
这样返回的是空
正确怎么使用？？

@kuangtao22 你确定是nil而不是在UI上没看到吗 ? 你设置个背景色看看, 因为默认的背景色是白色的, 你这样初始化后没有做任何的设置, 所以看到的效果就是一片空白.

repo: lifution/FSTextView


text:
Add names to SudokuDetailProcessors + first stab at docs

Sudoko detail processors (actors) didn't have custom names: added them.
Started updating exercise READMEs

LGTM

authors: eloots henrikengstrom

repo: lightbend/Pi-Akka-Cluster


text:
Tag Support

I use tags a lot so really hope you would support tags in case sonarr support is added. rn I use mediarr for sonarr but it does not support tags so really hope you support it.
Also is this supported in exclude?
'"animation" in Genres || "anime" in Genres'

I think I can add new filtering options, I will check what can we add

Tag support would indeed be useful to have. Thanks

Actually we already support Genre and Language in the rules. They are both a list of tags based on the OMDB information.
And you can use it like:
'"Comedy" in Genre && "Animation" not in Genre'

The case is the same for Language
'"English" in Language

Actually we already support Genre and Language in the rules. They are both a list of tags based on the OMDB information. And you can use it like:
'"Comedy" in Genre && "Animation" not in Genre'

The case is the same for Language
'"English" in Language

Nice to know. Is there a complete listing of syntax and options? I don’t see a mention of this in the readme  and now I’m wondering what else I’m missing and unaware of. Thanks!

The syntax to use for rules is in the documentation of the engine that we use: github.com/antonmedv/expr
The variables that you can use are in the ListItem definition: https://github.com/lightglitch/seekerr/blob/1c189faf0d86d5e36fefc777d1a8f4a692a5df4f/provider/provider.go#L46
Don't know if this a bit to technical for you but I can improve the docs later.

authors: hackmonker lightglitch neo-neo1

repo: lightglitch/seekerr


text:
Only shows loading screen

I tried to run this, and used a TMDB api key too, but all I get is this - no errors in the console, just that loading screen
Any suggestions?

hey @bradparks I can see how you may have gotten confused by the eternal loading screen 😄
Hopefully the extra explanation in the readme and first screen from PR #3 will avoid this in the future!
Closing this ticket as merged to master.

authors: bradparks michielvandergeest

repo: lightning-js/blits-example-app


text:
Payment Retries

Add a Payment Retries section to Sending Payments.
Includes new InvoicePayer API that retires payments as paths fail.
Released v0.0.103.0
Pull Request

Looks like we also need to update both tutorials to use InvoicePayer similarly to how it's used in the sample.
https://github.com/lightningdevkit/ldk-sample/pull/40

Something Jeff said that I thought would be good to include in our docs:
"Just for clarification there are two things that may be getting conflated here: the scorer and the retrier. The scorer is used when finding a route and when getting events from successful and failed paths. The retrier consumes those events by telling the scorer that a path has failed or succeeded and then retries by querying for a (potentially new) path with the updated scorer. LDK users can use the LDK scorer and their own retry logic, the latter of which delegates to the scorer just as our retrier is doing."

authors: ConorOkus jkczyz moneyball


text:
ListBalances command returns incorrect output when importing duplicate proofs

The state described in https://github.com/lightninglabs/taro/issues/258 created from importing proofs duplicate times seems to also impact the asset_balances command. These balances are in excess of the total supply of both of these assets (21000000 each)
{
    "asset_balances": {
        "3e054532a6a869e75e1bde8a25e7944177d648a034fe5c148ab7f7743538cc9e": {
            "asset_genesis": {
                "genesis_point": "2b572baa90ab27552c7577a4992b048689af30b8549379be83a5b576e3ebc210:0",
                "name": "habibtaro_remote",
                "meta": "aGFiaWJ0YXJvLmNvbV9yZW1vdGU=",
                "asset_id": "kA8db7/36tAXrPlONdl1JI1tJMjVT9bSCi/s0FIOELk=",
                "output_index": 0,
                "genesis_bootstrap_info": "EMLr43a1pYO+eZNUuDCviYYEK5mkd3UsVSerkKorVysAAAAAEGhhYmlidGFyb19yZW1vdGUUaGFiaWJ0YXJvLmNvbV9yZW1vdGUAAAAAAA==",
                "version": 0
            },
            "asset_type": "NORMAL",
            "balance": "21000010"
        },
        "900f1d6fbff7ead017acf94e35d975248d6d24c8d54fd6d20a2fecd0520e10b9": {
            "asset_genesis": {
                "genesis_point": "3c5b0ca49b7bb003c80f2e738a13c33607a24f73c6c5782affe5a39a26fea8ef:1",
                "name": "habibtaro_local",
                "meta": "aGFiaWJ0YXJvLmNvbV9sb2NhbA==",
                "asset_id": "kA8db7/36tAXrPlONdl1JI1tJMjVT9bSCi/s0FIOELk=",
                "output_index": 0,
                "genesis_bootstrap_info": "76j+Jpqj5f8qeMXGc0+iBzbDE4pzLg/IA7B7m6QMWzwAAAABD2hhYmlidGFyb19sb2NhbBNoYWJpYnRhcm8uY29tX2xvY2FsAAAAAAA=",
                "version": 0
            },
            "asset_type": "NORMAL",
            "balance": "42000000"
        }
    },
    "asset_group_balances": {}
}

Thinking maybe I should consolidate this into 258, because I have also confused the utxos endpoint, which believes I control both outputs in a single taro tx:
{
    "managed_utxos": {
        "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:0": {
            "out_point": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:0",
            "amt_sat": "1000",
            "internal_key": "AnoaNXzWC+zV0PiCibsGv9s3fbSD299V3hw4Cs/7wphu",
            "taro_root": "iB/5setGzRpQNpAx0n5uLfoqfdJqgbdiddKGg3V5rqc=",
            "assets": [
                {
                    "version": 0,
                    "asset_genesis": {
                        "genesis_point": "2b572baa90ab27552c7577a4992b048689af30b8549379be83a5b576e3ebc210:0",
                        "name": "habibtaro_remote",
                        "meta": "aGFiaWJ0YXJvLmNvbV9yZW1vdGU=",
                        "asset_id": "PgVFMqaoaedeG96KJeeUQXfWSKA0/lwUirf3dDU4zJ4=",
                        "output_index": 0,
                        "genesis_bootstrap_info": "EMLr43a1pYO+eZNUuDCviYYEK5mkd3UsVSerkKorVysAAAAAEGhhYmlidGFyb19yZW1vdGUUaGFiaWJ0YXJvLmNvbV9yZW1vdGUAAAAAAA==",
                        "version": 0
                    },
                    "asset_type": "NORMAL",
                    "amount": "20999990",
                    "lock_time": 0,
                    "relative_lock_time": 0,
                    "script_version": 0,
                    "script_key": "AlfgTkdxtOBauSd85GrTuoO9qUWYreDTS2KIY1g9cMsj",
                    "asset_group": null,
                    "chain_anchor": {
                        "anchor_tx": "AgAAAAABAotUvaRjib4LIAdu+JHZhfKL09chEbykNqv8Wtf4ZjuFAQAAAAD/////i1S9pGOJvgsgB274kdmF8ovT1yERvKQ2q/xa1/hmO4UAAAAAAAAAAAAD6AMAAAAAAAAiUSA9IQPuVFvpjbeV1z4R/YY0s8C9ddkTNAJSC2HoHyHIregDAAAAAAAAIlEgUai+/8Zd3X7xelRG7HWkqk+aWMERe8R0VTxvNBXKbCY+zRMAAAAAACJRINqgGvK1f1IpAc/1nKQ2DiPaSkHWu0qknqmPtn2NIRvHAUBlGhmFAycyVnnN7vFCI4h26fRS3xbQDzqwVtbUudst1Zxiv/5WsajTzq/0QGcbyJCoG/eL7/obfCqbl+idWInBAUDzUTcJn5wvzDEoP7vkiVTKu4LKMPRyi800488/ygMl6nsKKgmnizlM+0cky4CPYcdWt8aXt4qE/Wl9O+8jENqqAAAAAA==",
                        "anchor_txid": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9",
                        "anchor_block_hash": "00000000000000033049394c9a659c276dd09ebd197803ebac5ca2691df81ea9",
                        "anchor_outpoint": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:0",
                        "internal_key": "AnoaNXzWC+zV0PiCibsGv9s3fbSD299V3hw4Cs/7wphu"
                    },
                    "prev_witnesses": []
                }
            ]
        },
        "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:1": {
            "out_point": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:1",
            "amt_sat": "1000",
            "internal_key": "A+riUffgTwRYogPwsYZf9qSPZu7VB09YbeMsTCO0eWIk",
            "taro_root": "V6ew3jt/75gTSkMcYiogPpsLpomkToLorsFsn7pCxv8=",
            "assets": [
                {
                    "version": 0,
                    "asset_genesis": {
                        "genesis_point": "2b572baa90ab27552c7577a4992b048689af30b8549379be83a5b576e3ebc210:0",
                        "name": "habibtaro_remote",
                        "meta": "aGFiaWJ0YXJvLmNvbV9yZW1vdGU=",
                        "asset_id": "PgVFMqaoaedeG96KJeeUQXfWSKA0/lwUirf3dDU4zJ4=",
                        "output_index": 0,
                        "genesis_bootstrap_info": "EMLr43a1pYO+eZNUuDCviYYEK5mkd3UsVSerkKorVysAAAAAEGhhYmlidGFyb19yZW1vdGUUaGFiaWJ0YXJvLmNvbV9yZW1vdGUAAAAAAA==",
                        "version": 0
                    },
                    "asset_type": "NORMAL",
                    "amount": "10",
                    "lock_time": 0,
                    "relative_lock_time": 0,
                    "script_version": 0,
                    "script_key": "Ao9XAROi+fc/XqUXTlcCVUi72pjQMj8F9bVr5vvjQMTu",
                    "asset_group": null,
                    "chain_anchor": {
                        "anchor_tx": "AgAAAAABAotUvaRjib4LIAdu+JHZhfKL09chEbykNqv8Wtf4ZjuFAQAAAAD/////i1S9pGOJvgsgB274kdmF8ovT1yERvKQ2q/xa1/hmO4UAAAAAAAAAAAAD6AMAAAAAAAAiUSA9IQPuVFvpjbeV1z4R/YY0s8C9ddkTNAJSC2HoHyHIregDAAAAAAAAIlEgUai+/8Zd3X7xelRG7HWkqk+aWMERe8R0VTxvNBXKbCY+zRMAAAAAACJRINqgGvK1f1IpAc/1nKQ2DiPaSkHWu0qknqmPtn2NIRvHAUBlGhmFAycyVnnN7vFCI4h26fRS3xbQDzqwVtbUudst1Zxiv/5WsajTzq/0QGcbyJCoG/eL7/obfCqbl+idWInBAUDzUTcJn5wvzDEoP7vkiVTKu4LKMPRyi800488/ygMl6nsKKgmnizlM+0cky4CPYcdWt8aXt4qE/Wl9O+8jENqqAAAAAA==",
                        "anchor_txid": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9",
                        "anchor_block_hash": "00000000000000033049394c9a659c276dd09ebd197803ebac5ca2691df81ea9",
                        "anchor_outpoint": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:1",
                        "internal_key": "A+riUffgTwRYogPwsYZf9qSPZu7VB09YbeMsTCO0eWIk"
                    },
                    "prev_witnesses": []
                },
                {
                    "version": 0,
                    "asset_genesis": {
                        "genesis_point": "2b572baa90ab27552c7577a4992b048689af30b8549379be83a5b576e3ebc210:0",
                        "name": "habibtaro_remote",
                        "meta": "aGFiaWJ0YXJvLmNvbV9yZW1vdGU=",
                        "asset_id": "PgVFMqaoaedeG96KJeeUQXfWSKA0/lwUirf3dDU4zJ4=",
                        "output_index": 0,
                        "genesis_bootstrap_info": "EMLr43a1pYO+eZNUuDCviYYEK5mkd3UsVSerkKorVysAAAAAEGhhYmlidGFyb19yZW1vdGUUaGFiaWJ0YXJvLmNvbV9yZW1vdGUAAAAAAA==",
                        "version": 0
                    },
                    "asset_type": "NORMAL",
                    "amount": "10",
                    "lock_time": 0,
                    "relative_lock_time": 0,
                    "script_version": 0,
                    "script_key": "Ao9XAROi+fc/XqUXTlcCVUi72pjQMj8F9bVr5vvjQMTu",
                    "asset_group": null,
                    "chain_anchor": {
                        "anchor_tx": "AgAAAAABAotUvaRjib4LIAdu+JHZhfKL09chEbykNqv8Wtf4ZjuFAQAAAAD/////i1S9pGOJvgsgB274kdmF8ovT1yERvKQ2q/xa1/hmO4UAAAAAAAAAAAAD6AMAAAAAAAAiUSA9IQPuVFvpjbeV1z4R/YY0s8C9ddkTNAJSC2HoHyHIregDAAAAAAAAIlEgUai+/8Zd3X7xelRG7HWkqk+aWMERe8R0VTxvNBXKbCY+zRMAAAAAACJRINqgGvK1f1IpAc/1nKQ2DiPaSkHWu0qknqmPtn2NIRvHAUBlGhmFAycyVnnN7vFCI4h26fRS3xbQDzqwVtbUudst1Zxiv/5WsajTzq/0QGcbyJCoG/eL7/obfCqbl+idWInBAUDzUTcJn5wvzDEoP7vkiVTKu4LKMPRyi800488/ygMl6nsKKgmnizlM+0cky4CPYcdWt8aXt4qE/Wl9O+8jENqqAAAAAA==",
                        "anchor_txid": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9",
                        "anchor_block_hash": "00000000000000033049394c9a659c276dd09ebd197803ebac5ca2691df81ea9",
                        "anchor_outpoint": "6ac3a0f55ab3370e689b4dffee511936a9550782be7a2d1eaf9566f39442a0e9:1",
                        "internal_key": "A+riUffgTwRYogPwsYZf9qSPZu7VB09YbeMsTCO0eWIk"
                    },
                    "prev_witnesses": []
                }
            ]
        },
        "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0:0": {
            "out_point": "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0:0",
            "amt_sat": "1000",
            "internal_key": "A79Pp4JcwLtdDPn1bWBmjtZnPr28StNUuxyh6e8N/Srl",
            "taro_root": "9Y2ZlI1RJiKtKVWP0SfMeRqkkJUOkjDdNFGdTOz32Pg=",
            "assets": [
                {
                    "version": 0,
                    "asset_genesis": {
                        "genesis_point": "3c5b0ca49b7bb003c80f2e738a13c33607a24f73c6c5782affe5a39a26fea8ef:1",
                        "name": "habibtaro_local",
                        "meta": "aGFiaWJ0YXJvLmNvbV9sb2NhbA==",
                        "asset_id": "kA8db7/36tAXrPlONdl1JI1tJMjVT9bSCi/s0FIOELk=",
                        "output_index": 0,
                        "genesis_bootstrap_info": "76j+Jpqj5f8qeMXGc0+iBzbDE4pzLg/IA7B7m6QMWzwAAAABD2hhYmlidGFyb19sb2NhbBNoYWJpYnRhcm8uY29tX2xvY2FsAAAAAAA=",
                        "version": 0
                    },
                    "asset_type": "NORMAL",
                    "amount": "21000000",
                    "lock_time": 0,
                    "relative_lock_time": 0,
                    "script_version": 0,
                    "script_key": "Al63R9lWMhzXudbqXi/DBB0FfIXFkqPvh4rcRX1xp31N",
                    "asset_group": null,
                    "chain_anchor": {
                        "anchor_tx": "AgAAAAABAe+o/iaao+X/KnjFxnNPogc2wxOKcy4PyAOwe5ukDFs8AQAAAAD/////AugDAAAAAAAAIlEgbRuT2OdIJF7lTREAw900QyKqHxNBnLqhgtVQSQ7jTiWda1cAAAAAACJRIKNcGBwG4HBZufdS/3bPVx2q2deJlq9oPvMWZ/96WA+JAUBlB0FKmKOyCW8PIoY2KoX3TpNeSSsh4OfPV9LT1d4XNOp06sQgV24TtGukXaXzp+5hysL0LOGFAFhXvRXtRl5eAAAAAA==",
                        "anchor_txid": "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0",
                        "anchor_block_hash": "0000000000000014e99eb54af9684c0b7396bb9e5652c8eeec32e93a9f837faa",
                        "anchor_outpoint": "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0:0",
                        "internal_key": "A79Pp4JcwLtdDPn1bWBmjtZnPr28StNUuxyh6e8N/Srl"
                    },
                    "prev_witnesses": []
                },
                {
                    "version": 0,
                    "asset_genesis": {
                        "genesis_point": "3c5b0ca49b7bb003c80f2e738a13c33607a24f73c6c5782affe5a39a26fea8ef:1",
                        "name": "habibtaro_local",
                        "meta": "aGFiaWJ0YXJvLmNvbV9sb2NhbA==",
                        "asset_id": "kA8db7/36tAXrPlONdl1JI1tJMjVT9bSCi/s0FIOELk=",
                        "output_index": 0,
                        "genesis_bootstrap_info": "76j+Jpqj5f8qeMXGc0+iBzbDE4pzLg/IA7B7m6QMWzwAAAABD2hhYmlidGFyb19sb2NhbBNoYWJpYnRhcm8uY29tX2xvY2FsAAAAAAA=",
                        "version": 0
                    },
                    "asset_type": "NORMAL",
                    "amount": "21000000",
                    "lock_time": 0,
                    "relative_lock_time": 0,
                    "script_version": 0,
                    "script_key": "Al63R9lWMhzXudbqXi/DBB0FfIXFkqPvh4rcRX1xp31N",
                    "asset_group": null,
                    "chain_anchor": {
                        "anchor_tx": "AgAAAAABAe+o/iaao+X/KnjFxnNPogc2wxOKcy4PyAOwe5ukDFs8AQAAAAD/////AugDAAAAAAAAIlEgbRuT2OdIJF7lTREAw900QyKqHxNBnLqhgtVQSQ7jTiWda1cAAAAAACJRIKNcGBwG4HBZufdS/3bPVx2q2deJlq9oPvMWZ/96WA+JAUBlB0FKmKOyCW8PIoY2KoX3TpNeSSsh4OfPV9LT1d4XNOp06sQgV24TtGukXaXzp+5hysL0LOGFAFhXvRXtRl5eAAAAAA==",
                        "anchor_txid": "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0",
                        "anchor_block_hash": "0000000000000014e99eb54af9684c0b7396bb9e5652c8eeec32e93a9f837faa",
                        "anchor_outpoint": "7eb4e6f92a0afc812df515efb05486bdeccb9c3c799a5d390cdca411f43f2bc0:0",
                        "internal_key": "A79Pp4JcwLtdDPn1bWBmjtZnPr28StNUuxyh6e8N/Srl"
                    },
                    "prev_witnesses": []
                }
            ]
        },
        "853b66f8d75afcab36a4bc1121d7d38bf285d991f86e07200bbe8963a4bd548b:0": {
            "out_point": "853b66f8d75afcab36a4bc1121d7d38bf285d991f86e07200bbe8963a4bd548b:0",
            "amt_sat": "1000",
            "internal_key": "A30ykpyTT6FlRxaNVkG5o8GTpDZs/evCPmYMwsU4TEbs",
            "taro_root": "geA/eUJn8/pYCWNYtdYLhqFhaCEI7qIv4XqZa095fWg=",
            "assets": []
        }
    }
}

Thanks for the report!
My read is that you performed a spend of 10 units and then imported the proof for the receiver? And also the minting proof later on?

Yes exactly!

Closing as tracked here now: https://github.com/lightninglabs/taproot-assets/issues/578
The existing ImportProofs call will be deprecated after that's fixed.

authors: Roasbeef habibitcoin jharveyb

repo: lightninglabs/taro


text:
[Feature request] Accepting or rejecting payments

When issuing an invoice, there should be a way for the recipient to finalize or reject the payment before finalising it automatically.
This is useful for example for a use-case of physical vending machine. The invoice is issued, the payment goes through up until the last step. The machine tries to dispose the product, but it detects a mechanical problem and wants to refuse the payment at the last moment, so the final decision is with the receiver of the payment to accept or reject the payment (but without affecting finality).

This is already possible through #2022  which needs special building, with invoicesrpc tag.
I haven't followed that one closely, but I see from other in progress PR's that there is ongoing work on redesigning it.

Thanks

authors: jooray vegardengen

repo: lightningnetwork/lnd


text:
"synced_to_chain": false when bitcoind and lnd are both at the most recent block

Background
lnd says it is not synced after bitcoind gets the next block, even though lnd reports it has reached the same block height as bitcoind.
Your environment

version of lnd: lnd version 0.13.1-beta commit=v0.13.1-beta
which operating system (uname -a on *Nix): Linux [redacted] 5.10.17-v7l+ [hash]1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux
version of btcd, bitcoind, or other backend: Bitcoin Core version v0.21.1
any other relevant environment details

Steps to reproduce
Start bitcoind
Start lnd
Wait a few moments for lnd to finish starting
At this point    "synced_to_chain": true
Wait for several minutes for a new block then check again
lncli getinfo
{
    "version": "0.13.1-beta commit=v0.13.1-beta",
    "commit_hash": "596fd90ef310cd7abbf2251edaae9ba4d5f8a689",
    "identity_pubkey": "02b6008aa463ab2eb16e533a74f8d29ef22429f458fff292b8bea50e6be5e5c4dc",
    "alias": "bluebean",
    "color": "#76f9ec",
    "num_pending_channels": 0,
    "num_active_channels": 0,
    "num_inactive_channels": 0,
    "num_peers": 6,
    "block_height": 692360,
    "block_hash": "00000000000000000012d3e4d31541b4eee3b5923ae68a2d046681d81640a075",
    "best_header_timestamp": "1627084819",
    "synced_to_chain": false,
    "synced_to_graph": false,
    "testnet": false,

bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 692360,
  "headers": 692360,
  "bestblockhash": "00000000000000000012d3e4d31541b4eee3b5923ae68a2d046681d81640a075",
  "difficulty": 13672594272814.14,
  "mediantime": 1627079409,
  "verificationprogress": 0.9999966648352485,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000001fc3894994ecde1939725cf8",
  "size_on_disk": 1921945361,
  "pruned": true,
  "pruneheight": 690692,
  "automatic_pruning": true,
  "prune_target_size": 2000683008,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": true,
      "height": 227931
    },

Expected behaviour
I would have thought it would say true as it seems lnd has caught up with the new block.
Actual behaviour
If I restart lnd then it says true, but then after a few minutes it switches to false and stays that way until I restart lnd.

See this issue where we're aggregating reports: https://github.com/lightningnetwork/lnd/issues/5132
Would be useful if you have logs of where things flip to "false", and if you see reports of "out of order" blocks in the logs or not. Also check that your bitcoind is configured properly: https://github.com/lightningnetwork/lnd/issues/5132

authors: Roasbeef raymondclowe


text:
Add tutorial for LOJ-1015 : Brush (I)

resolves #5
Checklist

[x] Add English tutorial
[ ] Add Bangla tutorial

You can add your name at the bottom with your Linkedin or Github profile.
Like this
Tutorial created by [AUTHOR_NAME]
add the link to your social profile (if you want) as a hyperlink on your name.

repo: lightoj-dev/problem-tutorials


text:
Allow full-cross-versioning with :::

Right now you can import java-style ivy dependencies:
import $plugin.$ivy.`org.scalamacros:paradise:2.1.0`

And Scala-style dependencies:
import $plugin.$ivy.`org.scalamacros::paradise:2.1.0`

Where the :: automatically appends the scala binary version, e.g. _2.12, to the name of the artifact. However, in some cases we really want to append the scala full version, e.g. _2.12.2, to the name of the artifact. This can be done now manually:
import $plugin.$ivy.`org.scalamacros:paradise_2.12.2:2.1.0`

But it would be nice to have a ::: syntax to handle this common use case for us:
import $plugin.$ivy.`org.scalamacros:::paradise:2.1.0`

Fixed in #637

repo: lihaoyi/Ammonite


text:
[iOS] Prevent the zoomed view from overlaying status bar

Is your feature request related to a problem? Please describe.
Prevent the zoom view from overlaying status bar
Describe the solution you'd like
We can have a prop that shouldOverlayStatusbar
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
On iOS when zooming the image, the image goes over the status bar

Overflow hidden

@likashefqet I added overflow: hidden on the container and it fixed the issue. Thanks!
      <View className="flex-1 justify-center items-center bg-app-blue-100 overflow-hidden">
        <StyledImageZoom
          uri={url}
          className="w-full h-full"
          resizeMode="contain"
          isDoubleTapEnabled
        />
      </View>

authors: badalsaibo likashefqet

repo: likashefqet/react-native-image-zoom


text:
Cannot run "arch=aarch64" on Intel Mac

I tried on both latest Catalina and Big Sur on Intel Macs to run Lima with an ARM image. The only changes I made in the config YAML was setting arch="aarch64" and cpus=1. It starts off like this:

But then the screen blanks and nothing further seems to be happening (there is still a lot of CPU usage in the qemu process though):

In desperation I tried to set legacyBIOS=true, but that didn't work at all.
Is this working for anybody else?

ARM on Intel is very slow.
Ctrl-Alt-2 may show some progress.

ARM on Intel is very slow.

Indeed. Even slower than I expected. 😄

Ctrl-Alt-2 may show some progress.

Ctrl-Alt-3 does show the progress. It is easier to keep waiting when you see "something" is still moving then when you are just listening to the fans spinning up and watching a black screen...
I wonder if Intel on ARM is similarly slow, but I don't have a machine yet to test.

I'm having this issue on Intel Mac. Am I doing something wrong?
limactl start ubuntu.yaml ? Creating an instance "ubuntu" Proceed with the default configuration INFO[0001] Downloading "https://github.com/containerd/nerdctl/releases/download/v0.11.1/nerdctl-full-0.11.1-linux-amd64.tar.gz" (sha256:ce7a6e119b03c3fb8ded3d46d929962fd17417bea1d5bbc07e0fce49494d8a09) INFO[0001] Using cache "/Users/bhenkel/Library/Caches/lima/download/by-url-sha256/3304d173f1e1824e5be6cf84bf2f78825cf0db416c4c975dbb2458776942629e/data" FATA[0002] failed to download the image, attempted 1 candidates, errors=[unsupported arch: "aarch64"]
Here's my ubuntu.yaml
`images:
Hint: run limactl prune to invalidate the "current" cache

location: "https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-arm64.img"
arch: "aarch64"
mounts:
location: "~"
writable: false
location: "/tmp/lima"
writable: true
ssh:

localPort is changed from 60022 to avoid conflicting with the default.
(TODO: assign localPort automatically)
localPort: 60028`

I wonder if Intel on ARM is similarly slow, but I don't have a machine yet to test.

It is very slow. On Mac M1, I am running x86_84 & arm64 VMs with just top & k3s. It slower by ~6x.

If you haven't see it yet, please check out https://github.com/lima-vm/lima/blob/master/docs/multi-arch.md#fast-mode-intel-containers-on-arm-vm-on-arm-host--arm-containers-on-intel-vm-on-intel-host for a way to just run the containers in the foreign arch, but the OS itself at native speed!

Thanks, @jandubois for the fast mode tip. In fast mode, VMs are twice as fast as normal mode.

authors: AkihiroSuda ChillarAnand bobhenkel jandubois

repo: lima-vm/lima


text:
Document use of JNDI under Wildfly

Wildfly has a very strict classloading. As a result, traditional JDBC properties cannot be used - the database driver wouldn't be loaded.
Therefore, it is necessary to create JNDI resource and use spring.datasource.jndi-name instead of the other spring.datasource.* properties.

Fixed.

repo: lime-company/lime-security-powerauth


text:
qml: minimap

Love it or hate it, it should be there.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1379640-qml-minimap?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).

Migrated to limetext/lime-qml#11.

authors: erbridge quarnster

repo: limetext/lime


text:
Ability to disable the main redirecting interface

The API user should be allowed to disable the main redirecting interface, possible reasons are:

The user only wants to use the exposed API (custom frontend implementation)
Security purposes

I just noticed that it's already implemented.
https://github.com/linda-project/linda/blob/61b61552fd58b067e8a1b5b12ac4338a61706df2/src/main/kotlin/dev/d1s/linda/controller/impl/BaseInterfaceControllerImpl.kt#L36

repo: linda-project/linda


text:
More sensible default DistributionStatisticConfig for Timer and Distr…

…ibutionSummary
Related: https://github.com/micrometer-metrics/micrometer/commit/ef2dad5bd5542c6f88c02f11c6df93ebabe02e7c#diff-a428c30af987802231f5617fea57ea4dR38
Motivation:
Micrometer folks changed the default DistributionStatisticConfig in
Micrometer 1.0.3. Our users observed unexpectedly reduced accuracy in
their percentile values.
Modification:

Define all properties related with percentile histograms so that our
users are not surprised.

Result:

Less surprises

Note: The values in this PR is not final. I'd like to listen to your preferences and choose the most sensible one. What percentilePrecision, bufferLength and expiry would you expect as a sensible default? /cc @imasahiro @taicki @huydx @anuraaga @jwills

nits: How about added your comment at the Why? section to the code itself? @trustin

authors: huydx trustin

repo: line/armeria


text:
Add Flags SPI

Motivation:
As described in https://github.com/line/armeria/issues/4093,
We'd like to provide a way to programmatically configure Flags via SPI.
Modifications:

Add new interface FlagsProvider SPI interface to let user specify flags programmatically with priority.
Move default values from Flags to a new class DefaultFlagsProvider which have the lowest priority.
Move JVM option values provider logic from Flags to a new class SystemPropertyFlagsProvider which have the highest priority.
Redesign Flags logic to get flags values in below order.

SystemPropertyFlagsProvider -> [sorted by priority] Custom1FlagsProvider -> Custom2FlagsProvider ... -> DefaultFlagsProvider
if (JVM is provided && It pass on validation) {
    -> use supplied JVM option
}
-> use default value

to
foreach (SystemPropertyFlagsProvider + SPI interface Providers) {
  if (flag is provided && It passes on validation) {
      -> use the value
}
-> use default value from DefaultFlagsProvider

Result:

Closes #4093
You can now supply Flags value using FlagsProvider.

public final class CustomFlagsProvider implements FlagsProvider {

    @Override
    public int priority() {
        return 100;
    }

    @Override
    public int numCommonBlockingTaskThreads() {
        return 100;
    }
    ...
}

What if we have a priority field in FlagsProvider

+1 I love the suggestion. To be honest, I had thought of a similar idea. 😄

I like the suggestion. I'll implement as suggested. Thanks 🙏

@klurpicolo Would you mind checking out the build failures? If you find it difficult to resolve, feel free to ask us.

@jrhee17 Thanks! I'll address lint issue and @ikhoon 's comment.
@ikhoon No, I'll try to fix it. If I can't I'll comeback for help. Thank you for offering. 🙏

Sorry for the conflict. We added a new boolean flag called reportMaskedRoutes in #4086.

Thanks a lot for quick follow-up! Did a little bit more clean-up. I'll merge this in as soon as build passes.

Thanks all reviewers 🙏

authors: ikhoon klurpicolo trustin


text:
Revamp DocService construction and add example request support

Motivation:

Construction of a DocService is not convenient enough when a user
wants to specify examples. We need a builder.
We remove example request support while we split armeria-thrift from
the core. We should bring it back.

Modifications:

Rename ServiceSpecificationGenerator to DocServicePlugin
Add a few more methods needed for the example request support to
DocServicePlugin

Add ServiceExamples interface that provides the specified examples
to DocServicePlugins

Add DocServiceBuilder
Replace FunctionInfo.sampleJsonRequest with exampleRequests which is a
List of Strings
Update 'armeria.js' to handle 'exampleRequests' properly

Result:

More convenient to construct a DocService
Example request support is back.

/cc @imasahiro who may be interested as well

Pushed my WIP #423 in case it provides any context on where there may be areas to simplify plugin writing.

@anuraaga Thanks! I will take a look. Could you also see if the new interface fits well to GRPC?

One thing I didn't like about DocService is that its notion of 'service name' is confusing. I think it would make more sense to use a service path (exact path for Thrift and path prefix for GRPC). However, touching this is gonna trigger another batch of refactoring, so I didn't go that far yet. WDYT?

The interface generally LGTM
Since this is mostly about documentation, I think "service name" is a good concept. Most people talk about RPC in terms of some service name (AuthService, MetricsService or whatever) so making it the top-level term seems to fit with what people would expect - you wouldn't talk about '/api/auth' with a co-worker, you'd say AuthService I think :)
The path that the service is mounted to is a very important implementation detail, which we show in EndpointInfo, and this seems pretty accurate to me - the same service can be mounted on multiple paths, but it's still one service with a service name, and with the same documentation.

@anuraaga The front-end does not work yet, but I think the refactoring is pretty much done. It should be much easier to build ServiceSpecification because you do not need to carry docstrings and examples anymore; DocService will inject them for you. I'll update the front-end as well once your review is done and we are sure no significant change will follow.
I also left a few fixmes and todos which need to be addressed later, which might interest you.
@taicki Heavy refactoring has been done, but it is basically same from your point. You can specify your examples like this:
DocService docService = new DocServiceBuilder()
        .exampleHttpHeaders(HttpHeaders.of()....)
        .exampleRequest(new MyRequest_args(...))
        .build();

@anuraaga I added ServiceSpecification.generate() method which simplifies the typical NamedTypeInfo generation workflow.
@taicki Client-side code has been updated. Ready for a review.

authors: anuraaga trustin


text:
Add circuit breaker service

Motivation:
Create a service breaker service to decorate services to allow them fail fast.
I am particularly interested in doing this as we had an incident regarding a misconfiguration in one of our services and a fail-fast service could have minimized the impact on our side (Unfortunately our biggest API consumer doesn't use Armeria clients). We will implement this fail-fast anyway and I like the idea of having this at service layer and not depend on clients or the service proxy. (And give back to community)
Modifications:

[x] Add CircuitBreakerService and CircuitBreakerRpcService.
[x] Add default on success and failure mapping function to service. **Note: ** Might want to use CircuitBreakerClientHandler instead of adding new handlers like ThrottlingService.
[ ] Allow defining rules by usingCircuitBreakerRule.
[ ] Allow defining content rules by using CircuitBreakerRuleWithContent
[ ] Add per path, per endpoint options by using CircuitBreakerMapping.
[ ] Callbacks, maybe?

Some doubtful ideas:

Move generic CircuitBreaker... stuff out of client folder and move them to common.
Refactor CircuitBreaker... stuff to take RequestContext and specialize it into two components for client and service.

Result:

Closes #3721

Seems like CircuitBreakerRule and other descendants are highly coupled with ClientRequestContext. Does it make sense to move them under client package to common package and refactor all ClientRequestContext to be RequestContext and provide a generic interfaces such as CircuitBreakerClientRule, CircuitBreakerServiceRule? In this sense, users can either write generic CircuitBreakerRules that apply to both client and service or they can use one of the two classes.
A similar change is needed for everything that uses CircuitBreakerRule.
It is gonna be a pretty huge change so just double checking. cc: @ikhoon as original issue reporter.

Are there any recommendations? Should we decide on whether to move the existing circuit breaker out of its client package or not? Please let me know.

Quickly checked the implementation of CircuitBreakerRule. It seems we can reuse  CircuitBreakerRule for the server side without major changes. I prefer moving CircuitBreakerRule to common and replacing ClientRequestContext with RequestContext.
As I said on https://github.com/line/armeria/issues/3721#issuecomment-1651203715, breaking changes should be avoided during the migration. Please properly deprecate the APIs in the client package if necessary.

Quickly checked the implementation of CircuitBreakerRule. It seems we can reuse CircuitBreakerRule for the server side without major changes. I prefer moving CircuitBreakerRule to common and replacing ClientRequestContext with RequestContext.
As I said on #3721 (comment), breaking changes should be avoided during the migration. Please properly deprecate the APIs in the client package if necessary.

Seems like we need to deprecate modify around 60+ classes. Even the AbstractRule is based on ClientRequestContext rather than the generic ClientRequestContext. Just double checking if the direction I am heading towards is do-able and feasible on your end? 😓

I am worried this would be a pretty huge change to re-use the existing circuit breaker logic. There is a lot of coupling between Client logic and circuit breakers.
What do you think @ikhoon ? Is it going to worth the effort? I think we should either re-write or duplicate the code. Trying to be backwards compatible looks super tough.

It looks tough, but I think, migrating circuit breaker APIs to common packages is a better choice rather than duplication.
Sorry. You would find it difficult to move many classes while avoiding breaking changes. If you want, I am willing to handle the migration first. You can continue this work when the work is done.

It looks tough, but I think, migrating circuit breaker APIs to common packages is a better choice rather than duplication.
Sorry. You would find it difficult to move many classes while avoiding breaking changes. If you want, I am willing to handle the migration first. You can continue this work when the work is done.

That sounds amazing. I am happy to hear moving to common will be a better approach. Will wait for it 😄

Created #5217 for that.

Eh, I think there is just a lot of changes going on around here. I am not sure if it is worth trying to maintain this PR. LMK how do you feel about just closing this one and re-starting new one when there is time to work on it.
I also have almost no idea how we can do such a huge refactoring without introducing breaking changes in code 🙁

I'm fine with leaving this open because it would still be worth keeping the discussions we had in this PR, which would be easily forgotten once it's closed.

authors: Dogacel ikhoon trustin


text:
Fix to correctly leave Gradle build scan results as a comment

Motivation:
A pull request number fails to get retrieved from a commit SHA of a PR. Interestingly, it was not a problem while testing the feature in the personal repo. Because that happens only when the commit is made from a forked repository.
For example, the PR information of https://github.com/line/armeria/pull/4972/commits/529961c4a43fb884cf780421218de4f56f1aafcc is retrieved by https://api.github.com/repos/minwoox/armeria/commits/529961c4a43fb884cf780421218de4f56f1aafcc/pulls but https://api.github.com/repos/line/armeria/commits/529961c4a43fb884cf780421218de4f56f1aafcc/pulls returns an empty array. Note that the owners of the repository are different.
As a result, the scan results are not updated as a comment of a PR. https://github.com/line/armeria/blob/0cd7094b763e6c501b08e2cd44bb1835eaa46eea/.github/workflows/gradle-build-scan.yml#L90-L90
Modifications:

Prepend a pull request number to the artifact names of scan results.
Remove get-pr-number-by-sha.ts and its dependencies

Result:
Correctly update build scan results.

Let me merge this PR because the changes are clear and only CI workflows are modified.


text:
Collect partner apis one yml

other users do not use partner API. so it should collect the one yml file.

https://developers.line.biz/ja/reference/partner-docs/
collect above APIs.

This was considered in advance, and endpoints from different domains have been separated into different YAML files. Therefore, please leave it as is.
Additionally, similar to #56, this will be a breaking change, so let me close it.

repo: line/line-openapi