Liveness issue with ELECTION

In the past weeks, I played a bit with the idea of partial connectivity [1][2]. The test I executed consecutively here involves 5 nodes named A to E, where A is the leader.  This was enough to record different behaviors.
During the partial connectivity issue, leader A stepped down, and I did not find any violation in safety. Nodes A, B, and C all seem to realize the cluster is in partial connectivity, although consistently, in all executions I did, nodes D and E do not update their view (not sure if this is a problem). Their logs show something similar:
165681 [WARN] GMS: D: not member of view [A|7]; discarding it
168589 [TRACE] FD_ALL3: D: sent heartbeat
168590 [DEBUG] FD_ALL3: D: haven't received a heartbeat from E in timeout period (40000 ms), adding it to suspect list
168591 [DEBUG] FD_ALL3: D: haven't received a heartbeat from B in timeout period (40000 ms), adding it to suspect list
168591 [DEBUG] FD_ALL3: D: haven't received a heartbeat from A in timeout period (40000 ms), adding it to suspect list
169202 [TRACE] GMS: D: I'm not the merge leader, waiting for merge leader (A) to start merge

In some executions, node C was elected the leader. I think the election from the dissertation [3] is unable to make progress in this case. Finding a way for this to happen deterministically would be the best. Since node C still connects to everyone, it should be able to reach quorum. But we should still respect the restrictions RAFT imposes, e.g., log prefix [3].
Now getting to the weird behavior.

In some executions, some nodes relentlessly try to become the leader, increasing the term in succession. In one execution, node A went from term 7 to 85 before stopping the voting thread.
And a liveness issue. After the network recovers, the nodes remain without electing a new leader. This requires manual intervention to restart nodes.

For the first scenario, I didn't dig too deep. I believe it happens when the node receives a merge view and mistakenly thinks it still connects to a majority, going on a spree sending vote requests until the view updates.
The second issue is where I spent more time. From what I could identify, nodes A, B, and C updated their views during the partial connectivity period, but nodes D and E did not. The issue happens after the network is restored and the view coordinator either nodes D or E. Since they still see the old view before the disconnection, they compute the update as "no_change" and do not start the voting thread, still believing node A is the leader. Meanwhile, nodes A, B, and C are idle since they are not the view coordinator. Some logs from node A after the network is restored:
330341 [DEBUG] GMS: A: I will be the merge leader. Starting the merge task. Views: {B=[A|8] (3) [A, C, B], E=[A|4] (5) [A, B, C, D, E], A=[A|9] (2) [A, C]}
330341 [DEBUG] GMS: A: merge task A::2 started with 4 participants
330342 [TRACE] GMS: A: sending MERGE_REQ to [B, D, A, E]
330342 [TRACE] GMS: A: got merge request from A, merge_id=A::2, mbrs=[C, B, D, E, A]
330344 [TRACE] GMS: A: fetched all digests for [C, A] in 2 ms
330344 [TRACE] GMS: A: got merge response from A, merge_id=A::2, merge data is sender=A, view=[A|9] (2) [C, A], digest=C: [3 (3)], A: [93 (93)]
330344 [TRACE] GMS: A: got merge response from B, merge_id=A::2, merge data is sender=B, view=[A|8] (1) [B], digest=B: [2 (2)]
330346 [TRACE] GMS: A: got merge response from D, merge_id=A::2, merge data is sender=D, view=[A|4] (1) [D], digest=D: [0 (0)]
330346 [TRACE] GMS: A: got merge response from E, merge_id=A::2, merge data is sender=E, view=[A|4] (1) [E], digest=E: [0 (0)]
330347 [TRACE] GMS: A: collected 4 merge response(s) in 5 ms
330347 [TRACE] GMS: A: consolidated view=MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]
consolidated digest=E: [0 (0)], B: [2 (2)], D: [0 (0)], C: [3 (3)], A: [93 (93)]
330347 [DEBUG] GMS: A: installing merge view [E|10] in [B, D, E, A]
330347 [DEBUG] GMS: A: merge A::2 took 6 ms
330347 [DEBUG] GMS: A: installing view MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E] ([E, B, D] joined)
330348 [DEBUG] ELECTION: A: existing view: [A|9] (2) [A, C], new view: MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E], result: reached
-- view change: MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]
330348 [TRACE] GMS: A: mcasting view MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]

And node E:
296449 [TRACE] GMS: E: got merge request from A, merge_id=A::2, mbrs=[E]
296453 [DEBUG] GMS: E: installing view MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]
296454 [DEBUG] FD_SOCK: E: socket to A was closed gracefully
296455 [DEBUG] FD_SOCK: E: pingable_mbrs=[E, B, D, C, A], ping_dest=B
296455 [TRACE] FD_SOCK: E: ping_dest=B, ping_sock=Socket[addr=/<IP_ADDRESS>,port=35159,localport=38397], cache=C: <IP_ADDRESS>:33045 (295 secs old)
A: <IP_ADDRESS>:44261 (295 secs old)
B: <IP_ADDRESS>:35159 (295 secs old)
D: <IP_ADDRESS>:43301 (295 secs old)
E: <IP_ADDRESS>:37185 (295 secs old)

296456 [DEBUG] ELECTION: E: existing view: [A|4] (5) [A, B, C, D, E], new view: MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E], result: no_change
-- view change: MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]
296457 [TRACE] GMS: E: mcasting view MergeView::[E|10] (5) [E, B, D, C, A], 3 subgroups: [A|8] (3) [A, C, B], [A|9] (2) [A, C], [A|4] (5) [A, B, C, D, E]

I did a small reproducer here. This is not replaying the whole stack, only RAFT and ELECTION simulating the steps with the views. In the end, no leader is elected.
Entering now into possible solutions, which also happens to be a highly suggested optimization, too. In Diego's dissertation [3], Section 9.6 quickly describes the PreVote mechanism. In summary, a node would query the nodes it knows to inspect if it can start a new election, helping to avoid disrupting the cluster.
Our implementation is already stable concerning disruptions and already includes the CheckQuorum optimization [4]. I propose adding the PreVote before starting the voting thread so address case 1 described previously.
To solve issue 2, we could add PreVote if the node computes the new view with "no_change" and is the new view coordinator and is not the RAFT leader. This would cause the node to probe everyone, and if it receives a majority of replies agreeing, the node then starts the voting thread. To reinforce, we keep everything as we have today and only include the PreVote as an additional validation before running the voting thread. See, this could also add a slight delay in the election process.
Let me know what you think of this. If this is something that we workaround with configuration changes would be good, too. I can check other scenarios from [1][2] to stress the implementation.

[1] https://dl.acm.org/doi/pdf/10.1145/3552326.3587441
[2] https://omnipaxos.com/blog/how-omnipaxos-handles-partial-connectivity-and-why-other-protocols-cant/
[3] https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf
[4] https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/
Reproducer: https://github.com/jabolina/jgroups-raft/commit/4231a04dc9637aaa962b76ebd14ac62c5d4f23f6

Hi Jose
implementing the prevoting, as discussed in Diego's thesis in ch. 9.6, sounds like a good plan.
Modeling the faults in PartialConnectivityTest first is critical IMO, then implementing prevoting and making sure the previously failing test now passes.

Given that partial connectivity is the edge case, and not the norm, I suggest creation of an ELECTION2 protocol, perhaps extracting the common functionality into an Election class, and making ELECTION and ELECTION2 extend it.
Alternatively, allow users to configure whether or not they want a prevoting phase: some users may not want this as patial connectivity will not occur in their networks, or - if it does occur - they're willing to allow for manual intervention.

Thanks, Bela.
I plan on following the approach you suggested in creating the ELECTION2, asserting the PartialConnectivityTest is catching the issue (and working with the fix), and in addition:

Extend some tests to cover both election protocols;
Include an operation to start the voting thread. Focused for operators, an easier way for manual intervention.


tests: drivers: counter: counter_basic_api: run on google_dragonclaw

Add google_dragonclaw board definition and allow running the drivers.counter.basic_api.stm32_subsec test on the board.

@nordic-krch please take a look.


Support TLS 1.1 and 1.2 in .NET 4.5

Hi Kerry,
I found out that a SuperWebSocket server only supports TLS 1.0 even on .NET 4.5 when I use security="tls" configuration.
I've checked with Wireshark that even on Windows Server 2012 R2 with .NET 4.5.2 the SuperWebSocket only supports up to TLS 1.0.
When I use WebSocket4Net as a client, the version is capped to 1.0 by the client. When I connected from browser JS, client hello contained version 1.2 but server responded with 1.0.
Custom test client/server app between two test servers (same configuration - WS 2012 R2, .NET 4.5.2) managed to use TLS 1.2, so it should be supported by the system and platform in question.
The tested SuperWebSocket version was a NuGet package <IP_ADDRESS>
Thank you,
Honza

Yes, I improved the SuperSocket to support TLS/SSL better, but have not migrated to SuperWebSocket yet.

Closing this old issue since this is now solved in newer versions and the improved NuGet package structure and releases.


when user focus on the game for the first time, scroll up to the top

element.scrollIntoView()

Turns out this was just a confusing state because of other bugs.
Fix for #222 make this not a issue.


Remove cities behind timezone

Please remove cities behind timezones because it is just too long for the design:

Expected behaviour:
(UTC-06:00) 12:00
Note: we have file with timezones, we just need to remove the part after ()

@arsenijesavic I don't see this on dev yet?

@arsenijesavic looks good, but the timer looks like it is proposal about to expire or something and I am not sure if it is pm or am?

Can we:

remove the seconds
change to AM / PM format (only if possible)


Trim state via snapshots, only keeping last 128 blocks

The state database size is really out of control.

Have added entries() to trie to help accomodate.


Cannot exit since version 1.54.0

VS Code Version: 1.54.0, 1.54.3, and 1.55.0-insider
OS Version: Ubuntu 18.04.5 LTS

Clicking on the close button has no effect. File -> Exit and CTRL+Q do not work as well. This also happens on fresh installation without any extension and anything opened. Downgrade to 1.53.x solves the problem.
Steps to Reproduce:

Click on the close button

Does this issue occur when all extensions are disabled?: Yes

[main 2021-03-22T10:51:11.777Z] Lifecycle#window.on('close') - window ID 1
[main 2021-03-22T10:51:11.778Z] Lifecycle#unload() - window ID 1
[18894:0322/185111.780497:INFO:CONSOLE(626)] "%cTRACE color: #888 [lifecycle] onBeforeUnload (reason: 1)", source: file:///snap/code-insiders/661/usr/share/code-insiders/resources/app/out/vs/workbench/workbench.desktop.main.js (626)
[18894:0322/185111.782592:INFO:CONSOLE(626)] "%cTRACE color: #888 [lifecycle] onBeforeUnload continues without veto", source: file:///snap/code-insiders/661/usr/share/code-insiders/resources/app/out/vs/workbench/workbench.desktop.main.js (626)
[main 2021-03-22T10:51:11.784Z] Lifecycle#unload() - no veto (window ID 1)
[18894:0322/185111.786123:INFO:CONSOLE(626)] "%cTRACE color: #888 [lifecycle] onWillUnload (reason: 1)", source: file:///snap/code-insiders/661/usr/share/code-insiders/resources/app/out/vs/workbench/workbench.desktop.main.js (626)
[18894:0322/185116.791773:INFO:CONSOLE(626)] "%c WARN color: #993 [lifecycle] onWillShutdown is taking a long time, pending operations: join.closeStorage", source: file:///snap/code-insiders/661/usr/share/code-insiders/resources/app/out/vs/workbench/workbench.desktop.main.js (626)

