Add overlap warnings when strict is False

Currently there is not a way to see all erroneous intervals in a TextGrid, even when strict is set to False. Here, if strict = False, the mark and start/end times of an interval will be printed, allowing a user to collect all problematic instances without crashing on the first case.

What would you say to turning these into log statements (at WARNING or lower level) instead? I don't think debugging information ought to be printed to stdout unless the user has agreed to it.

Agreed - that makes a lot more sense. Converted them to warnings (as debug isn't output by default in logging).

This is better, thanks! Sorry, I have one last request. Can you convert these to use logging-style string formatting instead of .format? For instance:
logging.warning("Overlap for interval %s: (%f, %f)", self.mark, self.minTime, self.maxTime)

Or something like that.
The reason for this is that Python logging is smart and won't actually do the (surprisingly expensive) string interpolation if logging at that level isn't requested. Whereas .format runs at run-time regardless of log-level. (The alternative to this is f-strings, which are parsed at compile-time, but those have not been and will not be backported to Python 2.)

Done!


Feature Request: Get address transactions via Electrum (electrs)

Implement a provider for AddressTransactions which requests the data from a local/trusted Electrum server (for example electrs). This helps with #4.

With 5d289d9739add635b0c9d3ec67c638ad1fdfbbc4 one can get the script (as hex string) for a Base58 P2PKH or P2SH address. Bech32 addresses are not supported, yet.


Udpate action and tests

@soumeh01, this action has moved to its official location at https://github.com/ARM-software/cmsis-actions


Update fixable list

This should really be ALL, or code-generated, but I just want to fix this real-quick.

@charliermarsh Thanks! Looking at it now, C is still listed (as it is probably a substitute for C4 from what I've gathered from the previous conversation), as is COM.

C does match C4 and C9. It's admittedly confusing, but because those two categories both have a C prefix, they're both matched by C. This is different from COM, though.

Oh, I see. It's one of those things that only become intuitive after someone explains them. Hopefully this PR fixes the logic, making this discussion redundant 🙏 . Thanks!


Hamburger unable to get multiple Primary Buttons

<Controls:HamburgerButtonInfo ClearHistory="True" PageType="views:MainPage">

</Controls:HamburgerButtonInfo>
<Controls:HamburgerButtonInfo ClearHistory="True" >

</Controls:HamburgerButtonInfo>

Hi Sir,
I am adding multiple primary buttons but its giving exception on run.

If you are not going to tell me the exception, I am not sure how I can help you. You had might as well just say "It don't work!". I see that your second button does not have a page type. Clicking on that to navigate might be the error you are receiving. Again, I am just guessing here.

I have resolved it, The problem was with if we use bitmapicon with URISource for multiple  primary button it gives exception and close the application . SO I used the Image control instead of BitMapicon. and its resolved


Add script to compile the contract

It still doesn't compile properly:
./compile.sh
npm WARN saveError ENOENT: no such file or directory, open '/home/anatoli/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/anatoli/package.json'
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN anatoli No description
npm WARN anatoli No repository field.
npm WARN anatoli No README data
npm WARN anatoli No license field.

+<EMAIL_ADDRESS>updated 1 package and audited 1436 packages in 3.195s
found 2 low severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details
Error: Could not find openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol from any sources; imported from /home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol
    at /home/anatoli/node_modules/truffle/build/webpack:/packages/truffle-resolver/index.js:76:1
    at /home/anatoli/node_modules/truffle/build/webpack:/~/async/internal/onlyOnce.js:12:1
    at next (/home/anatoli/node_modules/truffle/build/webpack:/~/async/whilst.js:68:1)
    at /home/anatoli/node_modules/truffle/build/webpack:/packages/truffle-resolver/index.js:64:1
    at /home/anatoli/node_modules/truffle/build/webpack:/packages/truffle-resolver/fs.js:85:1
    at /home/anatoli/node_modules/truffle/build/webpack:/~/async/internal/once.js:12:1
    at replenish (/home/anatoli/node_modules/truffle/build/webpack:/~/async/internal/eachOfLimit.js:61:1)
    at iterateeCallback (/home/anatoli/node_modules/truffle/build/webpack:/~/async/internal/eachOfLimit.js:50:1)
    at /home/anatoli/node_modules/truffle/build/webpack:/~/async/internal/onlyOnce.js:12:1
    at ReadFileContext.callback (/home/anatoli/node_modules/truffle/build/webpack:/packages/truffle-resolver/fs.js:81:1)

Committed as https://github.com/DoggyWalkie/eth-contract/commit/8db60185812d6990e3c5829ec1f596d59fb7ee29

./compile.sh
+<EMAIL_ADDRESS>added 90 packages from 332 contributors and audited 142 packages in 3.67s
found 0 vulnerabilities

Compiling ./contracts/DoggyWalkie.sol...
Compiling ./contracts/Migrations.sol...
Compiling openzeppelin-solidity/contracts/access/Roles.sol...
Compiling openzeppelin-solidity/contracts/access/roles/MinterRole.sol...
Compiling openzeppelin-solidity/contracts/introspection/ERC165.sol...
Compiling openzeppelin-solidity/contracts/introspection/IERC165.sol...
Compiling openzeppelin-solidity/contracts/math/SafeMath.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/ERC721.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/ERC721Enumerable.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/ERC721Metadata.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/ERC721Mintable.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/IERC721.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/IERC721Enumerable.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/IERC721Metadata.sol...
Compiling openzeppelin-solidity/contracts/token/ERC721/IERC721Receiver.sol...
Compiling openzeppelin-solidity/contracts/utils/Address.sol...

Compilation warnings encountered:

/home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol:50:5: Warning: No visibility specified. Defaulting to "public".
    function addToHold(uint256 tokenId, address from ,uint256 price){
    ^ (Relevant source part starts here and spans across multiple lines).
,/home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol:57:5: Warning: No visibility specified. Defaulting to "public".
    function confirmJob(uint256 tokenId){
    ^ (Relevant source part starts here and spans across multiple lines).
,/home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol:67:5: Warning: No visibility specified. Defaulting to "public".
    function onHold(uint256 tokenId) returns(bool){
    ^ (Relevant source part starts here and spans across multiple lines).
,/home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol:24:5: Warning: Function state mutability can be restricted to pure
    function finishMinting()
    ^ (Relevant source part starts here and spans across multiple lines).
,/home/anatoli/a/walkie-contract/contracts/DoggyWalkie.sol:67:5: Warning: Function state mutability can be restricted to view
    function onHold(uint256 tokenId) returns(bool){
    ^ (Relevant source part starts here and spans across multiple lines).

Writing artifacts to ./build/contracts


fix: do not inject global variable into module wrapper

Summary
It's not part of the module wrapper, so we shouldn't inject it: https://nodejs.org/api/modules.html#modules_the_module_wrapper
Fixes #10565.
EDIT: Huh, seems like this blows up for tests I didn't bother to run locally. Specifically, it explodes for tests using global in JSDOM. I'm thinking we can just add it to the JSDOM env and remove in a future version. Might be considered a breaking change, though?

Test plan
Test added

extraGlobals should probably also be proper globals, put not for this PR I guess

That defeats (half) the purpose of it (https://github.com/facebook/jest/issues/5163#issuecomment-355509597, specifically the part about 50% speedup)


Error Crashed

I tried to make 100000 requests call to WebApi that has been registered in Consul cluster for 2 instances that running in the same local machine. The server return successful response but suddenly in the middle of the request I received Error Crashed exception "Unable to connect to remote server"

It seems like the Consul agent for some reason wasn't able to process the request for service status.
That is the only place that logs an exception with the text "crashed" (Logger.Error(x, "Crashed");)
This in itself is not critical as this only delays the removal of any potentially dead services.
Is the problem reproducible or was it a one time event?

It's not one time event, happen when reached  > 30K call requests.
I have changed the client code to make a direct call  to the WebAPI for a testing and has no problem at all.

Here is the detail execption message
"An operation on a socket could not be performed because the system lack sufficient buffer space or because a queue was full"

http://stackoverflow.com/questions/4415175/an-operation-on-a-socket-could-not-be-performed-because-the-system-lacked-suffi
Seems like a resource leak in the ConsulRestClient. the HttpClient needs proper disposing.

I have change the code in ConsulRestClient
try
{
using (HttpClient client = new HttpClient())
{
var response = await client.GetAsync(string.Format("http://localhost:{0}/v1/health/state/critical", consulPort)).ConfigureAwait(true);
....
}
catch{...}

This have been resolved earlier, closing


Docker build logs new lines

This change is

Codecov Report

Merging #272 into master will decrease coverage by 0.11%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master     #272      +/-   ##
============================================
- Coverage     19.19%   19.08%   -0.12%
  Complexity      248      248
============================================
  Files            74       74
  Lines          3079     3113      +34
  Branches        295      300       +5
============================================
+ Hits            591      594       +3
- Misses         2427     2458      +31
  Partials         61       61

Impacted Files
Coverage Δ
Complexity Δ

...ha/yad/steps/DockerBuildImageStepFileCallable.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...kostyasha/yad/launcher/DockerComputerLauncher.java
23.52% <0%> (-6.48%)
2% <0%> (ø)

...ain/java/com/github/kostyasha/yad/DockerCloud.java
11% <0%> (-0.23%)
9% <0%> (ø)

...tyasha/yad/launcher/DockerComputerSSHLauncher.java
5.61% <0%> (+1.07%)
1% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf89724...7c808b2. Read the comment docs.


Adding backstick rule

What's done:

Prohibited backsticks for non-test methods
Tests
Updating codestyle

Related issue is #105


Changes to get working with nutch 2.2.1 and firefox v 24

It would be ideal to put this on a nutch-2.2.1 branch

Please refer to latest implements: https://github.com/xautlx/nutch-ajax


ENV_ROUTE clarification

@steff456 , I don't mean to bombard you with issues on this plugin, but I have some questions about the terminal setup.
What is the intention of the terminal plugin? Is is supposed to emulate an interactive login shell?
The reason I ask is that the ENV_ROUTE for bash and zsh may need some adjustment.

For bash, I'm not aware of any circumstance in which both ~/.bashrc and ~/.bash_profile are sourced. The expected source files are:

Interactive login: first /etc/profile then the first available of ~/.bash_profile, ~/.bash_login, or ~/.profile
Interactive non-login: first /etc/bashrc then ~/.bashrc

For zsh, all files are sourced, in order, if they exist:

Interactive login: /etc/zshenv, $ZDOTDIR/.zshenv, /etc/zprofile, $ZDOTDIR/.zprofile, /etc/zshrc, $ZDOTDIR/.zshrc, /etc/zlogin, and $ZDOTDIR/.zlogin
Interactive non-login: /etc/zshenv, $ZDOTDIR/.zshenv, /etc/zshrc, $ZDOTDIR/.zshrc

Additionally, do you know where environment variables are passed to new terminals? Maybe it's somewhere in terminado? For the macOS standalone application, some environment variables need to be removed, e.g. PYTHONHOME and RESOURCEPATH.

Hi @mrclary, don't worry about opening issues!
The main idea behind this plugin is to have a console inside Spyder that works as close to a system terminal as possible. This is the reason why we decided to try to import all the configurations that may be modified by the user, specially to have all the conda paths available inside the terminal.
Maybe this can help, https://github.com/spyder-ide/spyder-terminal/blob/45b2a3ca1ebe7aad5fe2d18536199dfb57d43264/spyder_terminal/server/logic/term_manager.py#L55


dev.boringcrypto branch behind the main releases (1.13.4b4 vs 1.13.6)

The latest release for dev.boringcrypto is 1.13.4b4, the latest official release is 1.13.6.
Most of the dev.boringcrypto releases happened fairly promptly after the official releases in 2019, is the plan moving forward to keep releaseing the dev.boringcrypto branches?
Pretty much what are the plans with dev.boringcrypto for 2020?

Ping. GoLang 1.13.7 was release a few days ago with 2 security fixes and unfortunately the dev.boringcrypto is still inactive since November 25 2019.
https://go.googlesource.com/go/+/dev.boringcrypto/misc/boring/RELEASES
https://go.googlesource.com/go/+/dev.boringcrypto
If this branch is being officially abandoned that would a be a big disappointment but knowing so would let us proactively plan to switch to an alternative solution for our needs.

@solul Thanks for the ping. There are plans to update these branches and make a BoringCrypto release, it just hasn't been done yet.
Let's wait to hear from @FiloSottile and @katiehockman.

I see that go1.13.7b4 is available. Thank you @FiloSottile and @dmitshur this is very much appreciated!

Sorry for the delay!


If auto geolocation is used, then when applying filter and searching, location is set to default

This is because clicking search button passes the empty search string, which then makes application revert to default location (City Hall)

Fixed


[4.0.0-beta.19] Page with tabs opened from tab destroying outlet

Bug Report
Ionic version:
4.0.0-beta.19
Current behavior:
I have a tab based app.
Inside it I open, upon clicking a button, another page that contains tabs. Everything works fine before I open it, and inside that page it works fine. The problem is when I navigate from that page back to the main app, navigation in the app stops working. In console: router-outlet destroyed
Expected behavior:
Navigation should not stop working
Steps to reproduce:
See behavior and code
Related code:
Main tabs:
<ion-tabs #tabs>
  <ion-tab-bar slot="bottom" color="secondary" selected-tab="home">
    <ion-tab-button tab="home">
      <ion-icon name="home"></ion-icon>
      <ion-label>home</ion-label>
    </ion-tab-button>
    <ion-tab-button tab="search">
      <ion-icon name="search"></ion-icon>
      <ion-label>search</ion-label>
    </ion-tab-button>
    <ion-tab-button tab="library" >
      <ion-icon src="/assets/ic_books.svg"></ion-icon>
      <ion-label>library</ion-label>
    </ion-tab-button>
  </ion-tab-bar>
</ion-tabs>

Page with tabs:
  <ion-tabs>
    <ion-tab-bar slot="top" color="primary">
      <ion-tab-button tab="tab1">
        <ion-label>tab1</ion-label>
      </ion-tab-button>
      <ion-tab-button tab="tab2">
        <ion-label>tab2</ion-label>
      </ion-tab-button>
    </ion-tab-bar>
</ion-tabs>

Routers:
const routes: Routes = [
  {
    path: 'tabs',
    component: TabsPage,
    children: [
      {
        path: 'home',
        children: [
          {
            path: '',
            loadChildren: '../home/home.module#HomePageModule'
          },
        ]
      },
      {
        path: 'library',
        children: [
          {
            path: '',
            loadChildren: '../library/library.module#LibraryPageModule'
          },
        ]

      },
  {
    path: '',
    redirectTo: '/tabs/home',
    pathMatch: 'full'
  },
  {
    //This is the page with the tabs:
    path: 'kitzur',
    component: KitzurSubjectsPage,
    children: [
      {
        path: ':chelek',
        children: [
          {
            path: '',
            loadChildren: '../kitzur/kitzur-tab/kitzur-tab.module#KitzurTabPageModule'
          }
        ]
      },
      {
        path: '',
        redirectTo: '/kitzur/Chol',
        pathMatch: 'full',
      },
    ]
  },
];

Other information:

Ionic info:

insert the output from ionic info here

Thanks for your issue! I believe you have the same issue described here -> #16411 (see the gif if this is the same problem for you). There I have a workaround to make it work -> https://github.com/ionic-team/ionic/issues/16411#issuecomment-443186868

@paulstelzer I'm not sure if it's the same issue. I tried removing   <ion-router-outlet></ion-router-outlet> from app.component.html, but now everything is blank... Did I misunderstand the workaround?

Same issue is if you cannot switch the pages anymore. Tapping on the link the page stays the same. If you have this issue, then it's the same.

@paulstelzer I tried what you did, and in app.component.html instead of:
<ion-app>
  <ion-router-outlet></ion-router-outlet>
</ion-app>

I put:
<router-outlet></router-outlet>

It indeed solves the problem.

Is this OK and won't result in performance issues? Should I use ion-router-outlet?
Why isn't this a bug? I think there should be some official guidance when people try similar navigation.

@amitairos of course it's a bug :D it's the reason why I opened #16411 . This is just a workaround until the bug is fixed
btw, router-outlet is from Angular and is not using the stack functionality. So in performance it's better than the Ionic outlet

@paulstelzer I see. Thanks. Then why not use router-outlet always?

It's depend on you. ion-router-outlet brings you the stack functionality and animations between page transitions ;)


Does not work when new image is added in the html after calling baguetteBox.run()

I am trying to use the library, and it works great, when I initialize 2 images in the dom, then run the baguetteBox. Then I try to add another new image in the dom, but this time, it doesn't work, even if I call baguetteBox.run() again, after the creation of the new image, inside setTimeInterval().

baguetteBox does not work with dynamically added images. It caches the gallery on run and works on that data even when re-run.  I'm facing the same problem.


Train on CamVid

Do you use this codes with CamVid? There are some bugs.

Your labels do not range from 0 to num_classes.

/home/ydhong/.conda/envs/detectron/lib/python3.6/site-packages/torch/optim/lr_scheduler.py:100: UserWarning: Detected call of lr_scheduler.step() before optimizer.step(). In PyTorch 1.1.0 and later, you should call them in the opposite order: optimizer.step() before lr_scheduler.step().  Failure to do this will result in PyTorch skipping the first value of the learning rate schedule.See more details at https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate
"https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate", UserWarning)
/opt/conda/conda-bld/pytorch_1573049301898/work/aten/src/THCUNN/SpatialClassNLLCriterion.cu:104: void cunn_SpatialClassNLLCriterion_updateOutput_kernel(T *, T *, T *, long *, T *, int, int, int, int, int, long) [with T = float, AccumT = float]: block: [32,0,0], thread: [544,0,0] Assertion t >= 0 && t < n_classes failed.
Traceback (most recent call last):
File "train.py", line 317, in
train_model(args)
File "train.py", line 220, in train_model
lossTr, lr = train(args, trainLoader, model, criteria, optimizer, epoch)
File "train.py", line 87, in train
loss.backward()
File "/home/ydhong/.conda/envs/detectron/lib/python3.6/site-packages/torch/tensor.py", line 166, in backward
torch.autograd.backward(self, gradient, retain_graph, create_graph)
File "/home/ydhong/.conda/envs/detectron/lib/python3.6/site-packages/torch/autograd/init.py", line 99, in backward
allow_unreachable=True)  # allow_unreachable flag
RuntimeError: cuDNN error: CUDNN_STATUS_NOT_INITIALIZED


Principals can be up to 29 bytes long

A colleague (David de Kloet) found an issue with ICRC1 transfers.
The transfer doesn't work if the destination principal isn't 29 bytes long.
He points to this line in the code.
Yet, principals can be up to 29 bytes long. See the docs on Principal.
I confirmed the issue.
I created two test vectors. One with the destination that isn't working, and one with a destination where the transfer succeeded.
The principal that wasn't working is "ttwhn-ittl6-fnuml-tqdgz-tbyhu-f7jti-ft2cr-znzsu-biv4l-gpvg4-ba". I also marked the test vector with isWorking to differentiate them.
Could you please fix it? Thanks!
icrc-1-issue.json.txt

The non-working example is 28 bytes. But principals can be much shorter than that. Even "aaaaa-aa" is a valid principal.


parse-render loop creates newline

MWE:
import mistletoe
from mistletoe.markdown_renderer import MarkdownRenderer

print(repr(MarkdownRenderer().render(mistletoe.Document("a"))))

Output:
'a\n'

Expected output:
'a'

Hi @nschloe, the behavior you describe seems to be intentional, or say "by-design" to me. It is the Document class constructor which adds new newline (\n) if it is missing in the input:
class Document(BlockToken):
    """
    Document token.
    This is a container block token. Its children are block tokens - container or leaf ones.

    Attributes:
        footnotes (dictionary): link reference definitions.
    """

    def __init__(self, lines):
        if isinstance(lines, str):
            lines = lines.splitlines(keepends=True)
        lines = [line if line.endswith('\n') else '{}\n'.format(line) for line in lines]
        # ...

I'm not sure if this should be / can be safely changed. So closing for now, but feel free to reopen this issue if needed.

Not sure why you put in this workaround. The only situation I could imagine where it does anything is to append a missing terminal "\n" and to add "\n" where "\r" is a line break. Don't know why you'd want either of those.
I'd always expect a parse-render loop to stay as faithful to the input as possible, unless it's illegal input; error out then. What's your take on this?

Yeah, I'm not sure either why this was introduced by the original author 5 years ago. As you write, this could possibly deserve some investigation, so I'm reopening this...


refactor: rm imagenormalizer as all features are in core

nearl all features are in core and more efficiently  implemented there https://docs.jina.ai/datatype/image/

It will still be on hub @hanxiao

why?

I mean it will still be published and available here https://hub.jina.ai/executor/dzrova7k


tables don't obey $hr-width

How can we reproduce this bug?
Set $hr-width to something smaller than $global-width; say, 200px.
What did you expect to happen?
The
 table should be the width specified, and centered
What happened instead?
The
 table is the full width of the <container>.
The interim
 code I'm using:

<h-line> element should be used here.


[Feature request] add flowchart and mermaid support the default theme.

Feature request
add flowchart and mermaid support the default theme.
Description
It is useful to add support for flowchart and mermaid support the default theme.
Proposed Solution
I notice there are plugin already, just do not know how to integrate it, and I think it is possible as theme-hope has that.

This is not your personal theme and most people won't need this.
Stop posting any feature unless we are all no doubt that >80% people will be interested in it.
Also, VuePress plugin system is designed to let users use their own features according to their needs.


errors in d3dx12.h

Hey I am using your engine as a basis of learning. I am currently writing mine and getting a lot of useful information from the core. but I can't get it to run. I keep getting errors that are pointing to d3dx12. most errors point out that identifiers are undeclared

Hi.
Is this on a fresh pull from Master branch (with miniengine building against 17763 SDK)?

Yes, is it possible to retarget to 17134 because I dont have the newer version at the moment and our internet is locally bad to download anything thanks

Hi
You can find a 17134 compatible version in the 17134 release:
https://github.com/Microsoft/DirectX-Graphics-Samples/releases/tag/v10.0.17134.0.2.

Thank you for the time. Will try it out


Docker to Singularity for HPC and permissions

Hi, I am using a Linux HPC system to use msconvert to convert .WIFF files to .mzML. We can only use Singularity on HPC, and do not have root access. I am using the docker container provided by pwiz and converted it to singularity, however I get the issue described here: https://stackoverflow.com/questions/73328706/running-singularity-container-without-root-as-different-user-inside
Is there an alternate workaround that does not involve rebuilding the container for every user? We would like to include this as part of a nextflow workflow, and this issue really limits its ease of portability. Thanks!

Ive struggled with this in the past... what I found works for me is ...
documented here:
https://github.com/jspaezp/elfragmentador-data#setting-up-msconvert-on-singularity-

Hi, I am using it in a script through
for FILE in "${FILES[@]}" ; do
  TMPMYWINEPREFIX=`mktemp -d /dev/shm/wineXXX`
  singularity exec \
    --cleanenv \
    -B "$OUTDIR":/data \
    -B $TMPMYWINEPREFIX:/mywineprefix \
    --writable-tmpfs \
    "$IMAGE" \
    mywine msconvert \
    --32 --zlib --filter "peakPicking true 1-" --filter "zeroSamples removeExtra" \
    --outdir  z:/data/mzML \
    "z:/data/$FILE"
   sleep 2 ; rmdir $TMPMYWINEPREFIX
done

So the temporary directory for the wine stuff is created as a user, and then mounting that directory into the container. I haven't tested recently, but this could get you on track.
Yours,
Steffen

Hi @tracychew! I have the exact same issue here. We also want to integrate this docker container in our nextflow pipeline and run it on an HPC. Any progress on this?
I would be super grateful for a smooth solution


[Feature] Thala For a Reason Calculator

Description
Hi, I'd like to create a calculator where the user will enter a 6 digit number, and after performing some calculations they will get the answer "7", please assign it to me under JWOC'24
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[ ] I am a IWOC'24 contributor.
[X] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @rishicds


SPARK-4921. TaskSetManager.dequeueTask returns PROCESS_LOCAL for NO_PREF ...

...tasks

@sryza any progress investigating this? FYI those NO_PREF tasks can be returned when the locality level is "any" and "rack_local" too. See TaskLocality.scala. If you don't show a concrete benefit from this, I'd suggest closing the issue and not changing it. The way I see it, this could break the scheduling order in existing jobs, with minimal benefit in performance (just avoiding one small delay for datasets that include both combined and non-combined files).

My conclusion (sorry if it was unclear above) was that dequeueTask returning NO_PREF instead of PROCESS_LOCAL should have no effect at all.  I still think it's worth changing for clarity, but it's obviously less important.
In what cases would dequeueTask return NO_PREF tasks when maxLocality=RACK_LOCAL or ANY?  My understanding is that, in a single resourceOffers call, dequeueTask gets called multiple times in order of TaskLocality, so any NO_PREF tasks would be returned when it's called with maxLocality=NO_PREF.  And none would remain when ANY and RACK_LOCAL come around.

I'm going to close this as "Won't Fix" as this has been open for a long time, touches sensitive code, and is mainly a code cleanup issue.

@sryza, could you reopen this one?
TaskInfo will be sent to SparkListener. Without this patch, for NO_PREF RDDs, their taskLocalitys in TaskInfo will be PROCESS_LOCAL, and the user can see it in SparkListener. Test codes:
    import org.apache.spark.scheduler.{SparkListenerTaskStart, SparkListener}
    sc.addSparkListener(new SparkListener{
      override def onTaskStart(taskStart: SparkListenerTaskStart): Unit = {
        println("taskLocality: " + taskStart.taskInfo.taskLocality)
      }
    })
    sc.parallelize(1 to 10, 1).count()

@zsxwing I have sadly lost most of the context on this issue and don't have time to pick it back up at the moment.
What you point out does seem to be an issue, though.  Definitely feel free to take my patch if you think it's the right fix.

Merged build triggered.

Merged build started.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44838/
Test FAILed.

Merged build finished. Test FAILed.

retest this please

I think this is the right fix. However, more pairs of eyes on this change would be better.

Merged build triggered.

Merged build started.

Test build #44967 has started for PR 3816 at commit 247ce55.

Test build #44967 has finished for PR 3816 at commit 247ce55.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44967/
Test PASSed.


migrate codecov to v2

What type of PR is this?
What this PR does / why we need it:
On February 1, 2022, codecov v1 will be fully sunset and no longer function
ref codecov Deprecration of v1
Which issue(s) this PR fixes:

xref #157
Special notes for your reviewer:

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@6f80fc2). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             main    #171   +/-   ##
======================================
  Coverage        ?   7.30%
======================================
  Files           ?      25
  Lines           ?    2928
  Branches        ?       0
======================================
  Hits            ?     214
  Misses          ?    2696
  Partials        ?      18

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f80fc2...f33c30b. Read the comment docs.


Add buttons to remove keys\items from dictionaries\arrays.

This PR adds a 'remove' button for array items and dictionary items.
Fixes #23058.

PoolXArrays now have deletes and no longer crash:

There seems to be some trailing whitespace according to Travis logs.

This change bloats Inspector horizontally and the goals is to have it very horizontally compact.
Is there an option to hide this button?

(above screenshot is actually from Debug window since Inspector has a bug and can't show 3rd level of nesting when dictionary is involved)

Right, that was also my concern. I don't think it should be made optional, but we should find a different way to provide this feature without bloating the UI.
One option would be to change the Edit button to a drop down menu with Edit and Delete options.

One button with 2 options is a cool idea.
I'd be even cooler if this button had less width than current Edit. Perhaps button from dock windows, with 3 vertical dots, could be used? It's quite thin.

The horizontal bloat for nested arrays\dictionaries needs to be solved in a smarter way but I can change the edit button to an 'options' button with edit and delete options.

The horizontal bloat for nested arrays\dictionaries needs to be solved in a smarter way but I can change the edit button to an 'options' button with edit and delete options.

I agree with both statements, this will need to be reworked eventually, but in the meantime having an Options button instead of the current Edit one seems good.

Some Notes:

I manually fixed the merge conflict (RID change).
Array now copies dictionary style (Edit Type->Remove Item) if it's untyped. If it's typed it's still the trash button as there is no reason to show a menu for one option.
Removed the dictionary addition, it already had a remove item anyway.

I ran the clang formatter through Visual Studio, it seemed to alter parts in the file I hadn't touched please advise if I should revert these lines.

The changes removing new lines after { are wrong indeed, our style guide allows those so far and up until version 8.0 at least clang-format would not remove them. What version do you have?

The changes removing new lines after { are wrong indeed, our style guide allows those so far and up until version 8.0 at least clang-format would not remove them. What version do you have?

For the reference, the option that controls this is KeepEmptyLinesAtTheStartOfBlocks, which should default to true in clang-format 8.0 or earlier. If you have a newer version (from SVN) and they decided to change the default, that could explain the changes you got.

I am not certain what version of clang-format visual studio uses. I used a custom install and it worked fine. Hopefully this is now satisfactory.

Thanks!


How do I call a RemoteObject method from Apache Royale?

I need is to add more than one method to the RemoteObject.
Using the example as3, but adding one more method, how would this look in Apache Royale?
<mx:RemoteObject id="Server" destination="Server" source="gb.informaticasystems.Server" fault="handler_backendCommunicationFails(event)" >
<mx:method name="executeQuery" result="handler_fetchDataRequestSuccess(event)"/>
<mx:method name="getData" result="handler_getDataSuccess(event)"/>
</mx:RemoteObject>
Someone has a similar example but in Apache Royale??

Did you check this one ? RemoteObjectAMFTest

Yes, but what I do not understand is where I put the path of the source parameter; that routes the method file.
example source parameter:

as3.
<mx:RemoteObject id="Server" destination="Server" source="gb.informaticasystems.Server" fault="handler_backendCommunicationFails(event)" >
<mx:method name="getData" result="handler_getDataSuccess(event)"/>
</mx:RemoteObject>
apache royale.
fx:Script

	<![CDATA[

protected function getSomeCompressedProduct():void
{
Server.send("getData", []);
}
]]>
</fx:Script>
<js:CompressedRemoteObject id="Server" destination="Server" result="onResult(event)" fault="onFault(event)"          endPoint = "http://localhost:8080/messagebroker/websocket-amf"
/>

Hi,
first thing I see is that right example to look is this. The other one is for Royale RemoteObject that I not recommend to use. Better use MXRoyale emulation of Flex RO.
I'm using MX RO extensively, but not using mx:method mxml tag, although I see in that example that Alex put several ones and I remember that was working.
About "source" property. I don't recommend to use that since is deprecated and expose the internals of your server, in opposite I use destination, and channelset, that uses endpoint.
CompressedRemoteObject is used when you compress data in your server, so maybe is not right to use for your case.

Hi Carlos,
If I tried to use MXRoyale library, but it doesn't show anything I get the blank page. Do you have a solution in Jewel UI?

Hi, I use Jewel UI with RemoteObject AMF from MXRoyale. I only use MXRoyale for that and some few more classes like some validator that is still not created in Jewel. Notice that in the project I linked before there's and example mxml App with Jewel and other without Jewel. Compile one or the other to see the diferences.

The goal of the MX Emulation Components is to emulate existing Flex behavior whenever possible.  The "source" property is not well documented in the Language Reference so it isn't clear how it is supposed to work.  It looks like you should be able to set it from MXML.  Whether it is deprecated or not, if it used to work, we should consider trying to make it work in Royale.
Volunteers are needed to help make it work correctly if it isn't.  Simple test cases and a test server would be helpful, not to mention an actual pull request with any required changes.

Maybe I'm wrong, but I think others already made source work so don't think is broken. I recommend starting from the example I posted with your backend or using the one we have in our examples/amf folder to test (this), and from a working app that sends AMF, try to tweak to use source property. Then report back with your findings.

We are using it this way:
responderComp1 = new Responder(fn_roCompListRH, fn_HandleFault);
tokenComp1 = roCompList.fn_GetCompListDP();
tokenComp1.addResponder(responderComp1);
trace(tokenComp1);
instead of
roCompList.fn_GetCompListDP();
&
<mx:RemoteObject id="roCompList" endpoint="http://localhost:8080/SHMA/messagebroker/websocket-amf"
					 destination="shmCompanySetupBO"/>

result and fault handlers are removed from mx:RemoteObject Section.


Repository Update

General format update
Added description for new data components
Deleted Expansion Option Folder
Changed Aggregation Folder to Contribution Folder
Updated aggregate_yaml.py: sort_keys = False
Updated new_data_sources_names.yml
Updated DataSOurcesDefinition Notebook

Going to resubmit


Pull queue, agent implementation

update
There is an initial implementation available in the unstable 0.5 image that you can test. Please note that this implementation is highly unstable and the protocol will change before the final release, breaking the existing implementation. So don't start using 0.5 expecting a stable or production quality implementation.
This issue will be closed once the communication protocol is finalized. We are currently looking to implement the STOMP protocol with features based on Apache Apollo (http://activemq.apache.org/apollo/documentation/stomp-manual.html). This will provide a standard communication protocol with the potential to easily choose between the embedded drone queue and a compatible STOMP mq server for added scaleability.

[ ] implement stomp protocol for standard communication
[ ] update documentation to reflect protocol change and configuration
[ ] remove existing custom protocol
[ ] remove existing agent token / secret for custom protocol
[ ] make sure logging of the above items is removed (see https://github.com/drone/drone/issues/1779)

This is a proposal to switch from a push queue in 0.4 to a pull queue in 0.5. The current version of Drone manages incoming build requests, and pushes builds to docker daemons when build slots are available. This doesn't really allow for very fine-grained scheduling, and using the Docker remote API as the transport protocol makes supporting non-Docker builds (like iOS app) much more difficult.
The pull queue would have us place an agent on a server that will poll the main Drone server for builds. The agent would be started on each server by running the Drone server in agent mode:
docker run drone/drone --agent --host=http://mydrone.com

The Drone server would need an endpoint for polling jobs:
POST /api/work/pull

And an endpoint for posting job results, including intermediate updates like pending, running, finished, as well as build logs:
POST /api/work

Below discusses some pros and cons to the current approach vs. proposed new approach.
Pros
Durability
The Drone server can be taken down for periodic upgrades without worrying about losing the in-memory build queue (see https://github.com/drone/drone/issues/1195). Agents can use backoff to retry contacting Drone server if unavailable when posting results or requesting jobs.
Multi-architecture
This makes it easier to support multiple operating system and architectures, especially those that don't support Docker (I'm looking at you, iOS). A build system that doesn't support iOS applications can never be a true alternative to Jenkins.
Resource Usage
This allows (in a future release) the agent to regulate how many builds can execute based on resource usage, instead of just a fixed number (ie 2 builds on this server). This is similar to how Docker swarm has different profiles for allocating resources, and we could (eventually) provide something similar.
Elasticity
The current design makes increasing or decreasing capacity relatively simple, however, I think agents make this even easier. You could simply snapshot an image or AMI and start up a bunch of servers in batch, which would immediately start processing jobs when they come online. This could still be used in conjunction with Docker machine to bring up the server and run an agent. It would also work better with something like Rancher and Mesos, which have their own GUIs for launching servers.
Cons
Extra Setup
This adds an extra step to our installation. Right now you can simply start Drone and use the host machines Docker daemon to run builds. I want to make sure Drone is easy to evaluate, but I do think agents will scale better for real-world, multi-server installs.
Secure Communication
We need to find a way to secure communications between the Drone server and their agents. Docker handles this today by creating and installing certificates (using Docker machine) and using TCP for communications.
Single Server Installs
Running Drone on a single server (with no external build servers) may be slightly more complex because we'll need to deal with inter-container communication.
Support Both?
While technically possible, I want to pick one approach and execute and document it extremely well. Attempting to support both will likely result in more complex code, complex documentation and confusing and increased support for the community.

While pull-based agents would (as you noted) make setup more involved, I think the pros probably outweigh the cons.
Some things that appeal to me:

Not having to open sockets on all of the worker machines. I'd rather focus my security efforts on the Drone server as much as possible.
Might end up being a little less fragile.
If I am understanding correctly, container orchestration systems like Kubernetes will pretty much automatically get agent auto-scaling support. That's code that we don't have to write and maintain, and it lets admins adapt their Drone configuration to the paradigms and patterns they are most familiar and comfortable with. Did I mention that we don't have to write code for this, too?
Might be easier to write custom agents that have alternative behaviors this way. Meet the pull-based "interface" and go nuts. At the very least, the development flow might be easier since you've got a more full separation from Drone core.

Things to think about or build in mind with:

A build gets pulled by an agent. Work starts, but for any number of reasons the agent dies without reporting. We'll want to make sure the build isn't stuck in an "In Progress" state indefinitely, since the agent died. Will be crucial to nail this for general reliability and in case an aggressive auto-scaler kills a container/machine that's doing work without waiting for it to finish.
Multi-agent build parallelism. I think this is an important feature for modern CI setups to do well with. Given a build, launch the same build on multiple agents with a different evar/build var set. Let the user figure out the rest. CircleCI does this well, IMO. Give them the ability to do it, let them figure out how to split the work up. We obviously don't need a solution in place anytime soon, but I'd hope that we have a rough ideal-case design or two sketched out to make sure that our pull-based implementation allows us to eventually tackle this.
As you mentioned in Gitter, matrix builds. This and build parallelism remind me of Celery's notion of chords. All of the sub-tasks must finish before the top-level job is marked as complete.

I like the idea of the switch, overall. We can probably mitigate some of the setup overhead with documentation and maybe an option to run drone + the agent in a single container for evaluation or low-traffic setups.

@gtaylor agree with everything you've written above

Not having to open sockets on all of the worker machines. I'd rather focus my security efforts on the Drone server as much as possible.

We may need to open a port on the worker machine to stream build logs. When a client visits the page of a running build, we create a websocket to the server, which would connect to the worker machine and proxy the logs.
An alternative design would be for the worker to send the log stream to the server, to avoid opening a port. The server then would multi-cast the logs to clients that may connect. The drawbacks to this approach are that a) the server would need to store the logs in-memory for every running build which could limit server scalability and b) this makes clustering the server difficult since we would need a central cache for the logs.
But if we can work around those two issues, it would be nice to avoid bi-direction communication ...

It might be worth pointing out that there would need to be some additional logic to prevent 2 workers from picking up the same job in parallel. This seems like it'd tie in with the "a worker dies unexpectedly" story.
What would be a unit of work to be picked up? Would it be a single job? Or a build? How would this tie in with matrix builds?

@macb thanks for joining the conversation. I've attempted answered your questions below. I'd love to know your overall thoughts on the proposal? If we can implement this correctly, and keep the setup simple, do you see this as an improvement?

It might be worth pointing out that there would need to be some additional logic to prevent 2 workers from picking up the same job in parallel.

We can use a Go channel to queue up jobs. The agents could long poll for jobs and connect to the channel to receive the jobs. This is similar to what we do in 0.4, however, the 0.4 server also manages execution state and lifecycle which is why restoring everyone when the server restarts is a pain. This proposed approach will allow us to restore the queue without having to restore execution state, which is much more simple.

This seems like it'd tie in with the "a worker dies unexpectedly" story.

I'm thinking we can have agents ping the server every N minutes. If an agent doesn't ping within N minutes + some buffer we can re-allocate the job to another server. It sounds simple enough in my head but this this the first time I've through about it :smile:

What would be a unit of work to be picked up? Would it be a single job? Or a build? How would this tie in with matrix builds?

Great question. Matrix builds make this a bit more complicated because we need to execute notifications after the all matrix jobs are complete. I think we'll need a unit of work that is a bit more flexible, and perhaps a priority queue to always ensure notifications are executed after build completion in a timely manner.
I don't have an immediate answer for this, but will give it some thought and post back.

It sounds like there is some overlap between matrix and parallel builds. Solve one and the other becomes a smaller task.
Re: The queue stuff. There are a ton of queue daemons that can do this stuff, gotta figure someone else has already done the work to expose a queue library with timeouts and retries.

in general, i like the idea of moving to a pull queue very much.
my big concerns are things that have already been brought up.. what happens if two workers try to grab the same job at the same time? this can definitely be mitigated, but it's a challenge to make sure you think about.
also why the opposition to bidirectional communication? it seems to me like it's more or less necessary for things like log streaming and notifications. a simple websocket server/client setup would make all of this much easier. when a new build needs to run, emit an event (potentially with constraints that would be resolved on the client side), clients could then send a response accepting the job (which would only work once, later ACKs would be rejected so the client is aware the job is already taken). logs could be streamed over the socket as well, and it still doesn't require opening any ports on the client side of things.

thanks @nlf for the comments. I also wanted to document your suggestion from Gitter for keeping the logs out of RAM. The agent can stream the logs to the server, the server can write the logs to a tmp file, and connected clients can stream the output from the tmp file

A couple thoughts:

I agree with @nlf that bidirectional communication between the server and workers is necessary (cancel a job and such).

:+1: for the idea of the server to stream logs to a tmp file and then that file output gets streamed to the client.

But... couldn't the client also directly open a websocket to the worker?  The server could tell the client which worker to open a connection with.  Workers could also write the output to a db if needed while they stream results to the client.  Just a crazy thought.

While the proposed design is great for manual or auto scaling of drone, it does make single installations more complex (as mentioned above).  I agree that having two architectures is not ideal, but what about two different installation scripts or methods?  Would that even make sense?

I think mitigating two workers picking up the same build could be done in many different ways... some more complex than others.

A silly thought, but raft consensus would be interesting and might allow scaling out of more than one drone server behind a load balancer.  Also it may not practical for this sort of problem (way over kill?).

Secure server communication is a concern for me. Who provides the certs? How do you add a worker to the pool securely? Repo secrets passed across networks and proxies via SSL/TLS (don't anger fragile/touchy corporate proxies!).  Do we have a mode without SSL/TLS to debug silly internally networks?

Overall I think the new design proposal is an exciting next step for drone, but poses new challenges we all have mentioned thus far.  I think the benefits far outweigh the costs for a VERY scalable drone solution that can tackle iOS and other builds.

But... couldn't the client also directly open a websocket to the worker? The server could tell the client which worker to open a connection with

I wouldn't be crazy about this, since now we're talking about exposing ports on all of our worker VMs instead of just the Drone server (if I am understanding correctly).

While the proposed design is great for manual or auto scaling of drone, it does make single installations more complex (as @bradrydzewski mentioned above).

We can preserve the existing simple install by doing something like the GitLab Omnibus image does, at least by default. Those with more traffic or rigorous conditions could run separate containers for Drone and its workers.
Also, I'll leave this here for worker discovery: https://www.serfdom.io/

I really like most ideas mentioned above. But I would prefer to let the server only communicate to the clients, including a load balancer in front of multiple servers. A socket connection between servers and workers sounds reasonable. For log writing and streaming I would suggest a database because temp files won't work for loadbalanced servers. For discovery of workers I like the idea of using serf :)

I've been trying to think of alternatives to workers automatically streaming the logs to the build server. The reason is that, in most cases, this is un-necessary unless there is a user on the website attempting to view the running build.
I'm worried that if we automatically stream the logs for every build we'll hit network limitations and filesystem limitations for larger installs (1000+ workers).
Instead I'm thinking when a user attempts to view the logs for a running build it opens a websocket to the Drone server that blocks and waits. The agent is notified that a user wants the log stream, so the starts pushing the to the server to the server. The agent log stream is somehow connected to the block user websocket, which immediately starts an io.Copy to send the data back to the client.
Not sure if I described it correctly, but I believe it would still allow uni-directional communication from agent to server via websocket, without less risk of overloading the server with too many build streams or having to worry about disk performance and temp files.

Just to be sure: I'd still be able to look at all of my historical build logs (at least the latest X builds or days worth) after the fact? We find ourselves checking our old build logs periodically for various reasons (timings, output differences, watching some moving parts that we haven't factored out yet).

@gtaylor yes! at the end of the build, the agent will always post the updated build information and full build logs to the drone server to get persisted in the database.
The on-demand logs described above only impacts real-time streaming

Cool cool cool

Has there been any update on this ticket? We're kinda concerned about the durability aspect you've mentioned in the ticket and are just making the assumption that this work is starting to be investigated or even actioned :)

@Spedge I wouldn't be too overly concerned about the durability aspect unless you have a high volume drone install and plan on stopping / starting your drone instance during working hours. If you do stop / start drone while builds are running, drone will mark those builds as failed on restart, but will leave behind artifacts (build containers) which will need to be manually removed.
So just to clarify, restarting the drone instance does not result in data loss. Restarting drone results in previously pending or running builds to be force-marked as failed and then some manual cleanup is required.

the issue is outdate?

No, it's not outdated. The communication protocol is not finished yet

closing issue, agent code and protocol updates merged to master


$redirect modifier for basic rules

Discussion:
https://github.com/AdguardTeam/AdguardForWindows/issues/1501

I've been waiting for a long time
When can it be achieved?

Closing as duplicate of #1043 which is more informative


[WIP] Build for Android with Clang

Checklist

[ ] documentation is added or updated
[x] tests are added or updated
[ ] CLA is signed

Description of change

Add support for building for Android with NDK's clang. Targets master yet I guess 1.1 branch can be applied as well.
Documentation incomplete. See util/configure-android.sh and .travis.yml for usage of ./Configure. See also https://travis-ci.org/yan12125/openssl/builds/191712918 for a test build.

So this currently adds 12 new travis targets that only build. I'm not sure that it's useful to try and build all those targets. Is it possible to run the test suite for any of them?

I've been looking at travis config. This adds whole hour of CPU time. It's hardly appropriate. Ironic thing is that significant portion of time is used unpacking NDK zip (in each build), as well as installing compilers that won't be used... But even if optimized, I'd also say that we should pick just one target for continuous testing. I suppose clang would be most appropriate since they apparently plan to eventually remove gcc from NDK...

I agree we don't want to add all those build-only targets. At most one.  And all those android config targets should all be moved into a separate file.

Thanks for all the feedbacks. Please let me explain them one by one.
About bloated .travis.yml: Agreed. I removed those new Travis targets. At first I put them there just to verify that my patches works fine. Actually, I test openssl for android in my repo from time to time, so I don't miss any breakages in openssl.
In response to @kroeckx's comment:

Is it possible to run the test suite for any of them?

Currently I use the Termux app to get a working copy of Perl on Android. Unfortunately, seems it doesn't provide useful APIs to control it - human operations are necessary to get openssl's test suite running on Android.
About the problem of $CROSS_COMPILE: First, nothing will get broken as those variables are not removed. Instead, they're moved from unix-Makefile.tmpl to Configure. Second, in unix-Makefile.tmpl, AR and RANLIB relies on CROSS_COMPILE. Without CROSS_COMPILE, I have to set at least AR and RANLIB to get correct commands. For example,
AR=aarch64-linux-android-ar
RANLIB=aarch64-linux-android-ranlib

If that sounds fine, I'll drop CROSS_COMPILE-related patches.
Last, about @richsalz's comment:

And all those android config targets should all be moved into a separate file.

Reasonable. What's the naming convention for files in Configurations? Is "50-android.conf" a good name?

Is it possible to run the test suite for any of them?

... [no] ...

This is not strictly true. If linked statically OpenSSL Android binaries can be executed on Linux host. If Android target is x86[_64], then make test works as is. If target is non-x86, then it's possible to use qemu by setting up EXE_SHELL environment variable. [That's how MIPS64R6 support was tested.] Note that I didn't say that make works as is, only make test. As for make, even though it's possible to pass -static flag to Configure(*), resulting Makefile needs minor fix-up, namely removal of -pie and -ldl flags to get binaries linked...
(*) -static alone is sufficient for Linux targets, and it's even possible to execute such binaries on Android units. [That's by the way how I usually perform ARM benchmarks.]

.. just don't set any CROSS_COMPILE variable when using clang.

AR and RANLIB relies on CROSS_COMPILE. Without CROSS_COMPILE, I have to set at least AR and RANLIB to get correct commands.

Or you can modify $PATH so that it uses target-specific un-prefixed tools. I mean there are un-prefixed binaries too, e.g. in toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/aarch64-linux-android/bin/...
Trouble with special treatment of CROSS_COMPILE triggered by a word clang is that it becomes less flexible and non-uniform. For example CROSS_COMPILE can as well be a directory name, not necessarily platform-this-n-that-, so what happens if somebody wants to env CROSS_COMPILE=/my/platform/clang/bin/ ./Configure something?

Is "50-android.conf" a good name?

I'd vote for 20-android.conf to denote that it's not exclusively community-supported targets. I mean 10-* is what we officially support(*), 50-* and following are de-facto community-supported, not regularly supported and unsupported stuff...
(*) modulo fact that there are few legacy platforms that we don't actually know if they work, and intension is to move them out as we gather information about them.

This is not strictly true. If linked statically OpenSSL Android binaries can be executed on Linux host

First, I don't think running Android binaries on Linux brings persuasive test results. Unlike ELF on FreeBSD or PE/PE+ on Unix (via Wine), Linux is not designed to be compatible with Android binaries. Second, static builds are broken (https://github.com/android-ndk/ndk/issues/272)

Trouble with special treatment of CROSS_COMPILE triggered by a word clang is that it becomes less flexible and non-uniform.

Got it. I remove CROSS_COMPILE related changes.

I'd vote for 20-android.conf

Done!

Modification is difficult to read - to understand modification I have to split into 2 parts : to extract existing android targets into new file and then updates from this issue.
Main modification is to add a lot of templates bases on existing configurations.
It seems to me main idea of templates is to use flag -mandroid for gcc and -target LLVM_TRIPLET for clang.
Question is why to use -mandroid for gcc?
In GCC online documentation for first time in version 4.6 we could find option documented as "-mandroid: Compile code compatible with Android platform. This is the default on ‘--linux-android’ targets. When compiling, this option enables -mbionic, -fPIC, -fno-exceptions and -fno-rtti by default. .." .
It seems to me option is required for GCC pre 4.6 releases.
My oldest installed NDK version is r10d(December 2014) with gcc 4.6, 4.8 and 4.9 and current stable r13b is with gcc 4.9.
I think that removing option -mandroid is enough to allow build with clang. Users of oldest gcc has to specify -mandroid and clang users should use -target LLVM_TRIPLET.
In both cases users has to override compiler (CC). Cross-compile prefix is not enough.

In *-clang targets, there are more flags than -target, for example -fno-integrated-as. It sounds a bad idea to force OpenSSL users to understand which targets require -fno-integrated-as.

Question is why to use -mandroid for gcc?

I guess OpenSSL aims to support as old toolchains as possible without bothering users with compiler internals.

Question is why to use -mandroid for gcc?

I guess OpenSSL aims to support as old toolchains as possible without bothering users with compiler internals.

Right.

clang users should use -target LLVM_TRIPLET.

It's safer to put it into config than to let user mistype it. Well, user still has a number of environment variables to get wrong, but goal is to minimize amount of things to get wrong, not to maximize. Besides the triplet is tied to assembly pack, so that it's really not something that user is free to mix-n-match.

In both cases users has to override compiler (CC). Cross-compile prefix is not enough.

??? Cross-compile prefix is enough with gcc. As for clang suggestion is to not set cross-compile prefix, but manipulate PATH so that you have clang as well as un-prefixed tools such as ar and ranlib. It does work. Yeah, it's inconsistent, but what can one do?

This is not strictly true. If linked statically OpenSSL Android binaries can be executed on Linux host

First, I don't think running Android binaries on Linux brings persuasive test results. Unlike ELF on FreeBSD or PE/PE+ on Unix (via Wine), Linux is not designed to be compatible with Android binaries.

When it comes to statically linked executable it all boils down to system call numbers. So the question is if Android changes any of Linux system call numbers, even more specifically those used by OpenSSL test suite. And there is a lot of evidence that it doesn't. As already mentioned, 'make test' does run and produced meaningful on Linux, be it native or qemu-user-assisted. The keyword, again, is that Android is built on top of Linux kernel and [most of] its user-kernel interface is unmodified. Also once again note that we are not looking at arbitrary Android application, but specifically about OpenSSL test programs which are just "console" applications.

Second, static builds are broken (android-ndk/ndk#272)

Well, this of course can be problematic. But I'd count on linker to tell me when it becomes impossible to use them. I mean as long as one can link and as long as tests produce meaningful result, I see no reason not to trust them.

I think that removing option -mandroid is enough to allow build with clang. Users of oldest gcc has to specify -mandroid and clang users should use -target LLVM_TRIPLET.

In other words suggestion is to have unified Android target[s] and put responsibility of setting CC environment variable and passing compiler-specific things like -target at config-time on user. While this is an option, and there is kind of "tradition" to give users quite a bit of power at config-time, I'd say that the said "tradition" is not really about unconstrained flexibility. I mean there are boundaries for the provided flexibility. This of course asks for question where/how to draw this boundary. For example there is no boundary between gcc and clang on Linux, right? In sense that there is no dedicated clang target and you can switch to clang by setting CC environment variable. Yes, but in such "traditional" case we are looking at so to say single-triplet installations, and there are no additional tidbits that have to be tied up together. This is not case here, as already mentioned, the triplet has to match assembly pack (and not to forget integrated-as limitation), and I'd say that arranging dedicated clang targets is justified here...

Andy Polyakov wrote:

Question is why to use -mandroid for gcc?

I guess OpenSSL aims to support as old toolchains as possible without bothering users with compiler internals.
Right.
Removal of flag -mandroid from current build configuration does not mean
to stop support for old compilers.
It is enough to update current comment in 10-main.conf.
On remark: for abi filters "armeabi", "armeabi-v7a" application has to
pack separate libraries even the build flags are same. NDK build pass
...-march=armv5te... for first abi and ...-march=armv7-a ... for second.

Andy Polyakov wrote:

I think that removing option -mandroid is enough to allow build with clang. Users of oldest gcc has to specify -mandroid and clang users should use -target LLVM_TRIPLET.
In other words suggestion is to have unified Android target[s] and put responsibility of setting CC environment variable and passing compiler-specific things like -target at config-time on user.
Yes . Idea is to minimize build configurations and in same way do not
stop users to build for each supported by NDK ABI.
The list of supported abiFilters in NDK r13b is following: "armeabi",
"armeabi-v7a", "x86", "mips", "arm64-v8a", "x86_64", "mips64".
ABI armeabi-v7a-hard is no longer supported.

How many build configurations to define?
6(7 if distinguish two arm ) plus 2 generic (no-asm) for GCC and same
number for CLANG?

[SNIP]This is not case here, as already mentioned, the triplet has to match assembly pack
What you mean by "triplet has to match assembly pack"?

Hi Andi,
Andy Polyakov wrote:

clang users should use -target LLVM_TRIPLET.
It's safer to put it into config than to let user mistype it.
Build is quote complex. I can not see way to minimize chance user to
"mistype" some of options.

7 abi filters
6 GCC target(host) triplets (not compatible with above, i.e. host_cpu
!= ABI)
6 platform directories (sysroot) (also not compatible with above)
7 LLVM target triplets (partially compatible with GCC)
A lot of room for failures.

For sample lets see one clang compilation command for a native library
(abi armeabi) :
/opt/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++

-target armv5te-none-linux-androideabi
-gcc-toolchain
/opt/android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64

--sysroot=/opt/android/sdk/ndk-bundle/platforms/android-9/arch-arm ...
Even with correct llvm triplet from OpenSSL build configuration user
could use set wrong toolchain path or sysroot.
My opinion is do not share responsibility between openssl configuration
and user build command.
What about just to comment existing build configuration?
For instance:
 # a) abiFilters "armeabi"
 #     gcc triplet arm-linux-androideabi
 #     llvm triplet armv5te-none-linux-androideabi
 # b) abiFilters "armeabi-v7a"
 #     gcc triplet arm-linux-androideabi
 #     llvm triplet armv7-none-linux-androideabi
 "android-armeabi" => {
     inherit_from     => [ "android", asm("armv4_asm") ],
 },

======

Well, user still has a number of environment variables to get wrong, but goal is to minimize amount of things to get wrong, not to maximize. Besides the triplet is tied to assembly pack, so that it's really not something that user is free to mix-n-match.
What is relation between triplet and "assembly pack"?

Roumen

Some initial comments on build with llvm (after remove of -mandroid).
a) Build pass without modification for ABI arm64-v8a, mips64 and x86_64. This is because minimum platform version is 21.
b) Build fail for armeabi-v7a, mips and x86 if platform is less then 21. Issue is from stdatomic.h , in following statement:
...
#if STDC_VERSION >= 201112L
include <uchar.h>  /* For char16_t and char32_t.              */
#endif
...
Header uchar.h does not exist in platforms before 21.
With flag -std=c99 build fail in assembler :(
As work around I could build with -D__STDC_NO_ATOMICS__
c) Work-around from b) does not work for ABI armeabi, dur to unresolved externals to many  __atomic... functions. Perhaps related to compiler flags as my build script use "... -march=armv5te -mtune=xscale -msoft-float -mthumb ..." similar and native build in android studio.
Build of master branch succeed with gcc 4.9 for all 7 ABI-filters.
I guess that gcc build with flag -std=c11 fail if platforms is less then 21 but this case is not tested yet.

My opinion is do not share responsibility between openssl configuration and user build command.

Well, following this logic we don't need any config lines whatsoever. Why not let user specify everything? I'm talking about everything, not just Android :-) Yes, I recognize that user has enough ways to screw it up by setting wrong environment variables, yet, I'd consider retaining control over things we can reliably control as desirable. "triplet matching assembly pack" means that you can't use -target i686-none-linux-android with ARM pack. But I think I see your point now. You're saying that there is need for specifying distinct -targets for same assembly pack, more specifically ARMv4 pack. Right? In gcc case you have freedom to pass additional -march or -D__ARM_MAX_ARCH__=8 at config-time and former is not an option in current suggestion. Yes, that needs additional consideration...

Header uchar.h does not exist in platforms before 21.

Platform headers in platforms/android-X/arch-Y/usr/include are not reliable. Use unified headers instead - this is my next goal after this PR.
Also, I'd like to hear NDK developers for Clang bugs (?) on x86 and MIPS before moving on.
https://github.com/android-ndk/ndk/issues/285
https://github.com/android-ndk/ndk/issues/286

Hello, NDK r14 is out, and the aforementioned two bugs are still in the NDK, so -fno-integrated-as workaround is still necessary. I think this pull request is ready for a second review.
For CLA: I'll read it and submit it soon

Any hope of this landing soon?

This still needs a CLA in place ...

@yan12125 ndk r16 is out now, would it be possible to complete this?
@t-j-h Is there a path where someone with CLA could commandeer the request if the original poster is no longer interested/available?

I'm currently not working on this and I don't think I can continue it in near future. I have a local patch at https://github.com/yan12125/python3-android/blob/563bd3388b48c7cf5cfaee92339953b2e393fed6/mk/openssl/ndk-clang-targets.patch, which should work for NDK r16. If anyone wants to finish this PR, I guess it's legal to start from my local patch as the latter is released with WTFPL.

I am using android-ndk 14 and i am getting the clang:error: unknown argument: '-mandroid' when i am trying to build openssl   can any one help me

@jainabhinav249 https://github.com/openssl/openssl/blob/master/NOTES.ANDROID should be helpful. Also make sure you're using the latest OpenSSL 1.1.1. Older OpenSSL versions may not work fine with Android.

Thank you so much @yan12125

So bitcoin/bitcoin#16110 is merged...


doc: reformat net-stack-arch doc for PDF output

While the two-column layout looked OK in the HTML output, it totally
broke the PDF version of the documentation.  So, this change puts the
picture before the text instead of using embedded raw html tags to
create a two-column look. (And fixes the PDF generated output.)doc:
reformat net-stack-arch doc for PDF output
While the two-column layout looked OK in the HTML output, it totally
broke the PDF version of the documentation.  So, this change puts the
picture before the text instead of using embedded raw html tags to
create a two-column look. (And fixes the PDF generated output.)
Signed-off-by: David B. Kinder<EMAIL_ADDRESS>

Here's what the PDF was looking like:

@MaureenHelm what's wrong with the commit message?
@jukkar Sorry, I need to get the PDF generation working.  I've added issue #19259 to track finding a suitable solution to bring back the two-column look that works for HTML and PDF.


Send request to<EMAIL_ADDRESS>makes the script crash

$client = new PostmarkClient("API_KEY");
$sendResult = $client->sendEmail(
          "fromEmail",
<EMAIL_ADDRESS>          "Subject",
          "Body"
        );

running this results in a 500 server error.
Can anyone reproduce this?

Can you post the specific error you get? A 500 server error could mean anything.

Apologies, the below code does, in fact, produce a documented exception. Output below.
try{
            $client = new PostmarkClient("API_KEY");
            $sendResult = $client->sendEmail(
                  "sender_email",
<EMAIL_ADDRESS>                  "subject",
                  "body"
                );
}catch(PostmarkException $ex){
            echo $ex->httpStatusCode;
            echo $ex->message;
            echo $ex->postmarkApiErrorCode;
}

422
You tried to send to a recipient that has been marked as inactive.
Found inactive addresses<EMAIL_ADDRESS>Inactive recipients are ones that have generated a hard bounce or a spam complaint.
406

This can be closed...


[FLINK-23054][table-blink] Correct upsert optimization by upsert keys

Cherry-pick #16239
What is the purpose of the change
After FLINK-22901.
We can use upsert keys to fix upsert join, upsert rank, and upsert sink.

For join and rank: if input has no upsert keys, do not use upsert optimization.
For upsert sink: if input has unique keys but no upsert keys, we need add a materialize operator to produce upsert records.

Brief change log

Join should use upsert keys instead of unique keys to do upsert
Rank should use upsert keys instead of unique keys to do upsert
TemporalJoin should use upsert keys instead of unique keys to do upsert
Introduce materialize operator to produce upsert records before sink.

Verifying this change

UpsertTest
UpsertITCase

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no) no
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no) no
The serializers: (yes / no / don't know) no
The runtime per-record code paths (performance sensitive): (yes / no / don't know) no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know) no
The S3 file system connector: (yes / no / don't know) no

Documentation

Does this pull request introduce a new feature? (yes / no) no

LGTM, +1


[MRG] ENH coreg-GUI:  use high-res head shape if available

Would we also prefer the high resolution head shape for FSAverage? I don't know the details of how it is computed but it showed up when I pointed the GUI to fsaverage (i.e., the GUI ran $ mkheadsurf on it). The plot does seem to suggest that the LPA and RPA fiducials are somewhat misplaced. Is that an artifact of the fsaverage creation?

This is just intuition, but I would say no, since it is an average (and a particularly special average at that: I was even surprised mkheadsurf would produce something vaguely head shaped). I think keeping it smooth gives an appropriate amount of play and smoothness for any unrecommended case where someone is using fsaverage, and it is less likely to throw off the ICP alignment via overfitting to a non-individual's brain. my 2 cents

[Current coverage][cc-pull] is 77.75%

Merging [#3383][cc-pull] into [master][cc-base-branch] will decrease coverage by 8.80%

@@             master      #3383   diff @@
==========================================
  Files           335        335
  Lines         57669      57839    +170
  Methods           0          0
  Messages          0          0
  Branches       8787       8819     +32
==========================================
- Hits          49919      44973   -4946
- Misses         5074      10724   +5650
+ Partials       2676       2142    -534

[][cc-pull]

Powered by Codecov. Last updated by [4f37ddc...aff7b3c][cc-compare]
[cc-base-branch]: https://codecov.io/gh/mne-tools/mne-python/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/mne-tools/mne-python/compare/4f37ddc0b186e91ebb05e07650555b38b96eea05...aff7b3c847c440c9e87b82f181a8f399c0a41046
[cc-pull]: https://codecov.io/gh/mne-tools/mne-python/pull/3383?src=pr

So then I'm wondering how this should be reflected in the GUI.  Or should we just include advice on it? Or have a second checkbox that says something like "also use high resolution brain for fsaverage" and is off by default?

Is there anything that can tell that a subject is not the genuine subject?, we could just uncheck the box and put a note saying for non-individual MRIs we don't recommend using the high resolution surface (assuming people agree, I haven't tested, it just seems like there is potential for find "strange minima").

I don't know if there is a general rule, fsaverage could be detected based on its name

what is the reason why the high res head is bad for non individual MRIs?

Because the two features the high res is most useful for (the ears and nose) are highly variable in their shape (and the ears can have different positions). People can easily overfit or worry about their match based on the fiducials. The advantage of the high res, is that I can fit the points right in the valley between the crus of helix and the tragus (where I digitize) and the nasion. In the case of using an MRI of someone you didn't scan, It isn't important for them to be at the right spot there. What matters most is that the EEG sensors are in the correct position. If someone uses for example the keep nasion option, on a person's data who has an odd shaped nose then, they will be hurting their ability to get a good fit. Again this is intuition, so feel free to ignore

[Current coverage][cc-pull] is 77.75%

Merging [#3383][cc-pull] into [master][cc-base-branch] will decrease coverage by 8.90%

@@             master      #3383   diff @@
==========================================
  Files           335        335
  Lines         57761      57840     +79
  Methods           0          0
  Messages          0          0
  Branches       8805       8819     +14
==========================================
- Hits          50056      44975   -5081
- Misses         5020      10724   +5704
+ Partials       2685       2141    -544

[][cc-pull]

Powered by Codecov. Last updated by [8b4aa67...be137e8][cc-compare]
[cc-base-branch]: https://codecov.io/gh/mne-tools/mne-python/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/mne-tools/mne-python/compare/8b4aa6731b828430453b6e36405313e1bea3d701...be137e89ceeca52a743d001581ee71d58ce7e6a1
[cc-pull]: https://codecov.io/gh/mne-tools/mne-python/pull/3383?src=pr

@agramfort

Current behavior is to simply display this message if "show high res head" is selected but no high res file is there. I am not sure if there is a way to detect average brains, and if they generally should not be aligned with high res heads. We could just look for the name ("fsaverage"), but then I wonder what exactly the behavior should be?

@christianbrodbeck what do you think the right approach is for the average?
I think the image you provided of fsaverage is a good example of my argument, the fiducials aren't lined up with a good point on the ear or the nasion, and I think that is a good thing (because of my earlier argument)

I updated the screen shot at the top of the PR (see the check box in the top left field).
@dgwakeman I don't like the idea of ignoring the checkbox for fsaverage and prevent users even if they intentionally want to display the high res head. I wonder whether there should be a second checkbox after the "high res head" button that says "use standard for fsaverage"? Although there is the question of whether fsaverage is actually the brain that the majority of average brain users use (if we use the name to detect it and if there is not a method to detect average brains in general). Otherwise I think it should just be documented that for fsaverage the high res head is less appropriate...?

Sounds reasonable, I guess the other key would be to have that in the example for coregistering/scaling

I suppose viz.plot_trans should also use the high resolution head if available, should I add this to this  PR or make a separate one?

Separate PR would be better

This is ready from my end unless there are suggestions for modifying the functionality. Currently this adds a checkbox for using high res head shapes (see first post, top left of the GUI), and will just display an error message if the high res head shape can not be found.

@christianbrodbeck I think @jona-sassenhagen had a few issues when trying to use the GUI, I assume those should be separate issues rather than fix them in this PR?

Yes I think #3432 is separate, what were other issues?

Not sure... maybe that was the only one. Didn't realize there was an issue open already.
This LGTM, @jona-sassenhagen since you're in coreg mode can you give it a try?

Not specific to this PR, but on my Mac, I get ...
/Users/jona/anaconda3/envs/py2/lib/python2.7/site-packages/pyface/ui/wx/init.py:25: wxPyDeprecationWarning: Using deprecated class PySimpleApp.
  _app = wx.PySimpleApp()
/Users/jona/anaconda3/envs/py2/lib/python2.7/site-packages/pyface/ui/wx/init.py:29: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'.
  wx.InitAllImageHandlers()

@jona-sassenhagen you should use QT backend, run $ export ETS_TOOLKIT="qt4". If you started it with form the terminal $ mne coreg you should have gotten a message about that.

Can't use QT for now because there's a problem with libpng and QT dependencies on Conda and working through them would be way too much work to be honest. I can try again when new versions of libpng or QT arrive on Conda.

Still, when I try, I actually get this funny error message (instead of the error about QT I usually get when I try to force the QT backend):

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-b88511442c68> in <module>()
----> 1 mne.gui.coregistration()

/Users/jona/anaconda3/envs/py2/lib/python2.7/site-packages/mne-0.13.dev0-py2.7.egg/mne/gui/__init__.pyc in coregistration(tabbed, split, scene_width, inst, subject, subjects_dir)
     66     view = _make_view(tabbed, split, scene_width)
     67     gui = CoregFrame(inst, subject, subjects_dir)
---> 68     gui.configure_traits(view=view)
     69     return gui
     70

AttributeError: 'CoregFrame' object has no attribute 'configure_traits'

However, that also happens on master.

Hm that might be due to our catching the ImportError internally for testing... As far as I know TraitsUI is only really compatible with QT backend (and possible the ancient wx 2.8?) so I am not sure if you can get it to run without QT...

Although on conda you could create a virtualenv...

Maybe not really worth investigating until I have a working pyqt.

For me something like this works:
$ conda create -n mayavi python=2.7 anaconda mayavi

That's how I've set up the env I'm using right now (I'm not using py2 usually). The problem is a libpng conflict: https://github.com/gpilab/framework/issues/3
I could in principle set up different versions of either dep, but that'd be effort ...

Should we try to avoid silencing those import errors?

Should we try to avoid silencing those import errors?

Is this still an open question? What import errors do you mean?

@Eric89GXL I meant the
try:
    from mayavi import x ...
except ImportError:
    x = None

pattern, because for people that don't have Mayavi installed this hides the true reason the GUI fails, Instead displaying something like
AttributeError: 'CoregFrame' object has no attribute 'configure_traits' ```

I think we originally added those to enable testing of subcomponents of the GUIs without Mayavi. Since some of the automatic testing environment now support Mayavi we could just make sure that on others modules that import Mayavi don't get imported?

Yeah that sounds reasonable to me. Nest all mayavi and related imports if necessary

Ok I will do that once the other GUI PRs are merged to avoid rebasing

Which PR do you mean? #3463 is the only one marked MRG but currently needs a rebase

@Eric89GXL Yes I meant #3463 and the current one this discussion is in.

Okay agreed, let's fix the other issues from @jona-sassenhagen in another PR then

Thanks @christianbrodbeck


gnatsd crashes on Windows i386 (and probably on any Intel 32bit platform)

The crash happens as soon as a client connects, and it's a null pointer exception on the atomic add:
// Lock should be held
func (c *client) initClient() {
s := c.srv
c.cid = atomic.AddUint64(&s.gcid, 1) //////// crash here
There are no null pointers but AddUint64() crashes if the pointer is not 64bit aligned ("fix" added on March 12: https://code.google.com/p/go/source/detail?r=09cc9661f4ee29dca7da92ae8916cefded775bb5&path=/src/pkg/sync/atomic/asm_386.s)
Suggestion: align the pointer or make s.gcid (and c.cid) int32 ?

Seems to be closed by #78. Please let us know if not.


Use PutVarInt instead of PutFixed while encoding stream entry value

As @ShooterIT recommended here: https://github.com/apache/incubator-kvrocks/pull/745
I changed PutFixed32 to PutVarint32 and GetFixed32 to GetVarint32.
Encoding/decoding functions were 'borrowed' from RocksDB codebase.
Obviously, this change makes it impossible to decode entries if entries were encoded with PutFixed32 (an error will be returned).
Is it too late to introduce such a change?

Is it too late to introduce such a change?

I don't think it is late, since now it is only on unstable branch which we may make changes on it.
one problem we need to concern is about open source license about these codes copied from leveldb/rocksdb.
should we put its license header. And is xxFixed32 copied from leveldb/rocksdb, should we describe this? @git-hulk

@torwig Thanks for your contribution. As @ShooterIT mentioned that we don't promise stability and compatibility before releasing, so feel free to do that.
@ShooterIT Those Put|GetFixedXXX are NOT copied from rocksdb/leveldb indeed, we rewritten them into BIGENDIAN while the rocksdb is little endian, so I think it's good to keep Apache 2.0 statement only. https://github.com/facebook/rocksdb/blob/0050a73a4fb1ba52d78655b271a0f09ba1fbf7fc/util/coding_lean.h#L25

@git-hulk BTW, after reverting snappy version I have Cmake error on Fedora 35
CMake Error at /usr/lib64/cmake/GTest/GTestTargets.cmake:37 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: GTest::gtest;GTest::gtest_main

  Targets not yet defined: GTest::gmock;GTest::gmock_main

Call Stack (most recent call first):
  /usr/lib64/cmake/GTest/GTestConfig.cmake:42 (include)
  /usr/share/cmake/Modules/FindGTest.cmake:187 (find_package)
  build/_deps/snappy-src/CMakeLists.txt:40 (find_package)

However, I see that all builds you have in your CI are successful.

@git-hulk BTW, after reverting snappy version I have Cmake error on Fedora 35
CMake Error at /usr/lib64/cmake/GTest/GTestTargets.cmake:37 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: GTest::gtest;GTest::gtest_main

  Targets not yet defined: GTest::gmock;GTest::gmock_main

Call Stack (most recent call first):
  /usr/lib64/cmake/GTest/GTestConfig.cmake:42 (include)
  /usr/share/cmake/Modules/FindGTest.cmake:187 (find_package)
  build/_deps/snappy-src/CMakeLists.txt:40 (find_package)

However, I see that all builds you have in your CI are successful.

There are some cmake changes from Snappy 1.1.7 to 1.1.9, find_package(gtest) always exists in 1.1.7 regardless of SNAPPY_BUILD_TESTS being set to OFF.
Could you open an issue for this? I will fix it.

And if you want to workaround it now, you can just remove find_package(GTest QUIET) in <build dir>/_deps/snappy-src/CMakeLists.txt.

@PragmaTwice I've created an issue: https://github.com/apache/incubator-kvrocks/issues/792

@ShooterIT Can have a look again and merge if have no comment.


Update setup-mpi.md

fix typo in HPC-X download command

@themorey : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

#sign-off


Breakpoints in schema

It doesn't appear that breakpoints are setting on a schema.

I believe this is because the package.json file says breakpoints are for markdown files, not xml (schema) files: https://github.com/jw3/example-daffodil-vscode/blob/master/package.json#L129


NativeImage get/set pixel method names are encorrect

NativeImage uses the same pixel format as OpenCV/OpenGL. Found this whilst testing why pixel values in MineLP aren't being interpreted correctly.
To reflect this both the methods should be renamed:
NativeImage.getPixelRGBA -> NativeImage.getPixelABGR
NativeImage.setPixelRGBA -> NativeImage.setPixelABGR

@Sollace Look at this:

So is this a vanilla bug or what?

Turns out you are indeed right!

hmm, sometimes we do have the habit of putting some values that come first in lower bits. This needs javadoc.

Eeyup, I'm guessing this is a Mojang bug. It's very likely whoever was working on this code didn't realise that the components go the other way, and since Mojang never does anything that's sensitive to components being swapped, they just never noticed. @liach

in another place where mojang encodes uv in 1.15 (see OverlayTexture), they put u in lower bits and v in higher bits as well. So this is like whether (u | v << 16) is called uv or vu order.

Hmm, can we rename those Rgb into like RgbLe, like we have seen writeIntLe for low-endian integers etc


unpin hotkey not working on Release Notes tab

VSCode Version:1.51
OS Version:macOS 10.15.7

Steps to Reproduce:

open Release Notes tab
use ⌘K ⇧Enter pin this tab
use ⌘K ⇧Enter again should unpin it, but nothing happens
same hotkey works fine on other normal tabs

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

Duplicate of #100953


Remove resource pages that we don't want people on

We don't want the following endpoints:

api_keys index, both html and json (should just use workers index)
jobs anything (should use workers index) EXCEPT for the create endpoint, which should redirect you to the workers index after creation
event_actions anything html (keep all the json ones though), the ui is all on the event receivers index
event receivers anything but index html (index uses the json endpoints)

To do this, we need to:

Remove endpoints from the controllers (change to redirects?)
Change back button links in the slim templates

This is almost done, need to fix the page you go to after creating a job though


Deploy every change to stg automatically.

We can utilize the zuul gating for this since we have staging secrets there.
Steps (from the top of my mind):

[ ] encrypt new secrets for stg, since they have changed recently. Guide is here (update might be needed).
[ ] Add openshift token to zuul CI. (we may want to have a "special" service account for this)
[ ] add a new job to zuul gating (DEPLOYMENT=stg make deploy)
[ ] Update Contribution guide with the statement that we merging all PRs using zuul label mergeit

Or we can do that from the other side (Openshift).
I hope https://github.com/packit-service/deployment/pull/31 (WIP now) should mostly do this.

Done in https://github.com/packit-service/deployment/pull/31


Fixed #12592

Short description of what this resolves:
Changes proposed in this pull request:

If the view doesn't exist, the view is setted as an empty array.

Ionic Version:  3.x
Fixes: # Tabs.select(idx), receive error "Cannot read property 'length' of null"

Hello and thank you for contributing to Ionic! We have been working on porting all of the Ionic components to web components and have recently updated master to reflect this. This significant change has caused this pull request to break. While we really appreciate the time and effort you put into creating this, we are not able to merge it because of the newly introduced conflicts. We are extremely sorry about this. We will not be merging any more features in to v3. If this is a feature and you have the time, please resubmit this PR against the master branch. If this is a critical security issue in v3, we would greatly appreciate it if you would resubmit the PR against the new v3 branch. Thanks so much for your time!


installation - pub get failed

Looking to install this on my mac on the Flutter dev channel, but getting a pub get error:
Because dartx >=0.2.0 <0.4.0 depends on path >=1.6.4 <1.7.0 and every version of flutter_test from sdk depends on path 1.7.0, dartx >=0.2.0 <0.4.0 is incompatible with flutter_test from sdk.
So, because neucalcu depends on both flutter_test any from sdk and dartx ^0.3.0, version solving failed.

...

SLVR:   ! dartx ^0.3.0 is satisfied by dartx ^0.3.0
SLVR:   ! which is caused by "neucalcu depends on dartx ^0.3.0"
SLVR:   ! thus: version solving failed
SLVR: Version solving took 0:00:03.039692 seconds.
    | Tried 1 solutions.
FINE: Resolving dependencies finished (3.1s).
ERR : Because no versions of dartx match >0.3.0 <0.4.0 and dartx 0.3.0 depends on path >=1.6.4 <1.7.0, dartx ^0.3.0 requires path >=1.6.4 <1.7.0.
    | And because every version of flutter_test from sdk depends on path 1.7.0, dartx ^0.3.0 is incompatible with flutter_test from sdk.
    | So, because neucalcu depends on both flutter_test any from sdk and dartx ^0.3.0, version solving failed.
FINE: Exception type: SolveFailure
FINE: package:pub/src/solver/version_solver.dart 312:5   VersionSolver._resolveConflict
    | package:pub/src/solver/version_solver.dart 133:27  VersionSolver._propagate
    | package:pub/src/solver/version_solver.dart 97:11   VersionSolver.solve.<fn>
    | ===== asynchronous gap ===========================
    | dart:async                                         Future.catchError
    | package:pub/src/utils.dart 113:52                  captureErrors.wrappedCallback
    | package:stack_trace                                Chain.capture
    | package:pub/src/utils.dart 126:11                  captureErrors

    | package:pub/src/command_runner.dart 193:13         PubCommandRunner.runCommand

---- End log transcript ----
pub get failed (1; ---- End log transcript ----)
exit code 1

Any thoughts please?  I am a beginner in Flutter but have a working development environment and have created quite a few test flutter apps.
P.S. This calc project seems to cause vscode to show all packages with red underlines, incl import 'package:flutter/material.dart'; e.g. a similar issue is discussed at https://github.com/flutter/flutter/issues/19384 in other projects.  However my other flutter projects are ok.  Flutter doctor is OK.

@abulka
There are two issues with what happened.
Red lines on material.dart indicates that you have not yet run pub get and you were unable to run pub get because there are conflicting package dependencies.
I just tried switching to the dev channel and it broke my app. I could only guess they might have introduced some breaking changes in the dependencies.
I suggest you switch back to the stable channel if you want to run my project.

I would like to also point out in my pubspec.yaml file I'm overriding dartx to v0.3.0 because hive has some packages that depend on that version and this is a known issue.


Neutral mobs cannot be pulled -- they escape pulling when unangered.

Description

Even when not angry, neutral mobs refuse to be pulled.

Screenshots

Additional context

Not sure if because of #26868  or just happenstance.

Renault not want to be pulling)

If Willow the Roo is downed while angry, and then revived, it still keeps breaking away from pulling. Usually just results in medbay having a few idling pets inside with no way of dragging them out.

Goats and iirc cows are the same too

For some reason the pulling TryStopPull(...) call triggers the AttemptStopPullingEvent for both the ai and the player, and when it happens on the player it succeeds even through handcuffs. without knowing why it causes the second trigger I dunno how to fix it.

I did the thing I said was gross. Theyll still escape when unangered however unless handcuffed & they must have hands, or otherwise unable to interact with themselves.

#30066
Here's another PR trying to fix this issue, but this one just makes the mobs/NPCs unbuckle/unpull only when angered.

#30066 Here's another PR trying to fix this issue, but this one just makes the mobs/NPCs unbuckle/unpull only when angered.

mfw you dont link your bug fixes

mfw you dont link your bug fixes.

For the handcuff issue, my PR isn't really solving it.
And I noticed this issue just today.
They mostly work together, with there being a bit of jank in the NPC/planner logic, causing situations where the NPC thinks it can unbuckle itself, and then tries it and fails ad infinitum.
I guess I could go and fix it at some point, I don't believe it's that big of a problem currently.

They mostly work together, with there being a bit of jank in the NPC/planner logic, causing situations where the NPC thinks it can unbuckle itself, and then tries it and fails ad infinitum. I guess I could go and fix it at some point, I don't believe it's that big of a problem currently.

Yeah I considered this, but they also can't do anything else useful while cuffed, so I didn't see any big downside? Maybe its worth the perf gain though? idk.


Getting an institution's parent and child institutions

When searching for an institution by name, what's returned can often be a department within the desired institution, rather than the desired institution itself. Support for the tree endpoint helps provide parent/child information to the user.

Looks good but I'd double-check with @paulwib as those endpoints seem to be marked as beta.

The endpoints should be out of beta tomorrow

Ok 👍