MRPC Produces Two Vastly Different Eval Accuracy

Hi,
I am testing using TF v1.14.0.
I ran for 10 times with run_classifier.py (do_traing=False, do_eval=True), i.e. do inference immediately after loading https://storage.googleapis.com/bert_models/2018_10_18/uncased_L-24_H-1024_A-16.zip
I am seeing two values 0.31617647 & 0.6838235.
I wonder why I am seeing different inference results and why I am seeing exactly these two results. Thanks!
check-pretrained-MRPC-1.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-10.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-2.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-3.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-4.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-5.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-6.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-7.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-8.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-9.log:INFO:tensorflow:  eval_accuracy = 0.31617647

Update: ran another 10 times and was able to see a 3rd accuracy value
check-pretrained-MRPC-1.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-10.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-2.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-3.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-4.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-5.log:INFO:tensorflow:  eval_accuracy = 0.6764706
check-pretrained-MRPC-6.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-7.log:INFO:tensorflow:  eval_accuracy = 0.31617647
check-pretrained-MRPC-8.log:INFO:tensorflow:  eval_accuracy = 0.6838235
check-pretrained-MRPC-9.log:INFO:tensorflow:  eval_accuracy = 0.31617647
and also read that " Small sets like MRPC have a high variance in the Dev set accuracy, even when starting from the same pre-training checkpoint." from README. Hence closing. :)

i also read this word "Small sets like MRPC have a high variance in the Dev set accuracy, even when starting from the same pre-training checkpoint", but how could this happened, i got the same input features and same weight, after inference got different probabilities? same input but different ouput!


Support Julia pre-v1.11?

I think we could easily support Julia versions before v1.11 something like this: instead of defining struct FixedSizeArray directly at the top level, we could use @static if:
@static if VERSION < v"1.11-"
    struct FixedSizeArray{T,N} <: DenseArray{T,N}
        mem::Vector{T}
        size::NTuple{N,Int}
    end
    parent_type(::Type{<:FixedSizeArray{T}}) where {T} = Vector{T}
else
    struct FixedSizeArray{T,N} <: DenseArray{T,N}
        mem::Memory{T}
        size::NTuple{N,Int}
    end
    parent_type(::Type{<:FixedSizeArray{T}}) where {T} = Memory{T}
end

A downside is that this could complicate #33.
Given that Julia v1.11 seems to be getting released soon anyway, I'm not sure that it makes sense to do this, though.

That's a neat trick, but I'm not sure it's worth it.  I think it's better to stick to Memory & Co. only, and forget about compatibility with older versions of Julia.

Actually, @static is not even necessary. A cleaner design than proposed above:
struct FixedSizeArray{T,N,Vec<:AbstractVector{T}} <: DenseArray{T,N}
    mem::Vec
    size::NTuple{N,Int}
    function FixedSizeArray{T,N,Vec}(
        ::Internal, mem::Vec, size::NTuple{N,Int},
    ) where {T,N,Vec<:AbstractVector{T}}
        new{T,N,Vec}(mem, size)
    end
end
parent_type(::Type{<:FixedSizeArray{<:Any,<:Any,Vec}}) where {Vec} = Vec

@longemen3000 could you list some motivating points for doing this?

I want to use this library in one of my projects, but we have compatibility with Julia 1.6 (changing the minimum compat to 1.10 as soon as 1.11 is released), so adding this dependency would not be possible on those systems.

Given that Julia v1.10 will become LTS (I think I read that somewhere?), perhaps we should support it in some manner.
Perhaps we could even keep this package v1.11-only, but introduce an additional package (FixedSizeArraysCompat?) that would also support Julia v1.10, perhaps by using package extensions.


open viewer without sockets..?

