Allow ImageCache/TextureSystem to store partial channel sets in cache.

Allow ImageCache/TextureSystem to store partial channel sets in cache.
ImageCache's original design would read all channels into a tile,    because (1) most files have only a few channels, (2) most uses (for    example, texture) tend to use most or all of the channels in the file,    in close temporal proximity if not in the same lookup, (3) most file    formats don't have a way to read a channel subset that's any more    efficient than reading all of them.
However, for the rare case that there are MANY channels, only a few of    which are needed (for example, looking up 3 channels of textures from a    40 channel file), this is very wasteful of texture space, and MAY    (depending on the format) also be wasteful of I/O.
So this patch:

Modifies ImageCache so that a tile can store any contiguous subset      of channels. This means the TileID stores a chbegin/chend range,      the hashes consider this, and certain ImageCache public API calls      now have varieties that take chbegin/chend parameters.

ImageCache will create cache tiles that store exactly the channel      range requested. The default is all channels in the tile. Use subsets      wisely -- if you have a 4-channel file and you separately look up      channel ranges [0,1) and [0,3), it will redundantly read and store      the overlapping channels!

TextureSystem is modified to ask for all channels when there are only      a few channels in the file, but when there are more than      max_tile_channels (a new settable attribute of the TS) channels in      the file, it will ask the IC for only the channels it needs for the      texture lookup. The max_tile_channels is set by default to 5, which      means for the vast majority of files (R, RGB, RGBA, RGBAZ) it will      read all channels and behave as before. But if you have a mega-channel      file, it will try to read and cache only the subset of channels you      requested with the texture call. If you don't want the new behavior,      just set max_tile_channels to something bigger.

The bottom line is that if your app uses IC with the old API calls, or    if you use TS with texture files having 5 or fewer channels (which is    almost always the case), you should see no change in behavior or    performance. But for those of you who for some reason deal with files of    many many channels, accessing a small subset of them via texture or IC    should result much more efficient cache behavior because the IC won't be    caching channels you aren't accessing.

Fixes #1123

Any objections to this, or feedback? I will merge in the next couple days if nobody objects.

What are the implications for an application that requests a single channel at a time via ImageCache::get_pixels(), but will typically do so in turn for each of the RGBA channels? Presumably in the past a single tile would have serviced each of those requests, so there would only be one read at the ImageInput level? Does this change mean that potentially each channel access via get_pixels() will now pay for its own read, to fill its own tile, and that for many formats each of those reads will also read all the other channels and throw them away?

Currently, yes, this patch makes IC behave as "I cache what you asked for", so if you call IC::get_pixels with each channel separately, it will end up doing multiple reads and caching the channels as separate tiles.
The IC is dumb and literal, but the TextureSystem tries to be smart about common idioms. In particular, when the TS functions (including TS::get_texels) encounter files with a reasonable number of channels (by default, 5, which would include RGB and RGBA, the 99% common cases), it will ask the IC for a tile containing all channels, even if the call itself is requesting only a subset thereof. Only for "many channel" files does it narrow the range in the cached tiles. It's a settable option of the TextureSystem, so you can just set "max_tile_channels" to 1000 or something to turn off this behavior entirely (from the TextureSystem's point of view).
So I can see a few ways to proceed:

Rather than IC::get_pixels(), you could call TS::get_texels(), and it will handle the issue of coalescing the channels into one tile for <= 5 channel files (and/or you can set the max_tile_channels option to be larger and avoid the issue). If you notice a performance difference between IC::get_pixels and TS::get_texels (they are somewhat different implementations and the latter may be clunkier), let's address that separately, it's fixable if it's a legit issue.

If you must operate at the level of IC rather than TS, you could ask IC::get_pixels for all channels (so it will cache all channels) and then copy out the one channel you need. Or change your code to loop over all channels for the tile at once, rather than separate the requests for different channels.

Or if you don't want to change your code, don't want to bother with an extra buffer copy, but must use IC, then I could add the same kind of max_tile_channels logic to the IC::get_pixels, so that it would automatically cache all channels for moderately-channeled images.

On Oct 14, 2015, at 6:25 AM, John Haddon<EMAIL_ADDRESS>wrote:
What are the implications for an application that requests a single channel at a time via ImageCache::get_pixels(), but will typically do so in turn for each of the RGBA channels? Presumably in the past a single tile would have serviced each of those requests, so there would only be one read at the ImageInput level? Does this change mean that potentially each channel access via get_pixels() will now pay for its own read, to fill its own tile, and that for many formats each of those reads will also read all the other channels and throw them away?
—
Reply to this email directly or view it on GitHub https://github.com/OpenImageIO/oiio/pull/1226#issuecomment-148048248.

--
Larry Gritz
<EMAIL_ADDRESS>

