How to propagate images/html files using ci.testling.com

I have mocha tests trying to load images:
img.src = '/test/fixtures/test.gif';

local mocha works because it perhaps starts a test server in the CWD. But ci.testling.com does not works because I do not know how to tell testling: copy '/test/fixtures/test.gif' to the build used by testling.
Should I just use files: ['/test/fixtures/*'] ?

The service is long dead, unfortunately.


[0.60.0-rc.3] react-native init stucked at installing required CocoaPods dependencies

React Native version:
System:
    OS: macOS 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 365.26 MB / 8.00 GB
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.4.0 - /usr/local/bin/node
    Yarn: 1.17.0 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
    Android SDK:
      API Levels: 22, 23, 25, 26, 27, 28
      Build Tools: 25.0.2, 27.0.3, 28.0.3
      System Images: android-22 | ARM EABI v7a, android-22 | Intel x86 Atom, android-22 | Intel x86 Atom_64, android-22 | Google APIs ARM EABI v7a, android-22 | Google APIs Intel x86 Atom, android-22 | Google APIs Intel x86 Atom_64, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom, android-Q | Google Play Intel x86 Atom
      Android NDK: 19.2.5345600
  IDEs:
    Android Studio: 3.4 AI-183.6<IP_ADDRESS>22156
    Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
  npmPackages:
    react: 16.8.6 => 16.8.6
    react-native: 0.60.0-rc.3 => 0.60.0-rc.3
  npmGlobalPackages:
    react-native-cli: 2.0.1

Steps To Reproduce

rn init CodePush --version react-native@next

Describe what you expected to happen:
Should show project init completion if it's completed, or show progress bar if it's installing?

Sorry, I don't understand - what is the issue?
If I run react-native init RN060 --version react-native@next it works. Have you installed cocoapods?

It keep stucked at this step

Ok, this seems to suggest that your issue is related to the CLI, so I suggest you open an issue there -> https://github.com/react-native-community/cli

I just created a new project and I thought I had the same problem, but the reality is that you just have to wait. Once it finishes installing the required dependencies with that project, all of the next projects will be faster.

I just created a new project and I thought I had the same problem, but the reality is that you just have to wait. Once it finishes installing the required dependencies with that project, all of the next projects will be faster.

How long have you waited?????

@Maskedheroe But I waited until to time out.

@Maskedheroe, the very first time I did it I canceled after 5 min. Next time I tried, I had to wait around 10 min (My computer is working slow lately) After those 10 min I waited, I haven't had any problem, every new project takes less than 2 min to setup.

this step i know , it's up to your net status , today i init project faster in company than my home.


Integer array field in postgress is not handled by flask admin properly

Integer array field in my table in postgres exists and work perfectly. I can create/apdate/insert/delete it  with numbers.
Flask-admin sees and interprets that field by SQLAlchemy model. Field shows up with its content in edit form in flask-admin.
But whenever I try to save the form (regardless of editing or leaving contents of array field as is) I got error 500. Postgres throws an error:
sqlalchemy.exc.ProgrammingError: (psycopg2.ProgrammingError) column "courses_ids" is of type integer[] but expression is of type text[]
So it seems that flask-admin interprets my int array field as text array.
Is there any solution on how to instruct Flask-Admin that the array field is of type int ?
Sqlalchemy field declaration: courses_ids = Column(ARRAY(Integer))

A workaround:
class Select2IntegerTagsField(Select2TagsField):
    def process_formdata(self, valuelist):
        super().process_formdata(valuelist)
        self.data = [int(x) for x in self.data]

class StudentView(ModelView):
    def scaffold_form(self):
        form_class = super().scaffold_form()
        form_class.course_ids = Select2IntegerTagsField("Course Ids", save_as_list=True)
        return form_class

admin.add_view(StudentView(Student, session))

Hi? Will this be systematically fixed without workarounds?

thanks! it's help me a lot

A workaround:
class Select2IntegerTagsField(Select2TagsField):
    def process_formdata(self, valuelist):
        super().process_formdata(valuelist)
        self.data = [int(x) for x in self.data]

class StudentView(ModelView):
    def scaffold_form(self):
        form_class = super().scaffold_form()
        form_class.course_ids = Select2IntegerTagsField("Course Ids", save_as_list=True)
        return form_class

admin.add_view(StudentView(Student, session))

what is the Select2TagsField Class you're inheriting from?

Please review this fix https://github.com/flask-admin/flask-admin/pull/2003

For future generations.

what is the Select2TagsField Class you're inheriting from?

from flask_admin.form.fields import Select2TagsField


[9.0] Add support for search panes.

Fix #2463, #2471
JS Demo ref: https://editor.datatables.net/examples/extensions/searchPanes.html
USAGE
$users = User::query()->select('id as value', 'name as label')->get();
$categories = Category::query()->select('id as value', 'name as label')->get();

return datatables()
    ->eloquent(Post::query())
    ->setRowId('id')
    ->searchPane('user_id', $users)
    ->searchPane('category_id', $categories);

TODO

[ ] Add option to set custom query handler for a specific search pane / column.

[ ] Add support for Collection. Might be added on a separate PR.

[ ] Add tests or yolo!

TODO: SearchPane Custom Query Handler Plan
$users = User::query()->select('id as value', 'name as label')->get();
...
->searchPanes('user_id', $users, function($query, $values) {
    $query->whereIn('user_id', $values);
})

Hello, I don't understand why I can't use searchPanes with serverside, it remains blank, empty, I've been looking for a solution for days but I can't find it, I also bought the datatables editor but I can't get it to work, can anyone help me figure out how to solve this problem?


Selection prompt to extract method not worked in VSCode

VSCode Version:Version 1.1.0 (1.1.0)
OS Version: Mac OS X EI Capitan

Steps to Reproduce:

Selection some lines code inside a method, will not show the prompt which will contains two menu item, just like "Extract Method" and "Use explicit type", which can be found in the release notes of v0.7.0
I just can not do this, and I google a lot for this, then I got nothing, so I'm here.

Hi -- thanks very much for taking the time to file this. We have some work to clean up the light bulb in VS code for C# and make it functional.

Hi @lishali12345: I haven't seen any problems with this in quite some time. There are a lot of fixes for Code Actions in the 1.7 release (due any day now). So, I'm going to go ahead and close. Please let me know if you have any more trouble.

Hi @DustinCampbell, I don't know if I should be contacting you or the VSCode team, but the extract method feature doesn't work well in VSCode, though it is a bit hidden and I didn't even know it was there, even though I read this issue way back then. :)
Right now, running VSCode v1.9.1, I get a light bulb containing "extract method" to the left of a selected line or lines, but only if my selection is particular. I believe it is using the cursor position only and not what I have selected. Is this correct?
It's a bit hard to work with it if it doesn't follow the selection. For example, if I want to extract the contents of an "else", I don't seem to be able to, unless it's a single statement. On the other hand, if I extract with the cursor on the "else" word, it will extract the full if-else (I guess this is expected... maybe ;)).
Furthermore, running extract method seems to disregard my preference of tabs vs spaces, always using spaces, and will also change the formatting of the extracted code (though maybe it runs format and this is expected behavior).
If you'd like, I could submit this as a new issue. Thanks for reading!

Hi @CanisLupus: This is definitely an issue for us. The VS Code version doesn't matter much though. Rather, it's the version of C# for VS Code that's important. Feel free to file a new issue.

I've updated the C# plugin to v1.7.0 before commenting, to see if it had fixed something in this regard, but it looks the same. I'll create a new issue and mention that. Thanks.

Still an issue for me on macOS 10.12.6, simply in the Interactive Playground even, not any fringe or self-installed programming language.


ConfirmYesNoAsync/ShowActionSheetAsync truncates text at end of second line

Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[] iOS
[*] Android
[] UWP
[*] NET Standard 2.0

Version of OS(s) listed above with issue (if android - please include version of Xamarin.Android.Support.* you are using)
Android 6.0
Samsung Galaxy S5
Xamarin.Android.Support=<IP_ADDRESS>
Version of ACR UserDialogs Library
7.0.1
Expected Behaviour
in ConfirmYesNoAsync/ShowActionSheetAsync:
Long text should wrap as many lines as needed.
Actual Behavior
Long text gets truncated at end of second line with "..."
Code of Conduct

No Library Update Requests - THIS ESPECIALLY MEANS ANDROID SUPPORT LIBRARIES
No Timeline Requests
Please read through the documentation and FAQs
Please be respectful of my time. I put a lot of effort into my libraries.  I try to support the issue requests within a day.  I'm not psychic, so please take the time to fill out the above form as complete as possible

With confirm - this is the default behavior for Android which I don't alter.
Actionsheets only support message on iOS.
You'll have to work with the OS here.


ValueError: could not convert string to float: b'5.0.0'

The title says it all :slightly_smiling_face: When running
python3 -m pdfsyntax overview

on an ebook I downloaded somewhere, I get the error in the title with the following traceback:
Traceback (most recent call last):
  File "/nix/store/x7agqy4zr8na6rc7252avhwppgfylz33-python3-3.10.13/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/nix/store/x7agqy4zr8na6rc7252avhwppgfylz33-python3-3.10.13/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/__main__.py", line 4, in <module>
    main()
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/cli.py", line 26, in main
    overview(args.filename)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/cli.py", line 229, in overview
    m = metadata(doc)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/api.py", line 124, in metadata
    i = info(doc) or {}
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/docstruct.py", line 310, in info
    return get_object(doc, info)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/docstruct.py", line 137, in get_object
    res = memoize_obj_in_cache(doc.index, doc.data[-1]['fdata'], ref, doc.cache)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/docstruct.py", line 108, in memoize_obj_in_cache
    obj = parse_obj(text, i)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/objects.py", line 228, in parse_obj
    obj = dedicated_type(text[h:i], t)
  File "/home/simeon/test/penv/lib/python3.10/site-packages/pdfsyntax/objects.py", line 193, in dedicated_type
    return float(text)