I have had a lot of trouble trying to get pptk.viewer() to run on CentOS without root privilege.
The main limitation is that pptk/viewer/viewer.py uses a socket to start up the viewer. The program just hangs after calling pptk.viewer():
Python 3.6.8 (default, Aug  7 2019, 17:28:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np; import pptk; x=np.random.rand(100,3); v = pptk.viewer(x)

After ^C it shows that the program was hanging on
x = s.accept()
After changing
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
to
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.SO_REUSEADDR, 1)
in pptk/viewer/viewer.py I get
Python 3.6.8 (default, Aug  7 2019, 17:28:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np; import pptk; x=np.random.rand(100,3); v = pptk.viewer(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dmf/.local/lib/python3.6/site-packages/pptk/viewer/viewer.py", line 48, in __init__
    s.bind(('localhost', 0))
OSError: [Errno 88] Socket operation on non-socket

I'm having this issue too, more or less. I have X11 set up on a remote server, but when I run pptk.viewer(xyz), it just sits there.


Ability to export multiple pages

It would be a nice addition to be able to export multiple pages from a single .tldr file, similar to the way frame exporting is implemented as of writing.

Thanks, agreed — this feature is on the to-do list.

I just looked into this today. It should make it into a release in the next day or two.

Thank you very much! I'll make sure to check it out

Ok this should be resolved in the just-released version 4.4.
Short version:
There's a new pages option, that works pretty much like the frames option in that it can take a boolean or an array of page names or ID strings.
Long version:
In addition to passing page names or IDs to pages, I think it also makes sense to allow page indices, so arrays of numbers are also allowed as an argument to pages. (Note that this argument type isn't available for the frames option, since frames are not explicitly ordered due to their two dimensions of freedom on the canvas.)
There's some ambiguity about how to design this API for least surprise while maintaining consistency with the precedents set by the frames option.
I think it's a reasonable assumption that by default one export command should yield one downloaded image file, though I realize this isn't always intuitive since only the tldr format can reasonably represent the multiple pages and frames that might be present in a TLDraw sketch. (At least without getting into more complex multi-page file formats like PDF, which isn't out of the question but is out of scope for this issue and my morning. 😅)
Nevertheless sticking with that idea for now, and if the user wants more complex (multi-file) export behavior, then they'll need to reach for the options.
Unfortunately this does result in a few nuances in terms of how the new pages option interacts with the existing frames option, which is spelled out in the table below:

pages undefined
pages false
pages true
pages string[]
pages number[]

frames undefined
Entire first page exported to a single image
Entire first page exported to a single image
Entirety of each page exported to separate images
Entirety of each page with matching IDs or names exported to separate images
Entirety of each page with matching zero-based index exported to separate images

frames false
Entire first page exported to a single image
Entire first page exported to a single image
Entirety of each page exported to separate images
Entirety of each page with matching IDs or names exported to separate images
Entirety of each page with matching zero-based index exported to separate images

frames true
Each frame of first page exported to separate images
Each frame of first page exported to separate images
Each frame of each page exported to separate images
Each frame of each page with matching IDs or names exported to separate images
Each frame of each page with matching zero-based index exported to separate images

frames string[]
Each frame with matching IDs or names on the first page exported to separate images
Each frame with matching IDs or names on the first page exported to separate images
Each frame with matching IDs or names on each page exported to separate images
Each frame with matching IDs or names of each page with matching IDs or names exported to separate images
Each frame with matching IDs or names of each page with matching zero-based index exported to separate images


Using lodash range function, importing PropTypes to reduce verbosity.

Not a meaningful one, but always happy to contribute :)

Nice! Always great to receive contributions ;)
lgtm to me, but @FrancescoCioria is the boss here

great, thanks!


Touch events on the Turtle window not recognized

The old interpreter had both mouse clicks and touchscreen taps on the Turtle window fire turtle-click Scheme event.
In the new interpreter, only mouse clicks currently work. This should be fixed so that touchscreen taps trigger some event, whether it be turtle-click, or a separate event.

This issue was moved to Cal-CS-61A-Staff/dart_scheme#14


Red 2-1 Switch support?

is there any plan to add support for the new Red 2-1 switches? If not, I may look into contributing (though I'm not really up on Javascript, and I'd have no idea what I'm doing).

I would be happy to test with the new 2-1, but I also have zero coding experience.

I have a PR currently being worked on that adds the 2-1 Switch support: https://github.com/ryanjohnsontv/node-red-contrib-ha-inovelli-manager/pull/66
I'm hoping to have it done soon!

Just got my first VZW31-SN, so I'm anxiously waiting for this update! Thank you so much for your work on this, my house depends on you :)
I don't know if this is possible, but I have one node for the LZW31-SN dimmers (7 in my house), another node for the LZW30-SN on/off switches (16 in my house) and I'm worried I'm going to have another node for these new 2-1 switches!
The reason I have that, is so all the switches in my house react the same way, no matter if they're a dimmer or a switch.
Is there any way to have one node figure out the switch's product code so that it is all housed within one node? I might be asking too much here :)
Thanks again. Please keep up the good work.

Just got my first VZW31-SN, so I'm anxiously waiting for this update! Thank you so much for your work on this, my house depends on you :)
I don't know if this is possible, but I have one node for the LZW31-SN dimmers (7 in my house), another node for the LZW30-SN on/off switches (16 in my house) and I'm worried I'm going to have another node for these new 2-1 switches!
The reason I have that, is so all the switches in my house react the same way, no matter if they're a dimmer or a switch.
Is there any way to have one node figure out the switch's product code so that it is all housed within one node? I might be asking too much here :)
Thanks again. Please keep up the good work.

Unfortunately none of the Home Assistant integrations pass identifiable product information in the event message body, so you're stuck using just the dedicated node/device ID

I have a PR currently being worked on that adds the 2-1 Switch support: #66 I'm hoping to have it done soon!

I can test tonight --

I added #69 to the mix here.

It looks like a new parameter of 99 was used for the notification. Looking at the code it should may be an easy change?
Something like the needed to be added to the inputSwitchConver function:
    } else if (["dimmer", "vzw31", "vzw31-sn", 99].includes(parameter)) {
      parameter = 99;

And this needs to be changed in the HTML I believe

Switch Type

On/Off (LZW30-SN)
Dimmer (LZW31-SN)
Light Dimmer (LZW36)
Fan Dimmer (LZW36)
Fan & Light (LZW36)
        _On\Off+Dimmer (VZW36-SN)_

I assume the rest of the value would be the same as the existing switches.

Any updates on this?

everyone must be enjoying summer....

I have a PR currently being worked on that adds the 2-1 Switch support: #66 I'm hoping to have it done soon!

Any updates perchance on this? :)

Bueller?

Any update on this @ryanjohnsontv ? Thanks!

@ryanjohnsontv I see that the Code has been updated in your pull request to work with the Red 2n1, Is this ready for testing? can we get a Beta Version to help Test?

Is this project dead now?

I swear I saw somewhere that @ryanjohnsontv ordered some of the new Inovelli Red 2-1 switches - but now I can't find it so maybe I was dreaming?


[REQUEST] Bring back old achievement notifications

Is your feature request related to a problem? Please describe.
Please bring back the old achievement notification style or if possible have the choice between the 2 without having to downgrade versions. The windows/game bar notification style is very ugly and takes up a lot more of my screen.
Describe the solution you'd like
Bring back old achievement notification.
Describe alternatives you've considered
I switched to Hydra for my achievement notifications and tracking simply due to how it was handled and loving it so far until the windows notification update. I moved away from Achievement Watcher as they use the same style of notification.
Additional context
No response

The first one (which I much preferred) had some compatibility issues and was causing a black box for some users.
We are working on a much better solution that hopefully will work for everyone using Windows (for Linux we don't have a solution yet)

Understood, thanks for the insight and the replies to my other tickets as well, appreciate the work you do. <3


Unexpected stop on logging into twitter for the first time

Bug Report :

Application crashes when you login to the twitter account for the first time and scroll through the tweets.
Logcat Output :

03-06 11:40:21.896  10910-10910/ly.priv.mobile E/InputEventReceiver﹕ Exception dispatching input event.
03-06 11:40:21.896  10910-10910/ly.priv.mobile D/AndroidRuntime﹕ Shutting down VM
03-06 11:40:21.945  10910-10910/ly.priv.mobile E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: ly.priv.mobile, PID: 10910
java.lang.IllegalStateException: The content of the adapter has changed but ListView did not receive a notification. Make sure the content of your adapter is not modified from a background thread, but only from the UI thread. Make sure your adapter calls notifyDataSetChanged() when its content changes. [in ListView(2131427422, class android.widget.ListView) with Adapter(class android.widget.HeaderViewListAdapter)]

@akoul Formatted the bug report.

@vshivam THANKS
Also, the app seems to crash everytime you scroll through the tweets.

If you could fix the bug and make a pull request to the develop branch, I could take a look.

I have not been able to reproduce this. Are you using the latest code from master / develop ?

@vshivam Sorry for the late reply. I noticed that this error occurs after installing the app and using it for the first few times. Why don't you reinstall the app(gradle-develop) or try clearing data/cache from the app setting and then try it. Scrolling through the tweets up/down causes the app to force shut.
I'm attaching the screenshot of the force close:

I am using the latest code from develop branch of privly git.
I'll try to fix the error and make a pull request.

I am posting a .gif file of my screen recording.

Steps to Reproduce :

Scroll down to the last tweet when more tweets start to load.
Scroll up while the tweets are loading.
App crashes.

@akoul Just pushed a commit to the develop branch. Looks like this issue has been fixed. Can you check and confirm ?

I'll do that in some time and let you know
On 7 Mar 2015 22:31, "Shivam Verma"<EMAIL_ADDRESS>wrote:

@akoul https://github.com/akoul Just pushed a commit to the develop
branch. Looks like this issue has been fixed. Can you check and confirm ?
—
Reply to this email directly or view it on GitHub
https://github.com/privly/privly-android/issues/45#issuecomment-77698250
.

I'm still getting the same app-force close on scrolling through the tweets.

Do you have this line :
mListViewPosts.addFooterView(mFooterView);
In the initializeComponent(View v) method of the MicroblogListPosts.java
class ?
On Mar 8, 2015 1:53 AM, "Akhil Koul"<EMAIL_ADDRESS>wrote:

I'm still getting the same app-force close on scrolling through the
tweets.
—
Reply to this email directly or view it on GitHub
https://github.com/privly/privly-android/issues/45#issuecomment-77700784
.

Sorry, MicroblogListPostsFragment.java class.

Yes, I do.

I wanted to ask as to whether you have used Twitter SDK or Intent Share for integration of Twitter into Privly? Also, can we used the ASNE library to integrate social platforms ?
The link is https://github.com/gorbin/ASNE. I haven't tried it though.

If you check out the develop branch of the repo. It does not have that
line. That's the line which is causing the issue most probably.
Here's the link to the latest code :
https://github.com/privly/privly-android/blob/develop/src/main/java/ly/priv/mobile/api/gui/microblogs/MicroblogListPostsFragment.java
On Mar 8, 2015 2:04 AM, "Akhil Koul"<EMAIL_ADDRESS>wrote:

Yes, I do.
—
Reply to this email directly or view it on GitHub
https://github.com/privly/privly-android/issues/45#issuecomment-77701333
.

Commenting out that line made the difference. Now the bug seems to have been resolved.

Bug Fixed.
Commit : https://github.com/privly/privly-android/commit/d45803a62d3fc88bf950a9425e425a39f5507e2d


[OTBN] Device memory map

In the OTBN bus device we provide three areas of memory:

Control/Status registers
A window into OTBN instruction memory (IMEM)
A window into OTBN data memory (DMEM)

IMEM and DMEM are currently both 4 kB in size.
This issue is about finding a good address space layout for OTBN as bus device (i.e., as seen from Ibex; this is not about how the OTBN core sees IMEM/DMEM from its side).
If we want to have a reasonably tight address space, we can do something like the following. Keeping control/status registers at the beginning of the address space is OpenTitan convention, and we should stick to it.
0x0         control/status registers
0x1000      IMEM
0x2000      DMEM

If we want to provide a bit of expansion space for IMEM and DMEM without changing the address map, we can do something like this, providing a 16 kB address space for both IMEM and DMEM at the expense of consuming more address space for the OTBN device.
0x0         control/status registers
0x4000      IMEM address space
	0x4000 - 0x4FFF: IMEM
0x8000      DMEM address space
	0x8000 - 0x8FFF: DMEM

From a software and hardware perspective, I'm not sure if we need the expansion space. It's not unlikely we'll increase IMEM and/or DMEM size, but since all register maps are auto-generated (both in HW and in SW), we only need to change a parameter. However, relying on all that machinery for a potential last-minute change to increase IMEM or DMEM seems risky, and there might be code out there which doesn't use it, so providing the 16kB space seems safer.
What's your take on that?
In the current spec version I produced a slightly odd design (TM) which isn't properly prefixing the regions.

@tomroberts-lowrisc @GregAC @lenary

This might be asking something that's already been addressed (hah!), but does it need to expose all the memory directly? i.e. could the OTBN just provide a single address / data register that auto increments as you write to it / read from it?

If we want to provide a bit of expansion space for IMEM and DMEM without changing the address map, we can do something like this, providing a 16 kB address space for both IMEM and DMEM at the expense of consuming more address space for the OTBN device.

I'd be in favour of this kind of approach, I'd even say up the address space to something relatively huge (e.g. 1 MiB each). Unless there are any particular reasons to prefer a tight address map?

does it need to expose all the memory directly?

It doesn't necessarily need to, but it makes things easier.

Software on the main CPU reads the OTBN computation results back from DMEM in pre-defined areas, having it not fully mapped makes that harder to do so.
We don't have a DMA engine today, but I see other peripherals, such as HMAC, also be designed in a way that occupies a larger address space (for a FIFO, in the HMAC case) to allow a potential DMA engine to simply increase the address for bulk transfers. It's all hypothetical at this point, but keeping things consistent will make things easier for us down the road, hopefully.
Ultimately, we're not talking about a huge address space for the device in a world where we have 32b to waste, i.e. we can go the simple route.

Unless there are any particular reasons to prefer a tight address map?

None I know of. And I do think we've seen other peripherals using address space rather freely, such as PLIC.

I'd even say up the address space to something relatively huge (e.g. 1 MiB each)

I like that, the more I think about it, the more I think I was over-optimizing by preferring a smaller address space.

I had a long reply typed out, and it got lost. Then @imphil wrote out part of my feelings in his comment.
@tomroberts-lowrisc I think an auto-incrementing approach would be a bad idea. It may prevent later adding DMA, and seeking around to extract information seems error-prone and probably won't give you much bandwidth for extracting info after the run completes.
--
I think the PLIC is not a good comparison, for two reasons. 1: we're following the RISC-V PLIC specification (or planning to), which tells us how big the PLIC needs to be, quite apart from our requirements.
Where we're using gaps to make our lives easier in the DIFs is where the number of registers in a multireg is controlled by an instantiation parameter of the device. The DIFs are supposed to be parameterisation-agnostic (something we're moving towards, where the parameter values are represented in the DIF at run-time, not compile-time), and this means you don't use each register's _OFFSET macro, instead you use the first register's _OFFSET macro and then calculate the other register's offsets based off that. Here is a good example:
https://github.com/lowRISC/opentitan/blob/0eb35283ef2ee65ac6093bcc4e469bfc5ef7e409/sw/device/lib/dif/dif_padctrl.c#L87-L105
I took a quick look at the otbn.hjson file that's been proposed, and it seems we're not using parameters (yet). In this case, I don't see an issue with using the tighter memory map, as we need to recompile if otbn.hjson changes anyway, and the reason for generating the _OFFSETs from the hjson is exactly so we can slightly change the layout later without software breaking entirely. That said, I don't know if you intend to use hardware parameters for the size of dmem and imem.
I do think if you do the sparse approach, you end up having to enforce that the area sizes are never larger than the gap you left originally, and eventually you degenerate into the tight layout anyway (once you have expanded memory enough). Though this takes longer if you allocate a bigger gap.
My preference for the moment would be to go with the tight map, and if we later add parameters for the memory sizes, then I could see the advantage of gaps (because you won't need to calculate the offset of the second memory based off run-time information).

That said, I don't know if you intend to use hardware parameters for the size of dmem and imem.

Currently the one and only source for IMEM and DMEM size is the window.items field in the hjson -- it's passed as parameter to the hardware SRAM primitives, and it's used in my prototype DIF. So as long as we keep relying on that tooling, we're fine.
However, re-generating the address map is disruptive when we only want to change the size of the OTBN SRAMs. While it all should work, it increases risk. All software needs to recompiled. Logic in the crossbar changes. You cannot run main-CPU binaries compiled for versions with less SRAM on versions of OT with more SRAM, etc.
There's one more point: we need to allocate space in the global address map for OTBN as well -- and AFAIK, that's hand-crafted to give each device a maximum address space. We don't gain anything by not filling that space out right from the start, but we loose some flexibility (see above).

Whatever we decide here is relatively easily changed at this stage in the development cycle, so we don't need to come up with the ultimate answer. However, the "closer to right" we can get this, the less we need to think about it in the future :smile:
@gkelly @eunchan What's your take on that?

Has no bearing on DMA - any noddy DMA can access fixed and incrementing addresses, and the bandwidth is the same whatever (32b a cycle). Agree though it depends on the access patterns - lots of random access to smallish chunks would be a pain.

If we want to provide a bit of expansion space for IMEM and DMEM without changing the address map, we can do something like this, providing a 16 kB address space for both IMEM and DMEM at the expense of consuming more address space for the OTBN device.

I lean to this approach for future proofing, though no one should be addressing base addresses by hand, so even this probably doesn't matter.


feat: add top alert to MobileHeader component

Closes #303

@Lunory hi, pr is ready for final review


Add context manager for Bigtable client.

This allows using the Bigtable Client class in a with statement.
Fixes https://github.com/GoogleCloudPlatform/gcloud-python/issues/1793.
@dhermes Please take a look.

Thanks for doing this. Change contents look good (except for a few tiny nits). I suggest running tox (all environments) locally first to make sure.
@tseaver Do you agree?

LGTM once pylint passes.

I don't have a Python 3.5 interpreter on my workstation, but everything else passes.
$ tox
...
____ summary ____
  py27: commands succeeded
  py34: commands succeeded
ERROR:   py35: InterpreterNotFound: python3.5
  cover: commands succeeded
  docs: commands succeeded
  lint: commands succeeded

@tswast Am I good to merge once Travis passes?

Yes, merge once Travis passes, please.


Vulkan: Adding a mesh without material causes other meshes to be rendered improperly (disappear)

Godot version
4.0.alpha5
System information
MacOS 10.15.7
Issue description
A mesh without a  material added to the scene can cause other meshes to 'disappear'. Possibly a duplicate of #51898, but I can't judge it.
Steps to reproduce
Remove material and material override from the 'pill' in the attached project. Also see the README.txt in the attached project.
Minimal reproduction project
material_not_set_bug.zip

Which hardware (and GPU) are you using? Can you post a video recording?

Here are my hardware specs. Will upload a screencast in a moment.

https://user-images.githubusercontent.com/29225521/161547502-e75581b7-7f65-4262-860f-cf9fed866e70.mp4
Removing the material from the 'pill' causes the 'column' to be rendered black in editor.

Running with a pill with material:
https://user-images.githubusercontent.com/29225521/161548268-a9c63ff0-5085-441f-a0ad-4a2d85d50179.mp4
Running with a pill without material:
https://user-images.githubusercontent.com/29225521/161548275-7b9e0fb1-8935-4ca2-b57d-52185a333647.mp4

this issue already apperas before alpha5 and I got this issue before alpha1

got the same issue on M1 Pro but your post makes me believe this is not a GPU architecture but a MoltonVK/Metal related issue.

Haven't tested it but I think the issue should be able to be replicated using a Mac OS VM if no apple hardware is available to developers.

Duplicate of https://github.com/godotengine/godot/issues/51898.


Server crash on boot - Mod interaction

http://pastebin.com/QApixNEX
The issue, I believe is that the Backpacks! mod by brad16840 modifies the biped model. Not sure who's error it technically is.
Also, the client loads fine, it is just the server that does not.

It is another problem. I will fix it

Brilliant!

Fixed in next release (busy preparing 1.1.2 now)

Awesome, thanks for the speedy response!


PARQUET-626: Disable LLVM toolchain parts of Travis CI build

Since llvm.org apt repo was taken offline, this patch triages builds until we sort out an alternative (or remove it altogether for now).

+1 -- I am merging this as a triage so we can get passing builds for the outstanding patch queue


Swiping causes button text to wrap

I've just wrapped a component in swipeout and, while it's mostly perfect, the one thing I have noticed is that the text wraps mid swipe.

In this case, I'm about half way through my swipe to the left and the text is wrapping on to two lines. It also wraps to three or more lines, depending on the length of the text and how wide the container is. I'm guessing this isn't expected, as the demo gifs don't show this.
Any thoughts on how to prevent the text wrapping?

Hey,
I had the same problem and also my list was lagging a bit.
So, instead of doing this:
{     text: 'Edit',     backgroundColor: '#f39c12',     color: 'white',     underlayColor: '#e67e22',   },
I started doing this:
{     text: 'Edit',     backgroundColor: '#f39c12',     color: 'white',     component: <Text>Edit</Text>,     underlayColor: '#e67e22',   },
With that I solved my lagging and the text wrapping.

It is also troubling me

My workaround is this:
const swipeBtns = [
       {
          component: <Text style={{numberOfLines: 1}}>Edit</Text>,
        },
]

it's work for me! @p-ugulino


Proposal: in Functions allow nested REST-like routes without backing files

Currently it looks like functions only do file based routing and any attempt to get a nested route returns Cannot GET <url>
E.g. REST apis like /rooms and /rooms/:id and /rooms/:id/schedule seem like they return Cannot GET /rooms no matter what I try.
The current functions Express server code and relevant line that adds each file (except for underscores) as a route:
server
I've tried using express() to get what I hope is the current app and adding routes within my function files (globally) but adding new routes dynamically after other app.use() middleware and the app.all() calls in the loop (code above) does not work - Express ignores them (according to a few Googled SO answers).
Backward compatibility at this point in time is pretty key so here's a proposal that might preserve current user code as is but introduce a workaround for those who need it.
// Line 49: Import `register` function if it exists
const { default: handler, register } = await import(path.join(functionsPath, file))

// ...

// Line 58: if `register` found, use it otherwise do default `app.all()`
const route = `/${file}`.replace(/(\.ts|\.js)$/, '').replace(/\/index$/, '/')
try {
  if (register) {
    register(app, route) // See below
  } else if (handler) { // Note: checking this too.
    app.all(route, handler)
  }
} catch (error) {
//...

Options:

return some kind success such that on failure, app.all() is called anyway. Not clear that would be the desired behavior :shrug:
have registration return an Express Router instead. Something like this example.

There are a few other discussions about 'dynamic routes' but seems like register() should do the trick.
import { Express, Request, Response } from 'express'
// ...
export default const handler = (req: Request, res: Response) => { }
// ...
export const register = (app: Express, base: string) => {
    console.log('register', base)
    app.get(base + '/room', handler)
    app.get(base + '/room/:id', handler)
    //...

    // Nothing to return?
}

I've tested my proposal as far as I can from within a function

doing the import() works as expected: existing code should work fine
register value is undefined if the function doesn't exist or isn't exported in the nested route's implementation TS
one thing that could be better is a bit more Typescript support to make sure register call is correct but I can't figure out how to make that a minimal declaration of register's type. Maybe (app: Express, route: string) | undefined.

Lastly, it might also be interesting to limit this option only to index.ts|js files if that makes breaking existing code somewhat less likely.
Suggestions welcome.

Another direction to go in would be to create a new type of Function for 'webhook' (or a new name) that functioned like actions and events:

treat 'index.ts' files in subfolders specially (or use a new reserved file name like endpoint.ts)
look at the incoming request and parse it into a specific structure like actions and events do
let the endpoint process however it wants


Feature/slo compatibility

This PR removes the extraneous attribute of "sso_url" since it already existed.

Moving to dev branch...


Chaperone height seems to be broken

The chaperone height doesn't change when I adjust it and save it in the tool. Perhaps because of my custom Steam directory?

I also had to switch Steam directories, and Chaperone Tweak doesn't save anything for me either now.
I thought it was due to the virus protection which prevented me from updating Steam in the first place, but perhaps ChaperoneTweak doesn't support anything but the default Steam directory name?


update to v2.0 event interface

LGTM

@suyograo already done in https://github.com/logstash-plugins/logstash-input-xmpp/commit/de5ebedfffd751e6738a2c2b16bdd6431e01216e no ?

I seems this is in master but I can't find the closed PR that did it.


Bump postcss and next #2

Hi ,
I'm a contributor to the [Repository Name] project. I wanted to discuss the pull request titled "Bump postcss and next #2" and its importance to the project.
The pull request proposes updates to two dependencies: "postcss" and "next." Specifically, it updates "postcss" from version 8.4.14 to 8.4.31 and "next" from version 13.4.6 to 13.5.4. These updates are crucial for [Explain Why They Are Important].
I believe that merging this pull request is essential for maintaining the project's stability, security, and functionality. It aligns with best practices for dependency management.
I have reviewed the changes, and they appear to be in order. However, I understand that you may have specific guidelines or considerations for dependency updates. I would greatly appreciate your insights and guidance on whether it's appropriate to merge this pull request.
If you have any questions or need further information, please don't hesitate to reach out. Your expertise in maintaining this project is highly valued, and I want to ensure that the update aligns with your vision for the repository.
Thank you for your time and dedication to the project. I look forward to your response and any direction you can provide regarding the pull request.
Best regards,

I need some more detail. I need to know this isn't all some jokes. I know I'm not crazy

can you help me


Use setLimits in set_param_from_param

took me a while to figure out that .copy() was necessary :-)

Could you add a test to make sure the widget items are properly updated when using set_param_from_param? You can have a look to the one I wrote in Param_utils_test to get the widget from a tree.

sorry I can't find where you do the test on the widget! I checked tests/utils/parameter_test/param_utils_test.py in branch settings or pymodaq-dev. is it somewhere else?


[video_player]add http headers option when loading network data source

I added optional request headers to VideoPlayerController.network contructor for video_player plugin. I did not see an obvious place to create a test for these changes, but happy to do so if you would like. I did manually test these changes on iOS and Android emulator.

I signed it!

We've had no issues with getting apps through the store with the AVURLAssetHTTPHeaderFieldsKey and I've found no one that has...

I really need this feature for my project. Unfortunately this PR seems abandoned. Any chance in getting it resumed?

I really need this feature for my project. Unfortunately this PR seems abandoned. Any chance in getting it resumed?

See comments in feature request https://github.com/flutter/flutter/issues/16466 and a similar pr https://github.com/flutter/plugins/pull/897
If I were you and you really need it, fork the repo, apply one of the prs (will have to update a little I am sure), and move on. You will have to merge in changes from the main repo though whenever you want the latest (see https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-an-upstream-repository-into-your-fork).

Can someone resolve the conflicts and merge it. That is very useful feature!
Thank you!

Closing, as there is already https://github.com/flutter/plugins/pull/897 which addresses the same issue; let's consolidate discussion there.


fix(actors): delete invalid reminders codes

the first time, daprd runtime actor received the reminder grpc/http request of placement,  than the reminder task will be executed after dueTime+time.Now;
next time, the reminder task will be executed in a scheduled daprd runtime actor,  execution time is nextInvokeTime+period
so the followed codes never be running.
    } else {
        if !lastFiredTime.IsZero() {
            nextInvokeTime = lastFiredTime.Add(dueTime)
        } else {
            nextInvokeTime = registeredTime.Add(dueTime)
        }
    }

@vinayada1 please review

@vinayada1 please review


Cannot swap two files

Bug Report Template
roamer --version:
0.2.1
OS:
mac os x 10.11.6
Python version:
2.7.10
Steps to reproduce (start with removing ~/.roamer-data):
$ mkdir test
$ cd test
$ echo "file1" > file1
$ echo "file2" > file2
$ roamer

I want to rename file1 -> file2 and file2 -> file1, so  I swap the two hashes (or the two file names, the same happens)
before editing:
" pwd: /private/tmp/test
file2 | fb4274b4ca38
file1 | c5075497aa5f

after editing:
" pwd: /private/tmp/test
file2 | c5075497aa5f
file1 | fb4274b4ca38

save, quit and inspect the result
$ roamer
roamer-trash-copy /private/tmp/test/file2
roamer-trash-copy /private/tmp/test/file1
cp /private/tmp/test/file2 /private/tmp/test/file1
cp /private/tmp/test/file1 /private/tmp/test/file2
$ cat file1
file2
$ cat file2
file2

Both files now have "file2" as content.

Excellent bug report 👍


Disable debug button if in debugging mode

Issue Type: Feature Request
Let's disable green play button for certain configuration if the debug configuration is already running.
It interferes with blue play button on the debug panel.
VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:06:21.742Z)
OS version: Darwin x64 18.0.0

@karanisverma ok. Here's a code pointer https://github.com/Microsoft/vscode/blob/f041bc0c5f05e3b53468b0de0765cbd9a1407c31/src/vs/workbench/parts/debug/browser/debugActionItems.ts#L26
The action is already disabled, it is just now grated out.
Basically if the start debug action is disabled via this the icon should be faded out.

Awesome! Thanks @isidorn for code pointer. I will share PR for the same.

Thanks @RealBuddy!

Hi @isidorn, I have pulled the changes from master. However I am can't see  isEnabled function  which you pointed to. master's isEnabled function always returns true!?
I am confused 🤔 Please help.

@karanisverma sorry but I do not have time this milestone to help with Pull Requests.
If you can try to figure it out, if not I can fix this issue later in January.
Thanks

Thanks @isidorn, I will try to figure it out :)

