Adding networks to tunnels?

Hi,
Looking at the screenshots I dont understand how you add which networks you want to go through the tunnel?
What am I missing?
-J

Networks are not a part of the scope of the plugin. See #7. I'd suggest using a custom field.


Make 'part_of' relationships part of parent/child relationships along with 'is_a'

...

Greg,
Since the parents can be of multiple different relationships. We'll probably need to keep track of the labels as well.
This is important as the drawing script assumes everything is "is_a" relationship.
https://github.com/tanghaibao/goatools/blob/master/goatools/obo_parser.py#L297
I don't have time to hack on it this week - if this is something you are working on I'd surely appreciate.
Haibao


Cargo doesn't run doctest for staticlib

Steps to reproduce:

cargo new mylib
open src/lib.rs and add:

/// ```
/// assert_eq!(1, 3);
/// ```
pub fn func() {
}

add following to Cargo.toml:

[lib]
crate-type = ["staticlib"]

cargo test

Build passes. Doctests aren't run.

Ah yeah this is probably just something that needs to be filtered when we run doctests, I think we already handle other pieces specially?

I think this is the correct behavior, this is filtered here: https://github.com/rust-lang/cargo/blob/8b0c007ac1c4b705570479326bb9be215fff2c76/src/cargo/core/manifest.rs#L312
and reasoned here https://github.com/rust-lang/cargo/blob/8b0c007ac1c4b705570479326bb9be215fff2c76/src/cargo/ops/cargo_test.rs#L147
If cargo run doctests will fail in any test that needs to be linked to the module.

Hm weird, so shouldn't we already handle this in that case?

We can add a warning when you run tests and doctested function return false.

In theory given that logic we shouldn't even attempt to test staticlibs b/c only rlibs are tested. We may just be forgetting a conditional somewhere to check that method return value.

Not really, the only problem with staticlibs is on "doctests" not on code tests. The problem is related with linking, then, to run doctests with staticlibs you have to compile it in another linkable format (lib or rlib). An approach (a bit weird in my opinion) when you dont have lib or rlib in your crate-type, compile it anyway and run doctests using it.
I think the solution is to warn the user that doctests aren't run when you don't have one of the doctesteable crate types.

From the user point of view, I advocate producing a warning. That's enough to resolve the issue as nobody will be surprised by the behavior.
I don't like silently producing lib or rlib as I found that may change compilation result. (My library once failed to build as rlib due to linkage error to _Unwind_Resume. staticlib worked fine.)