ValueError: could not convert string to float: b'5.0.0'

So it erroneously tries to convert 5.5.0 to a float, which of course doesn't work. I can "fix" it with something like
return float(".".join(text.decode("ascii").split(".")[:2]))

, which makes the command run successfully. But that likely won't cover all cases where this can go wrong - I have no idea what kind of strings it might try convert in other edge cases.

Thank you for your bug report!
The issue is that a literal string is cut because it contains parentheses that are not escaped; then the parser tries to interpret the remaining characters as a numeric object because this slice does not start with a parenthesis.
According to the PDF specification, the tokenizer should handle balanced parentheses even if they are not escaped.
I will commit a fix in a few minutes.
Regards


Test: Layout Control Types

Refs:  #137633

[ ] anyOS @mjbvz
[x] anyOS @rebornix
[x] anyOS @jrieken

Complexity: 2
Create Issue

Context
The layout control is visible in the top right of the window when the title bar style is custom. It is enabled by default in insiders and controlled via workbench.experimental.layoutControl.enabled.
Due to feedback that the layout control menu in the title bar is too many clicks, we experiment with new options. Please try out the new experimental setting workbench.experimental.layoutControl.type.

The new layout buttons and quick pick help with discoverability and I enjoy using them. Good work!

Main issues I ran into was getting the layout control to show up in the first place due to having nativeFullScreen disabled #143820 and clicking on the configure layout button sometimes doing nothing #143826
Also opened a few issues for the layout control itself


Add Salim as a windows maintainer

/cc @chef/client-windows

:+1:

:+1:

https://github.com/chef/chef-rfc/blob/master/rfc030-maintenance-policy.md#maintainer-1
Technically there needs to be more than 50% positive votes from the component maintainers/LTs. Since there are four existing LT/maintainers, that means 3 votes.
So I'll toss in an ex post facto :+1: to put you back on the good side of the law.


Could we get options to choose lora ?

Is it possible to choose a specific lora with the prompt ?

We haven't planned it yet. If you think this feature would be valuable, please feel free to contribute. We'd be happy to review it and consider it for inclusion.


Added extension oauth

Hi,
This should add the ability to use the "oauth" extension.
I tested it on Ubuntu 14.04 with PHP5.5.9.
Same as  #84, I need to use /usr/sbin/php5enmod to load the module.

Thanks


Bugfix for #110

The root cause for this issue is due to race condition. The background thread hasn't put the calculated lists into property collection while main thread already proceeds to get it. This fix makes sure this kind of race condition won't crash VS. Also update some other related places.
@EricMSFT @AndreSayreMSFT @adamdriscoll @Microsoft/poshtools

Will the main thread get a chance to get back to it, or is this just a defensive measure?

This is just a defensive measure as all these implementations are actually controlled by VS. When a keystroke occurs, VS will trigger the implementations such as GetClassificationSpans defined in IClassifier. The method needs to get those tokens and corresponding spans. If they are not yet available, then GetProperty will trigger a KeyNotFoundException.
Ultimate solution to this should be align the sequence of actions between our analysis and VS.

The above looks good, but when/where do we plan to address root cause?

With the latest commits, root cause addressed. The original code's issue is it checks if tokenizing is running, if yes, then it just return, which may cause the latest typed char not colorized.
The fix here is let every keystroke trigger colorization but only apply them when the tracing span is the current one. This ensures that the latest char will always take effect.

Also fixes #228 then? [And potentially, but not necessarily, #136?]

Yes, all are fixed in this PR.

Thanks!  For posterity's sake: Our in person convo about 'Classifier' was because one of our classes was named 'classifier', this isn't due to A VS-class named 'classifier'.


'@tanstack/react-query' does not work in Safari 14

Describe the bug
Well, once you open your application that makes use of react-query, a JS error gets immediately thrown, no more other JS is executing on the page from that point, React is basically dead. Depending on your error-handling settings, you might also see the error across the screen, like this:

Reads:
SyntaxError: Unexpected private name #setOptions. Cannot parse class method with private name.

Your minimal, reproducible example
https://codesandbox.io/s/naughty-wind-zc3qs6?file=/src/App.tsx
Steps to reproduce

Run the app in the codesandbox
Open it in Safari 14 (I personally used lambdatest for that).
Observe the error.

Expected behavior
No errors thrown.
How often does this bug happen?
Every time
Screenshots or Videos

Platform

MacOS Big Sur
Safari 14
"@tanstack/react-query": "5.8.3"

Tanstack Query adapter
react-query
TanStack Query version
5.8.3
TypeScript version
4.4.2
Additional context
No response

this is expected. as the requirements state, we only support safari>=15
https://tanstack.com/query/v5/docs/react/installation#requirements
That's because v5 uses private class fields, an ES feature old browsers don't know about. Safari 15 is from September 20, 2021. If you need to support older browsers, you need to instruct your bundler to transpile react-query from within node_modules.

Thanks, I see.
Well, at least now there's a page on the internet where people can quickly find out why their site broke right after upgrade.

it's also in the migration docs btw: https://tanstack.com/query/v5/docs/react/guides/migrating-to-v5#supported-browsers

@TkDodo We just ran into this too. IMO Safari 14 is not that old to ignore it. Would you consider producing a bundle that'd be compatible with slightly older browsers like Safari 14?

Safari 15 is from September 20, 2021. That's almost 2.5 years ago. If you must support older browsers, please tweak your bundlers or stay on v4 until you can upgrade.

Thanks for your reply @TkDodo. I'll see if it's possible to tweak Next to support older versions of Safari via the browserslist. I don't think it compiles dependencies from node_modules out of the box but it may be configurable via the transpilePackages option. Otherwise, I'd expect it to work since Next supports Safari 12+ but likely requires additional configuration.
As a side note, the average lifespan of an iPhone is 3-4 years according to some stats I found on the internet. I assume most users would upgrade but not all of them so 2.5 may not be a long enough period to give users to adjust to new standards which means questions like this may keep popping up for some time. I get your argument though - older browsers are not supported out of the box when it's easier to rely on the transpilers doing their job which is fine. Long gone are the days when had to support 15-year-old IE6 :) We could likely add a reference on how to tweak Next correctly for those who want to use the bleeding edge version of RQ but need to support older browsers so I'll see if we can make it work and submit a contribution if we find a way if you're interested.

transpilePackages: ['@tanstack/react-query', '@tanstack/query-core']

seems like it could be exactly what you want

so I'll see if we can make it work and submit a contribution if we find a way if you're interested.

absolutely, thank you 🙏

transpilePackages: ['@tanstack/react-query', '@tanstack/query-core']

seems like it could be exactly what you want

You may also consider adding '@tanstack/react-query-devtools' to the list if you use one.

Thanks! I meant to get back - it worked for us!

transpilePackages: ['@tanstack/react-query', '@tanstack/query-core']

seems like it could be exactly what you want

You may also consider adding '@tanstack/react-query-devtools' to the list if you use one.

I've been struggling to get react-query to successfully transpile in Next.js, adding these two packages causes the following client-side error in our production code:
TypeError: (intermediate value)(intermediate value)(intermediate value) is not a function
    at n.setEventListener (focusManager.js:34:22)
    at n.onSubscribe (focusManager.js:23:12)
    at n.subscribe (subscribable.js:9:10)

This error appears to be related to a private class but happens even on modern Chrome once I add it to the transpilePackages array.  Have you seen anything like this before?

Also found out that if you are using vite, you are all set. It transpiles private properties of deps automagically.

I want to recommend Suspensive. In my opinion, We can avoid this issue by using @suspensive/react-query with @tanstack/react-query v4. You can use useSuspenseQuery, useSuspenseQueries, useSuspenseInfiniteQuery, queryOptions, infiniteQueryOptions with @tanstack/react-query v4 by Suspensive interfaces
https://suspensive.org/docs/react-query/motivation
Then, You can use most of the interfaces of TanStack Query v5 while supporting the browser compatibility of TanStack Query v4.

Also found out that if you are using vite, you are all set. It transpiles private properties of deps automagically.

Not in the case of ‘rsbuild’.
It is necessary to write a mini Babel plugin to ensure compatibility with ‘tanstack-query’ in Safari 14.


Translations for zhs

Please:

Remove the changes introduced in .gitignore.
Format the JSON back to 2 spaces, and ideally order them as the original so diff can be properly reviewed.


