Inaccurate pros

The app feels more responsive and users do not see the flash between page navigations due to full-page refreshes.

If you utilise caching correctly, the flash between page navigations does not occur. If your APIs respond in a timely fashion, then it will feel responsive too. Also if you employ chunked responses, the server can send the data is has straight away (like the header), then wait for APIs to respond and then send the rest of the page.

Fewer HTTP requests are made to the server, as the same assets do not have to be downloaded again for each page load.

Again if you use caching correctly, this is not true. If you are lazy loading assets, then you would probably have more when rendering in the client.

Clear separation of the concerns between the client and the server; you can easily build new clients for different platforms (e.g. mobile, chatbots, smart watches) without having to modify the server code. You can also modify the technology stack on the client and server independently, as long as the API contract is not broken.

If you separate the "server" into two parts, for example, a Python back end and a Node front end; you have clear separation of concerns and none of the downsides of doing it all in the client. You are in complete control of all versions of all the software on each server instead of running you app in an unknown and uncontrolled environment. You have the ability to re-use the APIs for mobile apps etc and can easily change the tech on either stack. Also you can easily make cross origin requests, which makes it easy to compose a page from many APIs (if required).

Would you like to make a pull request to improve on the inaccuracies?

en,I am a new learner...

Nm

Uhh

WHAT


[setup] Support pacman on Arch Linux

Motivation
Ran dev_setup.sh on arch linux and it failed
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Ran scripts/dev_setup.sh
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

@adsharma Syncing with the repos for installation of dependencies is not a good idea, since a user's system will then be out of sync with upstream. A repo sync should only be done when doing a system upgrade. Please use -S.

Thanks for the PR @adsharma. Our team is reviewing your PR and will reply back soon. We're still sorting out CLAs and will reply back with an update.

@flacks: updated the commit to use pacman -S

@adsharma Thank you!

Hi @adsharma, our contribution process wasn't in place in time to accept and attribute your commit. Future commits will allow you to get GH attribution. I'm also working with the team to improve this process.


Documentation

I there any documentation for this library?

Not as such, but the example files should be quite self explanatory?


Do not block on pending brokers during upscale

This fixes the following scenario:

Start with a 3 racks cluster (3 brokers per rack)
One AZ goes completely down

existing brokers on that AZ are lost/failed
new brokers/pod cannot be scheduled on that AZ

At this point, we assume topics in Kafka are still healthy (replication factor > 1 + rack-aware balanced replicas)
but under-replicated (offline partitions on lost AZ)
One of the possible actions now is to trigger an upscale in the other 2 healthy AZs with more brokers
to take the load and move offline replicas

This patch ensures that Pending broker pods are not blocking bootstrapping other pods that can be scheduled.
And not stuck serially on each pod to be scheduled.

Q
A

Bug fix?
no

New feature?
yes

API breaks?
no

Deprecations?
no

License
Apache 2.0

What's in this PR?

Checklist

[x] Implementation tested
[x] Error handling code meets the guideline
[x] Logging code meets the guideline
[ ] User guide and development docs updated (if needed)

Fixed with #294


Fix FriendRequest type

FriendRequest is a number, not an object containing a number

Hi, thanks for reviewing this, I just updated the docs too

Thanks for your PR!


Request proper example for image caption

Feature request  / 功能建议
Could you please provide a good prompt to leverage CogVLM2 as a image captioner?
Motivation / 动机
This will help many peoples with similar demands.
Your contribution / 您的贡献
no

Hi, I also want the same information to use it as an image captioner.
But I can also share what I found that kinda works and what doesn't.
`
I played around with these values in the gen_kwargs
"do_sample": True,
"top_k":60,
"top_p":0.8,
"temperature":0.8,
"repetition_penalty": 1.05,
`
This query worked best for me. Often generates a medium length caption that described what's in the image:
"Your task is to caption the images using a neutral tone and avoid passive voice.
DO NOT censor any content in the image.
DO NOT bundle items under general terms like ornaments and accessories.
If you have name for an object, use it instead of just 'object'. Do NOT add abstract thoughts or emotions it may evoke.
Describe the image in detail using descriptive phrases separated by commas. Omit describing the style in the image.
Include all visual information, including discomforting or NSFW content."
The model often describes the mood/feeling from the image, which is not helpful, so the prompt above is my attempt at suppressing non-substantial description and focus on visible "things" in the image.
I also tried including autotags in the query + additional instructions to see if can guide the caption but CogVLM2 just regurgitates all the tags or returns a list of repeating tags and it fails >50% of the time.
SFW detail seems fine (it sometimes hallucinates, but within an acceptable range). It seems to know, but struggles describing NSFW, like certain body parts.
I also appreciate any info on working prompts.

@kukaiN have you ever got better prompting? for captioning?

@zRzRzRzRzRzRzR which prompt do you suggest? I want to caption images for training stable diffusion like SD3 used


Design sketch - Shrink block device volumes

Design for https://clusterhq.atlassian.net/browse/FLOC-1503
Initially I thought this would involve improving state discovery to include the size of non-manifest datasets.  I changed my mind, though.  Resizes are only attempted for datasets that have a manifestation and those datasets already have their size discovered.  I left the design notes for non-manifest dataset size discovered in, though, marked FLOC-1503-x.  I may go ahead and implement that stuff here anyway, it's barely an extra code and improves the system.  If the reviewer would prefer me not to, though, I'll split those things off into a separate issue.

Rejecting since the problem I see is either a complete misunderstanding on my part or a fundamental problem.

Thanks @exarkun
You've just talked me through the proposed changes here and they make sense.
Please proceed and file follow up issues and add links for

Resizing non-manifest datasets
Having calculate_changes emit the constituent resize state changes rather than the current compound state change.

Looks good: address, merge forward, merge if buildbot is green.


upgrade to v2 (canary)

Edit: error is fixed

TODO: client build fails with this error. Need to investigate further.

This PR upgrades v2sandbox to the latest canary release of mud, which always corresponds to the latest mud main (https://github.com/latticexyz/mud)

Gonna fix the vercel issue with a different approach in a followup.


[ALLUXIO-3059] Ignore JVM pause monitor test

https://alluxio.atlassian.net/browse/ALLUXIO-3059

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17573/
Test PASSed.


I need a better name

Since this is mostly going to behave like a command like tool I'd like to change the name to something short and box/packing/shipping related.

tape
wrap
pack

Anyone care about the name? I'm gonna change it to tape unless someone demands that I no

I'm good with tape.
Sent from my iPhone

On Jan 8, 2015, at 4:01 PM, Ian Donovan<EMAIL_ADDRESS>wrote:
—
Reply to this email directly or view it on GitHub.

tape it is!

Just out of curiosity, I checked rubygems, and someone's already got tape. https://rubygems.org/gems/tape

I'm willing to surrender packing_tape, which was supposed to be packer and a tape of sorts. But it could all leave inside packing_tape the ansible recipes, playbook, the gem and the packer integration.


Formatting

I wonder if you want cargo fmt used on the codebase?  There are substantial modifications to some files when used.  If you want it I will make a PR just for formatting, and I will then cargo fmt any work that I push elsewhere.  If you don't want to enforce formatting then I will just try to use sensible conventions that fit with your style in my work without running the tool.

Okay.  I used to have some issues with it, but after not using rust for a while the idea of a formatter is comforting ;)


KAFKA-5702: extract refactor StreamThread

Extracted TaskManager to handle all task related activities.
Make StandbyTaskCreator, TaskCreator, and RebalanceListener static classes so they must define their dependencies and can be testing independently of StreamThread
Added interfaces between StreamPartitionAssignor & StreamThread to reduce coupling.

@guozhangwang, @bbejeck, @enothereska, @mjsax, @sriramsub - Sorry about the size of this change, but it is pretty difficult to pull it apart without it being so big. I don't think it is by any means perfect or complete, but I hope it can put us on a better path. There is way too much coupling in the internals stuff at the moment and we really need to think about defining and using appropriate interfaces.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6576/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6561/
Test PASSed (JDK 8 and Scala 2.12).

@dguy thanks for taking this on.
My thoughts after a first pass is can we extract  the inner-classes (RebalanceListener,TaskCreator and StandbyTaskCreator etc) from StreamThread? Although I'm pretty sure those classes are only used by StreamThread IMHO it's worth the trade-off to reduce StreamThread by a few hundred LOC.

@dguy LMK if you'd like to take a further stab on this PR to break the circular dependencies, otherwise the PR looks good in general to me.

@guozhangwang i've addressed your comments. I've left the circular dependency for now as i think it needs some more thought on how to do it properly. We can address that and moving TaskCreator etc in a separate PR - WDYT?

System test results here: http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/2017-08-09--001.1502280749--dguy--stream-thread-refactor--4d8960d/report.html

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6660/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6645/
Test FAILed (JDK 8 and Scala 2.12).

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6666/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6651/
Test PASSed (JDK 8 and Scala 2.12).

retest this please

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6686/
Test FAILed (JDK 8 and Scala 2.12).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6701/
Test PASSed (JDK 7 and Scala 2.11).

merged to trunk


Move buckets.scala

forward fit https://github.com/zio/zio-metrics/pull/119

duplicates https://github.com/zio/zio-metrics/pull/128/files


Incorrect parsing/highlighting of member access and function calls

Current Behaviour
The grammar currently parses these expressions incorrectly as function calls:

map.member
map.another_map.member

Note that calling a function like this is deprecated in the newest Elixir versions.
Parsed correctly but not highlighted as a function call:

function.()

Expected Behaviour
I think the grammar should parse/highlight as follows:
# Parse as member access or at least don't highlight as function calls:
map.member
map.another_map.member
# Always parse and highlight as function calls:
function.()
map.function()
Module.function
# Always highlight as a function call:
something |> function

The grammar currently parses these expressions incorrectly as function calls:

map.member
map.another_map.member

This is expected. The parser mirrors Elixir AST, and map.member is parsed as a call, the same way as map.member().
We can however change the highlighting.
map.member
map.another_map.member

