raftstore: init half split region

[x] dev

[x] test

@overvenus @BusyJay PTAL

The test failed.
test raftstore_cases::test_split_region::test_node_half_split_region ... key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 49],current_size:74,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 50],current_size:148,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 51],current_size:222,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 52],current_size:296,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 53],current_size:370,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 54],current_size:444,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 55],current_size:518,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 56],current_size:592,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 48, 57],current_size:666,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 48],current_size:740,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 49],current_size:814,region_size:1480
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 49],current_size:74,region_size:666
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 50],current_size:148,region_size:666
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 51],current_size:222,region_size:666
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 52],current_size:296,region_size:666
key:[122, 48, 48, 48, 48, 48, 48, 48, 49, 53],current_size:370,region_size:666
thread 'raftstore_cases::test_split_region::test_node_half_split_region' panicked at 'assertion failed: `(left == right)`
  left: `[48, 48, 48, 48, 48, 48, 48, 49, 53]`,
 right: `[48, 48, 48, 48, 48, 48, 48, 49, 49]`', tests/raftstore_cases/test_split_region.rs:766:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:68
             at libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: tikv::util::panic_hook::track_hook::{{closure}}
             at src/util/panic_hook.rs:59
   5: <std::thread::local::LocalKey<T>>::try_with
             at /checkout/src/libstd/thread/local.rs:377
   6: <std::thread::local::LocalKey<T>>::with
             at /checkout/src/libstd/thread/local.rs:288
   7: tikv::util::panic_hook::track_hook
             at src/util/panic_hook.rs:53
   8: core::ops::function::Fn::call
             at /checkout/src/libcore/ops/function.rs:73
   9: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:577
  10: std::panicking::begin_panic
             at libstd/panicking.rs:537
  11: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
  12: integrations::raftstore_cases::test_split_region::test_half_split_region
             at tests/raftstore_cases/test_split_region.rs:766
  13: integrations::raftstore_cases::test_split_region::test_node_half_split_region
             at tests/raftstore_cases/test_split_region.rs:738
  14: <F as alloc::boxed::FnBox<A>>::call_box
             at libtest/lib.rs:1440
             at /checkout/src/libcore/ops/function.rs:223
             at /checkout/src/liballoc/boxed.rs:817
  15: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
FAILED

https://circleci.com/gh/pingcap/tikv/8580?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

@overvenus @BusyJay @huachaohuang PTAL

We will merge master && fix conflicts after https://github.com/pingcap/kvproto/pull/229 merged

@BusyJay @overvenus @huachaohuang PTAL

PTAL

friendly ping @overvenus @BusyJay @huachaohuang

@overvenus @BusyJay @huachaohuang PTAL


Fix version of web3 to resolve BC breaks

we have to lock web3 at v5.20.0 since after that version they switched to websockets of v9.1 which brings BC break (comparing to v8.1) to our code by deprecating some classes that we use. I.e. websockets.protocol became websockets.legacy.protocol.
Related to #272
┆Issue is synchronized with this Asana task by Unito

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Why don't we simply do a compatible import, i.e.
try:
    from x.websockets import protocol as websocketsprotocol
except:
    from x.legacy.websockets import protocol as websocketsprotocol

?

@e271828-, there might be other incompatibilities as well. Although, there is a list of BC breaks: https://websockets.readthedocs.io/en/latest/project/changelog.html#id11 :thinking:
I can do some investigation on the usage of code that was moved/deprecated if you think it's worth spending time on it.

@e271828-, there might be other incompatibilities as well. Although, there is a list of BC breaks: https://websockets.readthedocs.io/en/latest/project/changelog.html#id11 🤔 I can do some investigation on the usage of code that was moved/deprecated if you think it's worth spending time on it.

Seems like we should at minimum switch to use the new refs so we can upgrade. Pinning to an arbitrary stale version with no ability to move forward short of code changes will make any security-related upgrades challenging.

Makes sense 👍 will do

@e271828- we are done here, since the hmt-escrow don't use the websockets package directly. BC breaks should be handled on our side. Please review/publish if all fine in the PR


Application::share not working in Laravel 5.4

Hi!
The share method has been taken out in Laravel 5.4, so this package is broken in that Laravel version.
You can solve the problem by using the singleton method tho.
Can you please take a look at that?

Thanks for pointing that out! I've updated the service provider and tagged a new release.

Thank you very much!


My True Form mod starts with two of each of the main game's forms

This feels like a bug in the frameworks we're using and not ours, since only one of Arcane Form is added.

I agree, it would make more sense to add this as a patch in BaseMod based on the BaseModCardTags.FORM tag

Tracking as https://github.com/daviscook477/BaseMod/issues/235


tsm1_compact_group error - wait exceed's limiter's burst

May 21 21:49:23 <hostname> influxd[28202]: ts=2018-05-21T21:49:23.178413Z lvl=info msg="Error compacting TSM files" log_id=08DAIK40000 engine=tsm1 tsm1_level=1 tsm1_strategy=level trace_id=08DAh3CG000 op_name=tsm1_compact_group error="rate: Wait(n=116648469) exceeds limiter's burst 50331648"

Trying to diagnose high memory/cpu use on a server I recently upgraded to 1.5. Any pointers on what this error message indicates? Did not find any previous issues on this topic from searching.

a couple addenda to this:

I traced the error to a call to s.compactor.CompactFull(group) where s is a *compactionStrategy and group is s.group in func(s *compactionStrategy) compactGroup() in tsdb/engine/tsm1/engine.go - this is the only match to the string "Error compacting" in the v1.5.2 source code. However, I can't identify where the "rate: Wait(n=115868815) exceeds limiter's burst 50331648" part of the error message comes from.

I ended up deleting the database entirely that was the subject of these errors, and recreating it. The error messages subsided for a bit, but now they're back.

Is cpu usage expected to be much higher for 1.5 vs 1.4? Perhaps I'm trying to diagnose something that is expected behavior. My 1.5 install is using 20x what a 1.4 install was doing for the same workload. Memory usage is up significantly as well, although I haven't measure it.

additional steps I have tried:

upgrading tsm to tsi, and setting the config file to use tsi
dropping the database that was the subject of this error (again)
pointing influx to a new data and meta/wal dir and starting fresh (with tsi enabled)

Each time, the error comes back after about 45 minutes of operation.
Investigating how to downgrade, but previous versions do not seem to be available via the ppa.

Hitting the same issue in our 1.5.3 database. Any idea on how to change this limiter´s burst? We don´t find it in the configuration.

Breakthrough! I found where the limiter rate is set in the code!
in tsdb/store.go:
	// Env var to disable throughput limiter.  This will be moved to a config option in 1.5.
	if os.Getenv("INFLUXDB_DATA_COMPACTION_THROUGHPUT") == "" {
		s.EngineOptions.CompactionThroughputLimiter = limiter.NewRate(48*1024*1024, 48*1024*1024)
	} else {
		s.Logger.Info("Compaction throughput limit disabled")
	}

Guess they did not get around to putting this in the config options? haha.
I will play around with changing this number and building to see what happens.

Ok, so I added the following line to /etc/default/influxdb:
INFLUXDB_DATA_COMPACTION_THROUGHPUT=536870912