sorry for the delay, I will resume working on it from tomorrow. hopes that's fine 🙄


Docs: Socket-based interceptor

Socket Interception
#ideas
Over the years, I sat down to write Socket-based interceptor at least half a dozen times. It never ended fruitfully. This time, I decided to at least document my findings and struggles so I don’t spend so much time finding my way in the same water once more.
Intention
The intention here is very simple: the network in Node.js goes through net.Socket, no matter who and how initiates it. http.ClientRequest constructs a Socket instance, fetch (Undici) constructs a Socket instance, and even bi-directional communication like WebSockets is also implemented through Socket. Tapping into net.Socket directly would mean even less request-specific code.
Obstacles
net.Socket is omitted  sometimes
Contradictory to my statement in the Intention, the call to net.Socket, net.connect() or net.createConnection() is not always performed when a request is made in Node.js. For example, the very default http.get() call will not result in either of those functions being called. There’s quite a chunk of internal logic in Node.js around creating and managing sockets (hence the Agent), and I can only speculate that it doesn’t create a new socket but it depends on the already created one, somehow.
Socket is too low-level
Socket handles Buffer sent/received over the network. We are talking about raw HTTP messages and raw Readable streams. Reading those isn’t a problem, recreating those is.
Re-creating that, eventually, becomes a necessity because if you extend net.Socket and emulate a successful connection to a host (since the actual connection would error, the host is mocked), you end up managing the entire socket’s life-cycle by yourself.
class Socket extends net.Socket {
  connnect(...args) {
    // This is enough to pretend that the Socket instance
    // has looked up, resolved, and connected to a host.
    this.connecting = true
    this.emit('lookup', '<IP_ADDRESS>', 'IPv6', 'hostname')
    this.emit('connect', false)
    this.connecting = false
    return this
  }
}