[#2135] improvement(integration-test): TrinoQueryITBase removes unusual static call

What changes were proposed in this pull request?
TrinoQueryITBase removes unusual static call (ContainerSuite.getInstance().getTrinoITContainers()).
Why are the changes needed?
There are unusual static call (ContainerSuite.getInstance().getTrinoITContainers()) in TrinoQueryITBase, which could remove from TrinoQueryITBase.
Fix: #2135
Does this PR introduce any user-facing change?
No.
How was this patch tested?
TrinoQueryITBase

cc @justinmclean.

I'm not sure about removing those methods, as they are required even if not used now.

@justinmclean, IMO, dropMetalake and createCatalog are not used in this ITCase at present, therefore we could remove these methods. If we need to create catalog or drop metalake, we could re-add in future.

@justinmclean, I have only updated ContainerSuite.getInstance().getTrinoITContainers(). PTAL.

hi @diqiu50 Please help @SteNicholas review this PR, Thanks.

@justinmclean, @diqiu50, could you help to review this pull request? I could not always rebase main branch for this pull request.


Add ability to import GCP Project

It would be cool if you will add support for google_project resource and use google_project.projectname.id and google_project.projectname.name for child resources as a reference.

I think this feature will be really helpful.
Please add a command to clone an entire GCP project.


Implement argmax on a PMMatrix

Implement something similar to this one : https://docs.scipy.org/doc/numpy/reference/generated/numpy.argmax.html on PMMatrix

The numpy example is quite stupid because ambiguous: we don't know if 5 is the 0-based index of the maximum value, or the maximum value itself!
Also we don't know what happens with negative values... I presume it's the maximum value and  not the maximum magnitude, but it would be good to have an example for disambiguating.
Answering a single index only make sense for an underlying flatten collection like in Smallapack.
But this is not the case of Didier Besset matrix implementation (Array of Array).
Can we access a PMMatrix with a single flat index?
Otherwise we should answer a row and a column index (or alternatively provide a block [:rowIndex :colIndex | ] as argument).

Note that in Smallapack I've implemented findMax: with a block argument which is (self collect: aBlock) argmax.
I also have findAll: which is equivalent of Matlab find (same as select: but answers the indices rather than the elements).

 Apparently without axis, the matrix is flattened before finding the argmax.


Wrong balance displayed if cosignatory chooses multi-signature account as sender account

0.5.22-BETA
When a cosignatory sends XEM and chooses a multi-signature account as a sender address, the balance at the amount textbox is not updated to the balance of the multi-signature account.

? not sure what you mean, how should it be updated?


signing: add genesis id for signer and verifier

Motivation

Closes #3503

Changes

Test Plan

TODO

[ ] Explain motivation or link existing issue(s)
[ ] Test changes and document test plan
[ ] Update documentation as needed

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

Please check my comments on the original pr. this change has the same incorrect implementation. And even added genesis id to vrf which is also a mistake.
Also it really has to many changes for no reason, lets stick to original plan with using option for genesis id to minimize amount of changes. This whole thing should around 50 lines of code


Install Error When Running install_depthai.sh

I am trying to install depthai on my ubuntu 20.04 machine. I am getting an error stating "/usr/local/bin/python3: No module named pip" despite the fact that I have pip installed. Here is the output of the terminal, can someone help me resolve this issue ?
sudo wget -qO- https://docs.luxonis.com/install_depthai.sh | bash
ENTER absolute installation path for depthai or leave empty and default path: $HOME will be used.
Using default installation path: /home/christopher/Luxonis
Directory: /home/christopher/Luxonis is OK
Python version: Python 3.11.1 found.
If you want to use it for installation, press ANY key, otherwise input path to python binary.
Press any key to continue

Calling linux_installer.sh

Updating sudo-apt.
Hit:1 http://packages.microsoft.com/repos/code stable InRelease
Hit:2 http://dl.google.com/linux/chrome/deb stable InRelease
Hit:3 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:4 http://ca.archive.ubuntu.com/ubuntu focal InRelease
Hit:5 http://ca.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:6 http://ca.archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:7 http://ppa.launchpad.net/appimagelauncher-team/stable/ubuntu focal InRelease
Hit:8 http://repository.spotify.com stable InRelease
Hit:9 http://ppa.launchpad.net/gnome-terminator/ppa/ubuntu focal InRelease
Hit:10 http://ppa.launchpad.net/obsproject/obs-studio/ubuntu focal InRelease
Hit:11 http://ppa.launchpad.net/solaar-unifying/ppa/ubuntu focal InRelease
Reading package lists... Done
Installing global dependencies.
 Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
libjpeg-dev is already the newest version (8c-2ubuntu8).
libpng-dev is already the newest version (1.6.37-2).
libsm6 is already the newest version (2:1.2.3-1).
libxext6 is already the newest version (2:1.3.4-0ubuntu1).
pkg-config is already the newest version (0.29.1-0ubuntu4).
python3 is already the newest version (3.8.2-0ubuntu2).
python3-dev is already the newest version (3.8.2-0ubuntu2).
libdc1394-22-dev is already the newest version (2.2.5-2.1).
libgtk2.0-dev is already the newest version (2.24.32-4ubuntu4).
libtbb-dev is already the newest version (2020.1-2).
libtbb2 is already the newest version (2020.1-2).
python3-pyqt5 is already the newest version (5.14.1+dfsg-3build1).
python3-pyqt5.qtquick is already the newest version (5.14.1+dfsg-3build1).
qml-module-qt-labs-platform is already the newest version (5.12.8+dfsg-0ubuntu1).
qml-module-qtquick-controls2 is already the newest version (5.12.8+dfsg-0ubuntu1).
qml-module-qtquick-layouts is already the newest version (5.12.8-0ubuntu1).
qml-module-qtquick-window2 is already the newest version (5.12.8-0ubuntu1).
qml-module-qtquick2 is already the newest version (5.12.8-0ubuntu1).
qtchooser is already the newest version (66-2build1).
qtdeclarative5-dev is already the newest version (5.12.8-0ubuntu1).
build-essential is already the newest version (12.8ubuntu1.1).
cmake is already the newest version (3.16.3-1ubuntu<IP_ADDRESS>).
git is already the newest version (1:2.25.1-1ubuntu3.10).
libgl1-mesa-glx is already the newest version (21.2.6-0ubuntu0.1~20.04.2).
libtiff-dev is already the newest version (4.1.0+git191117-2ubuntu<IP_ADDRESS>).
python3-numpy is already the newest version (1:1.17.4-5ubuntu3.1).
udev is already the newest version (245.4-4ubuntu3.20).
ffmpeg is already the newest version (7:4.2.7-0ubuntu0.1).
libavcodec-dev is already the newest version (7:4.2.7-0ubuntu0.1).
libavformat-dev is already the newest version (7:4.2.7-0ubuntu0.1).
libswscale-dev is already the newest version (7:4.2.7-0ubuntu0.1).
python3-pip is already the newest version (20.0.2-5ubuntu1.8).
qt5-qmake is already the newest version (5.12.8+dfsg-0ubuntu2.1).
qtbase5-dev is already the newest version (5.12.8+dfsg-0ubuntu2.1).
qtbase5-dev-tools is already the newest version (5.12.8+dfsg-0ubuntu2.1).
0 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
/usr/local/bin/python3: No module named pip
Failed installing dependencies. Could be a bug in the installer or unsupported platform. Open a bug report over at https://github.com/luxonis/depthai - exited with status 1 at line 120
Failed installing dependencies. Could be a bug in the installer or unsupported platform. Open a bug report over at https://github.com/luxonis/depthai - exited with status 1 at line 192

Thanks for the report @cwillboyd
CC: @PetrNovota it detected Python3.11 while Ubuntu20.04 defaults to 3.8 (which the python3-pip installs pip for as well). Also an python3 -m ensurepip could be issued beforehand if need may be.

@cwillboyd thank you for the report. If you try running the python3 -m ensurepip command prior to running the installer, does it help?


[SMALLFIX] Move a master log message from error to debug

The LOG.error in here may be an expected case.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/10210/
Test PASSed.

LGTM


If a project has set a theme that does not exist in the installation, the buttons are messed up

In 3.12, when viewing a project with a theme that does not exist, the buttons are all messed up.
I fixed this in x_getThemeInfo (in xenith,js). If the retrieval of the theme's info file fails with a 404, the theme is reset to default.

Also, apparently if th etheme is not set at all (project from 2015) than it still does not work.
Easily fixed by setting x_params.theme to "default" in that case.


doc: Add NOTICE for CalicoWindows

Add NOTICE for CalicoWindows

Thanks for your contribution, let's wait for Ariel Patano 's review.

They will not review this PR. Please see the email thread.

Thanks for your contribution, let's wait for Ariel Patano 's review.

They will not review this PR. Please see the email thread.


v2.0 WIP

Use PSR-6 caching interfaces
Remove Dsarrola cache adapter and use php-cache
Refactor throttling algorithms
Drop PHP 5 Support and use PHP 7

Hi,
I was looking for ratelimiter and came across here.
Is there any reason you are waiting for this to be merged ?

@harikt Sorry for my late reply. The 1.x branch is usable, you could try the latest release.
Also this PR is in-complete, that's the reason its still open, need to rewrite some more stuff and fix the tests. I am hoping to complete this soon as I don't have much spare time right now. Any help is much appreciated.

@Feijs thank you so much for your comments. Yes, it does make sense to split this a separate PRs as it will be easier to manage.
I just had few ideas for v2 and quickly started working on it and I didn't get any time to review my own code, it's really messy now, i will close this and will create new PRs


Using flowbite-react with React Native

Is your feature request related to a problem? Please describe.
Some users probably would like to use the react-flowbite with React Native. We need to check if there is any "catch" in the instalation and to provide some guide, if necessary.
Describe the solution you'd like
Document the process to use react-flowbite with React Native.
Describe alternatives you've considered
Maybe it isn't supported. In this case, what do we need to do to fix it?
Additional context
n/a

I did some research in the community, and it's not possible to take a React lib and use it in react-native code. Also, I did some tests here in which I created a react-native app, and add the flowbite-react inside the project.  It's don't works.
So, I believe it would be interesting to create a flowbit-react-native lib.
Anyway, I'm open to discussion about this :)

if it has the FlowBite interest,  I would be happy to start working on this task.
What do you think @rluders @bacali95 @tulup-conner  @zoltanszogyenyi ?

I think that it is a good idea, @mouracamila. If you could start a repository would be great.


Installing my first plugin

Hello everyone,
I recently started using homebridge,
I bought a raspberry pi zero W, all to use my air conditioners through homekit, and not through the melcloud app.
installing the plugin it gives me a timeout error, I also noticed that if I try to update hombridge from version 1.5.1 to version 1.6.0 it also gives me a timeout error there, is there anyone who can give me some indications? Thanks so much

My error, i have fixed


Autocmake on Microsoft Windows

Would it be please possible to add the "--generator" flag for the setup.py script ?
With the DIRAC software, we are using the 'setup --generator="MinGW Makefiles" ....' on MS Windows platform together with the (GNU) MinGW64 compilers suite.
Best, M.

I think this is a good idea. Would you like to contribute a patch for that?
You are in a better position to test such a patch.

Another connected issue with MS Windows is employing own CI service. According to Ivan Hrasko's (https://github.com/ihrasko) diploma thesis (DIRAC on MS Windows), there is the MS Windows CI service AppVeyor, http://www.appveyor.com/ .
Can I prepare and add appveyor.yml script for this CI service ?

I think this is a good suggestion but I would prefer this to first happen on a branch on your fork. Then, once Autocmake and the Appveyor CI integration stabilize a bit and we see it in action, we can integrate it to the main repo.

Fine;
so get it properly running on my fork and demonstrate it to the whole world, I have to place own buildup badges into https://github.com/miroi/autocmake/blob/master/README.md , right ?

Yes but I would not place it on the master branch because this will make it difficult
for you to file pull requests.

Closing due to accepted https://github.com/scisoft/autocmake/pull/18 .


hil: add pytest plugin for boards

Adds a pytest plugin (pytest-hil) that provides a pytest fixture for interacting with boards connected over serial. This provides an abstracted API that is both easier to interact with when writing tests and also provides a consistent interface for performing actions on boards that may not have the same serial console semantics.
The plugin is installed with pip and is automatically picked up by pytest because of metadata in pyproject.toml.
HIL tests can simply add a board argument and they will be passed a Board object that is already initialized with an open serial port, PSK credentials, and WiFi credentials (if relevant). The tests can interact with the board by calling methods on the Board object, such as board.reset(). The details of how the board is actually reset are defined inside the plugin. The plugin is structured to use inheritance to reuse as much code as possible. For example, the nRF52840DK class inherits from the ZephyrBoard class, which inherits from the Board class. The plugin also defines command line arguments that are used to specify the board type along with any information needed to instantiate the board (such as credentials and the serial port path). These arguments are passed to pytest by the GitHub Actions workflow.
Closes golioth/firmware-issue-tracker#290

So the idea is to create and maintain "cross-platform" pytest fixtures, of what is provided as part of Zephyr Pytest integration (which works obviously only with Zephyr now)?

So the idea is to create and maintain "cross-platform" pytest fixtures, of what is provided as part of Zephyr Pytest integration (which works obviously only with Zephyr now)?

It's similar to what's provided by Zephyr, but we're not looking for a 1 to 1 replacement. Our fixture will be tailored to our needs, and I expect will be much smaller. And yes, the goal is to make it more "cross-platform".


zipformer BF16 training recipe

This PR shows how to enable bf16 training of Zipformer. It's not intended for merging at this moment.
Advantages of using bf16 training:

BF16 uses less memory than automatic mixed precision (AMP), and is theoretically faster than AMP (no conversion between fp32 and fp16)
BF16 training should be more stable due to its larger dynamic range (so you won't meet the grad scale too small problem if you use bf16 (see #1463, #1550))

Disadvantages of bf16 training:

Limited hardware support (only supports ampere and afterwards, so V100 not supported)
(Possibly) Slightly worse results compared to AMP because bf16 has less numerical accuracy

TODO:

[ ] Performance benchmark with AMP on full LibriSpeech
[ ] Test exporting the model

Performance benchmark on LibriSpeech train-clean-100, all models are trained with 2 A100 GPUs. WERs are obtained with greedy search.

Training config
WER
peak GPU memory
Time per epoch

AMP, max_duration=1000
6.08/15.59
20459MB
8min

full bf16, max_duration=1000
6.11/15.72
15473MB
8min

The WERs are about the same(AMP slightly better than bf16), but bf16 training consumes much less GPU memory. The training speed is the same, but we will have to see on larger max-duration and larger model size.

Experiments on full LibriSpeech. The model is trained for 30 epochs using 4 A100 GPUs. WERs are obtained using modified_beam_search for decoding.

Training config
WER
peak GPU memory
Time per epoch

full bf16, max_duration=1000
2.4/5.31
15392 MB
~39min

There is a notable performance gap (around ~5%) between AMP (2.25/5.06) and full bf16 (2.4/5.31). We will investigate the reason and try to reduce the gap.

Since AMP also supports bf16 as dtype, I tried this (with minor modification to the original code). See this post for more instructions on how to use AMP. The results are shown below.

Training config
WER
peak GPU memory
Time per epoch

full bf16, max_duration=1000
2.4/5.31
15392 MB
~39min

amp bf16, max_duration=1000
2.15/5.1
16169 MB
~42min

So AMP+bf16 training achieves better WER than full bf16, while the peak GPU memory and time per epoch slightly increased.

Detailed experiment results:

model
test-clean
test-other
comment

amp + fp16
2.27
5.1
--epoch 30 --avg 9, greedy

amp + fp16
2.25
5.06
--epoch 30 --avg 9, modified_beam_search

amp + fp16
2.23
4.96
--epoch 40 --avg 9, greedy

amp + fp16
2.21
4.91
--epoch 40 --avg 16

amp + bf16
2.19
5.17
--epoch 30 --avg 13, greedy

amp + bf16
2.15
5.1
--epoch 30 --avg 13, modified_beam_search

amp + bf16
2.16
5.03
--epoch 40 --avg 13, greedy

amp + bf16
2.15
4.94
--epoch 40 --avg 13, modified_beam_search

full bf16
2.42
5.44
--epoch 30 --avg 15, greedy

full bf16
2.4
5.31
--epoch 30 --avg 15, modified_beam_search

full bf16
2.39
5.44
--epoch 40 --avg 17, greedy

full bf16
2.31
5.35
--epoch 40 --avg 17, modified_beam_search

Accuracy: amp fp16 = amp bf16 > full bf16
Training speech: full bf16 > amp fp16 > amp bf16
Memory usage: amp fp16 = amp bf16 > full bf16

The models are uploaded to huggingface:
The amp bf16 zipformer-M model: https://huggingface.co/marcoyang/icefall-zipformer-M-librispeech-amp-bf16
The full bf16 zipformer-M model: https://huggingface.co/marcoyang/icefall-zipformer-M-librispeech-bf16

I decided to only support amp+bf16 training in this PR. Full bf16 training loses too much accuracy.


remove invoices

https://github.com/lnbits/invoices

Really weird 🤔

Codecov Report

Merging #1515 (64bad6c) into main (bb05703) will decrease coverage by 2.15%.
The diff coverage is 50.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1515      +/-   ##
==========================================
- Coverage   49.02%   46.87%   -2.15%
==========================================
  Files          54       47       -7
  Lines        7052     6763     -289
==========================================
- Hits         3457     3170     -287
+ Misses       3595     3593       -2

Impacted Files
Coverage Δ

lnbits/extension_manager.py
46.93% <50.00%> (-2.63%)
:arrow_down:

lnbits/utils/exchange_rates.py
25.42% <0.00%> (-61.02%)
:arrow_down:

lnbits/core/helpers.py
55.55% <0.00%> (-15.56%)
:arrow_down:

lnbits/tasks.py
33.33% <0.00%> (-10.00%)
:arrow_down:

lnbits/app.py
48.83% <0.00%> (-6.52%)
:arrow_down:

lnbits/commands.py
57.89% <0.00%> (-1.76%)
:arrow_down:

lnbits/helpers.py
67.30% <0.00%> (-0.97%)
:arrow_down:

lnbits/db.py
76.51% <0.00%> (+1.34%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


During AGS install copy the st_raster shared library file to the PostgreSQL lib directory

We are not "installing" the st_raster library (libst_raster_pg.dll) during AGS installation. It is found in the folder C:\Program Files\ArcGIS\Server\DatabaseSupport\PostgreSQL\9.3\Windows64. Don't believe any part of the current Ops Server requires it, but we should install it to be complete.

Issue created by mistake. Researched this further and the libst_raster_pg.dll is being installed to the PostgreSQL lib folder by the Ops Server scripts. Closing issue as no corrective action is required.


Static checking of population

Is your feature request related to a problem? Please describe.
For the moment em::find(...) and em::find(..., { populate: ['something'] }) return exactly the same entity types and compiler don't know was references populated or not.
We have the solution to explicitly define references https://github.com/mikro-orm/mikro-orm/blob/dev/docs/entity-references.md#better-type-safety-with-referencet-wrapper but this solution is partial as you don't know were the references populated or not. You can await all populated references that will not perform database querying, but if you just remember population you may release the code that will produce a lot of unexpected queries to production. Also it causes significant boilerplate.
It would be nice if ``em::find(..., { populate: ['something'] })``` will return mapped type with all populated fields de-referenced.
Describe the solution you'd like
Here is a very rough idea how to define types:
class Reference<T> {
    unwrap<T>(): T {
        // implementation isn't important
        return undefined as any;
    }
}

type UnwrappedReference<T> = T extends Reference<infer U> ? U : T;

type PopulatedEntity<E, R extends keyof E> = {
    [k in keyof E]: k extends R ? UnwrappedReference<E[k]> : E[k]
}

class Credentials {
}

class Organization {
}

class User {
    name!: string;
    credentials!: Reference<Credentials>;
    organization!: Reference<Organization>;
}

function populate<E, R extends keyof E>(entities: E[], ...fields: R[]): PopulatedEntity<E, R>[] {
    // implementation isn't important
    return undefined as any;
}

const users = [new User()];

const populated1 = populate(users, 'credentials');
const credentials1: Credentials = populated1[0].credentials;
const organization: Reference<Organization> = populated1[0].organization;

const populated2 = populate(users, 'credentials', 'organization');
const credentials2: Credentials = populated2[0].credentials;
const organization2: Organization = populated2[0].organization;

Additional context
Types i provided allows to populate only one level of references. There is no generic ts solution to populate at any level, but if we limit deepness of population to some meaningful value like 3-5 correct typing is possible.

how to design the populate api to support nesting and maintain type safety?

I would prefer some monad-style population builder
const populated =await  new PopulateHelper([new Employee()])
    .populate('company', 'alliance')
    .populate('university')
    .exec();

how will the solution for 3 levels depth look like?

Here is a proof-of-concept PopulateHelper typings for 2-levels. Any additional level is just one, but long line of code
class Reference<T> {
    unwrap<T>(): T {
        // implementation isn't important
        return undefined as any;
    }
}

type UnwrappedReference<T> = T extends Reference<infer U> ? U : T;

type PopulatedEntity<E, R extends keyof E> = {
    [k in keyof E]: k extends R ? UnwrappedReference<E[k]> : E[k]
}

type PopulatedEntity2<E, R1 extends keyof E, R2 extends keyof UnwrappedReference<E[R1]>> = {
    [k in keyof E]: k extends R1 ? PopulatedEntity<UnwrappedReference<E[k]>, R2> : E[k]
}

class PopulateHelper<E> {
    constructor(entities: E[]) {
        /* doesn't matter */
    }

    public populate
        <R1 extends keyof E>
        (field1: R1): PopulateHelper<PopulatedEntity<E, R1>>;

    public populate
        <R1 extends keyof E, R2 extends keyof UnwrappedReference<E[R1]>>
        (field1: R1, field2: R2): PopulateHelper<PopulatedEntity2<E, R1, R2>>;

    public populate(field1: any, field2?: any): any {
        return undefined as any; // doesn't matter
    }

    public exec(): E[] {
        /* doesn't matter for typing */
        return undefined as any; // doesn't matter
    }
}

class Alliance {
}

class Company {
    alliance!: Reference<Alliance>;
}

class University {
}

class Employee {
    company!: Reference<Company>;
    university!: Reference<University>;
}

const employees = [new Employee()];

const populated = new PopulateHelper([new Employee()])
    .populate('company', 'alliance')
    .populate('university')
    .exec();

const alliance: Alliance = populated[0].company.alliance;
const university: University = populated[0].university;

will this work with self-referencing?

It should work. There can be problem with populating inside collections, but i don't know is it possible in mikro-orm already or not.

There can be problem with populating inside collections, but i don't know is it possible in mikro-orm already or not.

Not sure what you mean? When you populate 1:m or m:n property, the whole collection will be populated (via one query per entity). You can also (with a little hack) load only the collection elements (for m:n), without populating them.

Not sure what you mean?

class Picture {
}

class Book {
   picture: Collection<Pictures>
}

class Author {
   books: Collection<Book>
}

Can i now get an author with all books and their pictures loaded? Anyway it isn't problem from typings point of view, just one additional type case where collection will be converted into array.

Sure, em.find(Author, {}, ['books.pictures']) will do it. It will fire 3 queries, one for authors, one for books, one for pictures.

Fwiw/just my $0.02, but I don't personally consider this "type-awareness of loaded state based on findXxx parameters" to be that important.
The primary reason is that, in a large enough codebase, the "loading code" of "hey load objects x/y/z" (i.e. at the start of a request/endpoint) and the "processing code" of "okay, apply business logic and validation rules to objects x/y/z" are sufficiently decoupled (spread across different files / concerns / etc) that it shouldn't matter how the objects were loaded.
I.e. I worked in a very large Rails codebase, which used preload-style hints (i.e. findOne(Author, ["books.pictures"]), and it was a nightmare of N+1s b/c the processing code was constantly triggering new/dynamic fetches (as requirements changed/etc.) that the "loading code" had no idea it was going to need.
Such that, IMO, these sort of loading hints are just best avoided all together. They give a false sense of security, and kind of work well-enough in the small, but invariably just don't scale.
A secondary reason is that if the TypeScript types are "upgraded" to exactly match the "loading hint", I wonder if that's really that useful, b/c only the code that is immediately coupled to this specific "loading hint" will work on it; i.e. if I have some generic business logic that works on Author, whether Author was loaded from endpoint1 or endpoint2 or endpoint3, I need that code to be doSomething(author: Author) and not doSomething(author: AuthorWithEndpointOnesHints | AuthorWithEndpointTwosHints | AuthorWithEndPointThreesHints). I.e. code reuse gets much harder, out side of the immediate "this loading code and this processing code are directly coupled together", which I'm in general asserting is not that common in larger systems. (Although if it was author: { name: string } that is actually not that bad, thanks to TS's structurally typing.)
Instead, I think ORMs need to double-down on avoiding N+1s by doing either dataloader-style or optimistic-style fetching (i.e. don't use preload hints and wait until I do await author.book/await book.publisher but still do batched loads), i.e. lean on the framework/ORM to fundamentally solve the problem, instead of relying on the programmer to get their loading hints right.
(All that said, I'll readily admit there is a usability win for getting back author.books[0].pictures[0] all synchronously typed w/o promises, and if we still had to use callbacks, this would probably be a must have; but given we have promises now, and everyone is generally used to them, I assert it'd be more important for Mikro/an ORM to focus on framework-driven safe loading vs. programmer-driven safe loading, and the programmers should just be okay with promises b/c they're not that bad.)
And, granted, everyone has different opinions, so this might be considered a "must have", and if so that's definitely cool, Mikro supporting it doesn't mean I have to use it :-), but just thought I'd do a braindump given the comment in #145 about potentially coupling a v3 release to implementing this.

A secondary reason is that if the TypeScript types are "upgraded" to exactly match the "loading hint", I wonder if that's really that useful, b/c only the code that is immediately coupled to this specific "loading hint" will work on it; i.e. if I have some generic business logic that works on Author, whether Author was loaded from endpoint1 or endpoint2 or endpoint3, I need that code to be doSomething(author: Author) and not doSomething(author: AuthorWithEndpointOnesHints | AuthorWithEndpointTwosHints | AuthorWithEndPointThreesHints). I.e. code reuse gets much harder, out side of the immediate "this loading code and this processing code are directly coupled together", which I'm in general asserting is not that common in larger systems. (Although if it was author: { name: string } that is actually not that bad, thanks to TS's structurally typing.)

Very valid point.

All that said, I'll readily admit there is a usability win for getting back author.books[0].pictures[0] all synchronously typed w/o promises

This is still possible, you can use the unwrap method which is synchronous. It is kinda similar to type casting to any in typescript, as you are then responsible for the objects being loaded.

And, granted, everyone has different opinions, so this might be considered a "must have", and if so that's definitely cool, Mikro supporting it doesn't mean I have to use it :-), but just thought I'd do a braindump given the comment in #145 about potentially coupling a v3 release to implementing this.

I might have expressed it badly - I am not planning to postpone v3 release for this, but I would like to solve it during one of its feature releases (or possibly in v4 as part of bigger refactoring together with making Reference wrapped being the default way).

A secondary reason is that if the TypeScript types are "upgraded" to exactly match the "loading hint", I wonder if that's really that useful, b/c only the code that is immediately coupled to this specific "loading hint" will work on it; i.e. if I have some generic business logic that works on Author, whether Author was loaded from endpoint1 or endpoint2 or endpoint3, I need that code to be doSomething(author: Author) and not doSomething(author: AuthorWithEndpointOnesHints | AuthorWithEndpointTwosHints | AuthorWithEndPointThreesHints)

That is easily fixable: it's just a matter of extending a base type with more specific types depending on how you populated your entity.
const match = await em.findOneOrFail(Match, {});

that would return type Match which extends type AnyEntity.
const match = await em.findOneOrFail(Match, {}, ['site']);

that would return type Match & SiteProp which extends type AnyEntity.
const match = await em.findOneOrFail(Match, {}, ['site, creator']);

that would return type Match & SiteProp & CreatorProp which extends type AnyEntity.
If you have some generic business logic that accepts a Match type you will also be able to pass a Match & SiteProp or a Match & SiteProp & CreatorProp types because Match is a subtype of those.
The point is: how should the "generic" Match entity look like?
The first thing which comes to my mind is treating OneToOne and ManyToOne props as the union type AnyEntity | Reference. That would work great, but will have the annoyance that you will have to narrow the site and creator props down like this:
if (isRef(match.site)) {
  // Reference
} else {
  // Entity
}

Another -probably better- idea is to make Entities extend the Reference API: that way if you have a reference you can use the Reference API and if you have an Entity you can also use the reference API. If, for example, you will call the async load method on an already populated prop it will simply return itself but with a different type attached, no query needed. The advantage would be that you won't need to narrow the type down with if (isRef(prop)): it will be a Reference and you can treat it as a reference, but you will still be able to pass Match & SiteProp without the need for further changes.
On the contrary, if you want to make less generic code and take advantage of already generated props simply require the Entity & PropName as argument and you won't need to use the Reference API.
I think that would be the best of both worlds and in theory should be easy to implement, unless https://github.com/microsoft/TypeScript/issues/13995 ruins the party.

const match = await em.findOneOrFail(Match, {}, ['site, creator']);
that would return type Match & SiteProp & CreatorProp which extends type AnyEntity.

It's funny/coincidental that you say that: I have (~two months later) changed my prior-stated opinion on "meh just always code against the async/await .load() API and accept it as 'good enough' b/c it's always n+1 safe", because yeah, you guys are right, that gets tedious.
So I'm now doing basically exactly what you have here, with some slight variations (i.e. not literally Match & SiteProp & CreatorProp, but the idea is the same).
My "past-proof-of-concept-but-not-yet-in-production" approach is to have (using your Match example entity) Match.site be a Reference<Site> (i.e. not a Site directly) that only has a .load(): Promise<Site> API on it (so "default/generic Match" behavior is "you have to ask for .site/any collection/references to be loaded with an await), but if you use em.populate(match, ...some hint...) with a hint of 'site' or ['site', 'creator'], or { site: "matches" }populate hints, then theMatch.siteproperty you get back is type-intersected with aLoadedReferencethat extendsReferencebut adds a synchronous.get` method.
So then you can pass this around, i.e. to someBusinessLogic(matchWithSite: Loaded<Match, "site">), as a type to your various internal impl methods that can now (with the static guarantee that it's actually loaded) call match.site.get without the annoyance of await'ing every time it touches match.site.get.
See this test:
https://github.com/stephenh/joist-ts/blob/master/packages/integration-tests/src/EntityManager.populate.test.ts#L20
Here's a test doing multiple levels of load hints:
https://github.com/stephenh/joist-ts/blob/master/packages/integration-tests/src/EntityManager.populate.test.ts#L33
The mapped types that do this magic are here:
https://github.com/stephenh/joist-ts/blob/master/packages/orm/src/EntityManager.ts#L74
(Addressing my own original concerns from before: these loaded types, i.e. Loaded<Match, "site"> are still considered a sub-type of the original Match type as far as TS is concerned, so methods that take the vanilla Match will still accept a Loaded<Match, "site"> (but not the other way around, passing a vanilla Match into a method that wants a Loaded<Match, "site"> will be a compile error). Also, in terms of my original performance/N+1 concerns from my bad experience with a large Rails app, all of the populate calls are themselves dataloader/batch-loaded so should be N+1-safe even if they happen "several layers down" in the business logic.)

Started looking into this recently, sorry it took so long.
Currently thinking about having $ property added to the Reference interface dynamically that would serve as a getter for the real entity.
Here is updated example from @vimmerru:
class Reference<T> {
    constructor(private entity: T) {
	  // or we could have it as a getter and throw when not initialized
      Object.defineProperty(this, '$', { value: entity });
    }
}

type LoadedReference<T> = Reference<T> & { $: T };
type UnwrappedReference<T, K> = T extends Reference<infer U> ? LoadedReference<U> : T;

type Loaded<T, R extends keyof T> = {
    [K in keyof T]: K extends R ? UnwrappedReference<T[K], K> : T[K]
}

const users = [new User()];
const populated1 = populate(users, 'credentials');
const credentials1: LoadedReference<Credentials> = populated1[0].credentials;
const organization: Reference<Organization> = populated1[0].organization;

console.log(credentials1.$.email);
console.log(organization.$.name); // fails as not populated, so `$` is not there

const populated2 = populate(users, 'credentials', 'organization');
const credentials2: LoadedReference<Credentials> = populated2[0].credentials;
const organization2: LoadedReference<Organization> = populated2[0].organization;

console.log(credentials2.$.email);
console.log(organization2.$.name);

We already have a way to strictly type check the populate param (even nested) when provided as an object in v4:
const author = await orm.em.findOne(Author, 1, { populate: {
  books: { publisher: { tests: true } },
} });

So the last bit is to do the magic and infer the right types in right places. Which is basically what @stephenh already did in the joist-ts - and it looks amazing! Hope you don't mind if I try to take some inspirations from there :] Btw the "lens" way for populate is also interesting.

I really dislike programming by symbols, but I do like that it can be effectively 'defined'.

I was originally thinking about using the get method (its functionality could be implemented in load method) for this and having the dollar as alias, but that would be another breaking change and I must say I kinda like the dollar way (so I will most probably add it there anyway, the question is if we also have get method doing the same).
But we are targeting v4, so we can definitely afford to make that BC :]

get looks more like a method than a getter to me: if we have to choose a non-symbol getter I think unwrapped sounds better.

get would be a method for sure.

Hope you don't mind if I try to take some inspirations from there :]

Yep, np! I definitely got a big head start on joist-ts by liberally using mikro's ideas, EntityManager/find APIs, etc., so it's only fair for inspiration to be a two-way street. :-)

Spent the whole weekend trying to implement this. I kinda succeeded, but the solution is eating CPU madly (constantly eating 1 core when I open the test case, and it never goes down) and some validation is now broken (populate param is no longer properly type checked). Even when I simplify pretty much everything (e.g. keeping only 1 out of 4 ways to define populate, not even trying nesting).
Starting to feel like this is not really doable without codegen :/ Will give it one more try during next week, but I am already behind schedule and don't want to postpone v4 for god knows how long because of this.
It feels like the code itself is not the problem, but the inference is. TS goes mad without specifying the entity type explicitly. I guess it could work for repositories, where we already know the entity type...

@B4nan FYI on our projects we noticed that types inference for regular queries eats a lot of CPU already. Seems it is generic problem in typescript language server. For example, bug in Jetbrains https://youtrack.jetbrains.com/issue/WEB-43982

https://github.com/microsoft/TypeScript/issues/31248

Looks like this was indeed an error of mine. Found a typo on the populate type that was causing the circular reference (in the nesting support that I was not even testing yet), weird that it failed to report it. Now it does perform much better (still a bit heavy initially, but no 100% cpu usage, its more like ~20% for a brief moment, then it goes down to ~3%).

Just a brief update, this will require breaking changes in the entity definition, but the benefit should be much faster and more precise type inference. Namely I will need to require users to define a special property on every entity, pointing to its primary key:
@Entity()
export class FooBar {

  @PrimaryKey()
  id!: number;

  // ...

  [PrimaryKeyProp]: 'id';

}

This would allow to simplify a lot of the typings so I believe it will result in faster inference (both for the "is this T an entity" and for "what is the PK of this entity T" problems). It will also replace the PrimaryKeyType symbol required for composite keys. Another benefit is that it will allow to get rid of the PK type argument in IdentifiedReference and AnyEntity (and in general be 100% precise when it comes to inference of the PK type).

As an end-user I feel this is a bit annoying, because you can easily end up forgetting about the symbols.
As a developer I also don't like the fact that you're somehow "denormalizing" things (you already know which one is the primary key from the @PrimaryKey decorator).
But on the other end we already have to declare symbols for composite keys, so at least we end up with a more consistent API.
I also experienced the issues about primary keys inference first hand when developing the Mikro-ORM Dataloader, so if it makes things easier that's a good plus.
Regarding collections I think they should be type safe as well, meaning we should know in advance if they're already loaded or not (if that's what you were asking),

As an end-user I feel this is a bit annoying, because you can easily end up forgetting about the symbols.

You cant forget, as TS will complain about the entity not being valid without the key.

As a developer I also don't like the fact that you're somehow "denormalizing" things (you already know which one is the primary key from the @PrimaryKey decorator).

That is not really true, as there is no way to infer those keys based on decorators unfortunately (none that I am aware of).

Regarding collections I think they should be type safe as well, meaning we should know in advance if they're already loaded or not (if that's what you were asking),