Thanks for the info. It sounds like our current use pattern (this is in Gaffer's ImageReader node) is pretty much worst-case for this new setup, but I don't want to be the fly in the ointment if this works well for everyone else. Gaffer actually has its own caching mechanism for all nodes, but we currently turn it off for the ImageReader on the grounds that we're getting caching from OIIO::ImageCache anyway. It might be that longer term we need to drop down a level and make direct use of OIIO::ImageInput coupled with our own cache. We're in the process of adding support for deep data, and since ImageCache doesn't appear to support that we may end up going that route sooner rather than later anyway.
I wonder if it might be beneficial to add a query to ImageInput to help drive the decision making at the cache level, rather than use the current heuristics. Perhaps a query like "if I were to read this particular channel, what is the full set of channels you would be forced to read by the underlying format?". Or "if I were to read this channel, which other channels would you recommend also reading from a performance standpoint?". It seems that deferring to the formats themselves has the potential for allowing better performance while removing the need for the user to guess an appropriate value for "max_tile_channels", which may well vary from file to file and format to format anyway. It feels like this is the kind of query I'd be looking for if we were to bolt ImageInput directly to our own cache.
Anyway, assuming this is getting merged to master only, I think we have time to formulate a plan either with our own cache or using one of your suggestions, so don't let my comments stand in the way of anything.

In addition to John's points, do you think it might be worth-while to be able to request a selection of channels (possibly only 1 channel) and, at the same time, give ImageCache a hint as to which channels to load alongside the requested one. That way, get_pixels() would cause more channels to be cached than it is actually returning.
As John mentioned, though, we're in the process of implementing Deep support in Gaffer, so will most likely have to shift over to using ImageInput and our own caching, so all this may be moot.

@johnhaddon  and @HughMacdonald  : It sounds like the easiest solution is to make a variety of ImageCache::get_pixels that let you hint at how much you want cached, in addition to how much you want to retrieve at the moment. I'll make that part of this PR. This should be really easy and I may have time to do it today.
Every bit of this affair is too big a change (and an API break) to go anywhere but master, so if you are on an RB, there is no need to deal with this right away.
But I think that it's silly for you to reinvent the caching wheel here. I've been asked for it a couple times already, it's on my list. I'd rather give the IC the ability to handle deep data, than have people abandoning IC for their own separately-developed equivalents. The whole idea of OIIO is to avoid pointless duplication.

@johnhaddon and @HughMacdonald : for get_pixels, do you think it would be better to add int cache_chbegin/cache_chend parameters to give the precise range of what you want cached? Or is it sufficient (or simply better for you) if it's a simple bool indicating whether to cache all channels together, or exactly the channels you're retrieving with that call to get_pixels? Are those the only two useful choices, or is there merit to caching subsets (example: you're asking for channel 2 only, but you want it to make a cache tile of channels 0-4, but the file itself has 16 channels).
Another alternative is to just make get_pixels do what the TextureSystem functions to: automatically cache all channels together for the normal case of <= 5 channel files, and cache what you ask for for many-channel files. Is that (with no API change) a good solution for you? Or will you routinely have >5 channel files that you still need to get_pixels one channel at a time and don't want the data split across separate cached tiles?

I think that having the ability to pass in a list of channels to cache, but to only return a subset of that would be ideal. I think it would be good to keep it flexible. If cache_chbegin/cache_chend are not specified, then ImageCache would do its own logic about what it thinks it might want to cache, but if they are specified, then we know that the requesting code has made its own decisions, so just go with that.
If chbegin/chend aren't within the cache_chbegin/cache_chend range, then I'm not sure whether you'd want to fail, or just extend the cache channel range to encompass the requested channels.
If you're open to adding deep data support to ImageCache, then that would be great for us - I can't speak for @johnhaddon, but I'd definitely be happy to leave that work at the OIIO end of things.
Thanks

I'm fine with specifying a caching range to IC::get_pixels -- it keeps with the strategy of it retrieving and caching exactly what you ask for and not trying to be too smart under the covers.
No worries on the deep stuff, it certainly needs to be done anyway, and knowing that somebody will use it helps to bump it up in priority in my mind. We're using deep more and more here as well, so it's an investment of time that is directly beneficial on my end. I'll open a separate issue for that so we can discuss how it should work.

Great - we'll definitely be using it - I'm sure I'll get very involved with the discussion! I've spent the last couple of months implementing Deep for Gaffer. Mostly working at the moment, with the image I/O the last major part to do.
Thanks, and I'll keep an eye out for the new issue.

Sounds like you two are hashing out something entirely sensible that will definitely work for us, but I'm not 100% convinced we won't end up using bare ImageInputs and our own cache in the long run, for a couple of reasons :

The natural unit of computation in gaffer is a single tile (of a prescribed size - not necessarily matching the ImageCache) of a single channel, and no matter what happens with the ImageCache API, we can't avoid the buffer copy from the ImageCache into a tile in Gaffer. That copy is expensive enough to have shown up as a fairly large cost in profiling before, so eliminating it is worthwhile.
All other computed data in Gaffer (including the 3d side) lives in one cache, and I reckon having a single control over the amount of memory used is mostly preferable to having multiple controls.

OK, do whatever you need to, but I still feel like I need to extend IC to handle deep data either way.
Maybe IC will still serve a purpose for you. If you are maintaining a separate cache on your own with a custom tile size that does not match the tiles of the file itself (or the fact that some files are scanline), and caching channels separately, you're still going to run into an efficiency problem even with ImageInput (or for that matter, even if directly using the underlying format reader libraries). It's going to be hard to avoid redundant reads, or else reading more than you need to fill the tiles, if you know what I mean. It may, in the end, still be worth using IC to buffer the parts of the image you need (in file-specified tile sizes) and then doling them out in app-specified-tile sized chunks.

Updated the patch with the new get_pixels parameters.

cc me

So if I'm not mistaken, reading 4 channels out of a 32 channel file and setting them to cache_chbegin and cache_chend will only read and cache them, but if reading only 4 channels and setting cache_chbegin to 0 and cache_chend to spec.nchannels will actually read all channels and cache all channels.
This can be quite misleading since there seem to be 2 different usages here:

call get_pixels on all channels to cache them (cache_chbegin = 0, cache_chend =-1), but only retrieve a sub-portion of them at a time
call get_pixels to read and cache only what is requested (the point of the pull request in the first place), i.e: cache_chbegin = chbegin and cache_chend = chend

Also there could be a case where the developer could call ImageCache::get_pixels but some of the channels would not get cached at all! (even if read) which is quite the opposite of what is expected of a cache in the first place.
Shouldn't the first use case be covered by a new function which would actually just cache pixels? It seems that the get_pixels function is trying to do much more than what it is expected to do, that is: read and cache what's requested.
An alternative which would make it easier to understand would be 2 separate functions:

cache_pixels (..., chbegin, chend) : which explicitly reads and caches the requested channels (but does not fetch them) and would do nothing if they are already cached

get_pixels: which reads the requested channels (and cache them if they did not exist in the cache)

This way, use-case 1) would be:
cache_pixels(0,-1)

then  for each requested channel
get_pixels(chbegin,chend)
The second use case would just call get_pixels(chbegin,chend).
I know this idea breaks compatibility with existing code, but since we are already changing the API (though not the behaviour) with cache_chbegin,cache_chend, why not make it clear, or make a second version of it and mark the first one deprecated.

Also there could be a case where the developer could call ImageCache::get_pixels but some of
the channels would not get cached at all! (even if read) which is quite the opposite of what is
expected of a cache in the first place.

This is where I suggested that it would internally expand the cached channels to include the requested channels. So if a developer called get_pixels( chbegin = 0, chend = 4, cache_chbegin = 7, cache_chend = 10 ), then it would actually cache channels 0..10
I'm certainly not averse to having two calls - one to cache extra channels and another to actually get the data, but it does mean that you'd be doubling up on a lot of parameters, rather than having just two extra parameters to the existing get_pixels().

It can't work as two calls. A tile containing chans 0-3 and a tile with the same coordinates containing chans 0-31 are considered different tiles, hash differently, and searching for one will not magically turn up the other. So if you ask it to cache chans 0-31 and then get_pixels of 0-3, it will not know that you previously cached all channels and find that tile. The get_pixels retrieval needs to know what channel range to look for in the cache.
I don't think it's confusing. There are three cases:

get_pixels (..., chbegin, chend, /*default cache_chbegin/chend*/) : this has behavior identical to how it's always been (convenient for an unchanged API call appearance), which is to look for a tile containing all channels of the file (reading and caching all channels, if not already done), then fill your buffer with just the channels you asked to retrieve. Do this if you don't care, or if your files tend to be a small number of channels, or if you have many channels but know that you'll get around to needing them all eventually.

get_pixels (..., chbegin, chend, ... chbegin, chend) : look for a tile containing all just the channels you are retrieving now (reading and caching just those channels, if the tile is not yet resident), then fill your buffer with the channels you asked to retrieve. Do this your files tend to be a large number of channels and you only need this subset.

get_pixels (..., chbegin, chend, ... cache_chbegin, cache_chend) : you may wish to look for (and read/cache if not found) a tile containing a superset of the channels you need at the moment. Do this your files tend to be a large number of channels, you will only need the subset [cache_chbegin,cache_chend], but you are asking for an even more narrow subset at this very moment (but know you'll use the rest of the cached subset eventually).

(1) is the common case, you need all channels. (2) is more memory efficient if you're using a few channels from a many-channel file, for example you will only need channels 12-15 of a 32 channel image.
(3) is a weird case (but apparently one that John and Hugh need) where, for example, you will eventually need channels 12-15 of a 32-channel image, but your code is structured so that you are calling get_pixels for just one channel at a time (chan 12, then later chan 13, then later chan 14, then later chan 15, but no others).
I think the current proposed API is simple and has the nice property that the old parameter sequence (leaving the new params at their default) gives the old behavior, which is also the behavior you want for the common case.
As I currently rigged it, if you give an invalid cache_begin/end range (for example, if the cache begin/end doesn't contain all the channels you are asking to retrieve), it will fall back on case (1) and just read and cache all channels. If you don't want all channels read and cached, it's up to you to make a caching request that makes sense given your expected usage pattern. It will always work, but it may not be memory or I/O efficient if you don't know what you're doing.

Fair enough, as my edit says, as long as the documentation is clear on that, there might be other developers reaching unexpected behaviour.

On 16 Oct 2015, at 19:52, Larry Gritz<EMAIL_ADDRESS>wrote:
It can't work as two calls. A tile containing chans 0-3 and a tile with the same coordinates containing chans 0-31 are considered different tiles, hash differently, and searching for one will not magically turn up the other. So if you ask it to cache chans 0-31 and then get_pixels of 0-3, it will not know that you previously cached all channels and find that tile. The get_pixels retrieval needs to know what channel range to look for in the cache.
I don't think it's confusing. There are three cases:
get_pixels (..., chbegin, chend, /default cache_chbegin/chend/) : this has behavior identical to how it's always been (convenient for an unchanged API call appearance), which is to look for a tile containing all channels of the file (reading and caching all channels, if not already done), then fill your buffer with just the channels you asked to retrieve. Do this if you don't care, or if your files tend to be a small number of channels, or if you have many channels but know that you'll get around to needing them all eventually.
get_pixels (..., chbegin, chend, ... chbegin, chend) : look for a tile containing all just the channels you are retrieving now (reading and caching just those channels, if the tile is not yet resident), then fill your buffer with the channels you asked to retrieve. Do this your files tend to be a large number of channels and you only need this subset.
get_pixels (..., chbegin, chend, ... cache_chbegin, cache_chend) : you may wish to look for (and read/cache if not found) a tile containing a superset of the channels you need at the moment. Do this your files tend to be a large number of channels, you will only need the subset [cache_chbegin,cache_chend], but you are asking for an even more narrow subset at this very moment (but know you'll use the rest of the cached subset eventually).
(1) is the common case, you need all channels. (2) is more memory efficient if you're using a few channels from a many-channel file, for example you will only need channels 12-15 of a 32 channel image.
(3) is a weird case (but apparently one that John and Hugh need) where, for example, you will eventually need channels 12-15 of a 32-channel image, but your code is structured so that you are calling get_pixels for just one channel at a time (chan 12, then later chan 13, then later chan 14, then later chan 15, but no others).
I think the current proposed API is simple and has the nice property that the old parameter sequence (leaving the new params at their default) gives the old behavior, which is also the behavior you want for the common case.
As I currently rigged it, if you give an invalid cache_begin/end range (for example, if the cache begin/end doesn't contain all the channels you are asking to retrieve), it will fall back on case (1) and just read and cache all channels. If you don't want all channels read and cached, it's up to you to make a caching request that makes sense given your expected usage pattern. It will always work, but it may not be memory or I/O efficient if you don't know what you're doing.
—
Reply to this email directly or view it on GitHub https://github.com/OpenImageIO/oiio/pull/1226#issuecomment-148784577.

(3) is a weird case (but apparently one that John and Hugh need) where, for example, you will eventually need channels 12-15 of a 32-channel image, but your code is structured so that you are calling get_pixels for just one channel at a time (chan 12, then later chan 13, then later chan 14, then later chan 15, but no others).

I was agreeing with everything until this was labelled weird :) If you give users arbitrary control to load and composite images, then you really don't know what channels you need until you execute, and you won't know the full set until you finish. Just as if you give users arbitrary control to sample textures from multiple shaders, you don't know what was actually needed till the render finishes. Ideally in these scenarios you don't want to pay for any more than you ask for, but all you can do right now is hedge your bets by making two guesses :

If the user wants channel N now, what others might they want in the future?
If I ask for channel N from the cache, what other channels will the underlying ImageInput be forced to read due to the restrictions of the file format?

Hopefully for 1) it's reasonable to guess "the other channels in the same layer", or "a shader will do all its lookups at once and other shaders will be using different textures, so punt".
For 2), I still believe a method to query ImageInput directly might be valuable. It seems like the ideal cache granularity is the intersection of the channels from 1) and 2), so I guess this query is only useful if there are formats for which the set from 2) is smaller than the set from 1)?