There are more parts in the socket that depend on its state. For instance, you have to have the this._handle set, which is a reference to a TCP or Pipe wraps responsible for piping chunks through the socket.

To make things worse, those handles are internal in Node.js and you cannot construct them by yourself. Reference.

You end up implementing things like handle.writeLatin1String, handle.readStart(), handle.close(), and so forth. Honestly, this is too much.
Good things
On the bright side, or, rather, the side I’ve never got to in order to prove it’s even worse, reading/writing chunks is a matter of manipulating the socket’s stream. The worst part about it is having to translate the HTTP request message to some consumable format, like Request, and translate the mocked Response to the HTTP response message. None of those are deal-breaking.

Node.js doesn’t expose its HTTP message parser. It’s present on ClientRequest and the socket instances but you cannot operate with it easily.

Another good thing is that socket observer is trivial. It can be achieved with revokable Proxies spying at .write and .on(‘data')  methods/events. But observer alone is not enough to fulfill the interception requirements.
Where to go from here
Socket-based interception is, technically, possible. But it’s a big question whether it’s worth the price. Maintaining such an interceptor would require a deep knowledge of Node.js internals and keeping track of whenever those change across Node.js releases.
We may require to revisit this in the light of WebSockets support, but given how there’s no standard protocol for WebSockets, and the most popular solutions implement it over HTTP/XHR polling anyway, perhaps Socket-based interception won’t be needed entirely.

Socket is also sensitive to import order. Since most of developers don't import it directly, the Interceptor must be imported before any of the third-parties. This is problematic to achieve sometimes.

Released: v0.32.0 🎉
This has been released in v0.32.0!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.


[docs] Fix various layout issues with the v5 banner

Preview: https://deploy-preview-27237--material-ui.netlify.app/components/material-icons/#material-icons
Preview: https://deploy-preview-27237--material-ui.netlify.app/company/careers/

What's the height of the banner, 36px?

Yes, but it felt better with 30px margin. I could update.

Yes, but it felt better with 30px margin. I could update.

Ok, I didn't realize we were polishing the value too, makes sense. I asked because I have made a change in an opposite direction in https://github.com/mui-org/material-ui/commit/125f3db635f75f9c785022a31c295b4b69d15e1a#diff-77f04bc58bbbb50bc7d3dea9ec533b08d76f110c581114cda8105da367d236a5R12 to fix an issue with the anchor origin. I don't have a real preference on the approach as long as it's consistent.

Ok, I didn't realize we were polishing the value too, makes sense. I asked because I have made a change in an opposite direction in 125f3db#diff-77f04bc58bbbb50bc7d3dea9ec533b08d76f110c581114cda8105da367d236a5R12 to fix an issue with the link anchor origin. I don't have a real preference on the approach as long as it's consistent. I'm unsubscribing to PR. Maybe in v5 we should use more constants, to make the math visible. It's never obvious if the value is purely from a design one or if it satisfies a layout constraint.

Agree, let me in that case update to 36 so that we are going to be consistent.

I have pushed the changes to the docs repo so they can go live within the next few minutes.


Enable use of "type of organisation" with participating organisation roles

Is your feature request related to a problem? Please describe.
The filter for "type of organisation" appears just below "reporting organisation" and next to "secondary reporter?" This can lead users to think that the "type of organisation" filter will apply to organisation in the reporting or publishing organisations.
On the other hand, users could want to select activities funded by government (ie organisation role=funding + type=government") or activities implemented by international NGOs (ie organisation role=implementing + type=International NGO)
Describe the solution you'd like
Enable users to chose whether "type of organisation" applies to all participating organisations or only to certain roles when building their query.
Perhaps also move the filter "type of organisation" to avoid confusion for users about whether this filter applies to reporting org.

Thanks Josh. That would remove the confusion, if indeed the filter only applies to the reporting organisation field.
However, it would be a pity to not have type of organisation as a filter on other fields - especially funding and implementing. I'd like to keep this as a proposed feature as there are very few alternatives to this filter: in some cases "type of aid" can be used as a proxy, but the resulting data would be incomplete.


Private Link and DNS Alias

Azure requires user to access private link resource via original FQDN,
as described in https://docs.microsoft.com/en-us/azure/azure-sql/database/private-endpoint-overview#check-connectivity-using-psping
mysqldbsrvr.database.windows.net
Meanwhile it supports to create DNS alias,  and we use DNS alias to access private endpoint?
What about the certificate?
Here is the similar question from another post.
https://techcommunity.microsoft.com/t5/azure-sql-database/azure-sql-db-with-custom-name-and-with-ssl-cert-for-powerbi/m-p/1361874
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: eb6328aa-a54f-4936-1c35-ecf5c265d92d
Version Independent ID: 345bd3d2-4b53-a032-c13b-7e35f97cf2fa
Content: Azure Private Link - Azure SQL Database and Azure Synapse Analytics
Content Source: articles/azure-sql/database/private-endpoint-overview.md
Service: sql-database
GitHub Login: @rohitnayakmsft
Microsoft Alias: rohitna

@RonnieQuan Thank you for the detailed feedback. We are actively investigating and will get back to you soon.

@RonnieQuan
As per the note in the document with regard to checking connectivity using SSMS (link):

Use the Fully Qualified Domain Name (FQDN) of the server in connection strings for your clients. Any login attempts made directly to the IP address shall fail. This behavior is by design, since private endpoint routes traffic to the SQL Gateway in the region and the FQDN needs to be specified for logins to succeed.

Any request to your database instance would be the original FQDN + 1433 and based upon any routing requirement, that FQDN is routed to the private endpoint via the private link or to the public endpoint based upon the information contained in the the document. The private link functionality allows for the FQDN to not route to the public endpoint after an on-premise client connection is made, where the on-premise client connection is routed via VPN + VPN Gateway to the private link (See: Connecting from an on-premises environment over VPN). The SSL/TLS handshake will be successful because the originating client connection was made to the FQDN.

@RonnieQuan As for the Power BI issue with certificate FQDN mismatch, if the Power BI solution is part of a VNET and private link is leveraged, there are a couple options:
Connecting from an Azure VM in Peered Virtual Network (link)
Connecting from an Azure VM in virtual network to virtual network environment (link)
This ensures that the FQDN can be leveraged by Power BI as part of the database connection string, and the desired TLS is enforced and that routing is all done via private addressing to private endpoints. I don't think that the DNS Aliasing utility is going to resolve the networking routing configuration but the issue with the certificate and this new DNS alias raises another issue.

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


IMS IWstub development

As required by T6.3 is necessary to implement a IWstub to interact with an IMS lab environment.
High level details fo the IW stub are documented in this presentation: GDocs

We are in the process to define exactly how to do the authentication and the support of this scenario in Kamailio. Below you can find the issues where FHG and Quobis are working on:

we will have a new module for web_auth for authenticating the token
extracting the header from webrtc is 1 line script in the config file, e.g. $hdr(Web-Token)
generating SIP identities can be done with the uuid module: https://www.kamailio.org/docs/modules/stable/modules/uuid.html
storing associations is quite easy with redis, hashtable modules, right from the configuration script

We should have more advances by the end of this week.

@dvilchez please, when you can check if it's possibel to add a customized header (Web-Token) in the GET which creates the Websocket connection from the broswer. If not, we could send a pre-flight GET with that header so that Kamailio authorizes it.


Profile Manager: Capitalize the titles of the tabs instead of being all in uppercase

Description
The titles for the tabs in the profile manager should be capitalized not all in uppercase.
LOGIN -> Login
CONNECT YOUR WALLET -> Connect Your Wallet

Environment

Network: devnet
Dashboard Version: 2.1.0-rc3

verified


Functions created with classic App Service Plan should have Always On enabled by default

When creating a new Function App in a Basic or higher tier, we should turn on Always On. It's true that technically customers don't need it if they are only using HTTP triggers, but most triggers aren't HTTP.
This is related to https://github.com/projectkudu/AzureFunctionsPortal/issues/518, but this issue is about changing the default behavior in our ARM template.

I agree that we should do this.

Agreed. This is always the first thing we have to ask people when they tell us "their functions stopped running", and it's often the issue. It'd be good to remove this pitfall.

Confirmed fixed in canary, will be in prod soon.


It asks for a version that doesn't exist

Describe the bug
When I start the game, it asks me to update forgified fabric api to a version, that doesn't exist
Steps to reproduce
1.I download the mods I need (Alex's mobs, Citadel, Wilder wild, Forgified fabric api and sinytra connector)
2.I enter the game
3.It says following:

Logs
[21:44:51] [main/INFO]: ModLauncher running: args [--username, Atmarsde, --version, forge-47.1.3, --gameDir, C:\Users\artem\curseforge\minecraft\Instances\forge fabric, --assetsDir, C:\Users\artem\curseforge\minecraft\Install\assets, --assetIndex, 5, --uuid, 97df0dee82714963ac109fbc9969f2aa, --accessToken, ????????, --clientId, NzQ5MTRhMmQtNDhiZi00YmUyLWFlZmUtNTc0ZjU4N2VjNzNm, --xuid,<PHONE_NUMBER>123972, --userType, msa, --versionType, release, --width, 1024, --height, 768, --quickPlayPath, C:\Users\artem\curseforge\minecraft\Install\quickPlay\java\1696707889333.json, --launchTarget, forgeclient, --fml.forgeVersion, 47.1.3, --fml.mcVersion, 1.20.1, --fml.forgeGroup, net.minecraftforge, --fml.mcpVersion, 20230612.114412] [21:44:51] [main/INFO]: ModLauncher 10.0.9+10.0.9+main.dcd20f30 starting: java version 17.0.8 by Microsoft; OS Windows 10 arch amd64 version 10.0 [21:44:51] [main/INFO]: Loading ImmediateWindowProvider fmlearlywindow [21:44:51] [main/INFO]: Trying GL version 4.6 [21:44:52] [main/INFO]: Requested GL version 4.6 got version 4.6 [21:44:52] [main/INFO]: Mixin Transmogrifier is definitely up to no good... [21:44:52] [pool-2-thread-1/INFO]: GL info: NVIDIA GeForce RTX 2060 with Max-Q Design/PCIe/SSE2 GL version 4.6.0 NVIDIA 532.03, NVIDIA Corporation [21:44:53] [main/INFO]: Redefining 5 mixin classes [21:44:53] [main/INFO]: crimes against java were committed [21:44:53] [main/INFO]: Original mixin transformation service successfully crobbed by mixin-transmogrifier! [21:44:53] [main/INFO]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=union:/C:/Users/artem/curseforge/minecraft/Instances/forge%20fabric/mods/Connector-1.0.0-beta.17+1.20.1-full.jar%23161%23164!/ Service=ModLauncher Env=CLIENT [21:44:53] [main/INFO]: Found mod file Connector-1.0.0-beta.17+1.20.1-mod.jar of type MOD with provider dev.su5ed.sinytra.connector.locator.ConnectorEarlyLocator@22d9c961 [21:44:53] [main/INFO]: Found mod file alexsmobs-1.22.6.jar of type MOD with provider {mods folder locator at C:\Users\artem\curseforge\minecraft\Instances\forge fabric\mods} [21:44:53] [main/INFO]: Found mod file citadel-2.4.4-1.20.1.jar of type MOD with provider {mods folder locator at C:\Users\artem\curseforge\minecraft\Instances\forge fabric\mods} [21:44:53] [main/INFO]: Found mod file fabric-api-0.89.0+1.9.25+1.20.1.jar of type MOD with provider {mods folder locator at C:\Users\artem\curseforge\minecraft\Instances\forge fabric\mods} [21:44:54] [main/WARN]: Mod file C:\Users\artem\curseforge\minecraft\Install\libraries\net\minecraftforge\fmlcore\1.20.1-47.1.3\fmlcore-1.20.1-47.1.3.jar is missing mods.toml file [21:44:54] [main/WARN]: Mod file C:\Users\artem\curseforge\minecraft\Install\libraries\net\minecraftforge\javafmllanguage\1.20.1-47.1.3\javafmllanguage-1.20.1-47.1.3.jar is missing mods.toml file [21:44:54] [main/WARN]: Mod file C:\Users\artem\curseforge\minecraft\Install\libraries\net\minecraftforge\lowcodelanguage\1.20.1-47.1.3\lowcodelanguage-1.20.1-47.1.3.jar is missing mods.toml file [21:44:54] [main/WARN]: Mod file C:\Users\artem\curseforge\minecraft\Install\libraries\net\minecraftforge\mclanguage\1.20.1-47.1.3\mclanguage-1.20.1-47.1.3.jar is missing mods.toml file [21:44:54] [main/INFO]: Found mod file fmlcore-1.20.1-47.1.3.jar of type LIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found mod file javafmllanguage-1.20.1-47.1.3.jar of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found mod file lowcodelanguage-1.20.1-47.1.3.jar of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found mod file mclanguage-1.20.1-47.1.3.jar of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found mod file client-1.20.1-20230612.114412-srg.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found mod file forge-1.20.1-47.1.3-universal.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@58399d82 [21:44:54] [main/INFO]: Found 42 dependencies adding them to mods collection [21:44:54] [main/INFO]: Found mod file fabric-transfer-api-v1-3.3.1+4c6d1bcd77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-dimensions-v1-2.1.53+8005d10d77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-game-rule-api-v1-1.0.38+22f4bbd577.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-api-base-0.4.30+ef105b4977.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-renderer-api-v1-3.2.0+6f53282b77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-api-lookup-api-v1-1.6.35+561530ec77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-blockrenderlayer-v1-1.1.40+8005d10d77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-item-api-v1-2.1.27+cf233c5877.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-model-loading-api-v1-1.0.2+731e429d77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-block-api-v1-1.0.10+0e6cb7f777.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-rendering-fluids-v1-3.0.27+4ac5e37a77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-resource-conditions-api-v1-2.3.5+afab492177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-screen-handler-api-v1-1.3.29+561530ec77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-resource-loader-v0-0.11.9+65ee760177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-models-v0-0.4.1+7c3892a477.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-rendering-v1-3.0.7+1c0ea72177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-renderer-indigo-1.5.0+6f53282b77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-item-group-api-v1-4.0.10+f6e291bf77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-convention-tags-v1-1.5.4+fa3d1c0177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-mining-level-api-v1-2.1.49+561530ec77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-command-api-v2-2.2.12+561530ec77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-block-view-api-v2-1.0.0+0767707077.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file Connector-1.0.0-beta.17+1.20.1-fabricloader.jar of type LIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-biome-api-v1-13.0.10+1fd6f40777.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-entity-events-v1-1.5.22+b909fbe377.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-registry-sync-v0-2.3.2+1c0ea72177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-recipe-api-v1-1.0.20+514a076577.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-loot-api-v2-1.1.39+2e4442f377.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-object-builder-api-v1-11.1.1+1c0ea72177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-screen-api-v1-2.0.7+e7e7fde177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-rendering-data-attachment-v1-0.3.36+a6081afc77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-networking-api-v1-1.3.10+8ba517a077.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-particles-v1-1.1.1+7802dd6f77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-sound-api-v1-1.0.12+4f23bd8477.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-message-api-v1-5.1.7+ff2512b877.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-content-registries-v0-4.0.9+afab492177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-lifecycle-events-v1-2.2.21+afab492177.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-transitive-access-wideners-v1-4.3.0+1880499877.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-data-generation-api-v1-12.3.0+fbedf1fa77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-events-interaction-v0-0.6.1+25d9948677.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-key-binding-api-v1-1.0.36+561530ec77.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:54] [main/INFO]: Found mod file fabric-client-tags-api-v1-1.1.1+5d6761b877.jar of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.JarInJarDependencyLocator@fabb651 [21:44:55] [main/ERROR]: Failed to load dependencies with locator dev.su5ed.sinytra.connector.locator.ConnectorLocator@69923ac3 net.minecraftforge.fml.loading.EarlyLoadingException: Mod resolution encountered an incompatible mod set! A potential solution has been determined: 	 - Replace mod 'Forgified Fabric API' (fabric_api) 0.89.0+1.9.25+1.20.1 with mod 'Forgified Fabric API' (fabric_api), version 0.89.3+1.20.1 or later. Unmet dependency listing: 	 - Mod 'Wilder Wild' (wilderwild) 2.1.6-Fabric+1.20.1 requires version 0.89.3+1.20.1 or later of mod 'Forgified Fabric API' (fabric_api), but only the wrong version is present: 0.89.0+1.9.25+1.20.1! 	at dev.su5ed.sinytra.connector.loader.ConnectorEarlyLoader.createLoadingException(ConnectorEarlyLoader.java:70) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at dev.su5ed.sinytra.connector.locator.DependencyResolver.resolveDependencies(DependencyResolver.java:66) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at dev.su5ed.sinytra.connector.locator.ConnectorLocator.locateFabricMods(ConnectorLocator.java:123) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at dev.su5ed.sinytra.connector.locator.ConnectorLocator.scanMods(ConnectorLocator.java:67) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer.discoverMods(ModDiscoverer.java:128) ~[fmlloader-1.20.1-47.1.3.jar:?] 	at net.minecraftforge.fml.loading.FMLLoader.beginModScan(FMLLoader.java:164) ~[fmlloader-1.20.1-47.1.3.jar:1.0] 	at net.minecraftforge.fml.loading.FMLServiceProvider.beginScanning(FMLServiceProvider.java:86) ~[fmlloader-1.20.1-47.1.3.jar:1.0] 	at cpw.mods.modlauncher.TransformationServiceDecorator.runScan(TransformationServiceDecorator.java:112) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.TransformationServicesHandler.lambda$runScanningTransformationServices$8(TransformationServicesHandler.java:100) ~[modlauncher-10.0.9.jar:?] 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?] 	at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1779) ~[?:?] 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?] 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?] 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) ~[?:?] 	at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) ~[?:?] 	at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) ~[?:?] 	at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) ~[?:?] 	at java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) ~[?:?] 	at cpw.mods.modlauncher.TransformationServicesHandler.runScanningTransformationServices(TransformationServicesHandler.java:102) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.TransformationServicesHandler.initializeTransformationServices(TransformationServicesHandler.java:55) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.Launcher.run(Launcher.java:88) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.Launcher.main(Launcher.java:78) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:141) ~[bootstraplauncher-1.1.2.jar:?] Caused by: net.fabricmc.loader.impl.discovery.ModResolutionException: Mod resolution encountered an incompatible mod set! A potential solution has been determined: 	 - Replace §emod 'Forgified Fabric API' (fabric_api) 0.89.0+1.9.25+1.20.1§r with mod 'Forgified Fabric API' (fabric_api), version 0.89.3+1.20.1 or later. Unmet dependency listing: 	 - §eMod 'Wilder Wild' (wilderwild)§r 2.1.6-Fabric+1.20.1 requires version 0.89.3+1.20.1 or later of §6mod 'Forgified Fabric API' (fabric_api)§r, but only the wrong version is present: 0.89.0+1.9.25+1.20.1! 	at net.fabricmc.loader.impl.discovery.ModResolver.findCompatibleSet(ModResolver.java:149) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at net.fabricmc.loader.impl.discovery.ModResolver.resolve(ModResolver.java:35) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	at dev.su5ed.sinytra.connector.locator.DependencyResolver.resolveDependencies(DependencyResolver.java:58) ~[Connector-1.0.0-beta.17+1.20.1-full.jar%23161!/:1.0.0-beta.17+1.20.1] 	... 23 more [21:44:56] [main/INFO]: Compatibility level set to JAVA_17 [21:44:56] [main/ERROR]: Skipping early mod setup due to previous error [21:44:56] [main/INFO]: Launching target 'forgeclient' with arguments [--version, forge-47.1.3, --gameDir, C:\Users\artem\curseforge\minecraft\Instances\forge fabric, --assetsDir, C:\Users\artem\curseforge\minecraft\Install\assets, --uuid, 97df0dee82714963ac109fbc9969f2aa, --username, Atmarsde, --assetIndex, 5, --accessToken, ????????, --clientId, NzQ5MTRhMmQtNDhiZi00YmUyLWFlZmUtNTc0ZjU4N2VjNzNm, --xuid,<PHONE_NUMBER>123972, --userType, msa, --versionType, release, --width, 1024, --height, 768, --quickPlayPath, C:\Users\artem\curseforge\minecraft\Install\quickPlay\java\1696707889333.json] [21:45:00] [Datafixer Bootstrap/INFO]: 188 Datafixer optimizations took 152 milliseconds [21:45:02] [Render thread/WARN]: Assets URL 'union:/C:/Users/artem/curseforge/minecraft/Install/libraries/net/minecraft/client/1.20.1-20230612.114412/client-1.20.1-20230612.114412-srg.jar%23170!/assets/.mcassetsroot' uses unexpected schema [21:45:02] [Render thread/WARN]: Assets URL 'union:/C:/Users/artem/curseforge/minecraft/Install/libraries/net/minecraft/client/1.20.1-20230612.114412/client-1.20.1-20230612.114412-srg.jar%23170!/data/.mcassetsroot' uses unexpected schema [21:45:02] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD' [21:45:02] [Render thread/INFO]: Setting user: Atmarsde [21:45:02] [Render thread/ERROR]: Skipping early mod loading due to previous error [21:45:02] [Render thread/INFO]: Added resource packs: [] [21:45:02] [Render thread/INFO]: Backend library: LWJGL version 3.3.1 build 7 [21:45:03] [Render thread/FATAL]: Error during pre-loading phase net.minecraftforge.fml.ModLoadingException: Mod resolution encountered an incompatible mod set! A potential solution has been determined:    - Replace §emod Forgified Fabric API (fabric_api) 0.89.0+1.9.25+1.20.1§r with mod Forgified Fabric API (fabric_api), version 0.89.3+1.20.1 or later. Unmet dependency listing:    - §eMod Wilder Wild (wilderwild)§r 2.1.6-Fabric+1.20.1 requires version 0.89.3+1.20.1 or later of §6mod Forgified Fabric API (fabric_api)§r, but only the wrong version is present: 0.89.0+1.9.25+1.20.1! 	at net.minecraftforge.fml.ModLoadingException.lambda$fromEarlyException$0(ModLoadingException.java:50) ~[fmlcore-1.20.1-47.1.3.jar%23171!/:?] 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?] 	at java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(AbstractList.java:720) ~[?:?] 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?] 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?] 	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?] 	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?] 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?] 	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) ~[?:?] 	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276) ~[?:?] 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[?:?] 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?] 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?] 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[?:?] 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?] 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?] 	at net.minecraftforge.fml.ModLoader.(ModLoader.java:96) ~[fmlcore-1.20.1-47.1.3.jar%23171!/:?] 	at net.minecraftforge.fml.ModLoader.get(ModLoader.java:128) ~[fmlcore-1.20.1-47.1.3.jar%23171!/:?] 	at net.minecraftforge.client.loading.ClientModLoader.lambda$begin$1(ClientModLoader.java:73) ~[forge-1.20.1-47.1.3-universal.jar%23175!/:?] 	at net.minecraftforge.client.loading.ClientModLoader.lambda$createRunnableWithCatch$4(ClientModLoader.java:93) ~[forge-1.20.1-47.1.3-universal.jar%23175!/:?] 	at net.minecraftforge.client.loading.ClientModLoader.begin(ClientModLoader.java:73) ~[forge-1.20.1-47.1.3-universal.jar%23175!/:?] 	at net.minecraft.client.Minecraft.(Minecraft.java:459) ~[client-1.20.1-20230612.114412-srg.jar%23170!/:?] 	at net.minecraft.client.main.Main.main(Main.java:182) ~[forge-47.1.3.jar:?] 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?] 	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] 	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?] 	at net.minecraftforge.fml.loading.targets.CommonLaunchHandler.runTarget(CommonLaunchHandler.java:111) ~[fmlloader-1.20.1-47.1.3.jar:?] 	at net.minecraftforge.fml.loading.targets.CommonLaunchHandler.clientService(CommonLaunchHandler.java:99) ~[fmlloader-1.20.1-47.1.3.jar:?] 	at net.minecraftforge.fml.loading.targets.CommonClientLaunchHandler.lambda$makeService$0(CommonClientLaunchHandler.java:25) ~[fmlloader-1.20.1-47.1.3.jar:?] 	at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:30) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:53) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:71) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.Launcher.run(Launcher.java:108) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.Launcher.main(Launcher.java:78) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23) ~[modlauncher-10.0.9.jar:?] 	at cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:141) ~[bootstraplauncher-1.1.2.jar:?] [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.sound.SoundEngineLoadEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterColorHandlersEvent$Block to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterColorHandlersEvent$Item to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RenderLevelStageEvent$RegisterStageEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterParticleProvidersEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterClientReloadListenersEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$RegisterLayerDefinitions to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$RegisterRenderers to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterTextureAtlasSpriteLoadersEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterClientTooltipComponentFactoriesEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterEntitySpectatorShadersEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterKeyMappingsEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterRecipeBookCategoriesEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterGuiOverlaysEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterDimensionSpecialEffectsEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterNamedRenderTypesEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterColorHandlersEvent$ColorResolvers to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterItemDecorationsEvent to a broken mod state [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterPresetEditorsEvent to a broken mod state [21:45:03] [Render thread/INFO]: Reloading ResourceManager: vanilla [21:45:03] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.ModelEvent$RegisterGeometryLoaders to a broken mod state [21:45:03] [Worker-Main-5/INFO]: Found unifont_all_no_pua-15.0.06.hex, loading [21:45:04] [Worker-Main-8/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.ModelEvent$RegisterAdditional to a broken mod state [21:45:05] [Worker-Main-8/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.ModelEvent$ModifyBakingResult to a broken mod state [21:45:05] [Render thread/WARN]: Missing sound for event: minecraft:item.goat_horn.play [21:45:05] [Render thread/WARN]: Missing sound for event: minecraft:entity.goat.screaming.horn_break [21:45:05] [Render thread/INFO]: OpenAL initialized on device OpenAL Soft on Kopfhörer (Galaxy Buds (454C) Stereo) [21:45:05] [Render thread/INFO]: Sound engine started [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.sound.SoundEngineLoadEvent to a broken mod state [21:45:05] [Render thread/INFO]: Created: 1024x512x4 minecraft:textures/atlas/blocks.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 256x256x4 minecraft:textures/atlas/signs.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 512x512x4 minecraft:textures/atlas/banner_patterns.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 512x512x4 minecraft:textures/atlas/shield_patterns.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 1024x1024x4 minecraft:textures/atlas/armor_trims.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 256x256x4 minecraft:textures/atlas/chest.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 128x64x4 minecraft:textures/atlas/decorated_pot.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 512x256x4 minecraft:textures/atlas/beds.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 512x256x4 minecraft:textures/atlas/shulker_boxes.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.ModelEvent$BakingCompleted to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$CreateSkullModels to a broken mod state [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.EntityRenderersEvent$AddLayers to a broken mod state [21:45:05] [Render thread/WARN]: Shader rendertype_entity_translucent_emissive could not find sampler named Sampler2 in the specified shader program. [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.RegisterShadersEvent to a broken mod state [21:45:05] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/particles.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/paintings.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:05] [Render thread/INFO]: Created: 128x128x0 minecraft:textures/atlas/mob_effects.png-atlas [21:45:05] [Render thread/ERROR]: Cowardly refusing to send event net.minecraftforge.client.event.TextureStitchEvent$Post to a broken mod state [21:45:06] [Render thread/FATAL]: Crash report saved to C:\Users\artem\curseforge\minecraft\Instances\forge fabric\crash-reports\crash-2023-10-07_21.45.06-fml.txt
Additional context
No response

