feat(OGBEE-81): Implement push_event and hypertable init (OGBEE-89)

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#136  👈
#135
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ABCxFF and the rest of your teammates on  Graphite


UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-11: ordinal not in range(128)

https://github.com/thebigmunch/gmusicapi-scripts/issues/52#issuecomment-169818598
All songs synced up to, but not including this song:
El Mañana (Metronomy Remix) -- Gorillaz -- D-Sides (697e7789-87f3-39e6-bd70-7abcc89743f3)
I think the ñ could be causing the issue ...
When I make a dry run there is no problem using:
$ gmsync down -m -d<EMAIL_ADDRESS>This command will comfortably list all missing songs, including the song with the word Mañana in it
But when I execute a sync using:
$ gmsync down -m<EMAIL_ADDRESS>I get this notice:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-11: ordinal not in range(128)
Here's the complete output:
Scanning for missing songs...

Downloading 252 song(s) from Google Music

Traceback (most recent call last):
  File "/usr/local/bin/gmsync", line 9, in <module>
    load_entry_point('gmusicapi-scripts==0.1.0', 'console_scripts', 'gmsync')()
  File "/usr/local/lib/python2.7/site-packages/gmusicapi_scripts-0.1.0-py2.7.egg/gmusicapi_scripts/gmsync.py", line 180, in main
    mmw.download(songs_to_download, cli['output'])
  File "<decorator-gen-114>", line 2, in download
  File "/usr/local/lib/python2.7/site-packages/gmusicapi-7.0.1.dev0-py2.7.egg/gmusicapi/utils/utils.py", line 612, in wrapper
    return function(*args, **kw)
  File "/usr/local/lib/python2.7/site-packages/gmusicapi_wrapper-0.1.0-py2.7.egg/gmusicapi_wrapper/gmusicapi_wrapper.py", line 394, in download
    for result in self._download(songs, template):
  File "/usr/local/lib/python2.7/site-packages/gmusicapi_wrapper-0.1.0-py2.7.egg/gmusicapi_wrapper/gmusicapi_wrapper.py", line 331, in _download
    suggested_filename, audio = self.api.download_song(song_id)
  File "<decorator-gen-60>", line 2, in download_song
  File "/usr/local/lib/python2.7/site-packages/gmusicapi-7.0.1.dev0-py2.7.egg/gmusicapi/utils/utils.py", line 290, in wrapper
    return function(*args, **kw)
  File "/usr/local/lib/python2.7/site-packages/gmusicapi-7.0.1.dev0-py2.7.egg/gmusicapi/clients/musicmanager.py", line 350, in download_song
    filename = filename.decode('utf-8')
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-11: ordinal not in range(128)

Just so it is here. This is caused by a side-effect of the futurize level 1 changes. The response filename in the download_song method ends up being unicode rather than str so the decode results in an error.

#402 should hopefully fix this for you @shaneholloman

thank you @thebigmunch !

I'm going to close this, but feel free to reopen if #402 did not address the problem.


Flash of light mode on load

I have my mac set to prefer dark-mode and the site flashes white on load.

@ShaggyDude same here need to hide the layout until completed loading.


PoolConnection::drop: don't wait until inside the future to call .float()

I'm using sqlx with actix_web and postgresql, I found a problem when trying to spawn a custom thread, I made a sample project to describe the issue.
There are 3 apis in the server. /test and /nostuck works well, /stuck is problematic. I can only query this api DB_MAXCONN(defined in .env) times, after that sqlx will get stuck at pool.begin, even /nostuck will get stuck too. /test shows that actix_web is working well.
I don't know what's wrong with /stuck, it seems that in this api the connection isn't returned to the pool. What I'm trying to do in this api is I want to do something background without blocking the response, jh.join on line 130 is only there to demonstrate the problem, I won't join the thread in actual code.

I experimented a little, and found a working version /nostuck2.
However, along the way I found an interesting thing: If I do tokio::time::sleep, the problem is gone. stuck2, nostuck3, nostuck4 demonstrates this. It really confuses me. Hope someone who knows the internals can explain to me.