Yes, I was using "weird" to mean "so far, John's request is the only one I'd heard." As you explain it, it is entirely sensible.
How about an ImageInput::supports() query that reveals whether the format supports true channel subset reads?

How about an ImageInput::supports() query that reveals whether the format supports true channel subset reads?

I think the ideal is less a true/false thing and more a "which particular subsets of channels are mutually dependent when loading" thing, which I guess can't be squeezed through the supports() API. But I'll have to reveal my ignorance - I don't know enough about the underlying formats to know if this is a useful distinction in practice. A quick read of the EXR docs suggested that for EXR you have to get all channels for an image (or image part) at once anyway? Would I be right in thinking that a multipart file would present itself as multiple sub images via OIIO, and that therefore EXR can't actually read channel subsets independently at all as far as OIIO would be concerned?

I wasn't sure, so I looked more carefully at the OpenEXR spec, and it appears that although the various channels are separated (RRRRGGGGBBBBAAAA), they are compressed as one data block and thus not separately addressable prior to reading and decompression. So it's not possible to read just "G" alone; it has to read the whole scanline (of that "part"), thought the APIs make it easy to only copy certain channels to your app-side buffer.
So there is no I/O advantage to reading a channel subset (or "layer") of an OpenEXR file. The only advantage is in cache storage -- if you are using a tiny subset of the channels in the "part" of the file, you will get better cache performance if you don't cache the channels you don't expect to use.
Note, though, that for OpenEXR 2.0 and beyond, you can have "parts", and each part can be separately read and addressed. So rather than have 32 channels, with the first 4 being RGBA, and the next 4 being the diffuse AOV, and the next 4 being the specular AOV, or whatever, it may be much more efficient (if you intend to need to read only one of those "layers") to store each layer as a different "part": one part for RGBA, the next separate part in the same file for diffuse, etc. That kind of layout (which demands OpenEXR 2.x) WILL have I/O efficiency if you only need one of these AOVs.
For TIFF, there is a choice of "contiguous" planar configuration (RGBARGBARGBA) or "separate" configuration (RRRGGGBBBAAA). If a particular file is stored as separate, then there is indeed I/O savings to be had by requesting only some channels. But if you're going to use all the channels, contig is more efficient, so we always use contig.
I'm not aware of any other formats that we support which allow truly separate reading of channels.
Bottom line is, there is only an I/O advantage to partial channel reads for TIFF, and only if the file uses the packing order that we ordinarily advise against.
I'm still happy to try to implement this check, but I don't think it will really tell you anything useful.
I don't think it's reasonable for OIIO to tell you "which particular subsets of channels are mutually dependent when loading." That's a semantic distinction that depends a lot on what the app intends to do, I don't see how OIIO could be helpful in giving any hints there.

Is everybody ok with this change? Should I merge it into master?
The memory issues being described in #1123 don't appear to be related to this patch, so I see no reason to hold it on account of that. (And, in fact, I also claim that there is no leak, but merely an example of a use case that isn't aligned with the intended design of ImageCache.)

Looks good. I have fixed the ImageCache usage on our end, taking your advice.

Looking at the code, it appears that, if the chbegin..chend range crosses outside of cache_chbegin..cache_chend range, it will just cache the full range. Is that right?
I know that that isn't a situation that a user should ever find themselves in, but do you think that it's better to cache the full range rather than just expanding the cache range to encompass chbegin..chend?

The behavior I made was that if the cache range is invalid, it will cache all channels. The alternative is that if the range is invalid, use the requested channels as the cache range (or expand the cache range to include the requested channels?).
I'm not sure there's a strong argument one way or the other, but here's a weak one for my way: If the range is invalid, somebody has made a mistake, and maybe they'll make a mistake on the next call as well, so I think it's better to cache all channels and reduce I/O rather than have each query need to read the tile from disk again. Another weak argument is that this is the case for default arguments (0,-1), and by asking for all channels we are simply preserving the old behavior exactly.
Is there a good argument for why -- again, for a nonsensical cache range that we hope we'll never encounter from an app -- you would expect "expand the range to cover just these channels" is better than "expand the range to cover all channels"?

I think your argument makes perfect sense. As you said, it's an error on the programmer's part if it happens, so best to just go back to the old behaviour.


How to add groups only, to be used for openid?

Type of question
General Context
Support question
Hi,
I'm trying to set up nifi using nifikop with keycloak. I've been able to login through keycloak but how do I set up the groups (and thus access) for those users, without having to add every single user as another k8s resource? All I need is a group mapping that, say, a user is part of the group "admin" he gets all rights, etc. No need to have user duplicates.
Can you maybe point me into the right direction?
NiFiKop version
1.10.0
Golang version
No response
Kubernetes version
1.26.5
NiFi version
1.26.0

This was only supported starting in Apache NiFi v1.23.0: https://issues.apache.org/jira/browse/NIFI-11492
As long as the group name in keycloak exactly matches the name of the group in NiFi, the user will be granted the group's authorizations.

Thank you. That's good to know. Frankly, I'm really struggling running NiFi. I've so far only managed to get it running in Single User Mode (funnily enough authentication through OpenID works regardles). If I disable that (And disable the single user authorizer) I always get the error that the data/users.xml can't be found. This also doesn't change, if I actually add NifiUser (and NifiUsergroup) ressources to k8s.
Searches with google or here (or the old repo on github) didn't really help me, nor did the administrator's guide or samples.

Have you seen this? https://github.com/konpyutaika/nifikop/tree/master/config/samples/keycloak-example

Yes, I have. The issue, however, isn't the connection from Keycloak to Nifi, but having Nifi not terminate due to a file missing. Unless I've overlooked something within that sample.

Yes, to have the operator create a group in NiFi for you, use the NifiUserGroup resource.
I've never deployed a NiFi with single user configuration and tried to migrate it to use a different authorizer. Perhaps @juldrixx knows whether this works?
You cannot use both the single user authorizer and configure users and groups. It's one or the other.

I pretty sure it's not possible. When the single user authorizer is configured the user and group configuration aren't configurable in the NiFi UI so I'm guessing that it's not configurable.

Yes, to have the operator create a group in NiFi for you, use the NifiUserGroup resource.
I've never deployed a NiFi with single user configuration and tried to migrate it to use the standard managed-authorizer. Perhaps @juldrixx knows whether this works?
You cannot use both the single user authorizer and configure users and groups. It's one or the other.

I pretty sure it's not possible. When the single user authorizer is configured the user and group configuration aren't configurable in the NiFi UI so I'm guessing that it's not configurable.

@AlexEndris My recommendation would be to deploy a fresh NiFi cluster and configure NifiUser and NifiUserGroup resources as needed. Just as in the keycloak example in the nifikop repo, you shouldn't need to configure anything related to single-user auth.
and like in NIFI-11492, as long as an authenticating user belongs to a group (coming from Keycloak) that exactly matches a group in NiFi, then that user will be authorized. See this unit test for how the logic works.

@mh013370 As it's still in evaluation, I won't migrate anything and just create a new one. That's not a problem. I will have another look. Thank you very much for your help with this.
@juldrixx Last time I've tried not using the single user section (aka no configuration set so it should be 'false'), Nifi didn't start properly because it couldn't find the "../data/users.xml" file that's part of the file based authorizer which is used by the managed-authorizer. Even though I added a NifiUser and NifiUserGroup. Did I miss some configuration?

@mh013370 As it's still in evaluation, I won't migrate anything and just create a new one. That's not a problem. I will have another look. Thank you very much for your help with this. @juldrixx Last time I've tried not using the single user section (aka no configuration set so it should be 'false'), Nifi didn't start properly because it couldn't find the "../data/users.xml" file that's part of the file based authorizer which is used by the managed-authorizer. Even though I added a NifiUser and NifiUserGroup. Did I miss some configuration?

Not sure why, but maybe you didn't configuration authentication method at all. At least one method must be configured between singleUser, OIDC, LDAP, SAML, etc.

That might be it, although I could swear I had the OIDC with Keycloak configured. I'll have another stroll down the rabbit hole on Monday. Maybe it is as easy as that and I was just too deep to see it. Thank you!