Currently another_map and member are highlighted as @function, which is indeed not correct. I believe the accurate highlight tag would be @property, which JavaScript and Rust highlights use for fields.
As for function.() I am not certain that it should be highlighted as function, because it is noticeably different from a regular function call. If we did that, it would be inconsistent with the highlighting in function = fn x -> x end (which we could also highlight as function, but I don't think we should). @josevalim wdyt?

I agree: syntax-wise the "foo" in foo.() is a variable rather than a function.
Updating the highlights for the right-hand-side of dot makes sense though especially if map.member is deprecated as a way to call a function

This is expected. The parser mirrors Elixir AST, and map.member is parsed as a call, the same way as map.member().

You're right. We can test this in iex with quote do map.member end and quote do map.member() end. The former has [no_parens: true].

We can however change the highlighting.

Great. :+1:

As for function.() I am not certain that it should be highlighted as function, because it is noticeably different from a regular function call. If we did that, it would be inconsistent with the highlighting in function = fn x -> x end (which we could also highlight as function, but I don't think we should). @josevalim wdyt?

I don't think it would be inconsistent because in general calling a function is different from defining it, or at least it's certainly helpful to make that distinction. So function = fn x -> x end should remain a variable declaration syntactically and visually. However, when we see function.() it clearly represents a function call and highlighting it as such would reflect what the code actually does. Personally, I'm confused if this visual cue is missing.

One thing to keep in mind is that you can try to call any variable as a function which will fail. For example: foo = 42; foo.(). In that case I don't think that it makes sense to highlight foo as a function because it isn't one. And while in simple cases like what I just showed we might be able to determine if a variable contains a function in the general case we cannot (as far as I understand). Maybe this could change with the type system, but that's still a ways away.

@aexvir highlighting only works on syntax level, so foo.() (or mod.foo()) has the same meaning, regardless if it fails at runtime (or even compile time) :)

One thing to keep in mind is that you can try to call any variable as a function which will fail. ...

You may also do that with the pipe operator as in data |> some_variable. That shouldn't prevent us from expecting it to be highlighted as a function call. It's out of the current scope of a tree sitter grammar to be able to know what a symbol really is. I believe it's possible to integrate basic semantic analysis into a syntax highlighter to enhance it, but in case of Elixir it may never be completely accurate due to its dynamic nature. But that's a different project and not a simple feature to build.

foo() is a local function call, no variables
foo.() has foo as a variable holding a function
foo.bar() has foo as a variable holding a module
foo.bar has foo as a variable holding a map

So, in case of 2, if we can say that foo is a variable holding a function, that would be correct. But foo is not a function. It depends if we are doing static analysis or not (and we are being consistent with this analysis in 3 and 4).

The symbol foo in foo.() is a variable but it's used as a function. The highlighter usually cannot know what a symbol is (without expensive semantic analysis), so the best thing to do is to highlight things as what they most likely appear to be. To me it's not only visually appealing but important to highlight function calls consistently, because when I see the colour I know instantly something is being called. When foo.() isn't in that colour it looks strange and off to me.
Btw, while experimenting I found something curious:
iex> foo = %{bar: 1}
iex> foo.bar()
1

I would have expected an exception here (using Elixir 1.16.3).
In any case, we can see that we're able to put different values in these symbols and still use them in call expressions. The highlighter will never know what they hold at runtime, but it doesn't need to. It should aid us in making code more readable as best as it can.

Elixir does not need semantic analysis. We can tell syntactically what is what and the code you pasted emits a warning on v1.17.
The root of my argument is in this screenshot:

If you say that foo in the last example should also be colored in orange, because we know it is a module, then I agree we should color it for function. But I think most people would find that confusing and surprising. So we should treat it as variable in all of the cases. We are either consistent in showing types or we should the syntactic information. I am leaning towards the syntax information (variable).

So you mean foo in foo.bar() could be colored pastel green because we know it must be a module? But we don't because it's a variable... I see what you mean. However, by the same reason shouldn't bar be uncolored as well, because it's actually a property of foo and therefore not a "function"? But we don't leave properties uncolored everywhere in order to be consistent. As soon as an identifier is followed by parentheses (or an argument) it's colored as a function call. That seems to be the defining rule and can also be considered to be consistent.
Besides, what to do about something like foo.bar.()? bar is a property and currently it's colored as a function call, but after the coming fix it will be uncolored text. Does that make sense?
Lastly, let's take a look at this example:
doc
|> next_break_fits(:enabled)
|> fun.()
|> next_break_fits(:disabled)

Doesn't it seem strange that fun is uncolored? Doesn't it break the "visual flow"? When we read the code, we see that doc is piped into a function and then into the variable fun, but there is no visual indication that something will be called. How is that visually appealing and helpful?

The example does not look weird to me at all, either in GitHub or my editor (which also uses tree sitter) . Especially because the purple one tells me the name of the function that will be invoked. fun.() does not tell me the name of the function it will be invoked and I don't want to think there is a function named fun.
So yes, it looks both visually appealing to me, even though I don't think we should go into the discussion of what is visually appealing, because it will be based on taste and that will not lead us anywhere. With the opened PR, it seems we will be consistent here, so I will close this in favor of the PR.

Besides, what to do about something like foo.bar.()? bar is a property and currently it's colored as a function call, but after the coming fix it will be uncolored text. Does that make sense?

After the PR bar in foo.bar.() will be highlighted as a property, which is consistent with foo in foo.() being highlighted as a variable.
Another perspective on the discussion is that semantically it's not about highlighting "calls", but rather "function" references. And it's clear that foo in foo.() references a variable.

Thanks for the discussion and the grammar changes so far! :pray:
Some good arguments were exchanged and I see why you want to keep foo.() a variable reference. In summary, it's because we don't respectively color foo in foo.bar() as a module and foo in foo.() is simply not a function reference.
We don't need to talk about taste, but I think we should still have a technical discussion (in a separate issue) about making a distinction between function declarations, calls and references. If we did that we could easily customize the appearance of these symbols to our liking in the editor of one's choice. :+1:


Full support for emojis

GitHub style emojis should be converted to the correct emoji, so that it displays in the menu bar. This should be configurable with the ability to be displayed.
E.g. :sunny: 5°C -> :sunny: 5°C

Emoji JSON exists, Unicode is being mapped, but not sure how to the actual emoji.


Can't use on aws with php-python combination

I want to use this  API for my university project, but can't do it with php:
This is my php code:
              <?php
                echo "alma: ";
                $original = 'rák';
                $output = passthru("python3 search.py $original");
              ?>

and in search.py
#!/usr/bin/env python
import sys
import requests
import deepl
import logging

logging.basicConfig()
logging.getLogger('deepl').setLevel(logging.DEBUG)

print "translated: \t"
translator = deepl.Translator("mykey")
result = translator.translate_text("Hello, world!", target_lang="FR")
print(result)
print '<br>'

And I got only alma: text back.
Also tried like: system("python3 -m deepl --auth-key=MYKEY text --to=DE 'Text to be translated.'"); but nothing. I didn't find anything in PHP error log.
BUT if I want to use in aws command line as was mentioned than I got the correct answers.
I also opened a stackoverflow error about this: https://stackoverflow.com/questions/69861167/how-to-parse-answers-with-deepl-api

I'm going to close this issue. @almakorte61 please comment again if you have further problems.


Fixed URL issue for multi store view

#19

@evasilchenko @steveburchfield Please review my PR.

Hi @sandy6666 apologies for the delay the review. Can you explain a little bit about what your PR is attempting to address?

Hi @sandy6666 apologies for the delay the review. Can you explain a little bit about what your PR is attempting to address?

Sorry, please disregard my comment as I just saw the issue which you file alongside your PR. Do you have an environment where this change is active so that I can go in and conduct some testing from my side?

Hi, @evasilchenko I don't have any open environment you can test it by creating two different websites and having different URLs for both of the websites.


updates to remaining report README files

This pull request includes updates to two reports not previously reviewed: supplying turnaround and requesting ratio.
I think it also includes previously-reviewed requesting turnaround and overdues reports.

Kristen, the review request included several files, and I'm not sure which
this comment refers to.  I'll send you links to each of my 'final' drafts
via slack.  hopefully that will make it easier for you to see each file...
On Fri, Jan 7, 2022 at 11:35 AM Kristen Wilson @.***>
wrote:

@.**** requested changes on this pull request.
Julie, I'm not sure I'm looking at the right version of this, so apologies
if you've done this and I'm just not seeing it. For the definition, it
seems like should clarify the difference between the average and median
times, as well as the counts (requests under 48, etc.).
—
Reply to this email directly, view it on GitHub
https://github.com/openlibraryenvironment/reshare-analytics/pull/34#pullrequestreview-846782791,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVUFOPGQY4Y776JE2OQXPM3UU4I6XANCNFSM5LLC3DJQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***
com>

@kristenwilson @julienye If it helps, you can click on the "Files changed" tab, and then click on a plus sign ( + ) on the left to select a line (or select multiple lines) in order to leave a comment on a specific file.

oh, wow  - that's good to know, thanks, Nassib!
On Mon, Jan 10, 2022 at 10:49 AM Nassib Nassar @.***>
wrote:

@kristenwilson https://github.com/kristenwilson @julienye
https://github.com/julienye If it helps, you can click on the "Files
changed" tab, and then click on a plus sign ( + ) on the left to select a
line (or select multiple lines) in order to leave a comment on a specific
file.
—
Reply to this email directly, view it on GitHub
https://github.com/openlibraryenvironment/reshare-analytics/pull/34#issuecomment-1009013676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVUFOPCJFDYWZM7ULSNE3DDUVL5ZPANCNFSM5LLC3DJQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@kristenwilson - there is still a question you haven't responded to, in the supplying_turnaround README.  I also just asked you the same question in Slack.  if you reply, I'll remove it from the README file and you can approve the changes and it will all be ready for NN to merge.  Thanks!


Fix nightly clippy warnings

We can fix these, but I need to remind myself to switch Clippy to the stable channel next Thursday (when Rust 1.62 is released).
Regarding that failure in test_strtod, I think the offending test should be just outright skipped.


Updating serverless to 1.32.0 and pinning version

Should resolve customer-support issue 18.  I'm doing the PR to get it in front of people, but I'll want to verify this on my local also.

I've added a test around setting a UUID on local awsRequestId in report.js in addition to pinning the version. (And I've added the JetBrains cruft directory to .gitignore.)
@kolanos @adjohn @ewindisch : I've structured the local ID somewhat arbitrarily:
local-${functionName}|${uuid()}.  I'd be happy to change this (and the test) to a different structure, if people prefer.  My thinking behind the pipe was to make testing a bit quicker, since we can just split on the pipe.  But this could change if a different structure works better for us and customers.