This issue is very similar to #1389 in that it's caused by the runtime going away while we're trying to spawn a task that's important to SQLx functioning correctly.
In this case, it's due to waiting to call .float() here until we're running in the async future (which is passed to sqlx_rt::spawn() in the drop handler of PoolConnection): https://github.com/launchbadge/sqlx/blob/v0.5.6/sqlx-core/src/pool/connection.rs#L104
Because you're using a single-threaded runtime, the task we spawn in PoolConnection::drop() will simply not be run because the runtime dies when the current running future returns. Because of that, we never call .float(), so the connection is effectively leaked from the pool.
If you were using a multi-threaded runtime, you'd probably see similar panics to #1389.
I need to fix this so that DecrementSizeGuard just holds the Arc<SharedPool<DB>> and not a &SharedPool<DB>, so the Floating can be created before being passed to the future which must otherwise be 'static, and then we should never have a situation where a connection is not covered by DecrementSizeGuard.
However, in the meantime, you probably don't want to be spawning a new runtime every time you want to run something in the background. You could instead use actix_web::rt::spawn() to spawn the future in the current Actix runtime, although that is still single-threaded so you probably want to either limit the total number of background tasks running to keep your API fast, or else concurrently run a multi-threaded Tokio runtime, which you can do using a pattern like this:
use actix_web::web::Data;
use tokio::runtime::Handle;

pub type TokioRuntime = Data<Handle>;

#[tokio::main(flavor = "multi_threaded")]
async fn main() {
    let multithreaded_tokio = Data::new(Handle::current());

    // do async setup stuff, like opening a `PgPool` and running migrations...

    // `actix_main()` will quit on Ctrl-C
    tokio::task::block_in_place(|| actix_main(multithreaded_tokio));
}

#[actix_web::main]
async fn actix_main(multithreaded_tokio: TokioRuntime) {
   // now in the Actix runtime
    HttpServer::new(move || {
        App::new()
            .app_data(multithreaded_tokio)
            .service(handle_request)
    })
    .bind("<IP_ADDRESS>:8080")
    .unwrap()
    .run()
    .await
    .unwrap();
}

#[get("/v1/some/route")]
async fn handle_request(
    tokio: TokioRuntime,
) -> HttpResponse {
    tokio.spawn(async move { /* some long-running async operation */ });

    HttpResponse::Ok().finish()
}

Hi @abonander , there is something I can't figure out in the pattern you've proposed, I wish you could kindly help me understand.
I've read in other posts that tokio runtimes can't be nested. It will panic when starting and dropping.
In your pattern, #[tokio::main(flavor = "multi_thread")] creates a multi-thread runtime, and #[actix_web::main] creates a current-thread runtime. But I've tested your code, it works nicely,  and I can send signal 15 to the running process and make it shutdown gracefully. Why is that?

It's because block_in_place() essentially makes the thread no longer a core thread for its duration. The thread-local Tokio context is cleared so to the new runtime the environment is indistinguishable from a freshly started process.


Added BestReplyMessages, formatting

Added BestReplyMessages, formatting. Please publish on July 1

@nenonix @JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

@Sameer-MSFT - we need your kind assistance to merge the new commit for the copy/edit review made by nenonix or make the necessary changes on the PR following the suggestions made. Thank you.

Looks good, thank you!


Feature rng 37

Thank you @cur4so for the pull request.
Travis CI failed to build this pull request, but I suspect it may be related to some thing else.
Results :