@juldrixx I've tried the following values for the nifi-cluster helm chart to instantiate the cluster. It keeps starting and terminating.
cluster:
  nodeUserIdentityTemplate: node-%d
  controllerUserIdentity: "nifi-controller"
  listenersConfig:
    internalListeners:
      - type: "https"
        name: "https"
        containerPort: 8443
      - type: "cluster"
        name: "cluster"
        containerPort: 6007
      - type: "s2s"
        name: "s2s"
        containerPort: 10000
      - type: "prometheus"
        name: "prometheus"
        containerPort: 9090
    sslSecrets:
        tlsSecretName: "test"
        create: true
  externalServices:
    - name: "nifi-cluster-ip"
      spec:
        type: ClusterIP
        portConfigs:
          - port: 8443
            internalListenerName: "https"
  nifiProperties:
    webProxyHosts:
    - nifi.example.com
    overrideConfigs: |
      nifi.web.proxy.context.path=/
      nifi.sensitive.props.key=changemequickly
      nifi.security.user.oidc.discovery.url=https://keycloak.url.com
      nifi.security.user.oidc.client.id=nifi
      nifi.security.user.oidc.client.secret=myultrasecret
      nifi.security.user.oidc.additional.scopes=offline_access,email
      nifi.security.user.oidc.fallback.claims.identifying.user=preferred_username
zookeeper:
  enabled: true

the user and usergroup:
apiVersion: nifi.konpyutaika.com/v1
kind: NifiUserGroup
metadata:
  name: test
  namespace: nifi-cluster
spec:
  clusterRef:
    name: nifi-cluster
    namespace: nifi-cluster
  usersRef:
    - name: test
  accessPolicies:
    # defines the kind of access policy, could be "global" or "component".
    - type: global
      # defines the kind of action that will be granted, could be "read" or "write"
      action: read
      # resource defines the kind of resource targeted by this access policies, please refer to the following page:
      #	https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#access-policies
      resource: /counters
---
apiVersion: nifi.konpyutaika.com/v1
kind: NifiUser
metadata:
  name: test
  namespace: nifi-cluster
spec:
  # identity field is use to define the user identity on NiFi cluster side,
  #	it use full when the user's name doesn't suite with Kubernetes resource name.
  identity<EMAIL_ADDRESS>  # Contains the reference to the NifiCluster with the one the registry client is linked.
  clusterRef:
    name: nifi-cluster
    namespace: nifi-cluster
  # Whether or not the the operator also include a Java keystore format (JKS) with you secret
  includeJKS: false
  # Whether or not a certificate will be created for this user.
  createCert: true

This is what I get during start up in the logs:
ERROR [NiFi logging handler] org.apache.nifi.StdErr [java.io.FileNotFoundException: ../data/users.xml (No such file or directory)]
ERROR [NiFi logging handler] org.apache.nifi.StdErr  - with linked exception:
ERROR [NiFi logging handler] org.apache.nifi.StdErr Failed to start web server: Error creating bean with name 'niFiWebApiConfiguration': BeanPostProcessor before instantiation of bean failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.security.config.annotation.method.configuration.PrePostMethodSecurityConfiguration': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.apache.nifi.web.security.configuration.AuthenticationSecurityConfiguration': Unsatisfied dependency expressed through constructor parameter 2; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authorizer': FactoryBean threw exception on object creation; nested exception is org.apache.nifi.authorization.exception.AuthorizerCreationException: javax.xml.bind.JAXBException

Am I missing something? According to what you said, this should suffice for it to run. I don't really know what I can do different here.
Logs from the operator itself just state, that it can't reach any node, which makes sense, if the node keeps throwing an exception during startup.

@AlexEndris  same error here


Newer versions (>sqlite-jdbc-3.43) can't open example database "chinook.db"

Describe the bug
A very common sqlite example database exists: chinook.db. It can be downloaded here.
Earlier versions of sqlite-jdbc allowed connecting to this database, e.g., sqlite-jdbc-<IP_ADDRESS>.jar works. Newer versions such as sqlite-jdbc-<IP_ADDRESS>.jar or sqlite-jdbc-<IP_ADDRESS>.jar result in an SQLException "No suitable driver found for jdbc:sqlite:chinook.db"
To Reproduce
Create IntelliJ Project, put chinook.db inside the project folder. Download sqlite-jdbc-<IP_ADDRESS>.jar, add it to the project's classpath. Build and execute the following code:
` public static void main(String[] args) {
Connection conn = null;
try {
String url = "jdbc:sqlite:chinook.db";
conn = DriverManager.getConnection(url); // This line fails
        System.out.println("Connection to SQLite has been established.");
    } catch (SQLException e) {
        System.out.println(e.getMessage());
    } finally {
        try {
            if (conn != null) {
                conn.close();
            }
        } catch (SQLException ex) {
            System.out.println(ex.getMessage());
        }
    }
}`

Expected behavior
Database connection should be opened, instead "No suitable driver found for jdbc:sqlite:chinook.db". When switching inside this project to an older lib version, connection is successful.
Environment (please complete the following information):

OS: Windows 10
Java SDK 22
IntelliJ

Additional context
May be a chinook.db problem?

"No suitable driver found for" sounds more like a problem with the class path / module path / project setup. This is a default error message from within the DriverManager class. The DriverManager uses a simple ServiceLoader based mechanism to lookup all viable JDBC drivers and checks if one of the found drivers can handle the provided URL. If the error message get's thrown, no driver has been found on the class path, that can handle URLs of a certain pattern.
In a very basic Maven project consisting of the parts below, I cannot reproduce the issue. Tested with the versions you have mentioned and the latest release <IP_ADDRESS>.
pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>test</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<dependencies>
		<dependency>
			<groupId>org.xerial</groupId>
			<artifactId>sqlite-jdbc</artifactId>
			<version><IP_ADDRESS></version>
		</dependency>
	</dependencies>
</project>

Test.java
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class Test {
  public static void main(String[] args) {
    String url = "jdbc:sqlite:chinook.db";

    try (Connection conn = DriverManager.getConnection(url)) {
      System.out.println("Connection to SQLite has been established.");

      try (PreparedStatement statement = conn.prepareStatement("SELECT COUNT(*) FROM ALBUMS");
          ResultSet result = statement.executeQuery()) {
        if (result.next()) {
          System.out.println("Got %d albums.".formatted(result.getInt(1)));
        }
      }
    } catch (SQLException e) {
      System.out.println(e.getMessage());
    }
  }
}

.
├── src
│   └── main
│         └── java
│               └── Test.java
├── chinook.db
└── pom.xml


Error with findOne special caractere "²"

Hello,
I have a problem with me project i use LokiJs and it might be a bug.
it seem lokiJS under IE11 have a problem to find attribute containing special character like '²'.
every other item in the database work but those with those seem to return null every time (yet it work well on chrome and firefox).
Anyone encounter the same problem ? is it a known bug or a mistake on my end?

I can't recreate this error using our LokiSandbox in IE11.  (Oddly though the following code block doesn't render preview correctly in github markdown editor on edge on 1803).
For example, this works :
var db = new loki('sandbox.db');
var items = db.addCollection('items');

items.insert({ name : 'mjolnir', owner: 'thor', maker: 'dwarves' });
items.insert({ name : 'gungnir', owner: 'odin', maker: 'elves' });
items.insert({ name : 'draupnir', owner: 'odin', maker: 'elves²' });

var result = items.find({ 'maker': 'elves²' });
logObject(result);

Can you use LokiSandbox to find a repro case and post it here ?

after some test it appear that the error wasn't related to LokiJS but rather a strange IE choice regarding value return from 'select' which make the value different from the one registered by lokiJS.
Sorry for the false issue.


Fix missing SetLoadBalancerListenerSSLCertificate permission

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
Masters are missing the permissions required to configure ELB resources.
What you expected to happen:
What happened before we locked it down https://github.com/jetstack/tarmak/pull/142
How to reproduce it (as minimally and precisely as possible):
TODO
Anything else we need to know?:
Seems SetLoadBalancerListenerSSLCertificate is the one missing.

/assign

I don't seem to be able to replicate this. I created a cert with cfssl, imported it to ACM, annotated a LB Service resource with it's arn, after a short delay a LB is provisioned with the correct cert set. I see no errors in the logs.
Closing for now.

Related links:


Support 0d array as argument of ndarray.getitem

This PR make ndarray.__getitem__ behave consistently with NumPy when there is 0d array in slices.

LGTM expect comment.

Thank you! Fixed.

OK!


Add validations to Listings

I just created a Listing with blank entries for all fields. I believe we should add validations on the fields such that they are not null. @maebeale does that sound right to you?

YES, please! Thanks for noticing this.


Docs reorder readme

Codecov Report
Patch and project coverage have no change.

Comparison is base (d6e0c71) 28.49% compared to head (b1e91c5) 28.49%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   28.49%   28.49%
=======================================
  Files          14       14
  Lines         758      758
  Branches       98       98
=======================================
  Hits          216      216
  Misses        538      538
  Partials        4        4

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Custom view loading from xib

hello,
Is there a way to get custom view from a xib?
thanks a lot

Would be interested in this too!

You need to return your custom view from viewGenerator, and update it in viewUpdater
let provider = CollectionProvider(
			dataProvider: dataSource,
			viewGenerator: { (data, index) -> CustomView in
				return CustomView.instantiateFromNib() (code to load from nib)
			},
			viewUpdater: { (view: CustomView, data: Data, at: Int) in
				view.configure(with: data)
			}
		)


fix ESM types

closes https://github.com/lukeed/polka/issues/199

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (8fb37d8) 100.00% compared to head (f6ada82) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              next      #200   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          204       204
=========================================
  Hits           204       204

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Released in the next.24 batch