FFAPI version 0.90.0+1.9.25+1.20.1 is now available.


seedgen: Fix recert podman pull for disconn registries

In a totally disconn env, the recert image may be mirrored to the local (private) registry as well.
(this is assuming recert and seed image share creds for the same local registry)

/cc @donpenney @jc-rh

assuming recert and seed image share creds for the same local registry

I don't think you can make that assumption. The auth file in the secret, as it stands today, only needs the write-auth for the repository to which the seed image is to be written. As well, if the seed SNO is setup to use a disconnected registry, it should already have the auth needed to pull the recert image from that registry, no? The only scenario in which you'd need to be able to specify a different auth file for this pull would be if the recert image was mirrored to a different registry than that used for installing the SNO, isn't it?

If you wanted to reuse the write-auth for pulling the recert image, I think you would need to merge it with the pull secrets for the cluster before writing it to file

As well, if the seed SNO is setup to use a disconnected registry, it should already have the auth needed to pull the recert image from that registry, no?

this is precisely what fails in my disconn env (see below error). The disconnected cluster has the creds configured but the pulling of the recert image fails (cause code doesn't specify where to find those creds).
2023-12-14T18:02:33Z	ERROR	Reconciler error	{"controller": "seedgenerator", "controllerGroup": "lca.openshift.io", "controllerKind": "SeedGenerator", "SeedGenerator": {"name":"seedimage"}, "namespace": "", "name": "seedimage", "reconcileID": "1a241eaa-394f-4fd5-82cb-3b7652dd717b", "error": "failed to pull recert image: failed to pull recertImage (jumphost.inbound.vz.bos2.lab:8443/edge-infrastructure/recert:latest): Trying to pull jumphost.inbound.vz.bos2.lab:8443/edge-infrastructure/recert:latest...\nError: initializing source docker://jumphost.inbound.vz.bos2.lab:8443/edge-infrastructure/recert:latest: reading manifest latest in jumphost.inbound.vz.bos2.lab:8443/edge-infrastructure/recert: unauthorized: access to the requested resource is not authorized\n: exit status 125"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/opt/app-root/src/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:329
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/opt/app-root/src/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/opt/app-root/src/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:227
``

we can use a different auth than the one used for pushing the seed, I don't have problems with that... but at least an authfile should be added to the podman pull command (if provided) otherwise it seems to fail for disconnected environments with above error


CC field is not displyed

**RainLoop version: <IP_ADDRESS>
**Browser: Firefox and Chrome
**OS: Mac OS
**Expected behavior:
The CC: field should be displayed below the TO: field
**Actual behavior:
The CC: field is not displayed below the TO: field.
This is true for list view and message view.
The only way for me to see the addresses in the CC field is to Reply All, at that point, they are populated properly.
Thank you.

Thank you for the quick reply, and for the screencast!
I understand your decision behind hiding that info under the i button, it makes the interface cleaner; but I think the CC field should be visible by default. The other fields can/should be hidden, but the CC field is elemental in email communication.
Is there a way to change this?
Thank you for your work, I'm a big fan of RainLoop.

Is there a way to change this?

Yes

Awesome, but how? :)

Wait for the next release

Thank you!

Please note that when you print the email, the CC field doen't not appear as well.
Everybody may be likely to have to provide evidence with the apparent recipients on a prited email.
Regards, Maxime


Move metasync.cb to common.cb

Refs: https://github.com/metarhia/MetaSync/issues/74

Landed in b7b5070


Cache Tool: initial commit.

CacheTool is a tool designed to work with the Traffic Server cache externally, in a manner similar to fdisk or fsck. This is very preliminary version but contains enough functionality to be useful in production environment.

squash please :)


