Decide if we will ever return null from a function.

How do we feel about returning nulls?  It's gross, but I'm not totally convinced that optionals are actually less gross in java.  Optional has the benefit of documenting the fact that something may not be present where null can be a surprise.  The have the downside that it's wrapping the element in a new object which is potentially expensive for critical things.
I think we have 3 options:

Allow methods to return null.  This is error prone in some ways, but it's familiar, it's not very verbose, and null checks are very inexpensive.
Don't allow methods to return null, instead throw and have hasX methods alongside getX methods.  This has the advantage of avoiding NPE but is similarly error prone if people forget to check the hasX.  It could also be complicated to efficiently implement hasX if getX is something other than returning a field.
Use Optional as a return value instead of nulls.  This is nicer in a lot of ways, but it's a big change, the syntax in java is only marginally less verbose than null pointer checks, and it introduces additional boxing overhead for all calls to the method, which is likely much more expensive than null checks.  If java supported value types this would be much more appealing since the overhead could be avoided.

I prefer to never return nulls, so either 2 or 3 fits that criteria. But in my opinion, Optional is the best option at least for some cases:

For getters that can return missing values, such as variant attributes (FORMAT/INFO), it is kind of interesting to distiguish between them. Optional is great for it: a missing value is returned as the string representation (.) or special value (-1?), and completely undefined as an Optional.empty()
Methods returning a boxed primitive (e.g., int) that can be null can return an Optional instead, because there are implementations storing the primitive (e.g. OptionalInt) that would have teh same performance as boxing (e.g., Integer).

I suggest never return null, but have a mixed approach depending on the case: for example, the previous cases are better represented by returning an Optional, but cases where it would become a performance issue can use the hasX/getX implementation. On the other hand, there are values where missing can be represented in a different way (e.g., getContig() can return an empty string if there is no contig or the special * to represent it; better than a hasX method, it can be directly compared with == by forcing the static object to be returned without copying).
Does this mixed strategy works for you?

I'm nearly in agreement with @magicDGS, but not quite.  My view is that null is parallel to exception.  What I mean is that exceptions should be used for exceptional conditions and not expected results.  Similarly for null, I think if the value being accessed is optional and can reasonably be expected to be missing, then Optional is preferred to null.  But in cases where something really shouldn't be null in 99.99% of cases, but occasionally can in weird situations, I think it's preferable to return null since using Optional gives the wrong impression.

So from the comments here, what I imagine now as a safe design:

Avoid null in most of the cases.
Use a constant in case there is a defined value the SAM/VCF/whatever specs (but not magic numbers/values). E.g., missing reference can be * (emty String is also a possibility, as usually empty is not a valid name).
Optional for cases where we can expect that something is not present: attributes in VCF or SAM records
null when none of this cases fits

Some return methods can distinguish in the API between missing in the record and missing value defined (e.g., VCF . missing value). In that case, this could be defined as 3+2 (return optional; not present was missing in the record; present but with a special value is explicitly missing in the record) or 3+4 (return empty optional if explicitly missing; null in case of not present at all).
I found this Wiki page from guava quite good for this discussion too: https://github.com/google/guava/wiki/UsingAndAvoidingNullExplained

More info about null to impove discussion: https://www.yegor256.com/2014/05/13/why-null-is-bad.html

What's about Bean Validation for specifying this and other constraints?


Added rule for abstract modifiers in interfaces

This would actually go into the direction of #251 since abstract is a redundant modifier in interfaces.

Looks good, thank you! Fixed by 4c55b334406ae44544f9399a02f22a5ea062bd3a


Fix a crash on restore down

Summary of the Pull Request
Fixes a crash that occur when changing the buffer height. During the resize, conpty would immediately request a repaint, which would throw an exception that would cause the resize to fail halfway through, and that would make the subsequent render fail.
This change prevents the VT Renderer from immediately requesting a paint during the resize.

References
Might also be related to #1095. I can't seem to get that to repro anymore with this change.
Might be related to #1856. We should verify.
This does however make another issue more apparent. When you restore down with a COOKED_READ input line (read:cmd.exe), the terminal can crash. I have a fix for that in d34a3be, which I wasn't sure if I should include in this PR or not, because I wasn't confident that was the right fix. I'm fairly certain there's another issue floating around tracking that bug. We could either merge that commit/branch into this one, or wait and save it for a separate one.

PR Checklist

[x] Closes #1795

For your tentative COOKED_READ fix, that is sort of how the v1 console used to do it when resizing anything. It would hide the cooked line, do the work, then redraw it in the new position. So I'm not really opposed to that.
My thought would be... should it belong to SCREEN_INFORMATION::SetViewportSize instead, though, because I bet other folks resizing it probably also have the same problem if it's true here.

Is this something we should cherry-pick into 20H1?

@DHowett-MSFT Probably.
@miniksa Okay that makes sense. I'll make another PR for that one, since this one has a pretty specific scope, as does the other.

@DHowett-MSFT Oh you said 20H1, not Vb. Eh, feels too risky for 20H1.

I was wrong this should be in 20H1 (which is Vb). Our codenames are confusing.


fix: upgrade to version 3.2.79

from: https://github.com/jenkins-x/jx

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign macox
You can assign the PR to them by writing /assign @macox in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
cc0b0f4a9f6007d1f6266b05cefb653308a6bf84
link
/test gsm-kapp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest


RS-DSGE estimation: filtered, updated and smoothed variables

Hi Junior,
Regarding RS-DSGE model estimation, in particular the output that is stored in the structure "filtering" after estimation, is the terminology as in the Dynare output? I.e., is it correct that filtered_variables are one step ahead forecast (t+1) for the endogenous variables given information up to time t; updated_variables are the best guess for the endogenous variables at t given information up to time t; and smoothed_variables are best guess for the endogenous variables given all available information?
Regarding the “Expected” concepts of the "filtering" output, what is the relation between the smoothed_state_probabilities, updated_state_probabilities and filtered_state_probabilities and the Expected_smoothed, Expected_updated and Expected_filtered variables?
Many thanks!
Cheers,
Martin

Hi Martin,
Your intuition is exactly right:
1- filtered_variables refer to one-step ahead forecasts: a_{t|t-1}
2- updated_variables refer to the updates a_{t|t}
3- smoothed_variables refer to the final estimates conditional on all
available information a_t{t|n}
As for the expected counterparts, they are averages across all regimes.
This means that in a regime switching model, you will have for every
variable, as many series as the number of regimes. The weights used to
compute those averages are the probabilities.
Cheers,
J.
On Tue, May 15, 2018 at 8:17 PM, mhardinga<EMAIL_ADDRESS>wrote:

Hi Junior,
Regarding RS-DSGE model estimation, in particular the output that is
stored in the structure "filtering" after estimation, is the terminology as
in the Dynare output? I.e., is it correct that filtered_variables are one
step ahead forecast (t+1) for the endogenous variables given information up
to time t; updated_variables are the best guess for the endogenous
variables at t given information up to time t; and smoothed_variables are
best guess for the endogenous variables given all available information?
Regarding the “Expected” concepts of the "filtering" output, what is the
relation between the smoothed_state_probabilities,
updated_state_probabilities and filtered_state_probabilities and the
Expected_smoothed, Expected_updated and Expected_filtered variables?
Many thanks!
Cheers,
Martin
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jmaih/RISE_toolbox/issues/78, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACagz2LaOUjXE_2tu3tDCnbCTMHalPuwks5tyxuugaJpZM4UACJv
.

Correct!!!

mai 2018 kl. 21:03 skrev mhardinga<EMAIL_ADDRESS>
Thanks!
So in the expected counterparts, say the Expected_filtered_variables are the filtered variables in each regime weighted with the filtered_state_probabilities, correct?
Martin
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Pins re-factor for remote SPI support

This is turning out to be a pretty hefty PR, so I figured before I get too deep into it I should note down some of the goals of this to make sure everyone's happy with them. So, here's the goals:

At the moment our software SPI support (regardless of pin implementation) constructs pins and bit-bangs on them. This is all well and good for all the strictly local implementations, but it's no good for remote pins in pigpiod because the latency involved ruins the SPI bandwidth (to the point where stuff starts malfunctioning).
Now, pigpiod has built-in SPI bit-banging support so instead of constructing a bunch of PiGPIOPin instances, we should be constructing something that looks like SPISoftwareInterface (or SPIHardwareInterface) but which uses pigpiod's various SPI methods.
This makes SPI pin implementation specific which means it needs to become part of the pin implementation itself.
Something very similar to this is going to be required in the near future for I2C support (again, pigpiod supports this remotely).

Here's how I'm going about implementing this:

The pin implementations are already too complex (messing around with __new__) and I don't fancy adding yet more class methods. The sensible thing to do here is to make an actual Factory instance with methods for returning a pin, an SPI interface, and probably in future an I2C interface (maybe 1-wire too eventually).
This means that pin_factory will change from being a Pin sub-class to being an actual Factory instance.
I'll also be introducing an abstract base SPI class. SPISoftwareInterface and SPIHardwareInterface will descend from this, and instances of these will be returned by the factories associated with local pin implementations (i.e. everything except pigpiod).
Each pin implementation will wind up implementing at least two things: a Pin subclass and a Factory subclass, and optionally an SPI sub-class (as mentioned above, local pin factories will all use SPISoftwareInterface wrapping their respective pin subclasses, or SPIHardwareInterface).

