Handling of lazy="dynamic" relationships

Checklist

[X] The bug is reproducible against the latest release or master.
[X] There are no similar issues or pull requests to fix it yet.

Describe the bug
Model relations are automatically loaded regardless of the ModelView configuration, this causes issues with relationships defined as lazy="dynamic" because it ends up in InvalidRequestError( '%s' does not support object population - eager loading cannot be applied.) from sqlalchemy. The error is raised on any list or detail request.
The current workaround I'm applying is:

class ModelView(ModelView):
    def __init__(self) -> None:
        super().__init__()
        self._relations = [rel for rel in self._relations if rel.lazy != "dynamic"]

Steps to reproduce the bug
Setting up two SQLAlchemy Models and configuring a relationship between them with the lazy="dynamic" parameter should suffice
Expected behavior

Relationships not being listed as part of column_list or column_details_list are not eagerly loaded
Relationships with lazy="dynamic" are either ignored (short term fix?) or correctly handled (longer term feature?)

Actual behavior
InvalidRequestError causes the ModelView to be unusable for models with lazy="dynamic" relationships
Debugging material
Starlette Debugger.pdf
Environment

OS: Debian 11 (Bullseye)
Python: 3.11
SQLAlchemy: 1.4.44

Additional context
No response

I see this other issue explains this might not be handled soon, maybe this could be added to docs? maybe the workaround shown here can also be helpful for others 🤷

Hey @jarojasm95 ,
I think it might even be better to apply this change to automatically ignore the unhandled models.
As for the long term I'm still not sure how that would look like with AsyncIO extension: https://docs.sqlalchemy.org/en/14/orm/collections.html#dynamic-relationship

@aminalaee thanks for the quick reply!
I'd be open to putting up that PR if that sounds good to you

Yes, that would be great.

Bumping. Have this been adressed? I seem to have the same issue, no matter what lazyloading technique I use, the admin loads all relationships, even unused ones.


Improve unittesting for thenewboston_node.business_logic.storages.file_system.py:FileSystemStorage

Cover at least these cases if they are not already covered:

Each method coverage
All edge cases
All compression type choice on save
Decompression for each type of compression

@dmugtasimov Before I can proceed to unit testing itself some refactoring were needed. Please see the description here https://github.com/thenewboston-developers/thenewboston-node/pull/80#issue-614433274

@dmugtasimov Please see PR https://github.com/thenewboston-developers/thenewboston-node/pull/82

@andbortnik thank you. I merged it. I added a couple of minor comments to the PR. Feel free to fix them in any up coming PR. Move the task to done if we should consider it as such.

@dmugtasimov Minor fixes requested https://github.com/thenewboston-developers/thenewboston-node/pull/94

merged

@dmugtasimov Just another couple of tests and we can close the task https://github.com/thenewboston-developers/thenewboston-node/pull/96/files

@andbortnik merged, thanks


Possible problem generating session_uuids for analytics?

Description
There is a very large gap between the number of unique daily sessions counted in our analytics server versus the number of sessions and users tracked on Google Analytics. For instance, GA says there are tens of thousands of users and sessions today, while the analytics server only has ~160 unique session_uuids. Could you check the implementation of this feature?
What I'm seeing now is a very large number of searches distributed between this small number of sessions, which doesn't seem right.
Reproduction
Does not apply
Expectation
Every time the user opens CC Search in a new tab, the frontend should generate a session_uuid and preserve it throughout the session. Any action the user takes on other pages, like clicking an attribution button on a detail page, should use the same session_uuid. session_uuid generation should be handled entirely client side; no two users should have the same session_uuid. When the user closes CC Search, the session_uuid should be erased from client side storage. Next time the user opens CC Search again, a new session_uuid should be generated.

The usage analytics shares session id logic with the A/B test code, which seems ill-advised to me. The session ids are stored in a cookie for 7 days.
There may be additional issues with the Google Analytics tracking that further complicates the issue, but diagnosis there is still pending.

@obulat
The UsageDataService methods that accept a sessionId parameter currently use state.sessionId, a cookie that expires after 7 days. We want to use a new cookie that expires at the end of the user session.
Similar to the logic in abTests/lib/sessionId.js please replace all instances of state.sessionId in src/store/search-store.js with a new cookie USAGE_SESSION_ID, that has no expiry. A cookie without an expiration will expire as soon as the user's session ends.
You can either store the cookie in the vue store or just replace the state.sessionId calls with inline logic like this: Cookie.get(USAGE_COOKIE_NAME) || Cookie.set(USAGE_COOKIE_NAME, uuid()).


Review package description for the official .NET package manager nuget.org

Before we publish a new version of the package to nuget.org, we should get some green lights regarding the package description that will be shown there.
This is the current version: (from project.json)
{
  "summary": "A .NET implementation of the OpenTracing API.",
  "description": "This library is a .NET implementation of the OpenTracing API. To fully understand this platform API, it's helpful to be familiar with the OpenTracing project and terminology more generally.\r\n\r\nFor the time being, \"mild\" backwards-incompatible changes may be made without changing the major version number. As OpenTracing and opentracing-csharp mature, backwards compatibility will become more of a priority.",
  "authors": [ "The OpenTracing Authors" ],
  "projectUrl": "https://github.com/opentracing/opentracing-csharp",
  "iconUrl": "https://avatars0.githubusercontent.com/u/15482765",
  "licenseUrl": "https://raw.githubusercontent.com/opentracing/opentracing-csharp/master/LICENSE",
  "tags": [ "opentracing", "distributed-tracing", "tracing", "logging" ],
  "repository": {
    "type": "git",
    "url": "git://github.com/opentracing/opentracing-csharp"
  }
}

@bensigelman @dawallin @yurishkuro - It would be great if you could give your feedback and CC other people who should be involved in this.

@cwe1ss I think that generally looks good. Do you need/want an email address? I think we have a barely-used one for OT committers which would be appropriate here. (For credential recovery, etc)

The email address does not show up here but it is instead added to the nuget owner account. Right now it is my email, maybe we should change it to a OT owned one.

Maybe it would yet be best to have co-owners on the packages?! We could change the email address of the current "OpenTracing" account to an official address and have you and me as co-owners with our own email address. This way, we don't have to share passwords and whoever owns the official OT email address would always have a way to get access to the packages should you or I be unavailable.

I think this sounds like a good idea. I added myself as an co-owner. I didn't know your name @cwe1ss so you have to add it yourself. @bensigelman, do you have an open tracing email we use for the OpenTracing nuget user? Me and @cwe1ss will have separate access so it is only that the OpenTracing organization can use it as a backup.

I added myself as well. We'll close this issue once we have changed the email address of the OpenTracing account.

@cwe1ss @dawallin<EMAIL_ADDRESS>is an alias I have access to for "emergencies", etc. Good idea, thanks!

@bensigelman I added the email above to the gravatar account (needed for nuget). You should have received a verification email. Once this is done I can change the email on the nuget owner.

@cwe1ss I added you as co-owner of the BasicTracer nuget.

@dawallin I tried to do the gravatar thing and got:

Grr, how annoying! Maybe try to find me on Gitter when we're both online and we can get the transaction done quickly.

@dawallin @bhs has this ever been resolved?

@cwe1ss I am as ignorant about the .NET/C# ecosystem as I was a year ago... that said, I do not see any nuget stuff in my inbox from around the time of this issue. If I can help with anything, please let me know.

We have now transferred the ownership of the OpenTracing nuget account. This issue can be closed.

awesome, thank you.


refactor: bump pyright to 1.1.333

Summary
Bump to Pyright 1.1.333. This makes changes to application_commands.py to support the fact that ellipsis is @type_check_only. Range and String need to support type checkers properly with Annotated and such, but this is a patch for now to bump to latest Pyright.

This is a Code Change

[x] I have tested my changes.
[x] I have updated the documentation to reflect the changes.
[x] I have run task pyright and fixed the relevant issues.

Care to resolve conflicts with the base branch

This may be increased to 340 as that is out, but it is producing some wild errors (thinking TextChannel is a TypeVar?, unnecessary type ignore which complains when I remove it, ...) on my laptop, so I will try again on desktop.

Any updates? Latest version is now 1.1.369.

Closing this to get it out of the list, there are so many versions that basically make all these changes irrelevant.


fix bug: all records in app table may be overwritten during deploy under some conditions

eg. exceptions occured, assert failed, might be other conditions as well.
Fixes Issue #218.

good job!✌


fix: #504 laravel + websockets: Unhandled promise rejection with TypeError

#504

@SocolaDaiCa thanks for trying to fix the issue reported in #504 :+1:
I just gave an explanation in #504 why this isn't really a bug in our HTTP component and should be reported downstream in https://github.com/beyondcode/laravel-websockets instead.
I can totally understand the reason behind this pull request, as it makes sense that we should support  Throwables instead of just exceptions. Raising the PHP version from PHP 5.3 to PHP 7 is at least a BC break and I don't think we want to go this step for the current v1.
We're currently working on ReactPHP v3 which will raise the minimal supported PHP version to PHP 7.1 anyway, so I think we might want to take a look at this over there. We also have plans to improve the error reporting for v3, so I think we will pick this up in the upcoming weeks/months. The v3 roadmap ticket for HTTP is still outstanding but will drop soon.
With all that said, I'll close this ticket for now and we'll have a look at this as we move forward with ReactPHP v3 :rocket:


Issue #SC-0000 feat: code changes for samza lag computation enhancement

Codecov Report

Merging #489 into release-2.2.0 will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             release-2.2.0     #489   +/-   ##
================================================
  Coverage            31.99%   31.99%
  Complexity            1210     1210
================================================
  Files                  172      172
  Lines                15116    15116
  Branches              2396     2396
================================================
  Hits                  4836     4836
  Misses                9557     9557
  Partials               723      723

Continue to review full report at Codecov.

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


Could you please add CS, IP register?

As we know, 8086CPU has 14 registers, but 8086-emulator-web lacks both of CS and IP.
I want to verify this theory that jmp ax:bx semantically equivalent to execute mov cs,ax & mov ip,bx.
Could you please add CS & IP? Or just tell me why this emulator does not include CS and IP.

And it seems do not support all feature of jmp command,

ref: wiki-JMP (x86 instruction)

Hey,
Thanks for using the emulator!
So the answer for both of your questions is same : it is because the emulator does not translate the instructions to an actual bytecode.
The way emulator works now, is in first pass it converts the code to a simple intermediate representation, which is text based. Then instead of converting that to bytecode, which would be stored in memory, the actual running of program is done directly from this text-based IR, where each instruction is parsed and evaluated each time it is to be run.
Ideally, the IR should be converted to a bytecode which then should be stored in the memory ; but when making this, we could not find a definitive definition of Hex codes for 8086 assembly. The few sources which we found seemed to disagree with each other and did not cover all the instructions, so we kept the IR text-based. (We could have defined out own bytecode, but we didn't).
Thus we cannot actually store the instructions in the memory like the data is stored. Hence there is no meaning of CS and IP, as we cannot treat any place in memory as the "code" segment, and the IP is maintained internally by the emulator, and it should be modified.
For the same reason, the jmp instruction only supports jumping using labels, as any memory address given explicitly or in register cannot be an instruction address.
In case you have any idea about 8086 asm hex codes, we can try implementing that, or if you have any idea of making a consistent bytecode for all ~100 instructions, please feel free to mention!

Thx for your replying.
Your project is awsome. When the code work with memory, I found it does not work well. Such as mov [0],cx, cs:ip.
The implementation details you gave us tells me the reson why such type of code does not work well.

Your project is awsome

Thank you!

When the code work with memory, I found it does not work well. Such as mov [0],cx, cs:ip.

For the reasons explained above, cs and ip will not work in code. For the mov [0], cx example, it will give error because you need to explicitly tell that the memory you are giving the address of should be treated as byte or word. That way mistakenly using cx which is a 16 bit register when you wanted to move 8-bit value is prevented. The correct syntax for this in the emulator is mov word [0], cx.
You can check out the instructions page on the website : https://yjdoc2.github.io/8086-emulator-web/help for details of the instruction syntax. This lists all the instructions, and the operands supported by them. For example , for move :

This specifies, that for mov instruction using memory as one of the operand, you need to add "byte" or "word" in front of it.
Hope this will be helpful.


Beta 14 update

Hi there! Do you plan on updating this to Beta 14 anytime soon?
Thanks

Thank you!


Does caravel support data visualization on specific contry?

I want to plot the data with granularity of states not countries. Does anybody know how to configure it or how to extend it?

If you are talking about the world map  you have to extend it as we don't have  that data in caravel. See WorldMapViz in viz.py.

Got it. Thank you.


Support includePrivatePreviews of ComposablePreviewScanner

close #441

@sergio-sastre Thanks as always. I've added support for includePrivatePreviews. I also did a little refactoring to avoid making breaking changes. I would appreciate your opinion. Do you have time to review this?

@sergio-sastre Thanks as always. I've added support for includePrivatePreviews. I also did a little refactoring to avoid making breaking changes. I would appreciate your opinion. Do you have time to review this?

Sure! I‘ll find some time today in the evening 😉

You could simply extend the interface with
fun getPreviewOptions(): Options = defaultOptionsHere

Thank you for the great advice. I applied it, and it allowed us to pass the JUnit test rules from users.

Thank you for your reviews. I'll merge and release this.


The Windows installer (a.k.a the 🐘 in the room)

So for some unknown historical reason node core has a Windows installer (probably to appease the MS gods)...
After a recent conversation with @ljharb, IMHO the installer should be in this WG's focus, since it's essentially a "management-challenged" version manager....
We are fielding issues as:

Allow multiple installs of Node on Windows with msi
Stop the installer deleting my symlink for AppData\Roaming\npm
Windows installer: Per user install (feature request)
and the list goes on...

Which bring up the same issues that are discussed here, like:

where do we put the global node_modules?
Should we install npm or not, and where?
Does core want to officially support side-by-side multi-version, and if so how to switch versions (i.e. version manager yes or no)?
How to detect which version are installed?

Not to diminish from this WG's efforts in the least, and not intending to step on anyone's toes!!!
It's just that our questions are less "academic" since they are motivated by issues opened by users, since the Windows installer is unfortunately an existing core feature 🤦♂ So we need to answer them sooner rather than later...
BTW: Personally my prefered answer would have been "The Windows installer is deprecated, use the zipped package or a userland version manager" but it got push-back https://github.com/nodejs/node/issues/4603#issuecomment-313275229
/cc @tniessen @nodejs/platform-windows

Fwiw the osx installer is in equal disarray
Have you seen nodejs/installer?
On Jul 14, 2017 12:18 PM, "Refael Ackermann"<EMAIL_ADDRESS>wrote:

So for some unknown historical reason node core has a Windows installer
(probably to appease the MS gods)...
After a recent conversation with @ljharb https://github.com/ljharb,
IMHO the installer should be in this WG's focus, since it's essentially a
"management-challenged" version manager....
We are fielding issues as:

Allow multiple installs of Node on Windows with msi
https://github.com/nodejs/node/issues/4603
Stop the installer deleting my symlink for AppData\Roaming\npm
https://github.com/nodejs/node/issues/7882
Windows installer: Per user install (feature request)
https://github.com/nodejs/node/issues/13830
and the list goes on...
https://github.com/nodejs/node/issues?utf8=✓&q=is%3Aissue label%3Awindows label%3Ainstall

Which bring up the same issues that are discussed here, like:

where do we put the global node_modules?
Should we install npm or not, and where?
Does core want to officially support side-by-side multi-version, and
if so how to switch versions (i.e. version manager yes or no)?
How to detect which version are installed?

Not to diminish from this WG's efforts in the least, and not intending to
step on anyone's toes!!!
It's just that our questions are less "academic" since they are motivated
by issues opened by users, since the Windows installer is unfortunately an
existing core feature 🤦♂ So we need to answer them sooner rather than
later...
BTW: Personally my prefered answer would have been "The Windows installer
is deprecated, use the zipped package or a userland version manager" but it
got push-back nodejs/node#4603 (comment)
https://github.com/nodejs/node/issues/4603#issuecomment-313275229
/cc @tniessen https://github.com/tniessen @nodejs/platform-windows
https://github.com/orgs/nodejs/teams/platform-windows
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/version-management/issues/16, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAecV0pyiI6pYJZy0SazNTJ4A22Etuujks5sN06YgaJpZM4OYIi6
.

Fwiw the osx installer is in equal disarray
Have you seen nodejs/installer?

Ohh yeah sorry I meant to mention the osx installer.

Have you seen nodejs/installer?

I keep forgetting it... But again it has the benefit of cooking behind the scenes while the Windows and osx installers are out there causing headache...

So fwiw this is pretty close to the conclusion we reached at at the last
collaborators Summit
We need to completely overhaul our installers, and likely move towards a
version manager.
Likely move away from /user/local, and try and standardize where stuff
loves to make it easier to move between tools!
The latest work has been happening in the installer repo, but we should
perhaps make a more directed effort. This should like be a joint effort
between build and release
On Jul 14, 2017 12:21 PM, "Refael Ackermann"<EMAIL_ADDRESS>wrote:

Fwiw the osx installer is in equal disarray
Have you seen nodejs/installer?
Ohh yeah sorry I meant to mention the osx installer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/version-management/issues/16#issuecomment-315336236,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAecV6SqOkNVtjphjrfpIPWL5_ytZfUmks5sN08jgaJpZM4OYIi6
.

Hey, I think our install should have the following properties:

Installable from package managers on the 3 biggest platforms (choco on windows, brew on linux, apt/pacman/whatever on linuxes).
Installable as an installer on Windows and Mac where this sort of installation is popular. For what it's worth the windows/mac installers do a pretty good job today - and for the 95% of users they work pretty well.
A standalone installer would be nice (that doesn't touch anything global) for all three platforms - personally I just grab the source and build when I need this but I don't think many users do that.

I think it's worth saying that overall our installers - while in disarray - work pretty well. Especially compared to other platforms and stacks (installing Node is much simpler than installing Python+Flask for example which is one of the simpler stacks).
I'm -1 on any option that doesn't include NPM as well (since it is a vital tool for developing Node.js with our small core). I'm fine with revisiting letting the user pick a package manager - but honestly NPM works well enough for most users with most use cases IMO anyway.

@refack a replacement has to happen in the background... I have yet to hear
of a sustainable way of building on top of what we currently have. I
totally support driving more aggressively towards this happening, we just
need people to invest time
On Jul 14, 2017 12:32 PM, "Benjamin Gruenbaum"<EMAIL_ADDRESS>wrote:

Hey, I think our install should have the following properties:

Installable from package managers on the 3 biggest platforms (choco
on windows, brew on linux, apt/pacman/whatever on linuxes).
Installable as an installer on Windows and Mac where this sort of
installation is popular. For what it's worth the windows/mac installers do
a pretty good job today - and for the 95% of users they work pretty well.
A standalone installer would be nice (that doesn't touch anything
global) for all three platforms - personally I just grab the source and
build when I need this but I don't think many users do that.

I think it's worth saying that overall our installers - while in disarray

work pretty well. Especially compared to other platforms and stacks
(installing Node is much simpler than installing Python+Flask for example
which is one of the simpler stacks).

I'm -1 on any option that doesn't include NPM as well (since it is a vital
tool for developing Node.js with our small core). I'm fine with revisiting
letting the user pick a package manager - but honestly NPM works well
enough for most users with most use cases IMO anyway.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/version-management/issues/16#issuecomment-315337959,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAecVw8tyHDsK8K9r6XODAvBpKCaIBLZks5sN1G8gaJpZM4OYIi6
.

@refack a replacement has to happen in the background... I have yet to hear

Agreed, my question is what do we do meanwhile? Improve the existing installers? Recommend userland VerMan (nvm / nvs) ? Say: wait for "The Installer"?
BTW: As I see it any work we do meanwhile on the windows (MSI) installer, could and should be harnessed the "The Installer" and any VerMan

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.
(Of course - I agree that we can do a better job with both the installers and I think you're doing an amazing job being on top of the windows platform, the installer, and issues people have - which historically Node didn't do as good of a job with as other platforms.)

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.

Our (@tniessen and I's) efforts are not to replace, but only to improve the existing Installer

There are geniune problems with the widows installer regarding how it
handles the non directory and inability to remove files. We are also
limited in expanding functionality.
On Jul 14, 2017 12:52 PM, "Refael Ackermann"<EMAIL_ADDRESS>wrote:
@refack https://github.com/refack I'll just say this clearly one more
time - I don't think the situation with the windows installer at the moment
is all that bad - and neither is the situation with the macOS installer.
I'd like any new installer you work on to be at least as easy to use as the
existing installers since environment set up is a huge problem in my
experience for new users.
Our (@tniessen https://github.com/tniessen and I's) efforts are not to
replace, but only to improve the existing Installer
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/version-management/issues/16#issuecomment-315341323,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAecVwrvW3T6yUZQn2HAg0kO-J2SVJANks5sN1Z-gaJpZM4OYIi6
.

There are geniune problems with the widows installer regarding how it
handles the non directory and inability to remove files. We are also
limited in expanding functionality.

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.

Just to add, Installers are hammers not surgical scalpels. They assume stuff about your system, and they read/write/delete system files in an irreversible way. Any bug can lead to a catastrophe for the user.
(biased and not 100% correct list, but totally real)

Node install destroyed PATH
Installer puts down npm 4.5.0, not 5
nodejs LTS v6.10.2 Windows installs give npm version 1.4.2 instead of 3.10.10
Windows installer can corrupt its npm installation
Win64 .msi install breaks Windows Explorer.

I think I can say, without a doubt, that whatever version management solution we end up eventually coming up with and shipping as part of node will have the following characteristics:

works on every officially supported platform
can install multiple versions of node at a time, and switch between them on a systemwide/per-shell/per-invocation basis
is sufficient to replace any other form of installer (even if other means remain, like untarring and make/configuring)
can elegantly handle permissions issues, including providing a mechanism to fully function without any special privileges

I'm sure there are more things that can go on this list, but that's just some things off the top of my head.
Other thoughts:

the global node_modules must not be shared across node versions; every version of node needs a separate reinstall of packages, for compilation reasons if nothing else (there's also packages that dynamically load different JS based on which node version it's running in, and this could easily happen at postinstall time too).
npm comes with node always. It should never be installed separately, and it should always start out initially as whatever version ships with that stock node version. If people want an option to npm install -g npm at the same time, that's great, but that should be the mechanism by which it's upgraded.
side-by-side different versions is version management, and should not be supported until the solution mentioned above is ready. Side-by-side of the same version is a weird use case, so I'm not sure it should be supported at all, but if so, it'd also be version management.
node -v detects which version is installed.

I think there are two important questions that need to be answered before we can move forward to proposing solutions:

Is it a requirement that Node installers use the OS-specific installation technologies? For Windows, many people, especially system administrators, expect software to be delivered via MSI packages. MSI installers have consistent command-line options, can be logged, inventoried, deployed via group policy, etc. I'm less familiar with installers on the Mac, but I'd imagine there are similar considerations. Are there benefits of moving away from the OS installation technologies that would outweigh the drawbacks?

Should Node installers participate in / be aware of version management? Currently version manager tools do not actually use the platform specific installer packages; they always download and extract the .tar.gz/.zip packages directly (as far as I know). And then the version-manager needs special-case logic to deal with any Node version that might have been installed separately.

Everything written here is my option and open to debate 👐
Preamble: I don't like the Windows MSI installer. I think it's unfortunate, but we're stuck with it. It being a part of core is doubly unfortunate. Ideally it would have been a 3rd party product like nodesource/distributions, nvm or nvs. Less ideally but better then the status quo, it should be a separate project like libuv, or npm and not an afterthought of core.
I think this WG's existence is indicative of that we can all agree that an Installer's requirements and knowledge-base is very different from those of the "pure" node platform.

@ljharb, My perspective re the state of current Windows installer

the global node_modules must not be shared across node versions;

This is not true for the current installer, hence a bug need fixing.

npm comes with node always.

Why? (not arguing I'm just lacking context).

side-by-side different versions is version management, and should not be supported until the solution mentioned above is ready.

That's a bit of a pickle. In that sense the Windows Installer already is a de-facto degenerate VerMan. Which we need to keep supporting...
I need to split some hairs here, regarding "enabled" vs. "supported". Side-by-side versions is a scenario that has always been enabled and maybe even supported, and has great value. e.g. my computer:

IMHO the Installer could enable that (even as an undocumented feature not "Officially" supported) just by working right. I agree that it's not a scenario that we want to "Support". But I don't see a reason not to enable it. Let's discuss...

node -v detects which version is installed.

A corollary of (3)... I'm not sure I see the significance of that. As I see it the bare node command is just a convenience...

@jasongin

Is it a requirement that Node installers use the OS-specific installation technologies?

Unfortunately MSI use is grandfathered in. Even if the VerMan will not use the MSI, AFAICT the MSI will have to continue being available. Maybe we could spin it off as a sub-project... I don't know, but hope...

Should Node installers participate in / be aware of version management?

I see no reason why not, even ad hoc. Using a global registry like in PEP514, or a some other means of discovery.

Oooffffff that turned out long...
To sum. INHO we (node-core) are already in the version management business like it or not 🤷

Is it a requirement that Node installers use the OS-specific installation technologies?

I would assume so, yes, you have outlined very good reasons yourself.
@refack and I started to work on a solution for https://github.com/nodejs/node/issues/4603, which has been open for 1.5 years without any progress.

Should Node installers participate in / be aware of version management?

Not necessarily IMO. The problem discussed in https://github.com/nodejs/node/issues/4603 is not that there is no way to switch between different versions, users can do that on their own. But our current MSI actively prevents different node.js versions from being installed at the same time, so users need to do the whole setup on their own as soon as they want to install multiple different versions, including permissions, npm and PATH configuration.
Our idea was to identify each node.js release as a separate "product" (MSI terminology) and put these products into folders C:\Program Files\nodejs\<version>, each having its own node_modules. Each version can be installed, modified and uninstalled independently, without having to use any kind of version manager, not even to set the PATH.
@ljharb suggested not to do any platform-specific work in this area, so we were curious about this WG's plans to solve the problems on Windows in the foreseeable future.

Our idea was to identify each node.js release as a separate "product" (MSI terminology) and put these products into folders C:\Program Files\nodejs<version>, each having its own node_modules. Each version can be installed, modified and uninstalled independently, without having to use any kind of version manager, not even to set the PATH.
@ljharb suggested not to do any platform-specific work in this area, so we were curious about this WG's plans to solve the problems on Windows in the foreseeable future.

Transcript of @tniessen and I's conversation https://gist.github.com/refack/e9d1371a1c2530b7ff48a432fafea1af

@refack Intentional enabling is support - as opposed to unintentional enabling.

npm comes with node always.

Why? (not arguing I'm just lacking context).

Because that's how node works, modulo the option to exclude npm - npm also requires node, so it doesn't make sense to install it without node, and npm is node-version-sensitive, so it's important to correlate npm and node versions. There's just no scenario where you need npm without node (altho there may be scenarios where you want node without npm).

That's a bit of a pickle. In that sense the Windows Installer already is a de-facto degenerate VerMan. Which we need to keep supporting...

Things that are unintentionally enabled aren't things we necessarily need to keep supporting.

That's a bit of a pickle. In that sense the Windows Installer already is a de-facto degenerate VerMan. Which we need to keep supporting...

Things that are unintentionally enabled aren't things we necessarily need to keep supporting.

I'd be very happy if we can get consensus on that 👍

Because that's how node works, modulo the option to exclude npm - npm also requires node, so it doesn't make sense to install it without node, and npm is node-version-sensitive, so it's important to correlate npm and node versions. There's just no scenario where you need npm without node (altho there may be scenarios where you want node without npm).

A bit of an academic discussion if we agree that the global node_modules has to be in 1-1 correlation with an installed node version but...
In MSI terms one can define a dependency chain where one "product" (in this case npm) can only be installed by another product (in this case node), but later could be uninstalled/fixed/updated independently. If the parent is uninstalled that propagates to uninstalling the dependant.
That seems to describe our case very well, and it may solve some implementation details with the Windows installer, so we would like to keep that option open.
This also might give a better sense of the responsibility boundary between node and npm...

If node is uninstalled, npm will stop working.
npm can't exist independent of node, and it makes no sense to try to create a world where that's the case.

If node is uninstalled, npm will stop working.
npm can't exist independent of node, and it makes no sense to try to create a world where that's the case.

Yes agreed, but we can enforce that via MSI product dependencies.
Just an example, for stuff currently installed on my computer:

Two kinds of dependencies:

If I "Uninstall Visual Studio 2017" it will automagically uninstall "Resharper" (no user prompt, except for if I want to keep the user settings or purge)
If I try to uninstall one of the "C++ Runtime redistributables" it will warn me that uninstalling will break "Visual Studio"

P.S. it's also an example of side-by-side versions:

I think only npm should be managing npm; so I wouldn't expect npm to show up in that installed program list.

I think only npm should be managing npm; so I wouldn't expect npm to show up in that installed program list.

I assume you mean node in the first use of npm.
That's the debatable point since npm is managed by npm.com but it does not appear in the "Installed Programs" 😉 even though it's simply piggy backing onto the node installer.
But I'm not gonna bike-shed over that until I see an immediate and substantial benefit in splitting them.

So I guess the real question is, is "side-by-side installation" something node core officially supports (prior to any version management scenario), or merely enables (inconsistently across platforms)?
If the former, then obviously the Windows installer should add it, and there should be documentation for every platform on how to do it - and then a number of other questions in this thread become relevant.
If the latter, however, then it's totally fine if one platform enables it and another does not - because it's out of scope for node core - and the rest of this thread is moot as it relates to current node policy.
I'd argue it's solidly the latter - does anyone believe it's the former?

we can enforce that via MSI product dependencies.

Visual Studio has a sophisticated external installer that orchestrates all the MSI dependencies. (I worked on parts of it ~10 years ago.) That functionality is not at all a built-in to MSI. So it would take considerable work to replicate.

I'd argue it's solidly the latter - does anyone believe it's the former?

My personal 2¢ - we should make the installer as minimal as possible while still being consistent. There are a few features it has I would actually love to deprecate. If we have consensus around that I'd be happy to convey that to the users and point them to best-of-bread userland solutions.
Re: side-by-side (SxS) I have no problem disavowing "SxS Installation" but "SxS existence" is a super important feature (implying 0 global state).

So I guess the real question is, is "side-by-side installation" something node core officially supports (prior to any version management scenario), or merely enables (inconsistently across platforms)?

Neither of these options would prevent the WIndows installer from allowing side by side installation, would it? It does not make the situation worse than it is (a sfar as I know), so I don't fully understand your antipathy to this.

@tniessen yes. Intentionally adding support for something is very different from it having been an emergent property. If something is not "supported", then it must not ever be added intentionally, but it also need not be removed if it happens to exist.

To clarify; intentionally adding support for a feature makes it supported.

Meaning:
👍 True
👎 Bad
😕 Not happy that it's being true

If something is not "supported", then it must not ever be added intentionally, but it also need not be removed if it happens to exist.

Okay, I see your point. Then I guess it is up to this WG to decide whether side-by-side installation on Windows should be "supported" or the current behavior should be kept, effectively actively preventing the installation of different versions. Even with third-party version managers in place, IMO side-by-side installation on Windows using official MSIs is justified.

If something is not "supported", then it must not ever be added intentionally, but it also need not be removed if it happens to exist.

Why can't you ever add something that's unsupported? We have an entire class of core APIs that are experimental (i.e. unsupported), and that stance precludes us ever testing anything before we ship a stable version. I'm also not sure why it matters if you meant to add something.

Things that are unintentionally enabled aren't things we necessarily need to keep supporting.
To clarify; intentionally adding support for a feature makes it supported.

If a significant number of people rely on a feature it basically becomes supported no matter what the original intent was (or whether it was accidentally added).

So I guess the real question is, is "side-by-side installation" something node core officially supports (prior to any version management scenario), or merely enables (inconsistently across platforms)?

I think it's something that node core is considering officially supporting, as it's clearly a very common use case (hence this Discussion Group right?) However we'd definitely want to experiment first.

@gibfahn surely it's intended to be supported in some sense; my question is, prior to the VM group releasing something is it something node core wishes to support?
My guess is no.
Regarding experimental apis, installer features aren't APIs, so it's a different beast.

I did some complex Windows MSI package 15 years ago... I can't believe that you can't more easily build one today for Node !

@doodadjs please reconsider your comment as I don't feel it adds something constructive to the discussion. Node is already installed by an MSI installer - and this discussion is about how doing a better job with edge cases (like multiple installs) and is about specifying behavior.
If you have extensive experience with windows packaging - I would love it if you weighed in on the issues discussed above.

@benjamingr By reading the comments, I had the feeling that people wanted no MSI at all
My experience with MSI is very old. But I remember you can group things in modules (don't remember the exact term) then include them in MSI. Everything has a UUID that you must keep, or sometimes discard. I also remember that you can embed executables and call them in your MSI. You can also build interfaces, etc., etc. But like I said, that's 15 years ago.

I'm probably barging in here, but considering what I went through these past 2 weeks just trying to set up Node on a Windows machine that will need to build multiple native modules  at a new client of mine, I'd say the Windows installer should probably include an installation of all required build tools (windows-build-tools project just isn't enough), this should probably include the c++ redist package, python 2.7 and the MASM files (ml64.exe. and ml.exe with their dependent dlls).
It was a nightmare finding working solutions on the web and setting them up correctly (especially the MASM files which get installed only if you create a VS c++ project and add the correct build dependency)
I know it sounds like I'm whining, and that's because I AM. Seriously, "ease of use" should still be a priority, shouldn't it?

@RobiFerentz i don't think you'll find any disagreement on any of that :-D but I think that's probably tangential to the question of whether the Windows installer should be able to install multiple versions at once; your comment seems more about how well it installs one version.

@ljharb I know, but whatever decision is made, I think there are more pressing issues with Node on Windows than single or multiple version installations  (besides the actual idea of developing a node app on windows which in itself is problematic :gun:).

@RobiFerentz have you tried windows-build-tools? It was created by Microsoft employees to try to ease the pain of setting things up on Windows. It's documented in the node-gyp README, but it should probably be somewhere more prominent, like the website.

@ljharb @RobiFerentz - no arguments... the pain of native builds is substantial. One factor that we may need to consider within this group is if and how native build tools traverse different versions and architectures.
For example, Windows still needs to support both 32 and 64-bit architectures. For native modules, supporting both architectures per version can potentially mean a huge amount of build tool redundancy (multiple versions of VS for older versions, isolating windows-build-tools per version). This can (at least with older versions of node) translate to a large footprint of unusable levels.
While I agree the pain @RobiFerentz addresses focuses on a single version, the problem compounds with multiple versions. I fear we're treading in "shared global node_modules" territory, in the sense that sharing build tools would be more efficient (if it could even work), but opens a floodgate for potential problems.
I don't have a good answer for this, but I do think it's something we need to keep on our radar. Even if the Windows installer ultimately handles all of this for a single install, we still have to address what the implications are across multiple installs.

While I agree the pain @RobiFerentz addresses focuses on a single version, the problem compounds with multiple versions. I fear we're treading in "shared global node_modules" territory, in the sense that sharing build tools would be more efficient (if it could even work), but opens a floodgate for potential problems.
I don't have a good answer for this, but I do think it's something we need to keep on our radar. Even if the Windows installer ultimately handles all of this for a single install, we still have to address what the implications are across multiple installs.

Not necessarily. Native modules (😭) depend on node-gyp and the "node sdk" (i.e. *-headers.tar.gz) which are backward compatible with node version 0.8 and up. And only need one toolset (Preferably VS2015, but as far as I recall some stuff will work with VS2013, and VS2017 is fully compatible)

Just came about this thread, wanted to mention that ps-nvm actually does download and use the msi distributions on Windows to install multiple Node versions side-by-side:
https://github.com/aaronpowell/ps-nvm/blob/b15c9259d069b30296f46edc91beb72f8aec9076/nvm.psm1#L266-L268

From nodejs/node#4603, 3.a appears to be consensus. Does anyone object to 3.a?

Awesome, that's settled, then :)


[TRACK]: Sherlock Components Testing and Documentation

For sherlock, many new components will be created to aid in working with LLMs and supporting LLM based workloads. Currently, many of these components have been prototyped in the fea-sherlock branch. Before releasing these components in 23.11, they will all need to be documented and tested.
This is a tracking issue for following progress of the documenting and testing each component:
### Tasks
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1276
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1277
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1278
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1279
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1280
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1281
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1282
- [ ] https://github.com/nv-morpheus/Morpheus/issues/1283

All subtasks are complete. Closing.


Add a Gitter chat badge to README.rst

ITCase/pyramid_sacrud now has a Chat Room on Gitter
@uralbash has just created a chat room. You can visit it here: https://gitter.im/ITCase/pyramid_sacrud.
This pull-request adds this badge to your README.rst:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Coverage remained the same at 96.26% when pulling 55b315ded9cf086bbbeb19949323bdf2b6e92d10 on gitter-badger:gitter-badge into 07f1ba7a724d8fb1c6993e76ec17a19f118faf8d on ITCase:master.


apply function to Series, NotImplementedError

Hello, here my problem to apply function to Series:
while this works:
import dask
d = np.arange(10)
dd = dask.array.from_array(d, 10)
np.cos(dd)

with dask.DataFrame it doesn't:
import pandas as pd
d = pd.DataFrame({'x': np.arange(10, dtype=float)})
dd = dask.dataframe.from_pandas(d, 2)
np.cos(d['x'])      # this works
np.cos(dd['x'])    # this doesn't work

actually I am not able to apply any functions. I get:
NotImplementedError                       Traceback (most recent call last)
<ipython-input-140-69836e5dabc3> in <module>()
----> 1 np.cos(dd['x'])

/usr/lib/python2.7/site-packages/dask/dataframe/core.pyc in __getitem__(self, key)
    372             return Series(merge(self.dask, key.dask, dsk), name,
    373                           self.name, self.divisions)
--> 374         raise NotImplementedError()
    375
    376     def __abs__(self):

NotImplementedError:

Hi @wiso good question.  A few things.

You should probably be using da.sin rather than np.sin.  The NumPy function will turn the result into a numpy array.  This might change with the next release of NumPy if they release the __numpy_ufunc__ protocol.  Until then we have to use our own funcions, namely da.sin.
At the moment da.sin doesn't play nicely with dd.Series objects.  It should though.  I wonder if the right thing to do here is to implement __numpy_ufunc__ on dask array and dataframe objects in anticipation of the numpy release and then use this within our own ufuncs.

Until either of these happens you can always call the following (although this feels a bit ugly.)
myseries.map_partitions(np.sin)

Ok, thank you. I am wondering why it works for dask.array but not series.

Dask arrays implement the array interface, meaning that numpy functions coerce them into instances of np.ndarray before computing. We don't currently support this for dask.dataframe objects, but we could.
Note that when using numpy functions like np.sin, the whole array will be pulled into memory and run in serial at call time. Dask as a library works best if you build up a graph of your computations, and then compute in parallel. This is why we implement dask.array.sin, etc... - in general these should be drop ins for the numpy versions.


refactor overlap calculation code

Initial commit, will build and cancel sample imagery but integration tests fail

I put a little thought into this and I think this is pretty close to what we need. The overall idea is that we want to make it easy to swap out overlap algorithms. Separating the overlap calls into a function is a step towards accomplishing that. My original thought was that calculating the overlap all at once would be the most generic method since we can simply replace that all-at-once calculation with a different all at once calculation. After looking at this I think there's a simpler way.
In general, this is what needs to happen:

Perform some general calculations to get partial overlap data (this happens in BuildIndex).
Pass this partial data down to UpdateChildren.
Calculate the exact overlap for each level in UpdateChildren.

I think you can accomplish this with just a couple of function name changes. We could call the function called from BuildIndex something like PreprocessOverlapForInset and the function called from UpdateChildren something like GetOverlapForLevel. For this version of the code they would just call the same CalculateOverlap function that you've already written, but when we start working on overlap calculations they could do different things. That also eliminates the need for a flag since the calculations will be the same for this version, they'll just be organized differently.
To take it a step farther you could create an overlap class and put the two functions into it, then just pass the whole object from BuildIndex to UpdateChildren.
In summary, here's what I think needs to be done to finish up this ticket:

Put the two overlap calculation calls inside wrapper functions that describe what they're doing (as I described above). As I mentioned, you could create a class for this.
Remove the changes to the function signature for ReuseOrMakeAndUpdate.
Remove the new flag in MiscConfig.
Remove debugging code as noted in comments.
Move the doc changes to a separate PR so they can be in the 5.3.1 docs.

This is performance critical code, so I'm being extra picky.
Looking at the old code, this is roughly what happens:
Inside BuildIndex
For each genInfo:
  Call FindNeededImageryInsets // Returns all insets that overlap with the current inset at any level
  Call PacketGenFactory::ReuseOrMakeAndUpdate which eventually calls UpdateChildren

Inside UpdateChildren
For each level:
  Call FindNeededImageryInsets // Returns all insets that overlap with the current inset at a specific level

In the new code, this is what happens:
Inside BuildIndex
For each genInfo:
  Call calc->PreprocessForInset
    Which calls FindNeededImageryInsets // Returns all insets that overlap with the current inset at any level
  Call PacketGenFactory::ReuseOrMakeAndUpdate which eventually calls UpdateChildren

Inside UpdateChildren
For each level:
  Call calc->GetOverlapForLevel (does not call FindNeededImageryInsets)

The code in BuildIndex does the same thing in both versions, but the second call to FindNeededImageryInsets in UpdateChildren is missing in the new version. If I understand correctly, that means we'll have extra insets and do unnecessary processing. The ultimate goal here is to refactor the code such that it works exactly the same but it's easy to swap out different methods of calculating overlap.

This is performance critical code, so I'm being extra picky.
Looking at the old code, this is roughly what happens:
Inside BuildIndex
For each genInfo:
  Call FindNeededImageryInsets // Returns all insets that overlap with the current inset at any level
  Call PacketGenFactory::ReuseOrMakeAndUpdate which eventually calls UpdateChildren

Inside UpdateChildren
For each level:
  Call FindNeededImageryInsets // Returns all insets that overlap with the current inset at a specific level

In the new code, this is what happens:
Inside BuildIndex
For each genInfo:
  Call calc->PreprocessForInset
    Which calls FindNeededImageryInsets // Returns all insets that overlap with the current inset at any level
  Call PacketGenFactory::ReuseOrMakeAndUpdate which eventually calls UpdateChildren

Inside UpdateChildren
For each level:
  Call calc->GetOverlapForLevel (does not call FindNeededImageryInsets)

The code in BuildIndex does the same thing in both versions, but the second call to FindNeededImageryInsets in UpdateChildren is missing in the new version. If I understand correctly, that means we'll have extra insets and do unnecessary processing. The ultimate goal here is to refactor the code such that it works exactly the same but it's easy to swap out different methods of calculating overlap.

So, for now, UpdateChildren should be making that call to FindNeededImageryInsets?

Yes.

I just realized this was targeted to <IP_ADDRESS>. I've retargeted it to master (where we want to merge it), but that has created some merge conflicts.

I'm fine with including my commits on this PR.


Ingress error on v1.15.0: Required value: pathType must be specified

After upgrade devspace from 5.14.4 to 1.15.0, deployment ingress return an error:
[fatal]  error deploying main: Unable to deploy helm chart: error during 'helm upgrade main
/home/mysuer/.devspace/component-chart/component-chart-0.8.1.tgz
 --namespace my-namespace --values /tmp/894348912 --install --kube-context do-sfo2-rs-cluster':
Error: UPGRADE FAILED: cannot patch "main" with kind Ingress: Ingress.extensions "main" is invalid:
[spec.rules[0].http.paths[0].pathType: Required value: pathType must be specified,
spec.rules[1].http.paths[0].pathType: Required value: pathType must be specified,
spec.rules[2].http.paths[0].pathType: Required value: pathType must be specified,
spec.rules[3].http.paths[0].pathType: Required value: pathType must be specified]
 => exit status 1
Run `devspace purge -d main` and `devspace deploy` to recreate the chart

I downgrade to 5.14.4, and all works fine.
Local Environment:

DevSpace Version: 5.15.0
Operating System: linux
Deployment method: helm

Kubernetes Cluster:

Cloud Provider: other
Kubernetes Version: v1.20.2

/kind bug

I think I am running into a similar issue:
deployments:
- name: client
  helm:
    componentChart: true
    values:
      containers:
      - image: app/client
      service:
        ports:
          - port: 3000
      ingress:
        rules:
        - host: localhost
          path: /
          #  pathType: Prefix

This results in:
Error: Ingress.extensions "client" is invalid: spec.rules[0].http.paths[0].pathType: Required value: pathType must be specified
 => exit status 1
Run `devspace purge -d client` and `devspace deploy` to recreate the chart

But uncommenting pathType: Prefix such that:
deployments:
- name: client
  helm:
    componentChart: true
    values:
      containers:
      - image: app/client
      service:
        ports:
          - port: 3000
      ingress:
        rules:
        - host: localhost
          path: /
          pathType: Prefix

Results in:
[fatal]  deployments[1].helm.componentChart: component values are incorrect: yaml: unmarshal errors:
  line 7: field pathType not found in type latest.IngressRuleConfig

@cheslijones this should work with the new version v5.16.0-alpha.0 now, we'll release a stable version really soon

Should be fixed with v5.16.0


<EMAIL_ADDRESS>decompress error

Hi @bonitoflaku, thanks for posting this. If you are seeing this issue on windows, could you please try running the Powershell as an Admin and then install twilio-cli

Not the original poster, but I was trying to install the dev phone plugin as a basic webapp to test out a number, ran into the same issue while installing twilio-cli which was indeed resolved by running powershell as admin. Assuming the issue was extracting twilio-win32-x64.tar.xz, running elevated powershell gets rid of the exit code 2 issue. So for anyone else who happens to be googling trying to figure it out, that's what worked for me


appimage-run: depends on broken gst-plugins-base

Describe the bug
appimage-run currently depends on gst-plugins-base-0.10.36, which has been marked broken with d034a0039d8937aca2f64d1d3911e8b71f416137. This is causing it to fail:
error: Package ‘gst-plugins-base-0.10.36’ in /nix/store/d6ccdwwij22dfkcpiy1asznli5n0fvyv-nixpkgs-20.09pre234801.1facbd61b17/nixpkgs/pkgs/development/libraries/gstreamer/legacy/gst-plugins-base/default.nix:55 is marked as broken, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

(use '--show-trace' to show detailed location information)

To Reproduce
Steps to reproduce the behavior:

nix run nixpkgs.appimage-run

Expected behavior
This should drop you into an environment with appimage-run installed.
Metadata

system: "x86_64-linux"
host os: Linux 5.7.7, NixOS, 20.09pre234194.8d05772134f (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.7
channels(root): "nixos-20.09pre234194.8d05772134f"
channels(ivar): "home-manager, nixpkgs-20.09pre234801.1facbd61b17, nixos-20.09pre231796.22a81aa5fc1"
nixpkgs: /home/ivar/.nix-defexpr/channels/nixpkgs

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute: appimage-run

I really don't think this could possibly depend on the old version.
We'd just need to switch everything to gst_all_1.*.

It seems to depend on gstreamer 1.x and 0.10.x. From the looks of it, it has had these dependencies since it was initialized in  #41762 by @tilpner. That code was moved around and improved a whole bunch, but these dependencies seem to have stayed the same.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/update-not-all-packages/8230/1


Chapter 1, Lesson 4 homework.

Checker in VS doesn't work, so I'll check it by using PR.

I have no clue honestly what to do right now, probably will watch Lesson 5 and then try to comeback because I'm stuck on this for long time already and Float checks don't show if they're correct or wrong.

Done all checks, I think it should be alright now.

Okay, so I redid it a bit. Now I added another function AskingInformation and called it in Demo function.
Then I tried simplifying this thing, but not sure if I got it right. It's pretty hard to understand this, but I hope I can get better at it.


[FEAT] Delete records

I would like to also have the possibility of deleting records.

@nataliaElv This is something we could feasibly fit into v2. Do you think it adds value?

Yes it does! 😃 I'll add it to the milestone

@sdiazlor
How do you plan on interfacing this feature? I first expected just a record delete method, like so:
for record in dataset.record:
    record.delete()

@sdiazlor Are you still working on this?

@burtenshaw Yes, I worked on this and have the changes locally. These days I was waiting for the code migration to create the PR in the main argilla repo and no more PRs here


[test-triage] chip_sw_flash_crash_alert

Hierarchy of regression failure
Chip Level
Failure Description
UVM_ERROR @ 3496.978076 us: (sw_logger_if.sv:522) [flash_escalation_reset_test_prog_sim_dv(w/device/lib/testing/test_framework/ottf_isrs.c:60)] FAULT: Load Access Fault. MCAUSE=00000005 MEPC=20002dcc MTVAL=60000000
UVM_INFO @ 3496.978076 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
--- UVM Report catcher Summary ---
Steps to Reproduce

GitHub Revision: 53874025b
dvsim invocation command to reproduce the failure, inclusive of build and run seeds:
./util/dvsim/dvsim.py hw/top_earlgrey/dv/chip_sim_cfg.hjson -i chip_swq_flash_crash_alert --build-seed 137638316 --fixed-seed 573927059 --waves fsdb
Kokoro build number if applicable

Tests with similar or related failures

[ ] Test_name_1
[ ] Test_name_2

@engdoreis and I have seen that Jaedon is the maintainer of this block which is new and hasn't passed in the nightlies.

Tests
2022-11-03 07:11:23
2022-11-02 07:03:26
2022-11-01 07:10:18
2022-10-27 07:09:48
2022-10-26 07:06:46
2022-10-25 07:06:33
2022-10-24 07:05:24
2022-10-23 07:07:12
2022-10-22 07:06:03
2022-10-20 07:06:48
Suite

86
chip_sw_flash_crash_alert
0
0
0
--
--
--
--
--
--
--
chip_sw_flash_ctrl_escalation_reset

@jdonjdon i'll help triage this one since you're busy with i2c block level.
There are more dv things than design things to do there :)

Just make a note what I found for future debug.
Test failing right after 'read_host_if' is called.
'read_host_if' does flash read from host interface.

@tjaychen, yes I need a help to debug this.
After mmio read is called with address 0x40000000,
Load Access Fault comes out.
MCAUSE=00000005 MEPC=20002dcc MTVAL=60000000

should be fixed by #16084, waiting on regression results.

Passed on 3 nightlies. Ping on @engdoreis if this needs to be reopened.

Tests
2022-11-10 08:10:06
2022-11-09 08:04:06
2022-11-08 08:03:42
2022-11-07 08:08:10
2022-11-06 07:11:02
2022-11-05 07:11:23
2022-11-04 07:12:05
2022-11-03 07:11:23
2022-11-02 07:03:26
2022-11-01 07:10:18
Suite

83
chip_sw_flash_crash_alert
100
100
100
0
0
0
0
0
0
0
chip_sw_flash_ctrl_escalation_reset


Adjust default max fee

Longer claim names use higher fees - we should adjust the default max fee policy. Some miners and our servers are running 0.5 LBC max currently.

included in #355


Problem with setting default ResponseWriter status to http.StatusOK

I think there is a problem with this commit 34a385a. When status is set to something different than 0, Before functions are not called on response writer Write. Test don't show this, because there is explicit invocation of WriteHeader: response_writer_test.go#L99, but you usually not call it, you do just Write. This breaks some existing middlewares like negroni-sessions.

Thanks for the report @tdzienniak -- looking now.

Definitely a bug, see #126 for PR discussion.

Fixed by #126


Implement LayerManager using LitElement + anywidget

Overview:

Used anywidget to implement the custom widget and LitElement for template rendering. LitElement because it's simple, lightweight, efficient, and safe.
Changed build system to hatchling. The old setuptools build system is insufficient for building custom widgets.
The diffs show 2000+ more lines being added to the codebase than deleted. This is expected. There are several large, one-time additions like package-lock.json, the pyproject.toml changes, and the style sheets to replicate legacy ipywidgets styles. Future widget migrations will have much smaller diffs.

Files and directories:

geemap/static/* contains the compiled ECMAScript modules. These files aren't manually written. Each widget must have it's own compiled ECMAScript module. A previous version of this pull request checked in static files, but there are security risks with that and the Python package installers should know how to build the TypeScript into modules.
js/* contains the TypeScript and CSS source files. These files are written manually.
js/ipywidgets_styles.ts implements the legacy styles with the non-custom ipywidgets.
js/material_styles.ts implements new material styles (only fonts right now).

How to build and test:

The Python side is unchanged.
To build the TypeScript source, run npm install and then npm run dev. This starts a development server that will watch the TypeScript and CSS source files for changes and re-build when necessary.

TODOs remaining:

[x] Figure out how to simplify font loading. Currently, fonts are downloaded via an @import url command and then referenced in the stylesheets, but it involves duplication and brittle URLs. - @sufyanAbbasi
[x] Remove setuptools references from pyproject.toml. - @naschmitz
[x] Fix the build issues with this pull request. - @naschmitz
[x] (Lower priority) Unit tests for the TypeScript code. - @sufyanAbbasi
[ ] (Improvement, Lower priority) Get jslink working in Colab. It'll make the UI feel so much more responsive. - @sufyanAbbasi
[ ] (Improvement, Lower priority) Add a delete confirmation dialog over the layer manager instead of inline with the rows.

@naschmitz Sure, no problem. I will wait for other team members to review it first. I am not familar with TypeScript yet. Not much help I can provide yet.

@giswqs - This pull request is ready for your review

Tests are done! https://github.com/naschmitz/geemap/tree/anywidget-test
I'll leave it to you to merge them in!

@naschmitz Sorry for the delay! I just started reviewing the PR. This is tremendous amount of work. Thank you for puttting this together.
Here are some feedback I would like to share.

It seems that the basemap layer spinner continues to spin indefinitely, even after the basemap layer has finished loading. I'm not sure if you can replicate this issue. Here’s a screenshot for reference:

In previous versions, besides ticking the layer checkboxes, clicking directly on the layer names would also toggle the layers on and off. In this PR, it appears that layers can only be toggled by checking the boxes, and clicking the layer names has no effect.

@giswqs I think I've fixed both issues. Please take another look when you have time.

I fixed the cursor issue. It was as simple as adding cursor: pointer; to the relevant CSS class.


LFU Delete/pop key take a long time

func TestLFUPop(t *testing.T) {
	const maxKeySize = 10000000
	c := New[int, int](AsLFU[int, int](lfu.WithCapacity(maxKeySize)))
	take := time.Now()
	for i := 0; i < maxKeySize; i++ {
		c.Set(i, i)
	}
	t.Log(time.Since(take))

	take = time.Now()
	for i := 0; i < 300; i++ {
		c.Delete(i * 2)
	}
	t.Log(time.Since(take))
}

=== RUN   TestLFUPop
    cache_internal_test.go:366: 7.5215588s
    cache_internal_test.go:372: 11.4654817s   // delete 300 count key...used 11sec

@RelicOfTesla Thanks for your creating issue!
Please write descriptions what do you think problem? What do you have expectation? What can I do for that?
If you have additional context, please write more describe. Thanks!

profile
profile.pb.gz

Do you think deleting 300 keys takes more than 10+ seconds is a normal result?
Time-consuming code:
https://github.com/Code-Hex/go-generics-cache/blob/aac4f4743b3dcaff4b700f528d8d035b8986b1df/policy/lfu/priority_queue.go#L70-L74

@RelicOfTesla I would appreciate it if you could be a little more polite in your issue. i.e. add profile

Sorry, my English is not very good. I may have used inappropriate words semantically, which makes you feel uncomfortable.


bot not responding with Citrix Secure Web Mobile browser

Version

V3.
.NET framework
Directline Implementation

Describe the bug
Bot is totally not functional in Citrix secure web.
Where as bot is working fine Chrome mobile browser
We're are using in secure brower to secure with authentication.
To Reproduce
Steps to reproduce the behavior:

Open the bot link in Citrix Secure browser in Mobile
Say hi to bot
You'll not see any message sent back by bot

Expected behavior
Bot should work the way it function in desktop browser
Additional context
Needed to respond in Citrix Secure web Mobile reason being user is authenticated and context of current user is set.
Link to app Citrix Secure web mobile

HI @ShujaathKhan
This is the BotBuilder-V3 repository.  Please direct your issue to the WebChat repository here: https://github.com/Microsoft/BotFramework-WebChat/issues


Improve logging framework

Consider using slf4j instead of the standard java util logger. Implement file logging with log rotation.

Log4j has been integrated with log rotation and a logging threshold of INFO. This can be overridden by passing -l DEBUG or --loglevel DEBUG at run time (or any other valid logging level).


Pause button needs to be pressed only one time instead two times at launch up.

Can I try this issue?

Can I work on this issue under GSSoC'21? Kindly assign it to me.

@shairanshrawat yeah, Assigned.

As I am a beginner, Can I start my contribution by working on this issue under GSSoC'21? Kindly assign it to me.


MLZ: Fix multiple network watcher deployments

In the spokeNetworks module of bicep/modules/networking.bicep, the parameter of deployNetworkWatcher is set to spoke.deployUniqueResources (=true). In subscriptions where NetworkWatcher is already deployed this causes a quota violation with the following error message:
“Subscription  has a quota of 1 for resources of type NetworkWatcher with sku SkuNotSpecified. Subscription currently has 1 resources and the template contains 1 new resources of the this type which exceeds the quota. Please contact support to increase the quota for resource type NetworkWatcher”
Deploying MLZ to Virginia when already deployed to Azizona. Using 4 unique subscriptions for Hub, Identity, Operations, and Shared Services.

After talking to the end user deploying MLZ, they weren't using the UI and didn't realize they had to manually set whether network watcher should or should not be deployed. This isn't an issue anymore.

When deploying from PS, CLI, or API, the deployNetworkWatcher is set to false in parent bicep file but then the networking bicep overwrites that value with spoke.deployUniqueResources in networking.bicep


[Icon Request] Classic floppy disk save icon

A classic floppy disk save icon is very useful for forms. 😁

I created one by self...

for some reason doesn't look quite right...

A little curves on a edges perhaps?

The current save-icon looks a bit misleading indeed, would also like to see a classic version of the save-icon.

The current save icon, I feel it is actually a download file icon.  Since so many people associate the floppy classic as save since it has been and still is being used in many programs and places, I think this should be added in for good UI/UX design since most users will recognize it (still keep the existing icon though!).
Also nice floppy, I think the edge on the right is too long?  Something does look strange, just not sure what 😄


NIFI-9649 Upgrade SLF4J from 1.7.32 to 1.7.35

Description of PR
NIFI-9649 Upgrades SLF4J from 1.7.32 to 1.7.35.
PR #5440 for NIFI-9283 excluded references to Log4j 1.2 as well as the SLF4J implementation library slf4j-log4j12. This update to SLF4J also removes the dependency management declaration for slf4j-log4j12 and adds it to the list of banned dependencies.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[X] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[X] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[X] Has your PR been rebased against the latest commit within the target branch (typically main)?

[X] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[X] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[X] Have you verified that the full build is successful on JDK 8?
[ ] Have you verified that the full build is successful on JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

Merged, thanks @exceptionfactory


added git operation class diagram and FileCloner Module diagram

PFA the attached module diagrams and class diagram for the git operation
Module Diagram
Idea:

UI/UX composes Requester and Responder (since an instance of each must be created when the app starts)
Requester uses Networking to send request
Networking uses Responder to notify

Class Diagram
For now, idea is to implement the cloning operation of a local folder into temp folder (essentially a copy operation through the application) will develop on it in due course of time

Looks good to me.


Fail to join a new cluster

I installed the federation control plane and joined the host cluster. Before adding another cluster, how can I edit config and add the new cluster information? As someone new to kubernetes I was somehow confused with the user guide, because when I followed it
./bin/kubefed2 join cluster2 --cluster-context cluster2 \     --host-cluster-context cluster1 --add-to-registry --v=2
I got
I0421 22:27:32.530216   22738 join.go:165] Args and flags: name federated1, host: xxxx, host-system-namespace: federation-system, registry-namespace:  kube-multicluster-public, kubeconfig: , cluster-context: federated1, secret- name: , limited-scope: false, dry-run: false I0421 22:27:32.533013   22738 join.go:184] Failed to get joining cluster conf ig: context "federated1" does not exist F0421 22:27:32.533031   22738 join.go:133] Error: context "federated1" does not exist
What should I do before joining a new cluster to the federation?

The context name for the cluster you are joining needs to exist prior to joining.   As per the log message, the kubeconfig context being used for --cluster-context was federated1 (not cluster2 as indicated in the command line you provided).  Note that, if not provided, --cluster-context will default to the name of the cluster you are attempting to join.
I encourage you to follow the guide exactly rather than varying the names while you develop familiarity with federation.  Otherwise, if you run into problems, troubleshooting may be more challenging.

Thanks @marun . I found what I missed and made it. This issue can be closed.


RuntimeError when training on multiple GPUs

I tried to train on multiple GPUs, but when reading the data, even if I set num_workers=0, I still get the error
 RuntimeError: unable to open shared memory object
and I don't have root access, so I can't increase the openfile data.
trainer = pl.Trainer(gpus=2, precision=32, callbacks=[logger])
As soon as I change gpus to 1, training works fine. Anyone have ideas?

so am i

Try increasing the shared memory size by running this on the terminal
ulimit -n 16384


Scale up the number of observations for idwiki to 100k

Bug: T147107

Looks good to me.  @Ladsgroup, we might want to rebuild the model from
ores-compute-01.eqiad.wmnet before doing the merge.  I'll get to that in
~12 hours if you don't beat me to it.
On Mon, Dec 19, 2016 at 5:47 PM, Phantom-42<EMAIL_ADDRESS>wrote:

Bug: T147107
You can view, comment on, or merge this pull request online at:
https://github.com/wiki-ai/editquality/pull/53
Commit Summary

Scale up the number of observations for idwiki to 100k

File Changes

M Makefile
https://github.com/wiki-ai/editquality/pull/53/files#diff-0 (30)
M models/idwiki.reverted.gradient_boosting.model
https://github.com/wiki-ai/editquality/pull/53/files#diff-1 (0)
M tuning_reports/idwiki.reverted.md
https://github.com/wiki-ai/editquality/pull/53/files#diff-2 (330)

Patch Links:

https://github.com/wiki-ai/editquality/pull/53.patch
https://github.com/wiki-ai/editquality/pull/53.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wiki-ai/editquality/pull/53, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA8E7VlHuDi6ct1Cm4cumV4qKMi9W9Saks5rJxetgaJpZM4LRT39
.

@halfak the model is already in the PR. I can rebuild it once it's merged (since it's forked in another repo, not here) Do you mean something like this?

What I usually do in this case is follow the "Merging via command line" instructions and add a commit before finishing the merge.

I'm running the whole flow on ores-compute-01 right now :)


Async_call Regression in x.75 from x.74

My MemoryVectorStore similaritySearch timesout with a "ReferenceError: Property 'TextEncoder' doesn't exist".
I think there were some changes in async_call.js that broke the embeddings call

Hi, can you confirm which version of Node, or other JS environment, you're running this on? TextEncoder is available in Node.js since version 11.0, The current version is 20.x

Running it in the browser, as the MemoryVectorStore was marked as working without Node, it was working fine before!

@albert-carreras See here the compat table for TextEncoder https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder#browser_compatibility I suggest adding a polypill if you're running in an older browser


Format and getAge methods added

Fixes #3

Looks good, could you add some unit tests to test format method? You could look at how we do it the JavaScript repository. https://github.com/personnummer/js/blob/master/test.js#L63-L87

Travis tests failed du to undefined method:
NoMethodError: undefined method `digits' for 1964:Fixnum
    /home/travis/build/personnummer/ruby/lib/personnummer.rb:100:in `format'

You can ignore the test for Ruby: jruby-<IP_ADDRESS> since it's another problem and not your code.

Still, we have to test getAge method to know that the method are working the way it should. You could use this test cases https://github.com/personnummer/js/blob/master/test.js#L88

This PR is now out of date and irrelevant.


[BUG] Unsupported ctypes for getinfo to work

Describe the bug
Some CurlInfo constants can't be retrieved seemingly because types are not supported, such as curl_off_t.
Raw CURL command
> curl --compressed -so /dev/null http://www.whatsmyip.org/http-compression-test/ -w '%{size_download}'
256

Python attempt
> import curl_cffi

> curl = curl_cffi.Curl()
> curl.setopt(curl_cffi.CurlOpt.URL, "http://www.whatsmyip.org/http-compression-test/")
> curl.setopt(curl_cffi.CurlOpt.ACCEPT_ENCODING, 'gzip')
> curl.perform()

> curl.getinfo(curl_cffi.CurlInfo.SIZE_DOWNLOAD_T)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.12/site-packages/curl_cffi/curl.py", line 243, in getinfo
    c_value = ffi.new(ret_option[option & 0xF00000])
                      ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
KeyError: 6291456

Some more insight
> from curl_cffi._wrapper import ffi, lib
> ffi.getctype("long")
'long'
> ffi.getctype("char")
'char'
> ffi.getctype("curl_off_t")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ffi.error: undefined type name
curl_off_t

Expected behavior
CurlInfo options can be retrieved via Curl.getinfo
Versions

OS: linux x64
certifi==2024.8.30
cffi==1.17.1
curl_cffi==0.7.2
pycparser==2.22
typing_extensions==4.12.2

To expose the curl_off_t type, we need to include typedefs from curl/system.h in ffi.cdef().

curl_off_t looks like a long
curl.getinfo(curl_cffi.CurlInfo.SIZE_DOWNLOAD_T) ret_option = {     0x100000: "char**",     0x200000: "long*",     0x300000: "double*",     0x400000: "struct curl_slist **",     0x500000: "long*",     0x600000: "long*" } ret_cast_option = {     0x100000: ffi.string,     0x200000: int,     0x300000: float,     0x500000: int,     0x600000: int, }

I tried to add the typedef to cdef, but it does not work as documented, perhaps it's the more realistic way to do this.

curl_off_t looks like a long
curl.getinfo(curl_cffi.CurlInfo.SIZE_DOWNLOAD_T)
ret_option = {
    0x100000: "char**",
    0x200000: "long*",
    0x300000: "double*",
    0x400000: "struct curl_slist **",
    0x500000: "long*",
    0x600000: "long*"
}
ret_cast_option = {
    0x100000: ffi.string,
    0x200000: int,
    0x300000: float,
    0x500000: int,
    0x600000: int,
}


Fail to install the enviroment

Hi,Zifeng:
Your work is very good and I really want to use this method .
But i meet some problem at the first step:
conda env create --name survtrace --file=survtrace.yml
Here is the problem

[ ] Collecting package metadata (repodata.json): done
[ ] Solving environment: failed
[ ] ResolvePackageNotFound:
[ ]   - vs2015_runtime==14.27.29016=h5e58377_2
[ ]   - m2w64-gmp==6.1.0=2
[ ]   - cvxopt==1.2.5=py36h542453d_0
[ ]   - glpk==4.65=hdc00fd2_2
[ ]   - multiprocess==<IP_ADDRESS>=py36hf4a77e7_0
[ ]   - mkl_fft==1.3.0=py36h46781fe_0
[ ]   - icc_rt==2019.0.0=h0cc432a_1
[ ]   - setuptools==58.0.4=py36haa95532_0
[ ]   - libcblas==3.9.0=5_hd5c7e75_netlib
[ ]   - fastcache==1.1.0=py36he774522_0
[ ]   - sqlite==3.36.0=h2bbff1b_0
[ ]   - wincertstore==0.2=py36h7fe50ca_0
[ ]   - certifi==2021.5.30=py36ha15d459_0
[ ]   - vc==14.2=h21ff451_1
[ ]   - python==3.6.13=h3758d61_0
[ ]   - scikit-learn==0.22.1=py36h7208079_1
[ ]   - numexpr==2.7.3=py36hcbcaa1e_0
[ ]   - scikit-survival==0.14.0=py36he350917_0
[ ]   - scs==2.1.2=py36haa4650d_0
[ ]   - ecos==2.0.7.post1=py36haa4650d_3
[ ]   - msys2-conda-epoch==20160418=1
[ ]   - scipy==1.5.2=py36h9439919_0
[ ]   - mkl_random==1.1.1=py36h47e9c7a_0
[ ]   - numpy-base==1.19.2=py36ha3acd2a_0
[ ]   - m2w64-gcc-libs==5.3.0=7
[ ]   - cvxpy-base==1.0.31=py36h6538335_0
[ ]   - intel-openmp==2021.3.0=haa95532_3372
[ ]   - m2w64-libwinpthread-git==<IP_ADDRESS>34.697f757=2
[ ]   - libblas==3.9.0=1_h8933c1f_netlib
[ ]   - mkl-service==2.3.0=py36h196d8e1_0
[ ]   - pandas==1.1.5=py36hd77b12b_0
[ ]   - osqp==0.5.0=py36haa4650d_3
[ ]   - m2w64-gcc-libgfortran==5.3.0=6
[ ]   - pip==21.0.1=py36haa95532_0
[ ]   - m2w64-gcc-libs-core==5.3.0=7

And my compter is _Architecture:

[ ]  x86_64
[ ] CPU op-mode(s):                  32-bit, 64-bit
[ ] Byte Order:                      Little Endian
[ ] Address sizes:                   46 bits physical, 48 bits virtual
[ ] CPU(s):                          32
[ ] On-line CPU(s) list:             0-31
[ ] Thread(s) per core:              2
[ ] Core(s) per socket:              16
[ ] Socket(s):                       1
[ ] NUMA node(s):                    1
[ ] Vendor ID:                       GenuineIntel
[ ] CPU family:                      6
[ ] Model:                           85
[ ] Model name:                      Intel(R) Xeon(R) Gold 6246R CPU @ 3.40GHz
[ ] Stepping:                        7
[ ] CPU MHz:                         3400.000
[ ] CPU max MHz:                     4100.0000
[ ] CPU min MHz:                     1200.0000
[ ] BogoMIPS:                        6800.00
[ ] Virtualization:                  VT-x
[ ] L1d cache:                       512 KiB
[ ] L1i cache:                       512 KiB
[ ] L2 cache:                        16 MiB
[ ] L3 cache:                        35.8 MiB
[ ] NUMA node0 CPU(s):               0-31
[ ] Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
[ ] Vulnerability L1tf:              Not affected
[ ] Vulnerability Mds:               Not affected
[ ] Vulnerability Meltdown:          Not affected
[ ] Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v
[ ]                                  ia prctl and seccomp
[ ] Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user
[ ]                                   pointer sanitization
[ ] Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RS
[ ]                                  B filling
[ ] Vulnerability Srbds:             Not affected
[ ] Vulnerability Tsx async abort:   Mitigation; TSX disabled
[ ] Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtr
[ ]                                  r pge mca cmov pat pse36 clflush dts acpi mmx f
[ ]                                  xsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rd
[ ]                                  tscp lm constant_tsc art arch_perfmon pebs bts
[ ]                                  rep_good nopl xtopology nonstop_tsc cpuid aperf
[ ]                                  mperf pni pclmulqdq dtes64 monitor ds_cpl vmx s
[ ]                                  mx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid d
[ ]                                  ca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadli
[ ]                                  ne_timer aes xsave avx f16c rdrand lahf_lm abm
[ ]                                  3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 inv
[ ]                                  pcid_single intel_ppin ssbd mba ibrs ibpb stibp
[ ]                                   ibrs_enhanced tpr_shadow vnmi flexpriority ept
[ ]                                   vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep
[ ]                                   bmi2 erms invpcid cqm mpx rdt_a avx512f avx512
[ ]                                  dq rdseed adx smap clflushopt clwb intel_pt avx
[ ]                                  512cd avx512bw avx512vl xsaveopt xsavec xgetbv1
[ ]                                   xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm
[ ]                                  mbm_local dtherm ida arat pln pts hwp hwp_act
[ ]                                  window hwp_epp hwp_pkg_req pku ospke avx512_vnn
[ ]                                  i md_clear flush_l1d arch_capabilities

my conda version is 4.10.3.
thanks a lot,I will be appreciated if you reply me this stupid question

It is so kind of you,I will have a try,thanks a lot
发自我的iPhone
------------------ Original ------------------
From: Zifeng @.>
Date: Mon,Oct 18,2021 0:11 AM
To: RyanWangZf/SurvTRACE @.>
Cc: Dan @.>, Author @.>
Subject: Re: [RyanWangZf/SurvTRACE] Fail to install the enviroment (Issue #3)
hi, this is because you are using a linux platform (I guess) that is different from ours (windows).
I update the survtrace.yml and requirements.txt,
please try them and tell me if they work. 😊
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


no need padding-bottom on input error

the error on a wrong padding-bottom

It's going to be fixed on next release, coming today!

Please @Lupino, may you check if it works for you in the new release

thinks