CI export and test

Cache downloaded Godot executable
Download Godot export templates
Use Windows Godot console executable
Export test project GHA
GHA clearer cache names
GHA 10 minute timeout

Cache downloaded Godot executable
Download Godot export templates
Use Windows Godot console executable
Export test project GHA
GHA clearer cache names
GHA 10 minute timeout


Break title on colon

Replace colons in movie titles with ":".
(maybe dashes too?)
Check length of title - only replace if longer than X

Check length of title - only replace if longer than X

Specifically, check length of text before colon.
8 characters or less seems ok to leave.


image deletion plugin: do not expect amd file for deletion (on-premis)

The current version either uses S3 or checks for the existence of an amd file before actual image deletion. This has to be adapted to delete on local file system without checking for an amd file.

implemented by @rsehr and installed together with todays update


Optional dependency clutters installation log

We use this in our project, and it works very nicely - but when we run npm install, we get a very verbose error message due to a missing optional dependency - @wix/wnpm-ci:
npm ERR! registry error parsing json
npm WARN optional Skipping failed optional dependency /commons-validator-js/@wix/wnpm-ci:
npm WARN Unexpected token <
npm WARN <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
npm WARN
npm WARN <title>404 Not Found</title>
npm WARN
npm WARN
Not Found

npm WARN
The requested URL /nexus/content/groups/npmgroup/@wix/wnpm-ci was not found on this server.

