Define the interfaces for all the functions in Worker

Worker facilitates the stake and mint process.

It reads the stake requested data from the database.
It gets the worker address for the database for each chain.
It unlocks the worker address account.
It updates the database with the current status of facilitation.
For more details check the epic #1

This ticket is about defining the interfaces of all the functions in the Worker.
The proposed functions are provided for reference.
The implementer can think this in detail and can add/remove functions.

[ ] Constructor
- Accepts mosaic-config, facilitator-config as parameter.

Accepts Config object. (store in variable).
Creates DB object. (store in variable). (Still in discussion)

[ ] **function to get pending items from stake_request table. (Create the ticket for this.)

[ ] function that handles the state machine (Create a new ticket for this.)

[ ] function to get the message status from messageOutbox of the gateway.

[ ] function to get the message status from messageInbox of the cogateway.

[ ] function to get the latest stateRoot from the anchor contract (auxiliary chain).

[ ] function to update DB with the latest state of facilitation. (Task execution table) (Update the ticket).
- REQUESTED

ACCEPTED
ACCOUNT_PROVEN
STAKE_INTENT_COMFIRMED
PROGRESS_STAKE
PROGRESS_MINT
COMPLETE

[ ] function to update DB with hashlock and unlockSecret.
- [ ] function to update DB with proof data.

- [ ] **function to unlock worker address.**
	- Get the encrypted_account from Config for the given address.
	- Read the password from the env variable.
	- Decrypt the account.
	- Add it to web3 account wallet.

The accounts will be unlocked at the commander level and will update the web3 wallet.

[ ] function to create hashLock and unlockSecret.

Generate hashlock and unlockSecret pair

[ ] function to approve bounty amount.

[ ] function to accept stake request.

[ ] function to generate account proof.

[ ] function to confirm stake intent.

[ ] function to progress stake.

[ ] function to progress mint.

[ ] function to stop the worker (handle SIGTERM). (update the ticket.)

Please note that Worker will be called as Facilitator


Updating DynamicForms Module.txt

The CustomForms module name and website were listed.

Hi @phillipsj, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

Can you please re-create it by targeting 1.9.x? Thanks.


Policy Changes

Warning: do not merge before branch redesign-get-by-ids-dtos is merged.
This pull request changes policies used in UsersController.
Changes made

GET api/users/teachers method is now allowed for all registered users.
GET api/users/students is now allowed for teachers and administrators.

Pull request #60 has all changes from this PR.


Remove vscode folders, and add that to .gitignore

I don't normally see IDE settings committed into git.. are these meant to be here?

My laziness to create a proper .gitignore :)


Update Javadoc URL on Value

Value is no longer experimental, so (as the person who raised the issue
suggested) the Javadoc should no longer point to the 'experimental'
documentation. Fixes #1091

Putting myself in 'AUTHORS' seems excessive for something so trivial, I wasn't sure whether it was a project rule to always edit it or not. I'm happy to update the PR without the AUTHORS edit (and save that for if I make a future PR with actual work in it!)

No need to add your name to the AUTHORS file. Thanks for the fix.


Contributing feedback

Some inputs/adjustments to the contributors.md file based on my specific experience using it as a guide to get started.
These changes are intended to be seen as suggestions. Feel free to adjust/tune at your discretion.
Note: I also made a couple of small changes that I find make it easier to edit the md in a text editor (notepad++ in this case) so the diff is pretty big. Apologies if that's not the preferred way to format the file.

lgtm


MAUI app crashes when scanner invoked on iPhone 15 Pro Max (iOS 17.2.1)

This seems to be the same issue using the old library on my old phone. I have the generic MAUI app you get when creating a new MAUI app in Visual Studio. I added a button on the main page to create and display a new page that contains the scanner control, and that page sets the control options in the constructor and waits for a scan. Before adding the button and new page, I verified the app runs on the android emulator as well as my iPhone. Then I added the ZXing package, button and new page. I then re-verified the app compiles and runs on the android emulator. It scans my test QR code without issue. The app runs on the iPhone right up until I click the button to invoke the scanner, then it crashes. I see that others appear to have at least been able to invoke the scanner, so I'm not sure what's up. Perhaps a manifest provisioning issue? Particulars below:
==========================================================================
Windows 11 Home (x64)
Visual Studio 2022
iPhone 15 Pro Max
iOS v17.2.1
ZXing.Net.Maui.Controls 0.4.0
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:zxing="clr-namespace:ZXing.Net.Maui.Controls;assembly=ZXing.Net.MAUI.Controls"
             x:Class="SandboxMauiApp.ScannerPage"
             Title="Scanner">
    <VerticalStackLayout>

        <zxing:CameraBarcodeReaderView
            x:Name="barcodeScannerView"
            BarcodesDetected="BarcodeScannerView_BarcodesDetected" />

        <Button
                x:Name="ScanExitBtn"
                Text="Exit"
                SemanticProperties.Hint="Exits barcode scanner"
                Clicked="ScanExitBtn_Clicked"
                HorizontalOptions="Fill" />

    </VerticalStackLayout>
</ContentPage>

namespace SandboxMauiApp;

public partial class ScannerPage : ContentPage
{
    public ScannerPage()
    {
	InitializeComponent();

        barcodeScannerView.Options = new BarcodeReaderOptions
        {
            Formats = BarcodeFormats.TwoDimensional,
            AutoRotate = true,
            Multiple = true
        };
    }

    private void BarcodeScannerView_BarcodesDetected(object sender, BarcodeDetectionEventArgs e)
    {
        foreach (var barcode in e.Results)
            Console.WriteLine($"Barcodes: {barcode.Format} -> {barcode.Value}");

        Navigation.PopAsync();
    }

    private void ScanExitBtn_Clicked(object sender, EventArgs e)
    {
        Navigation.PopAsync();
    }
}

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
=================================================================
Native Crash Reporting
=================================================================

Native stacktrace:
=================================================================
0x10066d6e0 - /private/var/containers/Bundle/Application/73854A73-1F50-4120-9E6D-3EB1F63ADB41/SandboxMauiApp.app/Xamarin.PreBuilt.iOS : AppleCryptoNative_X509ImportCollection
0x1006585cc - /private/var/containers/Bundle/Application/73854A73-1F50-4120-9E6D-3EB1F63ADB41/SandboxMauiApp.app/Xamarin.PreBuilt.iOS : AppleCryptoNative_X509ImportCollection
0x1006ac174 - /private/var/containers/Bundle/Application/73854A73-1F50-4120-9E6D-3EB1F63ADB41/SandboxMauiApp.app/Xamarin.PreBuilt.iOS : AppleCryptoNative_X509ImportCollection
0x10066ced0 - /private/var/containers/Bundle/Application/73854A73-1F50-4120-9E6D-3EB1F63ADB41/SandboxMauiApp.app/Xamarin.PreBuilt.iOS : AppleCryptoNative_X509ImportCollection
0x1fa5b8888 - /usr/lib/system/libsystem_platform.dylib :
0x1d7dd2ed0 - /usr/lib/system/libsystem_kernel.dylib :
0x1d7dd2f04 - /usr/lib/system/libsystem_kernel.dylib :
0 d4  ......0A......
0x1d7dac358  03 01 00 54 7f 23 03 d5 fd 7b bf a9 fd 03 00 91  ...T.#...{......
0x1d7dac368  01 d5 ff 97 bf 03 00 91 fd 7b c1 a8 ff 0f 5f d6  .........{.....
0x1d7dac378  c0 03 5f d6 d0 03 80 d2 01 10 00 d4 03 01 00 54  ..............T
The app has been terminated.
0x1b0df98f8 - /System/Library/PrivateFrameworks/TCC.framework/TCC :
0x1b0df5814 - /System/Library/PrivateFrameworks/TCC.framework/TCC :
0x1b0dfd1f8 - /System/Library/PrivateFrameworks/TCC.framework/TCC :
0x1fa6bfb44 - /usr/lib/system/libxpc.dylib :
0x1fa6b24b8 - /usr/lib/system/libxpc.dylib :
0x198639380 - /usr/lib/system/libdispatch.dylib :
0x198656b04 - /usr/lib/system/libdispatch.dylib :
0x19864bd40 - /usr/lib/system/libdispatch.dylib :
0x19864b628 - /usr/lib/system/libdispatch.dylib :
0x1fa65f99c - /usr/lib/system/libsystem_pthread.dylib : _pthread_wqthread
0x1fa65fa04 - /usr/lib/system/libsystem_pthread.dylib : start_wqthread
=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x1d7dac358):0x1d7dac348  ff 0f 5f d6 c0 03 5f d6 30 41 80 d2 01 10 0

(* sigh *)
And just like that, it stopped crashing. The scanner control isn't rendered, mind you, but at least it doesn't crash.
I made a few adjustments to the XAML to explicitly declare the camera position and it started not crashing, but when I reverted the code to the original, it continued to work, so I have no idea what happened.
The odd thing is, even though the control isn't rendering, it's there, because I have Hot Reload active and when I modify the XAML to add IsTorchOn="True" and hit save, the light on my phone comes on and goes off if I change the value to "False". But no control is visible on the UI,
Things still work fine in the Android emulator, so I just need to figure out why the control won't render on the UI on my iPhone.
So close. :)