Finally, this is what this means for end users:

Because pin_factory is constructed up-front on library import, this implies that initialization of the pin factory will happen at import time rather than at time of first pin construction. This doesn't sound too important but it actually has a big impact on non-pi users as it means the NativeFactory tries to initialize straight away (and usually fails because neither /dev/gpiomem nor /dev/mem is accessible).
This means on a PC you have to either setup the pigpio client properly or explicitly specify the mock factory to import gpiozero successfully; trying to import something that will only work on a Pi will fail at import time rather than the first time you try and use a pin.
Because pin_factory is no longer a pin class I've taken the liberty of renaming the possible keys that can be used with GPIOZERO_PIN_FACTORY. They're now just named after the respective libraries and are case-insensitive. This is backward incompatible, but we haven't formally documented this yet and the new system is much friendlier: GPIOZERO_PIN_FACTORY=rpigpio.
When a pin factory is not explicitly specified (via GPIOZERO_PIN_FACTORY) and the default ordering is attempted, any pin factories that fail (necessitating fallback) will fire a warning. This helps guard against people trying GPIO Zero in a virtualenv and forgetting to install RPi.GPIO.

Current state:
The basic coding work is done and works pretty well on a Pi. However, the vast majority of the test suite is quite broken because most references to MockPin (et al) need replacing with pin_factory (the test environment is configured by conftest prior to any attempt to import gpiozero to ensure it'll work on all platforms, sub-units will override pin_factory as required).
So, I anticipate this'll eventually be a mammoth patch, but the vast majority of it is going to be changes to the test suite (the actual coding work isn't that heavy - only really hits the pin implementations).

All sounds pretty reasonable to me :+1:

the vast majority of it is going to be changes to the test suite

Rather than having all the unit-tests explicitly constructing MockPins, would it "make sense" to just have them constructing numbered pins, and then altering the Makefile so that 'make test' runs GPIOZERO_PIN_FACTORY=mockpin ...  (that may well be a stupid question as I've not looked at the unit-tests for a while - and it might not 'fit' with Travis)
I guess if the allocating-of-pins to various interfaces (Pin/SPI/I2C) is being managed by Factory instances, maybe you could also have a method to tell the Factory to 'reserve' certain Pins? E.g. perhaps you have an addon board attached to some pins (managed by a different piece of software), and you want to tell GpioZero to never try allocating those pins. Not sure how that'd work with pigpiod and remote Pis though, so perhaps the 'reserved pins' should only be supported by strictly local pin implementations (rpigpio, rpio & nativepin) ?
While you're messing about with Pins, is it worth thinking about #385 at the same time too, or is that an orthogonal problem?

This means on a PC you have to either setup the pigpio client properly or explicitly specify the mock factory to import gpiozero successfully

Would this work?
import os
os.environ['GPIOZERO_PIN_FACTORY'] = "mockpin"
from gpiozero import *

Rather than having all the unit-tests explicitly constructing MockPins, would it "make sense" to just have them constructing numbered pins, and then altering the Makefile so that 'make test' runs GPIOZERO_PIN_FACTORY=mockpin ... (that may well be a stupid question as I've not looked at the unit-tests for a while - and it might not 'fit' with Travis)

That's more or less what I'm intending to do. Just to get the test suite going again (to make sure I haven't broken too much) I've just done a bulk replace of MockPin(n) with pin_factory.pin(n) for now, and after a few tweaks I got all the tests working again. Of course, I've just broken all the SPI tests now I'm shifting everything over to pin_factory.spi(**args).
Ultimately I'll try to replace as much as I can with just straight pin references as that'll be much cleaner.

I guess if the allocating-of-pins to various interfaces (Pin/SPI/I2C) is being managed by Factory instances, maybe you could also have a method to tell the Factory to 'reserve' certain Pins? E.g. perhaps you have an addon board attached to some pins (managed by a different piece of software), and you want to tell GpioZero to never try allocating those pins. Not sure how that'd work with pigpiod and remote Pis though, so perhaps the 'reserved pins' should only be supported by strictly local pin implementations (rpigpio, rpio & nativepin) ?

Good thought. I'm discovering having the factory instance makes the code much cleaner. No more messing around with __new__, just a simple instance method which checks an internal "pins" cache. The Factory.close method (another ordinary method) handles pin clean-up at shutdown time ... it's all looking much nicer. I'm hoping this might also fix the issues with SPI being able to reserve pins properly - haven't got to that bit just yet, but that's my goal.

While you're messing about with Pins, is it worth thinking about #385 at the same time too, or is that an orthogonal problem?

Actually I've got another private branch where I was working on fixing that. However, it's almost certainly broken with all these changes. I'm seriously considering merging it into here though, because my goal is to make this the last backwards incompatible change in pins (i.e. after this the goal is only to add to pins with stuff like I2C).

Would this work?
import os
os.environ['GPIOZERO_PIN_FACTORY'] = "mockpin"
from gpiozero import *

Yes, that will work - and I know because that's almost precisely what conftest.py now does :). However it's not "mockpin", but "mock". I dropped the pin suffix because firstly the factory isn't a pin instance anymore (so that'd be misleading), and secondly this means the factory label is now just the library name (like "rpio", "pigpio", "native", etc.)

All looks good to me. Thanks Dave!

No prob, given everyone sounds basically happy I'll press on. The SPI stuff's coming together right now (but the tests are all horribly broken). Might have something to push by tomorrow afternoon I think.

Incidentally because this changes the names of the package entry points, when you want to test the PR that's eventually pushed you must run python setup.py develop before doing so (otherwise the new entry-points won't be registered and everything will fail horribly).

my goal is to make this the last backwards incompatible change in pins

Does that mean this latest refactoring would still work when you add IO-expanders, etc. ? ;-)
I guess they'd just be another Factory object? (which I guess implies that not all Factories will be able to construct SPI or I2C interfaces)

Does that mean this latest refactoring would still work when you add IO-expanders, etc. ? ;-)

That's the plan.

I guess they'd just be another Factory object? (which I guess implies that not all Factories will be able to construct SPI or I2C interfaces)

Whether they form full blown factories that can be placed in pin_factory ... I'm not sure on that yet. The pin factory also contains the "pi_info" interface which really doesn't apply to expanders. Not wholly sure what to do about that yet so for now I've left it more or less as is (i.e. pi_info migrates to Factory, and that's about it). I might introduce a PiFactory sub-class (i.e. a factory specifically for pins on a Pi) which holds the pi_info interface. There's already a LocalFactory sub-class which more or less replaces LocalPin.
However, I have planned for the concept that some factories may not be capable of constructing certain interfaces. I've added some custom exceptions for these cases and they appear in the base Factory class. Factories are even permitted to be incapable of constructing pins (imagine a chip which purely provides multiplexed I2C interfaces, but no GPIOs).

imagine a chip which purely provides multiplexed I2C interfaces, but no GPIOs

Yup https://www.kickstarter.com/projects/land-boards/rpi-i2c-hub/description

And presumably there's a separate Factory for each remote Pi that a pigpio instance might be talking to?

And presumably there's a separate Factory for each remote Pi that a pigpio instance might be talking to?

Precisely. That's a bit different to how things are now (constructing pins individually if you want multiple hosts) but I think it's actually simpler: define the factories you need and then either construct pins from them directly or assign them as the current pin_factory while you construct devices.

Okay, this is about to land. I've finally got all the tests working, the docs are building nicely and everything seems good. Now, it's a pretty gigantic patch so I'll lay out the story of what changes are in here working from the bottom up, so people can find their way around it. Obviously I won't merge this until some review's been done! A little warning up front: there's a contentious change in here that Ben and I discussed at PyConUK; more on that later!
So, first let's quickly cover what doesn't change:

Basically everything in the device hierarchy. That's all almost exactly as it was. The only changes here were down in the Device constructor
The actual pin implementations themselves. All their prior stuff (function, state, pull, etc.) is more or less untouched; there's just a lot more machinery surrounding the pin implementations now

Now starting from the bottom let's work our way up:

The Pin base class is still there but now there's a PiPin descendent which represents pins attached directly to the Raspberry Pi. PiGPIOPin descends from this. LocalPiPin descends from PiPin and all other pin implementations (RPiGPIOPin, etc.) descend from this. As discussed, not much else worth mentioning here except the new "address" stuff; I'll get to that in a bit.
There's a new Factory abstract base class. Instances of Factory (or rather concrete descendants of it) have methods for constructing new GPIO pins (pin(spec)) and SPI interfaces (spi(**spi_args)).  Secondly it forms a nice expansion point that we can build I2C and possible 1-wire support upon in future without messing up backwards compatibility.
Instances of Factory are obviously what pin_factory now point to ... except pin_factory has moved a little. Instead of being a global in gpiozero.devices it's now a class attribute of the Device class. This gets rid of a global (yay!) but you may be wondering "Dave's messing with pin_factory again?!". Yes, sorry - there's a circular dep issue here in that devices depend on pin factories which implement SPI which (in the software bit-banging variant) requires devices to implement. Oh dear. Making the pin_factory a (initially blank) class attribute solves this as it's now essentially a forward declaration that we can fill in once the devices module has loaded.
There's a new Device._set_pin_factory method which can be used to handle replacing the active pin factory. Frankly, though, with the GPIOZERO_PIN_FACTORY env var (which uses this) I'm not really expecting anyone to use it directly; I've bunged a mention in the docs though. Oh, and I've added GPIOZERO_PIN_FACTORY to the docs.
As mentioned above: pin factory instantiation now means you can't accidentally use the native pin implementation on a PC; import gpiozero will immediately fail. Also, pin factory fallback fires warnings for each default pin factory that fails. This should help users who forget to install RPi.GPIO in virtual envs.
Pin reservation is now implemented properly (it used to be completely broken between SPI and GPIO devices). There's no more _PINS global (yay!) and no more re-entrant locking (double yay!). Instead, there's new Device._reserve_pins and Device._release_pins methods which are called by descendants during construction. The _reserve_pins method in turn uses a new _conflicts_with method which is called on the device being constructed with any device it shares a pin with, to test whether the two conflict. In GPIODevice this simply returns True (no two straight-forward GPIO devices can share a pin). But other descendants have more nuanced implementations, e.g. SPI devices can all share clock, MOSI, and MISO lines, just not select lines.
SPI changes significantly in this patch. The actual software implementation is more or less the same, in the core, but the gpiozero.spi module becomes gpiozero.pins.spi and a lot of the wrapper stuff moves into gpiozero.pins.local. The major change is that the pigpiod backend does something different to the rest in that we now rely on pigpiod's SPI support directly. This means remote SPI support works (and works really fast with the hardware implementation!).
The remote SPI bit-bang implementation has proven a little tricky to test because unfortunately it looks like the current Raspbian pigpio package is lagging behind the upstream GitHub: i.e. the SPI bit-banging methods are missing from the current Raspbian package. @bennuttall any chance we can get Serge to rebuild the packages from the latest source at some point in the near future? It's not terribly urgent: just means anyone using the pigpio backend won't have software SPI until that happens (but everything else, including hardware SPI, should work). I think @joan2937 must've added the SPI bit-banging stuff fairly recently because I can see bit-bang stuff for I2C and serial in the current Raspbian package; it's just SPI bit-bang which is missing but then I'm not sure which source the Raspbian packages were built from. Anyway, like I said, nothing terribly urgent.
There's one issue I still need to track down with remote SPI, but which I haven't had time to dig into seriously yet: I can get the client to wedge fairly easily by interrupting it. Not sure what's going on there yet (my immediately thought was some sort of race, but then I realized there were no background threads in the test ... hmmm). Anyway, if you don't interrupt it, it'll place nice, and it's not (yet) the default back-end so I'll track that down in another ticket later.

Right ... contentious change time! One thing I didn't mention above is that pin reservation turned out to be quite tricky. In order to do pin reservation you need some means of uniquely identifying each pin in the system. "Easy!" says Dave and charges in by using the identify of each Pin object. Except that comes with a problem:

User sets up an SPI device (GPIOs 8, 9, 10, and 11) by doing something like MCP3008(channel=1)
User erroneously attempts to set up an LED on GPIO11 with LED(11)
Down at the Device level, we construct a pin on 11, but it doesn't conflict with anything because the hardware SPI implementation hasn't constructed any Pin objects that conflict with it.

"Okay!" says Dave, "we need some other unique identifier for a pin that can exist independently of the Pin object itself". Cue long internal debate about what forms this could take (imagine much blackboard scribbling here):

Must support hierarchy of GPIO extenders.
So identifier must have arbitrary number of components.
What's a good delimiter for a hierarchy? Commas? Dots like objects? Slash like paths? Hmm.
How about URLs? Maybe.
Could "/" reasonably appear in a factory address? Potentially.
Idiot! Why bother with URLs at all: these aren't going to be (directly) user-accessible addresses, so why not make an address a tuple of strings and avoid the whole delimiter issue.

So, slightly weirdly, pins have an address attribute which returns a tuple of strings (tuples are used because the addresses need to be immutable for the reservation system's dict key). Factories likewise have an address from which their pin addresses are derived. Currently it's a pretty simple system:

All local factories (RPiGPIOFactory etc.) simply have the address ('localhost',)
So all pins constructed by local factories have addresses that look like ('localhost', 'GPIO11')
Remote factories (PiGPIOFactory) have an address like ('raspberrypi:8888',)
So pins constructed by remote factories have addresses that look like ('raspberrypi:8888', 'GPIO10')

In future, this will likely become more complex as we add GPIO extenders. Pin representations don't change as far as users are concerned; __repr__ just returns the last component of address.
Now the next issue reared its head... In several pin implementations, when we construct a pin, the only way to get it into a "known good" state is to set its function, and the function is often limited to input/output. Unfortunately, hardware SPI demands that its pins remain in "alternate function" mode in order to operate. Flip 'em to an input and things break. So, consider the scenario again:

User sets up an SPI device (GPIOs 8, 9, 10, and 11) by doing something like MCP3008(channel=1). This reserves the pin addresses for GPIOs 8, 9, 10, and 11 against the SPI device.
User erroneously attempts to set up an LED on GPIO11 with LED(11).
Down at the Device level, we construct a pin on 11 to get its address ... and break the hardware SPI implementation.

Oh dear. So, whilst Pin.address is an attribute that exists for querying once a pin is constructed (in case you're passing in a straight Pin object rather than a pin specification), there's also a Factory.pin_address method which is used by the reservation system to query what address a pin would have if we were to go ahead and construct it. This is kinda horrid but I haven't come up with a better way yet. Now, because what Factory.pin_address is effectively doing is translating from a pin specification (a GPIO number) to a pin address I thought I'd throw in the following contentious change because, if we do this, this is exactly where it should go.
No, you know what: this is already way too long. Let's leave discussion of the stuff above for this ticket because I hope that despite some odd bits, it's all relatively uncontentious (albeit long). I'll open another ticket for the contentious change where we can chin-wag about it separately.


File names with apostrophes cannot be deleted in the manager

In list-view.blade.php and grid-view.blade.php the trash function does not account for apostrophes ', for example Jon's file.jpg.
Code that produces the error in list-view.blade.php
    name }}')">

On click the error produced is This is because the apostrophe :
Uncaught SyntaxError: missing ) after argument list
Doing this works:
    name.'"' }})">

Version 1.8

@streamtw you can close this issue.


Question regarding lifecycle

Hi! Nice extension.
I was experimenting with it and found that when using m3u8 network playback stream, the handleLifecycle=true paused playback properly when leaving the app, but never resumed it when coming back, resulting in back screen.
Not sure if it is a bug or a problem on my end. Perhaps it makes sense to be able to optionally create the exoplayer instance outside the library, for having more control over the instance? I'd assume then I would be able to use it to control playback with some custom logic.

Hello @Blefish! Thanks for your question. This library provide get exoplayer instance via 'playerInstance' property.
I think this is a library bug, please give your code included reproduce this issue? Thank you!

I have the same issue. After returning to the app the video is blank.
VideoPlayer(
    mediaItems = listOf(VideoPlayerMediaItem.NetworkMediaItem(videoUrl)),
    modifier = Modifier
        .aspectRatio(aspect)
        .align(Alignment.Center)
        .clickable { onClick() },
    controllerConfig = VideoPlayerControllerConfig.Default.copy(
        showSubtitleButton = false,
        showCurrentTimeAndTotalTime = false,
        showBufferingProgress = true,
        showBackTrackButton = false,
        showNextTrackButton = false,
        controllerShowTimeMilliSeconds = 0,
        controllerAutoShow = false,
        showFullScreenButton = false,
    ),
    usePlayerController = false,
    enablePip = false,
    enablePipWhenBackPressed = false,
    volume = if (videoState == VideoState.Muted) 0f else 1f,
    repeatMode = RepeatMode.ALL,
    handleLifecycle = true,
    autoPlay = true,
)

@Blefish @dsa28s
I've managed to workaround the issue by removing the view from the composition when onPause is called and adding it back in when onResume is called.
Here is the code:
var shown by remember {
    mutableStateOf(false)
}
DisposableEffectWithLifeCycle(
    onResume = { shown = true },
    onPause = { shown = false }
)

if (shown) {
    VideoPlayer(
        mediaItems = listOf(VideoPlayerMediaItem.NetworkMediaItem(videoUrl)),
        modifier = Modifier
            .aspectRatio(aspect)
            .align(Alignment.Center)
            .clickable { onClick() },
        controllerConfig = VideoPlayerControllerConfig.Default.copy(
            showSubtitleButton = false,
            showCurrentTimeAndTotalTime = false,
            showBufferingProgress = true,
            showBackTrackButton = false,
            showNextTrackButton = false,
            controllerShowTimeMilliSeconds = 0,
            controllerAutoShow = false,
            showFullScreenButton = false,
        ),
        usePlayerController = false,
        enablePip = false,
        enablePipWhenBackPressed = false,
        volume = if (videoState == VideoState.Muted) 0f else 1f,
        repeatMode = RepeatMode.ALL,
        handleLifecycle = true,
        autoPlay = true,
    )
} else {
    Box(modifier = Modifier.fillMaxSize())
}


Functionality for saving email credentials

Pushed functionality, encrypting passwords is remaining will be available in nosy 2.4

Won't be fixed


Error: Please set API_KEY environment variable.

Hi! Amazing project!!
When I try to run steam_miner.py, it returned the error Please set API_KEY environment variable.
How could I solve this problem
os: Window10 64bits
envi: Anaconda python 2.7

I try to add one line: os.environ['API_KEY'] = 'MyKey' to solve it then I meet an new error KeyError: 'matches'