npm WARN

npm WARN <address>Apache/2.2.15 (Red Hat) Server at nexus.intern.sparebank1.no Port 443</address>
npm WARN
npm WARN

I understand that this totally works for your organization - but it would be great if you could solve it some other way - so that the installation log would stay clean.

Fixed in https://github.com/wix/commons-validator-js/commit/eebee68bf0870a135a23adf78dad9bb4ae158d83.

Oops, just realized that the issue is about the optional dependency being unavailable.
I'm not aware of a way to silently ignore a missing optional dependency... suggestions?

Fixed in https://github.com/wix/commons-validator-js/commit/911b6fe0eb27c220fd66c5897b5a14d12258634b


unit weight in torque_drag

I am reading the code of torque_drag_example, and would like to understand what's the unit of  unit_weight.
In the BHA, the sample code:
 bha.add_section(
        od=(6.5 * ureg.inches).to('meters').m,
        id=(4 * ureg.inches).to('meters').m,
        length=(372 * ureg.ft).to('meters').m,
        unit_weight=(146.90 * ureg('lbs / ft').to('kg / meters')).m * 9.81,
        name='6 1/2" DC'
    )

and for Wellbore:
 wellbore.add_section(
        od=9+5/8, id=8.5,
        bottom=3688 * 0.7,
        unit_weight=(68 * ureg('lbs / ft').to('kg / meters')).m,
        coeff_friction_sliding=0.39,
        name='production 9 5/8" casing'
    )