Failed tests:

  ContinuousSamplerParametricTest.testSampling:53->check:127 Gaussian deviate [Box-Muller normalized Gaussian deviate [rng=org.apache.commons.rng.core.source32.MersenneTwister]]: Too many failures for sample size = 20000 (3 out of 50 tests failed, chi2=[22.682000000000002, 24.367000000000004, 24.088]

I checked out your pull request locally (https://gist.github.com/piscisaureus/3342247). Then built it with mvn clean site. Finally, under commons-rng/commons-rng-sampling/target/site/, opened the index.html file in my browser.
There, under Project Reports, I can see that PMD has two new issues from this PR (I'll comment on them). And Checkstyle has 4 new errors, which I'll also add a note to the PR.
Can you have a look at these issues @cur4so ? Great work so far. Thanks a lot for your contribution, and patience :-)
Bruno

Builds successfully in
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /opt/jdk1.8.0_131/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-35-generic", arch: "amd64", family: "unix"
I suspect the Travis CI build is not related to the PR, though would need someone else's opinion too.
The coverage report indicates 99% line coverage, and 86% branch coverage. :clap:

thanks @kinow for your suggestions and patience. I've implemented them in the last commit

fixed

now it's more clear @kinow :) Fixed. And rephrased the git commit message as Gilles suggested


CIV-6955 Add removed pba flags

JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ x ] No

This was meant to go in with this PR: https://github.com/hmcts/civil-service/pull/2261
Unfortunately it was taken out mistakenly.
As civil-service is broken for unrelated reasons, the build won't turn red. Still, this change is not expected to break the build further and in fact it's needed to ensure success of PBAv3/WTPP UAT tomorrow morning.
I will be overriding branch protections and merge it. This has been cleared with other TLs and DM.


CMake files for Windows are incomplete.

CMake Error at CMakeLists.txt:38 (add_subdirectory):
The source directory
C:/Users/MasonStorm/Downloads/OpenCL-SDK-main/external/OpenCL-ICD-Loader

does not contain a CMakeLists.txt file.
CMake Error at CMakeLists.txt:41 (set_target_properties):
set_target_properties Can not find target to add properties to: OpenCL
Configuring incomplete, errors occurred!

Best regards.

You've cloned the repo without --recursive. There is WIP to make this process more failsafe by the scripts doing it on your behalf if you forget. In the meantime, see here or here. Let us know if it solved the problem.

Ok, well, I'll do it another way. I just clicked on "clone" downloaded as a zip, unzipped it into Downloads folder.
I then open Cmake GUI and set the source directory as a the root directory of the OpenCL-SDK and created a folder in the root folder called "build" as a target location for the build process.
Is that really not going to work?

Indeed,
git clone --recursive https://github.com/KhronosGroup/OpenCL-SDK.git
on the Powershell fetches everything.
Thanks a lot.
Closing issue.


Issue with conda installation of cutadapt

CDC colleagues report this issue, with conda installation of cutadapt:
ERROR ~ Error executing process > 'MPAS_WORKFLOW:TRIM_PRIMER_SEQS (32)'

Caused by:
  Failed to create Conda environment
    command: conda create --mkdir --yes --quiet --prefix /home/andrias/conda_cacheDir/env-d42adc9e0b8ca4afdc6c17b09e8cc841 bioconda::cutadapt=3.5
    status : 1
    message:
      Channels:
       - defaults
       - bioconda
      Platform: linux-64
      Collecting package metadata (repodata.json): ...working... done
      Solving environment: ...working... failed

      LibMambaUnsatisfiableError: Encountered problems while solving:
        - nothing provides python_abi 3.6.* *_cp36m needed by cutadapt-3.5-py36h91eb985_1

      Could not solve for environment specs
      The following packages are incompatible
      └─ cutadapt 3.5*  is not installable because there are no viable options
         ├─ cutadapt 3.5 would require
         │  └─ python_abi 3.6.* *_cp36m, which does not exist (perhaps a missing channel);
         ├─ cutadapt 3.5 would require
         │  └─ python_abi 3.7.* *_cp37m, which does not exist (perhaps a missing channel);
         ├─ cutadapt 3.5 would require
         │  └─ python_abi 3.8.* *_cp38, which does not exist (perhaps a missing channel);
         └─ cutadapt 3.5 would require
            └─ python_abi 3.9.* *_cp39, which does not exist (perhaps a missing channel).

This seems to relate to a larger issue where conda can't find packages in other conda channels.  For instance, when specifying a bioconda channel package, conda is not able to find packages in the conda-forge channel.  Nextflow has a config option to specify conda channels in which to look.  Another option is to specify multiple channels in a conda yaml environment definition file.  This solution for this is described in #102.


process held fees on migrate

Description
What does this PR: do, how, why?
Limitations & risks
Are there any trade-off or new vulnarbility surface based on theses changes?
Check-list

[ ] Tests are covering the new feature
[ ] Code is natspec'd
[ ] Code is linted and formatted
[ ] I have run the test locally (and they pass)
[ ] I have rebased to the latest main commit (and tests still pass)

Interactions
These changes will impact the following contracts:

Directly:

Indirectly:

is this considered border patrol? :laughing:
lgtm


Tag names are always lowercase—but not in every Hugo project

Hi all,
Hugo seems to treat tags differently here (lowercase vs. uppercase as in front matter). Case 1 without, case 2 with an empty line before the trailing ---.
Front matter:
---
title: Test
tag:
- Test1
- Test2
---

Result:
test1, test2

Front matter:
---
title: Test
tag:
- Test1
- Test2

---

Result:
Test1, Test2

Unfortunately I was not able to reproduce this issue in a personal project. The reason might be, that redundant tags appear in lower and upper case in YAML in the same (big) project.
Thank you!

Thanks for getting in touch, but it feels like this is a question  that would be better suited to the Hugo Discussion Forum.  We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug. You may also find the answers you search for in Hugo Documentation.


How to use CustomMark prop

Hi there,  In the readme examples, there is no example with this property. When you make an example code, nothing is displayed on the screen, is it working?
<Slider
        onSlidingStart={value => console.log('start:', value)}
        onSlidingComplete={value => console.log('complete:', value)}
        onValueChange={value => console.log('change:', value)}
        style={styles.slider}
        thumbSize={markSize - 0}
        minimumValue={0}
        maximumValue={max}
        trackStyle={styles.track}
        CustomMark={({value}) => <Text>Hi {value}</Text>}
        step={1}
/>

Information:

@react-native-assets/slider version: 7.0.5

Rendering a view works perfectly, thanks
 CustomMark={({ active }) => (
              <SliderTrackMarker isSelected={active} />
            )}
   [....]

const SliderTrackMarker = styled.View<{
  isSelected?: boolean;
}>`
  border-radius: 22px;
  pointer-events: none;
  height: 18px;
  width: 18px;

  background-color: ${({ isSelected }) =>
    isSelected ? 'transparent' : 'gray'};
`;

Rendering a Text should also work fine. In the Readme, there is a link to a Snack expo. You can see there an example very similar to your first case, so this should work just fine.


How can I get all English vocabularies in Hatebase?

from hatebase import HatebaseAPI
key = '~'
hatebase = HatebaseAPI({"key": key})
hatebase = HatebaseAPI({"key": key, "debug": True})
filters = {"language": "eng"}
format = "json"

response = hatebase.getVocabulary(filters=filters, format=format)

vocablist = response["result"]
results = response["number_of_results"]
pages = response["number_of_pages"]

If I run the code above, I get vocablist with length 100, results with length 1522, and pages as length 16.
I thought I would get the whole vocabulary of English HateBase words by this query but there were only 100 vocabularies returned.
Is there any way I could get the whole vocabulary?
Thanks.

Hi, @isabelline .  Thank you for your question.  @meierale, could you help?

Hi @isabelline. Please try to adapt the Ara example to english: https://github.com/DanielJDufour/hatebase#get-all-arabic-vocabulary
The hatebase API limits its resultsets to max 100 vocabulary entries, but indicates how many total results on how many pages there are. So your code above contains the 100 vocab entries of the first page. Now you have to query all remaining pages, get their 100 entries and append them all to the 'full vocabulary' that you have to build yourself. The 'Get All Arabic Vocabulary' example in the readme shows how I usually do that.
Try to copy & paste that code, switch the language filter to "eng" and it should work right away. And for the English vocabulary it will take some time to loop through all pages, just so you know ;-)
Please let me know if that works for you.