I have solved it! Thanks~

What was the problem? Glad you figured it out!

At the begining there is the API KEY problem so I add my SteamAPI Key. Problem done!
The Key:Error related to json format  because I confused by 2 different SteamWeb API.


Issue with _posts not reflected on site

Hi, I'm having issues with posts showing up in blog.
This is in /_posts directory.
According to https://jekyllrb.com/docs/front-matter/  blog post URLs must be in the /year/month/day/title format and this is also stated in the github repo itself https://github.com/barryclark/jekyll-now#step-3-publish-your-first-blog-post . Not exactly sure why this format is needed but nonetheless I followed this.
I pushed my changes of adding more posts, and the changes are not being reflected on my site.

I have tried pushing through git like normal
Adding a posts under _posts through github UI.

Not having any luck. Not sure what the issue is, has anyone run into this issue?
Thank you

Update it ended up taking some time, but changes are reflected now


Update esi sdk

Related issue: https://github.com/CCI-MOC/esi/issues/536

Looks good! Can you update the description of the PR to be a bit more specific about the contents - e.g., "updates to object attributes, addition of functional tests"?

Looks good! Can you update the description of the PR to be a bit more specific about the contents - e.g., "updates to object attributes, addition of functional tests"?

Done! I'm now working on python-esileapclient PR. I might update this PR slightly (attribute naming, etc.) to sync with python-esileapclient if necessary. I 'll let you know when this one is in final stage to review.

Okay, sounds good!

I've updated the README.md, let me know what you think!

Thanks for adding the README! The code works well; there's just a few minor inaccuracies in the documentation that I've noted.
Could you also add a connect method, similar to https://github.com/openstack/openstacksdk/blob/master/openstack/init.py? What this allows one to do is have code like:
import openstack

conn = openstack.connect()
nodes = conn.baremetal.nodes(details=True)

And the openstacksdk will simply pull from your current environment.

Done!

This looks great - thanks!


MySQL: failure is reported as success

The following code:
new MySQLContainer<>()
            .withUsername("root")