Oh but wait, there's more. Turns out that while the control appears to not be responsive to HorizontalOptions or VerticalOptions, it is responsive to WidthRequest and HeightRequest. While in the Android emulator, no such properties were needed, if you don't set those values, the control is not visible on the iPhone. So now I have a visible control that seems to scan ok.
Still no idea why it stopped crashing, but progress.

Have you tried using a <Grid> rather than a <VerticalStackLayout> ?

For those who come here looking for help regarding using the scanner view on iOS:

Make sure you add ".UseBarcodeReader()" to the chain of methods called when the app is created. I believe this is mentioned on the front page of the Git project, but I forgot about it when migrating and it caused me a lot of unnecessary grief.

IMPORTANT! Make sure you include this key/value pair in the "info.plist" file in the iOS platform folder:
NSCameraUsageDescription
Barcode scanning

I am almost 100% sure this is the cause of the crash. I managed to get the Xamarin version working as well after adding this.
I would also suggest you set the "WidthRequest" and "HeightRequest" on the barcode reader control and give them some sane values (I used 360 and 480) to start. This should hopefully let you at least see something and verify the control is working.

Have you tried using a <Grid> rather than a <VerticalStackLayout> ?

I have not, but I may play around with that. I have things working now, so I'm content to leave things in a stack layout for now.

Hello, I am facing same issue and this crash only occurs as soon as I install app on iOS and click on "Allow Camera access" and app crashes.
Once I restart app it works fine.
if I uninstall app and then re-try to give permission it crashes.
How to resolve this? my code is as below, in .xaml file
  <zxing:CameraBarcodeReaderView     HeightRequest="200"     WidthRequest="200" Margin="10"     x:Name="cameraBarcodeReaderView"     BarcodesDetected="BarcodesDetected" />
in .cs

`
  public PageUpdate()

{
InitializeComponent();
cameraBarcodeReaderView.Options = new BarcodeReaderOptions
{
Formats = BarcodeFormats.All,
AutoRotate = true,
Multiple = true
};
}
 protected void BarcodesDetected(object sender, BarcodeDetectionEventArgs e)

{
foreach (var barcode in e.Results)
{
Console.WriteLine($"Barcodes: {barcode.Format} -> {barcode.Value}");
}
   Dispatcher.Dispatch(() =>
   {
       GridControl.Add(new Label { Text = $"{e.Results[0].Value}" }, 1, count);
       count++;

   });

}
`


doesn't works on toolbox (container)

What system are you running Yazi on?
Linux Wayland
What terminal are you running Yazi in?
foot, alacritty, tty
Yazi version
yazi 0.1.5 (283f937)
Did you try the latest main branch to see if the problem has already been fixed?
Tried, but the problem is still present
Describe the bug
doesn't works on toolbox (container), but seamless on host
Expected Behavior
can show preview of file, open, edit
To Reproduce

enter toolbox (fedora-toolbox-39)
run yazi

Configuration
no config
Anything else?
No response

Is the toolbox like Docker? Please try to launch Yazi in your foot terminal via:
alias yazi="TERM="foot" yazi"

to see if the image preview is normal.

it's like distrobox

The created container will be tightly integrated with the host, allowing sharing of the HOME directory of the user, external storage, external USB devices and graphical apps (X11/Wayland), and audio.

can show preview of file, open, edit

I'm not quite sure how about this. Could you please describe it in detail?

When it says "cannot preview, open, or edit files", does it refer to what kind of files? - Images, text files, or all of them
Does the toolbox have the file(1) command? What is the output of file -bL --mime-type your-file for the file you're trying to open?
Does the toolbox have the xdg-open command, which is used to execute opening files?

nice, thank you
the problem is file command is not found
seems necessary to add to the README that requires file?

Done! https://github.com/yazi-rs/yazi-rs.github.io/commit/f8b6b7992f75467126bbf6b409bf5788f6dcf557
Thanks for the suggestion!


Sponsor button is broken (Github only)

Describe the bug
Funding.yml cant be parsed because user is not enrolled in Github Sponsors
To reproduce
Click the sponsor button in the repo
Screenshots

Hello @rbracco,
Thank you for noticing that, unfortunately I am from Tunisia, and my country isn't supported yet by Github Sponsors.

I will hide this button until the Github Sponsors support comes.
If there is anyone interested in sponsoring this project, you may use the following IBAN (International Bank Account Number):
TN5904018104003696876646


Git hk adding dv2 monitor

Some changes to contribute to PR ITISFoundation/osparc-simcore#2411

Codecov Report

Merging #6 (63c9f6c) into adding-dv2-monitor (887ab73) will increase coverage by 14.4%.
The diff coverage is n/a.

@@                  Coverage Diff                  @@
##           adding-dv2-monitor      #6      +/-   ##
=====================================================
+ Coverage                71.7%   86.1%   +14.4%
=====================================================
  Files                     505      10     -495
  Lines                   19176     210   -18966
  Branches                 1868      17    -1851
=====================================================
- Hits                    13752     181   -13571
+ Misses                   4968      23    -4945
+ Partials                  456       6     -450

Flag
Coverage Δ

integrationtests
?