Oy. So close.


Pad data with extra data points if two measurements are too far apart

This is needed because sometimes for one reason or another the data points don't flow in regularly.

Reason 1 could be that the user puts the app into the background or locks the phone. This doesn't always result in data stream pause, but sometimes it does.
On Jan 26 the Bike 24 of the Cyclebar Fresno 2nd row center (always under the fan!) had a malfunction: the console could pick up the power sensor. I think the power sensor might have been low on battery. As a result the console started to pick up surrounding power sensors, multiple of them, and often paused.

I added debug-only capability to append workouts together: 990c45385f6ff5d8d8c9ad9f148ded0825e4a4f4
With this I appended 3 workouts into one. Then performed a recalculation of expended energy and distance (with enhancements https://github.com/TrackMyIndoorWorkout/TrackMyIndoorWorkout/commit/043ca682b9cdabbace56847a77d05788589675d7)
I'm not sure how these might be available to end users, but the last picture in the puzzle is that these appended workouts have large time gaps in between them. Any time gap results in crossover lines when we look at the track from the top. So I'm introducing a padding routine, which adds extra data points so the GPS would be relatively continuous. The distance and energy is calculated like the speed and watt reading would be sustained between the two data point time readings. So the intermediate padding data points won't be a linear interpolation, but a simple constant sustain of the speed / watts.

So far the first tests were promising on Strava, I cannot see it in MapMyRide, but SUUNTO and TrainingPeaks showed the across lines over the track inner. So needs some more inspection why it didn't work there.

With the latest changes I re-checked SUUNTO and Training Peaks uploads and they don't have any cross vectors over the inner of the track. Double checked the Strava upload and that's good as well.


⚠ ClamAV has degraded performance

In 00bb096, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 138 ms

Resolved: ClamAV performance has improved in 3edc860.


Cannot set --name correctly in etcd 2.0.0-rc.1

I'm currently the v2.0.0-rc1 version on my Mac.
It works when I use the default machine name "default".
Both of following commands work:
./etcd
./etcd --name 'default'

But it doesn't work when I assign another name
MacBook-Pro:try willy$ ./etcd --name default2
2015/01/13 17:57:58 no data-dir provided, using default data-dir ./default2.etcd
2015/01/13 17:57:58 etcd: listening for peers on http://localhost:2380
2015/01/13 17:57:58 etcd: listening for peers on http://localhost:7001
2015/01/13 17:57:58 etcd: listening for client requests on http://localhost:2379
2015/01/13 17:57:58 etcd: listening for client requests on http://localhost:4001
2015/01/13 17:57:58 etcd: stopping listening for client requests on http://localhost:4001
2015/01/13 17:57:58 etcd: stopping listening for client requests on http://localhost:2379
2015/01/13 17:57:58 etcd: stopping listening for peers on http://localhost:7001
2015/01/13 17:57:58 etcd: stopping listening for peers on http://localhost:2380
2015/01/13 17:57:58 etcd: couldn't find local name "default2" in the initial cluster configuration

The name you give to etcd must match the name you have in the initial cluster configuration. The default ones are matched. If you change the name, then you need to change the initial cluster configuration.
Please refer https://github.com/coreos/etcd/blob/master/Documentation/2.0/clustering.md


Add a showcase entry

Leave a simple project for a task of students. The framework was really helpful to get a fast result with cheap effort. Thanks!

Can you swap lines 92 and 93, so that they are in alphabetical order?

@ChristopherBilg The order is changed now. Best regards.


add license

What type of license would you prefer?

I prefer the Apache 2.0 license. This license is free as MIT license. But source code protects by an intellectual property right.

https://zgp.org/~dmarti/qanda/what-are-the-differences-between-open-source-licenses/

Because given the only one answer, and the fact that I also prefer MIT, the temporary choice is MIT.

Sorry, I didn’t eat it carefully, now I’m shitting apache and mit

Apache requires to mention the license in every file. Meath does not require. I don't see any advantages. What exactly is better to choose Apache 2 against MIT?

May be WTFPL?

This issue closed. This opened: https://github.com/deepcase/deepcase/issues/23


Allow loading sphinx declarations if avaialble

When trying to validate sphinx files docutils (and by association restructredtext-lint) pukes a bunch of errors that are false positives that are actually ok. I've had to work around this in https://github.com/stackforge/doc8 (which is used in a few openstack projects now btw) at https://github.com/stackforge/doc8/blob/master/doc8/checks.py#L79 ; is there any better option that can be used to avoid those types of non-errors that this helper program can make possible. Possibly loading the sphinx extensions so they aren't warnings/errors? Thoughts?

So I see the following which has something maybe we can do?
https://github.com/myint/rstcheck/blob/master/rstcheck.py#L323
https://pypi.python.org/pypi/rstcheck (pretty similar to this code-base in some ways)....

Right, they are leveraging directives and roles as mentioned in the previous comment. Are you still interested in opening a PR?

Let me see if I can; I'd like to so that I can get rid of https://github.com/stackforge/doc8/blob/master/doc8/checks.py#L99 (and such crap... there).

Closing as wontfix for the same reasons as given in #14. We have added documentation for adding new directives/roles via docutils in 0.11.3.
https://github.com/twolfson/restructuredtext-lint/pull/14#issuecomment-91933907


Update JSONParse to Swift 4, Xcode 9, iOS 11

Use the new Swift 4 JSON decoder and get rid of those force unwraps of optionals

Thanks FabioTacke 👍


Fallback to installing AMD64 plugins on Darwin

What this PR does / why we need it
With this PR it is now possible to fully use a locally built CLI on Mac ARM64 machines
Although the CLI is available for Darwin ARM64, the vast majority of plugins are not, and therefore an ARM64 CLI will not be able to install most plugins.
Thanks to Apple's Rosetta emulator available on Darwin ARM64 machines, it is possible to run AMD64 binaries.  This is currently how the CLI and its plugins are being run.
This commit teaches a Darwin ARM64 CLI that if a plugin is not available for Darwin ARM64, it should instead install the Darwin AMD64 version. With this approach, it now become possible to use a Darwin ARM64 CLI to its full potential.
Note that this approach cannot be used for Linux as there is no standard emulator for AMD64 binaries.  For Linux, plugins will need to be published for ARM64.
Unit tests have been added for this new feature.
Which issue(s) this PR fixes

Part of #357
Describe testing done for PR
# Reset the CLI
$ rm ~/.cache/tanzu/catalog.yaml
$ rm ~/.config/tanzu/config*
$ rm ~/.cache/tanzu/plugin_inventory

# Build an ARM64 CLI on Darwin
$ make build
build darwin-arm64 CLI with version: v1.1.0-dev
mkdir -p bin
cp /Users/kmarc/git/tanzu-cli/artifacts/darwin/arm64/cli/core/v1.1.0-dev/tanzu-cli-darwin_arm64 ./bin/tanzu

$ tz ceip set false
$ tz config eula accept
[ok] Marking agreement as accepted.

# Install a plugin that is not available in ARM64
$ tz plugin install telemetry --target global
[i] Reading plugin inventory for "projects.registry.vmware.com/tanzu_cli/plugins/plugin-inventory:latest", this will take a few seconds.
[i] Installing plugin 'telemetry:v1.1.0' with target 'global'
[i] Plugin binary for 'telemetry:v1.1.0' found in cache
[ok] successfully installed 'telemetry' plugin

# Confirm that the installed plugin binary is AMD64
$ tz plugin describe telemetry
  NAME       VERSION  STATUS     TARGET  DESCRIPTION                                                 INSTALLATIONPATH
  telemetry  v1.1.0   installed  global  configure cluster-wide settings for vmware tanzu telemetry  /Users/kmarc/Library/Application
                                                                                Support/tanzu-cli/telemetry/v1.1.0_a93519154dc71368d738aec09f9bc964a0c3bcd02a856106ccaddaaf31426636_global
$ file ~/Library/Application\ Support/tanzu-cli/telemetry/v1.1.0_a93519154dc71368d738aec09f9bc964a0c3bcd02a856106ccaddaaf31426636_global
/Users/kmarc/Library/Application Support/tanzu-cli/telemetry/v1.1.0_a93519154dc71368d738aec09f9bc964a0c3bcd02a856106ccaddaaf31426636_global: Mach-O 64-bit executable x86_64

# Now install a plugin that is available in ARM64
$ tz plugin install builder
[i] Installing plugin 'builder:v1.0.0' with target 'global'
[i] Plugin binary for 'builder:v1.0.0' found in cache
[ok] successfully installed 'builder' plugin

# Confirm that the installed plugin binary is ARM64
$ tz plugin describe builder
  NAME     VERSION  STATUS     TARGET  DESCRIPTION             INSTALLATIONPATH
  builder  v1.0.0   installed  global  Build Tanzu components  /Users/kmarc/Library/Application
                                                               Support/tanzu-cli/builder/v1.0.0_9e15f81e9a1dc5655aca06562922a48525231072b30033a187aef78ff56d3f74_global
$ file ~/Library/Application\ Support/tanzu-cli/builder/v1.0.0_9e15f81e9a1dc5655aca06562922a48525231072b30033a187aef78ff56d3f74_global
/Users/kmarc/Library/Application Support/tanzu-cli/builder/v1.0.0_9e15f81e9a1dc5655aca06562922a48525231072b30033a187aef78ff56d3f74_global: Mach-O 64-bit executable arm64

# Create a context for TMC.  None of the plugins are available in ARM64
# but with this PR, the installation of those plugins will now work
$ tz context create tmc2 --endpoint unstable.tmc-dev.cloud.vmware.com --staging

[i] If you don't have an API token, visit the VMware Cloud Services console, select your organization, and create an API token with the TMC service roles:
  https://console.cloud.vmware.com/csp/gateway/portal/#/user/tokens

? API Token ****************************************************************

[ok] successfully created a TMC context
[i] Checking for required plugins...
[i] Installing plugin 'secret:v0.1.4' with target 'mission-control'
[i] Installing plugin 'clustergroup:v0.1.4' with target 'mission-control'
[i] Installing plugin 'account:v0.1.4' with target 'mission-control'
[i] Installing plugin 'integration:v0.1.4' with target 'mission-control'
[i] Installing plugin 'aks-cluster:v0.1.7' with target 'mission-control'
[i] Installing plugin 'provider-eks-cluster:v0.1.4' with target 'mission-control'
[i] Installing plugin 'apply:v0.3.1' with target 'mission-control'
[i] Installing plugin 'setting:v0.2.2' with target 'mission-control'
[i] Installing plugin 'tanzupackage:v0.2.3' with target 'mission-control'
[i] Installing plugin 'continuousdelivery:v0.1.4' with target 'mission-control'
[i] Installing plugin 'ekscluster:v0.1.4' with target 'mission-control'
[i] Installing plugin 'helm:v0.1.4' with target 'mission-control'
[i] Installing plugin 'inspection:v0.1.4' with target 'mission-control'
[i] Installing plugin 'provider-aks-cluster:v0.1.4' with target 'mission-control'
[i] Installing plugin 'iam:v0.1.4' with target 'mission-control'
[i] Installing plugin 'audit:v0.1.4' with target 'mission-control'
[i] Installing plugin 'events:v0.1.4' with target 'mission-control'
[i] Installing plugin 'workspace:v0.1.6' with target 'mission-control'
[i] Installing plugin 'data-protection:v0.1.4' with target 'mission-control'
[i] Installing plugin 'policy:v0.1.4' with target 'mission-control'
[i] Installing plugin 'management-cluster:v0.2.4' with target 'mission-control'
[i] Installing plugin 'cluster:v0.1.6' with target 'mission-control'
[i] Plugin binary for 'cluster:v0.1.6' found in cache
[i] Installing plugin 'agentartifacts:v0.1.4' with target 'mission-control'
[i] Successfully installed all required plugins

# Check that these plugin binaries are AMD64
$ file ~/Library/Application\ Support/tanzu-cli/agentartifacts/v0.1.4_8f6cbbbd670ad0c32bc39adc37835e6d4dac28b66230af4517aa6c3ff83b3c3c_mission-control
/Users/kmarc/Library/Application Support/tanzu-cli/agentartifacts/v0.1.4_8f6cbbbd670ad0c32bc39adc37835e6d4dac28b66230af4517aa6c3ff83b3c3c_mission-control: Mach-O 64-bit executable x86_64
$ file ~/Library/Application\ Support/tanzu-cli/events/v0.1.4_e93c2eb67ee0cc21a0997cd116b66d81cc40064c121483daff530d31dd45cd9f_mission-control
/Users/kmarc/Library/Application Support/tanzu-cli/events/v0.1.4_e93c2eb67ee0cc21a0997cd116b66d81cc40064c121483daff530d31dd45cd9f_mission-control: Mach-O 64-bit executable x86_64

Release note

Allow fully using an ARM64 CLI on Mac (Darwin) by having the CLI install plugins for AMD64 when an ARM64 version of the plugin is not available.

Additional information
Special notes for your reviewer
Implementation approach
The implementation approach chosen is to replace the use of runtime.GOOS/GOARCH with our own version cli.GOOS/GOARCH everywhere in the code.  The new variable are set to the same value as the runtime ones.  However, it now becomes possible to programatically make the CLI believe it is running on a different OS/ARCH (for this PR, we change the ARCH to AMD64 to install plugins not available for ARM64 on Darwin).
An alternative approach would have been to add arguments to many different function to specify what ARCH should be used.  This second approach would have required a bit more changes.
However, the real reason I opted for the first approach is that it also allows to write unit tests for this feature, even if those tests are run on Linux, or AMD64, by using the cli.GOOS/GOARCH to make the CLI believe it is running on Darwin ARM64 for the test in question.
No E2E tests
To be able to use this feature, one must run on a Darwin ARM64 machine.  Therefore to be able to exercise the feature in E2E tests, those tests would need to run on darwin_arm64, which is not something offered out-of-the-box for Github actions.   Here are the options I can see:

implement an e2e test which will only test the feature when run manually by someone on their darwin_arm64 machine

inconsistent testing since requires to run it manually

deploy a self-hosted runner on a darwin_arm64 machine and have github run our e2e tests on it

does not seem possible to run a MacOS VM on Azure.  Not sure of other options.

don't implement an e2e test for this feature and rely on the existing unit test

should be a sufficient indication that the feature is functional

I prefer option 3 but am open to other opinions or suggestions.
Other aspect
A aspect that I did NOT implement is the following: when running a Darwin AMD64 CLI on a Darwin ARM64 machine, we could install ARM64 plugins when available; now, and with this PR, an Darwin AMD64 will only install AMD64 plugins.
I opted against this because with this PR, there should be no reason to run an AMD64 CLI on a Darwin ARM64 machine.  Therefore we should direct users to use the ARM64 CLI.  Same goes for plugin devs.  Note that 'brew install' will install the ARM64 CLI starting with the v1.1 version when on ARM64 Macs.
Besides, even if we did implement this extra "feature", a plugin dev would need to install the v1.1 CLI to benefit from it, which takes us back to: might as well install the ARM64 version of the CLI 1.1.

@scothis this may interest you


Gather URL Neds updating in slides

The GATHER server at Duke will be shut down In December 2016. Please use the new location at: http://changlab.uth.tmc.edu/gather/

Done - thanks @kiwiroy !


Publish to NPM

Self explanatory.

Time to do courage test! Let's publish it!

:rocket: PR was released in v1.0.0 :rocket:


Keep cursor pos in visual mode

How about keeping cursor position while visual selection?
You can only have 2 positions, begin or end of the selection depending on how you moved your cursor to select.
I can make a pull request if you want me to?

Sorry to catch up late.
@pelodelfuego I'm not sure keeping cursor pos in visual mode is really useful, but I guess it's interesting.

I can make a pull request if you want me to?

Could you please making pull request? :+1:

Hi,
Getting back in contribution, I agree with you this enchancement is not really usefull.
Still do you want me to make a pull request ?
Have a nice day !

Hi @pelodelfuego. Please send your pull request! This is the most needed feature in this plugin. Keeping the cursor where it was in visual mode is a game changer!


Add an initial warmup step to IPEXModels

What does this PR do?
The first 2 forwards of an IPEXModel after trace/load includes background optimizations steps that make the output of these forwards unpredictable and non consistent with the model after the optimizations. To fix that, an initial warmup step was added to the __init__ of IPEXModels

Depends on PR #542
@echarlaix
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Add OpenSourceOrg licenses

Machine readable licenses here.
Add these licenses to expand the database.
They include keywords like: "discouraged", "non-reusable", "osi-approved"

Last version of compiled JSON of licenses: https://api.opensource.org.s3.amazonaws.com/licenses/licenses.json


Query: Fix #6473 - No server-side handling of Contains (LIKE) on opti…

…onal relationships

DefaultIfEmpty was indeed being lifted, but had to correct a small bug in nav. rewrite.

@maumar @smitpatel

:shipit:


br tags in headings

It seems like
 in h1/h2/h3 etc. tags makes document.execCommand('formatBlock', false, 'p') function work not the way it have to.
Way to reproduce bug at the demo-page:

create three
-paragraphs
select them
click h2-button, so you get
Hello, World!
Hello, World!
Hello, World!

set caret after last
 and try to click h2-button again to remove h2 tag. It will not work.
If you wil set caret before
 and try to click h2, at first it will remove
-tag and after another click it will acts like it have to.

Confirmed 😞 , works if the whole h2 is selected so has a workaround.


Recommended terminal settings.

For Unix operating systems what are the recommended terminal settings? Is this documented anywhere outside of repo issues?

Please move request to PowerShell-Docs repo.


Use watchers for file changes?

Poking around the automagic suggestions for LaTeX commands, I see that all \input{} files are opened and scanned for suggestions. While this is nice, it currently happens each time the autocomplete provider is invoked.
This does cause some concern when working with large files with multiple inputs - though I don't have any noticeable slow down at the moment.
Would it be prudent to use something like watchFile or Atom's onDidChange or better yet chokidar and update the suggestions list only when there are changes to these input files?
What do you think?

Thanks for the suggestion. That might be a big change to how the file scanning works. I myself welcomes this improvement, yet it is not on the top of priority list.

TBH I will try to port this to the VS Code extension first, and see if it can be easily ported back.

Yep, low priority indeed! This should have the enhancement label and not bug :-)
I had quick peek, and it would seem that VSCode already uses chokidar unlike Atom that has issues on Windows with watchFile