Culprit seems to be SQLite storage:
onWillShutdown is taking a long time, pending operations: join.closeStorage

I also see you are using the Snap version. Could you try the same with our Zip archive to see if it is related to snap or not: https://az764295.vo.msecnd.net/stable/2b9aebd5354a3629c3aba0a5f5df49f43d6689f8/code-stable-x64-1615806628.tar.gz

The problem exists in the Zip version as well.

Can you try to run code --disable-extensions --user-data-dir <directory> where <directory> is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.

Tried that. No luck. Still not working.

Is there anything special about your filesystem that could have an impact?

No I don't think so.

At this point I am pretty much clueless and I have not heard from anyone else facing this issue. On close of a window we want to normally shutdown our SQLite connection used for persisting UI state. For some reason this seems to be taking more than 5s on your machine. Does it ever eventually finish or hangs forever?
Does it make any difference if you do File - Exit compared to opening 2 windows and just closing 1 window with the X? Does it reproduce when you close an empty window (from File - New Window)?

It just hangs forever. I've tried using File - Exit, tried closing 1 window with multiple windows opened, tried closing empty window. None of them works.

Can you maybe send me or attach the entire logs folder, I wonder if there is more. Ideally to it from a fresh --user-data-dir to have isolated logs. The logs folder is within.

logs.tar.gz
Here is the logs folder. I run vscode using code --disable-extensions --user-data-dir <directory> and try to close it using the x button. And terminate it using CTRL-C in terminal after a while. To me, it seems that there is nothing related.

This one is also a bit suspicious:
[error] Extension host terminated unexpectedly

Can you do the same running with --verbose this time, again from a fresh user data dir? That should produce a lot more output.

logs.tar.gz
Seems the error you mentioned above happened after I CTRL-C to terminate VSCode so it seems unrelated. Here is the logs folder running with --verbose and before terminating.

Thanks, I don't see anything suspicious.
Would you be able to setup your machine to run VSCode out of sources to conduct some more testing? I understand if that is not possible, but then I fear I need to wait for more users to chime in to give more information if possible.

I cannot do much on the company-owned laptop. I'll try to setup a similar environment on my own laptop and see if I can reproduce this problem.

That would be great 👍

@bpasero I pretty much have the same issue.


PS4: The media_player.select_source service doesn't appear to work

Home Assistant release with the issue:

0.91.1
Last working Home Assistant release (if known):
Unknown
Operating environment (Hass.io/Docker/Windows/etc.):

Docker
Component/platform:

ps4
Description of problem:
Although it appears it should support it, the PS4 integration doesn't seem to respond to the media_player.select_source service. Details below.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):
No traceback appears.
Additional information:
Here's an example of my PS4 integraiton with an existing source (i.e., a game that's been played at least once):

When I call the service with the required payload:

...the source of the media player doesn't change:

CC: @ktnrg45

@bachya What happens when you select the source from the drop down menu?

When I manually select the source, the UI changes to this:

...and the game starts.

I believe the title will need to be in utf8. The punctuation/special characters is why it doesnt work for your automation.

Ill submit a pr later for this.


fix table formatting in digest

follow-up to #4354, see e.g.
http://dlang.org/phobos/std_digest_crc.html

As with #4358, dmd's handling of empty lines should be fixed instead of working around it here.

closing in favor of fixing ddocs
https://issues.dlang.org/show_bug.cgi?id=16110


Error in log query

It seems like the application log entries might have changed format. Case one says it should be:
//case 1: for records that end with: "was denied. Reason: SNI TLS extension was missing."

but that is not the case. It seems to now be in format:
//case 1: for records that end with: "IP:PORT. Action: Deny. Reason: SNI TLS extension was missing."

Problem is the dot (.) after port.. TempDetails assumes there is a blank space after port, but for this message there is a dot. I solved this by adding
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int "." TempDetailsDeny
//case 1: for records that end with: ". Action: Deny. Reason: SNI TLS extension was missing."
| parse TempDetailsDeny with " Action: " Action1 ". Reason: " Rule1

and in the end just replaced
Action1 = case(Action1 == "denied","Deny","Unknown Action")

with
Action1 = case(Action1 == "Deny","Deny","Unknown Action")

Then I got all my error messages showing

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

ID: 2cc1c543-6db1-23cd-0f7a-4506f53b7d90
Version Independent ID: a7c1b69f-67dc-d94a-05d7-1d603ea82461
Content: Azure Firewall log analytics samples
Content Source: articles/firewall/log-analytics-samples.md
Service: firewall
GitHub Login: @vhorne
Microsoft Alias: victorh

@tesharp , Thank you for your feedback. I have assigned this issue to author to validate and make necessary changes.

@tesharp Thanks for the update.
Modified the the statement to Action1 = case(Action1 == "Deny","Deny","Unknown Action")
and merged.
#please-close


How should we deal with Docker Hub's inability to handle this?

Well this is disappointing: https://github.com/docker-library/official-images/pull/2511#pullrequestreview-15404410
It sounded like this would be possible to do in official images, but not yet I guess.
Given all that, @Quantisan, should we revert master to where it was before #28 & #27 were merged?
Then I can start on another attempt that will work with their official image building infrastructure.

@cap10morgan thanks dude!

Merging #30 & #31 should accomplish the revert.

👍


Rotary encoder velue change not on every click

Bug
What I did

Connected HW-040 Rotary encoder for volume control.
What happened

Does not change volume on every "click".
There exist different hardware types of Encoders with different mechanical stops.
For the 4 electrical combinations some encoders have only 2 stops and some have all 4.
I now got one of the boards with 4 stops and the code seems to cover only 2 stops so the volume changes only on every second step.
I expected this to happen
I expect a config option to switch between both types of encoders.

Further information that might help

Software
Base image and version

Raspbian GNU/Linux 10 (buster)
Branch / Release

2.3rc1 - f33e214 - develop
Installscript

Hardware
RaspberryPi version

RPI 3b
RFID Reader

Soundcard

Other notable hardware

Closing as there was no activity for a very long time.
Please check the current release 2.4 or our new implementation 3.2, if this issue still persists. Also GPIO has been significantly improved.
Feel free to open a new issue, if necessary.


Add FinalVal wart

any update on this?
should i add the following example to readme?
$ echo "object a { final val v = 1 }" > a.scala
$ echo "object b extends App { println(a.v) }" > b.scala
$ sbt ~run
1
$ echo "object a { final val v = 2 }" > a.scala
1

What is the proposed workaround for this situation?

Also, is there a bug filed against scala that we can link to?

It's in the spec, it's expected behaviour.

workaround is to use non-final vals
it's not a Scala bug, but it's still quite unsafe

@dwijnand Inlining is certainly in the spec but the incremental compiler not recompiling dependent files due to inlining is not (to my knowledge).
@tim-zh My concern there is that making a val non-final changes the semantics and people use final for a reason. I think we could say in the error message to use final def instead which does not seem to break incremental compiliation but preserves the desired semantics.

Yeah, I agree with you there. We should open a ticket against Zinc to fix it.

Btw it's constant-folding, not inlining.
And making it a def or adding a type ascription to the val are other alternatives.
val v: Int = 1
def v: Int = 1
final val v: Int = 1