unittests
86.1% <ø> (+17.0%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...server/src/simcore_service_api_server/db/errors.py

...g/src/simcore_service_catalog/models/domain/dag.py

...es/storage/src/simcore_service_storage/handlers.py

...imcore-sdk/src/simcore_sdk/node_ports/dbmanager.py

...base/src/simcore_postgres_database/models/users.py

...ore_service_api_server/db/repositories/api_keys.py

...es/director/src/simcore_service_director/config.py

...es/storage/src/simcore_service_storage/__init__.py

...sdk/src/simcore_sdk/node_ports/_data_items_list.py

...es/sidecar/src/simcore_service_sidecar/__init__.py

... and 485 more


Nice optimizing! 👍

Great work! 🔥


Add allow_missing in expand

Added an optional keyword argument to expand which will override the
default behavior when wildcards in the filepath are not present.  If
allow_missing=True and it is not used in the filepath, wildcards without
values will be left as wildcards.

all pass.
Also:

Added unit tests for the expand function
Added to faq to describe overriding product in expand and the new
allow_missing keyword.
Fixed some non-raw strings in re in io.py

Closes #124

This is a great feature! In terms of simplifying coding, do you think it might be better to switch to something like from functools import partial (see https://docs.python.org/2/library/functools.html)? This would obviate the need for the special keyword allow_missing.

Thanks for the suggestion. I must say though that I don't see the use case. You can always mask the wildcards:
assert expand("{a}_{{b}}.out", a=[1,2]) == ["1_{b}.out", "2_{b}.out"]

I typically keep my paths in the config and try to reference them in the workflow to keep everything DRY.  If my outfile = '{a}_{b}.out' I then have to do something like:
expand(outfile.replace('b', '{b}'), a = [1, 2])
# or
expand(outfile, a=[1,2], b='{b}')

both obfuscate the code more and get repetitive if I have a lot of wildcards I don't want to format.
The other example is chaining combinators, as brought up by this old issue.  The solution could now be rephrased as
expand(
  expand('{tp}/compare/{name}vs{comp}', comp=sample_to_compare, allow_missing=True),
  tp=sample_name, comp=sample_to_compare, zip)

The original issue also presented a use case where a partial expand would feed into listfiles or glob_wildcards.
I guess it's a convenience function for a corner case, but it would be a cleaner fix than format masking in complex examples.  It may (hopefully) prevent future issues asking for something similar.  If allow_missing isn't included in the kwargs it also doesn't add much overhead.

Thanks for the suggestion. I must say though that I don't see the use case. You can always mask the wildcards:
assert expand("{a}_{{b}}.out", a=[1,2]) == ["1_{b}.out", "2_{b}.out"]

This has also been discussed in this issue.
Do you have any suggestions for a good workaround to the example mentioned in the issue?


Could you release this?

Cloud you release this great gem on rubygems?
Unfortunately 'hcl' and 'rhcl' are already registered on rubygems, probably you should change some filenames and classes.
But I think that this gem better than rhcl and usable.

I have not considered it, but now that there is interest I think I should. I will take a look at the source again and see where I can clean it up, and make changes to filenames/classes and make it ready to be put on rubygems.
Thank you very much for your help and input!

Thank you! I'm glad you say so.
Please let me know if I can help anything.

I could also use this in a gem.
Thanks!

I will work on publishing this as a gem in the next few days.

@sikula any chance?


Integrate combin memory into pipelined and single-cycle CPUs

This PR (hopefully) modifies the existing CPU models to use the newer memory with no side effects to overall functionality.

At the moment the code does not work because I've hit a hard wall with that one simulator issue. I've tried to remove all relevant DontCares from the memory modules, but the NoSuchElementException still gets raised with the DualPortedCombinMemory.memory module. The elaborated FIRRTL doesn't have any invalid signals anywhere in the three memory modules (DualPortedCombinMemory, ICombinMemPort, and DCombinMemPort).
I may experiment with adding the firrtl.transforms.NoDCEAnnotation option to the simulator's optionsManager as freechipsproject/chisel3#971 seems to suggest, if DCE really is the case of this problem, though I am not sure if that would be a desired long-term fix.

That seems like a fine short term fix. Does it work if you add that option?

Finally had some time to work on splitting the IO. That flipped bus definitely seemed to be the issue, since the CPU is sending signals to the memory and the memory address size check assert is failing.

Changes look good! Sounds like we're getting somewhere!

Alright, I got almost all of the single cycle CPU tests passing. The ones that do fail are due to the CSR evec signal being DontCare/invalid, so the imem address gets assigned to 0x80000000. This address is too large for the memory address assert.
I can work around this by removing that assert and outputting 0 when the address exceeds the memory's size, which is what the old memory does, but ideally we should have that assert when the CSR is fully incorporated into the CPU.

This looks good to me. However, I would prefer if you could rebase and clean up the history to make sure that each commit is its own thing.
As a couple of examples:

make sure to keep the csr thing in its own commit
Make changes to the CPUs their own commits
Moving CoreIO around
Etc.

I rebased most of the combinational memory work. Hopefully the commit history is more clear.
My plan right now is to integrate the non-combinational memory into the pipelined CPUs, then rebase any frivolous commits starting at 9cce50c if needed.

Looks like we're ready to merge??? :D

Not yet, the non combin memory does not work with the pipelined CPUs. I'm debugging them right now but I think the PC isn't being updated

So, I need to make a more fundamental change to the design of the pipelined CPU that will deviate slightly from the pattern in Patterson & Hennessy.
I need to be able to freeze the ex_mem register - right now, the CPU flushes the register with 0 when there is a bubble, but the control signals otherwise propagate through to the mem_wb stage. This results in some desync between the writeback signals and the readdata signal, which is delayed.
I took the lw1 test and added some relevant debug info:
...
>>> Cycle #7
PC: 12
1 => 0 => 0 (readdata = 0)
Issuing a read

>>> Cycle #8
PC: 16
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #9
PC: 20
0 => 0 => 1 (readdata = 0)
*** Stalling! ***

>>> Cycle #10
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #11
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***
Data received:<PHONE_NUMBER>

>>> Cycle #12
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #13
PC: 20
0 => 0 => 0 (readdata = 0)

>>> Cycle #14
PC: 24
0 => 0 => 0 (readdata =<PHONE_NUMBER>)

>>> Cycle #15
PC: 28
0 => 0 => 0 (readdata = 0)

This corresponds with a lw t0, 0x400(zero) instruction entering the mem stage, being delayed for five cycles (the configured latency), and continuing on with execution.
The third line of each cycle printout (x => x => x) corresponds with the wbcontrol.toreg signal in the id_ex, ex_mem, and mem_wb registers respectively. The readdata corresponds with mem_wb.readdata.
The main issue is that at cycle #9 (a stalling cycle), the desired toreg signal, 1, is located in mem_wb, so the CPU will write back the contents of readdata, which is 0. At cycle #14, mem_wb.readdata is set to 0xFFFFFFFF, but toreg is 0 in mem_wb. So the readdata is lost entirely.
Ideally I must be able to freeze ex_mem as so:
...
>>> Cycle #7
PC: 12
1 => 0 => 0 (readdata = 0)
Issuing a read

>>> Cycle #8
PC: 16
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #9
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #10
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

>>> Cycle #11
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***
Data received:<PHONE_NUMBER>

>>> Cycle #12
PC: 20
*** Stalling! ***
0 => 1 => 0 (readdata = 0)

>>> Cycle #13
PC: 20
0 => 1 => 0 (readdata = 0)

>>> Cycle #14
PC: 24
0 => 0 => 1 (readdata =<PHONE_NUMBER>)

>>> Cycle #15
PC: 28
0 => 0 => 0 (readdata = 0)

>>> Cycle #16

Which would synchronize the readdata and toreg signals properly.

Seems reasonable, but let's talk more details in our meeting today.
On Wed, Jul 31, 2019 at 4:01 AM Jared Barocsi<EMAIL_ADDRESS>wrote:

So, I need to make a more fundamental change to the design of the
pipelined CPU that will deviate slightly from the pattern in Patterson &
Hennessy.
I need to be able to freeze the ex_mem register - right now, the CPU flushes
the register with 0 when there is a bubble
https://github.com/jlpteaching/dinocpu/blob/bb0ca05b56d5dd7503555851c1abbbd1d266ad70/src/main/scala/pipelined/cpu.scala#L296-L302,
but the control signals otherwise propagate through to the mem_wb stage.
This results in some desync between the writeback signals and the
readdata signal, which is delayed.
I took the lw1 test and added some relevant debug info:
...

Cycle #7
PC: 12
1 => 0 => 0 (readdata = 0)
Issuing a read

Cycle #8
PC: 16
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

Cycle #9
PC: 20
0 => 0 => 1 (readdata = 0)
*** Stalling! ***

Cycle #10
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***

Cycle #11
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***
Data received:<PHONE_NUMBER>

Cycle #12
PC: 20
0 => 0 => 0 (readdata = 0)
*** Stalling! ***

Cycle #13
PC: 20
0 => 0 => 0 (readdata = 0)

Cycle #14
PC: 24
0 => 0 => 0 (readdata =<PHONE_NUMBER>)

Cycle #15
PC: 28
0 => 0 => 0 (readdata = 0)

This corresponds with a lw t0, 0x400(zero) instruction entering the mem
stage, being delayed for five cycles (the configured latency), and
continuing on with execution.
The third line of each cycle printout (x => x => x) corresponds with the
wbcontrol.toreg signal in the id_ex, ex_mem, and mem_wb registers
respectively. The readdata corresponds with mem_wb.readdata.
The main issue is that at cycle #9
https://github.com/jlpteaching/dinocpu/pull/9 (a stalling cycle), the
desired toreg signal, 1, is located in mem_wb, so the CPU will write back
the contents of readdata, which is 0. At cycle #14
https://github.com/jlpteaching/dinocpu/pull/14, mem_wb.readdata is set
to 0xFFFFFFFF, but toreg is 0 in mem_wb. So the readdata is lost entirely.
Ideally I must be able to freeze ex_mem as so:
...

Cycle #7
PC: 12
1 => 0 => 0 (readdata = 0)
Issuing a read

Cycle #8
PC: 16
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

Cycle #9
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

Cycle #10
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***

Cycle #11
PC: 20
0 => 1 => 0 (readdata = 0)
*** Stalling! ***
Data received:<PHONE_NUMBER>

Cycle #12
PC: 20
*** Stalling! ***
0 => 1 => 0 (readdata = 0)

Cycle #13
PC: 20
0 => 1 => 0 (readdata = 0)

Cycle #14
PC: 24
0 => 0 => 1 (readdata =<PHONE_NUMBER>)

Cycle #15
PC: 28
0 => 0 => 0 (readdata = 0)

Cycle #16

Which would synchronize the readdata and toreg signals properly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jlpteaching/dinocpu/pull/82?email_source=notifications&email_token=AAA2YHHY2VF6BQSB5QVINRTQCFWHBA5CNFSM4IGOW5K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3G4LVQ#issuecomment-516802006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA2YHG3RYMGGLWBC5FVY33QCFWHBANCNFSM4IGOW5KQ
.

--
Jason Lowe-Power (he/him/his)
Assistant Professor, Computer Science Department
University of California, Davis
3049 Kemper Hall
https://arch.cs.ucdavis.edu/

Commit history rebased to stash away code for the non-combin memory, the PR should only involve the combinational memory except for the pipeline/bus IO commit.
I'm getting some strange dependency cycle/StackOverflowError that seems to happen randomly, but I'm positive all of the tests should pass after this force push.

@powerjg, seems like the Chisel snapshots updated and now there's a dependency desync. Could you perhaps look at it? The only thing preventing this PR from being merged is a compilation error due to what I assume was an updated Chisel snapshot.

There are actually two issues. First, treadle was updated. I made the required changes to the replrunner to compile. Then, there's an issue with the output directory. I'm seeing the following:
[error] (run-main-1) firrtl.options.OptionsException: Exactly one target directory must be specified, but found `test_run_dir/pipelined/add1, test_run_dir/pipelined/add1` specified via:
[error]     - explicit target directory: -td, --target-dir, TargetDirAnnotation
[error]     - fallback default value
[error] firrtl.options.OptionsException: Exactly one target directory must be specified, but found `test_run_dir/pipelined/add1, test_run_dir/pipelined/add1` specified via:
[error]     - explicit target directory: -td, --target-dir, TargetDirAnnotation
[error]     - fallback default value

I found this: https://groups.google.com/forum/#!topic/chisel-users/SgB7M65F4Ow
If you comment out line 19 of CPUTesterDriver.scala things seem to work, but it makes a mess in the CWD.
PS: There's a bunch of warnings in configuration.scala. I'm not sure what they mean.

Looks great to me! Please rebase then merge!
PS: Could you open an issue about the output directory for the tester?


Possible issue with "compressed: true"

https://github.com/D-Technologies/EthereumKit/blob/58bb34623a9d0cdd14eebe9f58a559956900f166/EthereumKit/Key/HDPublicKey.swift#L12
Hi, I am not sure if it is correct that "compressed: true" is used in this place. Could it be a potential issue, or should it be like that?

Looks like its okay here. I added some tests on HDPublicKey extended() method #136 . You have to use compressed public key for creating extended public key. It is defined in BIP32.

Good, thanks. Would be also good to include link to some test vectors used in your unit tests.
I haven't found your generated keys from #136 PR in BIP32 spec test vectors. (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

@sche Yes you are right. I added extra BIP32 key derivation tests based on vectors in BIP32 spec. #137


BatchNorm Issue

mxnet's BatchNorm doesn't seem to modify my input when used which is incorrect. Could someone take a look at the code below?
>>> from mxnet import gluon, nd
>>> import mxnet as mx
>>> import numpy as np
>>> def mx_DNN():
...     mx_DNN = gluon.nn.Sequential()
...     with mx_DNN.name_scope():
...         mx_DNN.add(
...             gluon.nn.BatchNorm(momentum=0.1, epsilon=1e-5, center=True, scale=True)
...         )
...     mx_DNN.collect_params().initialize(mx.init.Normal(0.02))
...     return mx_DNN
...
>>> mxnet_DNN = mx_DNN()
>>> data = nd.array([[1.5, 3.0], [-2.1, 2.1]])
>>> mxnet_DNN(data)

[[ 1.4999925  2.999985 ]
 [-2.0999894  2.0999894]]
<NDArray 2x2 @cpu(0)>

Environment:
Python 3.7.3
[GCC 7.3.0] :: Anaconda, Inc. on linux
mxnet-cu92==1.4.1

Thanks!

The default mode is testing, so the mean is 0, and the std is 1.
The following code is in the training mode.
with mx.autograd.record():
mxnet_DNN(data)

@econti Did wkcn help you resolve your problem? If so, please close the issue. Thanks

Yes, thank you @wkcn!


[LSM] Move LSM Token transfer to end blocker

Closes: #XXX
Context and purpose of the change
Previously, if there was a timeout when transferring the LSM token to the host zone, it was retried immediately in the transfer callback. However, at this point in the code, the deposit account has not yet had the LSM token refunded yet, which will cause an insufficient balance error when trying to submit this transfer. The refund does not happen until it moves onto the Transfer module (which is the next module in the middleware stack).
Additionally, bundling IBC transfer with the callback in the first place adds unwanted complexity when it comes to gracefully handling errors (it was flagged as a TODO to consider separating these).
As a result, the actual transfer submission has moved to the endblocker, similar to how the detokenization works.
Brief Changelog

Added status TRANSFER_QUEUE to LSMTokenDeposits
Added end blocker function TransferAllLSMDeposits to loop queued deposit records and submit the IBC transfer
Updated LSMLiquidStake transaction to simply add the record in status TRANSFER_QUEUE instead of submitting the transfer
Updated transfer callback to set the record back to status TRANSFER_QUEUE instead of resubmitting the transfer

Author's Checklist
I have...

[ ] Run and PASSED locally all GAIA integration tests
[ ] If the change is contentful, I either:

[ ] Added a new unit test OR
[ ] Added test cases to existing unit tests

[ ] OR this change is a trivial rework / code cleanup without any test coverage

If skipped any of the tests above, explain.

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] manually tested (if applicable)
[ ] confirmed the author wrote unit tests for new logic
[ ] reviewed documentation exists and is accurate

Documentation and Release Note

[ ] Does this pull request introduce a new feature or user-facing behavior changes?
[ ] Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md?
[ ] This pull request updates existing proto field values (and require a backend and frontend migration)?
[ ] Does this pull request change existing proto field names (and require a frontend migration)?
How is the feature or change documented?

[ ] not applicable
[ ] jira ticket XXX
[ ] specification (x/<module>/spec/)
[ ] README.md
[ ] not documented

The refund does not happen until it moves onto the Transfer module (which is the next module in the middleware stack).
In the current implementation (before this PR is merged), when does the refund happen, is it the same tx as the attempt to resubmit the transfer? If so, the main issue is that, in one tx, we first attempt to resubmit the transfer, then lower down the middleware stack get the refund?

Yeah that's exactly it.
The way to think about it is this is all one large OnAckPacket transaction that goes down the stack from autopilot to records to transfer. So we wind up having:

autopilot: does nothing
records: attempts to resubmit packet and fails because the tokens had been burned when it was first submitted
transfer: refunds tokens (but we never get here cause the above fails)

lgtm


Pylint false positive: no name in module

Is there a linter plugin to install, or is the module improperly configured for pylint? Functionally this code works perfectly, and intellisense can see that it's fine.

So intellisense is fine, the problem is on the pylint side, try ask pylint for help: https://pylint.readthedocs.io/en/latest/contact.html


4 byte alignment for entry address of trap handler

rCore registers trap handler here:
https://github.com/rcore-os/rCore/blob/master/kernel/src/arch/riscv/interrupt.rs#L19
it would be better to add 4 byte alignment after:
https://github.com/rcore-os/rCore/blob/master/kernel/src/arch/riscv/boot/trap.asm#L118
such as .align 4
otherwise, writing to stvec might be ignored

In fact, without RISC-V Compressed Instructions enabled, instruction are aligned by 4 naturally. So this is not a problem in fact.

seems like rCore is using these two json files, which enable compress feature
https://github.com/rcore-os/rCore/blob/master/kernel/targets/riscv64.json
https://github.com/rcore-os/rCore/blob/master/kernel/targets/riscv32.json

Oh, I missed that point.


Only upload using ingest processes

Maybe put the filter in the controller.py file? Also use executor enum


Bootstrap V4 Alpha checkbox fixes

This is based on https://github.com/bootstrap-ruby/rails-bootstrap-forms/pull/299 and adds support for the changed class names for checkboxes in Bootstrap v4 alpha.
It also relates to https://github.com/bootstrap-ruby/rails-bootstrap-forms/issues/268 but, I don't see how it'll be possible to easily support Bootstrap v3 & v4 in the same version of the gem.

Perhaps it would make sense to merge this into a v4-alpha working branch on this repo? Then others could continue submitting fixes for v4 up until its non-beta release.

@trammel @antpaw looks like we ended up duplicating this work. It doesn't look like there's anything new against the bootstrap-v4 branch, Can we close this?


Added "Category button" setting

Hi!
I'm trying again with the alternative controls!
I added a "Category button" setting in "Other settings", I think it'll be better than maintaining a fork just for that.
It's still the up/down arrow alternative.
Let me know if I should change anything, or if you just don't want this feature at all !

Sorry for the big one commit, the important stuff is lines 14811-14821.
For the rest, I just reproduced the code in use for other settings.

Hi again,
Thanks for sharing the updated approach.
I'm really sorry, but I'm a bit reluctant to add it at this time, maybe in the future.
If I keep on working on the app I may need the up and down buttons for, a grid/list view, so don't really want to add a feature if it's going to conflict or be removed down the line.
Grid view is something blacksheep is working on for HexFlow custom, I'll see how he approaches it once it's released.
I really appreciate your input over the last month, it's been great, I hope this doesn't discourage you.

I totally understand, there's no problem!
I'll keep updating my fork!


added EvilQuest queries

Part of a series of pull requests, placing queries from the TA reports in the repo.
Some of the column names may be outdated, as some of the reports are quite old.
Others in the series:
#145, #155, #163, #165,
#168, #169, #170, #172,
#173 , #174, #175, #177,
#178, #182, #183, #190,
#191, #192, #195, #196
#198, #202, #203, #204
#205, #206, #207, #208
#209, #214, #215, #218
#229, #230, #231

I updated several instances of "contains" to "has" to optimize the queries


Short solution needed: "How to install Xvfb on Ubuntu UBUNTU_VERSION" (xvfb)

Please help us write most modern and shortest code solution for this issue:
How to install Xvfb on Ubuntu UBUNTU_VERSION (technology: xvfb)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments explain solution.
Link to this issue in comments of pull request.

How to install Xvfb on Ubuntu UBUNTU_VERSION


cloud trail indexers

owners, cross account perms, etc. we currently do this as a set of standalone scripts, but should incorporate.

merged a basic version in #573


Added white and transparent background images

What does this PR do?
Adds logo images with white and transparent background.

Any background context you want to provide?
Addresses issue #2

Screenshots and/or Live Demo

@adityaketkar We would need the logos as well.

We won't put these images in the extension file because it would unnecessarily increase the extension size. Anyways I have updated the og-image on chrome webstore and product hunt. Thanks for designing these images. cc: @allcontributorscli

We won't put these images in the extension file because it would unnecessarily increase the extension size. Anyways I have updated the og-image on chrome webstore and product hunt. Thanks for contributing 🚀

@all-contributors please add adityaketkar for design


Invalid URL error

Just tried to install it on HA 2021.7
Looks like there is a conflict with nabucasa and just one of my google nest. Not sure why the other one is not showing up.
I only get the nabucasa errors when I have the integration turned on. I am including a screenshot of Wireshark showing the conversation.  I am assuming the URL is invalid because of the error thrown.
Also, notice my GW-1000 version is 1.6.8
Did they change something on you?
2021-07-13 15:51:05 INFO (MainThread) [hass_nabucasa.google_report_state] Connected
2021-07-13 15:51:24 WARNING (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Heartbeat timeout, resetting connection
2021-07-13 15:51:24 INFO (Thread-7) [pychromecast.controllers] Receiver:channel_disconnected
2021-07-13 15:51:54 ERROR (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Failed to connect to service ServiceInfo(type='host', data=('<IP_ADDRESS>', 8009)), retrying in 5.0s
2021-07-13 15:51:54 INFO (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Connection reestablished!
2021-07-13 15:52:38 INFO (SyncWorker_1) [homeassistant.loader] Loaded ssdp from homeassistant.components.ssdp
2021-07-13 15:52:48 WARNING (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Heartbeat timeout, resetting connection
2021-07-13 15:52:48 INFO (Thread-7) [pychromecast.controllers] Receiver:channel_disconnected
2021-07-13 15:53:18 ERROR (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Failed to connect to service ServiceInfo(type='host', data=('<IP_ADDRESS>', 8009)), retrying in 5.0s
2021-07-13 15:54:14 INFO (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Connection reestablished!
2021-07-13 15:54:44 WARNING (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Heartbeat timeout, resetting connection
2021-07-13 15:54:44 INFO (Thread-7) [pychromecast.controllers] Receiver:channel_disconnected
2021-07-13 15:54:59 INFO (Thread-7) [pychromecast.socket_client] [Kitchen speaker(<IP_ADDRESS>):8009] Connection reestablished!
2021-07-13 15:55:31 INFO (MainThread) [homeassistant.setup] Setting up ecowitt
2021-07-13 15:55:31 INFO (MainThread) [homeassistant.setup] Setup of domain ecowitt took 0.0 seconds
2021-07-13 15:55:48 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 314, in data_received
messages, upgraded, tail = self._request_parser.feed_data(data)
File "aiohttp/_http_parser.pyx", line 546, in aiohttp._http_parser.HttpParser.feed_data
aiohttp.http_exceptions.InvalidURLError: 400, message='invalid URL'

Does anyone have a sword I can borrow?
It was the '/' in the path. Sorry for the confusion.


Problems with OpenMPI (4.0.1) on macOS/macports

Describe the bug
I've installed amuse using the new "pip install" method, with prerequisites installed using macports, and using python3. I can run simple amuse scripts, but as soon as I need anything that needs a new worker, I get a segmentation fault:
[snowdrop:77107] *** Process received signal ***
[snowdrop:77107] Signal: Segmentation fault: 11 (11)
[snowdrop:77107] Signal code:  (0)
[snowdrop:77107] Failing at address: 0x0
[snowdrop:77107] *** End of error message ***
Traceback (most recent call last):
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/channel.py", line 1734, in accept_worker_connection
return server_socket.accept()
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/socket.py", line 205, in accept
fd, addr = self._accept()
socket.timeout: timed out
I have OMP_NUM_THREADS set to 4 (but the error also happens if it is set to 1) and OMPI_MCA_rmaps_base_oversubscribe is 1.
For installation, I followed the instructions from Steven at https://github.com/rieder/amuse/wiki/Installation-on-macOS-with-Python3 except that I did not use the virtual environment.
Environment (please complete the following information):

OS and version: macOS High Sierra 10.13.6
Compiler: gcc7

Update (which may be helpful) -- I tried to use the virtual environment to see if that made any difference. It still crashes in the same way, but I got a different error output which might be helpful:
[snowdrop:84343] *** Process received signal ***
[snowdrop:84343] Signal: Segmentation fault: 11 (11)
[snowdrop:84343] Signal code:  (0)
[snowdrop:84343] Failing at address: 0x0
[snowdrop:84343] *** End of error message ***
[snowdrop.physics.mcmaster.ca:84340] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c at line 532
[snowdrop.physics.mcmaster.ca:84340] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c at line 166
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node (-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127) instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***    and potentially your MPI job)
[snowdrop.physics.mcmaster.ca:84340] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!

ok, for the can you try in a python command line (the actual code is not important, sse is just one of the simplest):
from amuse.community.sse.interface import SSE
s=SSE()
# and the following variants:
#s=SSE(redirection="none")
#s=SSE(channel_type="sockets")
#s=SSE("debugger="gdb") # give command run in the debugger window that opens, if it opens

and see if any work/ give more hints in the output

Hi Inty,
All 4 variants gave the same error. Here's the full screen dump from
s=SSE() but the others are the same.

s=SSE()
[snowdrop:84677] *** Process received signal ***
[snowdrop:84677] Signal: Segmentation fault: 11 (11)
[snowdrop:84677] Signal code:  (0)
[snowdrop:84677] Failing at address: 0x0
[snowdrop:84677] *** End of error message ***
Traceback (most recent call last):
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/channel.py",
line 1734, in accept_worker_connection
    return server_socket.accept()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/socket.py",
line 205, in accept
    fd, addr = self._accept()
socket.timeout: timed out

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "", line 1, in
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/community/sse/interface.py",
line 211, in init
    InCodeComponentImplementation.init(self,
SSEInterface(**options), **options)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/community/sse/interface.py",
line 26, in init
    CodeInterface.init(self, name_of_the_worker="sse_worker",
**options)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/core.py",
line 752, in init
    self._start(name_of_the_worker = name_of_the_worker, **options)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/core.py",
line 780, in _start
    self.channel.start()
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/channel.py",
line 1810, in start
    self.socket, address = self.accept_worker_connection(server_socket,
self.process)
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/amuse/rfi/channel.py",
line 1738, in accept_worker_connection
    raise exceptions.CodeException('could not connect to worker, worker
process terminated')
amuse.support.exceptions.CodeException: could not connect to worker,
worker process terminated
When I try within my virtual environment, I get the same message as I
posted on the github error yesterday::

s=SSE()
[snowdrop:84834] *** Process received signal ***
[snowdrop:84834] Signal: Segmentation fault: 11 (11)
[snowdrop:84834] Signal code:  (0)
[snowdrop:84834] Failing at address: 0x0
[snowdrop:84834] *** End of error message ***
[snowdrop.physics.mcmaster.ca:84831] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 532
[snowdrop.physics.mcmaster.ca:84831] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
  --> Returned value Unable to start a daemon on the local node (-127)
instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
  --> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***    and potentially your MPI job)
[snowdrop.physics.mcmaster.ca:84831] Local abort before MPI_INIT
completed completed successfully, but am not able to aggregate error
messages, and not able to guarantee that all other processes were killed!
I don't know if this is helpful, but at least it is consistent. I guess?
Cheers,
alison
On 2019-07-18 5:37 a.m., ipelupessy wrote:

ok, for the can you try in a python command line (the actual code is
not important, sse is just one of the simplest):
|from amuse.community.sse.interface import SSE s=SSE() # and the
following variants: #s=SSE(redirection="none")
#s=SSE(channel_type="sockets") #s=SSE("debugger="gdb") # give command
run in the debugger window that opens, if it opens |
and see if any work/ give more hints in the output
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS477L6VYMPRVIHSJ3TQAA2TZA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2H5JPQ#issuecomment-512742590,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVYVS6R7MEB73JG7JYGYL3QAA2TZANCNFSM4IEUP4ZQ.

--
Alison Sills
Professor
Department of Physics & Astronomy

Can you try if MPI and mpi4py by themselves are bythemselves working ok, the command
python -c "from mpi4py import MPI;print(MPI.Is_initialized())"

should return True

It seems to be an error with the MPI installation: python -c "from mpi4py import MPI" gives me the long ORTE... error I pasted above.
I have tried completely wiping my entire macports installation (of everything) and starting again; I've tried manually deleting files in /opt/local/lib and other related directories, and nothing much works. Is there a nice little test that I can run without python and mpi4py that will let me test the MPI installation directly?

the simplest test is
mpirun -n 2 hostname

to run hostname two times ( can be some other simple command)
next would be to compile and run a simple MPI hello world
(e.g. https://mpitutorial.com/tutorials/mpi-hello-world/)

Well, the simple test fails with a segmentation fault. Google suggests that I have conflicting versions of openMPI on my computer, which seems plausible. But I can't find anything other than the latest MacPorts install (which goes away when I remove it, as expected). Does anyone have any suggestions about where to look?

hi Alison,
can you check which mpiexec you're using ("ls -l which mpiexec")?
steven

Op 9 aug. 2019 om 22:02 heeft asills1<EMAIL_ADDRESS>het volgende geschreven:

Well, the simple test fails with a segmentation fault. Google suggests that I have conflicting versions of openMPI on my computer, which seems plausible. But I can't find anything other than the latest MacPorts install (which goes away when I remove it, as expected). Does anyone have any suggestions about where to look?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

lrwxr-xr-x  1 root  wheel  35 Aug  9 15:12 /opt/local/bin/mpiexec -> /opt/local/bin/mpiexec-openmpi-gcc7
MacPorts, installed today(not that it made a difference), and then 'sudo port select --set mpi openmpi-gcc7-gfortran' as recommended.
mpirun has a similar path.

That should be correct.
Are mpicc and the other compilers pointing to a similar path?
What does "port installed | grep mpi" say?

Success -- of a sort.
After comparing various different AMUSE installations on different machines, I tried installing mpich instead of openmpi on the problematic computer. Voila, it works. I can now install and run amuse-12 using macports (gcc7 versions of the prerequisites) and pip. BUT I can't do "pip install amuse" because three community codes don't install: fi, phantom, & brutus. If there's any obvious commonality between those codes and not the 31 others, that might point to whatever it is I've done wrong. The odd thing is that when I had the openmpi prerequisite, everything compiled. But since it didn't run, that's not too helpful.
I still have no idea why openmpi didn't work.

Hi Alison,
great to hear it works now, but definitely there are a few odd things there...
I'm surprised at your mention of phantom - it is not a requirement of the AMUSE package, so it shouldn't be installed (unless you were trying to do so manually?). Anyway, that one is very much in testing (though it "works for me").
Fi requires the fftw3 libraries, and Brutus I think also has some additional dependencies. But you mention them compiling correctly before, so that's odd. It could be that macports built libraries with an incompatible compiler?
I'm not sure how to proceed with debugging your installation, perhaps you could send the list of macports packages (and their variants!) as installed on your computer? I think you get that list with "port installed".

Hi Steven,
Yes, I was just going through each of the packages manually. When 'pip
install amuse' fails, it seems to completely fail for me, and nothing at
all is installed. So I have to do 'pip install amuse-framework' and then
'pip install amuse-CODE' for each code. I was looking at a list that I
found on pypi.org and tried to install everything called amuse-SOMETHING
except for amuse-distributed and amuse-tests.
I have basically followed your instructions on your github wiki, except
replace openmpi-gcc7 with mpich-gcc7. All necessarily libraries should
be installed, and (I think!) built with gcc7. I've attached the list of
ports with variants.
It's not crucial that we get this sorted out, but it would be nice to be
able to use Fi.
Cheers,
alison
On 2019-08-16 4:32 p.m., Steven Rieder wrote:

Hi Alison,
great to hear it works now, but definitely there are a few odd things
there...
I'm surprised at your mention of phantom - it is not a requirement of
the AMUSE package, so it shouldn't be installed (unless you were
trying to do so manually?). Anyway, that one is very much in testing
(though it "works for me").
Fi requires the fftw3 libraries, and Brutus I think also has some
additional dependencies. But you mention them compiling correctly
before, so that's odd. It could be that macports built libraries with
an incompatible compiler?
I'm not sure how to proceed with debugging your installation, perhaps
you could send the list of macports packages (and their variants!) as
installed on your computer? I think you get that list with "port
installed".
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4KJBTDCRUG37HCKUTQE4FE3A5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PUEZI#issuecomment-522142309,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVYVS3MM7VLAMSJ5WOGFZTQE4FE3ANCNFSM4IEUP4ZQ.

--
Alison Sills
Professor
Department of Physics & Astronomy
The following ports are currently installed:
bzip2 @1.0.7_0
bzip2 @1.0.8_0 (active)
cctools @921_2+llvm80 (active)
cmake @3.15.1_0 (active)
curl @7.65.1_0+ssl (active)
curl-ca-bundle @7.65.1_0 (active)
expat @2.2.7_0 (active)
fftw-3 @3.3.8_0+gcc7 (active)
gcc7 @7.4.0_3 (active)
gcc_select @0.1_8 (active)
gettext @<IP_ADDRESS>_2 (active)
glib2 @2.58.3_0+x11 (active)
gmp @6.1.2_1 (active)
gsl @2.5_1 (active)
hdf5 @1.10.5_0+cxx+gcc7+hl (active)
icu @58.2_2 (active)
isl @0.21_0 (active)
ld64 @3_1+ld64_xcode (active)
ld64-xcode @2_1 (active)
libarchive @3.3.3_1 (active)
libcxx @5.0.1_4 (active)
libedit @20190324-3.1_0 (active)
libffi @3.2.1_0 (active)
libgcc @2.0_2 (active)
libgcc7 @7.4.0_3 (active)
libgcc8 @8.3.0_5 (active)
libgcc9 @9.1.0_2 (active)
libiconv @1.16_0 (active)
libidn2 @2.2.0_0 (active)
libmpc @1.1.0_1 (active)
libpsl @0.21.0-20190419_0 (active)
libunistring @0.9.10_0 (active)
libuv @1.30.1_0 (active)
libxml2 @2.9.9_1 (active)
llvm-8.0 @8.0.0_0 (active)
llvm_select @2_0 (active)
lz4 @1.9.1_0 (active)
lzo2 @2.10_0 (active)
mpfr @4.0.2_0 (active)
mpi-doc @3.3_0 (active)
mpi_select @0.0_3 (active)
mpich-gcc7 @3.3.1_0+fortran (active)
ncurses @6.1_0 (active)
openssl @1.0.2s_0 (active)
pcre @8.43_0 (active)
pip_select @0.1_1 (active)
py36-pip @19.2.1_0 (active)
py36-setuptools @41.0.1_0 (active)
python3_select @0.0_1 (active)
python36 @3.6.9_0 (active)
python_select @0.3_8 (active)
sqlite3 @3.28.0_0
sqlite3 @3.29.0_0 (active)
xar @1.6.1_0 (active)
xz @5.2.4_0 (active)
zlib @1.2.11_0 (active)
zstd @1.4.2_0 (active)

Thanks - the only thing that slightly worries me at first glance is that cctools is using the llvm variant. Can you check what variants 'port variants cctools' says are available? And if there is a gcc7 variant, can you install it with 'port install cctools +gcc7'?
Also, can you show the output of 'port select --summary'?
Finally, can you confirm you're using python 3 and not python 2 for AMUSE?
You're right that if 'pip install amuse' fails for any part, it will currently refuse to install anything. This is because we've set it up to have a hard dependency on each of the packages, so if any of them fails none will be installed. Perhaps we should not do it this way. We're still figuring this out mostly...

Hi Steven,
Here's what it says about cctools:
cctools has the variants:
   llvm50: Use llvm-5.0 for libLTO, llvm-mc, llvm-size, and llvm-nm
     * conflicts with llvm60 llvm70 llvm80 llvmdev xcode
   llvm60: Use llvm-6.0 for libLTO, llvm-mc, llvm-size, and llvm-nm
     * conflicts with llvm50 llvm70 llvm80 llvmdev xcode
   llvm70: Use llvm-7.0 for libLTO, llvm-mc, llvm-size, and llvm-nm
     * conflicts with llvm50 llvm60 llvm80 llvmdev xcode
[+]llvm80: Use llvm-8.0 for libLTO, llvm-mc, llvm-size, and llvm-nm
     * conflicts with llvm50 llvm60 llvm70 llvmdev xcode
   llvmdev: Use llvm-devel for libLTO, llvm-mc, llvm-size, and llvm-nm
     * conflicts with llvm50 llvm60 llvm70 llvm80 xcode
   universal: Build for multiple architectures
     * conflicts with xcode
   xcode: Use Xcode supplied cctools
     * conflicts with universal
I could try the xcode version?
alisonsills(2)port select --summary
Name     Selected            Options
====     ========            =======
cython   cython27            none
gcc      mp-gcc7             mp-gcc7 none
llvm     none                mp-llvm-8.0 none
mpi      mpich-gcc7-fortran  mpich-gcc7-fortran none
pip      pip36               pip36 none
pip2     none                none
pip3     none                pip36 none
python   python27            python27-apple python36 none
python3  python36            python36 none
And yes, python3. I haven't gone back to python2 to test things,
although that was on my list if mpich didn't work.
I think it might make sense to consider a successful installation if at
least 'framework' and perhaps some of the more common codes can be
installed.  But yes, I know it's early days for this!
Cheers,
alison
On 2019-08-16 5:17 p.m., Steven Rieder wrote:

Thanks - the only thing that slightly worries me at first glance is
that cctools is using the llvm variant. Can you check what variants
'port variants cctools' says are available? And if there is a gcc7
variant, can you install it with 'port install cctools +gcc7'?
Also, can you show the output of 'port select --summary'?
Finally, can you confirm you're using python 3 and not python 2 for AMUSE?
You're right that if 'pip install amuse' fails for any part, it will
currently refuse to install anything. This is because we've set it up
to have a hard dependency on each of the packages, so if any of them
fails none will be installed. Perhaps we should not do it this way.
We're still figuring this out mostly...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS6L33AACKPXJRBGXFTQE4KQLA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PXDMQ#issuecomment-522154418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVYVS4M5YNFY6D2NNEX3ODQE4KQLANCNFSM4IEUP4ZQ.

--
Alison Sills
Professor
Department of Physics & Astronomy

This may be related.  I have found that mpi4py fails to load on my macOS, making it impossible to run any AMUSE script.  I assume that I updated some component and now have an incompatibility, but I have tried reinstalling python, openmpi, and mpi4py and the problem persists.  The error is not a subtle one:
% python
Python 2.7.16 (default, Apr  1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

from mpi4py import MPI
[halley:28571] *** Process received signal ***
[halley:28571] Signal: Segmentation fault: 11 (11)
[halley:28571] Signal code:  (0)
[halley:28571] Failing at address: 0x0
[halley:28571] *** End of error message ***
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c at line 532
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the local node in file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node (-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127) instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***    and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed successfully, but am not abl  e to aggregate error messages, and not able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.

Definitely related (i.e. identical to my problem), but try this:
mpirun -n 2 hostname
If you have the same problem I do, then you get another segmentation
fault error and the only solution we've found so far is to ditch openmpi
and replace it with mpich.
So I'm thinking it's not mpi4py but openmpi itself. But this gets above
my pay grade so I'm hoping Inty & Steven can figure out what's up.
Cheers,
alison
On 2019-09-03 11:56 a.m., stevemcmillan wrote:

This may be related. I have found that mpi4py fails to load on my
macOS, making it impossible to run any AMUSE script. I assume that I
updated some component and now have an incompatibility, but I have
tried reinstalling python, openmpi, and mpi4py and the problem
persists. The error is not a subtle one:
% python
Python 2.7.16 (default, Apr 1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
        from mpi4py import MPI
        [halley:28571] *** Process received signal ***
        [halley:28571] Signal: Segmentation fault: 11 (11)
        [halley:28571] Signal code: (0)
        [halley:28571] Failing at address: 0x0
        [halley:28571] *** End of error message ***
        [halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
        Unable to start a daemon on the local node in file
        /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
        at line 532
        [halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
        Unable to start a daemon on the local node in file
        /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
        at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)

*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed
successfully, but am not abl e to aggregate error messages, and not
able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ.

--
Alison Sills
Professor
Department of Physics & Astronomy

Looks like I have your problem:
% mpirun -n 2 hostname
[halley:28957] *** Process received signal ***
[halley:28957] Signal: Segmentation fault: 11 (11)
[halley:28957] Signal code:  (0)
[halley:28957] Failing at address: 0x0
[halley:28957] *** End of error message ***
Segmentation fault (core dumped)
I only see to have the option in mac ports to install openmpi 4.0.1.  Is this something to pursue with th openmpi folks?
Steve
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:02 PM, asills1<EMAIL_ADDRESS>wrote:
Definitely related (i.e. identical to my problem), but try this:
mpirun -n 2 hostname
If you have the same problem I do, then you get another segmentation
fault error and the only solution we've found so far is to ditch openmpi
and replace it with mpich.
So I'm thinking it's not mpi4py but openmpi itself. But this gets above
my pay grade so I'm hoping Inty & Steven can figure out what's up.
Cheers,
alison
On 2019-09-03 11:56 a.m., stevemcmillan wrote:

This may be related. I have found that mpi4py fails to load on my
macOS, making it impossible to run any AMUSE script. I assume that I
updated some component and now have an incompatibility, but I have
tried reinstalling python, openmpi, and mpi4py and the problem
persists. The error is not a subtle one:
% python
Python 2.7.16 (default, Apr 1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from mpi4py import MPI
[halley:28571] *** Process received signal ***
[halley:28571] Signal: Segmentation fault: 11 (11)
[halley:28571] Signal code: (0)
[halley:28571] Failing at address: 0x0
[halley:28571] *** End of error message ***
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 532
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed
successfully, but am not abl e to aggregate error messages, and not
able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ.

--
Alison Sills
Professor
Department of Physics & Astronomy
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=AAPFB3UEF2OEMLNFSCINTSLQH2DCTA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YWKGY#issuecomment-527525147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPFB3WVZRVJRZ6O53XUNM3QH2DCTANCNFSM4IEUP4ZQ.

And I concur that it isn’t mpi4py.  I ditched my old /opt and did a clean install of just gcc7 (7.4.0) and openmpi (4.0.1).  Then
% mpirun -n 2 hostname
[halley:61771] *** Process received signal ***
[halley:61771] Signal: Segmentation fault: 11 (11)
[halley:61771] Signal code:  (0)
[halley:61771] Failing at address: 0x0
[halley:61771] *** End of error message ***
Segmentation fault (core dumped)
I’ll try with mpich.
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:07 PM, Steve McMillan<EMAIL_ADDRESS>wrote:
Looks like I have your problem:
% mpirun -n 2 hostname
[halley:28957] *** Process received signal ***
[halley:28957] Signal: Segmentation fault: 11 (11)
[halley:28957] Signal code:  (0)
[halley:28957] Failing at address: 0x0
[halley:28957] *** End of error message ***
Segmentation fault (core dumped)
I only see to have the option in mac ports to install openmpi 4.0.1.  Is this something to pursue with th openmpi folks?
Steve
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:02 PM, asills1<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Definitely related (i.e. identical to my problem), but try this:
mpirun -n 2 hostname
If you have the same problem I do, then you get another segmentation
fault error and the only solution we've found so far is to ditch openmpi
and replace it with mpich.
So I'm thinking it's not mpi4py but openmpi itself. But this gets above
my pay grade so I'm hoping Inty & Steven can figure out what's up.
Cheers,
alison
On 2019-09-03 11:56 a.m., stevemcmillan wrote:

This may be related. I have found that mpi4py fails to load on my
macOS, making it impossible to run any AMUSE script. I assume that I
updated some component and now have an incompatibility, but I have
tried reinstalling python, openmpi, and mpi4py and the problem
persists. The error is not a subtle one:
% python
Python 2.7.16 (default, Apr 1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from mpi4py import MPI
[halley:28571] *** Process received signal ***
[halley:28571] Signal: Segmentation fault: 11 (11)
[halley:28571] Signal code: (0)
[halley:28571] Failing at address: 0x0
[halley:28571] *** End of error message ***
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 532
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed
successfully, but am not abl e to aggregate error messages, and not
able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268 https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ>.

--
Alison Sills
Professor
Department of Physics & Astronomy
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=AAPFB3UEF2OEMLNFSCINTSLQH2DCTA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YWKGY#issuecomment-527525147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPFB3WVZRVJRZ6O53XUNM3QH2DCTANCNFSM4IEUP4ZQ.

Incidentally, does anyone know why sudo port uninstall openmpi doesn’t remove the compilers, mpirun, or the libraries…?
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:46 PM, Steve McMillan<EMAIL_ADDRESS>wrote:
And I concur that it isn’t mpi4py.  I ditched my old /opt and did a clean install of just gcc7 (7.4.0) and openmpi (4.0.1).  Then
% mpirun -n 2 hostname
[halley:61771] *** Process received signal ***
[halley:61771] Signal: Segmentation fault: 11 (11)
[halley:61771] Signal code:  (0)
[halley:61771] Failing at address: 0x0
[halley:61771] *** End of error message ***
Segmentation fault (core dumped)
I’ll try with mpich.
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:07 PM, Steve McMillan<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Looks like I have your problem:
% mpirun -n 2 hostname
[halley:28957] *** Process received signal ***
[halley:28957] Signal: Segmentation fault: 11 (11)
[halley:28957] Signal code:  (0)
[halley:28957] Failing at address: 0x0
[halley:28957] *** End of error message ***
Segmentation fault (core dumped)
I only see to have the option in mac ports to install openmpi 4.0.1.  Is this something to pursue with th openmpi folks?
Steve
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:02 PM, asills1<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Definitely related (i.e. identical to my problem), but try this:
mpirun -n 2 hostname
If you have the same problem I do, then you get another segmentation
fault error and the only solution we've found so far is to ditch openmpi
and replace it with mpich.
So I'm thinking it's not mpi4py but openmpi itself. But this gets above
my pay grade so I'm hoping Inty & Steven can figure out what's up.
Cheers,
alison
On 2019-09-03 11:56 a.m., stevemcmillan wrote:

This may be related. I have found that mpi4py fails to load on my
macOS, making it impossible to run any AMUSE script. I assume that I
updated some component and now have an incompatibility, but I have
tried reinstalling python, openmpi, and mpi4py and the problem
persists. The error is not a subtle one:
% python
Python 2.7.16 (default, Apr 1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from mpi4py import MPI
[halley:28571] *** Process received signal ***
[halley:28571] Signal: Segmentation fault: 11 (11)
[halley:28571] Signal code: (0)
[halley:28571] Failing at address: 0x0
[halley:28571] *** End of error message ***
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 532
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed
successfully, but am not abl e to aggregate error messages, and not
able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268 https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ>.

--
Alison Sills
Professor
Department of Physics & Astronomy
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=AAPFB3UEF2OEMLNFSCINTSLQH2DCTA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YWKGY#issuecomment-527525147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPFB3WVZRVJRZ6O53XUNM3QH2DCTANCNFSM4IEUP4ZQ.

Yup, mpich works.  I note that the installed version is 3.3.3.
Steve
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:46 PM, Steve McMillan<EMAIL_ADDRESS>wrote:
And I concur that it isn’t mpi4py.  I ditched my old /opt and did a clean install of just gcc7 (7.4.0) and openmpi (4.0.1).  Then
% mpirun -n 2 hostname
[halley:61771] *** Process received signal ***
[halley:61771] Signal: Segmentation fault: 11 (11)
[halley:61771] Signal code:  (0)
[halley:61771] Failing at address: 0x0
[halley:61771] *** End of error message ***
Segmentation fault (core dumped)
I’ll try with mpich.
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:07 PM, Steve McMillan<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Looks like I have your problem:
% mpirun -n 2 hostname
[halley:28957] *** Process received signal ***
[halley:28957] Signal: Segmentation fault: 11 (11)
[halley:28957] Signal code:  (0)
[halley:28957] Failing at address: 0x0
[halley:28957] *** End of error message ***
Segmentation fault (core dumped)
I only see to have the option in mac ports to install openmpi 4.0.1.  Is this something to pursue with th openmpi folks?
Steve
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS><EMAIL_ADDRESS>
On Sep 3, 2019, at 12:02 PM, asills1<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Definitely related (i.e. identical to my problem), but try this:
mpirun -n 2 hostname
If you have the same problem I do, then you get another segmentation
fault error and the only solution we've found so far is to ditch openmpi
and replace it with mpich.
So I'm thinking it's not mpi4py but openmpi itself. But this gets above
my pay grade so I'm hoping Inty & Steven can figure out what's up.
Cheers,
alison
On 2019-09-03 11:56 a.m., stevemcmillan wrote:

This may be related. I have found that mpi4py fails to load on my
macOS, making it impossible to run any AMUSE script. I assume that I
updated some component and now have an incompatibility, but I have
tried reinstalling python, openmpi, and mpi4py and the problem
persists. The error is not a subtle one:
% python
Python 2.7.16 (default, Apr 1 2019, 14:50:41)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from mpi4py import MPI
[halley:28571] *** Process received signal ***
[halley:28571] Signal: Segmentation fault: 11 (11)
[halley:28571] Signal code: (0)
[halley:28571] Failing at address: 0x0
[halley:28571] *** End of error message ***
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 532
[halley.local:28570] [[INVALID],INVALID] ORTE_ERROR_LOG:
Unable to start a daemon on the local node in file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_openmpi/openmpi-gcc7/work/openmpi-4.0.1/orte/mca/ess/singleton/ess_singleton_module.c
at line 166

It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS

It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[halley.local:28570] Local abort before MPI_INIT completed completed
successfully, but am not abl e to aggregate error messages, and not
able to guarantee that all other processes were killed!
I am running gcc 7.4.0, python 2.7, openmpi 4.0.1, and mpi4py 3.0.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268 https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=ALVYVS4PXQA25JQ2RMPLAMDQH2CKNA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YVTXA#issuecomment-527522268>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ https://github.com/notifications/unsubscribe-auth/ALVYVSZY4SQGAENRQLNJSSTQH2CKNANCNFSM4IEUP4ZQ>.

--
Alison Sills
Professor
Department of Physics & Astronomy
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=AAPFB3UEF2OEMLNFSCINTSLQH2DCTA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YWKGY#issuecomment-527525147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPFB3WVZRVJRZ6O53XUNM3QH2DCTANCNFSM4IEUP4ZQ.

Incidentally, does anyone know why sudo port uninstall openmpi doesn’t remove the compilers, mpirun, or the libraries…?

That seems very wrong. Perhaps there are multiple versions installed that need uninstalling by version? Check with ”port installed | grep openmpi”.

You were right — I had multiple versions floating around...
Stephen L. W. McMillan
Department Head and Professor of Physics, Drexel University
+1<PHONE_NUMBER>/2723, FAX +1<PHONE_NUMBER><EMAIL_ADDRESS>
On Sep 3, 2019, at 1:07 PM, Steven Rieder<EMAIL_ADDRESS>wrote:

Incidentally, does anyone know why sudo port uninstall openmpi doesn’t remove the compilers, mpirun, or the libraries…?

That seems very wrong. Perhaps there are multiple versions installed that need uninstalling by version? Check with ”port installed | grep openmpi”.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/amusecode/amuse/issues/456?email_source=notifications&email_token=AAPFB3UCZD4W2IHAVSQ4IPTQH2KTJA5CNFSM4IEUP4Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y4OSI#issuecomment-527550281, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPFB3UUJIG5U2YFYGVVEPDQH2KTJANCNFSM4IEUP4ZQ.

I cannot reproduce this on my mac...
I tested both openmpi-gcc7 and openmpi-gcc8 (v4.0.1 in both cases), both work without any problems (on macOS Mojave).
So I am still uncertain about the underlying problem of this...

Renamed this issue since we do know the origin of the initially reported problems now.

close, since an old issue; open new issue if necessary


Handle setting innerHTML to the empty string

I have looked at issue #1779, and the problem seems to have been in the innerHTML implementation. The setInnerHTML function includes a specific if-condition rejecting the empty string as input, while browsers seem to handle it. With the if-condition removed the output has been consistent with the way browsers behave, during my limited testing.
I am naturally a bit wary about simply removing a condition since someone must've put it there for a reason in the first place, but perhaps it no longer applies as the codebase has changed. Regardless, I'd appreciate if someone knowing more about the intricacies of innerHTML would chime in.

This is great. I have sufficient confidence in our test coverage that I'm happy to accept this. My guess is that the empty string check was copied from jsdom.env where we treat empty strings specially?
I'll merge this and do a release when I have some free time not at work, so at worst by Saturday.


Upgrade opentelemetry collector app and chart version

Chart updates :

Default resources decreased - cpu is now 256m instead of 1core, and memory is now 512Mi instead of 2Gi [we set the limits to ourselves so its ok]
they added support for running the collector as a statefulset

App version updates:

They deprecated some configs that we didnt use , and added some new features, not supposed to affect us and to break something

@oded-dd do you mean pull their image and push it to our dockerhub public repo [coralogixrepo] ?
what is the goal of doing it ?

Merging this, will take care of the image separately


Remove terraform.tfvars from example

What does this PR do?

This change removes terraform.tfvars from examples/existing-cluster-with-base-and-infra, and uses variables.tf for any defaults.
Motivation

When following the instructions HERE it directs the reader to set TF_VAR_xxxx environment variables. However, since there is already terraform.tfvars, the tfvars file will take precedent over environment variables per the terraform docs. This results in aws_region, eks_cluster_id, and managed_prometheus_workspace_id being unable to be set.
More

[ ] Yes, I have tested the PR using my local account setup  (Provide any test evidence report under Additional Notes)
[ ] Yes, I ran pre-commit run -a with this PR
[ ] Yes, I have added a new example under examples to support my PR (when applicable)
[ ] Yes, I have updated the Pages for this feature

Note: Not all the PRs required examples and docs.
For Moderators

[ ] E2E Test successfully complete before merge?

Additional Notes

Alternatively, we could change the directions on the site. Open to suggestions!

Thanks @gjohnson, can you run pre-commit so the example TF doc will be updated? We'll need to align the AMP doc as well https://docs.aws.amazon.com/prometheus/latest/userguide/obs_accelerator.html


Data translation problem

Is there any ways to tranlate exported logger into another language?
like chinese into english because I need to import it into other website

Do you mean excel file or JSON file? You need to replace the role name and weapon name in batch. This tool does not have this function.


Add unfriend button for delete contacts inside contact page on OwnCloud

add js methods for unfriend contact, styles, routes, add contactsController.php


3.0 - Get agave account creation permission from TACC

Asked on the TACC Slack team.

Didn't go so well.  Going to use TACC's installation for a while and force our users to get a TACC account. :/
Eventually, TACC will have the installation process down to something that isn't horrible, and we can deploy our own Agave instance.


Migrate Store Locator Widget Samples

Migrated all store locator widget samples except Baidu Maps sample

:tada: This PR is included in version 1.16.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update @apollo/client and fix mocked requests and responses on tests

From PR #1005 the CI checks are failing from this new apollo client version. Looking at the logs you can see that some unit tests fails with a message like this:
Missing field 'createdAt' while writing result {
  "content": "A very unique test comment!",
  "submissionId": 104,
  "author": {
    "name": "fake user",
    "username": "fakeusername"
  }
}

Which means that Apollo client is now type-checking the mocked request and response objects we have on our tests.

This issue doesn't occur anymore. But good to reference (tag).