How to handle moustache app macro

What do you recommend to handle a DSL like the moustache app macro?
The macro has four usages:

wrap a Ring handler,
to define routes,
to dispatch on HTTP methods
and to render plain text

Usage 1 (wrapping handler with middleware) is probably :flow-body
Usages 2 and 3 (routes and methods) are :pair-fn
Usage 4 is probably :hang-body

I don't have personal experience with moustache, so I've only looked at the walkthrough in the readme.  I've experimented with formatting the gist of the walkthrough, and I think that defining app as :pair-fn makes the most sense.  If you are using lein-zprint, you can then put a ;!zprint directive prior to any cases where :pair-fn doesn't work well to define app as something else.   That said, defining app as :pair-fn formatted the gist of the walkthrough at least as well (or in some cases better) than it was formatted by hand, so I don't think you are going to go far wrong with  that approach.

Okay, thanks Kim! I haven't used lein-zprint so I'll look into that.

@kkinnear I think to do this right I need a variant of options-fn that works for fn-map instead of just vectors
Consider a few examples:
(m/app [route] handler
       [route] handler
       [route] handler)

That works fine with :pair-fn. Similarly dispatching on HTTP methods:
(m/app :get  (m/app [route] handler
                    [route] handler)
       :post (m/app [route] handler
                    [route] handler))

However as soon as we throw a middleware in there, it's all confused:
(m/app middle1 [route]
       handler [route]
       handler)

and there can be an arbitrary number of middlewares:
(m/app middle1 middle2
       middle3 middle4
       middle5 [route]
       handler [route]
       handler)

Ideally that last example would be one of these instead:

(m/app middle1
       middle2
       middle3
       middle4
       middle5
       [route] handler
       [route] handler)

(m/app middle1 middle2 middle3 middle4 middle5
       [route] handler
       [route] handler)

I think in order to achieve this, I would need to be able to inspect the params to set the appropriate function classification. Additionally, it would be helpful to be able to use an arbitrary arg number, for example :arg5-pair (which shouldn't really be that hard if you want to make it completely dynamic, for unknown function classifications, you could convert to a string, match against a pattern and extract the number)
What do you think?

By the way, if you wouldn't mind re-opening this issue, I'd appreciate that, so it doesn't get lost

Thanks for the examples.  I see your point.  The "ideally the last example would be one of these" versions look a great deal like constant pairing, where I look backwards from the end of a list, and if there are constants in positions n-1, n-3, etc., I pair up those last things.
One approach would be to allow you to configure your own definition of "constant", which right now is a number, string, or keyword.  Then for m/app you could redefine constant inside that form in any way you want.  Probably a vector, which would allow the routes to pair up with the handlers.
A more general approach would be as you suggested, to support options-fn for lists.  For performance, you would only define one for the top level m/app, I think.
The hardest part of what you suggest would actually be the :arg-n generalization.  It sounds easy, but I suspect that it isn't -- not that I've tried to implement it yet.  It is challenging in part because things like comments can occur in between arguments, in part because the "arguments" can themselves be arbitrarily complex expressions which may not fit well on the current line.
It might be better to allow an options-fn to specify the number of things that should be paired up at the end of a list (like constant pairing, but without the checks for constants).  Then the rest of the list would end up like the left-hand of your two suggested outcomes. (Impressive use of markdown to get the two examples side by side, I didn't know you could do that!)
Anyway, I've written all of this down so that when I get back to it, I can recover my context.  I have several things to implement first, and the time to do them is in moderately short supply this time of year.  I will put this on the list of things to do and work on it as soon as I can release the current things. Thank you for the suggestion!

Oh, constant pairing looks interesting. No matter how many times I've been through the doc, there's always something I haven't seen yet.

Then for m/app you could redefine constant inside that form in any way you want. Probably a vector, which would allow the routes to pair up with the handlers.
...
It might be better to allow an options-fn to specify the number of things that should be paired up at the end of a list (like constant pairing, but without the checks for constants). Then the rest of the list would end up like the left-hand of your two suggested outcomes.

Either option sounds good to me! Thanks for considering it.

@kkinnear Just wanted to check back, has anything changed in zprint since last year, that would make it easier to configure the definition of "constant" for constant pairing? Rereading this issue, it seems like if I could treat vectors as constants, then I could really get the m/app macro to format properly.

Thanks for the reminder.  I'm embarrassed to say that this slipped off my radar despite being an open issue.  I'm really sorry that I didn't address this sooner!  The good news is that the only important thing I'm working on right now is how to handle Windows line endings, so something more creative -- like this issue -- would be most welcome.  I'll see what I can do and let you know, sooner than 10 months this time.  I'm really glad we had this conversation late last year and I wrote it down so I don't have to start from scratch!  I'm excited to work on this!

So, here is what I've prototyped so far to solve this issue.  I'd like your feedback if this would actually work for you before I commit into the next release.
This approach allows you to supply a function to decide what is a "constant", such that constant-pairing will pair up things from the end of a list for as far up (back) as there are "constants" for every other element.
This first example says that vectors are constants, so they are paired up.  However, this also makes the test (which I added, and isn't something that you would do, of course) for standard constant pairing fail:
 (czprint mapp1 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-fn vector?}}]}})
(m/app middle1
       middle2
       middle3
       (this is
             "a"
             test
             "this"
             is
             "only a"
             test)
       middle4
       middle5
       [route] handler
       [route] handler)

Here is the same approach, but I've fixed up the options map in the :fn-map to only consider vectors as "constants" for the top level of m/app, and then go back to normal constant pairing:
(czprint mapp1 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-fn vector?} :next-inner {:list {:constant-fn nil}}}]}})
(m/app middle1
       middle2
       middle3
       (this is
             "a" test
             "this" is
             "only a" test)
       middle4
       middle5
       [route] handler
       [route] handler)

