text:
Heroku compatible

Hi, I did some fix to add Heroku compatibility support.
We'll can push lgtm service on Heroku and/or similar PaaS.
I've tested this on Heroku and it seems to work quite well.
How to put lgtmco/lgtm to Heroku
# move to lgtm repo
cd $GOPATH/github.com/lgtmco/lgtm

# create Heroku app
heroku create

# add database plugin (e.g. JawsDB for MySQL)
heroku addons:create jawsdb:kitefin

# upload config vars to Heroku as you like
heroku config:set DATABASE_DRIVER=mysql
heroku config:set DATABASE_DATASOURCE='user:pass@tcp(hostname:3306)/databasename?parseTime=true'
heroku config:set GITHUB_CLIENT=<github client token>
heroku config:set GITHUB_SECRET=<github secret token>
heroku config:set GITHUB_SCOPE='user:email,read:org,repo'
heroku config:set GITHUB_URL='https://github.com'

# build Docker image and push to Heroku Container Registry
heroku container:push web

# open browser
heroku open

What do you think? @bradrydzewski

Thanks for this, @uetchy. Your instructions worked like a charm!

source: gharchive/pull-request

authors: rzane uetchy

repo: lgtmco/lgtm

license_type: permissive

license_source: bigquery


text:
speed

hi, thanks for the nice library. I wrapped it for nim-lang thinking it would be faster than my naive library.
See timings here:
https://github.com/brentp/nim-cgranges
My library (here: https://github.com/brentp/nim-lapper) has horrible worst-case performance given some huge intervals, because it's just sorted by start, with knowledge of longest interval. But, it does seem to work well for most genomic data-types which often do not have huge intervals.
I wonder if you could see if a simple datastructure like the one in nim-lapper holds up in your timings. (Or if you see something wrong with my code that would result in slowing down cgranges-- I was surprised at the result).
current timings here: https://github.com/brentp/nim-cgranges#speed

I am not surprised. In javascript, the naive version (the one used in paftools.js) is also faster than the interval tree version. That is probably because binary search has a much tighter inner loop in comparison to interval tree. There is a price to pay for improving the worst case. A solution to this is to inspect the data before indexing and choose the index data structure accordingly.
You should also note that cgranges can be up to twice as slow given an interval spanning the whole chromosome. NCList or centered interval tree may be more robust to such an interval.
At the end of day, though, I think the performance of overlap query is good enough in practice. Other steps can be slower.

BTW, here is an interesting thread on the performance of overlap query: https://github.com/BioJulia/Bio.jl/issues/340. On testing, I would be interested in the speed on the test BEDs in the release page. I guess the best performance may vary a lot with inputs.

thanks for the thread. also linking this: https://www.biorxiv.org/content/10.1101/593657v1
for completeness.
I have already found a use-case where nim-cgranges is faster than nim-lapper due to large regions (your LCRs).
I had thought to implement interval splitting for large intervals in lapper with a pointer back to the original interval, but never got around to it.

When talking about AIList in README, I have cited the preprint. The test/3rd-party directory provides the link to the original AIList repo.
I have also done more comparisons to AIList using the test data from the preprint. On all of their datasets, AIList is 20-50% faster than cgranges and cgranges is faster than AITree and NCList. Nonetheless, AIList is not implemented as a library. It even hard codes chromosome names. AIList requires a lot of code refactoring or even reimplementation to be used as a library. The transition to a library will slow it down a little bit, too. All that being said, AIList is a very good algorithm, possibly the fastest overall.

I understand that all benchmarks will be incomplete - and I'm sure mine also are in a million ways I have not thought of - but your test does not use my (simple) Cython-optimizations and also mixes reading and queries, while my NCLS is meant to be an in-memory datastructure. I think the AIList benchmarks have the same downsides.
Note that I do not have any ego attached to NCLS, I did not invent it. I was just looking into different datastructures to optimize my pyranges library and I do not find the current benchmarks compelling enough to switch. But if someone in the future has the time to do tests on these as in-memory datastructures and found that one was significantly faster than the other, I would be happy to write a Cython-wrapper for it.

What do you mean by “mixes reading and queries”? What cython-optimizations are you referring to? Both AIList paper and this repo compare C/C++ implementations, having nothing to do with Cython.
In general, I think AIList, NCList, CITree, and IAITree are all fast enough. User operations are probably of similar speed. You don’t need to change the underlying algorithm behind pyranges. If it were me, I would focus on reducing dependencies.

Yes, agreed. Sorry, I was being unclear and this post was not necessary anyways.
"mixing reading and queries": The benchmarks read the data and query at the same time. For genomicranges-like datastructures, this is not applicable, as all the data are in-memory.
The optimization I alluded to: when doing many queries at once with the NCList API you can malloc and free the IntervalIterator once, instead of once per query. This will presumably save some time (https://github.com/lh3/cgranges/blob/master/test/3rd-party/NCList/intervaldb.c#L630).
But I agree, all are so fast it is not really important. And thanks to your blog post I did start reducing dependencies (moved all code requiring FTP/mysql-libraries into their own package etc.). Looking forward to hearing you speak at Genome Informatics.

Thanks for the clarification.

"mixing reading and queries": The benchmarks read the data and query at the same time. For genomicranges-like data structures, this is not applicable, as all the data are in-memory.

In a lot of cases, the number of queries is too huge to be loaded into memory –– think about a short-read BAM. Reading and query at the same time is also a common pattern. With good APIs, streaming should be as fast as preloading all intervals.

The optimization I alluded to: when doing many queries at once with the NCList API you can malloc and free the IntervalIterator once, instead of once per query. This will presumably save some time

Yes, it does save time, but the effect is probably minor. Repeatedly mallocing a small chunk in a single thread is fairly fast.

source: gharchive/issue

authors: brentp endrebak lh3

license: MIT

license_source: github-api


text:
使用全屏弹窗的时候,怎样可以让弹出的内容不包括状态栏呢?

使用全屏弹窗的时候,怎样可以让弹出的内容不包括状态栏呢?现在弹出来全屏的内容和顶部状态栏重叠了,我是这样按照官方的弹出来的.
private void show(){
String[] str={"条目1", "条目2", "条目3", "条目4", "条目5","条目1", "条目2", "条目3", "条目4", "条目5","条目1", "条目2", "条目3", "条目4", "条目5",
"条目1", "条目2", "条目3", "条目4", "条目5","条目1", "条目2", "条目3", "条目4", "条目5","条目1", "条目2", "条目3", "条目4", "条目5"};
new XPopup.Builder(Lingsierqi.this)
.autoDismiss(false)
.asBottomList("请选择一项", str,
new OnSelectListener() {
@Override
public void onSelect(int position, String text) {
ToastUtils.showShort("点击"+position);
show();
}
})
.show();
}

可以给全屏弹窗的布局添加marginTop或者paddingTop，记住，弹窗就是Activity的View而已，把它当做一个普通View

已经搞定了,谢谢

authors: li-xiaojun roybill

repo: li-xiaojun/XPopup


text:
doc: Add Git Commit Guidelines

Introduce a simple guidelines for Git commits to ensure clear and effective communication in the development process. The guidelines cover:

Ensuring code adheres to established coding standards.
Avoiding the mixing of multiple logical changes in one commit.
Prohibiting the introduction of new trailing white spaces.

Looks good!
I'd definitely suggest to reference the guidelines from the main README, e.g.,
## Contributing
Contributions are always welcome [...]

Please check out our [guidelines](doc/git-commit.md) before opening a Pull Request!

Also, maybe consider adding a link to one specific commit following the guidelines or include a full example in the docs.
Having a concrete example at hand definitely helped me :)

@IlievIliya92 Would you mind helping me how to link to a .md from REDME.md?

If I write [guidelines](doc/git-commit.md), it works when we read raw Markdown but it doesn't work on HTML
If I write [guidelines](/git-commit.md), it doesn't work on raw Markdown but it works on HTML.

@pr0me Do you have any good one for examples? I've picked a few but if you have one I'd love to add it.

@IlievIliya92 Would you mind helping me how to link to a .md from REDME.md?
* If I write `[guidelines](doc/git-commit.md)`, it works when we read raw Markdown but it doesn't work on HTML

* If I write `[guidelines](/git-commit.md)`, it doesn't work on raw Markdown but it works on HTML.

Hi Yashi,
If the file itself git-commmit.md resides whitin the root directory of the doccumentation (doc)
I think the correct syntax supported by both HTML and Md would be:
[guidelines](git-commit.md)

Sphinx will parse this line for HTML down to:
href="git-commit.html"

I hope this information was helpful to solve the issue.

Hi @IlievIliya92,
Thanks. But the problem is
libcsp
├── README.md
└── doc
     └── git-commit.md

As you can see README.md and git-commit.md are in different dirs

Hi @IlievIliya92, Thanks. But the problem is
libcsp
├── README.md
└── doc
     └── git-commit.md

As you can see README.md and git-commit.md are in different dirs

Since the contents of the README.md file are directly included into the index.md file.
I can suggest the following approach to solve this issue.

Add the link which is resolved properly for markdown.

README.md
[guidelines](./doc/git-commit.md) before opening a Pull Request!

Remove the include for the README.md, we are going to insert the contents of the file
using a Sphinx source-read hook.

doc/index.md
-```{eval-rst}
-.. include:: ../README.md
-   :parser: myst_parser.sphinx_
-```

Insert the contents of the README file

Here we are using the sources-read Sphinx core event to preprocess the index file and insert the contents of the README.md file with the modified link in it.
doc/conf.py
def include_readme_file(app, docname, source):
    """
        This hook reads the contents of the README.md file, replaces the
        link for `git-commit` and inserts the modified contents in the index.md
        file before the first occuarance of  ```{toctree}
    """
    if docname == 'index':
        # Read and modify the contents of README
        with open("../../README.md", "r") as file:
            readme_contents = file.read()

        # Here we change the link for the `git-commit` page
        readme_contents = readme_contents.replace("./doc/git-commit.md", "git-commit")

        # Find the index of the first occurrence of ```{toctree}
        toctree_index = source[0].find('```{toctree}')
        if toctree_index != -1:
            # Insert the modified README files
            source[0] = source[0][:toctree_index] + readme_contents + source[0][toctree_index:]

def setup(app):
    app.connect('source-read', include_readme_file)

This approach would allows us to use markdown syntax from the README.md file and modify them
before procesing the HTML docs.
Here is a patch with all the changes for the solution propoused above.
From d9173ddb1bdb850b19272bf5dfa7ba469ade04f5 Mon Sep 17 00:00:00 2001
From: Iliya Iliev <iliyailiev3592@gmail.com>
Date: Mon, 4 Mar 2024 12:53:36 +0200
Subject: [PATCH] doc: Add suport for .md and HTML links for README.md file

Signed-off-by: Iliya Iliev <iliyailiev3592@gmail.com>
---
 README.md    |  2 +-
 doc/conf.py  | 23 +++++++++++++++++++++++
 doc/index.md |  4 ----
 3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index c30e8d2..d2df55a 100644
--- a/README.md
+++ b/README.md
@@ -69,7 +69,7 @@ The latest version of the /doc folder is compiled to HTML and hosted on:
 Thank you for considering contributing to libcsp! We welcome
 contributions from the community to help improve and grow the
 project. Please take a moment to review our
-[guidelines](/git-commit.md) before opening a Pull Request!
+[guidelines](./doc/git-commit.md) before opening a Pull Request!

 ## Software license

diff --git a/doc/conf.py b/doc/conf.py
index d8b7f0b..e24f284 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -69,6 +69,29 @@ html_theme_options = {
     'sticky_navigation': True
 }

+def include_readme_file(app, docname, source):
+    """
+        This hook reads the contents of the README.md file, replaces the
+        link for `git-commit` and inserts the modified contents in the index.md
+        file before the first occuarance of  ```{toctree}
+    """
+    if docname == 'index':
+        # Read and modify the contents of README
+        with open("../../README.md", "r") as file:
+            readme_contents = file.read()
+
+        # Here we change the link for the `git-commit` page
+        readme_contents = readme_contents.replace("./doc/git-commit.md", "git-commit")
+
+        # Find the index of the first occurrence of ```{toctree}
+        toctree_index = source[0].find('```{toctree}')
+        if toctree_index != -1:
+            # Insert the modified README files
+            source[0] = source[0][:toctree_index] + readme_contents + source[0][toctree_index:]
+
+def setup(app):
+    app.connect('source-read', include_readme_file)
+
 version = pygit2.Repository('.').head.shorthand

 # Add any paths that contain custom static files (such as style sheets) here,
diff --git a/doc/index.md b/doc/index.md
index a0194a4..9272206 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -6,10 +6,6 @@ Disclaimer: You are reading the latest version of libcsp document from
 [the `develop` branch](https://github.com/libcsp/libcsp).  Currently,
 we only have this version in HTML format.

-```{eval-rst}
-.. include:: ../README.md
-   :parser: myst_parser.sphinx_
-```

 ```{toctree}
 :caption: Setup
--
2.34.1

@IlievIliya92, super thanks! It works like a charm. I've appended your commit on top of mine.

And now with a commit message

This PR now depends on #538.

repo: libcsp/libcsp

license: mit


text:
Error creating FrameBuffer in latest version

Issue details
The creation of a Framebuffer is failing in v1.9.14 in the lwjgl 2 backend. The same code works well in v1.9.13.
Digging in the changes, I think that error is produced by the next commit created by @mgsx-dev
https://github.com/libgdx/libgdx/commit/1cfb4a8b5b6fdd8275ef7962a107f6b81166865b
Reproduction steps/code
Try to create a Framebuffer:
		FrameBuffer fbo = new FrameBuffer(Format.RGB565, w, h, false);

Version of LibGDX and/or relevant dependencies
This only happens in v1.9.14.
Stacktrace
Exception in thread "LWJGL Application" org.lwjgl.opengl.OpenGLException: Cannot use offsets when Pixel Unpack Buffer Object is disabled
	at org.lwjgl.opengl.GLChecks.ensureUnpackPBOenabled(GLChecks.java:125)
	at org.lwjgl.opengl.GL11.glTexImage2D(GL11.java:2899)
	at com.badlogic.gdx.backends.lwjgl.LwjglGL20.glTexImage2D(LwjglGL20.java:598)
	at com.badlogic.gdx.graphics.glutils.GLOnlyTextureData.consumeCustomData(GLOnlyTextureData.java:78)
	at com.badlogic.gdx.graphics.GLTexture.uploadImageData(GLTexture.java:270)
	at com.badlogic.gdx.graphics.GLTexture.uploadImageData(GLTexture.java:257)
	at com.badlogic.gdx.graphics.Texture.load(Texture.java:159)
	at com.badlogic.gdx.graphics.Texture.<init>(Texture.java:147)
	at com.badlogic.gdx.graphics.Texture.<init>(Texture.java:142)
	at com.badlogic.gdx.graphics.glutils.FrameBuffer.createTexture(FrameBuffer.java:81)
	at com.badlogic.gdx.graphics.glutils.FrameBuffer.createTexture(FrameBuffer.java:42)
	at com.badlogic.gdx.graphics.glutils.GLFrameBuffer.build(GLFrameBuffer.java:174)
	at com.badlogic.gdx.graphics.glutils.FrameBuffer.<init>(FrameBuffer.java:75)
	at com.badlogic.gdx.graphics.glutils.FrameBuffer.<init>(FrameBuffer.java:57)
	at com.bladecoder.engine.model.World.takeScreenshot(World.java:824)```

Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[X] Windows
[ ] Linux
[ ] MacOS

This has been fixed in the latest snapshot.

This has been fixed in the latest snapshot.

Which can be found where? All I could find is the latest version 1.9.14 of LibGDX which is strangely the non working version https://libgdx.com/dev/project-generation/ Where can I get the 1.9.15 SNAPSHOT or any other versions of the project creation tool?

You don't need to download a new project generator, just change the version in a generated project build.gradle file

Yeah, just change 1.9.14 to 1.9.15-SNAPSHOT in any place it appears in the topmost build.gradle . You will need to change it again shortly after 1.9.15 is released as stable, but that is just taking away the -SNAPSHOT part to leave 1.9.15.

Yeah, just change 1.9.14 to 1.9.15-SNAPSHOT in any place it appears in the topmost build.gradle . You will need to change it again shortly after 1.9.15 is released as stable, but that is just taking away the -SNAPSHOT part to leave 1.9.15.

Ok that fixed the errors. But it has the number 1.9.14 all kinds of other places in the project too - that doesn't matter?

The version typically isn't hard-coded anywhere but the assignment to gdxVersion in the root build.gradle, specifically so it's easier to upgrade. Extensions may also be version 1.9.14, and those should probably be updated too (probably in the same file). Where a version has a replacement-string like "com.badlogicgames.gdx:gdx-backend-lwjgl3:$gdxVersion", the $gdxVersion gets replaced by 1.9.14 or 1.9.15-SNAPSHOT or whatever else it is assigned to in build.gradle (or gradle.properties, an alternative location to set these properties). You may want to ask further questions on the Discord: https://discord.gg/8TC7H2v .

Hello, it seems like this issue appears in 1.10.0 again. Reverting to 1.9.15 still fixes it for me.

1.9.15 doesn't exist. 1.9.15-SNAPSHOT disappeared when 1.9.14's successor released, which turned out to be 1.10.0. Do you mean 1.9.13?

Hi, you're right, I was wondering about that too. But I actually did go from 1.10.0 to 1.9.15-SNAPSHOT and it fixed the issue.
I guess 1.9.15-SNAPSHOT automatically refers to something else now?
1.9.13 works as well, just tested it. But with 1.9.14 or 1.10.0 I get the error.
Statement is:
FrameBuffer fbo = new FrameBuffer(Format.RGBA8888, Gdx.graphics.getWidth(), Gdx.graphics.getHeight(), false);
I'm doing nothing else with that object, just creating it in the create() or any other method. Instantly crashes with the same error message as OP.
BR

I just tested this with 1.10.0, as you said, @Xjidea , by adding FrameBuffer fbo = new FrameBuffer(Pixmap.Format.RGBA8888, Gdx.graphics.getWidth(), Gdx.graphics.getHeight(), false); to the start of my create() method. There is no difference with that line in or out; both work fine. This is true for LWJGL 2 and 3. Check your dependencies for anything that might be pulling 1.9.14, which is the release that has the bug, and don't use snapshot releases after the following stable release is out, because the snapshot could cease to exist anytime. This bug is fixed, so any other issues are related to something else in your code, and should be discussed further in the Discord. Be prepared to paste relevant code, answer questions, etc. if you want your problem solved.

authors: Frosty-J JideaGit Tom-Ski bladecoder hasen6 tommyettinger

repo: libgdx/libgdx


text:
Fix Issue 2475 by packing the JFrame before setting visible.

On Linux systems, GDXSetup comes up as a blank window. Packing the JFrame before setting it visible resolves the issue. There are other issues (e.g., some labels don't correctly paint before initial mouse hover), and questions (e.g., why the explicit setSize()?), but those should probably be addressed in one or more other PRs.

This breaks the log, I'll fix it up and tweak the setup a little to see we can get better results on fedora.

authors: Sindisil Tom-Ski


text:
feat(photo-fetch): impl ui driven photo fetch

This PR implements a UI-driven API call to fetch a random photo and log its URL.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#25  👈
#24
#23
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @libhide and the rest of your teammates on  Graphite

Merge activity

Apr 13, 6:37 PM EDT: @libhide started a stack merge that includes this pull request via Graphite.

repo: libhide/uttam


text:
Cannot buid with -DJPEGXL_STATIC=ON for android

I followed the build steps described in this site:
http://blog.fpliu.com/project/ndk-pkg/package?name=libjxl
I modified the formula as this:
build() {
cmakew
-DJPEGXL_ENABLE_JNI=OFF
-DJPEGXL_ENABLE_TOOLS=OFF
-DJPEGXL_ENABLE_EXAMPLES=ON
-DJPEGXL_ENABLE_MANPAGES=ON
-DJPEGXL_ENABLE_BENCHMARK=OFF
-DJPEGXL_WARNINGS_AS_ERRORS=OFF
-DJPEGXL_FORCE_SYSTEM_BROTLI=ON
-DJPEGXL_VERSION=$PACKAGE_VERSION
-DZLIB_INCLUDE_DIR="$zlib_INCLUDE_DIR"
-DZLIB_LIBRARY_RELEASE="$zlib_LIBRARY_DIR/libz.a"
-DPNG_PNG_INCLUDE_DIR="$libpng_INCLUDE_DIR"
-DPNG_LIBRARY="$libpng_LIBRARY_DIR/libpng.a"
-DJPEG_INCLUDE_DIR="$libjpeg_turbo_INCLUDE_DIR"
-DJPEG_LIBRARY="$libjpeg_turbo_LIBRARY_DIR/libjpeg.a"
-DTIFF_INCLUDE_DIR="$libtiff_INCLUDE_DIR"
-DTIFF_LIBRARY="$libtiff_LIBRARY_DIR/libtiff.a"
-DGIF_INCLUDE_DIR="$giflib_INCLUDE_DIR"
-DGIF_LIBRARY="$giflib_LIBRARY_DIR/libgif.a"
-DJPEGXL_STATIC=ON
}
And got the error:
FAILED: encode_oneshot
: && /home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=armv7-none-linux-androideabi21 --sysroot=/home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot --sysroot /home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -Qunused-arguments -fpic -Wl,--dynamic-linker=/system/bin/linker -Wl,--strip-debug -Os -DNDEBUG -I/home/osboxes/.ndk-pkg/install.d/brotli/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/libwebp/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/libpng/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/libtiff/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/zstd/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/xz/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/libjpeg-turbo/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/giflib/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/openexr/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/imath/armeabi-v7a/include -I/home/osboxes/.ndk-pkg/install.d/zlib/armeabi-v7a/include --sysroot /home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -Qunused-arguments -I/home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/arm-linux-androideabi -include /tmp/tmp.Z14bZixPtv/1642154864/include.h -L/home/osboxes/.ndk-pkg/install.d/brotli/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libwebp/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libpng/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libtiff/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/zstd/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/xz/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libjpeg-turbo/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/giflib/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/openexr/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/imath/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/zlib/armeabi-v7a/lib --sysroot /home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -L/tmp/tmp.Z14bZixPtv/1642154864 -L/home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/arm-linux-androideabi/21 -Wl,--dynamic-linker=/system/bin/linker -Wl,--strip-debug -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer -O3 -DNDEBUG -O2 -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--fatal-warnings -Qunused-arguments -Wl,--no-undefined  -Wl,--gc-sections -L/home/osboxes/.ndk-pkg/install.d/brotli/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libwebp/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libpng/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libtiff/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/zstd/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/xz/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/libjpeg-turbo/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/giflib/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/openexr/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/imath/armeabi-v7a/lib -L/home/osboxes/.ndk-pkg/install.d/zlib/armeabi-v7a/lib --sysroot /home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot -L/tmp/tmp.Z14bZixPtv/1642154864 -L/home/osboxes/.ndk-pkg/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/arm-linux-androideabi/21 -Wl,--dynamic-linker=/system/bin/linker -Wl,--strip-debug -static -static-libgcc -static-libstdc++    -R/home/osboxes/.ndk-pkg/install.d/brotli/armeabi-v7a/lib -fPIE -pie CMakeFiles/encode_oneshot.dir/examples/encode_oneshot.cc.o -o encode_oneshot  lib/libjxl.a  lib/libjxl_threads.a  third_party/highway/libhwy.a  -Wl,--whole-archive  -lpthread  -Wl,--no-whole-archive   -static-libstdc++ -latomic -lm && :
ld: error: undefined symbol: BrotliEncoderCreateInstance

referenced by enc_jpeg_data.cc

          enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a

ld: error: undefined symbol: BrotliEncoderSetParameter

referenced by enc_jpeg_data.cc

          enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a

referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a

ld: error: undefined symbol: BrotliEncoderMaxCompressedSize

referenced by enc_jpeg_data.cc

          enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a

ld: error: undefined symbol: BrotliEncoderCompressStream

referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced 1 more times
ld: error: undefined symbol: BrotliEncoderHasMoreOutput
referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced by enc_jpeg_data.cc
enc_jpeg_data.cc.o:(jxl::jpeg::EncodeJPEGData(jxl::jpeg::JPEGData&, jxl::PaddedBytes*)) in archive lib/libjxl.a
referenced 1 more times
ld: error: undefined symbol: BrotliEncoderDestroyInstance

Is this still reproducible at the current main?

repo: libjxl/libjxl


text:
Incremental build for validator docker image

This diff changes build time from 40 to few minutes for incremental change, which is incredibly valuable during triage

@bors-libra r=kphfb
cc @sausagee I think this change should be safe for nightly build CI, but just in case letting you know its there

:pushpin: Commit 243f535 has been approved by kphfb

:hourglass: Testing commit 243f535e0c0b2ff2a3f23e64e516524ff4a3b609 with merge 78cebe8f79341d4b92bde932f6e77952eee29d42...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: kphfb
Pushing 78cebe8f79341d4b92bde932f6e77952eee29d42 to master...

@andll: This breaks CI, and is not the right way to do docker images (as was previously discussed a few months ago). Please revert this and we can discuss the options for this specific use case.

@sausagee fixed CI build.
What is specific concern you currently have?

CI is only fixed because it's using copies of the old docker files in libra-ops for now. It needs to be switched back and will break again at that point. My objections are the same as the last time this was discussed. Please revert and we can discuss how to approach this.

I agree we need to reuse same docker files in ci - will need to find a way to achieve that
Having incremental build was crucial in last investigation, I am not comfortable reverting this diff on the grounds of “this is not proper way of doing things” without having concrete solution to incremental build problem
On Oct 14, 2019, at 12:16 PM, Michael Gorven notifications@github.com wrote:

CI is only fixed because it's using copies of the old docker files in libra-ops for now. It needs to be switched back and will break again at that point. My objections are the same as the last time this was discussed. Please revert and we can discuss how to approach this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/libra/libra/pull/1296?email_source=notifications&email_token=AAWVVQK2C3ZUDD7BMVNLNLDQOTAPFA5CNFSM4I76VLAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBGDYMY#issuecomment-541867059, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAWVVQKAQ2YWSGRF6TZ6FI3QOTAPFANCNFSM4I76VLAA.

authors: andll bors-libra mgorven

repo: libra/libra


text:
[move source language] Added support for signer

Motivation

Added signer as a primitive resource type
Added move_to builtin
Added rules around transaction arguments
Blocked by #3913, so only look at the top commit

Test Plan

migrated tests

:umbrella: The latest upstream changes (presumably 75dcb5ae4d199f74493671f969b07a6772098103) made this pull request unmergeable. Please resolve the merge conflicts.

@bors-libra r=sblackshear

:pushpin: Commit 42a3e72 has been approved by sblackshear

:hourglass: Testing commit 42a3e727a198bbb7d55e2dbf60f1c1009285022e with merge fa91f1eb12b8470d830e47a810c93111cac93ac3...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=sblackshear

:pushpin: Commit aaad485 has been approved by sblackshear

:hourglass: Testing commit aaad48538aa9c44d9a81d7d9766c70cd85c41a73 with merge 89aa5588ccffa7643a676dfcf1e89194e427c236...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: sblackshear
Pushing 89aa5588ccffa7643a676dfcf1e89194e427c236 to master...

authors: bors-libra tnowacki


text:
Add device for Logitech G703 w Hero in Wireless mode

libratbag already have support for the G703 when connected with the wire, but not when used in wireless mode.
I have made a device file that made it work for me in wireless mode, however considering https://github.com/libratbag/libratbag/issues/805 my device file is not correct since I'm pointing it to the receiver and not the mouse. It does work however and piper even does a proper detection of the mouse so I guess that there have to be something else in the device file to let libratbag distinguish between this mouse and others using the same receiver, this https://github.com/libratbag/libratbag/issues/579 seems to indicate that it's something called WPID that is needed.
So if any one could let me know how to find what I should put where and we could add proper support for this mouse.
`[Device]
Name=Logitech G703 LIGHTSPEED Wireless Gaming Mouse w/ HERO
DeviceMatch=046d:c539
Driver=hidpp20
[Driver/hidpp20]
DeviceIndex=1
`

c539 is the ID of the receiver, we don't want that. The kernel driver exports a HID device with the actual device ID, that is what we want.
Which kernel are you running?

5.2 (the one from ubuntu 20.04)
Den lör 31 okt. 2020 15:32Filipe Laíns notifications@github.com skrev:

c539 is the ID of the receiver, we don't want that. The kernel driver
exports a HID device with the actual device ID, that is what we want.
Which kernel are you running?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libratbag/libratbag/issues/1088#issuecomment-719941920,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACM6IBVYJSV6VC4VOLFRZIDSNQNYLANCNFSM4TFUZQRQ
.

Can you post the output of dmesg | grep logitech?

henrik@ubuntu:~$ dmesg | grep logitech
[    2.228402] logitech-djreceiver 0003:046D:C539.0008: hidraw7: USB HID
v1.11 Keyboard [Logitech USB Receiver] on usb-0000:02:00.0-11/input0
[    2.288436] logitech-djreceiver 0003:046D:C539.000A: hiddev6,hidraw9:
USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:02:00.0-11/input2
[    2.350051] logitech-djreceiver 0003:046D:C539.000A: device of type
eQUAD Lightspeed 1 (0x0c) connected on slot 1
[    2.360403] logitech-djreceiver 0003:046D:C539.0009: hiddev5,hidraw8:
USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:02:00.0-11/input1
[    2.557577] logitech-hidpp-device 0003:046D:4086.000F: input,hidraw10:
USB HID v1.11 Keyboard [Logitech G703 LS] on usb-0000:02:00.0-11/input2:1
[   22.583683] logitech-hidpp-device 0003:046D:4086.000F: HID++ 4.2 device
connected.
henrik@ubuntu:~$
Den lör 31 okt. 2020 kl 17:07 skrev Filipe Laíns notifications@github.com:

Can you post the output of dmesg | grep logitech?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libratbag/libratbag/issues/1088#issuecomment-719953819,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACM6IBTHD7PHSKUO5W5IDFTSNQY3BANCNFSM4TFUZQRQ
.

So I changed to 046d:4086 and piper still works so this seems to be the
correct one to use. Never saw that one before since lsusb doesn't list it
Den lör 31 okt. 2020 kl 17:53 skrev Henrik Holst <
henrik.holst@millistream.com>:

henrik@ubuntu:~$ dmesg | grep logitech
[    2.228402] logitech-djreceiver 0003:046D:C539.0008: hidraw7: USB HID
v1.11 Keyboard [Logitech USB Receiver] on usb-0000:02:00.0-11/input0
[    2.288436] logitech-djreceiver 0003:046D:C539.000A: hiddev6,hidraw9:
USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:02:00.0-11/input2
[    2.350051] logitech-djreceiver 0003:046D:C539.000A: device of type
eQUAD Lightspeed 1 (0x0c) connected on slot 1
[    2.360403] logitech-djreceiver 0003:046D:C539.0009: hiddev5,hidraw8:
USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:02:00.0-11/input1
[    2.557577] logitech-hidpp-device 0003:046D:4086.000F: input,hidraw10:
USB HID v1.11 Keyboard [Logitech G703 LS] on usb-0000:02:00.0-11/input2:1
[   22.583683] logitech-hidpp-device 0003:046D:4086.000F: HID++ 4.2 device
connected.
henrik@ubuntu:~$
Den lör 31 okt. 2020 kl 17:07 skrev Filipe Laíns <notifications@github.com

:

Can you post the output of dmesg | grep logitech?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libratbag/libratbag/issues/1088#issuecomment-719953819,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACM6IBTHD7PHSKUO5W5IDFTSNQY3BANCNFSM4TFUZQRQ
.

which is strange since that is the value already used for the
/usr/share/libratbag/logitech-g703-hero.device and that didn't work
initially... But I removed my custom file and restarted ratbagd and piper
still works so that it didn't work initially must just have been a fluke,
sorry for bothering about this when it clearly works out of the box...
Den lör 31 okt. 2020 kl 17:56 skrev Henrik Holst <
henrik.holst@millistream.com>:

So I changed to 046d:4086 and piper still works so this seems to be the
correct one to use. Never saw that one before since lsusb doesn't list it
Den lör 31 okt. 2020 kl 17:53 skrev Henrik Holst <
henrik.holst@millistream.com>:

henrik@ubuntu:~$ dmesg | grep logitech
[    2.228402] logitech-djreceiver 0003:046D:C539.0008: hidraw7: USB HID
v1.11 Keyboard [Logitech USB Receiver] on usb-0000:02:00.0-11/input0
[    2.288436] logitech-djreceiver 0003:046D:C539.000A: hiddev6,hidraw9:
USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:02:00.0-11/input2
[    2.350051] logitech-djreceiver 0003:046D:C539.000A: device of type
eQUAD Lightspeed 1 (0x0c) connected on slot 1
[    2.360403] logitech-djreceiver 0003:046D:C539.0009: hiddev5,hidraw8:
USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:02:00.0-11/input1
[    2.557577] logitech-hidpp-device 0003:046D:4086.000F: input,hidraw10:
USB HID v1.11 Keyboard [Logitech G703 LS] on usb-0000:02:00.0-11/input2:1
[   22.583683] logitech-hidpp-device 0003:046D:4086.000F: HID++ 4.2
device connected.
henrik@ubuntu:~$
Den lör 31 okt. 2020 kl 17:07 skrev Filipe Laíns <
notifications@github.com>:

Can you post the output of dmesg | grep logitech?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/libratbag/libratbag/issues/1088#issuecomment-719953819,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACM6IBTHD7PHSKUO5W5IDFTSNQY3BANCNFSM4TFUZQRQ
.

That ID should already be enabled, not sure why it wasn't working.
https://github.com/libratbag/libratbag/blob/master/data/devices/logitech-g703-hero.device

repo: libratbag/libratbag


text:
devices: add Logitech G604

Fixes #827
Signed-off-by: Filipe Laíns lains@archlinux.org

It would be great if we could merge #829 before this.

It would be great if we could merge #829 before this.

that one still has work pending, doesn't it?

Yes, we can merge this however.


text:
Windows uint64_t uv__hrtime(double scale) not return correct value?

In https://github.com/libuv/libuv/blob/v1.x/docs/src/loop.rst, it say uv_now return the current timestamp in milliseconds, but I got number that is not system current timestamp.
The value returned by uv_now() is produced by uv_hrtime(), uv_hrtime() just call QueryPerformanceFrequency(), according to https://msdn.microsoft.com/zh-cn/library/windows/desktop/ms644905(v=vs.85).aspx , it says
Retrieves the frequency of the performance counter. The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.

It just  elapsed time, so I think something mistake.
So please @saghul, @cjihrig look into this.

I miss something

Do you call uv_update_time() before you call uv_now()?

@bnoordhuis please double check.

Please post your code, I'd like to see exactly how you are calling libuv.

ok, I found this issue use https://github.com/luvit/luv
Please wait a few minutes let me show you it in C code.

@bnoordhuis , please.
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <uv.h>

static uv_loop_t *loop = NULL;
static int i=0;
void update(uv_timer_t *req) {
    char data[500];
    time_t current_time;
    uint64_t now;

    uv_update_time(loop);
    now = uv_now(loop);

    current_time = time(NULL);
    printf("system time get by \"time_t time(time_t *t)\":                 %s\n",ctime(&current_time));
    current_time = now/1000/1000;
    printf("system time get by \"uint64_t uv_now(const uv_loop_t* loop)\": %s\n",ctime(&current_time));
    if (i<5) {
        i++;
    } else {
        uv_timer_stop(req);
    }
}

int main() {
    uv_timer_t ticker;

    loop = malloc(sizeof(uv_loop_t));
    uv_loop_init(loop);

    uv_timer_init(loop, &ticker);
    uv_timer_start(&ticker, update, 0, 1000);

    uv_run(loop, UV_RUN_DEFAULT);

    uv_loop_close(loop);
    free(loop);
    return 0;
}

on windows, output
system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:33 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:34 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:35 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:36 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:37 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

on linux, output
system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:33 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:34 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:35 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:36 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

system time get by "time_t time(time_t *t)":                 Fri Mar 24 17:08:37 2017

system time get by "uint64_t uv_now(const uv_loop_t* loop)": Thu Jan  1 08:01:54 1970

Why are you doing current_time = now/1000/1000?  Also, ctime(&current_time) doesn't make sense because it's not wall clock time.  From the documentation:

The timestamp increases monotonically from some arbitrary point in time.
Don't make assumptions about the starting point, you will only get disappointed.

So far I don't see anything that indicates a libuv issue.

haha, it's my fault.

sorry for disturb

authors: bnoordhuis zhaozg

repo: libuv/libuv


text:
Using relative paths for #include

#include "queue.h"
The intent of double quotes is to search the directory where the current file resides and, only if the file is not found, search the standard include directories .
Using relative path in double quotes can

Improve compilation performance slightly and make the code more standardized .
Make it easier to embed into other projects without the cmake system .
No need to add “\libuv\src”  to the standard include directories .

References

C11 standard (ISO/IEC 9899:2011):6.10.2 Source file inclusion (p: 164-166)
C99 standard (ISO/IEC 9899:1999):6.10.2 Source file inclusion (p: 149-151)
C89/C90 standard (ISO/IEC 9899:1990):3.8.2 Source file inclusion

Sorry for the delay, I missed the notification for your PR. I'm open to this change if it's done in a disciplined way. Particularly:

No need to add “\libuv\src” to the standard include directories

If you also fix up includes of uv-common.h and possibly one or two other files, you should be able to drop the include path from CMakeLists.txt and Makefile.am (and uv.gyp, but that file is going away anyway so it doesn't matter.)

I'm going to close this but let me know if you still want to pursue it. Cheers.

authors: bnoordhuis xth


text:
Adds full-name to README.md

Title's self explanatory.
But see discussion for why: https://github.com/libuv/libuv/discussions/3283

Thanks for the PR, but we're not going to make this change.

authors: cjihrig top-master


text:
ios: Fixes undefined PTHREAD_STACK_MIN

When I compile last commit for my ios project, it says that PTHREAD_STACK_MIN is undefined. It's actually defined in limits.h so I add the header to the file.

LGTM

Landed in db680a1, thanks!

authors: lynxluna saghul


text:
🛑 Backend - US is down

In f43ac71, Backend - US (https://api.us.licenseware.io/licenseware/) was down:

HTTP code: 503
Response time: 75 ms

Resolved: Backend - US is back up in 01ef96a after 5 minutes.

repo: licenseware/uptime


text:
Update scala3-library to 3.5.1-RC1

About this PR
📦 Updates org.scala-lang:scala3-library from 3.5.0-RC4 to 3.5.1-RC1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala3-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala3-library" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, version-scheme:semver-spec, commit-count:1

Superseded by #51.

repo: lichess-org/scalalib


text:
gulp watch fail to install theme bundle if you have liferay-hook.xml in WEB-INF

Having liferay-hook.xml file in your theme cause watch to fail install bundle.
The command
install 'webbundledir:file://.../.web_bundle_build?Web-ContextPath=/my-theme'
fail with NullPointerException
The Liferay log:
2018-12-08 22:53:09.218 ERROR [pipe-install 'webbundledir:file:///.../.web_bundle_build?Web-ContextPath=/my-theme'][WabDirURLStreamHandlerService:140] Unable to open connection
java.lang.RuntimeException: com.liferay.portal.kernel.deploy.auto.AutoDeployException: More than one auto deploy listener is available for .../.web_bundle_build: com.liferay.portal.deploy.auto.HookAutoDeployListener, com.liferay.portal.deploy.auto.ThemeAutoDeployListener
	at com.liferay.portal.osgi.web.wab.generator.internal.processor.WabProcessor.getAutoDeployListener(WabProcessor.java:310)
	at com.liferay.portal.osgi.web.wab.generator.internal.processor.WabProcessor.executeAutoDeployers(WabProcessor.java:247)
	at com.liferay.portal.osgi.web.wab.generator.internal.processor.WabProcessor.autoDeploy(WabProcessor.java:156)
	at com.liferay.portal.osgi.web.wab.generator.internal.processor.WabProcessor.getProcessedFile(WabProcessor.java:111)
	at com.liferay.portal.osgi.web.wab.generator.internal.WabGenerator.generate(WabGenerator.java:90)
	at com.liferay.portal.osgi.web.wab.reference.support.internal.WabDirURLStreamHandlerService.openConnection(WabDirURLStreamHandlerService.java:123)
	at org.eclipse.osgi.internal.url.URLStreamHandlerProxy.openConnection(URLStreamHandlerProxy.java:114)
	at java.net.URL.openConnection(URL.java:979)
	at org.eclipse.osgi.internal.location.LocationHelper.getConnection(LocationHelper.java:106)
	at org.eclipse.osgi.storage.Storage.getContentConnection(Storage.java:580)
	at org.eclipse.osgi.storage.Storage.getContentConnection(Storage.java:550)
	at org.eclipse.osgi.internal.framework.BundleContextImpl.installBundle(BundleContextImpl.java:145)
	at org.apache.felix.gogo.command.Basic.install(Basic.java:437)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:139)
	at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:91)
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
	at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: com.liferay.portal.kernel.deploy.auto.AutoDeployException: More than one auto deploy listener is available for .../.web_bundle_build: com.liferay.portal.deploy.auto.HookAutoDeployListener, com.liferay.portal.deploy.auto.ThemeAutoDeployListener

We have significantly changed the watch implementation in #190 with the hope of fixing the existing issues. At the time of writing, that's in the "master" branch and will be included in the next release (v8.0.0-rc.4). The master issue for tracking the rewrite is #127, so I am going to close these separate tickets and ask that we consolidate further discussion about watch there.

authors: backtime wincent

repo: liferay/liferay-js-themes-toolkit


text:
Getting error while running scriptmaster

[error] invalid use case selected ('Did not find a Gradle, Maven, Bach, JBang or Ant project') - exiting script
Can someone guide me how to resolve this issue.

Can you provide more details?

repo: lifinance/contracts


text:
Fix Akka HTTP Management configuration

@kikiya This PR contains the changes we created during the Akka Cluster workshop on RPi in Montreal.

^^^ @kikiya: No, forgot about that one. Need to do that...

repo: lightbend/Pi-Akka-Cluster


text:
Install Android charts library to build

After deciding on the Android Chart library, it will have to be installed in AppInventor itself, so that it can be used and compiled.

Additional consideration: Future support for iOS should be taken into account.
For that, [MPAndroidChart][https://github.com/PhilJay/MPAndroidChart] has a twin [Charts][https://github.com/danielgindi/Charts] library.

Library has been decided to be MPAndroidChart.

To handle:

[ ] Resolve API 14 only support

Chosen solution - ignore warnings and compile as is. Seemed to cause no issues so far.

repo: lightingft/appinventor-sources


text:
fix layering

lower vegetation should be printed first, then the player
later the trees, pop-ups and ui components

add on: fix tree drawing, should be sorted by y-axis before drawing

repo: lightmanLP/garrulous-gargoyles


text:
lnwire+routing: deprecate FinalIncorrectHtlcAmount in favor of unified UnknownPaymentHash

In order to fix a probing vector, we've recently made a modification in the specification to phase out
FinalIncorrectHtlcAmount in favor of adding an additional payload to UnknownPaymentHash of the final value the destination receives. This change coalesces the two errors, making an unknown payment hash error indistinguishable from the case wherein an intermediate node modifies the value of the final HTLC. Otherwise, if this isn't patched, then a node can probe the final destination of an HTLC as the node that returns FinalIncorrectHtlcAmount reveals that the know the payment hash pre-image, but the value is incorrect. After this change, lack of knowledge of a payment hash extended, and an incorrect value for a known payment hash will be indistinguishable.
Steps To Completion

[ ] Extend UnknownPaymentHash include a new lnwire.MiliSatoshi field of the payment amount. At the end, the error type should properly implement the Serializable interface.

[ ] Within the link, whenever we send back an UnknownPaymentHash error, we should always set the value of the incoming HTLC.

[ ] Within the link, stop returning FailIncorrectPaymentAmount  and instead return UnknownPaymentHash populated as we do above.

Taking this

authors: Roasbeef orbitalturtle

repo: lightningnetwork/lnd


text:
Generated idea project reports error Error:scalac: No 'scala-library*.jar' in Scala compiler classpath in Scala SDK org_scala-lang_scala-library_2.12.4_scala-library-2.12.4-sources.jar when compiling

In a mill project:
mill mill.scalalib.GenIdeaModule/idea

Then open idea and set scala project, and build.
It reports:
Error:scalac: No 'scala-library*.jar' in Scala compiler classpath in Scala SDK org_scala-lang_scala-library_2.12.4_scala-library-2.12.4-sources.jar

Check the scala related library, I see

Which has empty compiler classpath.
To fix it, I need to remove the two libraries:

org_scala-lang_scala-library_2.12.4_scala-library-2.12.4.jar
org_scala-lang_scala-library_2.12.4_scala-library-2.12.4-sources.jar

And add the scala sdk provided by IDEA, which is like:

I'm happy to have a look at this. I'm looking at making the dependencies get correctly allocated to sub modules and a few other improvements to to GenIdea

@ajrnz go for it

authors: ajrnz freewind lihaoyi

repo: lihaoyi/mill


text:
Implicit, type-safe conversions of value classes for attribute pairs

Hi!
Despite the extensive title, my question is rather simple.
I happily use ScalaTags to generate HTML on the server.
For type safety, I have introduced a little value class HtmlId that identifies an HTML element:
case class HtmlId(value: String) extends AnyVal {
  override def toString: String = value
}

Currently, I use it like this:
import scalatags.Text.all._

val myId = HtmlId("my-id")
div(id := myId.value)

I would like to use it like this:
import scalatags.Text.all._
import my.package.HtmlIdImplicitConversion

val myId = HtmlId("my-id")
// HtmlIdImplicitConversion is applied here so I don't need to call `.value`
div(id := myId)

The obvious thing to do is to have an implicit conversion from HtmlId to string:
implicit def implicitToString(id: HtmlId): String = id.value

I don't want to use that, though, since string is too general; I'd prefer to have a more type-safe conversion.
I'm not sure how to create such a conversion, maybe using ScalaTags' AttrPair or AttrValue?
Thanks!

My solution:
`trait PageIds
object PageIds extends PageIds {
val Content: PageId = "content"
}
case class PageId(id: String)
object PageId {
implicit def boxToPageId(id: String): PageId = PageId(id)
implicit def unboxToId(pid: PageId): String = s"#${pid.id}"
implicit final def unboxToAttr(pid: PageId): Modifier = builder => {
builder.setAttr("id", Builder.GenericAttrValueSource(pid.id))
}
}`
usage in scala js:
jQuery(PageIds.Content)
witch enup eq to:
jQuery("#content")
usage in scala jvm scalatags:
div(PageIds.Content, "some contents")
witch results to:

some contents

@mb720 @CyberGear

import scalatags.JsDom.all._

case class HtmlId(value: String) extends AnyVal {
  override def toString: String = value
}

implicit val stringAttr = genericAttr[HtmlId] // it uses toString() of class...

div(
  cls := HtmlId("bla")
)("aaaaaaa")

https://scalafiddle.io/sf/m9bm6qx/0

repo: lihaoyi/scalatags


text:
Iteration2

This pull request is to merge the features as described in sprint 2

Matches Project Backlog. Merge approved.

authors: Akash-Ravindra lilnpuma

repo: lilnpuma/ProjectCollie


text:
Command: show_at_center

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1197578-command-show_at_center?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-backend#50.

authors: erbridge quarnster

repo: limetext/lime


text:
How to include a file to a php page?

This is what I'm facing right now
Can anyone give some suggestions on PHP

http://php.net/manual/en/function.include.php

authors: Rajkumarrrrr lincanbin

repo: lincanbin/Carbon-Forum


text:
Display finishing date

Below the current line of text displayed in the prog-o-meter window stating how many days the user have left before they reach the goal, we should also display a line of text stating the end-date, i.e. the date on which they will reach their goal.
This requires that we calculate the end-date based on the current date + The number of remaining days of challenge (self.GOAL-self.days)
We should also make sure to update the the add_day method (belonging to the ProgressGUI class), so that when it is called, this line of text is updated. (Most likely the end-date will be the same, if the user is progressing at the "normal" speed. However, if they have not been progressing for one or more days, and then add a new day after their "hiatus", we should calculate, and display the new end-date)
Suggestion: You can add the new code to the canvas_layout method belonging to the ProgressGUI class. For inspiration on how to do it, check out the assignment of self.countdown_text in canvas_layout method belonging to ProgressGUI.
Maybe the python module datetime (https://docs.python.org/3/library/datetime.html) can be used to calculate which date it will be, x days from today.

Hey, I will take a look at this.

Awesome, and welcome to the team. Let me know if you have any questions

Hey @B-Souty how is it going with this issue? Let me know if you need any help or feedback :)

Hi lineaba,
I am submiting a PR right now.

@B-Souty Awesome! I am so stoked that you did your first PR with the prog-o-meter, it was exactly for that reason I started the project. I will take a look at you PR within the next couple of hours 😃 Please let me know if you have any feedback on the github repo, if there is anything that could be explained better, organized differently, etc.

Feature added in #50

hmmm, I'm checking on my windows VM.

@lineaba Ok I found the issue on line 134: return datetime.date.strftime(completion_date, "%B %-d{0}, %Y".format(suffix))
Apparently "%-d" is not supported on windows instead we need to use "%d". On Linux it allows to display the day as 1st, 2nd, 3rd, 4th, ... instead of 01st, 02nd, 03rd, 04th, ...
the quick fix is to replace line 134 with  return datetime.date.strftime(completion_date, "%B %d{0}, %Y".format(suffix))
Shall I create a branch, fix it there and make a new PR or do you want to take care of it?

Glad it was such a simple fix. I can change it and open a PR if you wanna approve it, or the other way around :)

I have fixed it and opened a PR. Take a look, and see if you can approve when you have time :)

Alright, I'll approve it as soon as it's in. My apologies for that, I had no idea there was such difference betzeen windows and linux. I'll do my tests on my windows VM as well from now on.

No worries, I hadn't either. I mainly use windows, so I hadn't considered these types of issues when I started collaborating. But it is all part of why I started the project, to be able to learn more of the "real issues"

@lineaba I edited your original comment on PR#60 to add a "#" in front of the issue number to create the link. This way, it gets automatically referenced in the issue ;)

Cool, i probably missed it, thanks for adding it.

authors: B-Souty lineaba

repo: lineaba/prog-o-meter


text:
CVE 2023 33202

CVE-2023-33202 : original commit id 0c576892862ed41894f49a8f639112e8d66d229c

fixed potential Denial of Service(DoS) issue
removed isSorted boolean

Closing this PR as a new PR will be raised from the contributor directly here

authors: abhiseksanyal soubhagyah

repo: lineaje-labs-gos/bc-java


text:
Design idea regarding Event::Command

The fact that it's possible for a user-defined command to accidentally collide with one of Druid's predefined commands doesn't feel great to me (as incredibly unlikely as it is). Therefore my first suggestion is for the Command variant to be split into two new Event varaints: DruidCommand and UserCommand (names subject to bikeshedding). DruidCommand can then become an enum with all the currently constant Selectors becoming variants instead.
My next thought was that it would feel more ergonomic to me if this new UserCommand type could become a user-defined enum, instead of using Any. It would likely require some additional threading of a new generic parameter, so this may not be worth it. But if it was done it could eliminate the Selector type entirely. We've got a type system, we should use it instead of just stringly typing things imo.
Both of these would be rather large breaking changes, so they may not be worth it. Thoughts?

Personally, I don't think it is worth the additional effort. Having a convention to just prefix all selectors with the crate name is just much simpler and does the trick. For example all commands offered by druid are called something like druid-builtin.some-command which would only collide if you really are looking for trouble.
Of course, if Rust should ever offer some ergonomic way to get access to constant, unique ids, we will switch to that for safety and ergonomics. Until then, we will probably have to live with string identifiers.

Hmm, I would have thought something like the following might have worked,
Alas, it fails the last assertion for constant values...
https://play.rust-lang.org/?version=beta&mode=release&edition=2018&gist=7d14d3d7eca390973af6127d01e290f2

I've actually tried this approach during my search for an alternative for string id's and could not stop the compiler to optimize all selectors to a single pointer :/
MaybeUninit seems to do the trick, but is there any guarantee that this will never change? Or is it more of a side effect, that rustc can't optimize it right now?
Another issue is that both
static UHH: UniqueId = UniqueId::new();
and
const UHH: UniqueId = UniqueId::new();
compile but the latter will not behave as expected.

MaybeUninit doesn't guarantee that the underling pointer will never change,
if you move the value it will absolutely change the underlying pointer along with the moved value.
Also i'm not particularly aware of the semantics defining std::ptr::eq, it does seem to be peculiar with both const, A third issue is that if you change it to MaybeUninit<()> unstead of bool I believe it'll also compare equal (what the inaccurate sized comment is about Zero sized is still sized).
Perhaps we can do something with std::pin::Pin to keep it from moving.  But yes, the specific details of this pointer equality approach seems non-obvious regarding the results and guarantees.
I don't think its reasonable to expect though that rustc could ever optimize it away, since it pretty well hides the underlying allocation from the compiler.  We could seek clarification I suppose if we decide this is an option worth pursuing.

When I initially came up with this idea I was thinking about the perf implications as well as the ergonomics, but you've mentioned that Selectors are actually just doing a pointer comparison and not a full string comparison, so that helps. I'm not sure what the cost of the any downcast is compared to an enum destructure, but probably not much.
However this raises an interesting issue to me. This style of pointer comparison only works if everything is statically compiled together. Now while that is the default in rust, compiling to a dylib is supported. If one were to define the same string in two different places, compile them to separate binaries/libraries, and have one load the other dynamically, these Selectors wouldn't match, despite the string contents being identical. This is an extremely unusual use case though, so I don't think it really matters. And to solve it you could just expose one of the strings publicly instead of defining it twice.
For an additional perspective on the enum based approach, take a look at the library Iced. The way they implement it is different from how it would have to be in Druid however. They have an Application trait that the root of your app implements, which has an associated type Message. That Message type then gets applied to all of your widgets inside the Application. Druid has no root-level construct like this.

@smmalis37

I was thinking about the perf implications

Honestly, if we manage to reach a point where comparison of command selectors becomes relevant, we will have already succeeded in building the fastest UI library in existence :)
Ergonomics is really the only reason I would be convinced to change this.

but you've mentioned that Selectors are actually just doing a pointer comparison and not a full string comparison

That's not quite right, Druid does a string comparison (which gets optimized with pointer comparison by Rust).
What @ratmice illustrated was what we could do if we went with pointers as id's.

That Message type then gets applied to all of your widgets inside the Application. Druid has no root-level construct like this.

Yeah, I don't think this approach would work for Druid. It could probably be done with something like parameterised modules but I doubt that will ever become a feature of Rust.

@ratmice

But yes, the specific details of this pointer equality approach seems non-obvious regarding the results and guarantees.

That's my biggest issue with this approach.
Another problem is debugging. Right now it is quite nice because every command has a unique, human-readable id that can easily be greped for. Using pointers you would probably still want to give your commands unique id's simply to be able to differentiate them when something goes wrong.

Druid has no root-level construct like this.

@smmalis37 Noob suggestion, but the delegate you register with the launcher strikes me as a pretty straightforward place to attach a potential Message type to. Or even making AppLauncher a trait for users to implement, and have it all on there? I don't know how all the *Ctx are implementen/constructed regarding commands, but given that there is some amount of plugging and plumbing at the top level anyway, why not encode it more coherently and also enable deeper control over command/message objects?

I'd be curious to see a sketch of this, but my current feeling is that adding a top-level user-defined type is going to end up infecting most of the other type signatures in a pretty big way, and it isn't totally clear to me what the benefits are.
One possible exception to this would be to have there be a separate 'Event::AppMessage' event, that would be a single place where you can inject a type, and this would hopefully only change the signatures of the event fn and the Event enum? For now though I'm happy to be hacking around with Command, even if it doesn't feel 100% pure and good.

I'm going to close this. For now all druid commands have a name starting with druid-builtins.* or druid-tests.*, so I think the collision risks are negligible; and as other already pointed out, it's not really worth the cost of a refactor.

also there is selectors macro in nursery. a selector generated by the macro will not collide with other selectors generated by the macro

authors: Finnerale Maan2003 PoignardAzur cmyr madbonkey ratmice smmalis37

repo: linebender/druid


text:
Designing a unified multi-click API

While working on #843 I also started thinking about double-clicks and how to best do them. I think that the behavior should match across platforms so that druid users can just read the druid docs and not worry about platform specifics.
Double-clicks are good, triple-clicks possibly worth it, but what about quadruple-clicks or even more? I'm not sure there's really much value in going beyond three. It's definitely more work.

Windows natively supports only up to double, so will need a custom implementation anyway.
GTK seems to support triple clicks, so we can probably piggyback on that for up to triple.
macOS supports up to triple on most buttons, but seems to be practically unbounded for left and right buttons. We can piggyback on the platform for up to triple, including unbounded_count % 3.
Web has some support via UIEvent.detail but I haven't tested how well it works.

Custom implementations (which Windows will need anyway) will need to be careful to follow the user configured OS setting for double click timeout.
Thus I propose the following unified API:

Support for up to triple-clicks.
Both MouseDown and MouseUp contain the click count.
No extra double or triple click events, it's merely an extra event property for those who care.

I think this design makes sense.
If we're using a simple timer to determine whether a click is part of a 'click sequence' I'm not if it makes much difference whether or not we stop at three, but I also don't think quadruple clicks are a problem we need to worry about in this century? Famous last words?

Question about click count, If i recall, mac OS would send sequentially higher click counts, so you would get an event with MouseDown and click count 1, then one with 2, etc.
Is this what you had in mind, or would their be a single event with click count 2.
Double clicks and event propagation can sometimes be tricky, presume it's possible that the first click gets put on some system platform event queue, same for the second click +incr click count,
the first event causes the window to close, the target for the 2nd event now no longer exists.
Anyhow its just an awkward case to keep in mind

It's a timer. playing around, here are three events with different positions that count as a click sequence, and then two events in the same location that don't:
(155.7109375, 201.76953125): 1
(155.41796875, 201.26171875): 2
(154.8828125, 200.51171875): 3

(147.55859375, 248.6640625): 1
(147.55859375, 248.6640625): 1

Yes my earlier macOS findings match this, indeed it's a timer.
As for what I meant for events, I mean that every physical click of a button will generate exactly one click event, no more. Each click event has a count associated with it, so those apps that care about differentiating double clicks can look at that while most apps can just ignore it.

If we're using a simple timer to determine whether a click is part of a 'click sequence' I'm not sure if it makes much difference whether or not we stop at three

That's true, but that's also why I want to stop at three. Because then we don't have to use a timer ourselves on some platforms like macOS. There we can just use the OS provided count which is guaranteed to respect OS settings.

I'm happy to stop at three, but on macOS couldn't we just use the clickCount property, which can be any integer?

macOS clickCount also stops at three with middle/X1/X2 in my testing. It's only left/right which can be any integer.
If you see more than 3 with all buttons then that would be interesting.

interesting yea there's weird stuff going on. I can get the middle mouse button up to ten repeats, but not higher.
Also interesting: it doesn't seem like the click count is button dependent; if I alternate between right and left it keeps incrementing.
I think most of this is just weird buggy edge case stuff that we can ignore. Three is a reasonable limit. I guess one thing to think about, though, is what happens on the 4th click; do we send click count of 1? The middle button seems to get weirdly throttled on my current mouse, but I don't trust my hardware particularly, and I don't seem to have another mouse around.

I think doing (count - 1) % 3 + 1 to just wraparound to a 1/2/3 sequence is a good way to harvest the larger OS count with some value.

I did some more testing. I can actually get the middle button up to 4, but no more. X1/X2 are 3 max.
The interesting situation however is having the count increase while switching between left & right buttons. This doesn't work when switching between other buttons.
I don't think this is something we would want. Doing a single right click and then a single left click shouldn't execute a double left click action. Testing macOS itself in Finder for example, doing a right click and then a left click doesn't open a folder. I'm not sure what it's doing underneath, but it's not just checking the click count.
I think the druid API should guarantee that the click count is per button. This allows for simple double click detection logic in the app.

Interesting about non-differentiation between buttons, at least during some point in history, it was possible to treat all buttons the same so left/right could be treated as a single button... probably a bug that isn't taking single-button vs multi-button into account.

I agree, and I the the implementation might actually get simpler if we don't rely on on system detection, assuming we have some way of getting the correct 'click interval'; this is trivial on macos, exposed on the NSEvent class as doubleClickInterval

Indeed, after learning of these subtleties, the manual implementation is looking more attractive.

I was reading through this and assumed that this proposed system had yet to be implemented but (on the GTK shell) I was surprised to see that the MouseDown event has a count field which reports the click count. Was there some PR adding this to the GTK shell that I cannot find? I'm pleased to be able to have something like this working in some sense already but it has some odd behaviour which makes me want to read through the PR which added this.

The current GTK click count was added in #151 so it has always been there. The count currently exists in some form on GTK, macOS, and Windows. This issue here is about improving it further and also crucially making it behave the same across platforms.

The way I handle this in Rutabaga is to have a platform function for retrieving the current double-click interval and then incrementing a click-counter when internally handling a click eveng. This is easy to get on Windows and macOS, but I punted on the Linux approach.

There is some more work to be done here. One thing I noticed in testing Runebender on Linux is that on double-click, Gtk sends both a GDK_BUTTON_PRESS and a GDK_2BUTTON_PRESS event. In our translation layer, this sends two mouse-down events, with count of 1 and 2. That in turn trips an internal invariant in RB's mouse handling, and thus a panic.
I did a little digging, and don't see an easy way to fix this on Gtk. I think it's likely we'll end up having to do our own click counting, just as we do on Windows. There, a challenge is to pick up the preferences. But I suspect it's not impossible to read those from the same source as Gtk, so we're consistent.

Is this issue still relevant? MouseEvent has a count field now.

authors: ForLoveOfCats PoignardAzur cmyr raphlinus ratmice wrl xStrom


text:
Respect starting directory for dialogs on Windows

Before this change, FileDialogOptions::starting_directory had not been used on Windows and therefore had no influence on the starting directory of a file dialog window.
This has now been fixed.
The use of SHCreateItemFromParsingName makes it mandatory to explicitly link against shell32.lib because this is not done automatically since Rust 1.33.0. See https://github.com/rust-lang/rust/pull/56568 for details.

Okay, this looks good, outside of the changelog conflict.
I'm not able to test on windows today but will be able tomorrow, if nobody beats me to it.

is there a quick repro sequence?

@raphlinus
diff --git a/druid/examples/open_save.rs b/druid/examples/open_save.rs
index 21d1a34..1a61d0d 100644
--- a/druid/examples/open_save.rs
+++ b/druid/examples/open_save.rs
@@ -42,6 +42,7 @@ fn ui_builder() -> impl Widget<String> {
         .allowed_types(vec![rs, txt, other])
         .default_type(txt)
         .default_name(default_save_name)
+        .force_starting_directory(std::path::Path::new("C:\\"))
         .name_label("Target")
         .title("Choose a target for this lovely file")
         .button_text("Export");

and then
druid\druid> cargo run --example open_save

should be sufficient to verify the behavior. With the added line, the "save" dialog opens at C:\, without it opens at the default location (probably %USERPROFIL%\Documents).

@cmyr I resolved the conflicts, feel free to merge & squash whenever you like 😄.

authors: MaximilianKoestler cmyr


text:
Failed to communicate with a quorum of validators when run publish-and-create

Issue:
Fail to publish contract with local testnet with error: 2023-06-08T03:29:48.969990Z ERROR handle_block_proposal{address="http://127.0.0.1:9100"}: grpc_client: error=Grpc error: remote request [handle_block_proposal] failed with status: Status { code: Cancelled, message: "Timeout expired", source: Some(tonic::transport::Error(Transport, TimeoutExpired(()))) } Error: Failed to communicate with a quorum of validators: Grpc error: remote request [handle_block_proposal] failed with status: Status { code: Cancelled, message: "Timeout expired", source: Some(tonic::transport::Error(Transport, TimeoutExpired(()))) }
Steps:
1 Run ./script/run_local.sh in terminal 1
2 Run linera --wallet $LINERA_WALLET --storage $LINERA_STORAGE publish-and-create ./examples/target/wasm32-unknown-unknown/debug/counter_contract.wasm ./examples/target/wasm32-unknown-unknown/debug/counter_service.wasm --json-argument "42"
Expectation:
Smart contract is deployed successfully
Result:
We get error: 2023-06-08T03:29:48.969990Z ERROR handle_block_proposal{address="http://127.0.0.1:9100"}: grpc_client: error=Grpc error: remote request [handle_block_proposal] failed with status: Status { code: Cancelled, message: "Timeout expired", source: Some(tonic::transport::Error(Transport, TimeoutExpired(()))) } Error: Failed to communicate with a quorum of validators: Grpc error: remote request [handle_block_proposal] failed with status: Status { code: Cancelled, message: "Timeout expired", source: Some(tonic::transport::Error(Transport, TimeoutExpired(()))) }
Note:
If we run open-chain directly after execution of run_local.sh, then open-chain will be OK. After that, we run linera --wallet $LINERA_WALLET --storage $LINERA_STORAGE publish-and-create ./examples/target/wasm32-unknown-unknown/debug/counter_contract.wasm ./examples/target/wasm32-unknown-unknown/debug/counter_service.wasm --json-argument "42", then we'll get the timeout error. After that if we try to run open-chain again, open-chain will also be timeout.
Screenshot:

Commit:
8d2ad58366e780f2667bbc572684ea8f409d1544

I think the problem is the debug-mode Wasm binaries. It works for me with the release-mode ones (compiled with cargo build --release in the examples directory):
linera --wallet $LINERA_WALLET --storage $LINERA_STORAGE publish-and-create ./examples/target/wasm32-unknown-unknown/release/counter_{contract,service}.wasm --json-argument "42"

The release-mode contract and service Wasm files are 150 KB and 919 KB, but the debug-mode ones are 90 MB and 110 MB!

I think the problem is the debug-mode Wasm binaries. It works for me with the release-mode ones (compiled with cargo build --release in the examples directory):
linera --wallet $LINERA_WALLET --storage $LINERA_STORAGE publish-and-create ./examples/target/wasm32-unknown-unknown/release/counter_{contract,service}.wasm --json-argument "42"

The release-mode contract and service Wasm files are 150 KB and 919 KB, but the debug-mode ones are 90 MB and 110 MB!

got it. is it possible to limit the max code size of the smart contract ? just like what in ethereum ?

The release-mode contract and service Wasm files are 150 KB and 919 KB, but the debug-mode ones are 90 MB and 110 MB!

got it. is it possible to limit the max code size of the smart contract ? just like what in ethereum ?

@kikakkz Yes, we were just talking about it today with the team!

authors: afck kikakkz ma2bd

repo: linera-io/linera-protocol