@meierale @DanielJDufour  Thank you! It works like a charm :)


Renest HTML; Closes #62

Problem
The DOM is getting mangled with multiple navs. This is becuase there are
redundant elements within the index file. This may of been becuase of a bad
merge conflict.
Solution
Renest the DOM elements and remove redundant tags.
Howto Test

[ ] No regressions

/cc @mkinsey

Looks good thanks Ben


update mapzen docs repo name

Part of https://github.com/mapzen/mapzen-docs-generator/issues/243.

Thanks @meetar!


Public transport view

Add option public transport view : bus, subway and tramway route.
Example public transport view in OSM :

We are actually working to implement and release this feature as soon as possible.

In the same thematic, some bus_stop are not rendered, like on openstreetmap.org.
I's not rendered when the bus stop is a way. Here an example : https://www.openstreetmap.org/way/385799459
Thanks !

Anything new?

A great first start already would be to show for stop positions (bus stops, metro stops, ferry stops etc) which lines (= ref value of OSM route relation) is stopping there.

A great first start already would be to show for stop positions (bus stops, metro stops, ferry stops etc) which lines (= ref value of OSM route relation) is stopping there.


chore(starknet_http_server): add metrics for added txs

Stack:

#2888
#2885
#2884
#2881
#2915 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is


jqf-alf-fuzz freezes and timeout doesn't work

When running the jqf-alf-fuzz, the status panel sometimes freezes and no updates afterward.
The timeout mechanism seems doesn't interrupt the running test. According to visualvm, it keeps reading the EOF in StreamBackedRandom