fails with  STDERR: ERROR 1396 (HY000) at line 1: Operation CREATE USER failed for 'root'@'%' but then:
18:38:14.158 INFO  🐳 [mysql:5.7.22] - Container is started (JDBC URL: jdbc:mysql://localhost:32775/test)
18:38:14.159 INFO  🐳 [mysql:5.7.22] - Container mysql:5.7.22 started

it may be caused by #1434, need investigation

I think there's a logical explanation. We have:
    private String databaseName = "test";
    private String username = "test";
    private String password = "test";
    private static final String MYSQL_ROOT_USER = "root";

and by setting username to root the following code path is run in configure():
        addExposedPort(MYSQL_PORT);
        addEnv("MYSQL_DATABASE", databaseName);
        addEnv("MYSQL_USER", username);
        if (password != null && !password.isEmpty()) {
            addEnv("MYSQL_PASSWORD", password);
            addEnv("MYSQL_ROOT_PASSWORD", password);
        } else if ...

        setStartupAttempts(3);

So MYSQL_USER will be root, MYSQL_PASSWORD will be test but also MYSQL_ROOT_PASSWORD will be test.
It looks like MySQL's bootstrap script tries to (re)create the root user account because MYSQL_USER is set. It fails with that error, but because there are three startup attempts configured it tries again. The bootstrap script only runs the first time the container is launched, so the 2nd start works.
Then, when Testcontainers attempts to obtain a JDBC connection it uses the configured username root with password test, which happens to be valid because MYSQL_ROOT_PASSWORD is set.
I think perhaps the right thing to do would be not set MYSQL_USER if it is set to root, therefore preventing the accidental account recreation attempt.
We should probably think about removing the default 3 startup attempts now - I'm not sure if that is genuinely needed any more now that our pulls and JDBC testing is more stable...


Emacs keybindings option

I have had users express interest in this. Maybe even fully customizable key bindings?

Not sure there is enough interest here to be worth it. Closing


feat: re-structuring of register-oracle cmd

Close #7
Some refactoring has been done including graceful shutdown and operation for each situation.
First, check if there is an existing node key.
If exists, continue the oracle registration process with the existing node key.
Or create a new one and request oracle registration to Panacea (done in #11).
When the node key exists, some checks would be done as below.

check if the existing node public key is equal to the one used in OracleRegistration in Panacea
check the status of OracleRegistration (handling for each situation: VotingPeriod, Passed, Rejected)

Please add a another reviewers :)

I would close this PR since we decided to make this register-oracle cmd simple.
This command will only execute generating node key and submitting transaction for registration of oracle to Panacea.


Error: Cycle issue with the version v16.0.0

Description
With the release of v16.0.0, we have exprienced the following issue with terraform apply:
Error: Cycle: module.my-eks-cluster.aws_iam_instance_profile.workers[0], module.my-eks-cluster.aws_launch_configuration.workers[0], module.my-eks-cluster.random_pet.workers[0] (destroy), module.my-eks-cluster.aws_launch_configuration.workers[0] (destroy deposed 53a4ae45), module.my-eks-cluster.null_resource.wait_for_cluster[0] (destroy), module.my-eks-cluster.aws_autoscaling_group.workers[0]
⚠ Note
And we have alredy done the following before submiting the issue.

Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
Re-initialize the project root to pull down modules: terraform init
Re-attempt your terraform plan or apply and check if the issue still persists

Versions
v16.0.0

Terraform:
0.13.7
Provider(s):
aws        =  v3.40.0
local      = v2.1.0
random = v3.1.0

This actually start to happen with the v16.0.0 release.

can you paste whole plan as seems there is some replacement on workers

Hello @daroga0002,
Thanks for your fast reply please find below the plan attached.
Cheers
plan.txt

reason of change is:
  # module.xxx-yyy-eks-test.aws_launch_configuration.workers[0] must be replaced
  ..........
     ~ image_id                         = "ami-00a182929447c6963" -> "ami-07edd1ff4d841185c" # forces replacement
  ..........

does you passing manually a AMI for workers or fetching dynamically from somewhere?

That actually comes from the terraform-aws-eks module it self precisely from here:
https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/workers.tf
and this part in the code:
`
image_id = lookup(
        var.worker_groups[count.index],

        "ami_id",

        lookup(var.worker_groups[count.index], "platform", local.workers_group_defaults["platform"]) == "windows" ? local.default_ami_id_windows : local.default_ami_id_linux,

      )`

So it's an expected behaviour.

In v16.0.0 we droped random_pets for LC/LT and local-exec for waiting for cluster. Those destroy are probably causing cycle. Can you please backup your state and then remove random_pets and null_resource and retry an apply ?
terraform state rm module.my-eks-cluster.random_pet.workers
terraform state rm cluster.null_resource.wait_for_cluster

@barryib that works fine thanks, is there a way to avoid this before actulally going to the v16.1.0 version? any adaptions we should carry on while on version v15.2.0 to avoid having to modify the state manually? Just our of curiosity !

@barryib that works fine thanks, is there a way to avoid this before actulally going to the v16.1.0 version? any adaptions we should carry on while on version v15.2.0 to avoid having to modify the state manually? Just our of curiosity !

I think the good answer here is just to observe BREAKING CHANGES mark in changelog before upgrade

got it @daroga0002 thank you all for the great help will the issue.


support network filter extension

starter check network filter should have only one needs to be removed
add network filter registry

Fixed by #161


CoVE-IO FID namespace

The CoVE-IO specification extends the CoVE ABI for supporting device direct assignment into TVMs.
The CoVE-IO ABI extensions require their own SBI FIDs and are currently left TBD in the spec. I propose that we assign a specific FID range for CoVE-IO, so that the CoVE and CoVE-IO FIDs can be formally defined without overlapping or interleaving.
Since FIDs can fill an entire register (a6), one possibility would be to reserve the top half COVG and COVH EID spaces for CoVE extensions. CoVE-IO could e.g take 6 bits from there and use them as needed.
@rsahita @jyao1 WDYT?

Yes, I like this proposal to separate role and responsibility.

sounds good - we should also make sure there are some reserved portions for other future extensions.

sounds good - we should also make sure there are some reserved portions for other future extensions.

Yep.
I'll send a PR for this.


Use OAuth instead of collecting user passwords directly

There is a MAJOR difference between asking to authenticate Twitch account and asking to enter password directly outside of trusted browser.
This raises serious security concerns. Please adopt similar techniques as Chatty and other local apps that uses OAuth authorization flow to do this operation securely.
Also this opens all kinds of opportunities for people to make fake apps to steal user authentication data caused by this decision and can be devastating for the community.

TL uses the official OAtuh authentication workflow in order to retrieve an user access token (on application startup) as pointed out HERE. The token gets used to communicate with the API.
There is no user access token without entering the username and password. There are app access tokens as described HERE. But these tokens would make all TL users share the same 800 API call limit per minute. And as stated in the documentation, it is not meant for client applications like TL:

As mentioned earlier, app access tokens are only for server-to-server API requests

If you are talking about the sub-only login where basically the login form of the Tiwtch website gets shown, that is different. But again, it is the official login form of the  Twitch.tv website. If you think that is unsafe, go ahead and tell Twitch, not me.
TL uses an integrated Chromium browser engine, which is the exact same browser engine as Goggle Chrome uses with the exact same security and sandbox features. So I gon't get where your security concerns originate from. Sounds like a lot of made up paranoia, and/or you do not understand what you are actually talking about.

Also this opens all kinds of opportunities for people to make fake apps to steal user authentication data caused by this decision and can be devastating for the community.

 Because TL now has a login form it is somehow prone to be faked? Dude...
To sum this up... you make a lot of claims but not a single on is actually backed up by any sort of proof or reason why you make that exact claim. And the claim that TL does not use OAuth tokens is simply wrong from the getgo.
TL is not unsecure or does fishy stuff. It only uses official endpoints documented by Twitch in order to retreive OAuth tokens. Login forms are displayed in an official build of the Chromium engine and sandboxed exactly like a "real" browser would be. So I give you one more chance to explain yourself and the paranoia.

@Franiac
You probably misunderstood me. I'm sure this app uses Twitch API to get OAuth tokens. The problem is how it receives the token.
The whole point of OAuth authorization flow is to keep user authentication data (i.e. passwords and OTP codes) completely separate from third parties while enabling them to use serviced requiring authentication.

OAuth (Open Authorization) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

(from wiki)
I'm not accusing TL of doing fishy stuff, I'm talking about violation the principal security approach of OAuth. Integrated Chromium is not a secure browser because it is under complete control of third party app maker. You can break into any sandboxes and inject arbitrary code to any pages rendered in webview. Therefore this approach requires a complete trust between app maker and user. And this is fundamentally wrong. We've seen many examples when legitimate apps and browser extensions were hijacked / sold to fishy companies. Users should never trust their passwords to third parties period.
Login form that looks like a Twitch logging form (and probably is in your TL case) IS prone to be faked. An app looking exactly like TL can be easily made to steal user authentication data, and previously that were impossible.
I'm urging you to at lease keep this discussion open so others can chime in. Being concerned about entering passwords to third party apps is not paranoia.

On an unrelated note: currently yt-dlp/yt-dlp is able to download any videos from twitch without user login (I assume they parse pages and user GraphQL directly with anonymous sessions). Are the reasons that can't be done in TL purely legal?

I did not misunderstand you.

OAuth (Open Authorization) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

This is ONE usecase. But Twitch does not use OAuth this way for the Helix API (as in password-less tokens). You are confusing OAuth and login credentials. OAuth is a workflow. It does not define what data is used for authentication. The Twitch Helix API NEEDS a user token received by entering username and password. TL uses the documented workflow of Twitch. The Twich website uses password-less tokens if you are not logged in, but at the same time such a token cannot access the Helix API.
READ THIS
This is how Twitch wants you to do it, and that is exactly what TL does. You cannot access the Helix API without logging in as an user in a client application.

Therefore this approach requires complete trust between app maker and user. And this is fundamentally wrong.

This is absolute nonsens. How do you think Steam works for example? Steam is an application with an integrated browser where you have to login. Do you trust Valve? Spotify is an application with an integrated browser. Do you trust Spotify? TL is an application with an integraten browser. Do you trust me?
The funny thing is, Steam and Spotify are even closed source, TL is open source. You can actually check, what happens. So my claim is, it is even more secure than Steam and Spotify because you can actually check, what happens with your username and password.

Login form that looks like a Twitch login form (and probably is in your TL case) IS prone to be faked. An app looking exactly like TL can be easily made to steal user authentication data, and previously that was impossible.

There are so many things wrong in this statement that I don't even want to try correcting it all. I can implement a fake app that looks exactly like Spotify... and now what? Every application can be faked.... so? How is that a problem only for TL just because now it has a login form?

I'm urging you to at least keep this discussion open so others can chime in. Being concerned about entering passwords to third-party apps is not paranoia.

Definitely not, because the amount of wrong information in your posts is way too high. You have not yet understood how Twitch wants you to access the Helix API even with the documentation provided, so please refrain from providing any more "tips" on how do do it correctly. The API is not the website and the OAuth workflow used for the website is different to the OAuth workflow of the API. You are mixing up so many things.

I assume they parse pages and use GraphQL directly with anonymous sessions

So in your world, parsing the website source and using the private GraphQL API is better than following the official Twitch documentation on how to access their public API? Big oof.
Funny point: TL is one of the few apps that actually use the API the intended way. GQL should not be used, it is not public.
And that's definitely the end of this discussion. Please refrain from opening up another issue on this matter.

Just in case this gets more attention than necessary I want to quickly address two important things, just without the paranoia part.
You should not input your username and password in third-party software when it's not open source and the flow where your credentials go cannot be tracked. TL is open source and the room for malicious behavior is minimal due to the fact that everyone can see the source code. In TL the username and password are input in the login form displayed by the in-app browser. Yes, I as a developer COULD break into the browser sandbox and collect your secret data. Fact is, I don't. And that again is backed up by the source code of TL. So your username and password of your Tiwtch account NEVER leave the browser sandbox and do not even flow through the TL source code at all. The only time your credentials get processed is on the Twitch server, resulting in the API authentication token. If I changed this behaviour, people would burn this repository down to the ground faster than I could delete it 😄
What the OP expects is that TL opens up the system default browser in order to input your credentials there. This way the user can be absolutely sure, that his credentials do not touch the third-party source code and get collected for malicious activity. Like I stated, correct for closed-source software but not TL that hundereds of developers have eyes on.
The claim that the pages and therefor the login forms shown by TL can be faked is quite weird. Many game launchers (World of Tanks, Steam, Ubisoft Connect, GOG Galaxy,...) are desktop applications with integrated browsers (usually the Chromium engine). So they work exactly the same way as TL does, also providing login forms. If someone can fake something in TL, they can fake the login dialog of World of Tanks or Steam since the browser technology is the same. The argument is, it is easier to fake something in an in-app browser than an actual browser. This is correct due to the fact that the in-app browser can also be accessed by the source code of the app. If it was actually an issue, none of the desktop applications like Steam or Spotify could be trusted.
And in general, applications can be faked. TL can be faked, true. But this is an odd argument. I can fake Spotify and upload it. If you download my fake Spotify app and use it, Spotify cannot do anything about it. So that's not an TL issue.
So basically the OP is not wrong, but also not right. The username/password issue the OP has is entirely negated by the open-source characteristic of TL. As long as you download TL from this repository, you are in a very safe place. Even if you don't trust me, trust the source code... that never lies.


community: Add missing async similarity_distance_threshold handling in RedisVectorStoreRetriever

Add missing async similarity_distance_threshold handling in RedisVectorStoreRetriever

Description: added method _aget_relevant_documents to  RedisVectorStoreRetriever that overrides parent method to add support of similarity_distance_threshold in async mode (as for sync mode)
Issue: #16099
Dependencies: N/A
Twitter handle: N/A

fixed linting error in 985a75d

@baskaryan @Spartee @tylerhutcherson
Hi, do you have any news regarding this PR ?
It would allow me to simplify my code greatly when using LangChain in my custom async APIs

sorry for delay, thank you @HugoMichard!

Apologies for the delay, glad this made it in!


Adaptive Sampling on Functions with Multiple Output

Can you use this package only for adaptive sampling purposes (away from optimization) where I just want to fit the surface correctly with smallest number of points possible? Also, how can I use the package when my function has multiple outputs?

Also, how can I use the package when my function has multiple outputs?
You can't. The package is target towards optimization of single output black box functions.

Can you use this package only for adaptive sampling purposes (away from optimization) where I just want to fit the surface correctly with smallest number of points possible?
I'm not sure exactly what you mean, but it sounds like this package will not help you much.


not in my case

Some other reason?
I have permission in the manifest but it does not solve the problem.
After installing on the phone permissions are visible in the application details - but it does not connect to the internet ...

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

ID: 2d84ae95-09e8-e59e-88d7-eb8dd493cdef
Version Independent ID: 39431014-6797-8371-57d6-03c86127062c
Content: Why can't my Android release build connect to the Internet? - Xamarin
Content Source: docs/android/troubleshooting/questions/android-internet.md
Service: unspecified
GitHub Login: @mgmclemore
Microsoft Alias: mamcle

Hi @ms666, thanks for your feedback!  We'll see if we can reproduce your observations on our end and update the workaround instructions accordingly.

I found the culprit. HTTPS and ignoring certificates.
Works in DEBUG mode and RELASE does not ...

Hi @ms666, thanks for the update!  Are you using a self-signed certificate?  If so, perhaps this forum discussion may be useful to you.

Try changing the SSL/TLS implementation in the Android Options in the project properties. You hit the Advanced button on the bottom to get to it.


Prerelease V2.0.0

The DataWedge plugin now supports an event stream which emits event objects containing the result of operations (like enabling the scanner, creating a profile). To properly map the emitted events to the running application, command identifiers can be provided.
async/await for functions was improved. Before the native method never returned.

You could run format once for all files. There are a few places that could use additional whitespace


Refactor model related code into its own directory

One of the nice things about having zero requires in any file is that moves like these are super trivial

Codecov Report

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

@@           Coverage Diff           @@
##           master       #8   +/-   ##
=======================================
  Coverage   98.57%   98.57%
=======================================
  Files           5        5
  Lines          70       70
=======================================
  Hits           69       69
  Misses          1        1

Continue to review full report at Codecov.

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


Miniquest "Architectual Alliance", Step location wrong (shayzien)

the step:
"talk to shayda north of the shayzien bank" is wrong, Its placed in the shayzien encampment, while the npc that you need to talk to is in the area BELOW the campment.
Here are screenshots of where it says compared to where she is,
https://cdn.discordapp.com/attachments/772056861934354433/855372392818016276/unknown.png
https://cdn.discordapp.com/attachments/772056861934354433/855372509104701490/unknown.png

Thanks, should be fixed with https://github.com/Zoinkwiz/quest-helper/commit/09f428cfcd4c787b203a951fc2bf6bdd11e23dc4#diff-be04cff44ec14f8f6df96a6bc75481e31bf2a60e916915b1ebb1e3972e04c455


Version 0.5

Steps

[x] Seat block, anything detached from it is destroyed
[ ] Prevent glitches that allow for blocks outside of build area
[x] limit which blocks can be used in which levels
[x] Limit contraption loading, so that it only works if enough build space and parts are available

Will remove contraption loading in the final game outside of sandbox


What is the project state ?

Hi @p4tin
My client uses your container since years now, what is the state of this project ?
Can you release the latest changes ?

We're wondering this as well. We're happy to take over maintainership if the current maintainer no longer has the time.

I am looking into passing the torch - thank you all for using goaws!!

I am looking into passing the torch - thank you all for using goaws!!

You can transfer it to @code-lts where you will/can keep rights and other people can contribute to it

We've transitioned the ownership to me now.  So I'm ramping up on outstanding issues, and the general state of the union.  Let me know if you have any outstanding issues or questions.  Thanks!

We've transitioned the ownership to me now. So I'm ramping up on outstanding issues, and the general state of the union. Let me know if you have any outstanding issues or questions. Thanks!

Do you also have access to the Docker image?
or get it deleted and create a new one

@Admiral-Piett thank you so much for taking this over, and @pfortin-urbn thank you for your response and passing the torch!

@williamdes yep, for now the new images are located below.  Anything pre-v0.3.2 is still at pafortin/goaws.  I'm looking into copying the old versions onto this registry, but one of many things on my todo list atm.

docker pull admiralpiett/goaws
docker pull admiralpiett/goaws:v0.4.1.  # republished just now
docker pull admiralpiett/goaws:latest

I honestly think it's best to continue uploading to the original image or to take down all images of the original image and host yours as said above.
I am interested in contributing a multi arch build when you tell me that the builds are golang up to date and working


Ensure that metadata is not blocked by over-restrictive rules on outb…

…ound traffic.
Fixes issue #212.

This was a simple enough fix that I decided to make it. Since my test box has no functional metadata, I haven't been able to test the function, but it creates the rule OK, and the tests cover it, so close enough for review.

LGTM.


Installation issue: errors while making rabit (on Windows)

As I understood from some installation guides, latest versions of xgboost  require rabit "made".
I tried  mingw32-make with the following results:
console output.txt,
as well as MVSC 2013 with these errors

What should I do to resolve it?

No thoughts on VS errors.
But for MINGW error, it is actually due to some recent updates in mingw-w64.
There is no ssize_t type in previous version of mingw-w64, but now it has, so there will be some conflicts.
You can just try to comment out this line https://github.com/dmlc/rabit/blob/master/src/socket.h#L31
It should be changed into something like:
#ifndef _SSIZE_T_DEFINED
#define _SSIZE_T_DEFINED
typedef int ssize_t;
#endif

@thirdwing can you open a PR to rabit to resolve this issue? Also if the instruction is followed and the mingw64.mk is copied to root folder as config.mk The rabit build should result in a dummy build that skips this step

@thirdwing Thank you, this step helped to resolve first of the errors:
the second one is regarding net_ntop
src/././socket.h:76:52: error: 'inet_ntop' was not declared in this scope&buf[0], buf.length());
the third one relates to sleep
src/allreduce_base.cc:206:16: error: 'sleep' was not declared in this scope sleep(1);
At the same time, newer mingw-w64 won't install due to Cannot download repository.txt [0]
@tqchen I'm glad to see you are involved. I've tried some manipulations with mingw64.mk and config.mk, but it had no results. Could you please clarify, how should I proceed.
Instead of mingw, I also tried cygwin, but unfortunately the result was exactly the same.