The question was how to apply this type safety on collections. E.g. Should we remove the getItems() method and have it only on loaded collections? But that for me sounds like too bug breaking change...

I personally never used getItems because it doesn't enforce type safety, so I'm for dropping it on unloaded collections. Do you feel like there are any reasons to keep it? v3 had to have it because it completely lacked type safety, but getting rid of it personally sounds more like a feature rather than a breaking change.

Seems it is generic problem in typescript language server. For example, bug in Jetbrains youtrack.jetbrains.com/issue/WEB-43982

So it was again burning my cpu, tried to use vscode instead of webstorm to verify if it's about the type complexity or about webstorm itself. And it was blazing fast in vscode :D Updated to latest webstorm and it looks like now it's quite fast there as well...

@B4nan You might want to apply for the OSS license for Mikro and get the full IDEA Ultimate (free). I run the EAP versions (and use their Toolbox to manage things), so I'm always at the latest version. If you can't tell, I'm a huge fan of IDEA. =)

I do have that license already, and I use the toolbox :] Do you think it's worth using full idea ultimate instead of webstorm for TS only projects?
Btw it's still quite cpu intense in webstorm, tried EAP as well, looks even worse :D I guess I will need to simplify something. Tried using vscode for 5 minutes but that would be really hard downgrading :D Maybe it will be ok in normal projects, I am testing it on the EM tests that are >2kloc full of type inference...