The original limit was 48 * 1024 * 1024 (hence why you couldn't find the number displayed in the error message by searching), so I set it to 512 * 1024 * 1024, but I think any setting at all just disables the entire limit. Which, is what we want, since the limit broke influx for us.
Restarted the server. Got this log message:
Jun 22 15:40:15 <host> influxd[20820]: ts=2018-06-22T15:40:15.736564Z lvl=info msg="Compaction throughput limit disabled" log_id=08r2IP_l000 service=store

influx proceeded to do a shitload of compactions that had been prevented by this bug for a long time. Now everything appears to be restored to normal - my server is usable again!
Would have been nice if someone who knows the codebase could have chimed in, say, a month ago, when I first posted this issue!

I observed the same problem on 1.5.3 and 1.5.4. (I'm running InfluxDB on Kubernetes)
It was simple enough to define the environment variable INFLUXDB_DATA_COMPACTION_THROUGHPUT and set it to 536870912 though as noted, the source code indicates the actual value doesn't matter.

user beware: it seems this mystery setting has migrated to the influxdb.conf file in version 1.7, leaving you vulnerable to mystifyingly terrible performance once again.
default settings:
compact-throughput = "48m"
compact-throughput = "48m"

(Note: regarding "exceeds limiter's burst 50331648" -- 1024 * 1024 * 48 == 50331648)
What I changed the settings to on a machine with 16gb ram:
compact-throughput = "512m"
compact-throughput = "1024m"

The initial compaction backlog pushed the system to its limits but made it through.
Just to clarify: as of 1.7 it appears that setting INFLUXDB_DATA_COMPACTION_THROUGHPUT will not longer protect you from "exceeds limiter's burst" misery. Instead change the new, badly-set defaults in influxdb.conf.

We have pinned this bug down to a quirk in the golang rate package. Specifically, rate.Limiter.WaitN(ctx, n)

returns an error if n exceeds the Limiter's burst size

InfluxDB uses WaitN() to rate limit writes in an io.Writer wrapper, passing the length of the byte slice for n. So, when TSM compaction writes a file larger than compact-throughput-burst, the write fails, rather than being throttled. This causes the entire compaction to unwind, retry, etc.
Notice, in original comment, the log says "exceeds limiter's burst 50331648". Also notice that 50331648 == 1024 * 1024 * 48, the default value for compact-throughput-burst.

Fixed in #14985, backported to 1.7 branch in #14989


#105: add progress bar for plugin installation

Codecov Report
Attention: Patch coverage is 70.00000% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 67.80%. Comparing base (b5688b3) to head (70b5ccc).

Files
Patch %
Lines

cmd/gbc/artifact/plugin.go
44.44%
3 Missing and 2 partials :warning:

cmd/gbc/command/build_action.go
50.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #106      +/-   ##
==========================================
- Coverage   67.89%   67.80%   -0.10%
==========================================
  Files          21       21
  Lines        1165     1171       +6
==========================================
+ Hits          791      794       +3
- Misses        314      316       +2
- Partials       60       61       +1

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


[Fabric] - Android - Chat - User unable to select any options in Fub menu and conversation

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch the special build
Log in with any account
Go to any chat
Tap on Fub menu or go to any conversation
Select any options

Expected Result:
User can select any options in Fub menu and conversation
Actual Result:
User unable to select any options in Fub menu and conversation
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: No
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/9a1b62de-1bcd-455f-ad6b-9b89fc950968
https://github.com/Expensify/App/assets/93399543/c458a177-eced-4555-9eff-10ed40373abf
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

I'll be working on this issue.

@WoLewicki will also be working on this issue, but he's OOO so I'm tagging him.

It seems to be working as expected when building the app from the current (https://github.com/WoLewicki/App/commit/70992f24e718ec6b1ee909358dbeb44e9318b415) andrew-fabric branch:
https://github.com/Expensify/App/assets/21055725/7575ad45-d9ed-44e6-8a82-2533d25786fa


why there are so many nz prefix

I'm submitting a...

[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Support request => Please do not submit support request here

Current behavior

every fork version will know it build from a ng-zorro project, because there are stupid nz prefix
Expected behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z

ng-zorro-antd version: X.Y.Z

Browser:
- [ ] Chrome (desktop) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] IE version XX

For Tooling issues:
- Node version: XX
- Platform:

Others:

avoid conflict with other ui components.

the input output name ?

if you used more than one directives on one html tag, you will understand why.

so i need to use  [nzMin]="min" [min]="min" both? also [nzMax], [max]

think again.

any problem? i introduce in, no mean i will absolutely inquire them. component should be easy to customize and free to reuse. not with a lot of self define tag.
such as namespace is designed to reduce of name collision. when no namespace, developer will write a lot of prefix, and it's hard to migrate and customize

please think again before you comment or submit any issue.


[Outlook] (preview) Add link to append-on-send article (#1899)

[Outlook] (preview) Add link to append-on-send article

Fix date

Docs Build status updates of commit 0b0b946:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/objectmodel/preview-requirement-set/outlook-requirement-set-preview.md
:white_check_mark:Succeeded

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


Possible regression because of recent startAtZeroEnabled changes

Without any changes to my code here is what I get if I use this library from 2177f7d

And here is what I'm getting from current master (2068a5c):

(Note -15 in the left axis and extra space)
I guess it might be related to recent changes around startAtZeroEnabled. In my code I don't this property.
Here are some chart params I set which might be useful to know for debugging the issue:
self.chartView.drawGridBackgroundEnabled = NO;
self.chartView.doubleTapToZoomEnabled = NO;
self.chartView.pinchZoomEnabled = YES;
self.chartView.scaleYEnabled = NO;

self.chartView.legend.form = ChartLegendFormCircle;

self.chartView.xAxis.drawGridLinesEnabled = NO;
self.chartView.xAxis.avoidFirstLastClippingEnabled = YES;
self.chartView.xAxis.labelPosition = XAxisLabelPositionBottom;

self.chartView.rightAxis.enabled = NO;

ChartDataEntry *dataEntry = [[ChartDataEntry alloc] initWithValue:value xIndex:index];

LineChartDataSet *dataSet = [[LineChartDataSet alloc] initWithYVals:values label:@"bar"];

dataSet.lineWidth = 2.0;
dataSet.drawFilledEnabled = YES;
dataSet.circleRadius = 4.0;
dataSet.drawValuesEnabled = NO;
dataSet.drawHighlightIndicators = NO;

startAtZeroEnabled is meant for positive values, when you want to see the 0 point in the axis. It normalizes the axis.
But when you have negative values, we can't just ignore them, they need to be visible.
The new behaviour is the correct one. If you don't want negative values to be visible you can either remove them, or set a custom y axis minimum to 0.

I am curious, @yas375 your data only has positive values (first screenshot), but it calculated a negative _yAxisMinimum in second screenshot?

Well I assumed he has -15 somewhere in his dataset, that is out of the visible range...

Yes, in the screenshot I don't see any negative. Need @yas375 to double check.

Thanks for the quick feedback!
I don't have any negative data entries:
ChartDataSet, label: Bar, 27 entries:
ChartDataEntry, xIndex: 0, value 103.0
ChartDataEntry, xIndex: 1, value 134.0
ChartDataEntry, xIndex: 3, value 202.0
ChartDataEntry, xIndex: 4, value 237.0
ChartDataEntry, xIndex: 7, value 131.0
ChartDataEntry, xIndex: 9, value 114.0
ChartDataEntry, xIndex: 10, value 238.0
ChartDataEntry, xIndex: 11, value 184.0
ChartDataEntry, xIndex: 12, value 274.0
ChartDataEntry, xIndex: 13, value 149.0
ChartDataEntry, xIndex: 14, value 203.0
ChartDataEntry, xIndex: 17, value 134.0
ChartDataEntry, xIndex: 18, value 81.0
ChartDataEntry, xIndex: 19, value 253.0
ChartDataEntry, xIndex: 20, value 250.0
ChartDataEntry, xIndex: 51, value 230.0
ChartDataEntry, xIndex: 52, value 214.0
ChartDataEntry, xIndex: 54, value 116.0
ChartDataEntry, xIndex: 55, value 260.0
ChartDataEntry, xIndex: 56, value 163.0
ChartDataEntry, xIndex: 57, value 234.0
ChartDataEntry, xIndex: 58, value 91.0
ChartDataEntry, xIndex: 59, value 207.0
ChartDataEntry, xIndex: 60, value 92.0
ChartDataEntry, xIndex: 64, value 92.0
ChartDataEntry, xIndex: 65, value 132.0
ChartDataEntry, xIndex: 76, value 12.0

And I have 77 values for xAxis and I believe you can use any strings there.
Let me know guys if you can't reproduce the issue with this data and I can try to make a sample project.
Thanks again!

Also I've verified locally that 67cb278ee2 makes the difference. Without this commit it works as it was before (my first screenshot).

Then it must mean that in your case, for some reason, axisMinimum is less than zero when the decision to not start at zero is made in the code. Somewhere there in https://github.com/danielgindi/ios-charts/commit/67cb278ee24b5631fce1d3ca3d1603194924f0f7... Do you mind debugging it a little? Or giving a small project demonstrating the problem?

The -15 value comes form the chart bottomSpaceLeft.
Without the 67cb278 change the _leftAxis.axisMinimum was set to zero even if you didn't set the leftAxis.customAxisMin.
Now with this change the value is not set to zero and the default is going to use the value calculated in the BarLineChartViewBase.swift  at line 324:
        _leftAxis.axisMinimum = !isnan(_leftAxis.customAxisMin) ? _leftAxis.customAxisMin : (minLeft - bottomSpaceLeft)

Don't know the complete library to well so I can not decide if the bottomSpaceLeft is really needed, but maybe Daniel can have a look and decide.

Oh I got it. It's something I missed. bottom spacing is not needed when
starting at zero
בתאריך יום שני, 17 באוגוסט 2015, alinoz77<EMAIL_ADDRESS>כתב:

The -15 value comes form the chart bottomSpaceLeft.
Without the 67cb278
https://github.com/danielgindi/ios-charts/commit/67cb278ee24b5631fce1d3ca3d1603194924f0f7
change the _leftAxis.axisMinimum was set to zero even if you didn't set the
leftAxis.customAxisMin.
Now with this change the value is not set to zero and the default is going
to use the value calculated in the BarLineChartViewBase.swift at line 324:
    _leftAxis.axisMinimum = !isnan(_leftAxis.customAxisMin) ? _leftAxis.customAxisMin : (minLeft - bottomSpaceLeft)

Don't know the complete library to well so I can not decide if the
bottomSpaceLeft is really needed, but maybe Daniel can have a look and
decide.
—
Reply to this email directly or view it on GitHub
https://github.com/danielgindi/ios-charts/issues/300#issuecomment-131873771
.

Will fix it soon
בתאריך יום שני, 17 באוגוסט 2015, Daniel Cohen Gindi<EMAIL_ADDRESS>כתב:

Oh I got it. It's something I missed. bottom spacing is not needed when
starting at zero
בתאריך יום שני, 17 באוגוסט 2015, alinoz77<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> כתב:

The -15 value comes form the chart bottomSpaceLeft.
Without the 67cb278
https://github.com/danielgindi/ios-charts/commit/67cb278ee24b5631fce1d3ca3d1603194924f0f7
change the _leftAxis.axisMinimum was set to zero even if you didn't set the
leftAxis.customAxisMin.
Now with this change the value is not set to zero and the default is
going to use the value calculated in the BarLineChartViewBase.swift at line
324:
    _leftAxis.axisMinimum = !isnan(_leftAxis.customAxisMin) ? _leftAxis.customAxisMin : (minLeft - bottomSpaceLeft)

Don't know the complete library to well so I can not decide if the
bottomSpaceLeft is really needed, but maybe Daniel can have a look and
decide.
—
Reply to this email directly or view it on GitHub
https://github.com/danielgindi/ios-charts/issues/300#issuecomment-131873771
.

Thanks a lot!


Key on EOS: biohazard item is irritating

Let’s remove the biohazard icon and say (Beta) or something similar.

This is specific to builds of org.endlessos.Key.Devel, just following a pattern that is used for many other GNOME apps. Unless #5 gets completely stalled, I don't think in two weeks we'll be installing .Devel builds for any case outside of a developer testing a build on their own system. But if that's definitely an issue in the short term, I think changing "☢" to "(Nightly)" makes fine sense, and I also created https://github.com/endlessm/endless-key-flatpak/pull/53 to make sure we are communicating that it is a development build in all the usual ways.

Yes, not visible when installing from Flathub. Thanks for the explanation @dylanmccall


Make Stackdriver main collector more library-friendly

We would like to use stackdriver_exporter as a library. The project is almost usable as a library as it is, though inside the main collectors code (MonitoringCollector) some CLI flag are used from the global context.
This PR does a couple of changes to make MonitoringCollector more suitable for library use:

Moves all kingpin CLI flags in a same file flags.go. This cleans the package collectors, making it only content the actual collector's code.
Creates a new type MonitoringCollectorOptions, which will be used to send the newly created collector all required settings.
Moves the parsing of monitoring.metrics-type-prefixesand monitoring.filters to the main package. Also for cleaning up the collectors package.

We've talked about making more of our exporter collector packages interchangeable to allow more library use. We're trying to come up with a registration/config pattern for this.
If you're interested in contributing, I would love to hear your thoughts.

We've talked about making more of our exporter collector packages interchangeable to allow more library use. We're trying to come up with a registration/config pattern for this.
If you're interested in contributing, I would love to hear your thoughts.

Definetely, feel free to tag me in any issue/thread were you are discussing. More than happy to contribute 😀

I didn't find an issue for it, so I opened https://github.com/prometheus/exporter-toolkit/issues/92.


Confusion about the timeoutInMinutes value for a task

I've set the timeoutInMinutes for a task like so:
- bash: |
    $(bin_path)/distribute.py
  timeoutInMinutes: 180
  displayName: Distribute

Based on the documentation I've found here I'd expect this task to be allowed to continue for 180 minutes before being killed. Instead, we are seeing it killed after 60 minutes. As far as I can tell, it's because the cancel timeout for the phase is set to it's default 60 minutes. Note: We do not set the timeout for the phase explicitly.
If we need to set the phase timeout to be the sum of the timeouts for all tasks in it, that would be useful to have in the documentation.
If we don't (which seems like the more sensible solution) then where are we going wrong?

phase default timeout is 60 mins. step default timeout is infinity until the current phase hitting timeout.
So, you need to increase your phase timeout first if you know your task is going to run more than an hour.
We will improve the doc.

timeoutInMinutes doesn't seem to be a valid property on a phase. i.e. this is wrong:
- phase: Whatever
  queue:
    name: Something
  timeoutInMinutes: 100
  steps:
  - whatever

Move the property under queue.
Note, we went through a schema rename to simplify concepts (although we held compat for existing customers). So the new syntax is:
jobs:
- job: Whatever
  pool: Something
  timeoutInMinutes: 100
  steps:
  - whatever

Or using the old syntax:
- phase: Whatever
  queue:
    name: Something
    timeoutInMinutes: 100
  steps:
  - whatever

We don't have any documentation about moving to the new format. We just deprecated the old preview docs (in the agent repo), and redirect folks to the new docs (on docs.microsoft.com)

i'll update the docs to clarify the lesser of the two timeouts wins

Sounds good to me. Thanks. :)

We have created a new repository for all YAML related issues, please move the current issue to there.
https://github.com/Microsoft/azure-pipelines-yaml

closing since answered.  if anything left to answer, see the point above about moving to azure-pipelines-yaml

Related: https://github.com/microsoft/azure-pipelines-yaml/issues/48


The search isn't matching with lower/upper case

Javascript is case-sensitive
When assign repo.name to card use repo.name.toLowerCase() instead

i just put card title.toLowerCase()


Use Keycloak export / enable auditing / adjust login lifespan settings

Closes #145
Closes #144
Closes #132
This PR was originally intended just to extend the email link expiration time.  However, when I went to adjust that value in keycloak/import/hmda-realm.json, the attributes that drive these timeouts (https://github.com/cfpb/hmda-platform-auth/issues/132#issuecomment-321881526) weren't present.  So, rather than just manually add them, I wanted to re-export the Keycloak config to get whatever other attributes in there that I may also be missing.  And while doing this, I discovered that Keycloak had recently added an Export feature to the Admin UI, removing the need to do the strange create/export/import dance we'd been doing.  And, while walking through the steps of manually setting up the HMDA realm for the export, I realized those docs were very out of date, so I updated those too.
Finally, while the hood was open, I also enabled Keycloak's auditing feature.  It is currently set to log ALL events to Keycloak's DB.  If we decide this is too verbose, we can tune it to only log events we find useful.

Also of note, the new Export feature formats the JSON differently from the old process, so it is not-so-easy to diff.  You can use https://github.com/cfpb/hmda-platform-auth/pull/146/files?w=1 to help a bit, but it's still not-so-great since it appears things aren't even ordered quite the same.
So, for additional confirmation, it'd probably be good to compare the resulting Keycloak with the new Manual setups updated in the README.

Added a couple grammar and and Markdown formatting fixups.
Also, if you'd like to see the rendered versions of the READMEs, you can head over to:

https://github.com/hkeeler/hmda-platform-auth/blob/readme-manual-config/README.md
https://github.com/hkeeler/hmda-platform-auth/blob/readme-manual-config/keycloak/README.md


OSSL_CMP_CTX_reinit(): fix missing reset of ctx->genm_ITAVs and of ctx->geninfo_ITAVs

Otherwise, further OSSL_CMP_exec_GENM_ses() calls go wrong.

Please add test

Done.
I made the CMP mock server more realistic by checking at least the number of ITAVS in a GENM request.
Without the fix, the extended execute_exec_GENM_ses_test(), which now does two GENM sessions, fails.

On this occasion I found and fixed an outdated example in OSSL_CMP_CTX_new.pod.

This time there are some strange unrelated CI failures on 01-test_symbol_presence.t.

The failures are happening on all builds, so not your problem.

Thanks @t8m for your swift approval.
I just realized that an update of the doc of OSSL_CMP_CTX_reinit() was missing,
the new check in cmp_mock_srv.c should be relaxed a little,

It turns out that a similar issue was with ctx->geninfo_ITAVs,
where in this case the solution is to add a missing API function OSSL_CMP_CTX_reset_geninfo_ITAVs() because the generalInfo header entries (such as certProfile) are usually shared among CMP transactions.

This time there is an unrelated CI failure with 90-test_threads.t.

Hmm, the added function looks like a feature. Should the PR be split?

Well, though a new function looks like a new feature, this is actually an API bug fix:
the function is needed, otherwise OSSL_CMP_CTX_push0_geninfo_ITAV() cannot be used properly.
ITAVs can be added, but there is no chance to remove them, so further CMP requests are e.g., stuck to use the same cert profile. Adding further OSSL_CMP_CTX_push0_geninfo_ITAV() calls will incorrectly add further profile names, which a server will not be able to handle.
An alternative fix would be to tweak OSSL_CMP_CTX_reinit() in a similar way as done here for genm_ITAVs, but as I tried to explain above, this would not be appropriate for the generalInfo case.

Then the documentation is incorrect as for the version this was added in. And the libcrypto.num update as well.

Good point - fixed.

Asking @openssl/committers for 2nd review.

Rebased to fix version 3.1->3.2 merge conflits.

Ping @openssl/committers for 2nd review

First step
Hi I will help you with everything you need but you have to subscribe to
the youtube channel and I will fulfill all your requests
https://youtu.be/aIaqr4eq18g
Pada Isn, 19 Sep 2022, 7:19 PM David von Oheimb @.***>
menulis:

It turns out that a similar issue was with ctx->geninfo_ITAVs,
where in this case the solution is to add a missing API function
OSSL_CMP_CTX_reset_geninfo_ITAVs() because the generalInfo header entries
(such as certProfile) are usually shared among CMP transactions.
—
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/pull/19216#issuecomment-1250886812,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APESUCRQRBZDFC6HMJ65JITV7BD53ANCNFSM6AAAAAAQMRLCXM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I'm going to resolve the trivial new merge conflict with libcrypto.num when merging this PR.

This needs a rebase and update since 3.0.6 was already released without this.

Argh, I had missed that this was ready to merge for quite a while.
Rebased to fix the trivial conflict in libcrypto.num and updated the version reference.
Still ready to merge?

Looks like re-approvals are needed here?

@paulidale please reconfirm

Rebased again to fix a (trivial) merge conflict in  libcrypto.num.
@paulidale could you please re-confirm?

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Merged to master, 3.0., and 3.1.
Thanks @t8m and  @paulidale, also for the re-approvals that meanwhile were needed.

When cherry-picking to 3.0 and 3.1, I had to fix some merge conflicts regarding the new function OSSL_CMP_CTX_reset_geninfo_ITAVs() due to the fact that those branches do not contain functions that meanwhile were added for 3.2.
Doing so, I made a mistake deleting one more line from OSSL_CMP_CTX_new.pod, which made doc-nits fail.
I've corrected this right away in a follow-up commit.

When cherry-picking to 3.0 and 3.1, I had to fix some merge conflicts regarding the new function OSSL_CMP_CTX_reset_geninfo_ITAVs() due to the fact that those branches do not contain functions that meanwhile were added for 3.2.
Doing so, I made a mistake deleting one more line from OSSL_CMP_CTX_new.pod, which made doc-nits fail.
I've corrected this right away in a follow-up commit.

If the cherry-pick conflict resolution is not trivial a new PR should have been submitted.

If the cherry-pick conflict resolution is not trivial a new PR should have been submitted.

Thanks for pointing this out. Will do so in the future.
In this case it was borderline between trivial and slightly more involved,
and I just made a silly mistake when deleting the automatically added line containing the >>>>>>>.
So it was actually independent of the complexity of the conflict resolution.


this error only in debug / Windows

This error is in debug mode for Windows
That is happening in of V0.1 RC4 VS2017  or event in 0.98 VS2015
->\addons\ofxflowtools\src\core\ftflow.h(33): error C4716: 'flowTools::ftFlow::setVisualizationToggleScalar': must return a value

this was already fixed


API LOGGING

Hi,
I tried to follow after this guid: https://developers.google.com/google-ads/api/docs/client-libs/dotnet/logging
when I tried to put this code in my service:

I am getting an error:
System.TypeInitializationException: The type initializer for 'Google.Ads.GoogleAds.V10.Services.GoogleAdsServiceReflection' threw an exception. ---> System.Threading.ThreadAbortException: Exception of type 'System.Threading.ThreadAbortException' was thrown.
Do you know why?
and how can I solve this?
Best Regards,

Closing for now, pls reopen if this is replicable.


Split out the AuthUIContextProvider

Describe the desired behavior
Split the AuthUIContextProvider into two separate implementations for React Native and React.
Describe the current behavior
There is currently one implementation used for both.
Is this request related to a current issue?
No
Additional Context
There are currently some features/props that are implemented in one framework and not the other (or only applicable for one framework). Splitting this into a ReactAuthUIContextProvider and ReactNativeAuthUIContextProvider will allow us to define the types separately and make the documentation less confusing.
Inside the react-native-auth-workflow and the react-auth-workflow, we can re-export the contexts without the framework prefix so the end-user usage will remain the same:
// e.g., react-auth-workflow/index
export {ReactAuthUIContextProvider as AuthUIContextProvider } from '@brightlayer-ui/react-auth-shared';

// e.g., react-native-auth-workflow/index
export {ReactNativeAuthUIContextProvider as AuthUIContextProvider } from '@brightlayer-ui/react-auth-shared';

No longer relevant with the authentication workflow updates.


Experiment: Convert gradle to Kotlin

Description
I have converted our build scripts to use Kotlin DSL instead of Groovy - mainly due to the improved structure it promises to provide.
This might be done naively, so feel free to review critically :)

Checklist:

[x] My code follows the style guidelines of this project (.editorconfig, most IDEs will use this for you).
[x] I have performed a self-review of my own code.
[x] I have commented my code in areas it may be challenging to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes are ready for review from a contributor.

do you really expect us to review gradle stuff? I have no idea what's going on there

do you really expect us to review gradle stuff? I have no idea what's going on there

The expected response 😂 I'll do another review pass and merge it tomorrow :p

I could also take a look over it. I have some understanding of kts build scripts.
Just a note I want to add, modpublisher 2.0+ has much better kotlin support than 1.0. The docs and github have been updated with the new changes

I could also take a look over it. I have some understanding of kts build scripts.
Just a note I want to add, modpublisher 2.0+ has much better kotlin support than 1.0. The docs and github have been updated with the new changes

That'd be wonderful if you have the time! I'll also take a look at upgrading modpublisher later tonight :)

That should be all current feedback addressed :)


tenserflow build issue on rockpro64 (rk3399).

Hi, I followed the document to build tensorflow on my rockpro64 (Ubuntu18.04)
provided rk3399.conf and it threw error while tensorflow build-
DEBUG: Rule 'io_bazel_rules_docker' indicated that a canonical reproducible form can be obtained by modifying arguments shallow_since = "1556410077 -0400"
ERROR: /home/rock64/tensorflow-on-arm/build_tensorflow/sources/tensorflow/tools/local_arm_compiler/BUILD:3:1: in cc_toolchain_suite rule //tools/local_arm_compiler:toolchain: cc_toolchain_suite '//tools/local_arm_compiler:toolchain' does not contain a toolchain for cpu 'aarch64'
ERROR: Analysis of target '//tensorflow/tools/pip_package:build_pip_package' failed; build aborted: Analysis of target '//tools/local_arm_compiler:toolchain' failed; build aborted
INFO: Elapsed time: 76.716s
INFO: 0 processes.
Any suggestion?
Thanks.

@rahulsharma11 I have the same problem, have you found a solution yet?

Hi, u can past your rk3399.conf?


File Explorer fails when alias does not match hostname

Given the following SSH config:
Host marwan
    HostName marwan
    User marwan
    ForwardAgent yes

The File Explorer works as expected.
However, if the alias does not match the hostname such as:
Host marwan_vm
    HostName marwan
    User marwan
    ForwardAgent yes

Then I get the following error when clicking on "File Explorer":

I don't believe this is expected to work, as this config would be used up when you connect to the nickname (marwan_vm) but not vice versa.

Yes, we should prompt for the user - I will create an issue to track this. I don't think there is anything more we should do around using a matching HostName as we're using SSH directly and it's not a function of it.


fixes build in rushjs pnpm monorepo context

Not necessarily final version, but I did run into some build issues when using boardgame.io together with rushjs.io/
Namely some undeclared dependencies which were okay to having trans deps in node_modules before and rollup putting logs on stderr which prevents rush from caching.

Would you like any further changes here for the moment?

Is this iteration looking okay?

Hi @ksjogo.  Sorry about the delay in getting to this.  Been a bit busy.  Will try to get this PR on next week.

No worries. Thank you.

Hi Johannes, sorry about the delay.  Just took a look now.
I'm still unsure about the regenerator-runtime and left a comment.  Everything else looks good to go.

Removed the regenerator-runtime now.

Updated in regards to conflicts.


TextInputSheet allows text to flow under the "clear" button

Describe the bug
When you type enough text in a TextInputSheet, the text flows under the "Clear" button
To Reproduce
Steps to reproduce the behavior:

Go to ObsDetails and start writing a comment
Write enough so your text gets to the "Clear" button
Note that it flows under the clear button

Expected behavior
User text should not appear to touch the "Clear" button.
Screenshots

Context (please complete the following information):

Device: Simulated iPhone 15 Pro
OS: iOS 17.2
App version: v0.20.0+68

Additional context
Note sure what the best solution is here, but I'd probably try giving the Clear button a rounded corner white background with padding, or just give the text input some space at the bottom so the text never gets to the clear button.

This does not look fixed for me, @angie. Assuming it's fixed for you, what are the conditions that it's working under?

I think this was fixed in f6e499a79245f6f145123ac3adcec02c0178adb1


Network Provider is changeable on cluster edit

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Create custom cluster
Edit cluster
Result:
See Network Provider being changeable, while it is not in v2.2.9
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.3.2
Installation option (single install/HA): single

Available in latest-2.3.

Tested with latest build from v2.3-head with UI tag - https://releases.rancher.com/ui/latest-2.3/index.html.
We do not allow for Network Provider to be changed on edit cluster as expected.


Error phasing(phase_common):AC field is needed in file

Hi,
I'm using shapeit5 to phase HGDP chr14 VCF file and I get the following error:
Reading genotype data:
  * VCF/BCF scanning ...
ESC[31mERROR: ESC[0mAC field is needed in file

Not entirely sure, where the AC field is missing. Any help would be appreciated.

I have encountered the same problem when using static v5.1.0.
I tried using BCFtools +fill-tag to add AC,AN,MAF to my VCF input file.
But the error still exists.
Here are my command;
bcftools +fill-tags myVCF.vcf.gz|head -1000|bcftools view -Oz -o myVCF.filtag.vcf.gz
bcftools index myVCF.filtag.vcf.gz
phase_common_static --input myVCF.filtag.vcf.gz
--scaffold ${Scaffold}/myscaffold_${chr_no}.vcf.gz
--region $chr_no
--map ${map}/${chr_no}.b38.gmap.gz
--reference myRef.${chr_no}.vcf.gz
--output ~/target.phased.bcf
--thread 1

I found this is problem with v5.1.0.
I tried downloading SHAPEIT5_phase_common_static_v1.0.0 and it works just fine with my data.

Hi,
Version 5.1 requires that ALL input VCF/BCF files have the fields AC and AN
present (main, scaffold and reference).
Of note the VCF header need to be correct too.
Adding this fields can be done using:

bcftool +filltag (slow)
bcftools view -c 0 (fast)
A tool that is there (fast): https://github.com/odelaneau/otools fillfreq

I bet that if the software complains, it is because of the scaffold or the
reference in your case.
Best,
Olivier Delaneau
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Sans
virus.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Le mar. 18 avr. 2023 à 13:04, VNakhonsri @.***> a
écrit :

I have encountered the same problem when using static v5.1.0.
I tried using BCFtools +fill-tag to add AC,AN,MAF to my VCF input file.
But the error still exists.
Here are my command;
bcftools +fill-tags myVCF.vcf.gz|head -1000|bcftools view -Oz -o
myVCF.filtag.vcf.gz
bcftools index myVCF.filtag.vcf.gz
phase_common_static --input myVCF.filtag.vcf.gz
--scaffold ${Scaffold}/myscaffold_${chr_no}.vcf.gz
--region $chr_no
--map ${map}/${chr_no}.b38.gmap.gz
--reference myRef.${chr_no}.vcf.gz
--output ~/target.phased.bcf
--thread 1
—
Reply to this email directly, view it on GitHub
https://github.com/odelaneau/shapeit5/issues/23#issuecomment-1512883393,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4XTIKKSUVG3WNSCLBZ7CLXBZYMTANCNFSM6AAAAAAWYL6FZQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi,
Thank you for writing this! I was just wondering: how is AC and AN  used by SHAPEIT5? I am asking as I am interested in phasing only a subset of individuals, and I am unsure whether to annotate before or after filtering by samples.
Thank you in advance for the information!


[Bug] Connector cannot access methods from pulsar-client-original

Search before asking

[X] I searched in the issues and found nothing similar.

Version

OS: macOS 13.4.1 m1
Pulsar: 3.0.0

Minimal reproduce step
See https://github.com/BewareMyPower/pulsar-sink-demo
What did you expect to see?
It should succeed.
What did you see instead?
ClassCastException
Anything else?
From https://github.com/apache/pulsar/pull/17835, it seems that we need to use reflection to access methods and classes in the module. But it harms the user experience.

The root problem is that connectors should not bundle the Pulsar client impl because it's provided at runtime by the Java Functions framework.

From the PR description, it seems to be related to how the Java Functions framework loads the connector. Ideally, it should use the default classpath of Pulsar broker.
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

Can reproduce on my local env. This is a X is not X class loading issue -
java.lang.ClassCastException: class org.apache.pulsar.client.impl.MessageIdImpl cannot be cast to class org.apache.pulsar.client.impl.MessageIdImpl (org.apache.pulsar.client.impl.MessageIdImpl is in unnamed module of loader java.net.URLClassLoader @148080bb; org.apache.pulsar.client.impl.MessageIdImpl is in unnamed module of loader org.apache.pulsar.common.nar.NarClassLoader @2416a51)
	at org.example.DemoSink.lambda$write$0(DemoSink.java:25) ~[OjpVVcIuC05Ba5ELqz3aLA/:?]
	at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
	at org.example.DemoSink.write(DemoSink.java:22) ~[OjpVVcIuC05Ba5ELqz3aLA/:?]
	at org.apache.pulsar.functions.instance.JavaInstanceRunnable.sendOutputMessage(JavaInstanceRunnable.java:439) ~[?:?]
	at org.apache.pulsar.functions.instance.JavaInstanceRunnable.handleResult(JavaInstanceRunnable.java:401) ~[?:?]
	at org.apache.pulsar.functions.instance.JavaInstanceRunnable.run(JavaInstanceRunnable.java:341) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]

I'll try to investigate it.

Logging how NarClassLoader load classes. It loads -
- loading org.example.DemoSink
- loading org.apache.pulsar.client.impl.MessageIdImpl
- loading org.apache.pulsar.client.api.MessageIdAdv

But not MessageId. So the instance is of MessageId loaded by the URLClassLoader while we try to cast it to MessageIdImpl loaded by NarClassLoader.
We set the NarClassLoader as context class loader before handling result -
                Thread.currentThread().setContextClassLoader(instanceClassLoader);

                // register end time
                stats.processTimeEnd();

                if (result != null) {
                    // process the synchronous results
                    handleResult(currentRecord, result);
                }

Workaround with a hack internal -
diff --git a/pulsar-functions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java b/pulsar-functions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java
index c3f36f754d..cc4bd4d7d2 100644
--- a/pulsar-functions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java
+++ b/pulsar-functions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java
@@ -211,6 +211,8 @@ public class JavaInstanceRunnable implements AutoCloseable, Runnable {
         this.collectorRegistry = collectorRegistry;

         this.instanceClassLoader = Thread.currentThread().getContextClassLoader();
+        log.info("componentClassLoader: {}", this.componentClassLoader);
+        log.info("instanceClassLoader: {}", this.instanceClassLoader);
     }

     /**
diff --git a/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/runtime/JavaInstanceStarter.java b/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/runtime/JavaInstanceStarter.java
index 89281a2f55..c47c2bf9fa 100644
--- a/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/runtime/JavaInstanceStarter.java
+++ b/pulsar-functions/runtime/src/main/java/org/apache/pulsar/functions/runtime/JavaInstanceStarter.java
@@ -195,7 +195,7 @@ public class JavaInstanceStarter implements AutoCloseable {
             functionDetailsJsonString = functionDetailsJsonString.substring(0, functionDetailsJsonString.length() - 1);
         }
         JsonFormat.parser().merge(functionDetailsJsonString, functionDetailsBuilder);
-        FunctionCacheManager fnCache = new FunctionCacheManagerImpl(rootClassLoader);
+        FunctionCacheManager fnCache = new FunctionCacheManagerImpl(functionInstanceClassLoader);
         ClassLoader functionClassLoader = ThreadRuntime.loadJars(jarFile, instanceConfig, functionId,
                 functionDetailsBuilder.getName(), narExtractionDirectory, fnCache);
         inferringMissingTypeClassName(functionDetailsBuilder, functionClassLoader);

The root cause is that the Record passed to sink.write is loaded by functionInstanceClassLoader and thus its internal MessageIdImpl. The class loader is URLClassLoader loading pulsar.functions.instance.classpath.
... while the sink class is loaded by NarClassLoader whose parent is "root classloader" a.k.a. the default AppClassLoader.

cc @jiangpengcheng @nlu90 @lhotari @nicoloboschi Although the root cause located, it's not quite easy to solve this issue. My workaround can work, but I'm not sure if extra affect coupled.


Reset and output stability

fixes #29
fixes #30

Minor comments. Feel free to merge after fixing.


linker: update posix linker template, linker.ld

The function zephyr_linker_sources() states:

When placing into NOINIT, RWDATA, RODATA, ROM_START, the contents of
the files will be placed inside an output section, so assume the
section definition is already present.

However, in the posix linker.ld template the NOINIT, RWDATA, RODATA, and
ROM_START was not placed inside a pre-defined output section, which
means that linker scripts created for native_posix when
zephyr_linker_sources() is used are invalid
This result in the following failure:
/usr/bin/ld:zephyr/linker_zephyr_prebuilt.cmd:81: syntax error
collect2: error: ld returned 1 exit status

This PR fixes this issue be predefining output sections according to
the documented behavior.
Signed-off-by: Torsten Rasmussen<EMAIL_ADDRESS>

@trantanen FYI.


Most icons in the editor's dark mode modals have the wrong shade

Issue Summary
While in dark mode, click on an image card, audio card, gallery card, etc., and you'll see that most of the icons in the modals are dark on dark rather than light on dark.

I haven't looked, but I presume I've missed several others.
Steps to Reproduce

Click on a card in dark mode to pull up its modal
See the dark on dark icons

Ghost Version
5.61.1
Node.js Version
Yes
How did you install Ghost?
Ghost(Pro)
Database type
MySQL 5.7
Browser & OS version
No response
Relevant log / error output
No response
Code of Conduct

[X] I agree to be friendly and polite to people in this repository

@stromfeldt  @daniellockyer  hello, I want to fix this issue. Can you please assign this to  me. also, can you give me a head start. How do I reproduce this issue ?

Some svg icons inside Koenig action bar have .fill-white and some others have .fill-white-no-conflict
In light mode, .fill-white-no-conflict applies #ffffff and the icons with .fill-white aren't affected as .fill-white does not add any styles in light mode. https://github.com/TryGhost/Ghost/blob/c6cf4fc2f30c81f867bd2933afaf20b3399d8584/ghost/admin/app/styles/spirit/_icons.css#L242-L243
https://github.com/TryGhost/Ghost/blob/c6cf4fc2f30c81f867bd2933afaf20b3399d8584/ghost/admin/app/styles/patterns/global.css#L28
In dark mode, .fill-white-no-conflict applies #15171a. This is what cause the reported problem.
https://github.com/TryGhost/Ghost/blob/c6cf4fc2f30c81f867bd2933afaf20b3399d8584/ghost/admin/app/styles/app-dark.css#L79
In dark mode, icons with .fill-white inside get #e3e6e8 from:
https://github.com/TryGhost/Ghost/blob/c6cf4fc2f30c81f867bd2933afaf20b3399d8584/ghost/admin/app/styles/components/koenig-dark.css#L33-L36

@daniellockyer the fix I have added works. But I am curious if there's a plan to move to a utility-first CSS framework like Tailwind CSS?

This was fixed in https://github.com/TryGhost/Ghost/commit/1b1d871374e88324c37b64e32ccbca6a1ed9116b and released in Ghost 5.63.0


Missing dvc show in current version

Hi,
I am unable to generate DAG in current release 0.9.3. Is it removed?

Hi @rahulguptajss !
Do you mean autotomatic dependencies? If so, then yes, it was removed in 0.9.0 in favor of explicit dependencies notation.

yes, I wanted to use dvc show pipeline command. Can you confirm the command in 0.9.3 for the same.
Thanks.

@rahulguptajss ah, I see. Unfortunately 'dvc show pipeline' was also removed in 0.9.0, we felt like it was way too raw and it required additional dependencies which were not very easy to install everywhere. We do think about bringing it back in the future though.

ok thanks for the update. dvc docs seems to be out of date currently.
https://dataversioncontrol.com/docs/#commands_command_reference_show

@rahulguptajss Oops, sorry for that. We will be sure to update that. Thanks for the feedback!

Thank you for your quick responses.

@rahulguptajss And thank you for the feeback!
I'll leave this issue open while documentation is not fixed.

Turns out site doesn't auto-update from out docs/doc.rst, so the issue is not fully resolved yet. Keeping open for now.

I'll take care of it.

Can you please confirm if there is any plan to reintroduce the GUI feature of DVC show . Currently if project is huge then generating and making changes to pipeline is very painful due to lack of view.

@rahulguptajss I can 100% confirm that. We are fully aware of the need to visually represent repository structure. We are currently considering a few options, including the possibility to re-introduce refactored dvc show. I suppose we are going to have something ready in the nearest few releases. Thank you for your interest!

@rahulguptajss Btw, it seems like you are doing some pretty interesting stuff with jenkins and dvc. We are thinking about something related and would love to discuss it. Would you mind discussing it in more details? My email is<EMAIL_ADDRESS>feel free to drop a message if you are interested. We could arrange a skype call or something.

yes sure. I'll drop you an email on what we have been trying to do and some recommendations about dvc.

@rahulguptajss Thank you! Looking forward to it!

Fixed https://dvc.org/documentation .

Hi @rahulguptajss !
Just wanted to let you know that we now have ASCII DAG visualization. Here is an example https://dvc.org/doc/get-started/visualize . Please feel free to give it a try :slightly_smiling_face:
Thanks,
Ruslan


Props on router-view and beforeRouteEnter

Hello,
I figured out that we can pass data to a view component using props on RouterView.
<router-view :foo="bar"></router-view>

I dont know if it s supposed to works like this it s working.
I would like to be able to use those data in beforeRouteEnter to prefetch some data related to this props.
But it dont seams to be possible to use the props data in beforeRouteEnter.
Maybe you can add this feature ?

You already can:
beforeRouteEnter (to, from, next) {
  next(vm => {
    // access to component instance via `vm`
  })
}

(http://router.vuejs.org/en/advanced/navigation-guards.html#in-component-guards)

You can fetch something else with the hook.
You can also use a global state management lib like vuex
If you got more questions, please, ask them on the forum or StackOverflow

I dont want to do it in the hook because i want do it before the route enter


Update Fibonacci.cpp

1st rule violated

can, I upload a program in dynamic Programming section? Is it valid?

can, I upload a program in dynamic Programming section? Is it valid?

No it isn't.
Here are rules:
https://github.com/shubham7668/hacktober#readme


incus: 6.7.0 -> 6.8.0

https://github.com/lxc/incus/releases/tag/v6.8.0

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I need to refactor these tests. They're too flaky.
x86
/nix/store/1ln4y17gl37r5ywhcrq99jjckxrvqpqp-vm-test-run-container-legacy-init
/nix/store/rh61i1fcivb03scjw7my0x0zf44vm26y-vm-test-run-container-systemd-init
/nix/store/3hbbp53fvbaf5w5zmc4yzq0j6xil48ya-vm-test-run-incusd-options
/nix/store/pfyjc1qi38cnjna40f85h9np9llxh26g-vm-test-run-lxd-to-incus
/nix/store/v1r5qn3cbb9198d7xpcizc5ic3a9vrgv-vm-test-run-incus-openvswitch
/nix/store/rq5pfi8blj1gq8pk3g5phkpcfx6xf5sn-vm-test-run-incus-socket-activated
/nix/store/c5rsa85mr5s0p0wi2dibw790z4bjb0yf-vm-test-run-incus-storage
/nix/store/j2j1fr56vkx9k6nzxx1v4sb0f2b8igqr-vm-test-run-incus-ui
/nix/store/r7ppqv7ywsw2llcq2dxyz2hcp35l7pvq-vm-test-run-incus-virtual-machine


[Documentation]: Example shown in the Documentation throwing error. (FaissVectorStore)

Documentation Issue Description
The demo example mentioned here https://docs.llamaindex.ai/en/stable/examples/vector_stores/FaissIndexDemo/ for FaissIndex is throwing error on adding documents to the VectorStoreIndex.
My code as copied from the documentation:
documents = SimpleDirectoryReader("./random_internet_data/paul_graham/").load_data()
d = 1536
faiss_index = faiss.IndexFlatL2(d)
vector_store = FaissVectorStore(faiss_index=faiss_index)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
Error:
File ~/anaconda3/envs/pytorch_p310/lib/python3.10/site-packages/faiss/class_wrappers.py:228, in handle_Index.<locals>.replacement_add(self, x)     215 """Adds vectors to the index.     216 The index must be trained before vectors can be added to it.     217 The vectors are implicitly numbered in sequence. When nvectors are    (...)     224    dtype` must be float32.
225 """
227 n, d = x.shape
--> 228 assert d == self.d
229 x = np.ascontiguousarray(x, dtype='float32')
230 self.add_c(n, swig_ptr(x))
AssertionError: `
Am I missing anything? Kindly help
Documentation Link
https://docs.llamaindex.ai/en/stable/examples/vector_stores/FaissIndexDemo/

Thanks. I copied the code and tried in my local. Looks like 384 is the dimension of the embeddings of the document.


(re-)Remove IE8–10 related Sass and CSS build tasks

Replacement for https://github.com/alphagov/govuk-frontend/pull/3559 which was accidentally merged prematurely.

Rebased to include today's PR merges


Bootstrap CSS without at-rules for MBB

Hi,
I see that At-rules are not supported for MBB yet. Could anyone tell me where I could find a bootstrap css or other css templates without at-rules for mobile app?
When I use a Page, using bootstrap is easy because I use HTML. The moment I start using a Shell, I am mandated to use a ContentPage and in ContentPage HTML is not allowed unlike in a Page. This forces me to use controls and style css without at-rules. Is this is the expected behavior, please?

I've been using @media rules successfully, including @media print... but that's the only "at rule" I've tried so far.

@BenMakesGames O, great! Is it in a Shell's ContentPage?

There are two places to use CSS in Mobile Blazor Bindings:

For native UI elements there is some limited CSS usage, which you can read about here: https://docs.microsoft.com/en-us/mobile-blazor-bindings/ui/css-styles
For hybrid apps the HTML UI in a BlazorWebView has full CSS support (well, I'm sure there's some limitation, but not much)

Thank you so much for the information, @Eilon


Update MD file on new branch 2017-11-22_13-33-47

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/content1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Using vscode-telemetry-extractor npm package.

Our build scripts used to clone a repo and run npm install, but now that repo has been released as an npm package and therefore we should use that for easier management. This just edits the build to account for the new changes.

@lramos15 Always use yarn to add/update dependencies: yarn add vscode-telemetry-extractor. You missed the yarn.lock file: https://github.com/microsoft/vscode/commit/a6c461b564ad5857a8bd1486d336a3678039030a

Oh okay :+1:. I just manually put it in the package.json and the builds worked because when they run yarn it gets added to the yarn lock.


tests: compat with flask-sqlalchemy v3

The 'create_all()' and 'drop_all()' methods no longer have the 'app=' argument.  Therefore we have to use 'with app.app_context()' wrapper, at least when there are multiple apps in action.
Otherwise, it is possible to take the app context on a per-test-case basis, using the pattern:
setUp():
    self.ctx = self.app.app_context()
    self.ctx.push()

tearDown():
    self.ctx.pop()

The changes done in this commit still keep compatibility with flask-sqlalchemy v2.
Fixes: #75
Closes: #74
Closes: #73
Closes: #78

I think I'm done here.  Would anyone please take a look at the review?

I'm reopening -> this deserves a release.


Start sending 'check' events from SDK

BUC-2523

Using a Proxy object for the value. Each time it is read, a custom function is called that triggers an event,
Using a per-key rate limiter of 5 events per minute to avoid spamming the API,
Added the version into the mix as we'll need that on API side,
Fallback flags are also reported with no version attached, we can deal with them as want on the API side (maybe send a bool that it was unresolved, or just warn),
Some cleaning was required related to the use of nock to make validation of calls tighter.

@Munter I asked @pavkam to include it because it was thinking there could be situations where our Proxy implementation doesn't completely cover the use cases. However, smaller interfaces are better so I'm OK to remove it now and we can add it back in if it becomes necessary. Apologies for the back/forth @pavkam

@pavkam I've been wanting to rebase the ReactSDK work i've been doing on top of this in order to test that check events are being sent correctly. Lemme just give that a quick try, otherwise everything LGTM

@Munter I asked @pavkam to include it because it was thinking there could be situations where our Proxy implementation doesn't completely cover the use cases. However, smaller interfaces are better so I'm OK to remove it now and we can add it back in if it becomes necessary. Apologies for the back/forth @pavkam

Will do!

@pavkam I've been wanting to rebase the ReactSDK work i've been doing on top of this in order to test that check events are being sent correctly. Lemme just give that a quick try, otherwise everything LGTM

Will wait for you then

I tested it with the new React and it looks good. Nice work.
One thing was was apparent is that we need to make the rate limiter a bit smarter. Because of the way React works, you can have a ton of re-rendering going on. Each re-rendering can cause a "check" event to get emitted even though it's actually the same "check" (same flag key + context + result). Those could quickly saturate the rate limit causing check for new flags not to get transmitted. Can we make a rate limit of 1 event/minute but there's a separate ratelimit for each key/context combination?

I tested it with the new React and it looks good. Nice work.
One thing was was apparent is that we need to make the rate limiter a bit smarter. Because of the way React works, you can have a ton of re-rendering going on. Each re-rendering can cause a "check" event to get emitted even though it's actually the same "check" (same flag key + context + result). Those could quickly saturate the rate limit causing check for new flags not to get transmitted. Can we make a rate limit of 1 event/minute but there's a separate ratelimit for each key/context combination?

Hm, good find. Will add the change. Thanks!

Closing as this package is superseded by browser SDK which will incorporate all the additions.


Add portfolio

do not merge

Coverage remained the same at 92.27% when pulling fa78ec8e0bac4c35f13760bce50cae5acf854656 on khooroko:WeiPing_Portfolio into 98b333eb345efe890d1fa6b83c35c651acd42f10 on CS2103AUG2017-T17-B1:master.

Coverage remained the same at 92.27% when pulling fa8f08f1013ddd80ee8fe9245c6424ca8d67e54a on khooroko:WeiPing_Portfolio into 98b333eb345efe890d1fa6b83c35c651acd42f10 on CS2103AUG2017-T17-B1:master.


Promise能否增加基于点(.)语法的链式写法支持？用 [] 来写链式写法步骤多了之后超级别扭啊

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

如果改为 . 语法支持的话，就会不兼容现在的api了

感觉并不需要修改吧，只是在现有的API之上增加语法糖的包装吧

一般oc里面链式调用，需要 then 返回一个block, 而现在返回的是 Promise对象


Spelling fixes

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @scop!

:book:

Thanks for contributing to our documentation. We :heart: our documentarians!

  Generated by :no_entry_sign: dangerJS

:tada:  thanks for your contribution @scop


TELEWORK: ADM Research

User Story
As an ADM, I want the Telework form sign-off process to be compatible with my process.
Task List

[ ] Create a timeline for completing this project and incorporating the results before launch.
[ ] Create a script for asking ADMs about how they currently sign off Telework Agreement forms
[ ] Get list of at least five ADMs to contact from PIE. These ADMs should be from different ministries (at least five ministries, not including the PSA).
[ ] Contact the ADMs
[ ] Compile the results
[ ] Compare ADM processes to the Telework form process for compatibility
[ ] Determine how to address compatibility issues
[ ] Make recommendations to management
[ ] Create corresponding tickets if technical solutions are required

Acceptance Criteria

[ ] Test changes (if any) and confirm the solution is functioning
[ ] Create supporting documentation if necessary

Received feedback from Sean (Policy) that we will monitor feedback from ADMs after the soft launch on August 2nd. Then incorporating those feedback before the final launch in September.

Moving this one to the icebox for now until we get direction from PIE/Sean/Rueben about what functionality is required in phase 2.
My recommendation: do research to get a clear idea/requirements of what ADMs would like before we build and/or adjust the current workflow.


Component keeps refreshing when using dynamic custom values

Describe the bug
Component keeps refreshing when using dynamic custom values
To Reproduce
import random
randomlist = []
for i in range(0,5):
    n = random.randint(1,30)
    randomlist.append(n)
search_keywords = st_tags('Keywords:', 'Press enter to add more', randomlist)

Hello,
Currently, the component only accepts static lists
I am working on a fix to enable custom values. Please star the repo is you liked streamlit-tags

is there any update on this?

I am facing the same issue, is there any update on the fix ?

I believe that's how Streamlit works. It hashes component based on all initial values - labels, starting values, options list, key, etc. If any of that changes - Streamlit treats the component as a new one, thus, refreshes it completely. Streamlit works like this for its core components, but I'm pretty sure 3rd party components are treated in the same way, judging from my experience.


Unsupported block type "lifecycle" for several modules in "plan and review" phase

Describe the bug
When I try running the step for "Plan all and review" it seems the tool suddenly stops. I can see in the console the following line is logged:
"<IP_ADDRESS> - - [11/Jan/2024 14:55:25] "POST /terraform_history_configs?tenant_key_main=0&tenant_key_target=1 HTTP/1.1" 200 -
The command cd /home/stian/src/dnb/test-dt-config-mgr/data/work/0-1/terraform/config
terraform plan -lock=false -parallelism=10 -out=./2024-01-11_14-55-25_complete.plan >NUL > /home/stian/src/dnb/test-dt-config-mgr/data/work/0-1/terraform/history/complete/2024-01-11_14-55-25/2024-01-11_14-55-25_plan_all.log 2>&1 failed with error code 1
Deleting old overall directory:  /home/stian/src/dnb/test-dt-config-mgr/data/work/0-1/overall"
Out of curiosity I tried running the command, manually and I see multiple errors like:
"╷
│ Error: Unsupported block type
│
│   on modules/aws_credentials/AWS-CB-Migration-Dev_REGIONS_eu-west-1.aws_credentials.tf line 10, in resource "dynatrace_aws_credentials" "AWS-CB-Migration-Dev_REGIONS_eu-west-1":
│   10:     lifecycle {
│
│ Blocks of type "lifecycle" are not expected here.
╵
"
Screenshots

Desktop (please complete the following information):

OS: WSL Ubuntu 20.04
Browser: Edge (chromium)
Version 1.1.0

Sorry about this, webhook fixed in version v1.1.2
Will look into aws credentials which is similar early next week

Completely fixed with v1.1.3
https://github.com/Dynatrace/Dynatrace-Config-Manager/releases/latest


[Packager] Catch error on starting app version 0.5.0 cocoapods

URL: http://bimawa.local:8081/index.ios.bundle
 line: 1670
 message: Invariant Violation: Application EventLentView has not been registered."
2015-06-08 17:22:26.065 [error][tid:com.facebook.React.BridgeMethodQueue][RCTBridge.m:432] RCTDataManager.queryData was called with 4 arguments, but expects 3

Are you sure you did something similar to AppRegistry.registerComponent('EventLentView', () => EventLentView); in your index.os.js?

Yes. May be something changed in RCT_EXPORT_MODULE. @paramaggarwal can u help me in slack private messages?

Here you have some solutions http://stackoverflow.com/questions/29287987/invariant-violation-application-awesomeproject-has-not-been-registered-when-b.
I had similar issue after update and I have to init new project and copy my source code into.

I had similar issue after update and I have to init new project and copy my source code into.

Yea u right!
i roll out on v.0.4.2 and get new error:
 ERROR  Error while minifying JS
Transformed code line: "    );"
Module name (best guess): precomputeStyle
Unexpected token: punc ()) (line: 19167, col: 4, pos: 620877)

go experimenting more ...

Tag 0.4.3 not describe in React.podspec research continues..

on commit: =>'bb4de45d56aaa5816bece984fa554cbb2881cb04' working fine, except for one thing minifying:
ERROR  Error while minifying JS
Transformed code line: "    );"
Module name (best guess): precomputeStyle
Unexpected token: punc ()) (line: 19167, col: 4, pos: 620877)

update on tag 'v0.5.0' call this (JS_DIR=pwd/ReactComponent; cd Pods/React; npm run start -- --root $JS_DIR)
get fails:
../Pods/React/packager/packager.js:71
    options.root.forEach(function(root) {
                 ^
TypeError: Object true has no method 'forEach'
    at Object.<anonymous> (../Pods/React/packager/packager.js:71:18)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:929:3

I try this call (cd Pods/React; npm run start --root '../../ReactComponent') server launch success but after request root not found:
{ [NotFoundError: Cannot find entry file index.ios.js in any of the roots: ["../Pods/React"]] message: 'Cannot find entry file index.ios.js in any of the roots: ["../Pods/React"]',  name: 'NotFoundError',
  type: 'NotFoundError',  status: 404, errors:  [ { description: undefined, filename: undefined,lineNumber: undefined } ] }

how change root path now?

Founded!!!! Somthing Wrong in new parseCommandLine.js replace this fail from tag v0.4.4 now woring all! Pls review this file guys: parseCommandLine.js

Ah I am also having an issue with this file when upgrading from 0.4.1 to 0.5.0. The error I get is that source.root.forEach is an undefined function - and on further analysis, source.root was coming as a boolean true, though it should be a string.

@paramaggarwal yes and now i fix it local on first time.

This is fixed in 0.6.0-rc with this commit https://github.com/facebook/react-native/commit/769efdfcefd55cfed4fc16752e06bea1e7604a00

I update to 0.6.0, also meet this problem.

Can anyone solve it ?

@threepointone ye it not working for me.
@soliury how i write above, i just exchange parseCommandLine.js from v0.4.4 now i can work.

@bimawa ok, thank you .

@bimawa but, I have try, it failed again.

@soliury  Are you sure that you were in tag v0.5.0 and replace parseCommandLine.js from v0.4.4 ?

oh, I use the tag v0.6.0-rc,

I have find the problem, the v0.6.0-rc don't support the es6 class, I create a new project, i change the example file to use class xxx extends Component, it will show this bugs.

hmm ok i go try too thx

So, I think it's the problem of babel

Still getting this on 0.6.0rc - happens for folks using a custom --root attribute on the packager.
/Users/Param/Documents/ios-app/Pods/React/packager/packager.js:71
    options.root.forEach(function(root) {
                 ^
TypeError: undefined is not a function
    at Object.<anonymous> (/Users/Param/Documents/ios-app/Pods/React/packager/packager.js:71:18)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
    at startup (node.js:129:16)
    at node.js:814:3
Process terminated. Press <enter> to close the window

I'm running package with a modified launchPackager.command.
#!/bin/bash

THIS_DIR=$(dirname "$0")
$THIS_DIR/Pods/React/packager/packager.sh --root $THIS_DIR/JS
echo "Process terminated. Press <enter> to close the window"
read

I confirm that using --root with the packager works again now in v0.6.0rc after previously working in v0.4.1 for me.

Ok, everyone, this is the problem - when you update to v0.6.0rc, some of the require() methods have changed. For example require('createReactIOSNativeComponentClass'); is now var { requireNativeComponent } = require('react-native');. The packager is actually failing internally because some of the require() calls are failing. This will need further debugging as to why packaging errors are not bubbling up and showing up in the terminal.

So how to solve it ?

@soliury by fixing all the require() calls. If a module that does not exist is inside require(), then it'll fail - otherwise it will work fine.

@brentvatne appears this issue has been solved.


replace sycl::queue* with sycl::queue and rename dp.cpp files

We should not use sycl::queue in pointer format. It's already a container of actual pointer(from https://intel.github.io/llvm-docs/doxygen/queue_8hpp_source.html):

Also, we should not use *.dp.cpp as filenames. Just use *.cpp.
We applied these modifications in our forked repo for transform inference part. We can apply these to other parts in this repo,too.
@delock @CaoZhongZ

I'm okay with the change.   Need to check UT passrate.

@delock How to run UT? Anyone could help to do that?


Make new apps "deployable to Heroku" by default

This change makes new suspender apps "deployable to Heroku" by default,
moving the Heroku setup in the local machine to be run by default (i.e.
with the --heroku flag off). All the setup that requires to hit the
Heroku API to create the staging and production apps is kept to be run
only with the flag on.

Thank you! Linking to related issues:

https://github.com/thoughtbot/suspenders/issues/735
https://github.com/thoughtbot/suspenders/pull/604

While we are editing, can we improve the changed lines to comply with the style guide, and please Hound CI? Thanks!

Left a few comments and questions. This is great work, thank you @sebarmano!

This is already a step forward. Question: do you think it's worth it to extract a shell script that performs the stateful operations?

Create Heroku apps, pipelines, and remotes
Configure CI autodeploys
Set static files, rails secret, and application host constants

This would require some refactoring in suspenders. We could work on it as part of a different PR, too.

Great, thanks! Let me know when you consider this ready for another review.

Let me know when you consider this ready for another review.

I think it's ready for review @tute. I fixed the Hound issues and deleted the redundant app.js test. Please, let me know if you think of anything else that can be improved regarding this PR.

I think it's ready for review @tute. I fixed the Hound issues and deleted the redundant app.js test. Please, let me know if you think of anything else that can be improved regarding this PR.
Show all checks

What do you think of dividing the spec with more descriptive sections? https://github.com/thoughtbot/suspenders/pull/756#discussion_r61895648

Do you think we should solve https://github.com/thoughtbot/suspenders/pull/756#issuecomment-216561336 as part of another PR?

What do you think of dividing the spec with more descriptive sections?
I think it's a good idea. Right now we are "suspending" only one app to run all the tests in the block. Splitting the tests will add the time of creating a new app for each one of them (which I don't think is an issue at this point given the amount of tests).
Also, right now there are three tests inside the block and one outside (the app.js one). I think splitting the tests will improve consistency in the feature spec file.

Do you think we should solve #756 (comment) as part of another PR?
As I understand, the idea is to be able to have fully functional apps without the need of creating the staging and production Heroku counterparts. I think that if we keep the circle.yml file by default and someone intends to use Circle CI it just for their local app, it won't work (please correct me if I'm wrong on this). So I think the best call is to keep that file to be created only under when the --heroku flag is on. Also, I think that the change is part of this same PR as otherwise we would be merging something that is not 100% functional for some use cases.

Ok, I think that the PR is ready for another review. I moved back the Circle CI configuration based on this comment. Also, I've divided the specs in new_project feature spec file to be more descriptive.

Splitting the tests will add the time of creating a new app for each one of them

Because we use before(:all) instead of before(:each), we recreate a suspenders app once regardless of the number of examples in the spec file, so there should be no performance penalty.

I think that we can work on that in another PR, as it is related to this same issue but is not exactly the same thing. This PR is solving a problem related to not having the Heroku setup for local apps. The comment you mention seems more like a new feature of suspenders, right?

Makes sense to me. 👍

Looking great, left two minor comments. Thank you! 🎉

I just pushed the last changes and I think it's again ready for another review. In addition to the changes you mentioned, I changed the name of the methods and tests related to app.js file to mention the "manifest". I think that name is more accurate and is the name Heroku uses. In this way, for example, if someone wants to know more about what this file does, it will be easier to google for it after the methods' names and their contents. Feel free to tell me if this doesn't make sense, I can rename back the methods.

Looking great! Added a note on a missing step. Thanks!

Ready for another review (thanks for taking the time to review this like a million times!). I moved the Heroku gems method to be run by default.
The only thing that I'm not 100% sold with is the test. I left the test as it was before (just moved it to the right place), but it's testing just that the gem is in the Gemfile, not that is inside the production & staging block. I couldn't find a way of testing it in an easy way, but if you think of one I'm happy to add that too.

Hey, thank you for your patience with the iterative work and feedback! :)
You know what? If we always add that gem into the Gemfile, we can directly edit the template/Gemfile.erb file, and add the gem in the production environment, after rack-timeout so we keep the alphabetical order. We can then drop the code for setup heroku gems, but I'd leave the test where it is.
Thanks again for your work and patience! :)

Sure! This is good because I learn how the codebase works with each step.
I just pushed another version for review. As we removed the method that was adding the rails_stdout_logging I was able to also remove a method from the Heroku adapter and its test that were there just because of that gem. This is just a heads up so you can tell me if I went too far removing that.

The spec would document why we have that line there, and in that sense it is useful. Anyway Rails 5 is just around the corner and we won't need that gem anymore, so this looks good. Will test soon-ish, and when I see everything works as we expect, I'll merge. Thank you! 🎉

Just to clarify, I didn't remove the test in the new project feature spec referencing that gem, which is still there and testing it.
In the heroku adapter there was a method to add that gem (and the corresponding spec in the heroku adapter tests). I removed that method (and test) which I think is not needed anymore because the gem is added via the Gemfile template.
Also, just found a typo in that I'll fix now.

Just to clarify, I didn't remove the test in the new project feature spec referencing that gem, which is still there and testing it.
In the heroku adapter there was a method to add that gem (and the corresponding spec in the heroku adapter tests). I removed that method (and test) which I think is not needed anymore because the gem is added via the Gemfile template.

That is perfect. 👏 👍

Just fixed the typo in this last push, so it's basically the same as before.

Thanks so much! 🎉