Probably there will be an official API soon, since the implementation of the language-server protocol requires something like this. https://github.com/atom/atom/issues/14163

Yeah, I saw that a few days back.
In the interim, I have implemented a chokidar based watch system directly in PR #47 :-)


Move Babel behind --optimize flag and/or new --babel flag

See #89 for context.
Built off of the monorepo-support branch since I wanted to test the changes together. But I can rebase it back onto master if needed to merge first.

I like it. Risky proposition: Move babel and preset to peer-dependencies and lazy load them (though both peer-dependencies and lazy-loading can be kind of a pain, so I get it if the answer is no way).


docs: ✏ Proxy config clarification

Proxies could cause packages not to download. Clarified that you need to check for proxies in documentation.
✅ Closes: 580

👋 Thanks for creating a pull request! 🚀 Checkout the storybook we've created for it: chlorophyll


Add self to Build script owners

PR Summary
Add self to build script owners
PR Checklist

[X] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[X] Summarized changes
[X] Change is not breaking
[NA] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[X] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[NA] Not Applicable
OR
[ ] User-facing Documentation needed

[NA] Issue filed - Issue link:

Testing - New and feature

[ NA] Not Applicable or can only be tested interactively
OR
[NA] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

Can you also look at the code owners in the powershell-docs repo and add yourself where we are?

@dantraMSFT Why did you close this PR? I'm going to merge it this morning.

@daxian-dbw - Hmm, I don't how it got closed. Would you reopen it?