Awesome... just wanted to make sure you're up to speed on the IDEA stuff.
Sorry about the speed stuff. =(

Tried using vscode for 5 minutes but that would be really hard downgrading

It was the same for me, it took years but I'm glad I did. Bad type inference was one of the biggest reasons why I wanted to switch (the other one was ram consumption).
Is it slow with the simplified codebase with PrimaryKeyProp or with the more complex one?

It's slow even after that change. I feel like the biggest problem here is still the FilterQuery. While it's great to have that kind of type safety it offers, it's simply too complex.
It handles all the possibilities, like for a m:1 property, you can pass:

the target entity instance
primary key of that instance

this now checks also composite keys as well as PK from FK (shared PK)
for string keys it also allows to use regexp
it also allows to pass strings instead of object id in mongo

array of primary keys
hash with known operators

Then you can have the m:1 as a Reference, same with collection items (another level of nesting). And this all happens recursively.
I see similar problem with the populate itself, as we allow multiple ways to define it:

em.find(E, ..., ['a'])
em.find(E, ..., [{ field: 'a' }])
em.find(E, ..., { populate: ['a'] })
em.find(E, ..., { populate: { a: true } })
em.find(E, ..., { populate: { a: LoadStrategy.JOINED } })
em.find(E, ..., { populate: [LoadStrategy.JOINED, { a: true }] })
em.find(E, ..., { populate: [{ field: 'a' }] )

Thinking about getting rid of 1., 2., 6. and 7. Getting rid of the populate vs FindOptions could help a lot with the inference of T, and it will be more readable anyway. It will also allow to remove lots of method overloads in EM and repository API. It will be quite huge BC, especially for me as I am using the "naked populate" param quite often :D But at leasts it will be all reported by TS compiler.
I guess I will give that a shot first to see if it helps, as I don't want to make such BC if there would be no real impact on the performance.

Wow, did you really plan to maintain 7 different syntaxes? Why do we need so many in the first place? I'm all in for breaking changes if they help to get a cleaner, simpler API.

There were only 2 ways up until now (v3) - 1. and 3., this all emerged from the joined strategy support and type safe populate param in general (as array of strings is not enough for nesting). It definitely needs cleanup :]

Currently revising the FilterQuery type, I managed to "simplify" it and improve the autocomplete there, but it appears to be totally unusable in webstorm. Opened an issue so let's see if they can do something about it.
https://youtrack.jetbrains.com/issue/WEB-46029
Current progress on this can be found in https://github.com/mikro-orm/mikro-orm/tree/type-safe-refs
It works quite well when it comes to the functionality and autocomplete, but as said, this is totally unusable in webstorm... Without the last commit (FilterQuery redesign) it was relatively usable, but the inference and intellisense on the Loaded type is still very CPU intense.
I was kinda postponing this mainly because I knew how slow it was when I originally introduced the FilterQuery type and I saw this coming... On the other hand, I though this is caused by TS, not by webstorm (which apparently wasn't true).

How is it going? Did you hit any new roadblocker?

Well, its slow and performance heavy, I feel like the additional breaking changes did not really help, so I would rather not do them (mainly the one with FindOptions everywhere). I also don't really like that [PrimaryKeyProp] thing...
I am currently postponing this, wan't to finalize few other things first, as this was so far really a time eater (already spent around 2 weeks on this one). Also waiting for more stable webstorm eap builds, the latest one was still not very good experience (tried to use it for some time even not just in this project to verify).
Maybe I will try to make things a bit less precise, maybe we don't really need infinite levels of nesting correctly typed and having fixed level implementation would be sufficient (personally I do population for 2-3 levels max, usually it's just one).
I also feel like the issue here might be the redesigned Primary<T> type, that is now really precise in what can be a primary key of given T, but that type itself was quite performance heavy.
It's really hard to measure here, I am not aware of any tools for performance debugging of complex TS types, but when I just watched the history of CPU activity, it was easily visible that with the EAP it was much worse (even without those changes, browsing thru the dev branch), and the latest stable has that inference bug.
Will first try to spend some time working on filters/scopes, as that is the last big feature I would like to have in v4.

I am currently more inclined to not merging it, it's still really slow, sometimes (quite often) the inference takes too long and TS just resolves to any. Working with the typed result is extremely slow, you basically don't get any intellisense so it kinda beats the purpose (yes, we still have strong type checking). Yes, its mainly about webstorm, but without this change it performs quite well.
To have this working, I believe we really need something like PrimaryKeyProp - or we would have to drop the support for IdentifiedReference (its purpose is to be able to do ref.id, instead of ref.get('id') - the type knowns about the primary key name and type). joist does not need to handle this as the PK there is restricted to be under key id and composite keys are not even supported, which simplifies the problem a lot. (not talking about joist using codegen to get around some TS limitations.)
I will maybe try to do a version without PrimaryKeyProp and IdentifiedReference, requiring users to do ref.get('id') to access the PK.
This is literally the last thing that holds me from merging #527 and shipping RC.

Got an idea how to simplify this, allowing at least the first level population - handling the nesting appears to be the problematic/performance heavy bit, so I commented that out. Also instead doing the PrimaryKeyProp thing and precise inference of the actual PK type, I just return Reference instead of IdentifiedReference from the Loaded type - it turns out we don't really need to handle the PK properties as the LoadedReference type is merged with the actual type, that is correctly defined as IdentifiedReference.
For simplicity I will keep it working only on single level with the array syntax for now, rest will be ignored. Better to have this simplified version than nothing.
This way there are no breaking changes (only the Reference.get() method that will now be available only on loaded references, like $) and it looks like it's fast enough to be merged. Will ship alpha.10 hopefully later today so we can try it in the real world, I still hope that the actual performance in real life files (that are usually smaller than the ORM test files) will be much better.

I did few more simplifications and also moved the testing code to its own file. It feels quite fast now, even with the nesting support enabled, so will ship that too. Let's see how it works, we can simplify later.

Let's test it, 4.0.0-alpha.10 is out.

@B4nan

We would still have to have something like $/get() even with codegen. Maybe you did not fully understand how it works - those are added on the runtime via TS, we need something like that to allow sync type safe path to the wrapped entity. Codegen would help only with preparing some types where we could easily infer what can be populated and what not - but that is working fine already without codegen (at least for Reference and Collection - we don't need it elsewhere).

Yeah maybe it's not clear for me. Isn't the issue here mostly about type checking? Making TS aware of the populated relationships, and mark everything else as never ?
Did the need evolve to support runtime checking as well? Because for a purely type checking solution there's no need to change what's actually returned by findOne and the likes.

It is about being able to tell whether a Reference or Collection is loaded, at the TS level.
// here publisher is a (nullable) `Reference` and tags are `Collection`
const book1 = await orm.em.findOneOrFail(Book, 1, { populate: ['publisher', 'tags'] });
expect(book1.publisher!.$.name).toBe('Publisher 123'); // the `$` is available only on loaded references - if you do not have the `publisher` in populate param, it won't be there
expect(book1.tags.$[0].name).toBe('t1'); // same applies to collections, if we did not have `tags` in the populate hint, this would not type check

Can you elaborate on that? Does that mean this could still work?

Yes, it still works the same, it's just about having the $/get() available on loaded references/collections. Nothing from the public API of collection changed, it's just about making TS aware of this information - whether its loaded or not - so you can write it typesafe (with the $). And if you do not use Reference wrapper, again, nothing changes, as this is only about References and Collections.
The thing is that with Loaded type, you can make sure other parts of your application also make sure that things are loaded where they should be. It's not really about the call site, where you clearly see the populate param. So in a service, you can define method that expects more than just a: Author, but a Loaded<Author, 'books'> - that way TS will warn when you try to pass an author without books populated.

Alright it's fine by me then, thanks for clarifying.

@B4nan
However would like to clarify a bit about the codegen proposal. I see you're open to it as long as it's optional, but just to make sure we're talking about the same thing:
During entity discovery, the engine would generate typings from entities relationships, it's dead easy thanks to the metadata. This could generate all the possible populate outcomes. (As well as queries, if that's needed).
In my playground it gives something along those lines:
interface AuthorPopulateReturnType {
  books: {
    books: Collection<ScalarsOf<Book>>;
  } & ScalarsOf<Author>;
  address: {
    address: ScalarsOf<Address>;
  } & ScalarsOf<Author>;
  'books.tags': {
    books: Collection<
      ScalarsOf<Book> & {
        tags: Collection<ScalarsOf<BookTag>>;
      }
    >;
  } & ScalarsOf<Author>;
}

The generated d.ts would then override the methods of EntityRepository to return a PopulateReturnType<Entity> based of the generated outcomes:

I think processing those types would be significantly faster for TS, especially if we generate queries types as well.

In that example/screenshot - if address is m:1 relation, this way you would require it to be populated just to access the PK of that address - instead of disallowing the access totally, we should have something like IdentifiedReference there (so a type where you can access just the PK(s), as that is known without the full entity).
I am also not really bought on the dot syntax in populate - this could exponentially explode if you want to generate all the combinations, even if we set the limit to 3 levels, it could be really lots of code (it still might be ok, just something to test properly in a realworld app with let's say 10-20 entities).
Also in that example you are using AuthorPopulateReturnType in the method definition, we need something generic (but that should be easy to achieve I guess).
In general, I would like to see this as a 3rd party thing, at least for the initial implementation.

I think processing those types would be significantly faster for TS, especially if we generate queries types as well.

Yeah most probably it would be faster as well as more precise, for sure. But you would have the overhead of generating the d.ts file on the fly, which for large codebase could be quite heavy itself - but again, something to test, it might work fine.
In fact the current metadata caching mechanism is pretty similar to the codegen approach, the only unknown for me is how to use this generated file, as I really don't like to let users use hard imports to generated files - prisma uses a meta package for this, where the types are stored, this could be also doable I guess.

Alright. It's a WIP on my mikro-resources package so for now yeah it'd be available as a 3rd party package. I will let you know once it's properly testable, although it's not really high on my priority list right now.
For sure the cached metadata was a genius move and there's a lot we can do with that.

Not sure if this helps you here, but TS4 seems to have some advances that might help...
https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/

https://github.com/microsoft/TypeScript/pull/40336
This may help to type relation paths.


The find() method cannot be called without any parameters

The example on the ngCordova site (http://ngcordova.com/docs/plugins/contacts/) shows a getAllContacts() method that uses the contacts' plugin find() method without any parameters. This doesn't seem to work. I am using Cordova 4.3, cordova-plugin-contacts 1.1.0, ngCordova 0.1.19 and Ionic 1.0.

This worked for me:
    var coptions = { fields: ['*'], multiple: true };
    $cordovaContacts.find(coptions).then(function(contacts) {
        $log.debug('CONTACTS:', contacts);
        }
    );

You'd have to show what you code you tried with the empty find that caused an issue. We're currently using the empty find and haven't encountered an issue with it.  See also, this commit: https://github.com/driftyco/ng-cordova/commit/ebac7e53f27ff3f839540757874f9d2cc088bf7c


docs: correct links, badges

Coverage remained the same at 100.0% when pulling 4b4f2b03ff9b534d88dccd9929cc72d0aee8ffbe on docs/update-links-badges into 52a5625aebca8046d55d1db6c4f4f052dd7014f2 on master.


Cannot create container for service data: network www_default not found

#docker -compose.yml
version: '2'

services:
  www:
    restart: always
    build: .
    command: tail -f /dev/null
    #command: npm run dev
    env_file:
      - .env.honestdev
    links:
      - mongo:mongo
    volumes:
      - ./:/usr/local/resly-web
      # use the node modules and bower already built with the package
      -
      # don't track dist
      -
    volumes_from:
      - data
    ports:
      - "3000:3000"
    expose:
      - "3000"
    networks:
      - public
      - private
    depends_on:
      - mongo
  mongo:
    image: mongo:3.3
    hostname: mongo
    volumes_from:
      - data
    ports:
      - "27017:27017"
      - "28017:28017"
    expose:
      - "27017"
      - "28017"
    command: --smallfiles --rest  --noauth
    networks:
      - private
  data:
    image: ubuntu:16.04
    command: echo 'Data Container'
    volumes:
      - /data
      - /data/db
      - /var/local

networks:
  public:
  private:

When run "docker-compose create", I can see above error(title).
Thanks

This looks to be an issue for docker compose, not docker. Can you

report this in the docker compose issue tracker (https://github.com/docker/compose/issues) instead?
when reporting, try to reduce your docker-compose.yml to the absolute minimum; it's possible there's a fault in your docker-compose.yml format
be sure to include version information (both of docker-compose, and docker version), and output of docker info

I'll close this issue here


Skip or merge on database export

I'm using the Export Data for migrating an old database to a new, and during this process I have some records in the new database that already exists. When the process hits the record that already exists, it raises an Unique Constraint exception, and is giving me a popup where I can choose skip or ignore.
Is it possible for DBeaver to say "skip all" or "merge all" when such a constraint is met, so I don't have to make an active click every time it happens?

i am very interested in this as well

already implemented


Support authenticated requests

Short version
Possibility to use authorization header in the htsget request
Longer Version
The python client for htsget (https://github.com/ga4gh/htsget) and the samtools support the possibility of sending a JWToken when making a request against the htsget server. It would be great if the htsget server would be able to pass this header (and possibly any other headers the user is providing) to the backend that will be handling the request.
Use case - Example scenario
The htsget server is used for accessing data that requires authorization. One scenario to support that would be to have a service between the htsget server and an s3 backend, which passes the files to htsget. This middle layer could check the JWToken against some authority, access the file in the s3 backend and serve it to the htsget server.

When htsget-rs passes the authorization headers to the backend, what gets returned to htsget-rs?

Does htsget-rs just have access to the files already, and simply needs a confirmation of whether the user is authenticated or not?
Is it the files themselves? I assume this wouldn't be the whole file, htsget-rs only needs the header and index to perform a search query. The backend would probably also need to be aware of the query id, in order to return the correct files?
Another option could be to return an AWS S3 key and bucket, which htsget-rs is expected to fetch and has access to.

The idea would be for the request to return exactly what it returns now. The proposed feature only enables for using an authentication service on the backend side (either on the S3 or as a service between the htsget server and the S3)

I guess that depends on the implementation. In our case, the service between the htsget server and the S3 backend is having access to the files, and through its endpoints, it provides access to the the htsget server, after authenticating and authoring the access. In general, I assume the authorization could happen either by a middle layer or by the S3 backend itself and they both require some kind of token for that?
I think that either the whole file or the header + the index file are possible. As long as there is a description of the expected format, it should be doable.
There are two issues here for our case: We are not using AWS S3 and we would like to avoid giving direct access from the htsget server to the storage, since it will be a user facing service

Does that make sense?

Yes it does. A few more clarifications/questions:

What's the protocol htsget-rs would use with the external service? HTTP/TLS?
Would it be possible for the external service to return URLs containing the files (e.g. something similar to AWS presigned URLs) that htsget-rs could fetch? We think this would fit nicely with implemented a feature that allows htsget-rs to perform queries using any HTTP URL (see https://github.com/umccr/htsget-rs/issues/134). This would also disallow any direct access to the storage.

I was thinking that the service could return serialized resolvers. This would enable flexibility to choose which URLs/files correspond to the query id.

To illustrate this a bit more - the external service could return something like:
[[resolvers]]
regex = '.*'
substitution_string = '$0'

[resolvers.storage.url] # This would be a new storage type.
file = "https://data.umccr.org/example.bam"
index = "https://data.umccr.org/example.bam.bai"

# Could have multiple files here for one authorization header.

[resolvers.allow_guard]
allow_formats = ['BAM']

This does not need to be TOML, and it could instead be JSON or another format. These URLs would be fetched by htsget-rs while performing the query. A query would return a reference to the URLs in the resolvers:
curl -H "Authorization: <JWT_TOKEN>" "https://htsget.umccr.org/reads/example.bam"

{
  "htsget": {
    "format": "BAM",
    "urls": [
      {
        "url": "https://data.umccr.org/example.bam",
        "headers": {
          "Range": "bytes=0-2596770"
        }
      },
      {
        "url": "data:;base64,H4sIBAAAAAAA/wYAQkMCABsAAwAAAAAAAAAAAA=="
      }
    ]
  }
}

The URL tickets returned by htsget-rs correspond to the URLs defined in the resolvers which htsget-rs got from the external service.


[Feature Request] ReactOS Support

First off, very nice project.
You may or may not know this but there is an open source reimplimentation of Microsoft Windows called ReactOS. Making special effort to get appget working under ReactOS might gain your project some visibility; it certainly deserves some.
The ReactOS project is currently in a late public alpha and is reasonably stable. I mention this because the project has long had its eye on building or adopting a package manager. It currently has a GUI-only stand-in for an eventual replacement package manager.
AppGet Testing Under ReactOS Thus Far

Testing was performed under ReactOS 0.4.10 in a VirtualBox VM.
Attempts to execute the installer failed with "Your operating system version is not supported" (or similar) error.
Enabling compatibility mode and setting the reported OS version to Windows 7 fails indicating the lack of an appropriate service pack.
You don't have build instructions documented (and I'm not super familiar with C#) so I wasn't able to build appget with the OS checks disabled just to see how far I could get.

I suspect the root cause is the fact that ReactOS reports its version kernel version as 5.2 instead of 6.0 or greater. The last post on this thread describes the canonical way to detect ReactOS is present instead of MS Windows. That post is a bit old, so these instructions could be dated.

So I've some time trying to get ReactOS running on a VM but can't get the network drivers to load correctly in hyper-v.
Anyways, most of the issues you've posted seem related to the installer system requirements, I would recommend copying the appget files from a windows system C:\ProgramData\AppGet\bin\ to a reactOS system and trying to run some of the commands and see what you get.
just keep in mind, whether or not we decide to support ReactOS really depends on how well it supports the packages in our repository.

So I've some time trying to get ReactOS running on a VM but can't get the network drivers to load correctly in hyper-v.

Yeah, you have to set the NIC to PCnet-FAST III to get it on the wire. ReactOS release 0.4.12 (which isn't out yet) adds support for Intel E1000 NICs, the default for most hypervisors.

just keep in mind, whether or not we decide to support ReactOS really depends on how well it supports the packages in our repository.

My mistake. I didn't realize that ReactOS lacked support for Dot NET out of the box; expected Mono (open source Dot NET) to "just work". I'll keep playing with appget on ReactOS, just to see if I can get it to work. But, you can close this.
If my testing exposes any appget bugs, I'll open a separate issue.