@dwijnand Indeed, thanks. It's a bit trickier than i thought, and it means the pr can't be merged :(, since we can't prevent false positives right now.

@tim-zh I think the only false-positive you're missing is final val v: Int = 1, which doesn't get folded. You can take the approach from ExplicitImplicitTypes to check for the annotation. Unlike with defs, the annotation should always be on the same line for vals. The only false positives we should see there are final vals generated by macro expansion which we'll hopefully have an answer for soon.

This looks set to merge to me and it'll go out in 1.1.0. The one additional thing I'd like to see is a ticket for the bug against Zinc so we can link to it in the README. Since this wart is related to an actual bug I want to know when it stops being relevant (due to a bugfix).

@ChrisNeveu sbt/sbt/#1543 ?

Thanks! I'll add a link to that in the README.

by the way, the incremental compiler now tracks these kind of constant vals


Bot created PRs are not being triaged

When a bot such as Dependabot opens a PR, it is not being triaged (labeled). These cases are still useful because we still need to review these, and it helps us mark what PRs may or may not be reviewed.

@nesl247 I am considering it now. Here is relevant part. https://github.com/pr-triage/app/blob/master/index.js#L23-L26. I agree with your use case so I'll remove the code.

@nesl247 I have merged the pr. It should be cool :sunglasses:.

Thanks!


Error when creating warehouse worksheet lines from pick worksheet

Hello,
we found a bug when createin warehouse worksheet lines:
When creating a "Whse. Worksheet Line" (Table 7326) via the "Pick Worksheet" (Page 7345) with the action "Get Warehouse Documents" the created lines have the description of the item and not the warehouse shipment line.
I analyzed that the GetItem-Funktion overwrites the description with the item description Can you fix this?

Alexander

Sorry, this is not an extensibility issue, please create hotfix request using regular partner support channels.


Error while fitting

AssertionError                            Traceback (most recent call last)
/tmp/ipykernel_33/4176855811.py in
----> 1 automl.fit(X_train, y_train, task="regression",metric='rmse',time_budget=3600)
/opt/conda/lib/python3.7/site-packages/flaml/automl.py in fit(self, X_train, y_train, dataframe, label, metric, task, n_jobs, log_file_name, estimator_list, time_budget, max_iter, sample, ensemble, eval_method, log_type, model_history, split_ratio, n_splits, log_training_metric, mem_thres, pred_time_limit, train_time_limit, X_val, y_val, sample_weight_val, groups_val, groups, verbose, retrain_full, split_type, learner_selector, hpo_method, starting_points, seed, n_concurrent_trials, keep_search_state, early_stop, append_log, auto_augment, min_sample_size, use_ray, metric_constraints, **fit_kwargs)
2089
2090         self._validate_data(
-> 2091             X_train, y_train, dataframe, label, X_val, y_val, groups_val, groups
2092         )
2093         self._search_states = {}  # key: estimator name; value: SearchState
/opt/conda/lib/python3.7/site-packages/flaml/automl.py in _validate_data(self, X_train_all, y_train_all, dataframe, label, X_val, y_val, groups_val, groups)
887             assert isinstance(y_train_all, np.ndarray) or isinstance(
888                 y_train_all, pd.Series
--> 889             ), "y_train_all must be a numpy array or a pandas series."
890             assert (
891                 X_train_all.size != 0 and y_train_all.size != 0
AssertionError: y_train_all must be a numpy array or a pandas series.
Info about data
<class 'pandas.core.frame.DataFrame'>
RangeIndex: 15129 entries, 0 to 15128
Data columns (total 28 columns):
Column                Non-Null Count  Dtype

0   bedrooms              15129 non-null  uint8
1   bathrooms             15129 non-null  float32
2   sqft_living           15129 non-null  uint16
3   sqft_lot              15129 non-null  uint32
4   floors                15129 non-null  float32
5   waterfront            15129 non-null  uint8
6   view                  15129 non-null  uint8
7   condition             15129 non-null  uint8
8   grade                 15129 non-null  uint8
9   sqft_above            15129 non-null  uint16
10  sqft_basement         15129 non-null  uint16
11  yr_built              15129 non-null  uint16
12  yr_renovated          15129 non-null  uint16
13  lat                   15129 non-null  float32
14  long                  15129 non-null  float32
15  dateyear              15129 non-null  uint16
16  datequarter           15129 non-null  uint8
17  datemonth             15129 non-null  uint8
18  dateday               15129 non-null  uint8
19  dateday_of_week       15129 non-null  uint8
20  dateday_of_year       15129 non-null  uint16
21  dateweekofyear        15129 non-null  uint8
22  dateis_month_end      15129 non-null  uint8
23  dateis_month_start    15129 non-null  uint8
24  dateis_quarter_end    15129 non-null  uint8
25  dateis_quarter_start  15129 non-null  uint8
26  dateis_year_end       15129 non-null  uint8
27  dateis_weekend        15129 non-null  uint8
dtypes: float32(4), uint16(7), uint32(1), uint8(16)

Hi @GDGauravDutta, is your y_train_all a pandas series? Make sure it is in pandas series format.  Let me know if it does not resolve the issue. Thank you!

Hi @GDGauravDutta, is your y_train_all a pandas series? Make sure it is in pandas series format.  Let me know if it does not resolve the issue. Thank you!

All are series

Hi  @GDGauravDutta, Can you share with me a copy or a sub-sample of your data such that I can reproduce the error you had? Thank you!


desert_stone, cobble bug

When you dig moreblocks:slope_desert_stone it turns into desert_cobble
and stone slope into default:cobble

This happen after recent changes. Even micro block stone turns into default:cobble
Anyone else have this issue?


4.1 Extended languages, refined translations, added details

Now some initial support for 12 languages is included in this project.

Looks good, current state could update main.


Error: failed to start faucet: Unable to bind faucet to <IP_ADDRESS>:9900

When I first try to run trdelnik test, it fails saying localnet is not running, and then if i retry, it says the port is already used, so im thinking its not waiting long enough or something?

-------------- TEST START --------------
Error: localnet is not running
thread 'test_happy_path' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/test/src/lib.rs:185:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test test_happy_path ... FAILED

failures:

failures:
    test_happy_path

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.10s

error: test failed, to rerun pass '-p trdelnik-tests --test test'
Error: testing failed
swaystar@Babaji:~/programming/solana/altruism$ Waiting for fees to stabilize 1...

swaystar@Babaji:~/programming/solana/altruism$ trdelnik test
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /home/swaystar/programming/solana/altruism/programs/altruism/Cargo.toml
workspace: /home/swaystar/programming/solana/altruism/Cargo.toml
warning: unused import: `altruism`
 --> trdelnik-tests/tests/test.rs:5:5
  |
5 | use altruism;
  |     ^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `trdelnik-tests` (test "test") generated 1 warning
    Finished test [unoptimized + debuginfo] target(s) in 0.40s
     Running unittests src/lib.rs (target/debug/deps/altruism-4cce7156c9d72dbd)

running 1 test
test test_id ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/program_client-316725de8b77c5f3)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/test.rs (target/debug/deps/test-429cbf0c0b1f2f8b)

running 1 test
-------------- TEST START --------------
Error: failed to start faucet: Unable to bind faucet to <IP_ADDRESS>:9900, check the address is not already in use: Address already in use (os error 98)
program_keypair(1).pubkey = Po1RaS8BEDbNcn5oXsFryAeQ6Wn8fvmE111DJaKCgPC
program_keypair(1).pubkey = Po1RaS8BEDbNcn5oXsFryAeQ6Wn8fvmE111DJaKCgPC
Error: localnet is still running
thread 'test_happy_path' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/test/src/lib.rs:185:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test test_happy_path ... FAILED

failures:

failures:
    test_happy_path

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.39s

error: test failed, to rerun pass '-p trdelnik-tests --test test'
Error: testing failed

https://github.com/SwayStar123/altruism
Here is the entire anchor project

Hey @SwayStar123,
thanks for your issue! Can you please tell me which version of anchor CLI do you use locally? In your code you work with anchor 0.24 which should be ok for trdelnik but what version of CLI do you use?
Trdelnik should be optimized for anchor < 0.25 (need to fix it in our readme). We currently exploring the version 0.25 so it's not supported yet.

@stefanprokopdev i tried both 0.25 and 0.24 currently using 0.24

@SwayStar123 Hi! We've just released a new version 0.2.0 with configurable startup timeout for solana-test-validator.
Make sure to check the CHANGELOG.md and the Configuration section in the README.md as this is a breaking change.

@SwayStar123 I'm closing this issue as I consider it resolved based on our conversation in #71


Question: UI thread slows down in Android when ForeGroundService in action

Hi,
OS: Android
I'm working on an Android application that uploads audio/video/images in background (while the user can still use the UI).
I tried this package and it works well. However, when the audio/video/image upload is going on in a ForeGroundService, the UI becomes very unresponsive.
I think this is expected as the Headless JS uses the UI thread (or the main thread).
Is there a way to get around this behaviour?
Thank you.

Hi @santo4ul, you might want to take a look at https://medium.com/@slavo3dev/mastering-threads-in-react-native-boost-your-apps-performance-cd915c8fa752


Whether to and how to display image message?

I have read the docs of blessed and written some code snippets to test the Image element. I could not find practical code of using blessed to display images in a scrollable box.
In general, Image in blessed confuses me in the following aspects:

It provide two types of Image: ansi and overlay. The former use ascii characters to render images so it lacks precision. The latter use w3mimgdisplay to display real image but it lacks compatibility with terminal. Which type should I use?
It maybe difficult to display image in proper location and size.

Must specify style option like top/left, cannot really "append" new image after the last message automatically.
The doc says height/width are options of ansi image that differs from other element's height/width in that only one of them is needed since blessed will maintain the aspect ratio. But I found that set either of them will cause freeze of the whole program. And the scale option does not work either.
For overlay image, height/width are independent of each other, it will be difficult to keep the ratio.

Image behaves like element more than content so it is unnatural to fit images into the log element which is containter of text messages.

I have searched node-facenet for blessed.image but the only usage is to show icon. Displaying images in the chat client is more difficult. Maybe we can just save non-text messages as local file.
@huan Do you have experience in using blessed to display lots of images? Can you give me any suggestions? Thanks!

Thank you very much for asking this great question. The CLI would be great if we can display beautiful images for users.
For your first question, I believe we should always make sure we are compatible with the terminal because the CLI is mainly for terminal users, we must make sure all terminals can run our cli without any problem. One additional reason is that we are planning to use the react-blessed to run our cli in the browser (for example, here and there), which means the compatibility with the terminal is the key (I guess, please correct me if I'm wrong).

It may be difficult to display images in the proper location and size.

For size, I remember that in the facenet manager, I'll resize the image to fit the terminal first, then paint it. This way might help.
BTW: I have just recorded a Facenet Manager screenshot at https://asciinema.org/a/427927, you can use the same command to run it locally, and try more with docker.

At last, as you said:

Image behaves like element more than content so it is unnatural to fit images into the log element which is the container of text messages.

I believe, for now, we can just show a clickable text message in our term to let user know it's an image message (like "Image message, click me to view"), then if the user clicks the image message, we pop up an image element to show the image for the user. We do not require scroll-able image messages now, maybe not necessary in the future, too.
Please let me know if the above suggestion works for you or not, thanks.


section updated

The history and use of worry dolls is added after the input section

Can you check this pull request


How to load this model by java?

I just tested the handtrack.js performance, more or less about 5ps~8ps in my computer. I suspect the performance will be improved if I build a java server with strong compute ability node to handle the canvas image frame.
What a pity, I am not quite familiar with the tensorflow java api. Could you show me more about how to load pb file and manifest.json by java ?
Thanks so much

I tried to load as below:
SavedModelBundle model = SavedModelBundle.load("${mypath}\ssdlitemobilenetv2\frozen_inference_graph_141 14-51-46-798.pb", "serve");
and error as below:
org.tensorflow.TensorFlowException: SavedModel not found in export directory:

I have implemented the model recognition by java. However, I found it's slower than the js code...

Glad you found a solution.


Big problem

with the new material-ui update the imports  of speed-dial are all wrong

Hi,
as you can see in readme for material-ui you should use https://github.com/smollweide/material-ui-speed-dial
Greetings


Problem of loading vector points

VectorTilePointsWithBatchTable/tileset.json
tileset.style.labelText =
{
evaluate: function (feature) {
let strName = feature.getProperty('name');
return strName;
}
}
Adjust the height and browse repeatedly
texture manage Has been decreasing, Until negative
1:  This causes the memory to not be released correctly
2:  Load a larger vctr to load text  Will reduce the frame rate
A large number of warning messages appear:
'requestAnimationFrame' handler took 207ms

@qwedsazh Thanks for reporting this - are you able to share a sample tileset that you used to reproduce this issue?

VectorTilePointsWithBatchTable.zip
Such as this tileset
Tileset.style.labeltext   needs to be set when loading

@qwedsazh I've tried to reproduce this on my laptop but haven't been able to. Could you please share a Sandcastle with the code you're using to run into this issue? Thanks.

@ebogo1
This is the link address.
https://sandcastle.cesium.com/#c=vVRtb9pIEP4re3ypuZLFBEjaBqLLQZszCiYJTloiSyfbDLDB3uV21xBT5b931jYETrmvZ8my5+WZfeaZset1ci0DrkkPFEuTwZgEUQRKES1IJlJJmOAkUAq08nmRQx3B6RRmQRrrqzzZE0vgpEv8CmSDRXgdsREbOA9bp+EyRzn8vh31nDNnufrx2Bt8ppj0z/R6iUnO6dCLmq73tBiO7VM3edjceHftp/5cT7xJwx3bL5PkLht6T8z97rRG/SW76Q1WT1hs6H1tudsrLO4+h80/4yhzzr7j4VHTMTl8kg2mJnfy446Nnr82XG/Zcp+drfscf6ZxOBv1o78fZ5H92IRN/zy5GcO39erx/Pq2dS/Os5PFt/Z5b9sbC79y4XOfrwNJ1gw2ILFNDptSLvqY+yy/EuV2T3AdMA7Sr1QLXB6n8KKBT60SVDgLo9n3WAzYhlpBpIUcshfGq/sztQmCxkPLSioCDnQlWcI0W4OiwXRq+ZwckjqqDNr6aeKEpDL+Qt5GeA8K5xsBnUmRXJkJO1Pr7FOj8alRrRWIJHhhSZoMIREye1DBHL6Qk4adX3nKa9UvyRorRqIhUtUyBXTmtkoT9Nholq1QCcE0u8UzmQKDonoB3JqlPNJm16wqKfmWHW+FSDxhlXBzGimvXUWlsxiO53IowdiEdyIYznmJIzCNgxBiD8dEuiZYJsM6iNNAY9dv9GYQ6FTCnmXepJZukBgKZZTOQWOLK5A6sz5wjH3YEZeACXwHyZ2vPn/NX4p7JyXjGiQywLJmOKVloUDdS7Jvh82IlYvc7ZJTu/oWICSKIZB73K7cm4KvuxfEf/x4cVgxPCr07iRqh3r/hUNlfH7LdLS4D/gcLJvaNXJi03ZtL3UoUm6yxqsFoEYSIakiv5MGbbeq79CCWMH/ScP+Dx5mp38LL4rJoL+GQtt29WBkxW2+BtxngQstN7jdB0sNUgq51zQSXAmzdWJeRoo9MI9KrdLJd/LSuP5gyUpIbb5di9K6hmQV40KqephGS+wlUsqAOvUdpDNla8Km3Xf+SLgP+CPHyCyN4zHbgl+57NQx/wgWi1zC0RpkHGSYYmh0Fo3LmyJAKe3U0TSH/hurhYjDQB7U/QU


run Devin via cli

Describe your question
in the previous release, one can invoke Devin
PYTHONPATH=`pwd` python opendevin/main.py -i 500 -f ${taskfile}

don't see doc mentioning how to run Devin via cli for 0.6.1.
Additional context

You can still do that, just main.py is now in opendevin.core. If you wish, you can use -c for the agent of your choice. Also you can use -l parameter to load a pre-configured llm, e.g. add in config.toml separately from the rest:
[claude]
model="claude-3-opus-20240229"
api_key="sk-something"

[gpt-35]
model="gpt-3.5-turbo"
api_key="sk-something-else"
...

and use it like python opendevin/core/main.py -i 500 -f ${taskfile} -l claude
I'm not sure what happened to its doc, but we should document it. Probably this is a good place https://github.com/OpenDevin/OpenDevin/blob/main/Development.md

What r available agents? Any doc when a particular agent should be used?Sent from my iPhoneOn Jun 5, 2024, at 4:40 PM, Engel Nyst @.***> wrote:
You can still do that, just main.py is now in opendevin.core. If you wish, you can use -c for the agent of your choice. Also you can use -l parameter to load a pre-configured llm, e.g. add in config.toml separately from the rest:
[claude]
model="claude-3-opus-20240229"
api_key="sk-something"
[gpt-35]
model="gpt-3.5-turbo"
api_key="sk-something-else"
...
and use it like python opendevin/core/main.py -i 500 -f ${taskfile} -l claude
I'm not sure what happened to its doc, but we should document it. Probably this is a good place https://github.com/OpenDevin/OpenDevin/blob/main/Development.md
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

The agents are here:
https://github.com/OpenDevin/OpenDevin/tree/main/agenthub
There is a README on the folder, though I don't think it answers your question, it's more geared for agent research and development, which is their purpose.
The best suggestion I can give is actually to use CodeAct unless you have a reason to use another. CodeAct, SWE-CodeAct and Monologue are generic agents, with the other two older and not as good. Others are in development, micro-agents or delegates are experimental and might be used by other agents as necessary (by CodeAct perhaps, in the future). Browsing agent is fine, but as the name says, it's specialized and its main use will probably be via another, for browsing tasks.

We recommand to use poetry to run the opendevin. Using cli run it may cause lots of dependency and environment problem.


Registry Preview crashed after clicking "Open file..."

Microsoft PowerToys version
0.69.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Registry Preview
Steps to reproduce
Open "Registry Preview"
Click "Open files..." at the menu bar.
✔ Expected Behavior
I should get the dialog window to select a file
❌ Actual Behavior
Registry Preview window disappeared or crashed.
Other Software
No response

I just upgraded PowerToys and tried the new Registry Preview, and it crashes when you click Open File...

If you opened the app from the elevated PowerToys launcher/settings page, this is a known issue we're tracking, #25250

@randyrants
Yes the user opened elevated.
Issue description:

Running as admin
Yes

/dup #25250


Typo: "UVG "

In appendix A, the language tag for Uyghur should be 'UYG ', not 'UVG '.

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

ID: 2296e659-a278-4505-3dbe-54e2f8e51a54
Version Independent ID: 5af9216e-b435-4a4c-3c5a-94756409f8f5
Content: Developing OpenType Fonts for Arabic Script - Typography
Content Source: typographydocs/script-development/arabic.md
Product: windows
GitHub Login: @mijacobs
Microsoft Alias: mijacobs

Fixed


C code in Graham Scan chapter is not highlighted

https://www.algorithm-archive.org/chapters/algorithms/graham_scan/graham_scan.html
code function ccw() is highlighted, following snippet and whole code is not :(

Ups... dup of #96
closing...


Add .nojekyll to docs root

So when publishing to github pages it won't process the project as a Jekyll project
See: https://help.github.com/articles/files-that-start-with-an-underscore-are-missing/

Fixed in #488


OODT-945 Rework OODT configuration to make use of Zookeeper for distributed configuration management (GSoC 2017)

This PR includes the Distributed Configuration Management implementation for OODT [OODT-945] along with the distributed configuration publishing CLI [OODT-952].
Explanation on the design of this feature is available at Rework OODT configuration to make use of Zookeeper for distributed configuration management.
User documentation on how to use this distributed configuration management feature is available at OODT Distributed Configuration Management
Corresponding GSoC project proposal is available at https://cwiki.apache.org/confluence/display/OODT/Proposal
Since this is the first glance of the distributed configuration management feature, there can be bugs and improvements required to be addressed. Please review this PR and provide me with your kind feedback so that I can improve on that.
Thank you!

please see my review comments above - great start!

@IMS94

hi @IMS94 I have errors building this locally can you check:
LMC-053601:oodt mattmann$ mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'parent.relativePath' of POM org.apache.oodt:oodt-conf:[unknown-version] (/Users/mattmann/git/oodt/config/pom.xml) points at org.apache.oodt:oodt-core instead of org.apache.oodt:oodt, please verify your project structure @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 5, column 13
[ERROR] 'dependencies.dependency.version' for org.apache.curator:curator-framework:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 19, column 21
[ERROR] 'dependencies.dependency.version' for args4j:args4j:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 39, column 21
[ERROR] 'dependencies.dependency.version' for org.apache.curator:curator-test:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 55, column 21
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project org.apache.oodt:oodt-conf:1.1-SNAPSHOT (/Users/mattmann/git/oodt/config/pom.xml) has 3 errors
[ERROR]     'dependencies.dependency.version' for org.apache.curator:curator-framework:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 19, column 21
[ERROR]     'dependencies.dependency.version' for args4j:args4j:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 39, column 21
[ERROR]     'dependencies.dependency.version' for org.apache.curator:curator-test:jar is missing. @ org.apache.oodt:oodt-conf:[unknown-version], /Users/mattmann/git/oodt/config/pom.xml, line 55, column 21
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

Hi @chrismattmann, can you check now? I had put wrong parent artifactId name in config/pom.xml earlier. It should build now.

hi @IMS94 got further, but failing on unit tests, thoughts?
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.apache.oodt.config.distributed.DistributedConfigurationManagerTest
log4j:WARN No appenders could be found for logger (org.apache.zookeeper.server.quorum.QuorumPeerConfig).
log4j:WARN Please initialize the log4j system properly.
Starting configuration publishing

Processing commands for component : FILE_MANAGER
Publishing configuration for : FILE_MANAGER
Published configuration for : FILE_MANAGER

Processing commands for component : RESOURCE_MANAGER
Publishing configuration for : RESOURCE_MANAGER
Published configuration for : RESOURCE_MANAGER

Starting configuration publishing

Processing commands for component : FILE_MANAGER
Clearing configuration for : FILE_MANAGER
Cleared configuration for : FILE_MANAGER

Processing commands for component : RESOURCE_MANAGER
Clearing configuration for : RESOURCE_MANAGER
Cleared configuration for : RESOURCE_MANAGER

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.209 sec <<< FAILURE! - in org.apache.oodt.config.distributed.DistributedConfigurationManagerTest
loadConfigurationTest(org.apache.oodt.config.distributed.DistributedConfigurationManagerTest)  Time elapsed: 0.049 sec  <<< FAILURE!
java.lang.AssertionError: null
	at org.junit.Assert.fail(Assert.java:86)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertTrue(Assert.java:52)
	at org.apache.oodt.config.distributed.DistributedConfigurationManagerTest.loadConfigurationTest(DistributedConfigurationManagerTest.java:91)

Running org.apache.oodt.config.distributed.DistributedConfigurationPublisherTest
Starting configuration publishing

Processing commands for component : FILE_MANAGER
Publishing configuration for : FILE_MANAGER
Published configuration for : FILE_MANAGER

Verifying configuration for : FILE_MANAGER
OK... Configuration verified
Verified configuration for : FILE_MANAGER

Processing commands for component : RESOURCE_MANAGER
Publishing configuration for : RESOURCE_MANAGER
Published configuration for : RESOURCE_MANAGER

Verifying configuration for : RESOURCE_MANAGER
OK... Configuration verified
Verified configuration for : RESOURCE_MANAGER

Starting configuration publishing

Processing commands for component : FILE_MANAGER
Clearing configuration for : FILE_MANAGER
Cleared configuration for : FILE_MANAGER

Processing commands for component : RESOURCE_MANAGER
Clearing configuration for : RESOURCE_MANAGER
Cleared configuration for : RESOURCE_MANAGER

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.512 sec - in org.apache.oodt.config.distributed.DistributedConfigurationPublisherTest

Results :

Failed tests:
  DistributedConfigurationManagerTest.loadConfigurationTest:91 null

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] OODT Core .......................................... SUCCESS [  1.820 s]
[INFO] Common Utilities ................................... SUCCESS [ 17.797 s]
[INFO] CAS Command Line Interface ......................... SUCCESS [  6.046 s]
[INFO] OODT - Configuration Management .................... FAILURE [  5.426 s]
[INFO] Process Control System Input Data Package .......... SKIPPED
[INFO] Catalog and Archive Service Generic Multi-valued Metadata Container SKIPPED
[INFO] CAS Protocol ....................................... SKIPPED
[INFO] CAS Protocol FTP Implementation .................... SKIPPED
[INFO] CAS Protocol HTTP Implementation ................... SKIPPED
[INFO] CAS Protocol IMAPS Implementation .................. SKIPPED
[INFO] CAS Protocol SFTP Implementation ................... SKIPPED
[INFO] Query Expression ................................... SKIPPED
[INFO] OODT Single Sign On Security Package ............... SKIPPED
[INFO] Catalog and Archive File Management Component ...... SKIPPED
[INFO] OODT CAS Virtual Catalog and Integration Service. .. SKIPPED
[INFO] Catalog and Archive Resource Management Component .. SKIPPED
[INFO] Catalog and Archive Workflow Management Component .. SKIPPED
[INFO] Catalog and Archive Crawling Framework ............. SKIPPED
[INFO] CAS Curation Web Services .......................... SKIPPED
[INFO] Process Control System Core Package ................ SKIPPED
[INFO] OODT Wicket Web Components ......................... SKIPPED
[INFO] CAS Curation Interface ............................. SKIPPED
[INFO] CAS PGE Adaptor Framework .......................... SKIPPED
[INFO] CAS Installer Maven Mojo ........................... SKIPPED
[INFO] OODT :: Archetypes :: OpsUI ........................ SKIPPED
[INFO] OODT :: Archetypes :: RADiX ........................ SKIPPED
[INFO] OODT :: Archetypes ................................. SKIPPED
[INFO] CAS Push-Pull-Framework ............................ SKIPPED
[INFO] Product Service .................................... SKIPPED
[INFO] Profile Service .................................... SKIPPED
[INFO] OODT Web Grid ...................................... SKIPPED
[INFO] XML-configured, DBMS-based Product and Profile Server SKIPPED
[INFO] Apache OODT Configurable OPeNDAP Profile Server .... SKIPPED
[INFO] CAS File Manager Browser Web App ................... SKIPPED
[INFO] CAS Product Server Web Application ................. SKIPPED
[INFO] CAS Workflow Manager Monitor Web App ............... SKIPPED
[INFO] Catalog and Archive File Management Browser ........ SKIPPED
[INFO] Catalog and Archive Workflow Management GUI Editor . SKIPPED
[INFO] Process Control System Operator Interface Webapp ... SKIPPED
[INFO] OODT Process Control System JAX-RS service layer ... SKIPPED
[INFO] Apache OODT ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 31.600 s
[INFO] Finished at: 2017-07-13T15:38:14-07:00
[INFO] Final Memory: 53M/480M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project oodt-conf: There are test failures.
[ERROR]
[ERROR] Please refer to /Users/mattmann/git/oodt/config/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :oodt-conf
LMC-053601:oodt mattmann$

Hi @chrismattmann, Can let me know do you have any of previously set up FILEMGR_HOME or RESMGR_HOME environment variables available in your system?

hi @IMS94 do I need to set those env vars? This will screw up tests since they should not have environment variable requirements, or if so, should be mock'ed in the tests themselves.

So I checked, and I do have those environment variables set, except for RESMGR_HOME e.g.,
LMC-053601:oodt mattmann$ echo $FILEMGR_HOME
/usr/local/bigtranslate/filemgr
LMC-053601:oodt mattmann$ echo $FILEMGR_URL
http://localhost:9000
LMC-053601:oodt mattmann$
LMC-053601:oodt mattmann$ echo $RESMGR_URL
http://localhost:9002
LMC-053601:oodt mattmann$

I was thinking about your code - is it that if an environment variable from local config isn't that set - you are publishing a null value to ZK or there is a getPropertyOrNull call somewhere that is causing this? If so, we should probably have a sensibleDefaults() configuration which are all the sensible defaults in case the environment is Null. Even better would be to use PathUtils in o.a.cas.metadata.util to do EnvVarOrMetadata replacement on all paths you read from config.

Hi @chrismattmann, No. Tests do not require any environment variable to be set. But if any of the above mentioned env variables are set, that could be a possible reason for your test failure (because I didn't encounter test failures). I'm using environment variables to determine each OODT component's HOME when downloading and storing configuration files from zookeeper.
Therefore, what I wanted know was whether you have any of those env vars set.

Hi @chrismattmann, Thanks for the update. That is the reason for the test failure. Actually this is a case I should have addressed within my code. I have wrote the fix. Will push it now.

@IMS94 feel free to request an invite to uscdatascience.slack.com I'll make a channel for slack chat if you want real time comm on this

OK @IMS94 I have invited you to the USC Data Science slack

Hi @chrismattmann, Thanks for the invitation.
I have pushed an update. There's still a chance for the tests to fail because I store configuration files in ${COMPONENT_HOME} directory if ${COMPONENT_HOME} is present, else in the working directory. If it fails again, I will find a more convenient method for my implementation.

merged this thanks @IMS94
LMC-053601:oodt mattmann$ git push -u origin feature/zookeeper-config
Counting objects: 475, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (203/203), done.
Writing objects: 100% (475/475), 81.85 KiB | 0 bytes/s, done.
Total 475 (delta 155), reused 355 (delta 113)
remote: oodt git commit: Update log4j config.
remote: oodt git commit: Merge branch 'feature/zookeeper-config' of https://github.com/IMS94/oodt into feature/zookeeper-config
remote: oodt git commit: assert not null.
remote: oodt git commit: Fix for empty component home variable
remote: oodt git commit: Merge and apply robust changes for stack trace print in tests.
remote: oodt git commit: Merge branch 'feature/zookeeper-config' of https://github.com/IMS94/oodt into feature/zookeeper-config
remote: oodt git commit: fix for presence of component home environment variables in tests
remote: oodt git commit: Merge branch 'feature/zookeeper-config' of https://github.com/IMS94/oodt into feature/zookeeper-config
remote: oodt git commit: fix pom.xml
remote: oodt git commit: Fixed parent artifactId in config/pom.xml
remote: oodt git commit: Removed * imports. Improved code formatting and refactored code.
remote: oodt git commit: Merge branch 'master' of https://github.com/apache/oodt into feature/zookeeper-config
remote: oodt git commit: Update README.md
remote: oodt git commit: Merge branch 'OODT-847' of http://github.com/adhulipa/oodt
remote: oodt git commit: Record change for OODT-847.
remote: oodt git commit: Merge branch 'master' into feature/zookeeper-config
remote: oodt git commit: Improvements to file downloading from zookeeper and tests
remote: oodt git commit: Minor improvements for configuration manager tests
remote: oodt git commit: Created test cases for distributed configuration manager and publisher
remote: oodt git commit: Added zip packaging for distributed configuration publisher
remote: oodt git commit: Implemented configuration fetching for DistributedConfigurationManager
remote: oodt git commit: Altered configuration publishing mechanism to use spring configuration
remote: oodt git commit: Implemented global configuration publishing mechanism.
remote: oodt git commit: Defined initial API for ConfigurationManager
remote: oodt git commit: Fix for OODT-847 contributed by adhulipa & rverma
To https://git-wip-us.apache.org/repos/asf/oodt.git
   ec5b201..3fb7660  feature/zookeeper-config -> feature/zookeeper-config
Branch feature/zookeeper-config set up to track remote branch feature/zookeeper-config from origin.
LMC-053601:oodt mattmann$

@chrismattmann Thanks for your support too. Did the tests pass for you without a problem?

they did pass once I disabled tesseract


Fix/update challenges for sass portuguese

[X] I have read freeCodeCamp's contribution guidelines.
[X] My pull request has a descriptive title (not a vague title like Update index.md)
[X] My pull request targets the master branch of freeCodeCamp.
[X] None of my changes are plagiarized from another source without proper attribution.
[X] All the files I changed are in the same world language (for Portuguese)
[X] My changes do not use shortened URLs or affiliate links.

Closes #34743 (Language: Portuguese)
Associated with #35031

@thefrontendwizard @jefferson2z Since you guys have reviewed other PRs related to Portuguese translation, I just wanted to check if you have time to look at this PR. Thank you in advance!

@thefrontendwizard @jefferson2z Since you guys have reviewed other PRs related to Portuguese translation, I just wanted to check if you have time to look at this PR. Thank you in advance!

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


Add KUBERNETES_NAMESPACE variable to Pod containers

If you want to make a REST calls from containers running in Pod to KUBERNETES_SERVICE, it would be handy to have the namespace that container is launched in available inside the container.

cc @derekwaynecarr

We want to support passing this information to containers, but not by exposing Kubernetes-specific environment variables.
This is essentially the same issue as #386, #560, parts of #1768, https://github.com/GoogleCloudPlatform/kubernetes/issues/2316#issuecomment-86202868, and #5093. The most concrete discussion was in #2316, but the most appropriate issue to use is #386.

@mfojtik I have a WIP that will encompass this; will tag you once it's PR'd

@pmorie cc me as well.  I agree we need this information.

@mfojtik Looks like #6739 will be merged; I think this can be closed.


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-30-main" workflow

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

Questions ?
Please refer to the Backport tool documentation


javaTpoint js tutorial is added

close issue #1329

Changes proposed

Screenshots

Note to reviewers

@CBID2 have a look!!!!!!!!!!!!

@CBID2 now check issue is resolved

@CBID2 please merge this PR and give level label.

@CBID2 please merge this PR and give level label.

Two approvals are required for merging. Please be patient

okay for sure.


DON'T MERGE - Change app artifact to move instead of link

This is a first step towards change in installation behavior mentioned in #13201.
I had to skip the two_apps_correct tests because I don't know the desired functionality (e.g. should we copy the source to both targets and delete the source?)

Any news on this?

I'm waiting for feedback from @jawshooah to make sure this is the correct approach.

@mwean Just to check, do you still intend on working on this?

@vitorgalvao Yeah I'd definitely like to. I just moved, but I'll try to take a look this weekend.

@vitorgalvao I rebased against master and made a couple more updates. I'm not sure what else needs to be done, and I don't know what the correct behavior should be for the two-app tests. I could maybe copy to both locations and delete the original? I'm not sure what the use case for that is. Let me know what you think.

I agree that the two-app tests seem useless; at least, I've never seen it.
@jawshooah if you want to take a look at the PR when you're free?

Will take another look at this tonight.

I found one issue with this pull request, but unsure how to correctly correct it. If an app, Atom for example, has a binary that needs to be symlinked to /usr/local/bin, it complains that the symlink source isn't there. The workaround I've used is:
sed -i -e<EMAIL_ADDRESS>/usr/local/Library/Taps/caskroom/homebrew-cask/lib/hbc/artifact/symlinked.rb
but that breaks installs for fonts (at least). I'm not sure what the correct solution is, but figured I'd add that bit.

@ptb are you saying that it tries to symlink the binary before it moves the app?

No it tries to symlink after moving, but it is expects that it still lives at the staged location (Caskroom).
brew cask install atom --force
==> Satisfying dependencies
complete
==> Downloading https://github.com/atom/atom/releases/download/v1.4.3/atom-mac.zip
######################################################################## 100.0%
==> Verifying checksum for Cask atom
==> Moving App 'Atom.app' to '/Users/admin/Applications/Atom.app'
Error: It seems the symlink source is not there: '/opt/homebrew-cask/Caskroom/atom/1.4.3/Atom.app/Contents/Resources/app/apm/node_modules/.bin/apm'

It had occurred to me recently this might be an issue. Basically this only happens if the binary to be linked is inside the app.
The solution would be to instead of having (to borrow atom as the example)
binary 'Atom.app/Contents/Resources/app/apm/node_modules/.bin/apm', target: 'apm'

have
binary "#{Hbc.appdir}/#{app[0]}/Contents/Resources/app/apm/node_modules/.bin/apm", target: 'apm'

Though that particular solution doesn’t work. All that’s needed is to add a new app_location (or something) special variable that we can grab in these cases, to just grab the install location.

@ptb @vitorgalvao I made a failing spec for the embedded binary case, but I'm not sure how to proceed. I'm a little concerned putting interpolations into the path declaration like @vitorgalvao suggested because it would require Cask authors to know more about the cask inner workings. I wonder if we could match the beginning of the binary path against the app path (the "Atom.app" part in this example):
app 'Atom.app'
binary 'Atom.app/Contents/Resources/app/atom.sh', target: 'atom'

If there's a match, we'd know to look in the appdir. It would be a little ugly because we'd have to look at the app's artifacts from the symlink class, but it wouldn't require any change to the dsl. What do you think?

I feel like you’re trying to make the feature smart, and smart is what got us in this mess in the first place are we’re trying to avoid.
It is not a huge user-facing change. I’d much rather have it be explicit, even if it means contributors need to know something new and working, than having something smart that later on we find breaks on some cases.
It’s better to have it be dumb and make it smarter later, than the reverse.

@mwean
it would require Cask authors to know more about the cask inner workings

I tend to agree with @vitorgalvao in that cask authors should be expected to know more about the cask inner workings.  It should be simple and dumb and easy for end users to use and not get into trouble...but  (IMO), it's OK to expect cask authors to need to know what they are doing.
It should be generally easy to create a cask...but it doesn't hurt to know the inner workings a bit in order to create one.

Ok, that sounds good. What about having tokens instead of direct interpolation (like they do in Paperclip)? Something like
binary ":install_location/:app/Contents/Resources/app/apm/node_modules/.bin/apm"

Tokens seem clunky, to me. We use interpolation for some things, and symbols for others. They are well define and predictable. Mixing here seems inappropriate.
Also, we really need a way to specify the index of what we mean. Some apps have multiple app stanzas, so we need to specify the one we’re pointing to. Something like binary "#{app_install_location}/#{app[0]}/…" seems acceptable, to me. We need to specify it’s the install location reserved for apps, in case we later need to do it for other artifacts.

Ok, I actually wasn't clear what app[0] was referring to in your earlier comment. Could we do something more explicit like app_specifications[0].name? Something shorter would be better but I can't think of anything right now.

Could we do something more explicit like app_specifications[0].name?

Not sure I get why. It seems more confusing to me. app[0] would reduce complexity, as we’re talking about the literal value of the app stanza. To clarify, let’s use a made up cask:
app 'One.app'
app 'Two.app'
binary 'Two.app/Contents/Resources/app/script'

In this case, we’d use
app 'One.app'
app 'Two.app'
binary "#{app_install_location}/#{app[1]}/Contents/Resources/app/script'"

I also wouldn’t oppose to just appdir instead of app_install_location.
To note that I’m not opposing app_specifications[0].name, I just don’t (yet?) see how it’s clearer than app[0], seeing as it directly refers to the actual stanza.

When I saw app[0], I wasn't thinking of having multiple apps, I was thinking of args to the app method or something, since we destructure the args elsewhere (e.g. source_string, target_hash = artifact_spec). At any rate, if we're saying app is the collection of app stanzas, then why would app[0] necessarily return the app name? I'm totally fine either way, just want to make sure it's clear as possible.

Right. From a user/contributor-facing view, I was thinking of app as “a string that indicates what will be acted upon”.
Lets look at it another way, though. What would be easiest/would make more sense for you to implement?

I'll try to spike on it a bit tonight and let you know.

Sounds good. Thank you.

Ok, I added the appdir method to the DSL for interpolation. I decided to leave out the app[0] part because current casks (e.g. Atom) are already duplicating the app ("Atom.app") part, and it's much simpler to just continue with that. @ptb, this should now work with the embedded binaries. Let me know what you think.

current casks (e.g. Atom) are already duplicating the app ("Atom.app") part, and it's much simpler to just continue with that.

Fair enough.

@ptb, this should now work with the embedded binaries.

But you’ll still need to update the casks by hand first, to try it out.
@caskroom/maintainers We should test this for a bit and see if we find any issue while using.

What's the best way to test locally?

@vitorgalvao should I work on a script or something to update all the existing casks with apps and binaries? That seems like it would take some work.

Best way to test locally:
git clone https://github.com/mwean/homebrew-cask.git # clone @mwean’s repo with this change
./homebrew-cask/developer/bin/develop_brew_cask # make his repo the main one to use

As develop_brew_cask warns, do not run brew update while in this mode. To get back to regular usage, run production_brew_cask in that same directory.
@mwean Just tested on a clean VM, and noted something. This is still using ~/Applications by default. With this change, /Applications should be the default. With that, only point 5 of the “The end of linking, and the beginning of moving (technical)” section in #13201 will remain of the first part of this change.
As for the script, you may work on it if you want, but if not, I’d be happy to do it. It’s likely many of the casks will have to be manually altered anyway, and that’s a boring job that I’m prepared to do.

Note that, if you already have a local clone of the repo, you can do the following from its root:
brew install hub
hub checkout https://github.com/caskroom/homebrew-cask/pull/13966
./developer/bin/develop_brew_cask

@vitorgalvao this only handles app stanzas now. Should I switch all the other artifacts (except binary) to use move?
I'll update the default appdir.
I'll try looking at writing a migration script this weekend, but feel free to tackle it if you have time before then.

Should I switch all the other artifacts (except binary) to use move?

Yes, might as well switch them all from the start.

I forgot that I skipped the two-app specs because I didn't know how to handle that case. We could copy the app and then do some sort of cleanup at the end of the cask installation or something. I don't really understand the use-case anyway.

@vitorgalvao Something we've found useful for testing relatively invasive changes like this is guarding the new behaviour behind an environment variable (e.g. CASK_MOVE_APPS), disabling it by default and then allowing people to enable it gradually. That also means you can merge PRs before needing to ship it to people so review becomes easier.

I ❤  this PR and the way it is implemented!
@mwean How are we going to handle brew cask install --force?
With plain brew cask install, I still see the warning:

Add the "--force" option to force re-install.

… which sets up my expectation that adding --force would trash and replace the existing app (if and only if the app is managed by brew-cask).
What I’m observing instead is that brew cask install --force now refuses to overwrite the existing app. I suggest this to be changed to avoid confusion and to give the --force option a chance to continue making sense.
Any thoughts?

@claui that's a good point. I was also thinking about that when I was looking at the specs that prevent clobbering existing artifacts. I was thinking that when we handle updates, it would be hard to be sure that we're overwriting the app that we installed and not one the user subsequently installed manually. Personally, I'd be happy to have it always overwrite, but a maintainer should weigh in on the desired behavior.

Agreed with the always overwrite - it shouldn't matter where the app came from, as desired user behavior should result in the latest (version in Cask) should be installed....
but in fact, this is where auto_updates true will be of use, as maybe that should be the only reason to not overwrite the existing app (if I'm remembering the original proposal correctly). We can handle misbehaving/auto-updating Casks on a manual basis after the initial merge, as adding that line isn't particularly onerous (and even probably scriptable, to be honest)

@mwean The use case is we have some casks that really do have two app stanzas. Some packages really consist of multiple app bundles.
Regarding auto_updates, the rule is: when we have upgrade functionality, every installed cask that has auto_updates (even if the cask was updated) will be ignored by us (and we’ll let the app take care of the update).
As for overwriting, I think it’s good we do not overwrite by default, but do overwrite when using --force. The reason is simple: it’s not at all uncommon for different casks to have artifacts with the same name (see all eclipse casks). Overwriting those by default could be a nasty surprise.
@MikeMcQuaid That is a great idea, and we should adopt that as well. For this particular case, however, I’m fine with letting the breaking change come in. Reason being we’re so low on core developers, this important feature is being contributed by someone outside the main team, and I really do not want to take @mwean’s time more than necessary. We’ve also warned everyone things would break and the response has been quite positive (people really want this new behaviour), so I’m fine with it.

The use case is we have some casks that really do have two app stanzas. Some packages really consist of multiple app bundles.

That makes sense, but the spec is specifically for the same app going to two different locations:
# test/support/Casks/with-two-apps-correct.rb
app 'Caffeine.app'
app 'Caffeine.app', target: 'AnotherName.app'

Having two app stanzas is fine, as long as they don't use the same source. Do you still want to support the use case in this spec?

As for overwriting, I think it’s good we do not overwrite by default, but do overwrite when using --force.

Sounds good. This should work correctly with @claui's branch.

@mwean I have checked every cask with two or more app stanzas:
grep -c '^\s*app\s' Casks/*.rb | ruby -ne 'puts $1 if ~/(.*):[^01]/' | xargs mate

and found that the scenario from the spec never comes up even once. I would suggest that that particular spec be abandoned because it has no redeeming value.

This should work correctly with @claui's branch.

Speaking of working correctly, I’ve been bitten earlier today with one more issue: brew cask install lingo --force finds an existing target, tries to trash it but fails because I happen not to be the owner.
Why not? Turns out I had bought the same app from the MAS years ago but forgot about it. Today I had my head in the clouds as always so I ran install lingo --force on my branch. The conflicting Lingo.app, being a MAS app, belonged to root so it didn’t budge. I feel it’s pretty safe to assume that in general, end users will not remember whether their app came from the MAS or HBC.
So I’m left wondering what HBC should do in that case?

Leave the artifact staged and display the Not moved message?

Go sudo, asking the user for the password?
Give up and ask the user to manually resolve the conflict?

@mwean @vitorgalvao Any thoughts as to what would be the most reasonable course of action here?

@mwean Yes, the way that spec is presented is a bit weird. There are indeed some casks with more than one app, but no, never the same, as @claui pointed out.
All that said, I agree with your previous comment, lets leave out the whole app[0] nonsense. It works well as is.
@claui Your second scenario seems the most reasonable. If we’re saying --force, then forceful it should be, consequences be damned (presumably, the user understands that force is the “do whatever it takes to make this work” option).
That said, I have no strong commitment to that behaviour. If anyone thinks one of the others should be the case and makes a good case for it, I’m fine either way.

Great, I'll update the 2-app specs and merge in @claui's branch.

@vitorgalvao @claui: Ok, I fixed the 2-app spec, updated all the binary stanzas, and merged in @claui's branch. I'm not sure what the failure is on Travis, but I think we might be good to go with this!

@mwean Ignore the Travis error - it's been nearly impossible to pin down, but it's in no way indicative of an actual failure/error in the PR.
Will let one of the other maintainers have a look, but LGTM.
Easiest way to "migrate" might just be to get a list of all casks, uninstall them and wipe out /Caskroom and associated symlinks, and then reinstall after this change is merged, but open to better methods - I wouldn't be opposed to tagging a new release as well, just as a symbolic measure.

i would prefer moving apps out of /Caskroom is better than reinstalling app (maybe someone dont like a new version installed)

@adidalal Are you thinking of a scripted migration? Would such a migration be optional or rather mandatory?

No opinion either way - with such a large change, there probably isn't a "best" way to proceed, but open to ideas for how to make it a not-terrible experience. If it's getting off-topic here, this discussion can be moved to a new issue, but it's one that should happen before this change is merged and made final

@muescha @claui @adidalal No migration. That’s the point made at the end of https://github.com/caskroom/homebrew-cask/issues/13201.

Doesn’t this mean a bunch of stuff might break?

(…) transition strategies is an inglorious job (everything will be discarded in the end, after all) that puts on hold even the smallest of changes indefinitely. It is incredibly time consuming, has variable results (we still get a bunch of issues pertaining to it), and (above all) kills momentum. Furthermore, this is a big change and there’s really no good way to make this seamlessly.

If anyone wants to devise a transition strategy, that is fine. We’d need commitment to that, however, meaning the transitioner will be responsible for implementation, bugs pertaining to it, and removing the code in a few months when everyone is presumably transitioned.
#13201 made clear from the start we’re willing to break things with this change. All things considered, it’s not even a huge break, your old installs won’t stop working. I’ll greatly advise anyone against a transition strategy for this. Even brew cask list is broken and we don’t keep track of installed casks correctly. There’s no way you’ll write a good transition when everything else is falling around you and you can’t be sure you can lean on other parts of the codebase.
Lets leave it be. Accept the breakage as we already knew it would happen, and move on.
Leaving this open for a few more days for disagreements, but I’ll say I’m excited to have this merged in. Not everything in #13201 is present, but the most important bits are, and it’s another step to the finally right direction.

I believe the changes to all of the casks to make "#{appdir}" work correctly will need to be enclosed in double quotes, otherwise these are the types of errors that will be produced:
Error: It seems the symlink source is not there: '/usr/local/Caskroom/atom/1.7.3/#{appdir}/Atom.app/Contents/Resources/app/apm/node_modules/.bin/apm

Great catch @ptb, I'll get that fixed

Ok, should be fixed now

The casks that specify a target for the binary didn't get changed (e.g. Atom, Github Desktop, others).
(And I'll say thank you now, for all of your work on this!)

Ah, gotta fix my regex...

Ok, let's try that again

Need to change dest_path to Hbc.appdir here as well.

I'm trying to reproduce the failure on CI, but I'm getting Hbc::CaskError: Uh oh, could not figure out how to unpack '/var/folders/81/krskm0797s78hqmfdx7v4_k40000gn/T/homebrew_tests20160527-29970-m1ln87/cache/stuffit-container-1.2.3.sit'. Could someone help me with this?

@mwean Do you have unar installed?
Separate but related issue: that test uses a test cask containing an artifact stanza with no target, which should never happen. Will fix in a bit.

Haha I was reading that as unrar... Problem solved.
@jawshooah I added target: sheldonmac/v1 and it's working now, thanks!

@mwean There are some conflicts now that #21549 has been merged in. Resolve those and push, and I'll be glad to merge this once Travis goes green.

@caskroom/maintainers

@jawshooah I think you're good to go!

Yay!!! What a fantastic day for Homebrew Cask! <3

So what's the next step @vitorgalvao??

Next steps:

Get rid of versioned subdirectories in the Caskroom. The .metadata directory will still need to exist (although its innards won’t have the versioned app directory either) since it will be useful to save a snapshot of the installed cask to handle updates/uninstalls at a future time.
Implement :required_location (apps that will benefit from it at the start are mentioned in #12858).

And with it, --force-appdir (these two really go hand in hand).

And that is actually way less of #13201 left than I realised!
We still have a lot to do after that, but closing #13201 will be a huge milestone (this merged pull request already is!), and it makes me really glad to see the project completing this step, one further in the right direction.
Thank you greatly, @mwean, @claui, @jawshooah, and many others (too many to mention all without missing some and making this sound like an award ceremonies speech) for all the work.

@muescha I think there was a bad rebase that reverted my doc changes. I'll make a new PR to fix them

Fixing issues caught by @muescha in https://github.com/caskroom/homebrew-cask/pull/21597.

I just have to say, it might be completely in my head (or due to the fact that I uninstalled/reinstalled all my casks to get the "move" behavior), but my applications seem to launch a LOT faster and spotlight seems to be a LOT more responsive  since this change has been implemented.  Nice work!!!


/home/ubuntu/catkin_ws/src/realsense/realsense_camera/src/base_nodelet.cpp:244:23: error: 'rs_get_device_info' was not declared in this scope
&rs_error);
^
/home/ubuntu/catkin_ws/src/realsense/realsense_camera/src/base_nodelet.cpp:249:43: error: 'RS_CAPABILITIES_MOTION_EVENTS' was not declared in this scope
if (rs_supports(rs_detected_device, RS_CAPABILITIES_MOTION_EVENTS, &rs_error))
^
/home/ubuntu/catkin_ws/src/realsense/realsense_camera/src/base_nodelet.cpp:249:84: error: 'rs_supports' was not declared in this scope
if (rs_supports(rs_detected_device, RS_CAPABILITIES_MOTION_EVENTS, &rs_error))
^
/home/ubuntu/catkin_ws/src/realsense/realsense_camera/src/base_nodelet.cpp:251:80: error: 'RS_CAMERA_INFO_MOTION_MODULE_FIRMWARE_VERSION' was not declared in this scope
const char * motion_module_fw = rs_get_device_info(rs_detected_device, RS_CAMERA_INFO_MOTION_MODULE_FIRMWARE_VERSION,
^
/home/ubuntu/catkin_ws/src/realsense/realsense_camera/src/base_nodelet.cpp:252:23: error: 'rs_get_device_info' was not declared in this scope
&rs_error);
^
make[2]: *** [realsense/realsense_camera/CMakeFiles/realsense_camera_nodelet.dir/src/base_nodelet.cpp.o] Error 1
make[1]: *** [realsense/realsense_camera/CMakeFiles/realsense_camera_nodelet.dir/all] Error 2
make: *** [all] Error 2
Invoking "make -j1 -l1" failed
Is there a chance I'm getting this similar error because all the installs are all muddled together? Is there an easy way to wipe out any trace of *realsense and start over? I'm not having this problem at all with kinetic, but I am having in here. If you're convinced it's an install issue then I'll grind on that until I can come up with new information.

@mdhorn I appreciate your patience during all of this. I decided this was likely a user error so I doubled down to track it down. Here's the documentation for anyone else who find themselves here (note, this is dodcument elsewhere on github but through human error I didn't get it correctly):
librealsense at version 1.4.0 is what was missing. I was able to track down my current version with
$ git describe --tags
1.5.0

Here's what needs to be done from the ground up. Works on both Ubuntu 14.04 amd64 and armhf
$ cd ~/github # where I keep my standalone github checkouts
$ git clone https://github.com/IntelRealSense/librealsense
$ cd librealsense
$ git checkout -b b1.4.0 1.4.0 # what I was missing before. git checkout -b [local branch name] [repo branch name]
$ mkdir build
$ cmake .. -DBUILD_EXAMPLES=on
$ make && sudo make install

$ cd ~/catkin_ws/src/ # where I keep my ros github checkouts
$ git clone https://github.com/intel-ros/realsense
$ cd realsense
$ git checkout -b b0.9.2 v0.9.2
$ cd ~/catkin_ws
$ catkin_make

@jacksonkr
Glad you got it resolved. Did you ever try just using the prebuilt ROS Debian packages under ARM? I know they work for Indigo for X86
sudo apt-get install ros-indigo-realsense-camera
FYI: I made an update to your previous comment. You had the tag swapped; v0.9.2 is for librealsense, and 1.4.0 is for realsense camera.
Also BUILD_EXAMPLES cmake flag for librealsense was not added until version 1.11.0 so it has no impact on the v0.9.2 release.
Cheers.

@mdhorn Good eye on the version numbers.
I'm trying to install again with only the apt-get binary but I'm running into trouble. see #139.

I switched to a different machine which is 4.4.0-46-generic kernel so I could try with only debian packages.
After completely removing EVERY trace of realsense (sudo find / -name *realsense* then manual remove of each listing) I retried my realsense-dependent app installation (rtabmap) with strictly the debian packages (ros-indigo-librealsense, ros-indigo-realsense-camera).

I did a cmake .. for my realsense-dependent app and realsense support was not enabled.
$ sudo apt-get install ros-indigo-librealsense
cmake .. shows librealsense support
make works as expected for realsense-dependent app

$ rtabmap
rtabmap: error while loading shared libraries: librealsense.so: cannot open shared object file: No such file or directory

I ran sudo apt-get install ros-indigo-realsense-camera and then recompiled my realsense-dependent app (removed all build files then cmake .. && make && make install)
Same error when running rtabmap so I ran
$ sudo find / -name librealsense*
/opt/ros/indigo/include/librealsense
/opt/ros/indigo/share/librealsense
/opt/ros/indigo/share/librealsense/cmake/librealsenseConfig.cmake
/opt/ros/indigo/share/librealsense/cmake/librealsenseConfig-version.cmake
/opt/ros/indigo/lib/pkgconfig/librealsense.pc
/opt/ros/indigo/lib/librealsense_camera_nodelet.so
/opt/ros/indigo/lib/x86_64-linux-gnu/librealsense.so

And you can see that the librealsense.so is in an obscure location so to test this out, I ran the following:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/ros/indigo/lib/x86_64-linux-gnu/
And then rtabmap could find librealsense.so.
As far as I can tell, this issue falls on librealsense because the librealsense.so is not in a generic enough location. What do you think?

@jacksonkr You should not be setting your LD_LIBRARY_PATH variable to include ROS, that is the job of the ROS setup.bash script.
Installing ROS is not enough, you need to source the ROS environment to use it:
http://wiki.ros.org/indigo/Installation/Ubuntu#indigo.2BAC8-Installation.2BAC8-DebEnvironment.Environment_setup
If you are install ros-indigo-librealsense and ros-indigo-realsense-camera, I'm not sure what you are attempting to build with 'cmake'?

@mdhorn
I always keep two ros sourcings in my ~/.bashrc:
source /opt/ros/[distrobution]/setup.bash
source ~/catkin_ws/devel/setup.bash

Note that this issue started out with me making both librealsense v0.9.2 and realsense 1.4.0 manually. During the length of this issue I moved to the debian packages per your suggestion, which is where the LD_LIBRARY_PATH portion comes in, because the path was not including the librealsense.so from the debian packages.
So the fact that my LD_LIBRARY_PATH was not set correctly for this build, is that a mistep of ROS? Do I need to move this issue there?

I would verify that the location where the librealsense.so is installed under /opt is also in your LD_LIBRARY_PATH; if not, re-source the setup.bash.
For example I checked and initially the location was missing:
$ find /opt -name \*librealsense\* -print
/opt/ros/kinetic/share/librealsense
/opt/ros/kinetic/share/librealsense/cmake/librealsenseConfig-version.cmake
/opt/ros/kinetic/share/librealsense/cmake/librealsenseConfig.cmake
/opt/ros/kinetic/lib/pkgconfig/librealsense.pc
/opt/ros/kinetic/lib/librealsense_camera_nodelet.so
/opt/ros/kinetic/lib/x86_64-linux-gnu/librealsense.so
/opt/ros/kinetic/include/librealsense

$ echo $LD_LIBRARY_PATH
/home/mhorn/ROS/devel/lib:/opt/ros/kinetic/lib:/usr/local/lib

Notice that the location of the librealsense is NOT in my LD_LIBRARY_PATH. I believe this is because I installed the package after I had source the /opt/ros/kinetic/setup.bash.
Re-sourcing the setup.bash fixes the problem:
$ source /opt/ros/kinetic/setup.bash
$ echo $LD_LIBRARY_PATH
/opt/ros/kinetic/lib:/opt/ros/kinetic/lib/x86_64-linux-gnu:/usr/local/lib

Even if I source my development area afterwards, the correct path is maintained:
$ source ~/ROS/devel/setup.bash
$ echo $LD_LIBRARY_PATH
/home/mhorn/ROS/devel/lib:/opt/ros/kinetic/lib:/opt/ros/kinetic/lib/x86_64-linux-gnu:/usr/local/lib

Hmm, I know that sourcing and resourcing the setup can resolve issues so I'll have to take your word for it since I'm beyond that point. If I run into this again I'll check back with the results.
Thanks @mdhorn


Maximum Public IP's per NIC

"There is a limit to how many private IP addresses can be assigned to a NIC. There is also a limit to how many public IP addresses that can be used in an Azure subscription. See the Azure limits article for details."
I cannot find details for the limit on Public IP's per NIC. Azure Limits does not have the information.

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

ID: 2a5293db-b062-ee9e-9d17-9db4ded5cfae
Version Independent ID: 938fc48b-fb70-9717-a731-79278553eed6
Content: Multiple IP addresses for Azure virtual machines - PowerShell
Content Source: articles/virtual-network/virtual-network-multiple-ip-addresses-powershell.md
Service: virtual-network
GitHub Login: @jimdial
Microsoft Alias: jdial;annahar

@gcormier From the Azure Network Limits, The limit of Private IP Addresses per NIC is 256.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

Thanks - should have been clear, the documentation didn't provide that information. A link to the Azure Network Limits in the quoted section would be useful to find that information.


Doesn't seem to run (Bootstrap failed: 5: Input/output error)

When I run:
sudo brew services start zouxian
I get this error:
Warning: Taking root:admin ownership of some zouxian paths:
/opt/homebrew/Cellar/zouxian/0.2.0/bin
/opt/homebrew/Cellar/zouxian/0.2.0/bin/zouxian
/opt/homebrew/opt/zouxian
/opt/homebrew/opt/zouxian/bin
/opt/homebrew/var/homebrew/linked/zouxian
This will require manual removal of these paths using sudo rm on
brew upgrade/reinstall/uninstall.
Bootstrap failed: 5: Input/output error
Error: Failure while executing; /bin/launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.zouxian.plist exited with 5.
Does anyone know how to resolve this error?

I rarely use Mac afterwards, so I have hardly paid attention to this project. Sorry for the long wait.
Check the repo homepage for the latest available method. If it doesn't work for you, please let me know.


AudioFile.Skip works only below ~2hours

To set position, I do
      au.Seek(0, IO.SeekOrigin.Begin)
      au.Skip(playerPos)

but when playerPos is larger than certain amount of seconds, the Skip method fails, leaving au position at the beginning.
A workaround is to divide playerPos and then skip multiple times.
Tested with .AAC and .3gp files, both of length > 8hrs

Setting the au.CurrentTime works just fine though :)


Make a small Hinglish Sentiment Adapter on SBERT

Deciding to use BERT-Base or other base transformers already available on the Hub instead of Sentence-BERT/Sentence-Transformers
See this issue for more info at the Adapter-Transformers repo
https://github.com/Adapter-Hub/adapter-transformers/issues/73

Awaiting tests from @meghanabhange


After Update to 1.1: Struct within Struct throws Uncaught TypeError: Cannot read property 'config' of undefined

This is a quite urgent problem since it breaks nearly all of our currently set up projects.
Abstract
Schemas using StructEditors inside other StructEditors as part of an Array inside Content Base Schemas are causing problems (I know, that's Levellevellayer-Inception-talk, but bear with me).
Reproduction
Using Hashbrown latest stable (v 1.1).
Set up the following schemas (names don't matter, I just use them in this way for better understanding):
Simple Component (as child of "Struct" Field Base)
use the following config:
    "config": {
        "struct": {
            "my_field": {
                "label": "My field",
                "schemaId": "struct",
                "config": {
                    "struct": {}
                }
            }
        }
    }

Simple Base (as child of Content Base)
with the following fields
    "fields": {
        "properties": {
            "components": {
                "label": "Components",
                "schemaId": "array",
                "tabId": "meta",
                "config": {
                    "allowedSchemas": [INSERT_SIMPLE_COMPONENT_ID]
                }
            }
        }
    }

Create a content (from here on called "Simple Content") with the Simple Base Schema and try to insert a new Component in the respective section.
What should happen
Our Simple Component should be added nicely to the array of components and we should be able to edit it's contents (though in this example there is none) as well as adding further components.
What is happening currently
We are getting an modal with an error "Uncought TypeError: Cannot read property 'config' of undefined". Component is not added, content did not change.

Other observations
We have a lot of projects which use that [Array in Content Base] > [Component Struct]  > [Fields within Component also using Structs] architecture and so we encountered this error first when we were trying to access our content after the Update to Hashbrown Version 1.1. We get the same error when the Editor tries to render all Inputs and after confirmation of the modal we are thrown to the json view of the content.

At some point I also got a browser console error which might help to follow the trail to the origin of the error.

Suspicion
The only line in the code where we are thrown to the json-view after an error is found in ContentEditor.js Line 556. Thus I suspect some part of the then-block of the HashBrown.Helpers.SchemaHelper.getSchemaWithParentFields-promise not to work correctly. Inside the same file there are multiple accesses to a config-property of fieldDefinition which is a part of the schema returned by the same promise.
Could it be that fieldDefinition is somehow not defined due to getSchemaWithParentFields not returning a usable answer?
Other effects
This issue also applies when Simple Component is not using a StructEditor itself but its parent does. E.g. "Simple Component Parent" would use a StructEditor for defining its input, "Simple Component Child" would not => using "Simple Component Child" as only allowed Schema on "Simple Base" > Components results in the same error when trying to add it.

@milesleif I'm on it

@milesleif can you test with the latest master? I've tested against the setup you described and can't reproduce the error anymore.
The error seems to be that the StructEditor was passing a part of the configuration to each field as a schema rather that the FieldSchema it was supposed to consume, but only if the struct was not inherited yet. A rather particular scenario I haven't bumped into before now

@mrzapp thank you very much. The bug seems to be gone, our arraystructstructs are working again. :)
We noticed you also commited it to the stable branch, I assume a new version/tag (patch level) would be a good idea?

@milesleif Yep, just about to bump the version number now


Fail v1.1.1 RUN pip install -r requirements.txt PyYAML~=5.4.1 Deprecated config in setup.cfg

Describe the bug
Step fail when starting running pip install.

Fixed in: https://github.com/saadmk11/changelog-ci/pull/100

@saadmk11 can we get a release that includes this bugfix?

@saadmk11 can we get a release that includes this bugfix?

I am planning on releasing the changes this weekend.

Released v1.1.2. The issue should be fixed now. Feel free to re-open the issue if the problem still exists.


is there out of box feature available to show audio languages in shaka player

is there out of box feature available to show audio languages in shaka player
Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
4.3.5
Please ask your question
Currently I am using audio version of Shaka Player and my manifest have difference audio languages:
Is there any out of box feature/setting available in shaka player to show the audio language list?
Currently I am able to see 2 options(Playback Speed and Captions)
below is the link of test url.
https://app-mediuspublic-prod-westus2-dev.azurewebsites.net/Content/html/Test2.html

Shaka Player is only able to show Audio Languages, If the manifest specifies it. And your manifest does (refer Image)

In your case, You are showing the Native Audio Element which doesn't have option to display the tracks. You would need to setup custom UI and call player.getAudioLanguages() to be able to show the languages.


chore: update build cache

Current Insiders still ships a broken version of the vscode-encrypt native module for macOS arm64,
% nm -g /Applications/Visual\ Studio\ Code\ -\ Insiders.app/Contents/Resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node | grep _openssl_fopen

From local build of latest vscode-encrypt
% nm -g ./build/Release/vscode-encrypt-native.node | grep _openssl_fopen
00000000000dc740 T _openssl_fopen

Very likely module cache was not updated properly in https://github.com/microsoft/vscode/pull/154356 which had .cachesalt conflicts from https://github.com/microsoft/vscode/pull/154334

Build for verification: https://monacotools.visualstudio.com/Monaco/_build/results?buildId=177589&view=results

Openssl is built for the wrong architecture in CI due to cross compilation
Configuring OpenSSL version 1.1.1n (0x101010efL) for darwin64-x86_64-cc

Verified with


Is this project still alive?

Are you interested in updating it to OL 5?
If not I won't send in pull requests.
You say you want help but you don't give out contact information in either place, so I am opening an issue.

Check package.json for the author's email address.


withAvatarConfig has issue with next/link

It's OK when it's standing alone, but when I wrap it inside a <Link />, it's showing a warning about refs.

Hi @ducdev,
Looks like the fix in https://github.com/zeit/next.js/issues/10305#issuecomment-579287598 might need to be applied to react-avatar as well.
I'll give it a try later and report back.

Hi @ducdev,
I've just published version v3.9.5 which includes the forwardRef fix when supported by the version of React in use.
It fixes the error on the demo page, could you let me know whether this solves the issue for you as well?

Hi, it works like a charm! Good job!