This works for :constant-fn functions that you write too:
(czprint mapp {:parse-string? true :width 40 :list {:constant-fn #(vector? %)}})
(m/app middle1
       middle2
       middle3
       middle4
       middle5
       [route] handler
       [route] handler)

To generalize a bit for the dispatching on http methods:
(czprint mapp2 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-fn #(or (vector? %) (keyword? %))}}]}})
(m/app :get (m/app [route] handler
                   [route] handler)
       :post (m/app [route] handler
                    [route] handler))

To turn it off so that the handlers don't get funny constant pairing:
(czprint mapp2 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-fn #(or (vector? %) (keyword? %))} :next-inner {:list {:constant-fn nil}}}]}})
(m/app :get (m/app [route] handler
                   [route] handler)
       :post (m/app [route] handler
                    [route] handler))

A more complex example with both handlers and http dispatching:
(czprint mapp3 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-fn #(or (vector? %) (keyword? %))} :next-inner {:list {:constant-fn nil}}}]}})
(m/app :get (m/app middle1
                   middle2
                   middle3
                   [route] handler
                   [route] handler)
       :post (m/app middle
                    of
                    the
                    road
                    [route] handler
                    [route] handler))

The standard constant-pairing requires two things before it kicks in, which all of your examples have, but here is what is necessary to make the pairing work for even a single pair:
(czprint mapp4 {:parse-string? true :width 40 :fn-map {"app" [:none {:list {:constant-pair-min 1 :constant-fn #(or (vector? %) (keyword? %))} :next-inner {:list {:constant-fn nil :constant-pair-min 2}}}]}})
(m/app :get (m/app middle1
                   middle2
                   middle3
                   [route] handler
                   [route] handler))

To me, this looks like it would solve the issue that you have raised.
But this only works to pair things up if you have vectors (or something identifiable as a "constant" by a function that you supply) as the n-1, n-3, ... elements of the list with m/app.   This works for the examples that you have given, above.
The question is -- would this work in the more general case for you?

Wow Kim! Pretty sure this is perfect. Can't wait to take it for a spin. This all works in .zprintrc, right?

For sure, this will work in .zprintrc.  I'm also planning to define a :style which includes it, currently named :moustache.
Here is the current :style that I'm working with.  I ended up extending the existing :constant-pair constant definitions
by adding vectors, instead of going for just keywords and vectors.
      :moustache {:fn-map {"app" [:none
                                  {:list {:constant-pair-min 1,
                                          :constant-pair-fn #(or (keyword? %)
                                                                 (string? %)
                                                                 (number? %)
                                                                 (= true %)
                                                                 (= false %)
                                                                 (vector? %))},
                                   :next-inner {:list {:constant-pair-min 4,
                                                       :constant-pair-fn
                                                         nil}}}]}},

It seemed like that might be a touch more generally useful. I think that will still give you what you want as well.

Looks great to me. When can I try it? :smile:

Need to finish the line endings work, but that is it for this release.  I'm thinking that I will do 1.0.2 fairly soon, possibly this coming weekend, but more likely the next weekend.

This is now available in 1.0.2.  See the :moustache style, as well as the pointer to the documentation for "more flexible constant pairing" in the "recent additions" section of the readme (right at the beginning).

@kkinnear Thank you! This is great. Thanks again for all your work on this.
I'm just stumbling on one thing, now... If I want to combine this with {:justify? true}, just for the app macro, is that hard to do? I've tried a few things, and the only way I've succeeded is :pair {:justify? true} in .zprintrc, but then it applies everywhere:
{:pair {:justify? true}
 :style [:moustache :respect-bl]}

I was able to make it work with the file comment API, but I'm pretty sure I'd like this to be the default for the app macro in this project:
;!zprint {:format :next :pair {:justify? true}}

If I try to add the style to my $PROJECT/.zprint.edn then zprint ignores my configuration entirely:
{:style [:moustache :respect-bl]
 :style-map
   {:moustache
      {:fn-map {"app" [:none
                       {:list {:constant-pair-min 1
                               :constant-pair-fn #(or (keyword? %)
                                                      (string? %)
                                                      (number? %)
                                                      (= true %)
                                                      (= false %)
                                                      (vector? %))}
                        :pair {:justify? true}
                        :next-inner
                          {:list {:constant-pair-min 4 :constant-pair-fn nil}
                           :pair {:justify? false}}}]}}}}

What would you suggest?

If this is hard, please don't worry about it. It might be enough to use the file comment API (which wouldn't have sufficed for the rest of this issue)

I'm giving this a look now, I'll let you know what I figure out.

This is a really tricky one.  You contributed to the issue with fn's in .zprintrc files, #124, and when I "fixed" that, I left out the graalVM binaries (for reasons that I haven't had a chance to review).  So, that's why when you try to redefine the :constant-pair-fn it isn't going to work if you are using the pre-built binaries.  Period.  If you are using lein zprint, then the #( ...) function construction won't work, but the (fn [x] (or ...)) construction might well work fine.  I didn't test that because I was assuming that you were using the pre-build binaries.
I will review why I sidestepped fixing the graalVM binaries when loading functions in the next day or so, but whatever I find out isn't going to solve your problem in the short term.
Another thing that (if you could redefine the functions) would be getting you is:

Note that styles are applied before the rest of the elements of a options map, so that you can override elements of the style that you wish to change by specifying an explicit element in the options map.

so that redefining a style and then trying to apply (i.e., use) it is problematic (i.e, doesn't work).
So, while I don't have a solution to these problems, I have something that is better than nothing, but not perfect (and I'm not entirely sure why at this juncture, actually).
If you do this in your ~/.zprintrc:
{:fn-map {"app" [:none
                 {:next-inner {:list
                                 {:constant-pair-fn nil, :constant-pair-min 4},
                               :pair {:justify? false}},
                  :style [:moustache :justified]}]}}

you will get justification at the top level use of app, but not on any nested invocations of app.
If you do this:
{:fn-map {"app" [:none {:style [:moustache :justified]}]}}

you will get justification in all of the uses of app, but also in all of the stuff inside of the uses of app, which may not be what you want.
At this stage, I don't have a way to get justification only in the top levels of app, though your re-definition of :moustache should work fine if it could be read-in.  It seems to work fine when I try it at the repl, but there is no way for you to input it using the graalVM binaries.
I will look at these things:

Why I didn't fix the graalVM binaries to be able to load functions.
Why doesn't the first ~/.zprintrc example above do what I expect? (That is, justify all of the top levels of app, and nothing else.)
Augment the definition of the:moustache style with {:pair {:justifiy? true}} and then turn it off with :next-inner, since that is actually what you wanted in the first place.
See if I can figure out how to redefine a style and then apply it and have that work in the .zprintrc.

I could probably do 3, above, in the next two days if that is important to you.   There is an overhead to every release in testing, the steps of which are automated but the overall process is not, so it is a couple of hours to release a new version even when I've just done it.  Which I will do if it would make things a lot better for you.  Otherwise, I'll try to figure out the larger picture and fix what I can, and then extend the -w switch, and then release all of that together (which is probably a couple of weeks, I would guess).

My current thinking is to move to sci for loading the config option maps, which will define functions with either (fn [] ...) or #(... %), and execute them --theoretically even with graalVM.  Which seems like a win.  I need to try it, with graalVM for sure, to know if this is really a solution.  But it looks promising from a first try at the REPL.

I wondered if this was related to #124. I hadn't heard of it before, but sci looks like a good fit!

Augment the definition of the :moustache style with {:pair {:justify? true}} and then turn it off with :next-inner, since that is actually what you wanted in the first place.

I think that makes sense. I'm sorry I didn't realize I wanted this earlier!

I could probably do 3, above, in the next two days if that is important to you.

That's a kind offer, but no need to rush. This is already usable for me as-is, and I'll just take advantage of the update when it's available.

So, I did sci for loading option maps.  But all of that should not matter, now, since I have (finally) released 1.1.0.  This has the :mustache style that I think you want built-in.  I think it does what you want.  If not, let me know.  Given that I've restructured not only the actual :mustache style by splitting it into two parts, but also the way that one style can employ another, and that you can define and use a style in the same .zprintrc, it should be relatively straightforward to get you the style you want even if the built-in one is still not quite right.
I've put a lot of effort into making all of this work, so if it isn't (yet) quite right, please let me know!
Thanks for your patience, and for also requesting an interesting capability.  As you can see, it has caused me to clean up a number of issues around styles and option maps, which was really good to do!

So, I did sci for loading option maps.  But all of that should not matter, now, since I have (finally) released 1.1.0.  This has the :mustache style that I think you want built-in.  I think it does what you want.  If not, let me know.  Given that I've restructured not only the actual :mustache style by splitting it into two parts, but also the way that one style can employ another, and that you can define and use a style in the same .zprintrc, it should be relatively straightforward to get you the style you want even if the built-in one is still not quite right.
I've put a lot of effort into making all of this work, so if it isn't (yet) quite right, please let me know!
Thanks for your patience, and for also requesting an interesting capability.  As you can see, it has caused me to clean up a number of issues around styles and option maps, which was really good to do!

I just took it for a spin, Kim, and it looks amazing. Thank you!!

I just took it for a spin, Kim, and it looks amazing. Thank you!!


feat: Use generics with Data::collection

As shown in the types/Collection.php tests, this PR ensures that the return types of Data::collection use generics.
Before, SimpleData::collection($items) would return a plain DataCollection.
Now, it returns DataCollection<array-key, SimpleData>.
Building upon #184, and makes sure that the correct generic types are returned when passing paginators.
$users = User::paginate();
$collection = UserData::collection($users); // PaginatedDataCollection<array-key, UserData>

$users = User::cursorPaginate();
$collection = UserData::collection($users); // CursorPaginatedDataCollection<array-key, UserData>

This allows you to make stricter assertions in your project.

Cool, thanks!


Usage section refactoring

@martinRenou I find it more intuitive to have the kernel implementation in a dedicated page rather than having it at the same level as the usage page and link to different parts of the implementation. Let me know what yuou think.

Sorry this needs a rebase since I made some language changes.

I totally agree this is really clearer like that

:tada:


Sample.apk fails to install

I downloaded the sample.apk file to install it on my device using ADB but it failed with the following error:
INSTALL_PARSE_FAILED_NO_CERTIFICATES
Is it properly signed with a release key?

Hmm, that's weird. Yeah, a keystore is used to sign it.

Added a new APK which isn't signed at all. A debug APK should install just fine.


Return promises to make use of async/await

Currently there are too many callbacks (ex: search with polling), it is kind of confusing users on handling. Can we just return promises and users can use the modern async/await to get the information required?
I'm being stumbled upon where I've to stream the preview results whenever it is available. This would be a great addition and will improve DX.

Hi @email2vimalraj thanks for your issue. This is going to be a significant refactor throughout the SDK which I'm not sure we're planning on taking on at this time. If we put investment into this SDK, we'll bring in modern JS features such as async/await.

Hi @shakeelmohamed , thanks for quickly looking at the issue. Can we at least keep this issue open and track?
So that we can know if someone voting for the issue and can prioritize.
Please let me know what you think.

@PixnBits we appreciate your concern and are well aware of the shortcomings of this SDK. As very small team of SDK maintainers we have to constantly reprioritize what we're working on in order to  maximize customer value. Sometimes we're going to fall short. We more than welcome any pull requests if you or anyone else is interested in helping to improve our developer tooling for the Splunk developer community. We are absolutely doing the best we can and we thank you for your patience.
I've re-opened the issue for tracking purposes as @email2vimalraj suggested.

@PixnBits we appreciate your concern and are well aware of the shortcomings of this SDK. As very small team of SDK maintainers we have to constantly reprioritize what we're working on in order to maximize customer value. Sometimes we're going to fall short. We more than welcome any pull requests if you or anyone else is interested in helping to improve our developer tooling for the Splunk developer community. We are absolutely doing the best we can and we thank you for your patience.
I've re-opened the issue for tracking purposes as @email2vimalraj suggested.

I took a shot at rewriting it on typescript and in the process decided to use async/await and separate them into modules/packages. Started with ModularInputs as that what i was using the sdk for. It needs some cleanup and testing but you can use it/adapt it if you want to.
https://github.com/jose-pr/splunkts

Promise support has been added in Javascript SDK v2.0.0


[Community Extensions] Random selection of extension (decided by jekyll sample) on the bar

This is to be reviewed by the design team.

The selection should be done in JS – I'll pass this on to Max.

Just curiosity, why JS side?
I think it's OK (better?) to have a given page have a fixed list (= refreshing will not scramble them), and that list to be determined at build time (so rebuilding the website will actually change the list).
Someone else picking this up is great, thanks!

The website builds are spaced out in time very randomly, sometimes we deploy every few minutes, sometimes there are no updates for days.


pkg/build: enable RedZone on FreeBSD

Before sending a pull request, please review Contribution Guidelines:
https://github.com/google/syzkaller/blob/master/docs/contributing.md

Note that KASAN will give similar checking (and more) once we create a syz-manager config with it enabled. I'm just waiting for an LLVM update to land in main first, right now make kernel-toolchain won't rebuild clang with KASAN support, and we need that for syzbot.
I don't see any issue with enabling this in non-KASAN kernels though.

I agree, that we should move to KASAN when it is available. But until we have that, and RedZone helped me to find issues right now, I think it is an acceptable interim step.


[BUG]: prompt_examples/*.wav missing in NaturalSpeech2

Describe the bug
when use NaturalSpeech2 inference, it report RuntimeError: not found NaturalSpeech2/prompt_example/ref_audio.wav.
same as https://github.com/open-mmlab/Amphion/issues/114, but in NaturalSpeech2, not VALLE. I think the problem comes from the .gitignore as well, it ignores all *.wav expect prompt_examples in VALLE now.
How To Reproduce
follow https://huggingface.co/amphion/naturalspeech2_libritts .
Expected behavior
such as:
RuntimeError: Failed to open the input "~/amphion/egs/tts/NaturalSpeech2/prompt_example/ref_audio.wav" (No such file or directory).

Oh I get it, not a problem. Just download from the demo page https://speechresearch.github.io/naturalspeech2/ or use own voice. But better provide a default example. Thanks~

Thanks for your attention and support towards our work. I will close this issue. If you have any further questions about prompt_examples, please feel free to re-open this issue. We are glad to follow up!


achene fruit (PO:0030107)

achene (PO:0030107)
Proposed def'n:
A fruit (PO:0009001) derived from a single carpel (PO:0009030) and is composed of a single fruit locule (PO:0025270) and a single seed (PO:0009010), which is attached to the dry, indehiscent pericarp (PO:0009084) at a single point at maturity.
Synonyms: akene (exact)
Fruit #76

Revised achene (PO:0030107) to achene fruit
Previous def'n:
A fruit (PO:0009001) derived from a single carpel (PO:0009030) and is composed of a single fruit locule (PO:0025270) and a single seed (PO:0009010), which is attached to the dry, indehiscent pericarp (PO:0009084) at a single point at maturity.
Revised def'n:
A fruit (PO:0009001) which develops from a carpel (PO:0009030) and comprises a dry exocarp (PO:0009085), dry mesocarp (PO:0009087), and dry endocarp (PO:0009086) that are fused to a seed coat (PO:0009088) at a single point.
Revised comment:
Commonly referenced fruit types such as accessory or multiple fruits (comprised of accrescent receptacle or infructescence tissue) containing as parts achenes are here treated as achene. For example, when annotating for a gene involved in strawberry development, any gene of interest that is involved in the development of the receptacle tissue would be mapped to receptacle (PO:0009064); genes involved in sepal (PO:0009031) persistence or accrescence would map to sepal (PO:0009031), and those involved in fruit characteristics would be mapped to achene (PO:0030107). Examples: sunflower (Helianthus annuus), strawberry (Fragaria vesca), fig (Ficus carica), and marijuana (Cannabis sativa).

Closing issue for achene fruit (PO:0030107)
def'n: A fruit (PO:0009001) which develops from a carpel (PO:0009030) or gyneocium (PO:0009062) and at maturity comprises a dry exocarp (PO:0009085), a dry mesocarp (PO:0009087), and a dry endocarp (PO:0009086) that are connected to a seed coat (PO:0009088) by a funicle (PO:0020006).
comment: Plant structures commonly referred to as ‘accessory’ (such as strawberry) or multiple fruits (such as figs..) which are comprised of accrescent receptacle (PO:0009064) or infructescence (PO:0006342) tissue, contain as parts achene fruits (PO:0030107). For example, when annotating for a gene involved in strawberry development, any gene of interest that is involved in the development of the receptacle tissue would be mapped to receptacle (PO:0009064); genes involved in sepal (PO:0009031) persistence or accrescence would map to sepal (PO:0009031), and those involved in fruit characteristics would be mapped to achene (PO:0030107). Examples: sunflower (Helianthus annuus), strawberry (Fragaria spp.), fig (Ficus sp.), and marijuana (Cannabis sativa).
synonyms: achene (exact), achäne (exact, German), akene (exact), aquenio (exact, Spanish), indehiscent fruit (broad)


Footer social links are not working. Please assign to me I would like tow work

@devnullone can u give links of facebook, twitter, and Instagram that u want to add?

@devnullone you already added? in production I can see it is working.

@devnullone you already added? in production I can see it is working.
Yes it already done!
Thanks


HTML Reporting for OpenSCAP

I added an option to display an HTML report for an OpenSCAP scan.  It is served at <serve_path>/api/v1/openscap-report.
I thought this would be a convenient option.

@enoodle @moolitayer @pweil- can you review?

LGTM :+1:

@pweil- I agree with your suggestions.  I made the minor changes and just committed,

Latest LGTM, I think this is ready for squash.

@pweil- @kevensen I agree we should squash.

@kevensen I'm curios about your use case with image-inspector, can you describe it shortly?

@moolitayer Certainly.  I understand that ManageIQ/CloudForms invokes the image-inspector during a SmartState analysis to generate the OpenScap report.  I am creating automation workflows (state machines) to interact with OpenShift.  The custom state machine will invoke the image-inspector, generate the OpenScap report (including the HTML) and e-mail the report.  At least, that's my desire.

@kevensen thanks that's interesting.
BTW are you running it as an OpenShift Pod?

@moolitayer - I sure am!

@kevensen to be clear, in order to merge this we're waiting for you to squash the patches in 1.

@simon3z - Gotcha.  Squashed.

@simon3z fyi it would be nice to maintain a basic pod definition as part of image-inspector

@simon3z - Squashed


Entire column of keys not working Fn, Shift, Esc, Tab, Plus/Equals.

Hello, I've loved my Advantage 360 ZMK keyboard so far, but today an entire column of keys stopped working.
I use firmware version 3.0, but my: Fn, Shift, Esc, Tab, Plus/Equals (can't type it) no longer respond to keypresses.  I'm using Ventura 13.5.2.
Even when I press the fn key the LED no longer changes color.
All over keys work perfectly.
Please advise if there is some software change to be made or this has been seen before.

This sounds like a hardware issue. Please open a ticket with Kinesis support on the website. https://kinesis-ergo.com/support/kb360pro/#ticket

Just following up on this, have you had this issue sorted?

@rustyconover We have received your ticket and will handle your RMA directly. Sorry for the inconvenience.


Building for visionOS has some framework errors

If I accept unsigned, the problem just appears again in the next build

Someone has figured this out already it seems but is shamelessly charging a subscription for a fork of an opensource app and keeping the changes to themselves, but not all features appear to be working, and they appear to have abandoned it. It would be nice to have codeapp available natively
https://apps.apple.com/gb/app/code-editor-git-and-terminal/id6480347047

Can you try building the CodeUI target instead? It is expected that the full build does not work for simulators.

On another note, I deliberately disabled visionOS support because I do not have a device to test it. @eurobob If you have access to a Vision Pro, I can enable it on TestFlight to let you test it.

@bummoblizard i was trying to build codeui target.
and yes i have the device so I’m down to test and help get this working 😊


Native histograms custom buckets storage

Implements parts of #13485
#13486
#13487
#13508
In short: implements the internal model, storage (TSDB) and basic unit tests for the storage and query.
No user visible impact yet. No scraping/remote write/configuration change.

/prombench main

/prombench main

I don't see any difference.  Also, prombench data doesn't have any native histograms.

/prombench cancel

I don't see any difference. Also, prombench data doesn't have any native histograms.

We made modifications to the engine, was wondering about any regression on the non-experimental part in floats.
Also my apologies, didn't realize I had to manually cancel.

I need a larger chunk of uninterrupted time to review this. I haven't got to carving that out. Will try ASAP.

FYI: I'm reviewing this now, but it will take me a while to get through all of it. Truly epic!

@beorn7 PTAL

Will give it another round of review ASAP.

Thank you! Keeping the current structure sounds good.

With the wild commit history, the DCO test got confused, but I think all commits are signed alright.


Swift module name breaks things

Expected Behavior
Default (implicit/empty) module name should not cause machine filename to be '__' and human filename '_'.
Likewise the customSuperentity shouldn't start with a '.' in same scenario.
Actual Behavior
In the case of the default module: Current Product Module under Xcode "Class" options,
the managedObjectClassName has a leading '.' which is currently escaped to ''. In in the case of a leading '.', we should isolate it before conversion to '' because if the module name is missing.
This is a simple check and I will raise a PR.
Additionally the customSuperentity is prefixing the super class with a '.', again we can sanitise this just like we do for sanitizedManagedObjectClassName.
Further details:
Here are the options for module in the core data editor.

This is what the default template with current release version of mogenerator produce
➜  freemote-app git:(master) ✗ mogenerator --version
mogenerator 1.32.  This file is machine-generated and constantly overwritten.
// Make changes to HomeAssistantConnection.swift instead.

import Foundation
import CoreData

public enum HomeAssistantConnectionAttributes: String {
    case entityID = "entityID"
    case host = "host"
    case token = "token"
}

open class _HomeAssistantConnection: .Gateway {

    // MARK: - Class methods

    override open class func entityName () -> String {
        return "HomeAssistantConnection"
    }

    override open class func entity(managedObjectContext: NSManagedObjectContext) -> NSEntityDescription? {
        return NSEntityDescription.entity(forEntityName: self.entityName(), in: managedObjectContext)
    }

    @nonobjc
    open class func fetchRequest() -> NSFetchRequest<HomeAssistantConnection> {
        return NSFetchRequest(entityName: self.entityName())
    }

    // MARK: - Life cycle methods

    public override init(entity: NSEntityDescription, insertInto context: NSManagedObjectContext?) {
        super.init(entity: entity, insertInto: context)
    }

    public convenience init?(managedObjectContext: NSManagedObjectContext) {
        guard let entity = _HomeAssistantConnection.entity(managedObjectContext: managedObjectContext) else { return nil }
        self.init(entity: entity, insertInto: managedObjectContext)
    }

    // MARK: - Properties

    @NSManaged open
    var entityID: String!

    @NSManaged open
    var host: URL?

    @NSManaged open
    var token: String?

    // MARK: - Relationships

}

Notice the .Gateway as the super class of _HomeAssistantConnection (presumably because the module is inferred default, but it KNOWS it has a module). The PR I open will allow for a sanitised version of the name of the super class (but still maintain the existing one so as to not break things that work already).
Tagging @rentzsch
PS.
Fully specifying the module name results in both the files and classes being fully qualified which generally breaks things even worse.
Edit: It's also necessary (my case here) to use the current module instead of global because it seems to break some things in SwiftUI if we don't:
See other post here

Closed by #388.


Boot crash with v1.4.0 on VMWare: Kernel panic

RancherOS Version: (ros os version)
v1.4.0 4.14.32-rancher2
https://releases.rancher.com/os/latest/rancheros-vmware.iso
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
Provisioning hosts via Rancher 2.0.5 on vSphere, ESXI 6.0.0
You can look up my Rancher specific configuration in https://github.com/rancher/rancher/issues/14480
The gist is that the nodes are stuck in "Waiting for VMware Tools to come online". When i try to access the console via vSphere client, i found that RancherOS crashes during boot.

After that i get send back to the boot selection menu.

For rancheros-vmware.iso, you should boot at least 2GB memory.
https://rancher.com/docs/os/v1.x/en/#hardware-requirements

If you want to use it as a kube node, 4GB at least.

I did try it with 2GB and 4GB of memory.

It's very strange, I have tried 2GB on my setup, it worked fine.
https://github.com/rancher/os/issues/2390#issuecomment-400157648

This seems like a different issue. Do you think the ESXi version could have something to do with this? Do i possibly need some extra cloud-init settings?

Hi,
We have the same problem. but when access the console via vSphere client Rancher OS boot properly, no fatal. However sometimes it works and sometimes rancher node stuck on "Waiting VMWare Tools". This problem is present with vSphere VMWare ESXi 5.5.
We tried on a vSphere VMWare ESXi 6.7, the problem disappear

We use open-vm-tools 10.2.5, not sure if it is not compatible with the old ESXi version.

The docs say ESXi 5.5 and upwards https://docs.vmware.com/en/VMware-Tools/10.2/rn/vmware-tools-1025-release-notes.html

I have this same exact issue but with Virtual Box.

the problem happens on vmware workstation 12 pro
v1.4.1

Is there someone can help to test this ISO?
http://releases.rancher.com/os/test/rancheros-master-vmware.iso
We really didn't reproduce the problem in 2G memory, but we did some optimizations to reduce the memory requirements, but the ISO size increased a lot.

I suspect this is a Linux Kernel/Virtualization issue.
I had issues with deploying CoreOS on my particular ESXi host as well. After updating ESXi to a certified version for the hardware we are running on, RancherOS and CoreOS booted without a problem.
As a workaround, you can use boot2docker - as long as you are not running it in production it works fine. It uses an older Kernel which worked fine for me.

@spawnia Thanks!
All the friends under this thread, can you try to upgrade your hypervisor?

Closing this issue since upgrading the hypervisor resolved the issue, see https://github.com/rancher/os/issues/2407#issuecomment-432553582


Kibana3 as a plugin

Hi guys,
do we really need Kibana 3 as a ElasticSearch plugin since we have Kibana 4 there as a separate package?

Depends on the installation, I guess. Personally I'm still using Kibana3 for many things, so would prefer it stick around. Is having it around causing problems in your deployments though? If so, I guess we could drop it and those needing it can list it as a remote plugin in their deployment properties. This question was also asked in #165, so maybe I'm missing something.

Two Kibana's just brings us a bit of mess here.
It's not an urgent issue, but in long term perspective I believe one of them should be removed.

Kibana 3 doesn't work with Elasticsearch 2.0 so when we merge https://github.com/logsearch/logsearch-boshrelease/pull/171 we'll remove Kibana 3


Support $push array update operator

Description
Closes #503.
In this PR:

implementation for $push
some refactoring for $pop

Readiness checklist

[ ] I added unit tests for new functionality or bug fixes.
[ ] I added integration tests for new functionality or bug fixes.
[x] I added compatibility tests for new functionality or bug fixes.
[x] I made spot refactorings.
[x] I updated user documentation.
[ ] I ran task all, and it passed.
[x] I added/updated comments for both exported and unexported top-level declarations (functions, types, etc).
[ ] I checked comments rendering with task godocs.
[x] I ensured that the title is good enough for the changelog.
[x] (for maintainers only) I set Reviewers (@FerretDB/core), Assignee, Labels, Project and project's Sprint fields.
[x] I marked all done items in this checklist.

Overall good. One thing I wonder is whether we want to add more test cases to both pop and push but that could be part of the following issues.

Hoping we reduce thinking much about it with https://github.com/FerretDB/FerretDB/issues/1831 :hugs:


Size is not calculated correctly

Describe the bug
The larger src is used instead of the correct one
To Reproduce
I created a codepen here, I also have a link to the live site if you want I can send directly via PM
https://codepen.io/raineng/pen/mdEZxzM
Steps to reproduce the behavior:
On this same site, most images are loaded correctly on mobile, but a few are being loaded with wrong size. It seems like it has something to do with object fit setting
What happened instead
In mobile mode, 320x480, 1024w version is used, perhaps 512w should be used instead?
In what environment (browser/device etc.) does this bug happen/not happen:
I tried on latest version of Chrome and Firefox on Windows

Edit 1:
I tried to remove all object-fit but the same issue still happens.
Edit 2"
I think this happens because the default DPR for my browser is set to 2 now, if it is changed to 1 then then the correct size will be used. I will need to look into this more.

Please read a) a good article about responsive image one that explains art direction and resoltuion switching and b) read the lazysizes especially the part how  data-sizes="auto" works.

You are right, it's not about art direction though, it's the sizes thing (dpr) that tripped me up.


Add log-collector script section to Elastic Stack docs

This commit will add a section to the Elastic Stack troubleshooting docs under Using Cloudwatch Logs in it's own section outlining how and where to use the log-collector script to send troubleshooting logs to the Support Team at Buildkite.

Looks like this is all good to go, so I'll merge for you. 😊


LAPP-40 Move default values to optional parameters

This would improve the user experience because the default values could be known at the configuration moment.

Codecov Report

Merging #131 into master will increase coverage by 0.63%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #131      +/-   ##
==========================================
+ Coverage   86.09%   86.72%   +0.63%
==========================================
  Files          27       25       -2
  Lines         791      761      -30
  Branches       82       74       -8
==========================================
- Hits          681      660      -21
+ Misses        109      100       -9
  Partials        1        1

Impacted Files
Coverage Δ

Analytics/Config.cs
85.71% <100.00%> (+4.10%)
:arrow_up:

Analytics/Client.cs
95.80% <0.00%> (-0.15%)
:arrow_down:

Analytics/Request/FakeRequestHandler.cs

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 b054ed1...39d84a0. Read the comment docs.


lib: add forSystems

Description of changes
This adds a function lib.forSystems which is similar to forAllSystems from the c-hello flake template
Co-authored-by: Justin Restivo<EMAIL_ADDRESS>Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@alyssais Currently all of our https://github.com/NixOS/templates contain the following boiler plate:
      # System types to support.
      supportedSystems = [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" "aarch64-darwin" ];

      # Helper function to generate an attrset '{ x86_64-linux = f "x86_64-linux"; ... }'.
      forAllSystems = nixpkgs.lib.genAttrs supportedSystems;

      # Nixpkgs instantiated for supported system types.
      nixpkgsFor = forAllSystems (system: import nixpkgs { inherit system; });

But if we merge this, we would be able to reduce it to this:
    forAllSystems = nixpkgs.lib.forSystems [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" "aarch64-darwin" ] nixpkgs;

With the same motivation as https://github.com/NixOS/nixpkgs/pull/173093#issue-1236188725 I'm closing this.
The lib namespace is not a place for experimental features.


Add Transaction filter by end_datetime

Adding filter for finance report on all transaction endpoint on watcher info
Overview
Add Transaction filter by end_datetime
Changes
Describe your changes and implementation choices. More details make PRs easier to review.

Add Transaction filter by end_datetime
Add test

Testing
mix test

dude it doesnt even run yet

unit test is missing?

added


Projects

We have to specify that projects 2020 refer to nma-cn, and we have to update the prject_materials.yml


README says "MIT license" but License.txt says BSD 3-clause

React doesn't have a license in package.json. We'll remove that line for us too.

README and LICENSE.txt still disagree.
What license is Reason under?

@jakealbert Just cleaned up the licenses. Please see LICENSE.txt in the project root :)


Bump lib-common modules and services to v0.1.0

Let's wait for the core services to have the v0.1.0 tag and then we'll resume this change


Research and select a suitable blockchain platform.

After speaking with the sponsor he confirmed that we will be using a private blockchain network

A suitable blockchain platform for developing a private blockchain would by Hyperledger Fabric, which is an open source enterprise solution for developing blockchains created by the Linux Foundation. As it is open source, there is no cost for using any of the software, and there is free detailed documentation that I will link at the bottom of this comment. One issue that is not specific to Hyperledger Fabric as it is found within all major blockchain platforms is that there is not an API SDK for CLisp. Therefore, we would have to develop a Lisp wrapper around a supported language in order to make API calls that can interact with our network. The available languages for the initial code that the wrapper will be created around will be Javascript, Java, Golang, Python, and Typescript.


linux-builder: support x86_64-linux on aarch64

Description of changes
This replaces #258502 which doesn't work locally for me as qemu-system-x86_64 is not available in pkgs.qemu_kvm.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

I'm concerned that this might lock mac users into a solution with worse performance, only some people knowing that it's slower than necessary and even fewer people knowing how to fix it.
What I recall from @sandydoo is that Rosetta 2 can run in Apple Virtualization Framework but not QEMU. See virtualisation.rosetta.enable.
What if we could launch UTM instead of qemu? It seems to have gained a CLI recently.

I'm concerned that this might lock mac users into a solution with worse performance, only some people knowing that it's slower than necessary and even fewer people knowing how to fix it.
What I recall from @sandydoo is that Rosetta 2 can run in Apple Virtualization Framework but not QEMU. See virtualisation.rosetta.enable.
What if we could launch UTM instead of qemu? It seems to have gained a CLI recently.

As the linux-builder is ephemeral, my preference would be to merge this despite being slow and leaving it as future work to speed it up which could be done without changing the interface.
Another way we could speed this up in the future is building QEMU with Virtualization support and using Rosetta (currently the patchset isn’t mainlined and don’t yet have the correct entitlements necessary to run Rosetta).


How to Stickto both "Top" and "Bottom" sides?

Hello!
I need to sliding stickto both sides on same time. How with yours library?
Thanks.

Hi @jamesmartins. Use stickTo to set where do you want to layer to appear from. If you need its boundaries to cover the entire screen simply do so using the typical mechanism in your layout.


update for the links to Chinese version

Sorry for the messy commit. For some reason, I cannot squash the commits for the moment. You can squash the commits as you wished. Thanks for your corporations :smiley:

No problem! Thanks for the updates :+1:


Some of the text in Chart dropdown is hidden

On 2.5.6-rc8

Go to Cluster --> Cluster explorer --> Apps and market place --> Charts -->. CIS benchmarks (for example) --> Charts dropdown
Repo name - Rancher/Partner is hidden, in the beginning

Verified that problem exists on v2.5.7 with K8S 1.20.5

Go to Cluster --> Cluster explorer --> Apps and market place --> Charts -->.  CIS benchmarks (for example) --> Charts dropdown
First letter of "Rancher" and "Partners" appear correctly.


feat: add backend

It didn't run the Cloudflare build. Maybe because it's a PR from an external fork.
Or...maybe during my tinkering, I broke the Cloudflare integration :fearful:


[pruned-liveness] Make some small fixes that only are exposed when working with multi-bit code

I am fixing some issues that I discovered in FieldSensitive liveness which internally uses pruned live blocks. There are a few things that I did here that fix some architectural issues:

Rather than attempting to perform operations all at once for multiple bits, we instead now just work one bit at a time. This simplifies the internal implementation and also more importantly allows me to specialize the internal implementation for single bit usage.
I changed getBlockLiveness to only return enough block liveness for the requested bits. If we returned extra dead bits we perform computeUseBlockLiveness additional times for bits where we do not want to do so. This can cause weird propagation issues.

NOTE: This is an interim change. I plan on splitting PrunedLiveBlocks into two separate implementations in a subsequent commit. The first will take advantage of SILNodeBits and only handle single bits and we will have a separate FieldSensitive one that handles multiple bits.

@swift-ci test

The reason why I think this hasn't hit the main move only address impl is that I am now fixing how we hoist destroy_addr which exposes these issues when we have partially deinited structs.

@swift-ci test

I just merged this and I think GitHub hit an issue where it didn't realize the merge went through? I guess I am just going to close this PR.


Update e-common

Details

Fixed Issues

$ #4187
Tests | QA Steps

Paste Formatted links into the composer.
You should receive the values based on the following rules:
a. [html](www.google.com) When html and you will see this type of link as html.
b. www.google.com when www.google.com and you will see this type of link as www.google.com.
c<EMAIL_ADDRESS>when<a href="mailto:abc<EMAIL_ADDRESS>and visible as<EMAIL_ADDRESS>
Tested On

[x] Web
[x] Mobile Web
[x] Desktop
[x] iOS
[x] Android

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @Luke9389 in version: 1.0.83-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

This has been deployed to production and is now subject to a 7-day regression period.
If no regressions arise, payment will be issued on 2021-08-24.  :confetti_ball:

🚀 Deployed to production by @isagoico in version: 1.0.85-9 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Upgrade Portal to Python 3.10

Motivation
Language features availability, performance, security.
Secondarily, TileDB Mac M1/arm builds are available for Py 3.10+, which avoids a lengthy compilation process for Mac M1 users.
Definition of Done
Data Portal runs w/o issue on 3.10, including BE and pipelines
Tasks

[ ] Docker containers updated
[ ] Linters updated (to check against 3.10 compliance)
[ ] Documentation updated
[ ] Full system testing performed on rdev

Created a companion issue to upgrade Explorer:

https://app.zenhub.com/workspaces/single-cell-5e2a191dad828d52cc78b028/issues/gh/chanzuckerberg/single-cell-explorer/564

@dsadgat , I added the gene expression label since this impacts GE, unless it's decoupled from Portal before this Python upgrade is done.

The data portal backend is already using Python 3.10 and does not need an upgrade. The pipeline is using 3.8 but to upgrade it painlessly, we'd need to change the base Docker image to Ubuntu 22 (currently, we're using Seurat's base image which is based on Ubuntu 20). This might not be worth it especially with Seurat 5 now being in beta.
Dockerfile.data_cube_creation is based on a python 3.9 image - is this what we want to upgrade?

Sound good if data_cube_creation is all we need to (and can reasonably) upgrade.


Add sample_point to Archipelago.

Now users can find points on the archipelago for their own uses!
For a concrete example of this: I have a game where I allow players to place objects, and these objects have a handful of "target points" around each object. I want my AI characters to randomly select one of these target points for an object and go there to interact with the object. However if the player places objects really close together, those points may be off the nav mesh. So I want to filter the target points based on whether they are on the nav mesh or not, hence this function.

Codecov Report
Attention: Patch coverage is 99.41860% with 1 line in your changes missing coverage. Please review.

Project coverage is 96.6%. Comparing base (5594d7d) to head (78469bc).

Additional details and impacted files

Files
Coverage Δ

crates/landmass/src/coords.rs
100.0% <100.0%> (+25.0%)
:arrow_up:

crates/landmass/src/lib.rs
93.6% <100.0%> (+0.1%)
:arrow_up:

crates/landmass/src/lib_test.rs
100.0% <100.0%> (ø)

crates/landmass/src/query_test.rs
100.0% <100.0%> (ø)

crates/landmass/src/query.rs
93.3% <93.3%> (ø)

... and 1 file with indirect coverage changes

Note this is related to #59.


create a configuration file loader API

OSAL should provide an API for loading text configuration files (akin to tables).

Trac comment by cdknight on 2016-03-19 10:52:09:
The configuration file format will be similar to the existing cfe_es_startup.scr format used by the Executive Service, namely:
field, field, field, ...;
! end of file marker
! more comments
But with the following two changes:

"!", as with "#" and ";" will be considered as markers for in-line comments. A warning should be given when "!" used and there are lines with data after the first occurrence as this will change the behavior.

Addition of section headers formatted as [header text]

Imported from trac issue 164.  Created by cdknight on 2016-03-19T10:48:43, last modified: 2019-04-23T15:45:34

Trac comment by glimes on 2016-03-21 14:50:08:
You can plant a link in the ticket to a specific link
by typing [changeset:1234567] ... just be very careful to
not put a blank after the colon, as that would trigger a
design flaw in Trac that makes the ticket unviewable.

Trac comment by cdknight on 2016-03-19 10:55:07:
Code being submitted in branch trac-164-confloader

Trac comment by jphickey on 2018-05-22 14:16:22:
Consider moving this to a CFE ticket?

Trac comment by jhageman on 2019-03-27 11:20:32:
This changeset is [changeset:f42e55e], the cFE ticket is [cfs_cfe:#145], and cfe work was done as trac-145-es_conf and pushed a single commit as [cfs_cfe:changeset:28bc5e9].

Trac comment by jwilmot on 2018-07-24 14:04:24:
Moved to 145 in cFE


Update repositories-pull-requests-discussions.md

https://github.com/huggingface/hub-docs/pull/327/files should be clear what is going on
without origin, the command errs.
cc: @coyotte508 @SBrandeis @julien-c

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Magic Notes React app Added issue #1556

🛠 Issue (1556)

Closes #1556
Description
MAGIC NOTES
It is a simple notes keeping project .
It is a REACT APP .
I had added My Project in the Project directory.
The project is added with the README.md file .
All the instructions are added in README file for installing the project .
It looks like the below screen shot :-

Checklist:

[x] I have made this from my own
[x] I have taken help from some online resourses
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas

React projects are not accepted in this repo

Should have told at the time when you were assigning project.
It's a request pls read the issue description before assigning it.


tensorflow-object-detection-api face co-ordinates

boxes = self.detection_graph.get_tensor_by_name('detection_boxes:0')  gives me normalized co-ordinates(0.1734, 08956, 0.34567, 012564) of the face detected, but I want un-normlized(original) co-ordinates (245, 475, 300, 600)

I want to crop the faces but i'm also having trouble in getting the face coordinates. Can anyone help?

boxes = self.detection_graph.get_tensor_by_name('detection_boxes:0') gives me normalized co-ordinates(0.1734, 08956, 0.34567, 012564) of the face detected, but I want un-normlized(original) co-ordinates (245, 475, 300, 600)

Hi @NarenBabuR
Did you find out how to convert normalized coords. to un-normalized?
Thanks


Hot Reload Works on M1 Macs?

Hi, I can't seem to get the Hot Reload to work on an M1 Macbook pro.  Does arm64 cause an issue?

Yes, you can now use VS code
VS code extension


Search v3 Saga

@keybase/react-hackers
Adds sagas that use entities. No searchv3 reducer!
use the actions/searchv3/creators::search function to create an action that will create a search result and save the results to the given keypath in entities.

Changed this so now you fire a search action that looks like:
{type:'searchv3:search', payload: {term: 'marco', service: '', actionTypeToFire: 'search:fooo'}} (Using the helper of course).
The search saga takes on that and fires an action of the type
{type: actionTypeToFire, payload: {searchTerm, searchResults, service}}
You can have another saga listen to your action type that you set, or just have it emit the 'chat:updateSearchResult' to have the reducer use it as is.

The commits 44153060a218...f1e001c17847 introduce visual changes on linux. :mag_right: 3 changed

Changed: Search_V_3_results_List-keybase_Results_One (before) (after)

Changed: Search_V_3_results_List-keybase_Results (before) (after)

Changed: Search_V_3_results_List-facebook_Results (before) (after)

The commits 44153060a218...8894e0bb55fc introduce visual changes on linux. :mag_right: 6 changed

Changed: unlock_folders-Success (before) (after)

Changed: Tracker-Tracker_Error (before) (after)

Changed: Tracker-Platforms (before) (after)

Changed: Search_V_3_results_List-keybase_Results_One (before) (after)

Changed: Search_V_3_results_List-keybase_Results (before) (after)

Changed: Search_V_3_results_List-facebook_Results (before) (after)

The commits 44153060a218...b33c91999990 introduce visual changes on linux. :mag_right: 3 changed

Changed: Search_V_3_results_List-keybase_Results_One (before) (after)

Changed: Search_V_3_results_List-keybase_Results (before) (after)

Changed: Search_V_3_results_List-facebook_Results (before) (after)

The commits 44153060a218...e8243e13cec7 introduce visual changes on linux. :mag_right: 3 changed

Changed: Search_V_3_results_List-keybase_Results_One (before) (after)

Changed: Search_V_3_results_List-keybase_Results (before) (after)

Changed: Search_V_3_results_List-facebook_Results (before) (after)


Use multi stage building

Per talks with @Alevsk it's better to use a multi-stage building to create the image.

Copy only the needed bin/libs/conf to the final image

O.O
https://www.youtube.com/watch?v=GFIUCTutwKo&t=13s&ab_channel=OpenInfraDaysMexico


Implement error when connectivity issue

Follow https://material.io/archive/guidelines/patterns/errors.html#errors-user-input-errors to implement error messages fpr:

lack of connectivity
unable to process citibike api response

You can set airplane mode on the emulator

added acceptable implementation, might review it later


Issue with /docs/tutorials/kubernetes-basics/cluster-interactive/

This is a...

[ ] Feature Request
[ X] Bug Report

Problem:
Terminal did not connect, refresh does not work using Safari 10.0.1 on MacOSX 10.12.1
Proposed Solution:
Use Chrome works fine
Page to Update:
http://kubernetes.io/...

Sorry you've encountered an error. Could you please check and try again. This should have been resolved.

marking closed


Use markdown syntax

This change tidies up the formatting a little, and adds a title to the README.md

Closing this out as the formatting was also fixed as part of #7 . Sorry for letting this wallow, I never noticed this PR and don't check this repo often.


require does not recognice libs from Crystal SDK

require "./benchmarks"
require "./objects"
require "./symbols"
require "./lexer"
require "option_parser"

It shows Cannot resolve file 'option_parser.cr' but option_parser comes from the Crystal SDK
If you want to check, you can use my project https://github.com/MarioAriasC/monyet/blob/main/src/monyet.cr
Cheers

Thanks! SDK support is the priority task together with adding language changes from 1.3.0


[Storage] mkdir() error writing on a Uniform bucket-level access

Using mkdir() through the stream wrapper on a bucket with uniform level access, this ServiceException is thrown:

Cannot insert legacy ACL for an object when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access.

Sorry for not responding here @javiermarinros. In case you missed it, a fix for this is available in google/cloud-storage v1.17.0.

It's okay, I checked the same day you pushed the fix and everything works fine now. Thank you!

I have just deployed a new instance and I am getting the same error. I am using a Laravel wrapper, however, I have checked the dependencies and it is using v1.18.0 of the cloud storage.

I'm using the latest version, and mkdir returns false.


Can't watch age-restricted videos

Script version
5.6
Describe the bug
Videos that are restricted by age don't load, showing a letter "This video is age-restricted and only available on YouTube". The video plays normally when I turn off the script.
Expected behavior
I'm logged with legal age, the video should play normally.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

the videos are now played in a youtube embed player like they were outside youtube (because that's the new way how the script works in order to not be detected by youtube) so you have to deactivate the script in order to watch these


Namespace issue

Hi @cristianoc, i've enabled namespace for reason module
with this module
<EMAIL_ADDRESS>"common/components/Spinner"]<EMAIL_ADDRESS>external make: (~size: string) => TsReact.element = "default";

gentype output is
/* TypeScript file generated by genType. */
/* eslint-disable import/first */

import {default as defaultNotChecked} from 'common/components/Spinner';

// In case of type error, check the type of 'default' in 'Spinner.re' and 'common/components/Spinner'.
export const defaultTypeChecked: (_1:{ readonly size: string }) => MyNamespace_TsReact_element = defaultNotChecked;

// Export '$$default' early to allow circular import from the '.bs.js' file.
export const $$default: unknown = defaultTypeChecked as (_1:{ readonly size: string }) => MyNamespace_TsReact_element;

import {TsReact_element as MyNamespace_TsReact_element} from './MyNamespace.gen';

export default $$default;

Please notice that it uses MyNamespace instead of TsReact.
TsReact is a simple module to make ts happy with our bindings
[@genType]
type element = React.element;

[@genType]
type elementType = React.element;

I was able to workaround this by creating MyNamespace.re that duplicates TsReact code
module TsReact = {
  [@genType]
  type element = React.element;

  [@genType]
  type elementType = React.element;
};

I think custom namespace (as string) is causing this issue.
Note on custom namespacing: if for some reason, you need a namespace that is different from what your name will produce, you can directly send a string to the namespace option. For example, if your package is a binding named bs-some-thing, you can use "namespace": "some-thing" to get SomeThing namespace instead of BsSomeThing.

Another observation, I have lerna monorepo setup with multiple reason modules, and there is one app that uses them all.
If i compile each package individually it works correctly,
but if i compile top root project, that has reason modules as deps - genType outputs incorrect relative paths for shims, which makes ts mad

@Coobaha after these investigations, do you think that the generation does not behave as expected?  Output uses invalid imports.
I will setup minimal repo with the issues above tomorrow

@cristianoc
https://github.com/Coobaha/gentype-monorepo-issue
Issues are collected in README.md

@Coobaha just mentioning that his issue was not forgotten. Just, it's non-trivial, and will take a while to unpack.

@cristianoc  Also noticed that with namespace: true
output is not a valid typescript

import {StringId_t as Opaque-BsGentypeIssue_StringId_t} from './Opaque-BsGentypeIssue.gen';

		"bs-platform": "^5.2.0",
		"gentype": "^2.40.0"

@Coobaha I could not repro on one of the existing projects.
Is the repro the same one pasted above?
https://github.com/Coobaha/gentype-monorepo-issue
I've tried to follow the instructions, but failed with:
$ npx lerna exec build

lerna notice cli v3.16.4
lerna info Executing command in 3 packages: "build"
/bin/sh: build: command not found

Is there a standalone repro? Not sure what lerna does under the hood.

@cristianoc npx lerna exec yarn build

Happy to revisit. Feel free to reopen if still a wish.

Yes this is still an issue in our monorepo codebase @cristianoc, I have found couple of workarounds: creating module with same name as custom namespace and also keeping shim files in root sources folder though.

@Coobaha I've started do look into this.
First, there was a comment above about import with namespace:true.
Here's an example of importing a type in a prpoject with namespace:true. https://github.com/cristianoc/genType/pull/307.
So far it looks OK.
Would you suggest what's the next small step to repro an issue?

(This is based on master, in case recent changes are relevant -- let's discuss about the latest version).

Have you tried ‘namespace: “custom”’? I will check/update my repo tonight
On 12. Nov 2019, 18.09 +0400, Cristiano Calcagno<EMAIL_ADDRESS>wrote:

@Coobaha I've started do look into this.
First, there was a comment above about import with namespace:true.
Here's an example of importing a type in a prpoject with namespace:true. #307.
So far it looks OK.
Would you suggest what's the next small step to repro an issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@Coobaha just tried namespace: “custom” and indeed it creates issues.
Haven't tried that before: so by definition it's currently unsupported.

For what is worth, I've updated the README to mention this limitation so at least the current state is documented.

@cristianoc checking my reported issues with recent gentype now

@cristianoc yeah, it seems to be resolved! i am closing this :) will report new issues here if will find some

Ooh that was much smoother than I was expecting. Thanks!

@cristianoc hey, sorry but one issue still there :/ I've pushed deps update to https://github.com/Coobaha/gentype-monorepo-issue
Steps to reproduce:
git clone git@github.com:Coobaha/gentype-monorepo-issue.git
cd gentype-monorepo-issue
yarn lerna bootstrap
yarn buld

yarn build will build packages/app that has other packages as deps, please check packages/app/src/App.gen.tsx (it will have wrong imports)
/* TypeScript file generated by genType. */
/* eslint-disable import/first */

// tslint:disable-next-line:no-var-requires
const AppBS = require('./App.bs');

import {Demo_t as DemoShimDemo_Demo_t} from './DemoShimDemo.gen';

import {Types_demo as DemoSomePackage_Types_demo} from './DemoSomePackage.gen';

// tslint:disable-next-line:interface-over-type-literal
export type wrongShimImportPath = DemoShimDemo_Demo_t;

export const wrongTsImportsWithCustomNameSpace: (_1:{ readonly size: string }) => DemoSomePackage_Types_demo = function (Arg1: any) {
  const result = AppBS.wrongTsImportsWithCustomNameSpace(Arg1.size);
  return result
};

@Coobaha I had a look at how the project is set up. Looks lerna has some pretty unusual setup -- not even sure why it builds.
Looks like there's nothing in node_modules.
For now, the plan is only to support a straighforward flow for now, as in https://github.com/cristianoc/genType/pull/301.
That's in master but not in a release yet. I'll cut a release.
(Already checked it does not support lerna, as it expects things to be in node_modules).

lerna+yarn hoists all modules to root node_modules. local packages can be symlinked with lerna link command.

@cristianoc I've tried 3.4.0
Output is almost there 😅
const AppBS = require('./App.bs');

import {Demo_t as DemoShimDemo_Demo_t} from<EMAIL_ADDRESS>
import {Types_demo as DemoSomePackage_Types_demo} from<EMAIL_ADDRESS>

It misses src in path, and uses package namespace for file prefixes.
Correct path will be @demo/shim-demo/src/Demo.gen for
[@genType]
type wrongShimImportPath = DemoShimDemo.Demo.t;

@cristianoc following your comment https://github.com/cristianoc/genType/issues/308#issuecomment-554380007
It works now 🎉, we are almost there :D shims are still not resolved correctly.
When compiled from main package.json packages/shim-demo/src/Demo.gen.tsx gets incorrect shim path:
import {t as ToShim_t} from './Shimmed.shim';
When compiled from module itself path is correct:
import {t as ToShim_t} from '../src/shims/Shimmed.shim';
Path is resolved correctly if shim is located in top folder though (src in this case):
// Main package.json compilation
import {t as ToShim_t} from './Shimmed.shim';
// Package as root compilation
import {t as ToShim_t} from '../src/Shimmed.shim';

P.S. This is reproducible in the same repo, I've updated genType version there

@Coobaha nothing special is done about shims and sub-projects.
In fact, I did not think one should do anything special. So any sub-project is a project which could define its own shims.
Can you explain at a high level what you would expect to happen and the rational about it?
We can also move it to a new issue.


[DO NOT MERGE] Fix Edm.Guid mutator

This commit should prevent undesirable replacements of immutable characters within a Guid string. Before this commit, the following code snippet raises an error:
from odfuzz.mutators import GuidMutator
while True:
    guid = GuidMutator.replace_char("guid'dddddddd-dddd-dddd-dddd-dddddddddddd'")
    if not guid.startswith("guid'") or not guid.endswith("'"):
        raise RuntimeError("oopsie")

Codecov Report

Merging #43 into master will decrease coverage by 1.76%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #43      +/-   ##
==========================================
- Coverage   60.60%   58.83%   -1.77%
==========================================
  Files          15       15
  Lines        3297     3153     -144
==========================================
- Hits         1998     1855     -143
+ Misses       1299     1298       -1

Impacted Files
Coverage Δ

odfuzz/mutators.py
38.64% <0.00%> (-6.42%)
:arrow_down:

odfuzz/generators.py
78.18% <0.00%> (-4.92%)
:arrow_down:

odfuzz/output.py
61.90% <0.00%> (-3.32%)
:arrow_down:

odfuzz/databases.py
71.42% <0.00%> (-3.29%)
:arrow_down:

odfuzz/config.py
85.71% <0.00%> (-2.86%)
:arrow_down:

odfuzz/fuzzer.py
33.41% <0.00%> (-2.21%)
:arrow_down:

odfuzz/entities.py
73.16% <0.00%> (-0.94%)
:arrow_down:

odfuzz/restrictions.py
71.66% <0.00%> (-0.92%)
:arrow_down:

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 9c9bedc...a95b1b0. Read the comment docs.

This PR should prevent replacing of undesirable characters in a string. For example, the following code snippet raises an error almost immediately.
from odfuzz.mutators import GuidMutator
while True:
    guid = GuidMutator.replace_char("guid'dddddddd-dddd-dddd-dddd-dddddddddddd'")
    if not guid.startswith("guid'") or not guid.endswith("'"):
          raise RuntimeError("oopsie")

Hi Lubos, does odfuzz have a test suite?
What about to use your latest PR comment to as the commit message?

@filak-sap, I deleted the comment and moved its content to the commit message.
Anyway, can you elaborate on your first question? If I understand it correctly, you want me to write a new test case for the Edm.Guid mutator proving that the fix really works, is that right? However, I would probably end up writing a test case like this: https://github.com/SAP/odfuzz/blob/master/tests/test_mutator.py#L31-L72. I reckon it is not a good way how to test the mutators. We should rather open a new issue and discuss different possibilities of creating more robust tests which can handle, for example, the non-deterministic behavior.

@lubosmj - well, this is fine example of what I tried to explain to you personally, that the project is in current state not easy to test. We should take this opportunity to design more testable API from bottom-up.
There are few ways how to test code as in GuidMutator.replace_char, but since what it does is string replacement and the random number is used in one place, this should be simply rewritten to be deterministic and testable method (instead of usage of something like testing in loops (like your first comment) or for example property testing, e.g. Hypothesis library).
Especially if this is fix for issue #40  - first you should try to write test that reproduces the bug, if it is possible.
As a quick, simple -but "hey, it is working" solution can be adding optional parameter to the method and if present, it will set the value for rand_hex_char instead of random number. And then you shoudl be able to write parametrized pytests for every possibilty, some of which should fail and therefore reproduce this bug.
Please create separate PR for this change. It expected to be failed on travis and I want to see such build log.
Then add fix from this commit there, proving that it fixes the problem uncovered by the test, and I will close this as duplicate.
And then we will move similarly for other odata data types.

@phanak-sap, the commit is not a fix for #40. I submitted the pull request #45 which should convince you that this is a real problem and it should be resolved as soon as possible in order to prevent unnecessary server errors during fuzzing.
In my opinion, once I add a new function parameter to the mutator, it may decrease the performance due to the fact that ODfuzz is going to check for that passed parameter always. We want to avoid such checks because the fuzzing process needs to be fast. I am in favor of creating a different API for the mutators globally. It really does not make sense to pass rand_hex_char to the function and create a wrapper around it because this will have to be done for every single mutator out there then. What about creating a new issue where we can discuss what kind of API should be the best to use?

OK, I have created blank issue #46 to discuss this topic and tie PRs to.

Guys, the initial comment contains a code snippet which can be used for testing or am I wrong? Why do you spend time writing code snippets instead for writing tests?

@filak-sap The snipped is endless loop - wait till the bug surfaces. The true, simple and deterministic test for this exact bug is part of already merged #45, with the code fix present in this one. This PR therefore serves no purpose anymore and was closed.


iPad with physical keyboard: enter key never sends message

Starting with first beta release of 1.47, pressing the physical enter key on my smart folio keyboard never sends the message, only inserts a newline (including using any modifiers like cmd, option, etc.). The only way to send the message seems to be to press the on-screen send button, which on iPadOS 15 is almost entirely obscured by system keyboard widgets for changing keyboard settings and dictation.

Not sure if relevant, but the desktop app (Mac) has settings for sending with cmd+enter -- it seems like this setting applies only to the desktop app itself, but I double-checked it anyway and I've always had it set to use cmd+enter for send only for codeblocks, changed it completely to off just to be sure, but it had no effect on the iPad app.
I'm on iPadOS 15.0.1, but the problem was present on 15.0, too (not sure about 14.x). Also, this started happening on first beta release of 1.47 and persists with all builds so far (last tested on 372). Reverting to version 1.46 fixes the issue.
Server version is 6.0.0-rc1.

@amyblais this is a regression, apps built with Xcode 13 and running on iPad 15, requires us to set a new property called WantsPriorityOverSystemBehavior.
Will submit a PR tomorrow and cut a new build as a new RC
Thanks for reporting @jbozanowski