thank you Luke!!!


feat(ui): add form for file type select

✅ This PR depends on https://github.com/neulab/ExplainaBoard/pull/74 . This PR is ready to be merged now!

Added a form item so users can select the file type. We can now generate analysis reports for NER (CoNLL format). related #54

Issues:

We might want to display more information about system output file formats (things we support for each task and description). This will require a change in the SDK.
Sample ID mismatch for QA tasks: https://github.com/ExpressAI/ExplainaBoard/issues/36
NER has a very different format. We briefly talked about some possible solutions for this but I don't recall we end up with a super concrete plan because we just started to implement system submission back then. I think it's finally time for us to actually address this issue 😎. Lets' talk about this when we meet this week!

Also, fixed a bug related to QA. closes https://github.com/neulab/ExplainaBoard/issues/73

This PR is finally ready to be merged now! When you get a chance, please take a look and let me know if there's anything you want me to change @OscarWang114 😀

LGTM!


Replace cmpopts.IgnoreUnexported with protocmp.Transform

Replace cmpopts.IgnoreUnexported with protocmp.Transform

Fixes #465

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

26 of 33 (78.79%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.2%) to 23.875%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

database/gormdb.go
11
14
78.57%

database/gormdb_course.go
15
19
78.95%

Files with Coverage Reduction
New Missed Lines
%

database/gormdb_course.go
1
63.16%

database/gormdb.go
2
78.49%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
2249

Relevant Lines:
9420

💛  - Coveralls

Codecov Report

Merging #576 (0c7233a) into master (f50777f) will increase coverage by 0.17%.
The diff coverage is 66.66%.

:exclamation: Current head 0c7233a differs from pull request most recent head 98f07a2. Consider uploading reports for the commit 98f07a2 to get more accurate results

@@            Coverage Diff             @@
##           master     #576      +/-   ##
==========================================
+ Coverage   21.64%   21.82%   +0.17%
==========================================
  Files          53       53
  Lines        7535     7542       +7
==========================================
+ Hits         1631     1646      +15
+ Misses       5622     5613       -9
- Partials      282      283       +1

Flag
Coverage Δ

unittests
21.82% <66.66%> (+0.17%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

web/courses.go
38.50% <ø> (ø)

database/gormdb_course.go
57.77% <61.11%> (-0.56%)
:arrow_down:

database/gormdb.go
75.00% <75.00%> (+2.84%)
:arrow_up:

ag/ag.pb.go
2.97% <0.00%> (+0.31%)
:arrow_up:

database/gormdb_enrollment.go
73.01% <0.00%> (+3.17%)
:arrow_up:

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 f50777f...98f07a2. Read the comment docs.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-2.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 759

Questions ?
Please refer to the Backport tool documentation


Include "connection reset by peer" errors in the summary

Proposal

Vegeta should not stop on read tcp ... read: connection reset by peer errors, but continue and include them in the final summary.
Background
I'm trying to use Vegeta to test the downtime effect of an application restart. If I run
echo 'GET http://localhost:8080/' | ./vegeta attack -duration 5s -rate 100 | ./vegeta report

while the app is not listening, I'll get
...
Status Codes  [code:count]                      0:500
Error Set:
Get "http://localhost:8080/": dial tcp <IP_ADDRESS>:0-><IP_ADDRESS>:8080: connect: connection refused

as expected. But if the app is running when Vegeta is started, and I quickly kill the app and restart it, Vegeta stops when its existing connections receive ECONNRESET, and prints a set of Get "http://localhost:8080/": read tcp ... read: connection reset by peer. If I reset the app nicely (not killing any already-open connections) then nothing bad happens (only a few "connection refused" errors during the downtime).
I'd expect it to "catch" the errors, include them in the summary and continue. I think it already includes those errors in the summary, but it still bails out and prints a bunch of stacktraces. Just like Vegeta counts "connection refused" errors and continues on, it should count "connection reset" errors and continue on.
Workarounds
Didn't think of any currently.

I think Vegeta does continue as you expect, but sending 500 requests that return immediately because they fail to establish a connection takes very little time.

The reason I think Vegeta does not continue is that the total count of requests does not match duration x rate. For example, in the -duration 5s -rate 100 case, if I kill the app - Vegeta stops without 500 total requests.

Here's a result demonstrating this: echo 'GET http://localhost:8000/' | ./vegeta attack -duration 5s -rate 100
stacktraces...
...
...
 Did you omit stack traces? Can you show those?
Sent via Superhuman iOS<EMAIL_ADDRESS>)
On Sun, Jul 12 2020 at 10:01 AM, Yonatan Goldschmidt <<EMAIL_ADDRESS>> wrote:

Here's a result demonstrating this: echo 'GET http://localhost:8000/' |
./vegeta attack -duration 5s -rate 100
stacktraces...
...
...

Reply to this email directly, view it on GitHub (
https://github.com/tsenart/vegeta/issues/527#issuecomment-657188717 ) , or
unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAAQPDZLYSVHHFE5P452CQLR3FUUPANCNFSM4OQ4FF3Q
).

There are tons of goroutines -> tons of stack traces, and there are many that are actually different... I spent some time looking at some of them, also looked in the code and I see it should handle connection reset by peer errors, which will be accounted in all send / receive error cases in lib/attack.go:hit.
So... I reached the top of the very long error message printed by Go, to find this bit first:
runtime: mlock of signal stack failed: 12
runtime: increase the mlock limit (ulimit -l) or
runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+
fatal error: mlock failed

Sigh. Very unexpected that Go needs so much mlock, apparently it's about https://github.com/golang/go/issues/35777.
My ulimit -l is 64 (Docker's default?) According to the stacktraces, the failed allocations are of Go's runtime, so Vegeta shouldn't do something about it, but a nicer error message describing what you should do to overcome it would be nice (at least so you could understand it's an external error which caused Vegeta to bail, and not something internal). Generally for all Go-runtime related errors I believe it's nicer user experience if Vegeta tells you that + attempts to give a fix.
Thanks, and sorry for the misleading bug report. I'm closing this but still thinking it's a good idea to improve Go-runtime related errors :)


Add a version flag to ribasim_cli

This is useful for users, makes bug reports easier, and we can use it for a basic sanity check of the built executable

[ ] Add the flag
[ ] Use it on TeamCity

Related to #90.

work out a method to track version compatibility with python and QGIS


[web] improve platform view semantics

Flutter communicates the semantics of platform views by providing a semantics node with a platformViewId. It then expects the engine to embed the semantics of the platform view into Flutter's semantics tree for proper presentation to the user.
On the web, there is no way to separate the semantics of HTML from its visual representation, and so it's not possible to render a platform view's pixels in the render tree, and its semantics into a separate semantics tree.
Currently, on the web we render semantics either on top of the render tree or below it[^1]. This works in simple cases, but it doesn't cover everything. For example, a video player covered by a pointer interceptor faces a dilemma:

If the semantics tree is on top, it obscured the semantics of the video player.
If the semantics tree is on the bottom, then it is obscured by the pointer interceptor.

A more correct implementation would segment the semantics tree such that Flutter semantics that must appear behind a platform view are rendered behind it, and those on top are rendered on top. Scenelet design touches on how this can be done if we prerolled the scene and semantics into a sequence of "scenelets", but we need a more details design.
[^1]: a developer-facing API this not yet available but is about to be implemented.

Yes, please Flutter team, address this if possible. As an example, when I embed a map (e.g. Google Map or MapBox map, whatever) in my Flutter app, it renders an flt-platform-view, which prepends its Semantics to the beginning of the web page. This cannot be overridden by wrapping the plugin widget (which renders the platform view) in Semantics, ExcludeSemantics, or anything.
I think the only way to override (but a very bad practice) is to add JavaScript to my index.html to listen for DOM changes, or inject from Dart, some JavaScript that will add aria-hidden="true" to all the flt-platform-view inside the flt-glass-pane shadow DOM. Would be really great to be able to just have the Semantics for these views show up in proper DOM order. Thank you.

Update: this is now partially addressed via aria-owns attribute. Unfortunately, Safari doesn't support it yet https://bugs.webkit.org/show_bug.cgi?id=223798, so we can't consider it fully fixed yet.


Configuration for position of single line statements

For example, deciding on this:
if (test) statement;
// or
if (test)
    statement;

I will probably keep the second as the default because I’m a big fan of it over the first.
https://twitter.com/davidsherret/status/1143491015518621696?s=21
Should be 3 options, one for first, second, then "maintain".

Implemented as singleBodyPosition.


Go Live

Push to live

Docs Build status updates of commit cde693c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/TOC.yml
:white_check_mark:Succeeded
View

msteams-platform/assets/images/tab-images/open-stage-from-adaptive-card1.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/tab-images/open-stage-from-adaptive-card2.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/tabs/stage-view-working.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/tabs/tabs-link-unfurling.png
:white_check_mark:Succeeded
View

msteams-platform/messaging-extensions/how-to/link-unfurling.md
:white_check_mark:Succeeded
View

msteams-platform/tabs/tabs-link-unfurling.md
:white_check_mark:Succeeded
View

msteams-platform/whats-new.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


15% discount instead of 5%

Not sure we are updated about that
See with Christophe and nicolas