Error sync of  repository https://packages.cloudfoundry.org/fedora/

Hello.
We are using a RedHat Satellite server and during the synchronization of the repositories " https://packages.cloudfoundry.org/fedora/" is giving next error:
A file located at the url https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm failed validation due to checksum.
Tried also to install the package "cf8-cli-installer_i686.rpm" directly using but the package cannot be open
[root@localhost ~]# yum localinstall  https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm f
Loaded plugins: auto-update-debuginfo, fastestmirror, product-id, search-disabled-repos, subscription-manager, verify, versionlock

cf8-cli-installer_i686.rpm                                                                                | 2.4 kB  00:00:00
Cannot open: https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm. Skipping.
Skipping: f, filename does not end in .rpm.
Nothing to do

Can you please check from your side if the package cf8-cli-installer_i686.rpm : https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm
was not altered by mistake?
Thank you

Hi,
The issue was with the filename. It is resolved now.  Please try downloading using the filename 'cf8-cli-installer_8.0.103_i686.rpm'.
If the issue still persists, please let us know.

Hi @gururajsh
Actually we are using Redhat Satellite to synchronize the cloudfoundre repository. I just checked and the error is still persists
"A file located at the url https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm failed validation due to checksum."
Can you check this issuer once again.
Thanks

Hi @lsstreet,
The link posted above is still pointing to old filename. I just tried with https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_8.0.103_i686.rpm and I'm able to download. Can you try with this link?

Hi @gururajsh,
Thank you for your reply
Yes, your link is working, but our satellite server, when it try to synchronize  is checking all packages from your repositories and is failing for the file cf8-cli-installer_i686.rpm which was modified and the checksum also changed.
If it is an old version of package in my opinion is better to remove this file and regenerate rpm metadata.

All 8.0.103 version files are removed now. Looks like this version was added as part of some testing, hence the issue.

hmm,  still have the error.
A file located at the url https://packages.cloudfoundry.org/fedora/releases/v8.0.103/cf8-cli-installer_i686.rpm failed validation due to checksum.

v8.0.103 folder itself is deleted. So, the link should give some path not found related error. May be its cached?

@gururajsh
I just checked and it seems that the version v8.0.103 is still available, please see the screenshot in above message.

Hi @lsstreet, where did you get 8.0.103 from? This is not an officially released version here or here
cc @gururajsh

Closing this issue. @lsstreet if you still face issues with downloading latest CLI version, please open a new issue.


No such module 'React'