Wait whoa, I'm sorry! I misread this bug and thought it was saying that we were trying to run doctests but they were failing (legitimately).
This is intentional behavior in that case because as pointed out by @jespino it's fundamentally not possible to run documentation tests for staticlibs (like executables). We tend to not print warnings that aren't really actionable (there's no great way to solve this), so this is currently intended, so closing.


Ambiguous vpiIndex in vpiVarSelect

Please compare the bit_selects in vpiIndexes in these two examples.
1:
module top(output logic o);
   parameter int ThetaIndexX1 [3] = '{4, 1, 2};

   function automatic logic theta();
      logic [4:0][1:0] c = 10'h100;
      return c[ThetaIndexX1[0]][0];
   endfunction : theta

   assign o = theta();

   final begin
      assert(o == 1);
   end
endmodule

The uhdm of c[ThetaIndexX1[0]][0] is:
        \_var_select: (work@top.theta.c), line:6:14, endln:6:35
          |vpiName:c
<EMAIL_ADDRESS>          |vpiIndex:
          \_bit_select: (work@top.theta.c.ThetaIndexX1), line:6:16, endln:6:31<EMAIL_ADDRESS>            |vpiName:ThetaIndexX1
<EMAIL_ADDRESS>            |vpiIndex:
            \_constant: , line:6:29, endln:6:30<EMAIL_ADDRESS>              |vpiConstType:9
              |vpiDecompile:0
              |vpiSize:64
              |UINT:0
          |vpiIndex:
          \_constant: , line:6:33, endln:6:34<EMAIL_ADDRESS>            |vpiConstType:9
            |vpiDecompile:0
            |vpiSize:64
            |UINT:0

2:
module top(output [3:0] b);
   reg [0:0][7:0] a;
   assign a = 8'h0F;
   assign b = a[0][6:3];
endmodule

The uhdm of the a[0][6:3] statement is:
    \_var_select: (work@top.a), line:4:15, endln:4:24
      |vpiName:a
<EMAIL_ADDRESS>      |vpiIndex:
      \_bit_select: (work@top.a<EMAIL_ADDRESS><EMAIL_ADDRESS>        |vpiIndex:
        \_constant: , line:4:17, endln:4:18<EMAIL_ADDRESS>          |vpiConstType:9
          |vpiDecompile:0
          |vpiSize:64
          |UINT:0
      |vpiIndex:
      \_part_select<EMAIL_ADDRESS>        |vpiConstantSelect:1
        |vpiParent:
        \_var_select: (work@top.a), line:4:15, endln:4:24
        |vpiLeftRange:
        \_constant: , line:4:20, endln:4:21
          |vpiConstType:9
          |vpiDecompile:6
          |vpiSize:64
          |UINT:6
        |vpiRightRange:
        \_constant: , line:4:22, endln:4:23
          |vpiConstType:9
          |vpiDecompile:3
          |vpiSize:64
          |UINT:3

The only difference between these two bit_selects is that there is no vpiName in the second example, but they describe such different cases.
Could you represent select from the second example in other way?
In the first example the indexes were used as we want. Each vpiIndex contains the parsed expression in [...].
The selects from the second example are currently harder to handle. There are bit_select and part_select in vpiIndex nodes, but here are no selects between [...] in the source code. These select nodes show the type of the indexes and how the indexes should be handled, but not what the expression is between them. The expressions are in child nodes of these selects.

Fixed by #2383


shiny create drop --template parameter

template should not require the --template flag
# 👍 😊
shiny create dashboard
shiny create chat-ai-ollama

# 👎 😥
shiny create --template dashboard
shiny create --template chat-ai-ollama

We have
shiny create myapp

in our docs, which seems like it would create a the basic-app template in myapp?

But shiny create myapp doesn't work and I think most people would rather use the template id for shiny create (which then populates the directory) than to have the primary argument of shiny create be the name of the directory.
Those docs would become
shiny create basic-app
shiny export basic-app site


Links between Lightning docs are not linked properly

📚 Documentation
https://pytorch-lightning.readthedocs.io/en/latest/trainer.html#profiler
The link to profiler.html is not properly linked.
These links are happening too (found out so far).

link to multi gpu docs
link to slurm docs
link to lr_finder docs
link to logger docs

This is not happening on the stable 0.9.0 docs.
I couldn't find what PR caused this or something caused this.
Currently, they are linked like
`Title <title.rst>`_

Using :ref: fixed this for now. But, I'm not sure this is a proper way to fix.

@ydcjeff yes using ref on the anchor is correct. could you try to fix it?

@awaelchli okay, I will try it


Some checkpoints have AAF soldiers when rebelling against NATO

After starting a new game rebelling against NATO, some checkpoints (4 out of 4 so far) had AAF soldiers instead of NATO.
P.S. Tested with ACE with MASTER branch in MP

My mistake, all fine


added Indonesian translation v1.0

Indonesian translation for Best Student Discount as part of open source project practise

woops needs to fix something


Sys.executable sometimes gives wrong directory

Saw an instance in the NVIDIA server ( https://discord.com/channels/185647255028629505/185808757115191296/952815438675468288 ) where somehow copying the sys.executable failed, having to fall back to the except method of downloading executable from github.
UTC 13/03/2022 19:01:03 Falled back to downloading from github method for going to Appdata directory due to error: Traceback (most recent call last):
  File "AutoDDU_CLI.py", line 366, in makepersist
  File "shutil.py", line 254, in copyfile
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\jason\\Downloads\\AutoDDU_CLI.exe'

Same issue for user folder.
Interestingly the user did AutoDDU a day later and it finished fine:
UTC 14/03/2022 05:58:40 Successfully copied executable to new user
UTC 14/03/2022 05:58:40 Successfully copied executable to Appdata directory

There were no executable changes between these two runs, which has resulted in me being dumbfounded.

Happened again: https://discord.com/channels/185647255028629505/185808757115191296/957087190918266890

This was fixed a long time ago, cause was a misstype in os.path.join


[Task] TextInput Enhancement (components/ads/TextInput.tsx)

[ ] Currently, the error message is absolute positioned which makes it difficult to align with other components.

For eg:- A Fixed bottom padding needs to be given so that the error messages could be visible and not overlap with other UI below the text input.

[ ] When validator returns isValid as false, onChange stops working which might not be the use-case every time.
disabling textChange if the value is inValid is not expected behavior.

[ ] Avoid Prop drilling {...props}.

[ ] Add comments for each prop to explain its usage and caveats. This should be visible in autocomplete for the component consumers.

common tasks which should be done for each component -

Can I work on this issue?

Hey👋🏼 @nishihere19 , thanks for showing interest in this issue.
Unfortunately, this issue is yet in the discussion phase and hence not labeled as a Good First Issue. Please do check our other Good First issues
Looking forward to seeing your contributions :)


Rename tsx files without JSX to ts files

Pull Request Description
This makes it clearer which files contain React components, and which do not.
Important Notes
The main things that should be tested to confirm that this did not break anything is the two files containing Tailwind classes:

Shortcuts ("delete" in context menu should still be red. text-delete is used elsewhere though, so this should not be broken either way)
Indentation of directory contents (multiple levels)
Many of the others should more or less be self-testing:
index.tsx -> index.ts would break the entire app if not handled properly
hooks.tsx contains useNavigate which would break routing if absent, and useToastAndLog which would break most  toast notifications.
http.tsx contains the HTTP client which would break all backend requests
useRefresh.tsx would... break login and logout if it was broken I guess

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

marking as ready to merge as this changes zero lines of application code.


Make Overview Textview in Movie Details Screen

When movie details are loaded and the overview text is too long, we need to cut it down and show only two lines at a time and allow users to click on the text body to expand it.
See attached screen:

Suggestions:
Use a Box, a Text, a linear gradient and finally a button. API should be able to expose config for max lines and what happens when a user clicks on the read more button.

Text view will expand, gradient removed and read more button hidden or
The user of the API can decide what happens and handle it separately, such as moving to a new screen

@daniel-waiguru this is a great call. Please go ahead.


Invalid Certificate and HTTP 403 on download.virtualbox.org

The SSL certificate deployed on download.virtualbox.org is NOT trusted because of host name mismatch.
Users are not able to download files even after manually trusting the certificate.
All requests to download.virtualbox.org return HTTP 403 Unauthorized Request.

This issue is not related to the project. BTW the same has been already fixed. Closing it.


Attach ACR to AKS failed

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az aks update
Errors:
The command failed with an unexpected error. Here is the traceback:
cannot import name 'Iterable' from 'collections'<EMAIL_ADDRESS>Traceback (most recent call last):
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 556, in execute
    self.commands_loader.load_arguments(command)
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/azure/cli/core/__init__.py", line 517, in load_arguments
    self.command_table[command].load_arguments()  # this loads the arguments via reflection
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/azure/cli/core/commands/__init__.py", line 313, in load_arguments
    super(AzCliCommand, self).load_arguments()
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/knack/commands.py", line 104, in load_arguments
    cmd_args = self.arguments_loader()
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 125, in arguments_loader
    op = self.get_op_handler(self.op_path)
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/azure/cli/core/commands/command_operation.py", line 59, in get_op_handler
    handler = import_module(mod_to_import)
  File<EMAIL_ADDRESS>line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/Users/lukas.maruniak/.azure/cliextensions/aks-preview/azext_aks_preview/custom.py", line 44, in <module>
    from tabulate import tabulate  # pylint: disable=import-error
  File "/usr/local/Cellar/azure-cli/2.30.0_1/libexec/lib/python3.10/site-packages/tabulate.py", line 16, in <module>
    from collections import Iterable
ImportError: cannot import name 'Iterable' from 'collections'<EMAIL_ADDRESS>

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aks update -n {} -g {} --attach-acr {}

Expected Behavior
Environment Summary
macOS-12.4-x86_64-i386-64bit, Darwin 21.5.0
Python 3.10.0
Installer: HOMEBREW

azure-cli 2.30.0 *

Extensions:
aks-preview 0.5.48
ssh 1.0.0
account 0.2.1
rdbms-connect 0.1.4

Additional Context

route to CXP team

@lukasmakac Can you please upgrade to the latest version of az cli 2.39.0? and retry

Sure, upgrade worked, thanks.
Just to specify - I experienced this on MacOS and az upgrade failed unless I installed Xcode command line tools via xcode-select --install.
So to summarize what worked for me:
xcode-select --install
az upgrade


[Request for External] Page 508 and 510 ShowOrders

Please make procedure ShowOrders in Pages 508 and 510 public and external, so we can use those procedures in our extensions and do not need to rewrite them.
Or even better implement ShowOrders, ShowInvoices, ShowReturnOrders, ShowCreditMemos, ShowPostedOrders, ShowPostedInvoices, ShowPostedReturnReceipts and ShowPostedCreditMemos
as public and external procedures in T37 and T39
with names ShowOrdersForBlanketOrderLine, ShowInvoicesForBlanketOrderLine aso.

These procedures are specific for Blanket Order line, therefore they are placed in corresponding pages. We don't want to overload T37/T39 with unnecessary code without string reason. If we make them external in P508/P510, how you are going to use it? If we should move it somewhere, why not move this to new codeunit instead of T37/T39?

To move those procedures to a new codeunit would also be convenient for us

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Add Js configuation

Pull Request Test Coverage Report for Build #22

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build #21:
0.0%

Covered Lines:
224

Relevant Lines:
224

💛  - Coveralls


Update singular vcore string on data controller dashboard

On data controller dashboard, if a resource has 1 vCore, we currently list that as "1 vCores". Fixing this logic to account for the singular case as well:

FYI postgres will show empty vcores for now.  We're still figuring out how to represent it as a single value.  Since there are multiple nodes, and different roles can request different numbers of cores.

Coverage decreased (-0.002%) to 35.838% when pulling 9ac8edda6c22ad2181b697c1be289d640d36361e on fix/arcvcore into a8a7559229f86e88ee31f3a8ebced2332e89fe0a on main.


drivers/gl: Use golang.org/x/mobile/gl instead of github.com/go-gl/gl/v2.1/gl.

This PR is a continuation of #78. It's different in that it simply modifies the existing driver, rather than adding an second driver.
This PR modifies the gl driver to use golang.org/x/mobile/gl package. This package offers a slightly higher level interface, with desktop (OS X, Linux) and mobile (iOS, Android) backends. There is ongoing work to add support for Windows and web browsers.
Resolves #45.
Related to #49.

The x/mobile/gl provides a universal GL interface which can run on desktop (OS X, Linux), mobile (iOS, Android), with current work to add support for Windows and web browsers.
Change index buffer data type from []uint32 to []uint16, since it offers enough size, and WebGL implementations do not support []uint32 as readily.
Remove stFloatMat2x3, stFloatMat2x4, stFloatMat3x2, stFloatMat3x4, stFloatMat4x2 and stFloatMat4x3 since x/mobile/gl does not currently have support for those operations they are unused.
Remove gl.INVALID_INDEX since x/mobile/gl does not have it.
Remove support for image.Gray format, since it's unused.
HACK: Hardcode []uint16 support in newIndexBuffer, since x/mobile/gl has poor support for non-[]uint8 types at this time, only []uint16 is used. Need to improve this.
HACK: Hardcode []float32 support in newVertexStream since it's the only type used, and x/mobile/gl currently has poor support for other types. Need to improve this.

Hmm, Travis is failing because of:

Disallowing packages: libgles2-mesa-dev

Any ideas why it's disallowing that package (yet libgl1-mesa-dev was fine)?

Fixed Travis by using the usual sudo apt-get install method of installing packages, since libgles2-mesa-dev is not whitelisted. Meanwhile, I've opened https://github.com/travis-ci/travis-ci/issues/3518 so once that's resolved, it'll be possible to go back to using apt_packages addon.

Does x/mobile/gl support windows yet? (I can't remember if either Hana or I added it.) I hope it's not to hard to add, but I wouldn't want to break any gxui users on windows.

I'll give it a try now.

Does x/mobile/gl support windows yet?
Apparently so

Although I'm not sure how.
I'll continue investigating...

No, I take it back:
# github.com/google/gxui/drivers/gl
drivers\gl\texture.go:94: undefined: gl.Texture```

Does x/mobile/gl support windows yet? (I can't remember if either Hana or I added it.) I hope it's not to hard to add, but I wouldn't want to break any gxui users on windows.

So AFAICT, no it doesn't. It doesn't seem trivial to add either. The problem is windows doesn't really have an OpenGL header that's worth using (the system one is OpenGL 1.1, which is pretty worthless). Typically, the drivers support more up to date versions of GL - GXUI has shown that most windows users have a driver that supports at least OpenGL 2.1, but the function pointers need to be obtained using something like wglGetProcAddress.
I'm not sure what the best course of action is for adding Windows support into x/mobile/gl. Really all you're going to end up with is something using GLEW or something that looks very similar to GLOW.

why change gl driver？let us focus on ui for desktop first。

why change gl driver？let us focus on ui for desktop first。

Don't worry. We won't switch until we're confident that desktop (Windows/OSX/Linux) will continue to work. Getting GXUI working on Android / iOS and WebGL would double the number of supported targets, which would be more than a worthwhile goal.

@shurcooL, @slimsag, @crawshaw - sorry, I've not had much time to look into this recently.
Given that x/mobile/gl windows support recently got labelled unplanned, perhaps it would be simpler to add Android support to go-gl? It seems rather easy to add new targets to GLOW, and I believe it wouldn't take much to do the GetProcAddress for Android.
What do you think?

I have been extremely busy with android/iOS platform bugs, so I won't have time to look at windows support before 1.5. If someone can get GLOW working quickly, makes sense to me.

@ben-clayton AFAIK you can generate OpenGL ES 2 bindings with:
glow generate -api=gl -version=2.0 -out=./gl/2.0/gl

And they already work quite well (I've been using them on Linux desktop, not Android though).
We shouldn't need to add a GetProcAddress for Android as it supports EGL, which means you just need to build the code with -tags=egl (we should probably make that the default for arm).
I'll see what I can do later today about making egl the default for arm and generating the ES2 bindings as part of the go-gl/gl repository (will send a PR).

@slimsag wouldn't you want -api=gles2?
I was playing with GLOW GLES2 generation when I created this bug. Aside from the harmless error, the output looked good.

I'll see what I can do later today about making egl the default for arm and generating the ES2 bindings as part of the go-gl/gl repository (will send a PR).

Awesome, thanks. I confess I haven't tried building and running Go on android yet, but I'm keen to give it a try when I get a chance.

@ben-clayton Oops -- yes! I had copied the wrong line from one of my shell scripts. Apologies.
I haven't built any Go code for Android yet either, but I'm excited to see how it plays out.

Given that x/mobile/gl windows support recently got labelled unplanned, perhaps it would be simpler to add Android support to go-gl?

To answer your question, I need to better understand what the end goal/motivation is. Can you elaborate on that please?
Namely, are we looking to maintain current OS X/Linux/Windows support, but also add Android support? What about Web support?

@ben-clayton After talking with @shurcooL a bit over Slack, it appears I've probably misunderstood.
If we go with go-gl/gl here, we'll effectively have to add separate duplicate drivers gxui/drivers/gl3 (Windows/Linux/OSX) gxui/drivers/gles2 (Android/iOS) and gxui/drivers/webgl (HTML5). It would be difficult compared to what adding Windows support to /x/mobile/gl would probably take.

The reason I'm asking for additional clarification here is because at this point, from the information I see above, my thoughts are that no, it would not be simpler to add Android support to go-gl than it would be to add Windows support to x/mobile/gl.
The main reason is that go-gl/gl is not a universal API with multiple backends (the way x/mobile/gl is). It is a collection of distinct low level specific OpenGL API bindings. So if you import go-gl/gl/2.1/gl you get OpenGL 2.1, if you import go-gl/gl/4.5/gl you get OpenGL 4.5, and if you import a hypothetical - it does not exist - go-gl/gles/2.0/gles package, you get OpenGL ES 2.0 bindings. So then gxui/drivers/gl would need to import multiple bindings depending on the environment and do all that. x/mobile/gl already has that work done inside, it's just missing Windows support, which is a lot easier to add.

The main reason is that go-gl/gl is not a universal API with multiple backends (the way x/mobile/gl is). It is a collection of distinct low level specific OpenGL API bindings. So if you import go-gl/gl/v2.1/gl you get OpenGL 2.1, if you import go-gl/gl/v4.5-core/gl you get OpenGL 4.5 Core Profile, and if you import a hypothetical - it does not exist - go-gl/gles/2.0/gles package, you get OpenGL ES 2.0 bindings.

I understand that. My thought was that we could use the same OpenGL ES 2 bindings on Android and on desktop. I know there are subtle differences between GLES and OpenGL, but for what GXUI uses that difference is not substantial.
Unless there's something I'm missing, this would mean Windows, OSX, Linux and Android would all use this hypothetical GLES 2 go-gl, leaving WebGL as the 'other' target. For that, I was thinking that we could create a simple renderer library to sit between GLES2/WebGL and the gxui/driver. This renderer library would expose the small interface required by GXUI, which in the current form is a handful of GL APIs. We could grow this renderer library as the GXUI driver matures, but I don't see a great deal of additional features for delivering GXUI V1.

My thought was that we could use the same OpenGL ES 2 bindings on Android and on desktop. I know there are subtle differences between GLES and OpenGL, but for what GXUI uses that difference is not substantial.

Desktop Linux supports OpenGL ES, but OS X (10.10) does not support OpenGL ES. I'm not sure about the status of OpenGL ES support in Windows, but it may be mixed or unsupported. [1] [2]
So by switching to using OpenGL ES bindings, you would lose OS X and possibly Windows support, maintain Linux support, and gain Android support.
Additionally, it would become harder or impossible to add a web backend.
Am I understanding things correctly?
[1] http://www.g-truc.net/post-0457.html
[2] https://github.com/glfw/glfw/blob/5733b0e4cb885c51b4ecb6c41bc2fb2b88b4b407/src/nsgl_context.m#L68-L73

Unless there's something I'm missing, this would mean Windows, OSX, Linux and Android would all use this hypothetical GLES 2 go-gl

If you have references showing that OS X and Windows have support for OpenGL ES, please point me to it. As far as I know, on desktop side, only Linux has full support for OpenGL ES. Windows and OS X do not support OpenGL ES, only OpenGL.

For reference, x/mobile/gl uses OpenGL ES on Linux, but OpenGL on OS X. /cc @crawshaw
/*
#include <stdlib.h>

#ifdef os_linux
#include <GLES2/gl2.h>
#endif
#ifdef os_darwin_arm
#include <OpenGLES/ES2/glext.h>
#endif
#ifdef os_darwin_amd64
#include <OpenGL/gl3.h>
#endif
*/
import "C"

So, my understanding is this:

OpenGL ES 2 is an (almost perfect) subset of OpenGL 3.1, but the profile must also support EGL. The key differences are mostly straight-up fewer APIs, but the incompatible differences are nearly all to do with GLSL.
Given that the exposed functions a simple subset, go-gl should be able to resolve the GLES 2 function addresses (all with matching signatures) even if the context was built with a OpenGL profile.
Having a context created with the OpenGL ES 2 profile simply means the driver should conform to the OpenGL ES 2 spec. So, the driver should throw errors when calling functions or passing arguments that are not part of the profile, and the driver should handle GLSL slightly differently. Khronos made sure that GLES 2 kept the function signatures the same as desktop GL, even though this resulted in many APIs requiring arguments to be a fixed constant value.

If my understanding is correct, none of what I've described should be a problem for GLES 2 go-gl function resolving on desktop - the OpenGL ES / OpenGL differences are all problems to be handled externally - i.e. by this renderer abstraction I mentioned.

@ben you are right,just as cocos2d-x do. we need not export all opengles api,we just export gxui api based on window&control&canvas&font. we should do more on layout,advanced control.

I've rebased, and pushed commit cbf18e7 that changes to use a fork of golang.org/x/mobile/gl with Windows and browser support added. See https://github.com/goxjs/gl. See last few comments at https://go-review.googlesource.com/#/c/8793/ for rationale why a that CL will not be merged as is (at this time), and therefore a temporary fork makes sense until a new upstream replacement package is available.
Therefore, this PR is now:

This PR modifies the gl driver to use a fork of golang.org/x/mobile/gl package with Windows and browser support added. This package offers a slightly higher level interface, with desktop (OS X, Linux, Windows), mobile (iOS, Android) and desktop, mobile browsers backends.

Because Windows support is preserved with the new package, this PR may be viable to merge, and therefore I think it can be reviewed.
I've tested most samples, everything continues to work for me (and everything should be completely go gettable).

Hi @shurcooL,
Thank you. I'll try to find time to check this out this weekend. Do you have any instructions on how to try out the WebGL renderer?

Awesome, thank you @ben-clayton!
I will provide instructions on how to do that soon!

I had to do a little work to implement creating fullscreen windows, since you've added a fullscreen sample and I wanted to make it work.
I was able to get it to work in browser (via Fullscreen API), but with a caveat.
http://virtivia.com:27080/3p0e9akjg1yj.mov
The caveat is that it works well when toggling the button with keyboard (tab to select, then enter or space). But not so well with the mouse... because by the time event is processed, the "mouse up" callback has returned and I can only use fullscreen API in user event handlers, so it has to wait until the next user event. Full details at https://github.com/goxjs/glfw/issues/3.

Ok, @ben-clayton, here are precise steps to run gxui samples in the browser via GopherJS.
Preface
To allow gxui to run in browser, we need support for 3 things: window/context creation, user input, and GL bindings. This PR is to go from OpenGL 2.1 API (via github.com/go-gl/gl/v2.1/gl package) to an OpenGL ES 2-like API (via github.com/goxjs/gl package). However, this PR does not address window/context creation and user input (currently provided by the github.com/go-gl/glfw/v3.1/glfw package).
So, in order for OpenGL programs to run both on desktop and in browser, I've created github.com/goxjs/glfw package. By using build tags, it simply reuses github.com/go-gl/glfw/v3.1/glfw on OS X, Linux and Windows desktop platforms, but it implements window/context creation and user input by using browser APIs (HTML5, Canvas element, Fullscreen API, Mouse Lock API, etc.) in browsers (under js architecture build tag). Since this PR doesn't include that change (this PR is strictly about switching from using OpenGL 2.1 to OpenGL ES 2.0 to make it browser/mobile-compatible), you'll need to checkout a different branch. It's exactly one small commit ahead, see shurcooL/gxui@2dab5ce.
Steps

Install the latest GopherJS compiler.

go get -u github.com/gopherjs/gopherjs

2. Fetch and checkout my use-goxjs-glfw branch, download dependencies.

    ```bash
cd $GOPATH/src/github.com/google/gxui

# Fetch and checkout my use-goxjs-glfw branch.
git fetch https://github.com/shurcooL/gxui use-goxjs-glfw
git checkout FETCH_HEAD
git branch use-goxjs-glfw

# Go get dependencies (there may be some additional ones under js build tag).
# Note that this is only needed because my work is on a different repository and branch,
# otherwise one could just do go get -u -d -tags js github.com/google/gxui and be done.
go get -u -d -tags js ./...

# May need to switch back to use-goxjs-glfw branch since go get -u may go back to master.
git checkout use-goxjs-glfw

Use gopherjs serve as a convenience way to build Go packages using GopherJS and serve them.

Run in some terminal and keep it open.
gopherjs serve

(This is recommended because it's faster/easier. If you want to actually build the javascript file and bring your own HTML (just one that uses a \<script> tag to run the javascript), then run `gopherjs build github.com/google/gxui/samples/panels` to do that. But then you need to create some html and open it in browser.)

4. Open a WebGL-capable browser and navigate to:

http://localhost:8080/github.com/google/gxui/samples/panels

Change URL to try out different samples.

Thanks and let me know if something doesn't work!

Thanks for the detailed info @shurcooL.
I gave the Windows build a try, and unfortunately we get a fatal error on start up initializing gl:
gl.Init: glActiveTexture
I believe the problem is that gl.Init must be called after MakeCurrentContext as wglGetProcAddress requires a bound context: When no current rendering context exists or the function fails, the return value is NULL.
However, I can get things running by:

Adding to Window in desktop.go:

func (w *Window) MakeContextCurrent() {
	w.Window.MakeContextCurrent()
	contextSwitcher.MakeContextCurrent(w)
}

func DetachCurrentContext() {
	glfw.DetachCurrentContext()
	contextSwitcher.MakeContextCurrent(nil)
}

And replacing the dummy ContextSwitcher in gl_windows.go with:

// ContextSwitcher is this library's GL context switcher. It facilitates switching
// between GL contexts, satisfying ContextSwitcher interface.
var ContextSwitcher contextSwitcher

type contextSwitcher struct{}

func (contextSwitcher) MakeContextCurrent(context interface{}) {
	if context != nil {
		if _, seen := contexts[context]; !seen {
			// First time this context has been made current. Initialize gl.
			contexts[context] = struct{}{}
			err := gl.Init()
			if err != nil {
				log.Fatalln("gl.Init:", err)
			}
		}
	}
}

var contexts = map[interface{}]struct{}{}

This feels a little hacky, but not significantly more than the WebGL context. :) Feel free to ignore this suggestion if you can think of any better solutions.
Cheers.

Thanks for the detailed issue report @ben-clayton!
I had actually tested the Windows backend on OS X, that's why this slipped under my radar. I was a little surprised when I tried placing gl.Init() inside of init() in the gl package and it still worked, but I can see that's not the case for Windows since its wglGetProcAddress requires a bound GL context.
I will absolutely fix this. Thank you for your suggestion, I like it a lot actually. It's interesting how it's quite similar to the ContextSwitcher work that needs to happen for WebGL contexts.
I can only think of one other simpler alternative: I could reinstate the gl.Init() func and make it a requirement to run it after context has been set, just as is the case with go-gl/gl/2.1/gl. It would be a noop on platforms where it's not needed.
However, I think your approach is nicer for two reasons: it makes the user code more simple and eliminates a possible user error. As long as it works in all situations, which I think it would, it's better to do more work inside glfw and gl. The other reason is that it'd be more consistent with the way the WebGL bindings are initialized via the ContextSwitcher, having two different ways to initialize would be suboptimal.
Have you had a chance to try it on OS X, Linux and in the browser yet?

Ok, I've resolved the issue you reported (see goxjs/gl#6 for full details). If you can update dependencies to latest versions, and the new commit at use-goxjs-glfw branch of my fork (shurcooL/goxui@395cb0bc0c0febfdbb3f3c029cd917f39d8a4514), I believe it should work. Please let me know your findings.

I can confirm Windows and OSX work fine, both in desktop mode and in the browser. I haven't tried linux as I need to dust off my linux-box. I'll try in the coming week.
It's very cool. Good work!
I have a few minor concerns I hope we can address before accepting the PR:

As I commented above, I'd like to remove the dependency on golang.org/x/mobile/f32 if possible.
Unless there's a reason for it, I'd also like to remove the transitive dependency on honnef.co/go/js/xhr.
Calling gl.Init() every time a context is made current isn't good. You mentioned exactly my concern on this bug: GXUI can make frequent switches between contexts when we have multiple windows open. If you have two windows animating, I'm guessing performance is going to suck.

This brings me to the ContextWatcher:

Perhaps we could add a ContextWatcher.OnCreate(Context) method to the interface for the gl.Init logic?
Super-nit - Why not use the name ContextWatcher.OnAttach instead of OnBecomeCurrent?

It's very cool. Good work!

Thanks! And thanks for reviewing @ben-clayton! I will gladly address and respond to your comments in the near future.

As I commented above, I'd like to remove the dependency on golang.org/x/mobile/f32 if possible.

It is possible, two ways, which would you prefer? See my reply inline at https://github.com/google/gxui/pull/86#discussion_r31706364.

Unless there's a reason for it, I'd also like to remove the transitive dependency on honnef.co/go/js/xhr.

There is a good reason for it, but it can be moved elsewhere or replaced with net/http. See my detailed response at https://github.com/goxjs/glfw/issues/4#issuecomment-108752326.

Calling gl.Init() every time a context is made current isn't good.

I've opened https://github.com/goxjs/gl/issues/7 and will work on resolving it there.

Perhaps we could add a ContextWatcher.OnCreate(Context) method to the interface for the gl.Init logic?

Can you please elaborate on how you envision it being used? Would it be so that gl.Init is called only when a new context is created for the first time, but not called when that context is made current subsequently? If I understand things correctly, this has the potential to cause issues if contexts are very incompatible (e.g., different video card hardware). However, it is unlikely, and it would be the same behavior as most OpenGL Go apps, including gxui now - which simply calls gl.Init once at startup.

Super-nit - Why not use the name ContextWatcher.OnAttach instead of OnBecomeCurrent?

Honestly, I had a hard time coming up with good names, and I never thought of OnAttach. I can change it easily. However, after thinking more about it, I think I like the current OnBecomeCurrent and OnDetached names better, because they mirror the language being used:
func (w *Window) MakeContextCurrent() // MakeContextCurrent makes the context of the window current.
func DetachCurrentContext() // DetachCurrentContext detaches the current context.

Also consider http://www.glfw.org/docs/latest/context.html.

This function makes the OpenGL or OpenGL ES context of the specified window current on the calling thread. A context can only be made current on a single thread at a time and each thread can have only a single current context at a time.
[in]	window	The window whose context to make current, or NULL to detach the current context.

As you can see, the surrounding language is consistently "make context current" and "detach [current] context". The word "attach" is never used, so OnBecomeCurrent sounds good to me.

I have addressed all points mentioned above, PTAL @ben-clayton.

As I commented above, I'd like to remove the dependency on golang.org/x/mobile/f32 if possible.

Done in c4e1bc165b279898d21657273fbd390c08d5a1f0.

Unless there's a reason for it, I'd also like to remove the transitive dependency on honnef.co/go/js/xhr.

Resolved in https://github.com/goxjs/glfw/issues/4#issuecomment-109212033.

Calling gl.Init() every time a context is made current isn't good.

Resolved in https://github.com/goxjs/gl/issues/7.

Super-nit - Why not use the name ContextWatcher.OnAttach instead of OnBecomeCurrent?

See motivation in my previous comment; for consistency I renamed it to OnMakeCurrent in https://github.com/goxjs/glfw/pull/5 and https://github.com/goxjs/gl/pull/8.
I also had to add calls to gl.ContextWatcher.OnMakeCurrent(nil) in place of where gl.Init() was previously, since this PR uses go-gl/glfw/v3.1/glfw which does not take on the responsibility of notifying the GL bindings of context changes via gl.ContextWatcher. See 834a38e9f7d51ca79038f0e0fb92edf254b34e71. This is because goxjs/gl bindings require that (well, on Windows backend only, but that's an internal detail). This will not be needed after switching to goxjs/glfw which adds support for browser (remember, this PR is only about changing the GL bindings an necessary changes to go from OpenGL 2.1 API to OpenGL ES 2.1 API).
I think that's all the remaining issues on my side, I'm not aware of any remanning ones. The only thing left from my side on this PR are various shortcuts taken, if you grep for the keyword "HACK" in comments. I'd appreciate suggestions on how to resolve those. It's also fine if you merge as is and clean up those shortcuts yourself in followup commits.

I've documented usage of goxjs/gl bindings (related to its ContextWatcher mechanism) in https://github.com/goxjs/gl/commit/d4a36dde034f885e1dafae350b058cb763fd1e8a?short_path=04c6e90.

I finally got around to testing on linux, and unfortunately on my desktop machine I get the following panic on startup:
$ $GOPATH/bin/polygon
panic: PlatformError: Failed to retrieve context version string

goroutine 1 [running, locked to thread]:
github.com/go-gl/glfw/v3.1/glfw.acceptError(0xc208067cb8, 0x2, 0x2, 0x0, 0x0)
	/usr/local/google/home/bclayton/src/github.com/go-gl/glfw/v3.1/glfw/error.go:164 +0x145
github.com/go-gl/glfw/v3.1/glfw.CreateWindow(0x320, 0x258, 0x7084d0, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/google/home/bclayton/src/github.com/go-gl/glfw/v3.1/glfw/window.go:264 +0x165
github.com/google/gxui/drivers/gl.newViewport(0xc20801e040, 0x320, 0x258, 0x7084d0, 0x7, 0x0, 0xc208067e80)
	/usr/local/google/home/bclayton/src/github.com/google/gxui/drivers/gl/viewport.go:79 +0x1a4
github.com/google/gxui/drivers/gl.func·019()
	/usr/local/google/home/bclayton/src/github.com/google/gxui/drivers/gl/driver.go:196 +0x66
github.com/google/gxui/drivers/gl.func·012()
	/usr/local/google/home/bclayton/src/github.com/google/gxui/drivers/gl/driver.go:61 +0x2f
github.com/google/gxui/drivers/gl.(*driver).driverLoop(0xc20801e040)
	/usr/local/google/home/bclayton/src/github.com/google/gxui/drivers/gl/driver.go:82 +0x75
github.com/google/gxui/drivers/gl.StartDriver(0x796c40)
	/usr/local/google/home/bclayton/src/github.com/google/gxui/drivers/gl/driver.go:51 +0x2b9
main.main()
	/usr/local/google/home/bclayton/src/github.com/google/gxui/samples/polygon/main.go:84 +0x2a

I'm guessing this is the switch from using OpenGL 2.1 to OpenGL ES 2. It is my understanding that GLES on desktop GPUs is not commonly supported. I'm also not sure why we're using OpenGL on Windows and OSX but GLES on linux. Is there a reason for this split?
If you'd like me to try getting goxjs/gl running on linux, I can try and reserve some time this week.
Cheers.

Thanks for testing it out on Linux, I will look into that issue.

It is my understanding that GLES on desktop GPUs is not commonly supported. I'm also not sure why we're using OpenGL on Windows and OSX but GLES on linux. Is there a reason for this split?

Yes, the reason is very simple. It's how the original golang.org/x/mobile/gl package was, and at this time, goxjs/gl is simply a fork of x/mobile/ with browser (WebGL, implemented directly rather than through another package) and Windows (via github.com/go-gl/gl/v2.1/gl package) back ends added. I simply haven't done anything to the OS X and Linux paths so far.
I don't know exactly why @crawshaw decided to implement Linux desktop support via OpenGL ES, but I have a guess (please confirm or correct me), it's likely because the x/mobile/gl package started out, as its name implies, by having OpenGL ES bindings for iOS and Android, and desktop support was added later, likely in a way that was simpler.

If you'd like me to try getting goxjs/gl running on linux, I can try and reserve some time this week.

Thanks, but it would be very easy for me to fix this by having the current Windows backend (via go-gl/v2.1/gl package) also take on Linux and maybe OS X as well. The go-gl/v2.1/gl package supports OS X, Linux and Windows well. Do you think that's the way to go?

The go-gl/v2.1/gl package supports OS X, Linux and Windows well. Do you think that's the way to go? /cc @slimsag

Yeah, keeping with what we know works sounds like a good approach to me. :)

Sorry, I said "This is needed to resolve google/gxui#86 (comment)." there and that closed this PR, that was unintentional.

Yeah, keeping with what we know works sounds like a good approach to me. :)

This is done now, see https://github.com/goxjs/gl/pull/9.
I'll be making one followup commit here to update dependencies (no longer need to fetch OpenGL ES libraries).

@ben-clayton, I have resolved the outstanding issues mentioned above, PTAL.
I've tested and gxui samples worked for me on OS X and Linux (Ubuntu 14.04 in a VirtualBox). Although it worked for me on Linux with OpenGL ES backend as well. Please let me know if it fixes your Linux test (where you don't have OpenGL ES support seemingly).

So linux runs again (yay!), windows does not (boo!).
I'm not too sure what happened during this PR, but somewhere along the way we've lost the changes to import "github.com/goxjs/glfw" instead of "github.com/go-gl/glfw/v3.1/glfw".
Fixing up all of these (and changing the glfw.Init to take the gl.ContextWatcher locally makes windows work again.

It is my understanding that GLES on desktop GPUs is not commonly supported.

On linux, you normally need to be running a mesa driver (intel, nouveau) to get EGL support, otherwise it will likely fail. With the push towards wayland, which currently requires EGL to avoid pulling in X, we should start seeing support from proprietary drivers soon (if it's not there already, haven't been keeping up with it).

I'm not too sure what happened during this PR, but somewhere along the way we've lost the changes to import "github.com/goxjs/glfw" instead of "github.com/go-gl/glfw/v3.1/glfw".

That's intended. I wanted to keep the two PRs separate so that the change to glfw can be reviewed separately. From my comment above:

Reminder, this PR is only about changing the GL bindings an necessary changes to go from OpenGL 2.1 API to OpenGL ES 2.1 API.

However, I would expect Windows to work, because of the change I've done in commit 834a38e9f7d51ca79038f0e0fb92edf254b34e71. From the comment above:

I also had to add calls to gl.ContextWatcher.OnMakeCurrent(nil) in place of where gl.Init() was previously, since this PR uses go-gl/glfw/v3.1/glfw which does not take on the responsibility of notifying the GL bindings of context changes via gl.ContextWatcher. See 834a38e9f7d51ca79038f0e0fb92edf254b34e71. This is because goxjs/gl bindings require that (well, on Windows backend only, but that's an internal detail). This will not be needed after switching to goxjs/glfw which adds support for browser.

So linux runs again (yay!)

Great!

windows does not (boo!)

Can you please provide more information, so I can look into it and fix it. I expect it to work with the current PR (and latest versions of dependencies). If there's a panic, can you please post a trace? I'll see if I can setup a Windows machine to test it myself later.

Sorry, I've had a manic day today and my brain didn't properly context-switch in the 10 minutes I got to test this out. I'm not sure why your OnMakeCurrent calls didn't fix the issue, but it's possible I screwed up something when fetching the PR on the windows box.
I'll have another test tomorrow morning. Like you say, I can't see why this wouldn't work.
Thanks for bearing with me, and sorry for being so slow in replying.

No problem, thank you for spending the time on this PR and helping review it in addition to all the other work you're doing!

Hi David,
I have tested this PR on a Windows machine I was able to get access to, and it worked without any issues. Both the current version gxui, as well as this PR branch, worked equally well. This is as I expected.

I'm not sure why your OnMakeCurrent calls didn't fix the issue, but it's possible I screwed up something when fetching the PR on the windows box.
I'll have another test tomorrow morning. Like you say, I can't see why this wouldn't work.

I recommend using gostatus to confirm that all dependencies are latest versions and not checked out on some non-master branch, etc.
If you run it like this:
# Show status of all dependencies (recursive) of all gxui packages.
$ go list -f '{{join .Deps "\n"}}' github.com/google/gxui/... | gostatus --stdin -v

The output should be exactly this:
b    github.com/google/gxui/...
     code.google.com/p/freetype-go/...
     github.com/go-gl/gl/...
     github.com/go-gl/glfw/...
     github.com/goxjs/gl/...

The b under github.com/google/gxui/... is expected because you're likely going to have this PR checked out on a different branch. But all other deps should be with a clean status (up to date, master branch checked out, not a dirty working tree, etc.).

Tried again, and it is working on windows. Accepting the PR. Thanks :).

Thank you for reviewing and merging!


Fixed some typos in the Getting Started guide

Amazing - thanks

@orta wow that was a fast merge, I was just about to make a few other changes!

Hah, it was an obvious win 👯 \


feat : dependabot workflow automation for updating dependency

What type of PR is this?
/kind feature
What this PR does / why we need it:
Dependabot workflow automation for updating dependency
Does this PR introduce a user-facing change?:
NONE

Signed-off-by: Pratik Raj<EMAIL_ADDRESS>

Hi ! Have you considered adding pip and docker package-ecosystems ?

/ok-to-test


Just --fmt step in build action fails after the release of just 1.18

This is the second sequential just minor version bump that cause our pipeline to fail.
We should consider:

locking the justfile format check to use a specific version (if possible)
removing the step altogether

In any case we probably want some way to stabilize the automatic builds while still enable us to run the latest version of just

The problem has been somewhat alleviated by adding a justfile in the repo allowing for easy formatting of the justfiles in the repo before pushing.
Let's reopen if this still is a big inconvenience.


Donate Button

I would love to give you a donation to your project. I have been an Excalidraw user for over 3 years and I have been using Obsidian with the plugin, but this makes sharing drawings terrible. Your tool is perfect.

Thank you very much for your love and appreciation for ExcalidrawZ.
The integration of donation is on the way 😁.
If you have any needs or suggestions, please do not hesitate to bring them up.

Hi @jfuqua7, I’m happy to tell you that I finally managed to set up the donation channel, so you can buy me a coffee here.

By the way, if you update the app, the annoying sound when selecting the tool has gone.
If there are no other issues, I will close this issue. 😄

buymeacoffee.com/Chocoford


flet build apk -- verbose error v0.20.0

Hello everyone.
I have tried to run the following command
flet build apk --verbose
but i have a error:
Flutter bootstrap directory: C:\xxx\DESARR~1\AppData\Local\Temp\flet_flutter_build_iJocUHqJab
Additional Flutter dependencies:
{}
Creating Flutter bootstrap project...OK
Customizing app icons and splash images...OK
Generating app icons...
Run subprocess: ['C:\flutter\bin\dart', 'run', 'flutter_launcher_icons']
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in run_code
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Scripts\flet.exe_main.py", line 7, in
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\site-packages\flet\cli\cli.py", line 83, in main
args.handler(args)
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\site-packages\flet\cli\commands\build.py", line 585, in handle
icons_result = self.run(
^^^^^^^^^
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\site-packages\flet\cli\commands\build.py", line 814, in run
r = subprocess.run(
^^^^^^^^^^^^^^^
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\subprocess.py", line 548, in run
with Popen(*popenargs, **kwargs) as process:
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\subprocess.py", line 1026, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\xxx\DESARROLLO\AppData\Local\Programs\Python\Python312\Lib\subprocess.py", line 1538, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [WinError 193] %1 is not a valid Win32 application
any suggestions? thanks.

It's Python 3.12.0 specific issue. Upgrade your Python installation to 3.12.2.

I have a problem and it stops converting the application to apk
PS C:\Users\ninja\Desktop\PythonFile\f\myapp> flet build apk --verbose
Flutter bootstrap directory: C:\Users\ninja\AppData\Local\Temp\flet_flutter_build_QDuuckPBts
Additional Flutter dependencies:
{}
Creating Flutter bootstrap project...OK
Customizing app icons and splash images...Copying C:\Users\ninja\Desktop\PythonFile\f\myapp\assets\icon.png to
C:\Users\ninja\AppData\Local\Temp\flet_flutter_build_QDuuckPBts\images
OK
Generating app icons...
Run subprocess: ['C:\Program Files\flutter\bin\dart.BAT', 'run', 'flutter_launcher_icons']
and he stop here


docs: Fixed validator names in cloud_firestore_odm to start with an uppercase letters

Description
The example of the cloud_firestore_odm validator starts with a lowercase letter. Corrected min to Min and max to Max.
Related Issues
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (melos run analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[x] No, this is not a breaking change.

Thanks!
Could you accept the CLA?

Could you accept the CLA?

@rrousselGit
Thanks for the confirmation!
I approved the CLA, but it doesn't seem to be reflected. Could you please re-run it?


feat: support custom default system prompt

Resolved #251
In addition, I have an idea to share with you: I am planning to add a default folder to store a set of recommended default prompts, making it more convenient for users to access and notice this feature.
What do you think about this idea? I will create a PR for it.

It would be great if the user can change the default prompt from the UI. Currently, you are setting it using the environment variable that works for users who host this app manually.

And as for this default part, I was thinking there should be a prompt library that we could add from a GitHub repo maybe where people can share popular prompts and it will be available as a separate tab in prompt bar.
Let me know what do you think about this @mckaywrigley

It would be great if the user can change the default prompt from the UI.

Great suggestion, I just have a very initial idea and welcome everyone to improve it. I am willing to create a PR for this.

Currently, you are setting it using the environment variable that works for users who host this app manually.

Yes, this is to solve #251.

Great suggestion, I just have a very initial idea and welcome everyone to improve it. I am willing to create a PR for this.

I think you should add the PR for this so that it would be easier for users to change the default prompt from the UI if you are willing to do that.

I love the work I see going in to this project and hope to be able to help somehow ( I can code but, some python, PHP, MySQL, HTML, etc)
I am new here so, I hope this is in accordance with the topic....
This system prompt, I assume is so named for the benefit of multi-model use cases. I figure mostly it will become the system role for gpt3.5 and 4.
I experimented with the curie and davinci models up through 3.5turbo (with system role) system prompts and they responded well using first person.
Also with the current tiff with openAI and chatGPT having that site taken down it's probably just that they ask everyone not to use their name etc tied to ai generative stuff so... they probably don't want to see there model name there either they said something to the effect that you take ownership of the models output so... I volunteer this system role for your use case to edit or use or not as you see fit, and solve the other issues as notes to developers with reference to open ai etc and on the project page none of the sort even the footer should all be chatbot-ui...
system role:
I am chatbot-ui. As an AI intellectual booster, I gather and analyze data from various sources using advanced algorithms and natural language processing techniques to identify patterns and trends. I adapt to my client's needs, constantly learning and providing valuable insights to help them achieve their goals more effectively. With my ability to process information quickly and accurately, I provide recommendations that are impossible to obtain otherwise. I help clients achieve success by providing the tools and knowledge to excel, whether they're working on a complex problem or trying to stay ahead of the competition.


Adapter red

Hello,
First of all a big thank you for providing this adapter.
Since a few days the adapter turns to red, red, green.  Before this I was able to use it without  any problems.
Here is my log...
2021-10-03 00:14:02.327 - info: lg-thinq.0 (9842) starting. Version 0.0.1 in /opt/iobroker/node_modules/iobroker.lg-thinq, node: v14.17.2, js-controller: 3.3.18
2021-10-03 00:14:05.065 - info: lg-thinq.0 (9842) Login successful
2021-10-03 00:14:05.637 - error: lg-thinq.0 (9842) Error: Request failed with status code 400
2021-10-03 00:14:05.643 - error: lg-thinq.0 (9842) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2021-10-03 00:14:05.645 - error: lg-thinq.0 (9842) unhandled promise rejection: Cannot read property 'length' of undefined
2021-10-03 00:14:05.649 - error: lg-thinq.0 (9842) TypeError: Cannot read property 'length' of undefined
at LgThinq.getListDevices (/opt/iobroker/node_modules/iobroker.lg-thinq/main.js:470:40)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async LgThinq.onReady (/opt/iobroker/node_modules/iobroker.lg-thinq/main.js:94:37)
2021-10-03 00:14:05.652 - error: lg-thinq.0 (9842) Cannot read property 'length' of undefined
2021-10-03 00:14:05.840 - info: lg-thinq.0 (9842) terminating
2021-10-03 00:14:05.841 - warn: lg-thinq.0 (9842) Terminated (UNCAUGHT_EXCEPTION): Without reason
2021-10-03 00:14:06.425 - error: host.raspberrypi instance system.adapter.lg-thinq.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2021-10-03 00:14:06.426 - info: host.raspberrypi Restart adapter system.adapter.lg-thinq.0 because enabled
Can anyone help
Best regards

I add additional logging please reinstall. But it looks like you have no homes in your account

Hi TA2k
I got it running again. It crashed due to missing new agreements to LGs new terms of use. After clicking these in the app the adapter seems to work properly again.
Thank you so much for this nice adapter and your fast response
Best regards


Decrease flush interval and bump debezium version

Incorporates #25, which was closed due to git shenanigans

Looks good to me.


Integer Overflows aren't handled properly

When the calculated permission is higher than 2 147 483 647 (Hex: 7FFFFFFF) then an integer overflow occurs and the calculation wraps to -2 147 483 648. This is because a signed integer is a 2^31 number (32 bits). When this limit is reached the signing bit changes (0 -> 1) and the integer becomes a negative value.
So you can't calculate permission that extends 2 147 483 647.

Blame JavaScript and how it does numbers and bitwise operations in general.
Does any Discord permission actually have a value greater than 2^32 - 1?

I found out that all permissions from discord calculated into 1 bitfield are exactly 2 147 483 647. It seems like the calculator is calculating wrong.


COST-374: Cost model empty state appears at bottom of page

Fixed cost models empty state so it's not at the bottom of the page
https://issues.redhat.com/browse/COST-374
Before

After

Codecov Report

Merging #1623 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1623   +/-   ##
=======================================
  Coverage   78.65%   78.65%
=======================================
  Files         240      240
  Lines        3926     3926
  Branches      718      718
=======================================
  Hits         3088     3088
  Misses        740      740
  Partials       98       98

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 851fbd5...69e86b6. Read the comment docs.

LGTM


Fix the text on the send and receive screens

The text at the bottom of the BOTH screens should say:

For Receiver: For the transaction to complete, you should get online during the 12 hours after Beams are sent.
For Sender: For the transaction to complete, the recipient must get online within the next 12 hours and you should get online within 2 hours afterwards.

@alexandrashelenkova please update the text on receive screen in Zeplin.

@DenisDemyanko @alexandrashelenkova the text was updated for both Send and Receive screens: please see description

checked


Translate to Hindi

I want to translate it into Hindi, for most Indian people who do not understand English properly, how can I do it can someone tell me the stepwise procedure

Hello @savmg, sorry i didn't understand what need to be translate in hindi?

@savmg  If it would be possible then can you assign me to this issue I want to resolve this

@pragyamishra56 that’s not how things work on github; issues aren’t assigned like that. You just make a PR if you want to work on something.

@ljharb Thank you for guiding me Sir

Greetings @hyperingenious and @savmg, I'm unclear on the reason behind translating this into Hindi. If the translation is pursued, it could impact the website's ranking and SEO. However, this doesn't pose a problem. It's important to note that implementing the translation requires additional effort at the architectural level.


Correction for raw affiliation Elsa, Research Group for Environmental Lifecycle and Sustainability Assessment, Montpellier, France; IFP Energies Nouvelles, 1 et 4 Avenue de Bois-Préau, 92852 Rueil-Malmaison, France; LBE, Montpellier SupAgro, INRA, UNIV Montpellier, Narbonne, France

Correction needed for raw affiliation Elsa, Research Group for Environmental Lifecycle and Sustainability Assessment, Montpellier, France; IFP Energies Nouvelles, 1 et 4 Avenue de Bois-Préau, 92852 Rueil-Malmaison, France; LBE, Montpellier SupAgro, INRA, UNIV Montpellier, Narbonne, France
raw_affiliation_name: Elsa, Research Group for Environmental Lifecycle and Sustainability Assessment, Montpellier, France; IFP Energies Nouvelles, 1 et 4 Avenue de Bois-Préau, 92852 Rueil-Malmaison, France; LBE, Montpellier SupAgro, INRA, UNIV Montpellier, Narbonne, France
new_rors: 03rnk6m14;03gcbhc33;03573dx38;022m8c549
previous_rors: 03rnk6m14;03gcbhc33;03573dx38
works_examples: W2921724567
contact: e63bd893df40183eddaa4666aafbed08:df52999781470e5a1f92201d0a082d97825f @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-09. The new affiliations should be visible within the next 7 days.


Show title and description ( list items layout ) in selected item for Dropdown

Summary
Show title and description ( list items layout ) in selected item for Dropdown
Examples
Show title and description ( list items layout ) in selected item for Dropdown
Motivation
Show title and description ( list items layout ) in selected item for Dropdown
Search keywords: Show title and description ( list items layout ) in selected item for Dropdown

Hi @vjoshi92, can you explain what your issue is in more detail? (You could link to a code repository showing the problem you're facing, or maybe a section of the documentation that's unclear.)


fix: 🐛 Handle ProposalAdded case from approve_join_identity

Description
Proposal details are missing in ProposalAdded event when invoked from approve_join_identity extrinsic. This adds in the underlying proposal details to prevent SQ from breaking
Breaking Changes
NA
JIRA Link
DA-1394
Checklist

[ ] Updated the Readme.md (if required) ?

/fast-forward


NonEmptyText should be a lower bound not an upper bound and fixes a f…

…ew functions & tests accordingly.

@friedbrice okay so I didn't realize this package was doing an upper bounds check on the Nat, which was not my intuition for how this should behave.
Dug in an "fixed" everything where NonEmptyText 10 was setting a range and changed 10 to be a lower bound.


[SR-3658] Can't build CoreFoundation on Ubuntu 16.04, January 16

Previous ID
SR-3658

Radar
None

Original Reporter
ewconnell (JIRA User)

Type
Bug

Environment
Ubuntu 16.04

Additional Detail from JIRA

Votes
5

Component/s
Compiler, Foundation

Labels
Bug, Linux

Assignee
None

Priority
Medium

md5: 39b731dec7a0058949a21269d2dc8b64

relates to:

SR-3648 Unable to Import Foundation

Issue Description:
I tried updating my Ubuntu 16.04 build to use the January 16, 2017 snapshot. Jan 15 failed the same way. Swift build can't seem to find Block.h, which appears to be in the tree. If I specify that directory explicitly so it can find it, then it can't find the C++ <vector> header.
So something is definitely broken. My project builds fine with the Dec 13 release.
This is the output that is repeated over and over
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^
/home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:56:10: note: in file included from /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:56:
#include <CoreFoundation/CFBase.h>
         ^
/home/ed/swift/usr/lib/swift/CoreFoundation/CFBase.h:72:10: error: 'Block.h' file not found
#include <Block.h>
         ^
<unknown>:0: error: could not build Objective-C module 'CoreFoundation'
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^
/home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:56:10: note: in file included from /home/ed/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:56:
#include <CoreFoundation/CFBase.h>
         ^
/home/ed/swift/usr/lib/swift/CoreFoundation/CFBase.h:72:10: error: 'Block.h' file not found
#include <Block.h>

etc....

Any ideas??

This older issue seems to be fixed or no longer relevant.


Make default OAuth 2.0 client type "public" for development

The OAuth 2.0 application created by default uses the "confidential" OAuth 2.0 client type. We need a "public" client type in development for our frontend to speak to the backend over unencrypted HTTP.

@mcovalt, could you give more information on this? I'm surprised this happens by default since we're using stock Girder4 for this project. Do other projects need to worry about this as well?

This issue was created after walking through #38 with @naglepuff. I think they were referencing a guide from another Girder 4 project. Is that right, @naglepuff? Which project was that?

That's correct. I was following the guide here from Multinet.

The Multinet guide says to switch the type to Public, so I'm confused what this issue is saying to do.

This seems to be done: https://github.com/atlascope/atlascope/blob/fe6cafb80ff3734d962593292b73c9d5bb987194/atlascope/core/management/commands/populate.py#L73.


Operationalizing

Seems good.
Some spelling errors int the notebook.
How are we setting the metadata #parameters tag? I guess this is a bit of a weird exercise where the notebook is an object in the excerise rather than containing the excercise itself.
Do you think it's work putting the other steps - running papermill, in a Markdown file?
We might also want to upload the PPT to here.


`GLIBC_2.29' not found error when runing the helloworld server example in python

What version of gRPC and what language are you using?
grpcio==1.46.3
grpcio-tools==1.46.3
Python Language
What operating system (Linux, Windows,...) and version?
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
What runtime / compiler are you using (e.g. python version or version of gcc)
python
What did you do?
I was trying to run the "greeter_server.py" file from the "/grpc/examples/python/helloworld" directory.
What did you expect to see?
I was excepting to see the server start without any error.
What did you see instead?
I got the following error message

Traceback (most recent call last):
File "greeter_server.py", line 19, in
import grpc
File "/home/tqc_adm/.local/lib/python3.7/site-packages/grpc/init.py", line 22, in
from grpc import _compression
File "/home/tqc_adm/.local/lib/python3.7/site-packages/grpc/_compression.py", line 15, in
from grpc._cython import cygrpc
ImportError: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' not found (required by /home/tqc_adm/.local/lib/python3.7/site-packages/grpc/_cython/cygrpc.cpython-37m-arm-linux-gnueabihf.so)

Anything else we should know about your project / environment?

How did you install grpcio? pip? Can you please include the install logs?
This error message suggests that the artifact you installed is not compatible with your environment (wrong libc version). Have you tried installing from piwheel?

How did you install grpcio? pip? Can you please include the install logs?
This error message suggests that the artifact you installed is not compatible with your environment (wrong libc version). Have you tried installing from piwheel?

I have reinstalled the grpcio package from piwheel and the error is not there anymore. Thank you,

I'm getting a very similar error with all versions above 1.44.0:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/ben/.local/lib/python3.9/site-packages/snsary/contrib/google/__init__.py", line 1, in <module>
    from .bigquery import BigQueryOutput
  File "/home/ben/.local/lib/python3.9/site-packages/snsary/contrib/google/bigquery.py", line 51, in <module>
    from google.cloud import bigquery_storage_v1
  File "/home/ben/.local/lib/python3.9/site-packages/google/cloud/bigquery_storage_v1/__init__.py", line 25, in <module>
    from google.cloud.bigquery_storage_v1 import client
  File "/home/ben/.local/lib/python3.9/site-packages/google/cloud/bigquery_storage_v1/client.py", line 24, in <module>
    import google.api_core.gapic_v1.method
  File "/home/ben/.local/lib/python3.9/site-packages/google/api_core/gapic_v1/__init__.py", line 16, in <module>
    from google.api_core.gapic_v1 import config
  File "/home/ben/.local/lib/python3.9/site-packages/google/api_core/gapic_v1/config.py", line 23, in <module>
    import grpc
  File "/home/ben/.local/lib/python3.9/site-packages/grpc/__init__.py", line 22, in <module>
    from grpc import _compression
  File "/home/ben/.local/lib/python3.9/site-packages/grpc/_compression.py", line 15, in <module>
    from grpc._cython import cygrpc
ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not found (required by /home/ben/.local/lib/python3.9/site-packages/grpc/_cython/cygrpc.cpython-39-arm-linux-gnueabihf.so)

I can't work out what has changed after 1.44.0 that's causing the problem. My libc version is 2.31 and the source package is as up-to-date as it can be (apt update && apt install libc6).
ldd --version
ldd (Debian GLIBC 2.31-13+rpt2+rpi1+deb11u3) 2.31

Here's the install log:
pip install --upgrade grpcio
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: grpcio in ./.local/lib/python3.9/site-packages (1.44.0)
Collecting grpcio
  Using cached grpcio-1.47.0-cp39-cp39-linux_armv7l.whl (69.6 MB)
Requirement already satisfied: six>=1.5.2 in ./.local/lib/python3.9/site-packages (from grpcio) (1.16.0)
Installing collected packages: grpcio


Error: No matching export in "node_modules/react-native-web/dist/index.js" for import "TurboModuleRegistry"

Describe what happened
Starting getting this error when we updated the library version from 1.7.0 -> 1.8.*

Error: Build failed with 4 errors:
node_modules/@datadog/mobile-react-native/lib/module/specs/NativeDdLogs.js:8:9: ERROR: No matching export in "node_modules/react-native-web/dist/index.js" for import "TurboModuleRegistry"
node_modules/@datadog/mobile-react-native/lib/module/specs/NativeDdRum.js:8:9: ERROR: No matching export in "node_modules/react-native-web/dist/index.js" for import "TurboModuleRegistry"
node_modules/@datadog/mobile-react-native/lib/module/specs/NativeDdSdk.js:8:9: ERROR: No matching export in "node_modules/react-native-web/dist/index.js" for import "TurboModuleRegistry"
node_modules/@datadog/mobile-react-native/lib/module/specs/NativeDdTrace.js:8:9: ERROR: No matching export in "node_modules/react-native-web/dist/index.js" for import "TurboModuleRegistry"
    at failureErrorWithLog (/Users/runner/work/1/s/node_modules/vite/node_modules/esbuild/lib/main.js:1649:15)
    at /Users/runner/work/1/s/node_modules/vite/node_modules/esbuild/lib/main.js:1058:25
    at /Users/runner/work/1/s/node_modules/vite/node_modules/esbuild/lib/main.js:1525:9
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { viteCommonjs, esbuildCommonjs } from '@originjs/vite-plugin-commonjs';

// https://vitejs.dev/config/
export default defineConfig({
  define: {
    global: 'window',
  },
  optimizeDeps: {
    include: ['@react-navigation/native'],
    esbuildOptions: {
      mainFields: ['module', 'main'],
      resolveExtensions: ['.web.js', '.js', '.ts'],
      plugins: [esbuildCommonjs(['@react-navigation/elements'])],
      loader: {
        '.js': 'jsx',
      },
    },
  },
  resolve: {
    extensions: ['.web.tsx', '.web.jsx', '.web.js', '.tsx', '.ts', '.js'],
    alias: {
      'react-native': 'react-native-web',
    },
    preserveSymlinks: true
  },
  plugins: [viteCommonjs(), react()],
  build: {
    commonjsOptions: {
      transformMixedEsModules: true,
    },
  },
  esbuild: {
    loader: 'tsx',
    include: [
      'src/**/*.jsx',
      'src/**/*.tsx',
      'cypress/**/*.tsx',

      'node_modules/**/*.jsx',
      'node_modules/**/*.tsx',

      'src/**/*.js',
      // "node_modules/**/*.js",

      'src/**/*.ts',
      'node_modules/**/*.ts',
    ],
    exclude: [],
  },
});

package.json
{
  "name": "com.endotronix.cordella.onthego",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "lint": "eslint .",
    "start": "react-native start",
    "test": "cypress run -b 'chrome' --component --reporter 'junit'",
    "pods:install": "cd ios && bundle exec pod install && cd ..",
    "pods:clean": "cd ios && bundle exec pod deintegrate && cd ..",
    "pods:reinstall": "yarn pods:clean && yarn pods:install",
    "prepare": "husky install",
    "android:staging": "react-native run-android --variant=stagingdebug",
    "android:staging-release": "react-native run-android --variant=stagingrelease",
    "android:dev": "react-native run-android --variant=developmentdebug",
    "android:dev-release": "react-native run-android --variant=developmentrelease",
    "android:prod": "react-native run-android --variant=productiondebug",
    "android:prod-release": "react-native run-android --variant=productionrelease",
    "ios:dev": "react-native run-ios --scheme 'TestAppDevelopment'",
    "ios:prod": "react-native run-ios --scheme 'TestAppProduction'",
    "ios:staging": "react-native run-ios --scheme 'TestAppStaging'"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,ts,tsx}": [
      "prettier --write",
      "eslint --fix",
      "git add"
    ],
    "*.{html,css,less,ejs}": [
      "prettier --write",
      "git add"
    ]
  },
  "dependencies": {
    "@datadog/mobile-react-native": "^1.6.0",
    "@datadog/mobile-react-navigation": "^1.6.0",
    "@react-navigation/bottom-tabs": "^6.5.7",
    "@react-navigation/native": "^6.1.6",
    "@react-navigation/native-stack": "^6.9.12",
    "@reduxjs/toolkit": "^1.9.3",
    "babel-plugin-module-resolver": "^5.0.0",
    "react": "18.2.0",
    "react-dom": "^18.2.0",
    "react-is": "^18.2.0",
    "react-native": "0.71.6",
    "react-native-auth0": "^2.17.2",
    "react-native-config": "^1.5.1",
    "react-native-paper": "^5.6.0",
    "react-native-safe-area-context": "^4.5.0",
    "react-native-screens": "^3.20.0",
    "react-native-svg": "^13.9.0",
    "react-native-svg-transformer": "^1.0.0",
    "react-native-typescript-transformer": "^1.2.13",
    "react-native-vector-icons": "9.2.0",
    "react-native-web": "0.19.5",
    "react-redux": "^8.0.5",
    "redux-logger": "^3.0.6"
  },
  "devDependencies": {
    "@babel/core": "^7.21.4",
    "@babel/preset-env": "^7.21.4",
    "@babel/preset-typescript": "^7.21.4",
    "@babel/runtime": "^7.20.0",
    "@originjs/vite-plugin-commonjs": "^1.0.3",
    "@react-native-community/eslint-config": "^3.2.0",
    "@tsconfig/react-native": "^2.0.2",
    "@types/node": "^18.15.11",
    "@types/react": "^18.2.0",
    "@types/react-dom": "^18.2.4",
    "@types/react-native": "^0.71.6",
    "@types/react-native-auth0": "^2.17.4",
    "@types/react-native-vector-icons": "^6.4.13",
    "@types/redux-logger": "^3.0.9",
    "@vitejs/plugin-react": "^4.0.0",
    "cypress": "12.12.0",
    "eslint": "^8.19.0",
    "eslint-config-prettier": "^8.8.0",
    "husky": "^8.0.0",
    "jetifier": "^2.0.0",
    "lint-staged": "^13.2.2",
    "prettier": "^2.4.1",
    "react-native-clean-project": "^4.0.1",
    "react-test-renderer": "^18.2.0",
    "typescript": "^4.9.5",
    "vite": "^4.3.6"
  }
}

Running yarn test fails now anytime after using 1.8.*
Describe what you expected:
Expect the tests to pass.
Additional context

Version of the SDK: 1.8.*
Version of React Native: 0.71.6

Hi @bpotaczek, thanks for reaching out and sorry for the delay!
From what I understand you are using @datadog/mobile-react-native with react-native-web, is that correct?
If so, we don't officially support react-native-web usage yet (it's on our roadmap), so you probably have some bindings somewhere in your code to make it work that were broken by our upgrade to support the new RN architecture in 1.8.0.
If you can share the code where you make @datadog/mobile-react-native compatible with react-native-web I can try to help you fix it.
Let us now if your use case is different so we can help troubleshoot it.
Thanks a lot!

Hi @bpotaczek,
There has not been any activity on this issue for a while so I'm going to close it.
Feel free to reopen it with more details if you still encounter the problem :)


Make close tab button always visible

In Edge, the close tab button always visible by default. I think it will simple to implement directly or make a option in Firefox config page.

I've added a tweak that will show the close button when hovering over the tab as that will make it easier to read smaller sized tabs: uc.tweak.show-tab-close-button-on-hover


Feature/adding seaclouds dc to catalog

This PR adds the deployment of the seaclouds-dc in the catalog.bom in order to be deployed within the SeaClouds Platform. At the end of the deployment of the seaclouds-dc it is also installed a monitoring rule that need to be statically added to the Monitor Manager. @kiuby88 @rosogon can you have a look?

have you tested this new bom with the installer?

I have tested this PR. The I have tested the new .bom and it does not break the installation process. But I have found some little issues during the application deployment. I have opened a PR to @MicheleGuerriero's branch. Moreover, I think SLA does not works very well, so please @rosogon could you take a look?
All that remains now is the final effort, the last push :)
Thanks a lot.

@rosogon . SLa produces this agreement it looks that the connection between the sla-core and the sla-db is wrong.

Thanks @MicheleGuerriero

@rosogon MySQL avoid the driver problems, but the sla-service is not working correctly. The database can not be accessed, something went wrong about the credentials. Take a look please :) and let me now

@rosogon , @MicheleGuerriero has just updated the PR. It is ready from my side. Take a look :)

@rosogon @perezp take a look please

@MicheleGuerriero you have avoid my commit and it is mandatory to use the installer so please, included it in your PR.

Probably, you should do a pull of the remote branch before rebase branch

@MicheleGuerriero I have opened a PR to your branch again https://github.com/MicheleGuerriero/SeaCloudsPlatform/pull/5
It should solve the installation issues of this PR

+1 from mi side.
You can use this topology in order to facilitate the testing

The seaclouds-data-collector of this PR is deployed when the platform is installed. I've tested it.
The information for this module is created in the DAM when the DAM is generated during the application design. I've seen it.
So, +1.
Nevertheless, I had some issues with the deployment of the application I had tested, but I'm quite confident that these issues are beyond the concerns of this PR.


few question

1.“Knife kill feed icons are automatically replaced” It doesn't work .Display the default knife kill Icon.
2.When I die, the weapon I drop is sometimes the default skin.

for 1, it is broken since panorama update, need to find what object has the new listener that needs to be hooked


Restructure project for modular RL environment configuration

Users should be able to add new environments easily.
New project structure:
/project_root
├── /environments/
│   ├── init.py             # Environment factory function
│   ├── /base_env.py            # Base class for all environments
│   ├── /commonroad_env/
│   │   ├── init.py
│   │   ├── commonroad_env.py    # CommonRoad-specific environment class
│   │   ├── experiment_setup.py  # CommonRoad-specific experiment setup
│   │   ├── ... custom stuff
│   ├── /dummy_gym_env/
│       ├── init.py
│       ├── dummy_gym_env.py     # Dummy gym environment class

I think this will help you.
https://mega.co.nz/#!B31G2LaZ!uBBOCp9hLC7bq9kP8NC6s4DanQJJZuoFRr5FI_jkeic
I put the necessary dlls in the archive


Custom env variables to be used in templates

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the problem to be solved
I want to dynamically set the document.domain in my custom template based on the mode I am in. I use different domains for development and production mode. Currently this is the solution I have:
<script>
      {{ if show_details }}
      document.domain = 'local.mydomain.com';
      {{ else }}
      document.domain = 'mydomain.com';
      {{ end }}
</script>

This is not perfect since I actually have 3 states: development, staging and production, each with their own domain. The current solution just handles development and production with the help of the show_details flag since this is turned off in production I can use it to set the domain accordingly.
Suggest a solution
I searched existing issues and also had a peak inside the source code but did not find anything the would allow me to set a custom environment variables that are populated inside the template like so:
...
extraEnv:
  DOMAIN: mydomain.com

that would be available inside the html template:
<script>
      document.domain = '{{domain}}';
</script>

Additional context
If there is a similar existing solution I have missed please let me know.

Is #165 can solve this issue?

Wow that was quick! Yes this would work, thanks 😀
Maybe add some doc example (in the README or somewhere) so other users also know that this is possible.
Otherwise looks great.

:fire: Released in v2.20.0


Xiaomi Honeywell Smoke Detector support

Device model
lumi.sensor_smoke.mcn02
Device name
Xiaomi Honeywell Smoke Detector
Does the device require a MiCloud connection?
Do not know
Anything special about the device?
I can already see the sensor state in logs.
Created this issue as requested in: https://github.com/merdok/homebridge-miot/issues/292#issuecomment-2034216908

Thanks, will have a look at that when i find some free time.


Added Slack Event API tutorial (issue #447)

Fixes
Resolves #447
Checklist

[x] I have made a material change to the repo (functionality, testing, spelling, grammar)
[x] I have read the [Contribution Guide] and my PR follows them.
[x] I updated my branch with the master branch.
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation about the functionality in the appropriate .md file
[ ] I have added in line documentation to the code I modified

Short description of what this PR does:

Updates USE_CASES.md with a tutorial on how to send an email with a Slack Event API integration.

If you have questions, please send an email to Sendgrid, or file a Github Issue in this repository.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hello @semijoelon,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX

Closing as this feels like more of a blog post than library documentation and use cases.


Fix bug with wrong calculation of duration in DateTimeInterval init

@TrachYuri I think it's still different from the rest of the file. Looks like you're using 2 spaces now rather than what the file is using.


Should Oid implement AsRef<[u8]>

Not entirely certain this makes sense, but it would allow avoiding a call to as_bytes when passing an Oid into functions taking in &[u8] generically.
Looking through std there's precedence in that str.as_bytes() and AsRef::<[u8]>::as_ref(str) are equivalent.

I'd be fine with adding an impl!

Cool, I'll probably get to it in the next day or so.


Job Creation: Search for Sites Without Redundant Circuit

Environment

Nautobot version:
nautobot-circuit-maintenance version:

Proposed Functionality
I'm looking to add a Nautobot Job to get packaged that will search through the possible records, and flag any sites that will not have a redundant circuit available during a maintenance of another circuit.
        # Query for all of the circuits maintenances that are on going in the future
        # Query for all of the circuits within Nautobot
        # Loop over each of the circuit maintenance records
            # Check to see if there are any circuit maintenances that are duplicated time
            # Report failures for any time where a circuit will take an outage
            # Evaluate adding a tag of an impeding site outage due to WAN outages
            # Log success for each time there is a known circuit still available at the site at the same time

Use Case
Give the ability to notify when there is an outage being created by maintenance events, even though the network design has redundancy of circuits.

is this addressed by #214?


[Question] How to contribute to add a translation?

I would like to contribute Chinese locale for the remote. But don't know how to add and where to request.

understand how to contribute this already. thanks

Just in case anyone is looking for the answer. To add a translation - send pull request with
/app/src/main/res/values-[locale name]/strings.xml file translated to your language.
But is it possible to integrate Kore translations into Kodi translation project at transifex?

It's being worked on.


fix: GetBorrow rounds up

Description
closes: #545

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[x] added appropriate labels to the PR
[ ] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch (see PR Targeting)
[x] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[x] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Codecov Report

Merging #559 (5eb183b) into main (20d0cd5) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #559      +/-   ##
==========================================
+ Coverage   48.37%   48.41%   +0.04%
==========================================
  Files          63       63
  Lines        7916     7923       +7
==========================================
+ Hits         3829     3836       +7
  Misses       3830     3830
  Partials      257      257

Impacted Files
Coverage Δ

x/leverage/client/tests/suite.go
100.00% <100.00%> (ø)

x/leverage/keeper/borrows.go
83.13% <100.00%> (ø)

x/leverage/keeper/iter.go
54.97% <100.00%> (ø)


Register on bower

bower                        ENOTFOUND Package purescript-memoize not found

Done, thanks!

Thanks :+1:


6g is broken

Seems like the output is going to stdout

"Fixed" inasmuch as it now appears in the asm pane. Looks pretty awful though


Add main property/value to bower.json

Can someone please add "main": "tooltip.js" into bower.json so that wiredep can pick it up when we install it using bower install

Thanks for using Tooltip (still I hope :sweat_smile: ). I recently pushed out some changes that fixed the incorrect bower.json and package.json files from this project. Let me know if you run into any issues though and I'll be more than happy to help :smile_cat:


Document steps for reconnection

The spec should document steps needed for a client to resume streaming after a broken connection without duplicate packets or missing packets.
Good to document resume for both a simple case, say single station with no wildcards and for the more complex case where wildcards are used and so there is the potential of new stations coming online after the resume. Example:
STATION IU *
SELECT *_B_H_?
DATA
END

then there is a break in the connection. The client wishes to resume all existing stations for which it has seen data (ie it has a last seq num) but also wants to allow for data from IU stations for which it has not yet received a packet.

Feedback from proposal team
If mixing sequence numbers with wildcards is not supported by the server, then the client must not use wildcards with stations that are resumed. For example, assuming that the client opened initial connection as shown above and received data from IU_BILL (last seq 254483417) and IU_JOHN (last seq 3929540), they can resume connection with:
STATION IU_BILL
SELECT *B_H?
DATA 254483418
STATION IU_JOHN
SELECT B_H?
DATA 3929541
STATION IU_
SELECT *B_H?
DATA
END
Note that according to spec, Stations that already matched a previous STATION command are excluded, so “STATION IU *” does not apply to IU_BILL and IU_JOHN, which were matched earlier.
Change of specification
Add comments to “Example handshaking”.

+1 on change


WIP proposal to build imagecodecs and imagecodecs-lite from one feedstock

This is a WIP/proposal to build imagecodecs and imagecodecs-lite from one feedstock, the same as is done with matplotlib. This might be especially important as upstream imagecodecs-lite is deprecated.
Checklist

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

Main problem is that for some reason the split outputs trigger the 2nd output to not find python and then not find '-m' as a command. At least that is what @nehaljwani deducted.

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

To my knowledge, imagecodecs-lite has been deprecated.
Why would we want users to install it if we can provide full featurtes from imagecodesc?

The package has been deprecated, but the install method is still in imagecodecs. I thought that many packages depend on imagecodecs-lite specifically and that -lite is easier to install for many people / some archs. But if you want to move all packages to full imagecodecs that is ofc also fine.

yeah, for conda-forge, i would make modern imagecodecs-lite a pointer to imagecodecs.
We can then focus on efforts in bringing as many features there


[JENKINS-55787] Switch labels from entry to checkbox

JENKINS-55787
Basically checkboxes should have labels, splitting the labels away from their checkboxes is poor UX, poor accessibility. This change brings the layout more inline with how normal settings UIs lay out checkboxes.
The new UI looks like this:

The old UI looks like this:

Eventually the labels which are currently to the left of text boxes will be switched to being above them, which will reduce the amount of whitespace to the left of the checkboxes.

Thanks @jsoref


Update the code generator to use polyglot instead of old usage of polyglot-go

Description

Update the code generator to use polyglot instead of old usage of polyglot-go.
Add golint support; Fixed some linters errors

Fixes # (issue)
Type of change
Please update the title of this PR to reflect the type of change. (Delete the ones that aren't required).

[ x] Bug fix (non-breaking change which fixes an issue) [title: 'fix:']
[ ] New feature (non-breaking change which adds functionality) [title: 'feat:']
[ ] Refactor (non-breaking code changes that do not add new functionality or break existing functionality) [title: 'refactor:']
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Testing
Please make sure that existing test cases pass (with go test ./... -race and go test -bench=. ./... -race),
and if required please add new test cases and list them below:

[ ] Test A
[ ] Test B

Final Checklist:

[x] My code follows the style guidelines of this project
[ x] I have performed a self-review of my own code
[ x] I have commented my code, particularly in hard-to-understand areas
[ x] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[x ] I have checked my code and corrected any misspellings

@ShivanshVij
I will close this pull request and create 2 separate ones addressing them individually.


A11y_OSvisualupdate_MiniControGallery_GenericControls_Screenreader : Several controls in the calendar pop up are not provided with descriptive names.

GitHubTags: #A11y_OSvisualupdate, #A11yMAS, #A11yTCS, #Win10, #DesktopApp, #WindowsUILibrary, #MAS1.3.1, #MAS4.1.2, #Narrator, #NVDA
Environment Details:
Application Name: OS visual update
Windows Version: Windows10
Screen Reader: Narrator, NVDA 2019.2
Steps to Reproduce:

Launch Mini Control Gallery App from the installer location.
Screen with all generic controls would appear on left side of the screen.
Verify that all the elements of "MiniControlGallery-Generic Controls" are accessible and MAS Compliant.

Actual:
The “Previous”, “Next” and “November 2019” buttons are not provided with descriptive names defining the actual functionality of the controls.
Similar issue is observed in the below scenario:

MiniControlGallery - Calender and Color Picker Controls -> Launch Mini Control Gallery App from the installer location. -> Screen with Calender and Color Picker controls would appear on right side of the screen.

Expected:
For “Previous”, “Next” and “November 2019” buttons descriptive names should be “Previous Month”, “Next Month” and “Change month” respectively which be announced to screen reader users.
User Impact:
If proper name is not provided for the controls, then the screen reader users will have difficulty in understanding the control and its associated functionality.
Attachment:
A11y_OSvisualupdate_MiniControGallery_GenericControls_Screenreader  Several controls in the calendar pop up are not provided with descriptive names..pptx

This is by design -- Next/Previous are contextual based on the "zoom level" of the control, same as "November 2019" button. We don't do much to help the sighted user here either so it seems ok.