Please wait for a minute. I am updating the building instructions on Windows.

@FACE1E55 I think you are using an old GCC, maybe 4.7 or even older.
If you can't upgrade it, try to add #include <unistd.h>.
This might help, but I am not sure.

@thirdwing I am using an old version of GCC for sure.
I'm afraid, #include <unistd.h> is already there.
Now I think it's no use continuing this with an old compiler on windows


Whitelist is compared to uppercase SQL query

Hello, first off thank you so much for this project - it's super useful! I noticed an issue with the way the whitelist is working. I have a table with a modified timestamp field named updated. If I add updated to the EXPLORER_SQL_WHITELIST param within settings the query refuses to run and says it does not pass the blacklisting check.
In utils.py#L26 the SQL query to run is transformed into all uppercase but the whitelist words are matched as they appear within the tuple. If I amend my tuple to have ('UPDATED', ...) then the query passes and runs fine.
I am not sure what the best general fix for you would be - a simple one would be uppercasing the whitelist before the compare is done within utils.py but perhaps there is a reason for it matching exact case in this instance?

Thanks! That was just a regular ol' bug. Just fixed.


Allow to switch out of Bing layer even if Bing API broken

Right now, bing somehow broken and initMetadata() call newer executed.
This cause error when end user tries to change the layer in onRemove()
Cannot read property length of underfined when iterating over this._providers.length

Don't really understand how i can reproduce the bug, but you may remove this line in your patch :  https://github.com/kmmbvnr/leaflet-plugins/blob/patch-1/layer/tile/Bing.js#L68

To reproduce the bug i think you can just put <IP_ADDRESS> to /etc/hosts for bing server, to emulate bing servers down and see that it prevents to switch to another one layer.
Anyway, introducing new class variables in 3d level callback and then referring to it in other places is a bad programming style.
this._providers should be initialized as soon as possible.

Anyway, introducing new class variables in 3d level callback and then referring to it in other places is a bad programming style.

Feel free to provide awesome patch to make it better :)


Showing icons on jam in games feed

User = one author
Users = not one author

Resolves #1480

Awesome! I wasn't 100% sure it was going to work, but yeah it actually looks really good!


Linked Videos are Screenshots only

Hi team,
all linked videos are screenshots only, can you pls check and link the videos?
Best,
Thomas

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

ID: a03180ce-ce5e-a242-534e-a6d2a71fddc3
Version Independent ID: 009bf11f-5419-1da4-36eb-89f16bf82ca2
Content: Fault domain awareness
Content Source: WindowsServerDocs/failover-clustering/fault-domains.md
Product: windows-server
Technology: failover-clustering
GitHub Login: @cosmosdarwin
Microsoft Alias: cosdar

#assign:xelu86

Hey @thomas-kringel,
A documentation change has been made updating the links to these videos and will be live after the next business day. We will now be closing this thread. Thank you and have a most pleasant day.
#please-close


Ensure filter compliance with ISO

What has to be done
Filter housings, in particular patient tubing connectors must be modified to comply with ISO standard.
How do you know it has to be done
It was claimed in our documentation that we had this requirement satisfied, but after migrating to AutoDesk, it is not clear
that this is still true.
The claim used to be as follows:
The patient breathing circuit connector cone is dimensioned according to ISO 5356-1.
This has been removed from the filter housings readme until this ticket is addressed separately.
How do we know it is done?
Once we satisfy this standard once again, it might still be brittle: i.e. at any other point in time, someone might modify the
design and break this feature without anyone automatically realizing this has happened. Several suggestions to prevent this:

tag all relevant constraints with something like an ISO_ prefix
add comments to all relevant constraints explaining which aspect of the standard it addresses
make drawings that explicitly highlight those features or constraints that are pertinent
create a checklist, probably somewhere in the relevant README, that encourages (could use stronger language?) contributors to take certain steps, such as generating relevant drawings and comparing them to the previous version, to confirm that said features are still intact

Don't forget

[x] Put the issue in a milestone
[x] Assign it to one of the projects
[x] Add appropriate labels
[x] Mention dependent/blocked issues if any

This came up in #918

This could be tackled together with #1051


Customizing SDK style builds

I have a question regarding customizing SDK style projects. In old-style projects, I could redefine any standard Target that I wanted, by placing my own definition after the Import for "Microsoft.CSharp.targets". However, with the new SDK style projects the SDK.targets is implicitly added to the very end of my project file, so there is no "after" for me to include my redefinitions. Is there a way to do this with SDK style projects, or is this simply no longer an option?

Okay, I think I figured it out. It seems that all that Sdk="Microsoft.NET.Sdk" is doing for me is adding those Imports, so I can just replace that with an explicit import instead:

... my project stuff ...

... override targets here ...

I only realized this after I saw that the Import element now has an "Sdk" attribute (thanks Intellisense).
Is this really all the Sdk attribute on Project is doing?

Is this really all the Sdk attribute on Project is doing?

Yes, that's all that attribute does - automatically adding the Imports at the top and bottom of the project.  See https://github.com/Microsoft/msbuild/issues/1493 and https://github.com/Microsoft/msbuild/issues/1392.