No such module 'React' in the new project!
My old project with react native not run with react native 0.60.5.
I create a new iOS project and integrate with React Native (https://facebook.github.io/react-native/docs/integration-with-existing-apps), but the result is the same, I can't run the project because the module React no such.
React Native version:
System:
OS: macOS 10.14.6
CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Memory: 57.05 MB / 8.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 10.6.0 - ~/.nvm/versions/node/v10.6.0/bin/node
Yarn: 1.5.1 - /usr/local/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v10.6.0/bin/npm
Watchman: 4.7.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3
Android SDK:
API Levels: 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.1, 25.0.2, 25.0.3, 26.0.2, 26.0.3, 27.0.3, 28.0.3, 29.0.0
System Images: android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom_64, android-25 | Google APIs ARM EABI v7a, android-25 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.3 AI-182.5<IP_ADDRESS>14842
Xcode: 10.3/10G8 - /usr/bin/xcodebuild
npmPackages:
react-native: ^0.60.5 => 0.60.5
My package.json:
{   "name": "MyReactNativeApp",   "version": "0.0.1",   "private": true,   "scripts": {     "start": "yarn react-native start"   },   "dependencies": {     "react-native": "^0.60.5"   } }
My Podfile:
`platform :ios, '9.0'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
target 'NewReactNativeIntegrate' do
pod 'React', :path => '../node_modules/react-native/'
pod 'React-Core', :path => '../node_modules/react-native/React'
pod 'React-DevSupport', :path => '../node_modules/react-native/React'
pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS'
pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation'
pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob'
pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image'
pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS'
pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network'
pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings'
pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text'
pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration'
pod 'React-RCTWebSocket', :path => '../node_modules/react-native/Libraries/WebSocket'
pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact'
pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi'
pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor'
pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector'
pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'
pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
use_native_modules!
end
`

I had the same issue, seems like the imports are now case sensitive.
changing import react from 'React' to import react from 'react'` fixed the issue for me.

Hi..
So, the problem is in Xcode with Swift, see:

same issue here

same issue here

the same problem Xocde 10 RN 0.60.5, react can't be found

Hi, I'm running into the same No such module 'React' error.
In the past our project has always had use_frameworks! enabled, but React-Native 0.60.5 documentation says to remove use_frameworks!, which I speculate is the reason we're seeing the No such module 'React' error.
Here is issue #25349 where others indicate the need for use_frameworks!, and some workarounds that may work for you (your mileage may vary).
The other option is to use<EMAIL_ADDRESS>which has use_frameworks! support.

I managed to resolve the No such module 'React' error and successfully build iOS app. My steps:

Upgrade my React-Native dependency from RN 0.60.5 to RN 0.61.0-rc.3 via React Native Upgrade Helper
Add the line use_frameworks! to your Podfile, under target '<your target name>' do
Perform fresh install of your Pods ($ pod install)
In Xcode, clean your project and delete Derived Data
Build/Run your app

Please note that RN 0.61 is still a release candidate and not yet stable at the time of this post. Use with caution.

Hi, I was experiencing same issue in my project and have finally fixed it by turning ONLY_ACTIVE_ARCH = 'NO' in Build Config tab on Pods project in XCode on RN 0.61.2 version.
I added post_install hook to Podfile:
post_install do |installer_representation|
  installer_representation.pods_project.build_configurations.each do |config|
    config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
  end

  installer_representation.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
    end
  end
end

Hopefully this will help.

@Marcus172 Thank you!
This solution works @ v0.61.5

Having the same issue. When I try @xutopia 's solution I have issues with the test framework file disappearing.

@ivoilic, I'm assuming your test framework file is somehow tied with your pods. Hence why the file is disappearing when you perform fresh pods install?
Maybe try manually adding the test framework file back into your project after fresh pod install?

I am facing the same issue. Any solution?


Automated Prometheus version update 0.60.1-41.7.3

Automated changes by the cron-prometheus-update GitHub action
Adds [Prometheus add-on](https://kurl.sh/docs/add-ons/prometheus) version 0.60.1-41.7.3.

Minimized diff:
diff -r ../diff/0.60.1-41.7.3/Manifest ../diff/0.59.1-40.1.0/Manifest
2c2
< image grafana grafana/grafana:9.2.3
---
> image grafana grafana/grafana:9.1.4
6c6
< image prometheus quay.io/prometheus/prometheus:v2.39.1
---
> image prometheus quay.io/prometheus/prometheus:v2.38.0
8,9c8,9
< image prometheus-config-reloader quay.io/prometheus-operator/prometheus-config-reloader:v0.60.1
< image prometheus-operator quay.io/prometheus-operator/prometheus-operator:v0.60.1
---
> image prometheus-config-reloader quay.io/prometheus-operator/prometheus-config-reloader:v0.59.1
> image prometheus-operator quay.io/prometheus-operator/prometheus-operator:v0.59.1
diff -r ../diff/0.60.1-41.7.3/crds/crds.yaml ../diff/0.59.1-40.1.0/crds/crds.yaml
2c2
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml
50c50
<                   alerts matching the resource's namespace.
---
>                   alerts matching the resource’s namespace.
64c64
<                         the alert matches the resource's namespace.
---
>                         the alert matches the resource’s namespace.
97c97
<                         the resource's namespace.
---
>                         the resource’s namespace.
1783c1783
<                               application's API token, see https://pushover.net/apps.
---
>                               application’s API token, see https://pushover.net/apps.
1813c1813
<                               user's user key. The secret needs to be in the same
---
>                               user’s user key. The secret needs to be in the same
4384c4384
<                   the resource's namespace. If present, it will be added to the generated
---
>                   the resource’s namespace. If present, it will be added to the generated
4410c4410
<                     description: 'List of matchers that the alert''s labels should
---
>                     description: 'List of matchers that the alert’s labels should
4480c4480
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagers.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagers.yaml
4507c4507
<     - description: The number of desired replicas
---
>     - description: The desired replicas number of Alertmanagers
4514,4518d4513
<     - description: Whether the resource reconciliation is paused or not
<       jsonPath: .status.paused
<       name: Paused
<       priority: 1
<       type: boolean
5829,5873d5823
<                   templates:
<                     description: Custom notification templates.
<                     items:
<                       description: SecretOrConfigMap allows to specify data as a Secret
<                         or ConfigMap. Fields are mutually exclusive.
<                       properties:
<                         configMap:
<                           description: ConfigMap containing data to use for the targets.
<                           properties:
<                             key:
<                               description: The key to select.
<                               type: string
<                             name:
<                               description: 'Name of the referent.   Must
<                                 be a valid secret key.
<                               type: string
<                             name:
<                               description: 'Name of the referent.  Each ConfigMap is added to the StatefulSet definition as a
<                   volume named `configmap-<configmap-name>`. The ConfigMaps are mounted
<                   into `/etc/alertmanager/configmaps/<configmap-name>` in the 'alertmanager'
<                   container.
---
>                   Pods. The ConfigMaps are mounted into /etc/alertmanager/configmaps/<configmap-name>.
5909c5856
<                   for this Alertmanager instance. If empty, it defaults to `alertmanager-<alertmanager-name>`.
---
>                   for this Alertmanager instance. If empty, it defaults to 'alertmanager-<alertmanager-name>'.
8554,8556c8501
<                   Pods. Each Secret is added to the StatefulSet definition as a volume
<                   named `secret-<secret-name>`. The Secrets are mounted into `/etc/alertmanager/secrets/<secret-name>`
<                   in the 'alertmanager' container.
---
>                   Pods. The Secrets are mounted into /etc/alertmanager/secrets/<secret-name>.
11317c11262
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml
11506,11509d11450
<                     filterRunning:
<                       description: 'Drop pods that are not running. (Failed, Succeeded).
<                         Enabled by default. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase'
<                       type: boolean
11987c11928
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_probes.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_probes.yaml
12694c12635
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheuses.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheuses.yaml
12721c12662
<     - description: The number of desired replicas
---
>     - description: The desired replicas number of Prometheuses
12723,12727c12664
<       name: Desired
<       type: integer
<     - description: The number of ready replicas
<       jsonPath: .status.availableReplicas
<       name: Ready
---
>       name: Replicas
12729,12734d12665
<     - jsonPath<EMAIL_ADDRESS>== 'Reconciled')].status
<       name: Reconciled
<       type: string
<     - jsonPath<EMAIL_ADDRESS>== 'Available')].status
<       name: Available
<       type: string
12738,12742d12668
<     - description: Whether the resource reconciliation is paused or not
<       jsonPath: .status.paused
<       name: Paused
<       priority: 1
<       type: boolean
12825,12826c12751,12752
<                   which may cause issues if they are invalid or not supported by the
<                   given Prometheus version. In case of an argument conflict (e.g.
---
>                   which may cause issues if they are invalid or not supporeted by
>                   the given Prometheus version. In case of an argument conflict (e.g.
14170,14173c14096
<                   Pods. Each ConfigMap is added to the StatefulSet definition as a
<                   volume named `configmap-<configmap-name>`. The ConfigMaps are mounted
<                   into /etc/prometheus/configmaps/<configmap-name> in the 'prometheus'
<                   container.
---
>                   Pods. The ConfigMaps are mounted into /etc/prometheus/configmaps/<configmap-name>.
15585,15590d15507
<               hostNetwork:
<                 description: Use the host's network namespace if true. Make sure to
<                   understand the security implications if you want to enable it. When
<                   hostNetwork is enabled, this will set dnsPolicy to ClusterFirstWithHostNet
<                   automatically.
<                 type: boolean
18234,18236c18151
<                   Pods. Each Secret is added to the StatefulSet definition as a volume
<                   named `secret-<secret-name>`. The Secrets are mounted into /etc/prometheus/secrets/<secret-name>
<                   in the 'prometheus' container.
---
>                   Pods. The Secrets are mounted into /etc/prometheus/secrets/<secret-name>.
19097c19012
<                       or not supported the given Thanos version. In case of an argument
---
>                       or not supporeted the given Thanos version. In case of an argument
19120,19124d19034
<                   grpcListenLocal:
<                     description: If true, the Thanos sidecar listens on the loopback
<                       interface for the gRPC endpoints. It has no effect if `listenLocal`
<                       is true.
<                     type: boolean
19126,19127c19036,19037
<                     description: 'GRPCServerTLSConfig configures the TLS parameters
<                       for the gRPC server providing the StoreAPI. Note: Currently
---
>                     description: 'GRPCServerTLSConfig configures the gRPC server from
>                       which Thanos Querier reads recorded rule data. Note: Currently
19260,19264d19169
<                   httpListenLocal:
<                     description: If true, the Thanos sidecar listens on the loopback
<                       interface for the HTTP endpoints. It has no effect if `listenLocal`
<                       is true.
<                     type: boolean
19272,19275c19177,19178
<                     description: 'If true, the Thanos sidecar listens on the loopback
<                       interface for the HTTP and gRPC endpoints. It takes precedence
<                       over `grpcListenLocal` and `httpListenLocal`. Deprecated: use
<                       `grpcListenLocal` and `httpListenLocal` instead.'
---
>                     description: ListenLocal makes the Thanos sidecar listen on loopback,
>                       so that it does not bind against the Pod IP.
19652,19665d19554
<               tsdb:
<                 description: Defines the runtime reloadable configuration of the timeseries
<                   database (TSDB).
<                 properties:
<                   outOfOrderTimeWindow:
<                     description: Configures how old an out-of-order/out-of-bounds
<                       sample can be w.r.t. the TSDB max time. An out-of-order/out-of-bounds
<                       sample is ingested into the TSDB as long as the timestamp of
<                       the sample is >= (TSDB.MaxTime - outOfOrderTimeWindow). Out
<                       of order ingestion is an experimental feature and requires Prometheus
<                       >= v2.39.0.
<                     pattern: ^(0|(([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)?)$
<                     type: string
<                 type: object
21458,21465d21346
<                     observedGeneration:
<                       description: ObservedGeneration represents the .metadata.generation
<                         that the condition was set based upon. For instance, if .metadata.generation
<                         is currently 12, but the .status.conditions[x].observedGeneration
<                         is 9, the condition is out of date with respect to the current
<                         state of the instance.
<                       format: int64
<                       type: integer
21558c21439
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheusrules.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_prometheusrules.yaml
21659c21540
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml
22346c22227
< # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.60.1/example/prometheus-operator-crd/monitoring.coreos.com_thanosrulers.yaml
---
> # https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.59.1/example/prometheus-operator-crd/monitoring.coreos.com_thanosrulers.yaml
22369c22250
<     - description: The number of desired replicas
---
>     - description: The desired replicas number of Thanos Rulers
22376,22380d22256
<     - description: Whether the resource reconciliation is paused or not
<       jsonPath: .status.paused
<       name: Paused
<       priority: 1
<       type: boolean
diff -r ../diff/0.60.1-41.7.3/install.sh ../diff/0.59.1-40.1.0/install.sh
19,20d18
<     # Also delete any existing last-applied-configuration annotations for pre-122 clusters
<     kubectl get crd | grep coreos.com | awk '{ print $1 }' | xargs -I {} kubectl patch crd {} --type=json -p='[{"op": "remove", "path": "/metadata/annotations/kubectl.kubernetes.io~1last-applied-configuration"}]' 2>/dev/null
diff -r ../diff/0.60.1-41.7.3/operator/adapter.yaml ../diff/0.59.1-40.1.0/operator/adapter.yaml
261c261
<         checksum/config: dc936b24f0d9933a909ba714a0baba8449c8df33618b61a18233d1c6f3bcd0fe
---
>         checksum/config: 5109ca4b1192ad4bbd0d705a3ee715dc694429e1a79a82e98b26655b3edf96f2
diff -r ../diff/0.60.1-41.7.3/operator/default.yaml ../diff/0.59.1-40.1.0/operator/default.yaml
150c150
<     domain = ''
---
>     domain =
39183,39187d39182
< - apiGroups: ["coordination.k8s.io"]
<   resources:
<   - leases
<   verbs: ["list", "watch"]
<
39886c39881
<         checksum/config: 7da387ee2fa86926d4ecc9447aec9c4f509de93d960007cc203beee9681ea6a8
---
>         checksum/config: 4be064c4f92881a8b6ade02418cab9053518f0bc66ef2a88c23abb02e93ca147
39888c39883
<         checksum/sc-dashboard-provider-config: 4aa950cee484ef593634874abd479291a66b4ebba44b55e1a16d13e56d3ed48d
---
>         checksum/sc-dashboard-provider-config: bb3cb565c799e56da07e9643b290b81811ce6ea973ab04714729a72716dccbc5
39947c39942
<           image: "grafana/grafana:9.2.3"
---
>           image: "grafana/grafana:9.1.4"
40052c40047
<         - --resources=certificatesigningrequests,configmaps,cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,ingresses,jobs,leases,limitranges,mutatingwebhookconfigurations,namespaces,networkpolicies,nodes,persistentvolumeclaims,persistentvolumes,poddisruptionbudgets,pods,replicasets,replicationcontrollers,resourcequotas,secrets,services,statefulsets,storageclasses,validatingwebhookconfigurations,volumeattachments
---
>         - --resources=certificatesigningrequests,configmaps,cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,ingresses,jobs,limitranges,mutatingwebhookconfigurations,namespaces,networkpolicies,nodes,persistentvolumeclaims,persistentvolumes,poddisruptionbudgets,pods,replicasets,replicationcontrollers,resourcequotas,secrets,services,statefulsets,storageclasses,validatingwebhookconfigurations,volumeattachments
40099c40094
<           image: "quay.io/prometheus-operator/prometheus-operator:v0.60.1"
---
>           image: "quay.io/prometheus-operator/prometheus-operator:v0.59.1"
40104c40099
<             - --prometheus-config-reloader=quay.io/prometheus-operator/prometheus-config-reloader:v0.60.1
---
>             - --prometheus-config-reloader=quay.io/prometheus-operator/prometheus-config-reloader:v0.59.1
40191,40192c40186,40187
<   image: "quay.io/prometheus/prometheus:v2.39.1"
<   version: v2.39.1
---
>   image: "quay.io/prometheus/prometheus:v2.38.0"
>   version: v2.38.0
41575c41570
<             kube_pod_status_phase{job="kube-state-metrics", namespace=~".*", phase=~"Pending|Unknown|Failed"}
---
>             kube_pod_status_phase{job="kube-state-metrics", namespace=~".*", phase=~"Pending|Unknown"}
42037d42031
<       for: 5m
42046d42039
<       for: 5m
43116c43109
<   jobLabel: app.kubernetes.io/name
---
>   jobLabel: app.kubernetes.io/name
43140c43133
<
---
>
43168d43160
<     enableHttp2: true

(helm annotations removed, etc)


Solve compatibility issue with GPflow master

Codecov Report

Merging #41 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #41   +/-   ##
=======================================
  Coverage   99.71%   99.71%
=======================================
  Files           8        8
  Lines         690      690
=======================================
  Hits          688      688
  Misses          2        2

Impacted Files
Coverage Δ

GPflowOpt/scaling.py
100% <100%> (ø)
: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 7679a68...b2929b4. Read the comment docs.


XML Example not working

when i copy the xml example to notepad and save it as *.xml i get errors.
There seams to be an issue with the space characters used in the example.
When i delete the spaces and create new ones it works.

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

ID: 2317a87f-90c3-7756-7fe3-1c54c2b4b3be
Version Independent ID: 0757751f-bfb5-fe20-45b5-c202889bc1d3
Content: MSIX Shared Package Container - MSIX
Content Source: msix-src/manage/shared-package-container.md
Product: msix
GitHub Login: @dianmsft
Microsoft Alias: diahar

i realized that i also had to recreate all the line breaks, otherwise i could not use the example with the add command

Thanks for posted this. We updated the documented accordingly.


No apparent way to get column for a visible editor

As of VSCode API Version: 0.11.0, it seems to be impossible to get column of the active editor from a TypeScript extension.
This is quite strange considering typings for vscode.window.showTextDocument():
/**
 * Show the given document in a text editor. A [column](#ViewColumn) can be provided
 * to control where the editor is being shown. Might change the [active editor](#window.activeTextEditor).
 *
 * @param document A text document to be shown.
 * @param column A view column in which the editor should be shown. The default is the [one](#ViewColumn.One), other values
 * are adjusted to be __Min(column, columnCount + 1)__.
 * @return A promise that resolves to an [editor](#TextEditor).
 */
export function showTextDocument(document: TextDocument, column?: ViewColumn): Thenable<TextEditor>;

Could you please add a viewColumn property to the TextEditor interface?
See https://github.com/bbenoist/vscode-togglehs/issues/2 for the initial reasons of my request

Temporary trick in case others are suffering from the same issue:
function getTextEditorViewColumn(textEditor:any) : number {
  return textEditor._viewColumn;
}

It does exist as 'TextEditor.viewColumn'
@bbenoist Aure you sure you are using a recent version of vscode.d.ts?


Schedule DHT re-announce after announce completes

Supersedes this PR: https://github.com/feross/torrent-discovery/pull/16
cc @mafintosh @oleiba

Does this look good to you @oleiba?

Yup. Scheduling a re-announce once previous has completed ensures seeds will not stop being available, and this solution still ensures no simultaneous announces.
I was wondering about how to make DHT announces to complete faster than tens of minutes when seeding hundreds of files (this issue makes initial seeds to be available only once in a few announce cycles of the downloader client) - but I suppose that's a separate issue.
Thanks!

@oleiba Yes, that's a separate issue. Consider opening that as a new issue on bittorrent-dht.

Released as 5.3.3.


Upgrade libkermit and dependencies

And use ContainerAPIClient where needed 👼
🐸
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

LGTM

Hum Travis is not working again...

LGTM


First Actual Working Code

@jfkhoury Obviously, this is a WIP, but I thought I'd do a PR so that you can comment. I haven't tried updating props yet, so that code is untested. You can play with the alpha component on this pen.

neat 🍍

I suggest using built in React inline styles which will make life much much simples. You can use JSS for the keyframe style only, and have 2 little factory functions that give you a sheet for the top spinner element, and replace the ::after with a child div that get's it's own styles from the second factory function.

Yes would like to see some tests. We just started playing around Enzyme, so definitely sounds like a good choice.

@pbouzakis: You wanted tests? You got 'em! And using Travis CI to boot!


zls not working unless   zig.zls.path explicitly set

zls isn't working when zig.zls.path is set to "",
{
  "zig.path": "",
  "zig.zls.path": "",
  "zig.initialSetupDone": true
}

Both zig and zls are part of the $PATH used by VS Code. From the integrated terminal,
$ which zig
/home/user/.local/bin/zig

$ which zls
/home/user/.local/bin/zls

Only after explicitly setting zls' path does it work.

Fixed by #189, I'll release a new version soon.


verify-subtree.sh: relax check and ignore old content

If for whatever reasons a repo already had a release-tools directory
before doing a clean import of it with git subtree, the check used
to fail because it found those old commits.
This can be fixed by telling git log to stop when the directory
disappears from the repo. There has to be a commit with removes the
old content, because otherwise git subtree add doesn't work.
Fixes: https://github.com/kubernetes-csi/external-resizer/issues/21

/lgtm

@pohly can you address comments here:
I have been thinking some more about it. Does it make sense to use a content based diff for verifying subtree changes rather than git log based one? Something like:
git remote add csi-release-tools_root https://github.com/kubernetes-csi/csi-release-tools.git
git fetch csi-release-tools_root
git diff remotes/csi-release-tools_root/master HEAD:release-tools/
It does mean all CSI repos must have latest version of release-tools.

It does mean all CSI repos must have latest version of release-tools.

Exactly, and that is the problem. Each time we update the csi-release-tools master, the PR checks in all repos using it will start failing. Same for all old branches which have to be on an older revision (for example, because master adds new source code checks that older release do not pass).
One could argue that this is intentional because it forces maintainers to drop everything they are doing and sync up with csi-release-tools. But I find that rather intrusive and for older branches it may not be right.
Instead, the git diff could be against the revision that was imported. But determining that can only be done my parsing the commit messages, and that is probably not easier than the current approach.


fix(anvil): handle OP deposit txs in TypedTransaction and PoolTransaction conversion

Motivation
Fixes #8940

Solution
Change TryFrom implementations of PoolTransaction and TypedTransaction to use WithOtherFields<RpcTransaction> instead of RpcTransaction

unrelated error


Expose way to know if connection to Broker is lost then later regained

A client may have the need to expose its health to the rest of the system (Kubernetes) and so client needs a way to know if the parallel consumer connection to the broker has been lost. It later needs to be informed if the connection has been re-established.

@fowlerp-qlik are there mechanisms from the Kafka clients for this that you want exposed? Have you looked at available JMX metrics from the raw clients?

@fowlerp-qlik do you specifically want to be informed of connection state changes, or is it enough to have the state exposed through metrics / health check?

I've also just realised that AK consumer doesn't actually expose this either. We will be adding metrics very soon, let's see if that will be enough. Otherwise, we can also implement some active health check system like starting an admin client and interrogating the cluster about something.


Revert "Collapse HorizontalAlignment and VerticalAlignment modifiers into one (#1287)"

This reverts commit 794ae03db30498b8af84bcc5ecf9c4103b824dc7.
I'd argue that we shouldn't make this change for a couple reasons:

We lose consistency with the horizontalAlignment and verticalAlignment arguments for the Row and Column functions.

When we support a Box type we'll need to create separate HorizontalAlignment and VerticalAlignment modifiers anyways since we need to be able to configure the alignment for an individual item across both dimensions:

Box {
    Image(
        url = url,
        modifier = Modifier
            .horizontalAlignment(CrossAxisAlignment.Center)
            .verticalAlignment(CrossAxisAlignment.Center),
    )
}

It changes the public API names to be less clear:

Column {
    Image(url, modifier = Modifier.alignment(CrossAxisAlignment.Center)
}

It's less clear because it doesn't specify if we're aligning on the horizontal or vertical axis:
Column {
    Image(url, modifier = Modifier.horizontalAlignment(CrossAxisAlignment.Center)
}

I could see someone applying alignment thinking it changes the vertical alignment in a Column.

The main motivation for such a change is to implement #1261. The LazyList scope doesn't distinguish between whether it's a LazyColumn or LazyRow, and personally I don't believe it needs to be.

We lose consistency with the horizontalAlignment and verticalAlignment arguments for the Row and Column functions.

I'd argue that we gain consistency with two platforms that people are comfortable with — Android and the web (I can't speak for iOS).

In Compose UI, in order to align a single item within a Row/Column, we call Modifier.align. They also have this "inconsistency" where Row/Column gets passed a horizontalAlignment/verticalAlignment respectively, despite the children calling align.
In web, in order to align a single item within a flex element in either direction, we call align-self.

None of these state which direction we need to put it in, because it is evident from the parent.

It changes the public API names to be less clear

The example you gave is almost exactly the same as what Compose UI does.

It's less clear because it doesn't specify if we're aligning on the horizontal or vertical axis

I think we should use the CSS definition of alignment (as much of the Row/Column API is CSS-y).  If we're in a Row, you can only align on the vertical axis. By definition, alignment on the horizontal axis doesn't make sense, as moving stuff along the horizontal axis would be to "justify" it (and perhaps we should rename the MainAxisAligment properties too).

The main motivation for such a change is to implement https://github.com/cashapp/redwood/issues/1261. The LazyList scope doesn't distinguish between whether it's a LazyColumn or LazyRow, and personally I don't believe it needs to be.

Ah gotcha, I agree it doesn't have to use separate scopes, however I think it's better as an API consumer to have separate Modifier names. Using a single scope for LazyRow and LazyColumn also locks us into no direction specific modifiers in the future (due to binary compatibility) even if it's unlikely.

I'd argue that we gain consistency with two platforms that people are comfortable with — Android and the web (I can't speak for iOS).
The example you gave is almost exactly the same as what Compose UI does.

Compose UI uses align, however the major difference is the values passed to align imply horizontal or vertical alignment (e.g. Top, CenterVertically, Start, CenterHorizontally). CrossAxisAlignment uses Start and End for vertical alignment as well. As a result, we should either change the values passed to alignment so they imply direction (and come up with a proposal) or we should keep the directions in the method names.

I think we should use the CSS definition of alignment

I disagree. The CSS names for horizontal and vertical alignment aren't very intuitive. It's impossible to know which direction Modifier.justifyContent changes without understanding the CSS spec. Modifier.horizontalAlignment is clear about what it does without searching.
As mentioned, we will need two separate horizontalAlignment and verticalAlignment modifiers for Box so it's better to use horizontalAlignment and verticalAlignment for our other layout components to remain consistent.

Ah gotcha, I agree it doesn't have to use separate scopes

If we decide to go with horizontalAlignment/verticalAlignment, we will have to introduce another scope to LazyList, so that the *Alignment properties switch the *AxisAlignment types (so horizontalAlignment will be MainAxisAlignment in Row, but CrossAxisAlignment in Column. I think you implied this in the rest of the paragraph, but I just wanted to make it clear.

Compose UI uses align, however the major difference is the values passed to align imply horizontal or vertical alignment (e.g. Top, CenterVertically, Start, CenterHorizontally).

I like this less than having separate alignments tbh. I suppose my proposal solely aligns with CSS and not Compose UI.
The reason I like this less is that it isn't very accessible. Imo we should not only support LTR and RTL writing modes, but also top-to-bottom (like Japanese). Words like "top" have the same language centricity as "left" or "right" does. Granted, the words "row" and "column" also have this issue too.

I disagree. The CSS names for horizontal and vertical alignment aren't very intuitive. It's impossible to know which direction Modifier.justifyContent changes without understanding the CSS spec. Modifier.horizontalAlignment is clear about what it does without searching.

I assumed that having a CSS-like API was our north-star, as if someone didn't understand what something means, they can Google it. I'm a fan of that idea, as it means people don't have to learn esoteric APIs, even if they're debatably easier to learn. Also, it's a lot easier for people to jump into this if they have CSS knowledge already, and if they don't, learning CSS things is applicable outside of Redwood.
Granted, I'm thinking about discussions we (the Treehouse team) had about year ago, so perhaps the zeitgeist has since changed.

As mentioned, we will need two separate horizontalAlignment and verticalAlignment modifiers for Box so it's better to use horizontalAlignment and verticalAlignment for our other layout components to remain consistent.

Coming from CSS, a Box is achieved by just using flexbox, so you'd just use the align and justify properties, by first choosing a random direction you want to use (Row or Column). Again, debatably harder API, but less esoteric.

I think I'm debating a larger change than anticipated. Feel free to merge this, and I can update LazyList to take a horizontalAlignment and verticalAlignment.


Kieran/personalize analytics page with pub data

Description
Personalize the advanced analytics page dashboard -> analytics -> advanced analytics (beta) with blog details. Previous it just looked like analytics for Hashnode and not blog specific. This includes:

Meta title, description, ogImage and favicon
Header logo/title

These should match blogs for the same circumstances.
Vercel deployment of Umami analytics - https://vercel.com/hashnode-prod/hn-analytics-umami
Notes:

Since this analytics setup may be temporary (we might move out in the future), it was not worth implementing graphql for the pub data fetching here. GSSP fetch to an api on Main is sufficient. I checked with Bahaa who agreed.

BEFORE MERGING TO PROD - Set NEXT_PUBLIC_HASHNODE_ENV in Vercel

Testing

add your .env file with the following envs:

NEXT_PUBLIC_HASHNODE_ENV=development
DATABASE_URL='Find in vercel'
HASH_SALT='Find in vercel'

Build with yarn build

Run with yarn dev -p some other port

Run your hashnode servers (using the Hashnode Main kieran/personalize-analytics-page-with-pub-data branch).

Now you can access the advanced analytics /share pages locally e.g. /share/:umamiShareId/:UmamiWebsiteUUID

Umami details are on the publication model e.g. publication.umamiShareId.

Test out different publications with different settings

Regular pub and Team pub: With/without logo, dark mode logo, title, seo title, seo descrtiption, ogImage, favicon.

Open up the blog in the next tab to help with comparison. Everything should match as it does in Blogs.

@kieran6roberts Adding my observations here :-

For rogue umamiShareId/umamiWebsiteUUID - can we return a 404 page ?

@kieran6roberts Adding my observations here :-

For rogue umamiShareId/umamiWebsiteUUID - can we return a 404 page ?
Unable to see author's profile photo for mobile view -

Have updated to return not found when we can't get the publication using the given umamiShareId.
The profile image is intentionally hidden on mobile, the same as we do for blogs. We could include the profile image (for regular publications) in the top left corner if you think that's better (I'll show an example below). Let me know what you think.


Dont assume the Group name is the same as the users name

This causes the services to fail if that group does not exist.

Thanks


Ssc 1256 better hybrid batteries

Fixes #1256
Pairs with https://github.com/NREL/SAM/pull/1958
Overwrites "gen" in the hybrids compute module with the battery's gen, since the battery gen is an inout and include the total powerflow from all components.
Calculates annual and monthly energy values after the battery runs to capture them in the values.
Updates the test to compare these energy metrics and make sure everything is included in the annual outputs.

That's fine I think, then O&M production-based expense scales with net generation. Is that right?

Hybrid VOM is based on energy to grid, not net generation. I've set up a few test cases where the net generation is negative, do these make sense to you?
hybrid_vom_tests.zip

That's fine I think, then O&M production-based expense scales with net generation. Is that right?

Hybrid VOM is based on energy to grid, not net generation. I've set up a few test cases where the net generation is negative, do these make sense to you? hybrid_vom_tests.zip

Yes that looks right.


Add unit tests to ensure submodules are causal and streamable

Checklist

[ X ] Read CONTRIBUTING.md, and accept the CLA by including the provided snippet. We will not accept PR without this.
[ X ] Run pre-commit hook.
[ X ] If you changed Rust code, run cargo check, cargo clippy, cargo test.

PR Description
Add unit tests to check that the following submodules are causal and streamable:

StreamingConv1d
StreamingConvTranspose1d
SEANetResnetBlock
SEANetDecoder

Please see the related issue for more context.
CLA Snippet:
I, jerryli27, confirm that I have read and understood the terms of the CLA of Kyutai-labs, as outlined in the repository's CONTRIBUTING.md, and I agree to be bound by these terms.

Thanks!


response.headers()

https://developer.mozilla.org/en-US/docs/Web/API/Response/headers
Is there any reason response.headers() isn't implemented, out of curiosity?
On that note, are there any plans to aim closer to the core fetch standard? There are enough differences in output that I've had to write a wrapper to this library so it can place nicely with the other fetch functions.

@braco ,  thanks for the suggestion. I think this has already been addressed in #281 please move to that thread 😃 . Basically, I think this one should be corrected but I'm very busy and there're still tons of issues and requirements coming over. Will hand on this issue when I have time, and of course, a PR is definitely welcome 👍


chore: storybook upgrade

Contributes to #2846
This is a work in progress.

I have removed the storybook theme addon temporarily.
Upgrade was automatiic from the packages/core folder. - see storybook-upgrade-log.txt
Installed other parts suggested when attempting to run storybook
yarn storybook fails complaining about dynamic titles.
yarn storybook:build never completes - see storybook-build-log.txt

NOTE: Planning to upgrade CSF to v3 or MDX to v2 separately if possible.


The mod doesn't work with Majrusz's Enchantments

After disabling some enchantments from Majrusz's Enchantments, they are still accesible via enchanting table.

Minecraft 1.20.1 with Fabric Loader 0.15.6

enchantmentdisabler 0.1.4
fabric-api 0.91.1+1.20.1
majruszlibrary 7.0.5
majruszsenchantments 1.10.6

The mod seems to have it's own way of registering enchantments to the game, and I'm not really interested in supporting custom systems like this.
But it appears that the mod has its own configuration where you can enable/disable enchantments from the mod - maybe try that out.


Flush out and fix edge case bugs in async RPC

Unknown issue causing unexpected behaviour -
Hunting it down and resolving it.

Changes addressing this issue have been shipped. Closing per @Tomperez98 and @avillega


[WIP] Add basic I/O APIC support.

Summary
Add basic I/O APIC support with the ioapic module in mythril_core.
TODO

[x] Make the IoApic more usable

[x] Add a Mutex
[x] Add tests
[x] Find the available I/O APICS in kmain

[x] Make use of the IO APIC

Fixes: #26

@ALSchwalm We're getting the I/O APIC version and ID from the I/O APIC. Is there anything else you'd like me to do in the initial implementation?
Loading Mythril
[   0.000000] MYTHRIL-INFO: tsc calibrate diff=3094413 (khz=1802831)
[   0.000018] MYTHRIL-INFO: Allocating from 0x1f58ae8-3ffe0000
[   0.001764] MYTHRIL-INFO: RSDP: revision=1.0 rsdt=0x3ffe15c9
[   0.003675] MYTHRIL-INFO: RSDT: rev=1 length=48 table=0x3ffe15ed
[   0.005703] MYTHRIL-INFO: FACP: rev=1 length=116 table=0x3ffe14c1
[   0.007695] MYTHRIL-INFO: APIC: rev=1 length=128 table=0x3ffe1535
[   0.009740] MYTHRIL-INFO: HPET: rev=1 length=56 table=0x3ffe15b5
[   0.011808] MYTHRIL-INFO: HPET: rev=1 length=56 table=0x3ffe15b5 HPET address=0xfed00000
[   0.014580] MYTHRIL-INFO: IOAPIC: id: 0 version: 0x11 address: 0xfec00000 GSI: 0

@ALSchwalm updated

Looks good to me. Merged


Master into develop

Coverage remained the same at 44.624% when pulling b4a07c6135edff1b3afbacad14246e570bb2f3e9 on benjaoming:develop into 53c3ef89cd3456255a6901f70fcf32ec8b7eae1c on xhtml2pdf:develop.

Coverage remained the same at 44.624% when pulling 1bf3169485c4a669d3c8d65658846702bfe0f73c on benjaoming:develop into 53c3ef89cd3456255a6901f70fcf32ec8b7eae1c on xhtml2pdf:develop.


Added formats and updated libraries

Description

Added the option to set the image type
Updated the dependencies
Made the functions static, since I don't really see the need of instantiating the class for this usecases

Type of Change

[x] ✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[x] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[ ] 🗑 Chore

Thank you for the change. Great ideas!

If u publish this to pub dev put a higher major or minor versioning number cause this does include breaking changes btw!
A patch number might result in people getting bad dependencies resolved 😊


Nested properties

This adds the ability to retrieve nested properties from package.json mentioned in #2.

I rebased this to remove the merge conflicts. Should be good to go now :)

Thanks a lot and sorry for the delay

published as v1.0.0


[rancher/charts] RFE: Take ownership of CRDs that already exist in the cluster

For CRD charts, if the CRD is already installed onto a cluster we should patch the existing CRD with the ownership metadata for the CRD chart so that it is now managed by the CRD chart's lifecycle.
This is required for rancher-monitoring in particular since the CRDs usually come pre-installed in a Rancher cluster.

Temporary workaround for this issue is to delete the CRDs from the cluster before installing monitoring:
kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com # technically not needed since v1 monitoring never installed this in the first place iirc
kubectl delete crd alertmanagers.monitoring.coreos.com
kubectl delete crd thanosrulers.monitoring.coreos.com

Note: the approach mentioned above has been slightly altered based on discussions in design meetings. Please see https://github.com/rancher/charts/pull/595 for updated information on the design.
The new design will still enable the CRD chart to assume ownership of any existing CRDs in the cluster and will delete the CRDs on an uninstall.

The enhancement is validated on rancher:master-f7f8e8bb0649e6f163bd6ba2118622a9889236ce-head HA setup with the latest chart
The monitoring v2 app is installed into the local cluster successfully without deleting the existing CRDs