so why BHA's unit_weight * 9.81 and not Wellbore?

Hi there @huangkai31! I'll take a closer look but I think you can ignore the unit_weight param for wellbore.
If I recall correctly, I've reused a class and probably forget to remove that param when I copied and pasted.

@huangkai31 I just tested and indeed that unit_weight param in wellbore.add_section can be commented out and it still works fine.
I've removed the line from the example code and it'll get pushed next time I push a new post. Thanks for the feedback!


Desktop App resizing issue

First of all, I have yet to replicate this with my overlay_test_app, because there it works fine, I assume some kind of incompatibility with another package.
I think the video should explain the issue quite well.
If you have an idea, or encountered the problem at a certain point, feel free to share, otherwise I just use this issue to track my reproduction progress :smile:.
Steps taken:

[x] removed responsive_framework dependency

https://user-images.githubusercontent.com/77293597/145116858-3eb85acc-2eb9-46b9-a965-2f9f9bc2b0d0.mp4
Edit:
The error message in the end is: (over and over again)
Invalid argument(s): 0.0
The relevant error-causing widget was
MaterialApp
lib/main.dart:122

it seems to me that this is caused by some clamping on the position of the label box.
I'll need some time to debug and figure out what is going on.
And also I wonder why your overlay is not full screen at some point.

And also I wonder why your overlay is not full screen at some point.
yeah, it is kind of a multiple step issue:

not full screen on resizing (minus)
error message on certain size (big)

clamping issue is reproducible and I'm going to make a fix tomorrow.
the other issue I can't reproduce.

Ok, I reproduced the issue and I feel stupid :expressionless:
I had set for every OnboardingStep the fullscreen to false.
Hope this will help someone else in the future.
On another note:
Can you explain (or show an image) what the Arrow intends to do (hasArrow).
(I will close the issue, once the new version fixes the other issue)

error message on certain size (big)

Hope those help.

It does indead.
I was mainly inquiring to find an easy fix to repositioning the text, as the desktop draws it quite to the start :sweat_smile:.

But then I found out that you use textAlign to handle this.
The issue then is, that (obviously :smile:) the text is not left aligned anymore:

There is no silver bullet here. I've never targeted this plugin for larger screens. You might want to calculate the desired width put it in a sizedbox and a row and all that placed in a stepBuilder. Also you can use the debugBoundaries flag to understand how much space is allocated for the label. On full screen it takes as much as possible, on fullscreen false it's kinda limited I'm still searching for the equation that will gibe the right size of the label box, as the overlay could be a different shape.

3.0.0-pre.13