The testing command is
bin/jqf-afl-fuzz -x examples/target/test-classes/dictionaries/maven-model-afl.dict -i ../gen-seeds-dict/seeds/xml -o maven0 -c "examples/target/test-classes/:examples/target/test-classes:examples/target/dependency/*" edu.berkeley.cs.jqf.examples.maven.ModelReaderTest testWithInputStream

Interesting, thanks for the repro command and the profiler screenshot.
To be honest, I don't maintain the jqf-afl-fuzz bridge any more, for several reasons (mainly that AFL is quite outdated now and JQF is best used with Zest and other guidances implemented within Java). I can't promise a quick fix if this is AFL related. If you have a solution, PRs are definitely welcome.
Do you think the same bug would be encountered when fuzzing with Zest (i.e., via mvn jqf:fuzz?) If so, then I'll look into it further.


Onboarding deploy tooltip fix

Show deploy tooltip if the user clicks anywhere after the binding success tooltip appears.

@all-contributors please add @akash-codemonk for code

@all-contributors please add @akash-codemonk for code


balancebot-sim panics on X11

On Arch Linux using X11, from the project root I ran:
cd examples/cu_rp_balancebot/
cargo run

It output:
     Running `/home/paul/rust/copper-rs/target/debug/balancebot-sim`
thread 'main' panicked at /home/paul/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_winit-0.14.2/src/lib.rs:132:14:
Failed to build event loop: Os(OsError { line: 760, file: "/home/paul/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.30.5/src/platform_impl/linux/mod.rs", error: Misc("neither WAYLAND_DISPLAY nor WAYLAND_SOCKET is set; note: enable the `winit/x11` feature to support X11") })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It looks like you can just enable the "x11"  feature for the bevy crate. I'll submit a PR.


Function not found in a Windows debug binary generated by MinGW

Function make_foo is only referenced in the code, never called. Nevertheless, when compiled in debug mode, it's detected on Linux or when compiled with cl.exe on Windows.
testcase.tar.gz
On Arch Linux, compiled with gcc 6.1.1 everything works exactly as expected.

On Windows, with cl.exe (from Visual Studio 2013):

On Windows, compiled with mingw-gcc 5.3.0 (bundled with Qt 5.7 for MinGW), I am getting this:

After pressing H:

And after pressing P, the function and many in its call tree are added to the list:

I'm not 100% sure this constitutes a bug, but it definitely surprised me.

Ahh, this is good information, thanks.
First, a quick summary is that we don't scan looking for functions. We will automatically add functions exposed via symbols, and if the function is called from anywhere else, we should find it as well.
That said, there are symbols on the mingw binary so that's good to know, we should be able to fix that.
Any chance you could upload the mingw built binary as well?

It's in testcase.tar.gz from the first post, libtestlib_mingw.dll. Sorry for the bad naming.

Sorry for not closing this a while ago, this bug was fixed some time ago.


refactor: simplify dynamic loading of HiGlass

Working on a PR to dynamically load gosling component and dug into the higlass implementation. Perhaps there is something I am missing, but import(...) is well supported in the browsers we target and seems to work. Unless webpack inlines dynamic imports, would this be a suitable change?

The issue arises when a consumer app (i.e. the HuBMAP portal) tries to load HiGlass via Vitessce.
The import('higlass') statement causes the webpack build to have an additional file 9.min.js which contains the higlass code:

And then when a Vitessce view config includes a HiGlass component, the portal crashes because the portal  does not know where to find 9.min.js relative to its own bundle:

To reproduce this:

Build your branch npm run build-lib:prod
Copy dist to portal-ui/context/node_modules/vitessce/dist
Put a Vitessce view config containing a higlass component (for instance the one from http://vitessce.io/?dataset=just-higlass) in portal-ui/context/app/preview/cell-type-annotations.md
Run portal-ui/dev-start.sh
Open http://localhost:5001/preview/cell-type-annotations

This is why the only solution I could find was to load the HiGlass bundle dynamically from CDN, but maybe you know of a better solution?

This is why the only solution I could find was to load the HiGlass bundle dynamically from CDN, but maybe you know of a better solution?

I see. thank you very much for the detailed response. I guess the issue arrises from the current build target for vitessce (as a library) baking in webpack-isms. Since webpack doesn't generate ESM, any dynamic imports are changed to dynamic __webpack_require__, which I think isn't statically analyzed by bundlers (so those emitted chunks don't get consumed by
library users of vitessce).
I ran into a similar issue when trying to use gosling.js as a library in gos, since the codebase uses dynamic imports in a few places. Things would build fine, but then fail at runtime because the dynamic imports were never traced. An attempt at the solution was to try to replace webpack with something that produces a "module" library target: https://github.com/gosling-lang/gosling.js/pull/494
I'll try to think about this a bit more

I did have success using this branch to dynamically load HiGlass in the HuBMAP data portal by adding a higlass component to a view config at http://localhost:5001/preview/cell-type-annotations
npm install
npm run build-lib:prod
npm pack
cd ../portal-ui
# comment out the npm install in ./dev-start.sh
cd context
npm install ../../vitessce/vitessce-1.1.17.tgz
cd ..
./dev-start.sh

I am able to check the network requests and see that the higlass and pixi libraries are no longer loading from an unpkg URL.
However, when I try to test with the jupyter widget, the widget crashes and I see this error (running this notebook at http://localhost:8888/lab/tree/widget_genomic_profiles.ipynb) which contains a higlass component:
npm install
npm run build-lib:prod
npm pack
cd ../vitessce-python/js
npm install ../../vitessce/vitessce-1.1.17.tgz
conda activate vitessce-jupyter-examples
npm run build
cd ../docs/notebooks
pip install -e ../..
jupyter lab widget_genomic_profiles.ipynb

I see that in the dist directory for the built javascript for the jupyter widget, the file 1.labplugin.js does contain the pixi/higlass code. JupyterLab is trying to dynamically import the file from the URL http://localhost:8888/lab/tree/1.labplugin.js and failing:

Is there some configuration I need to do in the webpack build script for the Jupyter widget so that this type of dynamic import is supported / loaded from a different URL?

I had a chance to try the unpkg import for Gosling (http://localhost:3000/?dataset=just-higlass on branch keller-mark/gosling-test), basically by switching out the HiGlass bundle URL for a Gosling one. It works for Gosling v0.9.8 (based on the gosling-react example)

but I encounter an error with the latest v0.9.14:
Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of `HiGlassComponentWrapper`.

Do you know if the React usage of Gosling looks different in newer Gosling versions?

A single-chunk build for Jupyter means no dynamic importing there, right? If so, it feels like removing a feature since we currently do support a HiGlass dynamic import in Jupyter, albeit in a non-native way. However we do want to add support for Gosling and I have forgotten whether Gosling would depend on this PR.

Yes, no dynamic loading for the jupyterlab extension only. The PR I submitted was intended as a temporary fix until we can find a more robust solution. It's important to note that the limitation with dynamic loading is due to how vitessce is consumed/bundled by jupyter labextension build, but dynamic imports work in other contexts/bundlers (like the hubmap portal).
I thought removing dynamic loading for the jupyter lab extension exclusively might be an OK tradeoff since the content is loaded locally (from the Jupyter server) and not over a remote network. Additionally, it's worth noting that relying on content from a CDN means that these modules won't work offline in Jupyter. I'm not sure if that's a common use case, but something to consider.

Does the non-native dynamic import implementation cause issues with using Gosling? Could we load Gosling dynamically using the same kind of unpkg import? Does the native browser import() support remote URLs?

Yes, certainly! I think the original idea was to prevent HiGlass being loaded twice for a vitessce configuration with Gosling/HiGlass components. However, now Gosling doesn't bundle HiGlass.

Do you know if the React usage of Gosling looks different in newer Gosling versions?

HiGlass is no longer bundled as a part of Gosling's UMD export, so you'll need to import HiGlass from the CDN as well (like PIXI.js and React)

the limitation with dynamic loading is due to how vitessce is consumed/bundled by jupyter labextension build, but dynamic imports work in other contexts/bundlers

That makes sense, but I worry that there may be other bundlers that also try to do whatever jupyter is doing breaking our assumptions about dynamic imports.

I thought removing dynamic loading for the jupyter lab extension exclusively might be an OK tradeoff since the content is loaded locally (from the Jupyter server) and not over a remote network. Additionally, it's worth noting that relying on content from a CDN means that these modules won't work offline in Jupyter.

I hadn't thought about these tradeoffs.
What do you think about doing native dynamic import with a fallback to a CDN dynamic import as a compromise? On top of this, we could force the single-chunk build in Jupyter to enable the offline use case.
This way there are 3 dynamic import cases:

native dynamic import, which should work unless a bundler does something funky
native dynamic import within single chunk build for Jupyter and other local environments (I wonder if RStudio will also need a single chunk, I have not investigated there yet)
dynamic import from CDN (as a fallback for downstream bundling setups that we do not have control over)