@dsplaisted - unfortunately, Directory.Build.targets doesn't work as great as Directory.Build.props.  The props file does get imported rather early, so you can set a bunch of things before the SDK's props file.
However, the Directory.Build.targets file gets imported towards the end of Microsoft.Common.targets:
https://github.com/Microsoft/msbuild/blob/cb6c2643fe4a072f28e685bc46df3bace17a7108/src/Tasks/Microsoft.Common.targets#L147
And from there, most of the Microsoft.NET.Sdk's .targets files get imported after Microsoft.Common.targets, and thus after any Directory.Build.targets.
So if you want to override things after a SDK's .targets files, your only real option is to explicitly import the SDK.targets file.  😞

Thanks for the suggestions guys. I've got things working acceptably well now. One thing I'd suggest for documentation improvement, add a link from What's New In MSBuild 15.0 directly to How to: Use MSBuild Project SDKs.
That SDK topic is under "MSBuild Targets", which I didn't bother exploring, because I (thought I) knew all about how targets work. Honestly, the SDK feature feels like it should be its own top-level topic.

@mikejo5000 Feedback on doc organization ☝. Thoughts on making those changes? I'm not sure SDKs deserves a top-level feature, but user feedback is important.

@rainersigwald I'll add the link from What's New. Bumping up the topic to a higher TOC level seems like it would require the addition of a new TOC node such as "MSBuild Projects", but then we'd need to add new content on projects to make sense of it.


Updated ratatui 0.20.1 => 0.22.0

Should fix #18

0.23 is out btw

I had not seen the other  open MR for the same things... closing this one.
Ideally these MRs should also bump the version number of tui-textarea to get a new crate version...

0.23 is out btw

But it is a breaking change that seems to require more than a version bump.
I'd rather have 0.22 now and 0.23 later with fixes...


adapter-cloudflare should warn when server code uses Node builtins like fs

Describe the problem
Cloudflare uses its own JS runtime, so it is not possible to use Node builtins like fs or packages that specifically depend on Node like better-sqlite3. This is possible on, at least, Netlify.
Because IMO Cloudflare hasn't made this clear, a user might try to use them, correctly resulting in an error saying that some packages used are unavailable. However, this error is passed directly from esbuild, and reads like this as a result:

The package "util" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

This message reads as if it's emitted by SvelteKit or Vite and makes the user search for where to specify the platform: 'node', without realizing that it's a platform limitation. This reddit post is an example of a confused user:

I am building an app with SvelteKit and publishing it to Cloudflare Pages, but some packages I am using cannot access node native functions. […] This happened just after I added some server-side code, so that might be the reason, but Sveltekit supports that through Cloudflare workers, so I don't understand why. Help would be appreciated!

Describe the proposed solution
adapter-cloudflare should catch that the user is trying to use packages that are unavailable but are provided by Node, and replace esbuild's message with an explanation that they are unavailable on Cloudflare Workers. Perhaps something like:

The package "util" wasn't found on the file system but is built into node. Please note that Cloudflare does not run serverless functions in node and, as such, non-standard node builtins are unavailable when building for Cloudflare.

Alternatives considered
The explanation could be added to adapter-cloudflare's README instead.
Importance
nice to have
Additional Information
No response

This would presumably fall under part of the work described in #3535.

It does — it's definitely something we want to do, but I'm going to close this as a duplicate


fix(docs): Refer to the OpenAI documentation to update the openai-functions docu…

…mentation
I saw the openai official website, apIn the description: The parameters function_call and functions have been replaced by tool_choice and tools.So I submitted this update;But I haven't read the code of localai, so I'm not sure if it also applies to localai.
Description
This PR fixes #
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

LocalAI supports tools call indeed, however I'm not sure if the example work as-is, did you tested the python code?

I validated it using Python code and also validated it using curl. I found that the original Python example has expired, so I wrote a curl example


icon in the monorepo project cannot be scanned

Describe the bug
In the vite project in monorepo, ICONS used in subpackages cannot be scanned, causing the project startup to fail to display ICONS used in components
Reproduction
Reproduction
System Info
win11  edge

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

If I use fast-glob to match other directories, then this will scan node_modules as well


Common behaviour ?

I ran following code for testing and it showed a Torch prompt.
import lutorpy as lua
import numpy as np

## use require("MODULE") to import lua modules
require("nn")

## run lua code in python with minimal modification:  replace ":" to "._"
t = torch.DoubleTensor(10,3)
print(t._size()) # the corresponding lua version is t:size()

## or, you can use numpy array
xn = np.random.randn(100)
## convert the numpy array into torch tensor
xt = torch.fromNumpyArray(xn)

## convert torch tensor to numpy array
### Note: the underlying object are sharing the same memory, so the conversion is instant
arr = xt.asNumpyArray()
print(arr.shape)

After i quit, Torch the result showed up, is it normal behaviour or is there anything wrong with my setup

Hi @raaka1,
Thanks for your report.
That's not normal, you should only get the output without seeing the torch prompt. On ubuntu, it behave well, and no one report this issue before.
I will try to install it on a mac machine and test on it, since now we got more and more mac users.
Could you provide more information of how you install torch on your osx?

hi @oeway
I am using Jetson TX1, ssh via OSX
curl -s https://raw.githubusercontent.com/torch/distro/master/install-deps | bash
git clone https://github.com/torch/distro.git ~/torch --recursive
cd ~/torch; ./install.sh

Aha, so you are actually running ubuntu, sorry, I was wrong, I thought you are running lutorpy on osx. In that case, it shouldn't happen, and not related with osx at all.
Could you try to open a python prompt and run the file line by line and check which line triggered the torch prompt?


Add Greenlight env var to enable/disable recording thumbnails

Interesting :)
I couldn't find this option in https://github.com/bigbluebutton/greenlight/blob/master/sample.env
Is it not up-to-date?

Interesting :)
I couldn't find this option in https://github.com/bigbluebutton/greenlight/blob/master/sample.env
Is it not up-to-date?

Its not even documented properly.
https://github.com/bigbluebutton/greenlight/search?q=recording_thumbnails&type=code
https://github.com/bigbluebutton/greenlight/issues/1876


NIFI-11502 - Upgrade json-path to 2.8.0

Summary
NIFI-11502 Upgrade json-path to 2.8.0
https://github.com/json-path/JsonPath/releases
Upgrade json-smart to fix https://www.cve.org/CVERecord?id=CVE-2023-1370
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Might want to reference NIFI-11374 as well

@pvillard31 Unfortunately it looks like JSON Path 2.8.0 introduced some changes the break existing unit tests. Further evaluation is necessary to determine whether the test expectations need to be adjusted, or whether the changes have broad impact in runtime deployments.

There are some modules in Nifi using json-path 2.6.9 and some using 2.7.0. If 2.8.0 can’t be used, the modules using 2.6.0 should be updated to 2.7.0

Looking into it, the breaking change happens when going from 2.6.0 to 2.7.0.

After a quick investigation, with 2.6.0, if the JSON path is not resolving to anything we just return the initial JSON without any change and without logging any error. Starting with 2.7.0, if the JSON path does not resolve to an actual element, we throw an error. In order to not introduce any breaking change, I took the same approach as in JsonPathEvaluator with a debug logging and just return the JSON without any change.


Support for MongoDB ObjectID in Pydantic Models

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
I am using Pydantic in conjunction with FastAPI and MongoDB, and I would like to request support for MongoDB ObjectID as one of the field types in Pydantic models.
Background:
Currently, Pydantic supports various field types, but there isn't a specific type for MongoDB ObjectID. MongoDB ObjectID is commonly used in FastAPI applications with MongoDB databases, and having native support for it in Pydantic would greatly enhance the validation capabilities.
Suggested Solution:
I propose adding a dedicated type for MongoDB ObjectID in Pydantic, similar to how EmailStr and other specialized types work. This could be achieved by introducing a type like MongoObjectId or extending the existing PyObjectId to handle MongoDB ObjectID validation seamlessly.
from pydantic import BaseModel
from pydantic_mongo import MongoObjectId

class MyClass(BaseModel):
    my_id: MongoObjectId

Additional Context:
MongoDB ObjectID validation is a common requirement in FastAPI applications, especially when dealing with MongoDB databases. Adding native support in Pydantic would simplify the code and improve the developer experience.
I would love it if we could do something like the below with FASTAPI that works seamlessly in generating the OpenAPI schema as well.
This is because all the workarounds for the above issue face OpenAPI schema issues.
@router.get("/get_id/{my_id}")
def get_goal_by_id(my_class: MyClass ):
    return my_class.my_id

Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[ ] Dataclasses
[ ] Model Config
[X] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

@SkandaPrasad-S if you're using pydantic, FastAPI and pymongo, you can validate the _id field using bson.ObjectId and arbitrary_types_allowed = True, I attached an example with pydantic v1 and the same can be achieved in v2 using ConfigDict.
Anyway, I agree with you that ideally setting arbitrary_types_allowed should not be needed and there should be a standard validator.

@SkandaPrasad-S,
I think this is a valuable feature request, but belongs on the pydantic-extra-types repo. I'll move this request there 👍.
I might also suggest using Beanie, a helpful package for integrating usage of pydantic with mongodb: https://beanie-odm.dev/api-documentation/fields/#pydanticobjectid


ts, ui, sql, ccl: add metrics, timeseries graph for feature flags

PR: https://github.com/cockroachdb/cockroach/pull/57533
From release notes:

Added a timeseries graph indicating statement denials due to feature flags on the SQL Dashboard of DB Console. [#57533][#57533] {% comment %}doc{% endcomment %}

This issue might be for @ianjevans @ericharmeling.


Feathers SDK compiler "unknown error" when using [Bindable] metadata.

I has compiler "unknown error" in IntelliJ IDEA 2017.1.2 regularly the same like at this issue
https://github.com/BowlerHatLLC/feathers-sdk/issues/32
In project more than 10 classes with [Bindable] metadata. In some classes more than 20 public properties for this reason I don’t want to use manual PropertyChangeEvent.PROPERTY_CHANGE dispatching.
I try to import starling.events.EventDispatcher in each class, try to switch off "Compile independent modules in parallel" (in project one AS-library module) but still has compiler "unknown error".
Feathers SDK v 3.3.1 with AIR 27.0 SDK.
Added simple project files as you asked. When I remove [Bindable] in several classes then all is fine. Looks like too much [Bindable] metadata in project. Perhaps this is why earlier compiling was without errors.
errapp.zip

Tested some variats and made conclusions.
Maybe this error happens when class has double [Bindable] property. For example in this project is [Bindable] ActionVO class and it has property params (public var params:ParamsVO;), but class ParamsVO alredy [Bindable] itself. So when I remove [Bindable] from class ParamsVO and his childrens the compiling has no errors.

That seems like a good clue. Thanks!


Add snapshot and release workflows

Add new workflows to upload snapshots and release artifacts automatically.

This is a neat approach. Left a minor comment.

Closes #2752
Closes #2753


Cannot See Vive Controllers in VR with 1.2.3

I have tried Unity versions 5.5.0f3, 5.5.3f1, 5.5.4p4, 5.6.1f1, and 2017.1.1f1 with version 1.2.3 of the SteamVR plugin and none will show the controllers.  All I'm doing is removing the Main Camera from an empty project, and dragging in the [CameraRig and [SteamVR] prefab into the scene and playing the scene.
The only version I can get working (see the controllers in VR) is 5.5.0f3 with a copy of SteamVR 1.2.0 plugin that I have from an old project.
Is there something different that has to be done for 1.2.3 to work?

Thanks for the info. So here is the error, and sorry for the formatting. It's a long one:
Unable to load render model from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\resources\rendermodels
C:Program Files (x86)Steamsteamappsworkshopcontent250820675102547vr_controller_vive_1_5vr_controller_vive_1_5.obj
C:Program Files (x86)Steamsteamappsworkshopcontent250820675102547vr_controller_vive_1_5vr_controller_vive_1_5.obj.obj:
Cannot open file [C:\Program Files (x86)\Steam\steamapps\common\SteamVR\resources\rendermodels
C:Program Files (x86)Steamsteamappsworkshopcontent250820675102547vr_controller_vive_1_5vr_controller_vive_1_5.obj
C:Program Files (x86)Steamsteamappsworkshopcontent250820675102547vr_controller_vive_1_5vr_controller_vive_1_5.obj.obj]
The above is actually all on one line. I have no idea how this works, but if you look at the paths that contain the folder "250820675102547", notice that there are no slashes in the path. Is this behaving correctly?
I did check the controller models in both places and they exist. When I import them into Maya, I get the following error:
Your OBJ file contains faces shared by multiple groups.
Maya cannot create multiple objects for this file.
A single mesh object will be created instead.
The OBJ group information will be captured in Maya sets.
I'm assuming this is innocuous and is just an artifact of the import, but I figured I'd better include it just in case. After opening in Maya, the file consists of 1 combined mesh of everything and some Maya groups that individually list every face and vertex. I haven't used OBJ in years, but again, I'm assuming this is normal.
Oh, and when I open vrclient_TheLab.txt, I see the exact same error with the same paths.

  Try deleting that section and trying again.

@aleiby: Yay! Deleting my config folder fixed the missing controllers. Thanks for the diagnostics. One last question though: In Unity, I'm still not seeing any controllers in the scene view, only in the game view when I hit play. I've never really paid attention to this because I've always used my own custom models before. Am I right in assuming that to see them in the scene view I have to use the Model Override and then switch it back to None before building? If so, it would be nice if they would default to a default model within Unity, but no biggie.

@gevarre Correct.

Update: I've been trying out 2018, and there now seems to be something else going on. I'm still trying to track down the exact cause and sequence of events, but when opening 2018, I now lose the controllers again with the same "Failed to load IVRRenderModels interface version IVRRenderModels_005".
Big difference this time is that there are no errors in the logs and the only way to get them back seems to be to COMPLETELY remove steamvr's config folder, uninstall steamvr completely from steam, restart the computer, reinstall everything, and run all the steamvr setup stuff again. Switching back to 2017 and then 2018 seems to cause the error again, though, as I said, I'm still trying to trace down exact repro steps.

We have a problem where tracking works but the controller models don't show up in Standalone builds. The controller models show up in the editor though but once the project is built the controllers don't show up.
Using SteamVR 1.2.3, Unity 2017.3.1.p4.

I believe this issue has been fixed in recent versions of SteamVR and the Unity Plugin. Let me know if it's still an issue and I'll reopen.

@zite Recently, developer complains that this issue still occurs in recent Unity and SteamVR version. Here is the link to the error log. https://github.com/ViveSoftware/ViveInputUtility-Unity/issues/136#issuecomment-527535072


Add functions: Add/update Targets in TrustedRoot

Summary

The purpose of this PR is to add the required changes to add and update targets in the TrustedRoot. This will involve implementing two new functions:
add_target(&mut self, new_target: TargetType, target_name: Target) -> Result<()>
update_target(&mut self, target: TargetType, target_name: Target) -> Result<()>
These new functions improve the flexibility and usability of the TrustedRoot, making it easier to manage targets effectively.
Related issue: https://github.com/sigstore/sigstore-rs/issues/384
Release Note

Feature: Add and Update Targets in TrustedRoot
Documentation

Hello @flavio, @danbev,
Could you please have a look ?
Thank you in advance!

Hi @fghanmi,
sorry for the delay, I was on vacation.
Can you provide some examples about why we would need to offer the ability to alter the contents of the TUF repository?
Currently the code cares only about downloading the official TUF repository or consuming a local checkout, then rely on that to perform different checks.

Hi @fghanmi, sorry for the delay, I was on vacation.
Can you provide some examples about why we would need to offer the ability to alter the contents of the TUF repository?
Currently the code cares only about downloading the official TUF repository or consuming a local checkout, then rely on that to perform different checks.

Hello @flavio
actually, on our side we need to be able to manipulate trust_root.json in another Rust tool: tuftool (https://github.com/awslabs/tough/tree/develop), since as of now, only sigstore-rs  manages the new-style targets trust_root.json. So, it's the library where this code would fit and would be reusable by other people who have a similar usecase.
In this case, we would be able to use this crate in tough/tuftool to manipulate trust_root.json.
(a similar change was done on sigstore-go  https://github.com/sigstore/sigstore-go/pull/247)

I think changing the contents of the TUF repository is out of the scope of this library. Hence closing.
I can help with getting these changes into the tough crate upstream if you want


Add precompiles for pallet_evm operators: blake2f, modexp, bn128, ed25519verify

Adds some precompiles to the repo for functionality that may or may not exist on other blockchains but are useful nonetheless. These are not tested as I'm unsure how to test them yet but most of it has been migrated from openethereum and existing EIPs.
The modexp one in particular is unsure to be correct as IO between the rust openethereum client and the substrate implementation are a bit different. I'm unsure how to replicate certain IO operations so I opted to manually implement the input parsing.

Currently BLS precompile cannot be added until I find a no_std compatible repo for doing elilptic curve operations on the BLS381 curve. The repo here mentions adding this functionality but has not indicated it is completed: https://github.com/matter-labs/eip1962

@drewstone any updates?

Welp, now I'm getting std errors trying to work around this...

Alright all updated without changing wabt

Just updated again, thanks @NikVolf for the suggestion!

As this touches evm, @sorpaas should leave a review  at least.

Still hoping @drewstone can add the feature gates as requested in the last review! It's otherwise LGTM.

Will get to this this week! Sorry for the delay @sorpaas

@sorpaas I added the feature flags. Lmk wha you think!

Pallet EVM was removed, so this pr is not required in Substrate anymore.


Client only component not mounted after nextTick

Environment

Operating System: Linux
Node Version:     v18.20.3
Nuxt Version:     3.12.3
CLI Version:      3.12.0
Nitro Version:    2.9.7
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/github-bf56vz
Describe the bug
According to the documentation, we can access the rendered template after await nextTick() in the callback of the onMounted hook. But I found if the parent component of the client-only component is mounted after setting v-if as true. We can no longer get the ref template after the first await nextTick().
<script setup>
const mc = ref()

onMounted(async () => {
  await nextTick();
  console.log(mc.value.mounted$);
  await nextTick();
  console.log(mc.value.mounted$);
  await nextTick();
  console.log(mc.value.mounted$);
  await nextTick();
  console.log(mc.value.mounted$);
});
</script>
<template>
    <MyClientComponent ref="mc" />
</template>

will log as the following:
undefined
undefined
false
true

I don't know whether it is an expected behavior. If so, how do we know when we can get the ref template of the client-only component in the onMounted hook?
Additional context

Enter the reproduction
Press the Click to display button
See the log in console

Logs
No response

My workaround
onMounted(async () => {
    // @ts-expect-error mounted$ is not documented
    while (!mc.value?.mounted$) {
      await nextTick()
    }

   // Then we can access ref template safely
   mc.value.myMethod()
})