This is the news UI version with the 15% discount instead of 5% :
https://xd.adobe.com/view/b7fa1665-e867-40f7-ba97-c23d3c82d414-e2a9/


Added onMarkersChange callback

I need to listen to markers change in some way, so I added a callback for it. There is similar functionality in onRegionComplete (it has "markers" property), but usually, that information is not relevant. For example, in my case, I use onRegionComplete to request markers from the backend, after that library clustering them, and I have no chance to get clustered markers

Hi 👋
I released new version of this module: 3.2.0.
onMarkersChange is there 👍
Thank you for your contribution ❤


Retryable errors: make default list extendable

As mentioned in this comment, we should expose a helper function that returns the default retryable errors, so that the configurable list of retryable errors can be extended rather than replaced.

Is there any ETA for this please?

Is there any ETA for this please?

Hi Rich, we (Gruntwork) are not currently working on this as we're super busy with other things on our roadmap. However, if you'd like to try and contribute a PR to add this feature, I'll be more than happy to provide reviews/help/guideance.

Resolved in v0.51.4 release.


Small changes to the template

Proposing a couple of changes I find myself adding to every extension.
Namely, change the initialize function from:
    def initialize(self):
        self.extension_name = "%extension_name%"

to
    def initialize(self):
        self.extension_name = "%extension_name%"
        self.extension_version = self.activation_config.version
        self.logger.name = self.extension_name
        self.logger.info(f"Initializing {self.extension_name} {self.extension_version}")

Changes:

Set the extension version based on activation config version
Set the logger name to the extension name (often dynatrace_extension.sdk.extension is longer and less relevant than the extension name)
Log by default the extension along with its version. This helps in troubleshooting and is more relevant than the SDK version which is currently logged instead.

The existing log message already did what I wanted, however the self.extension_name part would always be empty since __init__ sets it to "" and implies that user must set it. I don't understand why, so I made a further change...
I moved name as a parameter on __init__. So our template now passes this into the object creation:
def main():
    ExtensionImpl(name="%extension_name%").run()

Not sure if you also agree with it?


Add documentation cmake support

Please use rebase instead of merge, we can't help you fix the conflict because we don't have permission to access your branch.

Thank you, it was some GitHub issue. Rebased.


Bump version for compiler hotfix release 0.58.1

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs


chore(package): use --failOn arg for license checking

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
561

Relevant Lines:
561

💛  - Coveralls


Resolve the UFS leak in copy job

What changes are proposed in this pull request?
This PR resolves the UFS leak problem in copy job. By making the method public in UfsManager.
Why are the changes needed?
Since we don't have mountID in Dora, so we need a new way to identify which UFS to use. Currently, I'm following the original design which uses Scheme, Authority & Properties as the key. Later on, we should also use the token given by the client to identify the UFS.
Does this PR introduce any user facing changes?
na

alluxio-bot, merge this please


qify should use divisibility hypotheses on nats

Right now, qify seems to be able to use divisibility hypotheses on ints but not nats. It would be nice if it worked for both.
import Mathlib.Tactic.Qify

example (n m : ℕ) (h : m ∣ n): n / m * m = n := by
  qify [h]
  -- oops! h wasn't used. goal is:
  -- ⊢ ↑(↑n / ↑m) * ↑m = ↑n
  sorry

example (n m : ℕ) (h : m ∣ n): n / m * m = n := by
  rw [← Int.ofNat_dvd] at h
  qify [h]
  -- yay! h was used. goal is:
  -- ⊢ ↑n / ↑m * ↑m = ↑n
  sorry

In turns out this is a confluence issue in the simp set that qify uses:
import Mathlib.Algebra.CharZero.Lemmas
import Mathlib.Tactic.Qify

example (n m : ℕ) (h : m ∣ n): n / m * m = n := by
  -- qify [h] is equivalent to the following simp here:
  simp (config := { decide := false }) only [Mathlib.Tactic.Zify.nat_cast_eq, Nat.cast_mul, Int.ofNat_ediv,
    Mathlib.Tactic.Qify.int_cast_eq, Int.cast_mul, Int.cast_ofNat]
  -- oops! h wasn't used. goal is:
  -- ⊢ ↑(↑n / ↑m) * ↑m = ↑n
  sorry

example (n m : ℕ) (h : m ∣ n): n / m * m = n := by
  -- if we remove a lemma, it works!
  simp (config := { decide := false }) only [Mathlib.Tactic.Zify.nat_cast_eq, Nat.cast_mul, --Int.ofNat_ediv,
    Mathlib.Tactic.Qify.int_cast_eq, Int.cast_mul, h, Nat.cast_div_charZero, Int.cast_ofNat]
  -- yay! h was used. goal is:
  -- ⊢ ↑n / ↑m * ↑m = ↑n
  sorry


Missing requirement: draftjs_sanitizer

Nevermind, the underscore confused me.

@umrashrf , sorry just wondering how you solved it? Just add that module in the requirements.txt?

@yxh10 you need to install the newest version of the dependencies. Whether by using pipenv install or pip install -r requirements.txt.

Thanks for replying. :) I installed those packages manually but will try
with the latest version of the dependencies later with my docker image.
On Mon, 19 Aug 2019 at 23:40, NyanKiyoshi<EMAIL_ADDRESS>wrote:

@yxh10 https://github.com/yxh10 you need to install the newest version
of the dependencies. Whether by using pipenv install or pip install -r
requirements.txt.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mirumee/saleor/issues/4587?email_source=notifications&email_token=AAAYUUH7JXTQ75KYUMCV3ZLQFKBEHA5CNFSM4II4S4XKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4STQRQ#issuecomment-522532934,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAYUUBQNTCT75IVQXJHRTDQFKBEHANCNFSM4II4S4XA
.


Broken Observatory UI

Version of Advanced Rocketry
AdvancedRocketry-1.12.2-1.4.0-88-universal.jar
Have you verified this is an issue in the latest unstable build
No, but I have checked the changelogs and didn't notice any fix listed.
Version of LibVulpes
LibVulpes-1.12.2-0.2.8-32-universal.jar
Version of Minecraft
Minecraft 1.12.2 (FTB Continuum 1.4.1)
Description of the problem
If you attempt to scan for asteroids you will get a nice long list in the Observatory that you can't scroll through at all. Every time you attempt to scroll it goes back to the top of the list, I assume every time the UI redraws. This means you just have to get lucky that a desired asteroid is in the top 4.
EDIT: Apparently part of the problem is Mouse Tweaks' Wheel Tweaks making it so you can't scroll using the mouse wheel but, there's still a problem with the clicking and dragging alternative option, even when all tweaks are disabled.

https://github.com/zmaster587/AdvancedRocketry/issues?utf8=✓&q=is%3Aissue+is%3Aopen+created%3A<2018-09-03+-label%3Aenhancement

This issue is still persisting, and the link you responded with is broken

Suggested to implement the possibility to scroll menus with the arrow keys to properly address this. That would circumvent all other collisions with other mods altering mouse behavior.


Change person model's full_name to first_name and last_name

Description

Frontend requires the full_name field to be split into first_name and last_name.
Acceptance Criteria

[ ] remove full_name and add first_name and last_name.
[ ] All existing person tests pass

Implementation details

First name should be required and last name should not.
Both should be strings.
Testing notes

LGTM ✅


JSDoc IntelliSense for anonymous functions doesn't include parameters

Testing #21031

Looking through the TypeScript implementation, it looks like this is by design currently but I agree that we should have consistent behavior for function expressions as well

Tracked upstream by https://github.com/Microsoft/TypeScript/issues/14280


Improve zsh extended history parsing

This patch fixes a segfault when .zsh_history contains commands starting with : and longer than 15 characters long.
Considering the history line:
:<PHONE_NUMBER>:0;:vspman epoll_ctl

The ranked item's line will be:
:vspman epoll_ctl

When building the prioritized history, we used to apply the zsh extended history offset if the line starts with : (and if the command is longer than 15, defined by ZSH_HISTORY_ITEM_OFFSET), which then makes the item point to:
tl

This makes the r->item pointer invalid, which causes the segfault observed in #408 within prioritized_history_destroy.

This patch prevents the same issue from arising again (even if the line is wrongly interpreted) since it avoids any pointer arithmetic between assignment and freeing.
Additionally, the patch also greatly improves the heuristics used in determining whether a line is of extended history format or not, since the non-extended format is also supported by zsh.

I tried your branch but there look to be issues there, such as hstr displaying empty history and more segfaults

@ostrolucky Thanks for trying it out. Could you give me some info about your OS and compiler? And if possible, any chance you could upload a backtrace taken from the segfaults as well?

@ostrolucky I just pushed a fix for what I think could be an issue with the patch, let me know if you get a chance to try it out :crossed_fingers:

Segfault seems gone, but history is still empty.

@ostrolucky Hmmm, any chance you could share even a small subset of your ~/.zsh_history file?

❯ tail -n 5 ~/.zsh_history
:<PHONE_NUMBER>:0;rg "FROM Transactions"
:<PHONE_NUMBER>:0;rg "FROM Transaction"
:<PHONE_NUMBER>:0;ssh aviation-testbox
:<PHONE_NUMBER>:0;tail ~/.zsh_history
:<PHONE_NUMBER>:0;tail -n 5 ~/.zsh_history

@ostrolucky Thanks. I'm not experiencing any issues with clang-10 on Fedora 32 though... The snippet of history you pasted is properly loaded... Could there be another command somewhere in your history that is causing some issue? Have you tried using a smaller ~/.zsh_history file just to test?

There is also another problem. I moved my .zsh_history and since then hh with your branch always returns segfaults. However, this stops being the case after I fill my history with more commands.
This is what lldb gives in such case:
Process 85220 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff69e14813 libsystem_platform.dylib`_platform_strcmp + 19
libsystem_platform.dylib`_platform_strcmp:
->  0x7fff69e14813 <+19>: movzbq (%rdi), %rax
    0x7fff69e14817 <+23>: movzbq (%rsi), %r8
    0x7fff69e1481b <+27>: incq   %rdi
    0x7fff69e1481e <+30>: incq   %rsi
Target 0: (hh) stopped.
(lldb) quit

This is the full content of .zsh_history in such case
❯ cat ~/.zsh_history
:<PHONE_NUMBER>:0;rm /usr/local/bin/hh
:<PHONE_NUMBER>:0;make && make install
:<PHONE_NUMBER>:0;hh
:<PHONE_NUMBER>:0;cat ~/.zsh_history
:<PHONE_NUMBER>:0;lldb /usr/local/bin/hh
:<PHONE_NUMBER>:0;tldr lldb
:<PHONE_NUMBER>:0;exit
:<PHONE_NUMBER>:0;tldr lldb
:<PHONE_NUMBER>:0;man lldb
:<PHONE_NUMBER>:0;lldb -o 'run' /usr/local/bin/hh
:<PHONE_NUMBER>:0;cat ~/.zsh_history

After some more things are recorded in file, hh starts working without segfault again, but again without showing anything. At that point, this is the content of a file:
❯ cat ~/.zsh_history
:<PHONE_NUMBER>:0;rm /usr/local/bin/hh
:<PHONE_NUMBER>:0;make && make install
:<PHONE_NUMBER>:0;lldb /usr/local/bin/hh
:<PHONE_NUMBER>:0;tldr lldb
:<PHONE_NUMBER>:0;man lldb
:<PHONE_NUMBER>:0;lldb -o 'run' /usr/local/bin/hh
:<PHONE_NUMBER>:0;hstr
:<PHONE_NUMBER>:0;h
:<PHONE_NUMBER>:0;echo wat
:<PHONE_NUMBER>:0;echo bar
:<PHONE_NUMBER>:0;echo baz
:<PHONE_NUMBER>:0;hh
:<PHONE_NUMBER>:0;echo barr
:<PHONE_NUMBER>:0;echo acaacac
:<PHONE_NUMBER>:0;exit
:<PHONE_NUMBER>:0;hh
:<PHONE_NUMBER>:0;cat ~/.zsh_history

If you would like, contact me on e-mail and I am willing to schedule some screen sharing session to help you troubleshoot this.

@ostrolucky I think I just noticed what went wrong in the patch a few minutes after pinging you. The last commit should fix it.

Good, now my hstr window is not empty, from inital look it seems everything is working now :)

Great! Now we just need @dvorka's eyes on this issue.

Another issue that this patch addresses by the way (and why the title refers to general "improvements" of zsh extended history parsing), is that it handles command records like this one:
:<PHONE_NUMBER>:6109;scan-view work/scans/2020-07-30-114451-3063582-1

Where the execution time isn't 0. Prior to this patch, hstr would show this command like so:
09;scan-view work/scans/2020-07-30-114451-3063582-1

And with this patch, we get the expected:
scan-view work/scans/2020-07-30-114451-3063582-1

Thanks for fixing the execution time issue. I use oh-my-zsh, which enables extended history, but I admittedly don't know much about it so I was wondering why my history looked weird under hstr. I have tested the patch and it works for me.

@chewi Glad this works for you too.
@dvorka Another ping on this one, I think it affects a lot of hstr users...

@thibaultcha I really appreciate all the effort you invested in fix and stabilization :+1: Busy days (in my daily job) recently. I will give this priority, will test it over weekend and release it if it works smoothly.
Thanks again for you help and interest in HSTR Thibault!

Nice one @thibaultcha, this fixed hstr for me, where it has recently started showing semicolons at the start of many lines when using a recent zsh. I've become dependent on hstr so thanks!

@thibaultcha I started to face the problems you fixed recently with extensive use of zsh on my computer(s). Big :+1: Thibault!

@dvorka Ha! Great, thanks for merging!

@dvorka Btw, who do we bug to update the distro packages? On Fedora I see hstr is a system package, and I'm not sure if we have to reach out to anyone or if you did already.


People, Places and other missing albums?

This app is probably the best Google Photos app I have found.  However,  it seems to only work within the constraint of albums I have manually created myself on my Google Photos site.  Why does it not show those automatically created albums Google nicely creates for us -- like the People album or Places album?

Hi,  Would love to add this in, however Google has limited what the old Picasa API allows use to pull.  See: https://developers.google.com/picasa-web/faq.
Official stance from Google:

If you are logged in as the owner of the content, you can retrieve all of the photos you've uploaded and albums you've created in Google Photos and Picasa Web Albums via the Picasa Web Albums Data API. There are some exceptions. For example, Google Photos "Shared Albums" are not available via this API. There are no plans to add support for all Google Photos features to the Picasa Web Albums Data API.

It's unfortunate. Maybe in the future!


Playlist function is not working

Reinstalling media-extended can solve the problem.
It is not clear why this happens.

Wait a moment.

If I open a sandbox vault and set up the plugins I need, the playlist function works fine. Then, I reload obsidian and the playlist function fails. This is really strange.

I used git to track file changes and found that during the reload process, vault did not generate any file changes.

If I disable media-extended and then re-enable it, the playlist will take effect again.

Knowing this, we already have a fix. Download the Lazy Plugin Loader plugin and give media-extended a short delay of one second. Then the playlist function will be normal.

I should also create a new issue in media-extended.


Identify Synthetic public-use data

Conversion from Synthea CSV to OMOP CDM.
The data we plan to use will likely be https://ohdsi.github.io/ETL-Synthea/ and expertise in R will come in handy to get data loaded.
Infrastructure set up is handled in separate issue. This task can occur concurrently as we can implement this in Hematology Server that already has OHDSI Tools and other infrastructure ready.

Task marked done in the Project, so closing this issue


issue#1

Fix I2C reset issue
First Issue:
The i2c_reset signal, which is generated in the top/u_clkrst_gen module, is based on the srst signal from the top/u_clkrst_gen/u_pll_top module. Since the srst signal does not occur at the very beginning, the i2c_reset signal is also delayed, as shown in the attached image. The image illustrates that as a consequence, i2c_sda and i2c_scl start, but then halt due to the reset.
The solution would be to ensure that i2c_reset is initially set to 0 and remains 0 until the rst_delay_cnt counter reaches 4 (since the I2C is enabled only after 4 seconds from the system power-up).
Second Issue:
When the reset signal in the top/u_i2c module goes to 0, data transmission on the I2C bus begins. However, at that moment, the value of the slave address, which is the first data transmitted via I2C, is set to an undefined value. Consequently, the setting of the slave_address_plus_rw (slave address plus read/write) signal is delayed by one data transmission cycle via I2C, which is not desirable. As a result, the first slave address written is 0.
To solve this second problem, the slave address should be set before the start of the I2C section. One approach is to introduce an additional input signal (which can be cam_en, as it occurs before the i2c_reset, as shown in the image).

Changes in the branch issue#1 have resolved the first part of the problem, i.e. the I2C section no longer starts before the srst signal. This was achieved by inverting the logic of the i2c_reset. Simulation results confirm that this part is now resolved.
However, there remains an issue highlighted in the image: the first sent slave address is 0. This is further illustrated in the second image, where it is evident that the second register has the correct slave address.

The issue of the first slave address being 0 has been resolved by setting slave_address as the parameter I2C_SLAVE_ADDR in the top/u_i2c module, ensuring it is defined from the start. The solution is evident from the image below.


tiva/lm3s6965-ek: Add module/elf definitions

Basically a copy-and-paste from spresense.
But I added -mlong-calls for ELF to avoid out of range relocations.
(Isn't it necessary for spresense?)

I am the copyright holder of the file that you copied.  I grant you permission to change the license header to apache 2.0.
This PR cannot come into the repository unless all new files have the Apache 2.0 license.

Sorry, didn't mean to close that.  I hit the wrong button.

@patacongo
the file's original copyright is:

Copyright 2019 Sony Home Entertainment & Sound Products Inc.
Author: Masayuki Ishikawa<EMAIL_ADDRESS>

I wrote all of the ELF module linker scripts.  I don't know why my copyright was changed on this one.  It should not have been.  You can take one of the other versions fo the same file which has my copyright.  It cannot come in without an Apache 2.0  license.

@patacongo done. thank you.


Fix crate version in getting_started.md

Getting started guide refers to version 0.6, but 0.7 is live on crates.io
Pointed out in #285

if you rebase, CI should be green

Getting started guide refers to version 0.6, but 0.7 is live on crates.io
Pointed out in https://github.com/Electron100/butane/issues/285


bme680 support

added support for the BME680 sensor

Thanks for this, I will review over the next few days


More robust solution to execute queueing

For #8322
This implements the 'delayed' future so that it's impossible to send more than one requestExecute at a time.
Tested locally and it works but doing this separately so that it can be reverted if it causes something to break.

Codecov Report

Merging #8651 (020fdc5) into main (22e2ed6) will increase coverage by 0%.
The diff coverage is 60%.

@@          Coverage Diff           @@
##            main   #8651    +/-   ##
======================================
  Coverage     71%     71%
======================================
  Files        382     383     +1
  Lines      24523   24607    +84
  Branches    3767    3787    +20
======================================
+ Hits       17499   17604   +105
+ Misses      5480    5468    -12
+ Partials    1544    1535     -9

Impacted Files
Coverage Δ

src/client/datascience/delayedFutureExecute.ts
54% <54%> (ø)

src/client/datascience/baseJupyterSession.ts
76% <100%> (+1%)
:arrow_up:

...t/datascience/notebook/vscodeNotebookController.ts
79% <0%> (-1%)
:arrow_down:

src/client/datascience/jupyter/kernels/kernel.ts
75% <0%> (+<1%)
:arrow_up:

src/client/datascience/serviceRegistry.ts
98% <0%> (+<1%)
:arrow_up:

src/client/activation/activationManager.ts
56% <0%> (+1%)
:arrow_up:

src/client/datascience/raw-kernel/rawSocket.ts
84% <0%> (+1%)
:arrow_up:

src/client/extensionActivation.ts
96% <0%> (+2%)
:arrow_up:

...upyter/interpreter/jupyterInterpreterStateStore.ts
94% <0%> (+2%)
:arrow_up:

.../datascience/notebook/notebookControllerManager.ts
79% <0%> (+3%)
:arrow_up:

... and 9 more

A restart test seems to be failing on all versions. Not sure why. I'm investigating now (hopefully it repros locally)


update cert name to "Front End Development Libraries Certificate"

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #42502

Thanks for the PR. We already have a work in progress PR for this. We would encourage you to look at some of out other help-wanted issues.


Xamarin Android Crashlytics build Errors

i have the similar issue i am using VS 2017 15.9.21 and Xamarin.Android.Crashlytics version <IP_ADDRESS>
for my Xamarin.Android project I receive build errors.
The same setup was working at my workstation desktop but now i am laptop and haven't made any changes to the solution
i have supporting packages as follows
Xamarin.Android.Crashlytics- package version <IP_ADDRESS>
Xamarin.Android.Crashlytics.Answers - - package version 1.4.2
Xamarin.Android.Crashlytics.Beta - package version 1.2.9
Xamarin.Android.Crashlytics.Core - package version 2.6.3
Xamarin.Android.Fabric- package version 1.4.3
and now i am getting build issues as shown in the screen shot

anyone knows about this how i can resolve ? If i uninstall all these packages i.e crashlytics supporting.
then app will works fine but i need to include crashlytics

@cmnagaraj610 thanks for the feedback.
Copy text and paste it here, please.
Save images for Instagram.

Error details

Error		Download failed. Please download https://maven.google.com/com/crashlytics/sdk/android/crashlytics/2.9.4/crashlytics-2.9.4.aar to a file called Local project path \XamarinBuildDownloadCache\crashlytics-2.9.4..aar.

Error		Download failed. Please download https://maven.google.com/com/crashlytics/sdk/android/beta/1.2.9/beta-1.2.9.aar to a file called Local project path \XamarinBuildDownloadCache\crashlyticsbeta-1.2.9..aar.

Error		Download failed. Please download https://maven.google.com/com/crashlytics/sdk/android/answers/1.4.2/answers-1.4.2.aar to a file called  Local project path \XamarinBuildDownloadCache\crashlyticsanswers-1.4.2..aar.

We are not allowed to host binaries (jars, aars, zips) in our repo, so in order to do binding those must be downloaded and this is done in cake script with target externals (in most cases). So:
dotnet cake -t=externals

or to run complete build
dotnet cake -t=ci

It is all here: https://github.com/xamarin/XamarinComponents#building
Closing this one, because it is not an issue.


added Custom Types Editor Feature

This is a hacky and probably very incomplete implementation to respect the Custom Type Editor in Tiled.
I used SuperTiled2Unity in Unity, which uses the Custom Types in Tiled. So implemented it here. It works cascading, so it will first look up the property in Custom Type and then local override.
It is only implemented in C# and would need an implementation in GDScript. I don't mind if you deny that pull request and make your own implementation I made a fork to stay on a par with your version.

Showing Custom Types in Tiled

You need to export the object types as json in Tiled and set it there as include.

Know the Tiled Custom Types Editor zero so far.
-> I first want to get clarity on what this is all about and then study your additions and changes.
Might take a while, since other things have priority at the moment.

I'm glad you understand the usefulness of that feature.
If you want you can annotate changes and I might have time to make it merge able. Or you have time some day or something. For now we can just let it sit here. I'm using it for a project so I might occasionally come back to it and fix things.

After a bit familiarizing myself with all that, I'm thinking of using the .tiled-project file as the source of the custom types instead of an exported .json or .xml file. Since the Custom Types Editor is only available when a project file is used, the file must exist.
Advantages:

No export necessary
so there is no ambiguity which export format was chosen
File also contains the complete info about the scope of a property class.
Last but not least :-) File is a json dictionary, therefore no array variant is required for reading the file

I think I can implement this in the course of the next week.

This sounds very great!
tbh, the workflow I implemented was from tiled2unity and I never questioned it. It would indeed be very cool, if you can extract the information from the tiled-project file directly.
I'm looking forward to the next release version then! Feel free to close this pull request, without merging, when you implemented your own version.

Just released Custom Types support with v1.6.0


Starting a video chat freezes webview video in background in ios

Hey, i'm building an app where i have a webview that shows a twitch stream , and i wanted to add an ability for people to watch the stream toghether through the app. On android everything seems to be working fine , however on IOS when i initialize the agora engine and enable the video it takes like 10 - 15 seconed for the permission pop up to apper and also the entire app freezes comletley, after the user agreed to the mic and camera use the app itself unfreeze but the stream in the webview stays frozen, i tried reloading the webview and to create abrand new app with just agora and a webview neither helped to fix the issue.

you can try setParameters("{\"che.audio.keep.audiosession\":true}")

@LichKing-2234 didn't work unfortunately

it hard to resolve, I have no idea about it

I think this is the iOS system behaves.

Closing due to inactivity


Fix Edit Button Alignment (#4)

The edit button is now aligned to the right properly next to the delete button

Looks great! I also just noticed that the icons aren't centred inside the buttons. This is something I fixed with the delete button in the create/edit filter group modal dialog, so I can implement that fix here.

Here's the fix let me know if this is good


Fix user configured resources for pgbouncer deployment

Add limits too

Add limits too

That adds everything under resources, only if they are defined. Pachd has the same thing here


Feature: Twitter bot

Same as the Discord bot except Twitter.

This looks like a good backend: https://github.com/FeedHive/twitter-api-client
Here is the API: https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md
Looks like the two methods needed are these:

https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md#twitterclienttweetsstatusesupdateparameters
https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md#twitterclienttweetssearchparameters

Technically it could all go in the Discord bot codebase. We can search for #webatweet and run the regular bot's code.
I have the Twitter credentials for out application ready, with:

API key
API secret key
Access token
Access token secret

Let me know if it's needed.

This looks like a good backend: https://github.com/FeedHive/twitter-api-client
Here is the API: https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md
Looks like the two methods needed are these:

https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md#twitterclienttweetsstatusesupdateparameters
https://github.com/FeedHive/twitter-api-client/blob/master/REFERENCES.md#twitterclienttweetssearchparameters

Technically it could all go in the Discord bot codebase. We can search for #webatweet and run the regular bot's code.
I have the Twitter credentials for out application ready, with:

API key
API secret key
Access token
Access token secret

Let me know if it's needed.

https://github.com/webaverse/ethereum-bot/pull/10

https://github.com/webaverse/ethereum-bot/pull/10

We also have https://twitter.com/webatweet, but I don't know if that is a good name choice. It's just needed for the above PR.

We also have https://twitter.com/webatweet, but I don't know if that is a good name choice. It's just needed for the above PR.

ready, just needs api keys and better branding


Fresh install bug

Acknowledge the following

[x] I carefully read and followed the Getting Started guide.
[x] I read through FAQ and searched through the past issues, none of which addressed my issue.
[x] The issue I am raising is a potential bug in al-folio and not just a usage question.  [For usage questions, please post in the Discussions instead of raising an issue.]

Describe the bug
Error when local running bundle install
To Reproduce
bundle install
In Gemfile:
classifier-reborn was resolved to 2.3.0, which depends on
fast-stemmer
System (please complete the following information):

OS: WSL2
Browser (and its version) [e.g. chrome, safari]
Ruby version [e.g. 3.0.2]

Additional context
Add any other context about the problem here.

Solved by running: sudo apt-get install ruby-full build-essential zlib1g-dev