TSD Future

Hey everyone!
I'm going to be jumping into this project and seeing what we can do to improve the sharing of TypeScript definitions. Development isn't (quite) going to happen instantly, so I wanted to submit a short issue that describes some of my immediate goals and see if there are other ideas of what they want to see moving forward. Feel free to create new issues with feature requests and we can label them for TSD Future.
Goal
The goal of TSD future is to seamlessly support any TypeScript definition files, from any source. By default, you should still be able to search the definitely typed repository and install from there. However, more focus will be trained onto support independent definitions, specifically ones bundled with modules. This is a primary focus because as the ecosystem grows, a single repo is going to be a challenge to scale and I would like to give more power to module authors.
Currently TSD (tsd@next) supports a feature called tsd link. It's a great first step, but comes with many drawbacks - mostly because it's just a really simple path copy and paste. It needs a bit more to be useful. In the future, you'll be able to tsd install and it will look up your dependencies via package.json or bower.json and it will install definition files. However, it'll then recursively resolve dependencies from there. Any dependencies the module has likely have their own definition files that they're depending on.
This will make tsd.d.ts less editor friendly, but the goal is to avoid having to manually edit this file and check in dependencies any more. Just as you don't check in your node_modules or bower_components, you shouldn't have to check in your type dependencies. As we resolve dependencies down the tree, if we encounter tsd.json files they'll also factor into the recursive resolution. This is important since not every module can or will adapt over night. If there are conflicts between sub-dependency definitions, we will provide a dialog for selecting the version that should be used (resulting in that flat structure we wanted, a la bower).
Doing this, we'll pull closer to the seamless usage of definition files. Similarly, the commands will be pulled closer to npm and bower. All that will be required from now on is tsd install. To remove old dependencies, you can tsd prune. Finally, tsd uninstall will remove a dependency from tsd.json. The tsd.d.ts file will always be kept in sync with hard module dependencies and the tsd.json.
To support all this, I think some changes to tsd.json are required. I'm going to change this last (avoid it if I can), but I think it's too tied to the one source approach which doesn't scale. From now on, manual definition file installations tsd install <source> should create an entry like package.json with "name": "source", where source can be any file/url (tsd.json or d.ts file). For example, the source when installed from the definitely typed repo will the raw git files. This allows anyone to host their own definitions. tsd install <module> will still fall back to the definitely typed repo and tsd search <module> will still search the repo. It is possible for this to be automated as well.
Having the name -> source mapping allows us a little more flexibility. For example, we can now check in our custom definition files and have them resolve according to the recursive algorithm since they are defined. On top of that, we can create aliases (which are supported by build tools like browserify and webpack) from one module to another. Finally, we can eventually support the module output format by TypeScript and automatically compile that into the namespaced module. That would personally be very cool to do, since it's a pretty big pain point for third-party module developers.
Ok, I think I'm done rambling but there will definitely be more to come.
Tracking

[ ] TSD to have command parity with NPM and Bower #142 #119 #122 #6 #116
[ ] Perform a complete, recursive defintion resolution #134 #105 #130 #123 #109 #151
[ ] Make sure we're running on all node versions >= 0.8 and iojs #144
[ ] Fix general inconsistencies #143 #125 #120 #112 #62 #75 #113 #95
[ ] Automatically install unknown dependency definitions #115
[ ] Install dependencies from any source #97 #135 #87
[ ] Start work on a wrapper that will accept any definition file and declare as a module name

Testing
I will start work in the next few days on the future branch.
npm install -g DefinitelyTyped/tsd#future

Related
There's a few proposals in TypeScript right now to fix the definitions situation that will probably (hopefully) make most of this redundant (https://github.com/Microsoft/TypeScript/issues/2338, https://github.com/Microsoft/TypeScript/issues/2839).

Glad to know this project still has traction. So when do you plan deaing with #144?

@5angel It definitely still has traction, but I'm not currently focused on previous versions of TSD for a few reasons (namely still not having publish access to NPM yet, since the original author is MIA). That issue doesn't mean it's not working with 0.12 or any other version, it's just the 0.5.x branch was pinned to certain node versions (see https://github.com/DefinitelyTyped/tsd/blob/master/package.json#L37). You can still install, it should only be a warning. If you install with tsd@next it won't even warn you since it specifies >= 0.10.

@blakeembrey phew, thank you. It was thinking about cloning the rep and making a pull request (:

namely still not having publish access to NPM yet,

@blakeembrey We (you and me) have that now. I'll change the tag on 0.6 to be latest (instead of next). I'll also remove beta from it. That will ensure that people can continue to use what we have right now while you work on vnext :+1: :rose:

@basarat Fantastic, thank you :smile: I saw it and I'm glad everything is alright.

Alright done ... phew. 0.6.0 is now latest so npm install tsd -g should just work.

Author here, sorry for going AWOL and dropping off the grid, stuff went different then expected :disappointed:
I kinda dropped the ball here, sadly can't commit OS coding time anymore so @blakeembrey has my full blessing to go ahead on this and take ownership. Thanks @basarat for being admirably more dependable contributor and getting stuff rolling.
Today I got an email from Angular guys who needed a sub-dependency mistake fixed: minitable. So I pushed an update for it to npm earlier but for some unknown reason I pinned the exact dependency here in TSD. So I think we need an TSD v0.6.1 soonish.. a PR will turn up any time.
Anyway, I'll have a look around the tickets soonish and see what's up. Its been a while since I ran TypeScript and node development though (doing python now (:open_mouth:) And I'll put some text together about project status and stuff.

@Bartvds Nice to see your ok! I was a little worried, even though I'm yet to meet you. Feel free to keep push any TSD versions and I'll make sure it stays maintained until the next version is ready :smile:

Cool, thanks. I got distracted. Not sure if I get back in TypeScript yet but at least TSD could have second revival (2nd yes).
It was a bit of wayback machine but here is TSD 0.6 bootcamp to help you going: Since I don't know when I got focus again I just typed a lot now:

0.3 and 0.4 where from maintainer before me, also got limboed.
0.5 was my full rewrite to link directly to github (I had too much time back then). 0.5.7 has been used up till this week.
0.6 was major cleanup to imports style and more npm modules (not all, not enough). it got stuck in limbo for release for a long time.

The main issues TSD faces and tries to solve are about user interface and conventions of the DefinitelyType repos. There was (is?) not a 100% consensus about how package naming and versioning are handled.
TSD works using the filenames in first level folder as the module name (npm name recommended), it also considers some legacy nested folders. The main folders are usefull for convenient bundeling but over whole of DT there is not a universal semantic pattern of putting definitions together in folders. Then parses for semvers (filename is leading). The information in actual header of file is mostly cosmetic for listing/search.
Then there is the use of bundles/linked definitions; TSD link and dts-bundle are an attempt but appear flawed. There is a prototype in 0.6 to read information from package.json, an approach to scan for tsd.json could be cool. It gets a bit fuzzy what defs/types you actually need, you might not need all of a packages tsd.json but only what is visible on it's exported API.
Versioning is an issue. It is a mix of the path/name/semver and git's commit system. Keep in mind the semver in path is of the module it describes, not of the definition. There is no guarantee a next commit on same (semvered) filename doesn't break peoples builds, so for safety TSD pins on filename in a specific commit.
There were ideas of adding metadata to either the headers or a separate file in DT repos, and some other ideas in various related repos (here, DT itself, definition-header, definition-tester etc).
Since 0.6 was oldish even before it got lost I was trying a prototype of a cleaner version that uses streams all the way. It supported adapters, to read trees and blobs from file system, github and local git. Most of it worked but I sorta got stuck on streamy http cache and some stream plumbing problems. Could be solved though.
Anyway, some random stuff about code:

it's a lot of own code, at least it's strict formatted and linted (and typed :wink:) and I hope you like generic promises..

/src code is basically a few main packages:

tsd has the type-definition specific stuff (and main app)
xm folder has (own) old utils. i tried to replace much of it with npm modules in 0.6 but only got so far. usefull but mixed quality. would be nice to get rid of.
expose is an experimental CLI command router and does fancy layout stuff, generate help, and outputcolor/plain/html etc. not essential but looks cool.
http is a http downloader with local file cache, it does e-tags and gzip and some http options (proxy etc). it prunes cache periodically. a small flaw is that it buffers downloads (works ok in our use-case).
git has wrappers to access blobs and trees from github over http, it uses the http cache.

the typings folder is epic, i used to edit DT contributions as hobby.

tests are a odd located: the actual cases are in src/spec, and src/test holds support code and custom assertions. some fixtures are located elsewhere.

some tests are a little involved, but most TSD/CLI specific ones allow to add many cases by repeating the pattern: after verifying updates you can copy new test output to the fixtures easily.

the gruntfile uses a custom grunt config wrapper/generator to create partial-tests. it's still just regular grunt running the tasks.

most of actual logical interface is implemented in tsd/API.ts (should be exported and documented for re-use).

API uses a structure from tsd/logic/Core.ts holding main services (index, http, git, downloaders etc).

sub-systems usually know about the structure of Core and may reach into/through it to get their own work done (fun times but TypeScript compiler keeps it together), still try to glue in API.

there is a settings/env/path thing in tsd/context/Context.ts. its not pretty but has the stuff. annoyingly it does IO and holds a copy of the tsd.json information in memory (race much).

cli is setup from tsd/CLI.ts, it should use the API. API then glues together different services..

.. so basically start there and follow the calls, but don't get stuck in custom utils.

i felt there is a little too much code and too many dependencies and typed wrappers for what it does. although it is expandable in it's way; just slap on new services and add the glue.

I'm Dutch and way back before 0.5 I just stopped writing games in Flash AS3..

.. anyway, most of it is kinda replacable except /src/tsd, and even that is basically just looping directory trees and parsing the paths for information. Then filter/compare and move blobs and paths around (don't underestimate amount of functionality needed though, it is a lot of things adding up, it's kinda like a mini VCS).
Cheers. :+1:

Thanks for the amazing introduction! :smile:

VS15 and VSCode depend on TSD now, correct? It looks like you guys have a lot of rewrite to do. Can you get it done? Are you preparing for the io.js merge, for example? I'm feeling queasy about depending on tsd for my projects after all this discussion and the degree of rewrite in #170.

VS15 and VSCode depend on TSD now, correct?

To be honest, I haven't heard or seen of this. Do you have a source?

Can you get it done?

Yes, absolutely. There's a lot of depth to the project, but it's not huge. I've just been incredibly busy since I started to rewrite and explore on the future branch.

Are you preparing for the io.js merge, for example?

That will definitely be prepared for, but it's unlikely we'll need to take any major action.

I'm feeling queasy about depending on tsd for my projects after all this discussion and the degree of rewrite in #170.

At the end of the day, it's completely up to you. TSD is currently stable on 0.6 and any future versions will have a completely seamless upgrade path. Even in #170, the first thing I implemented was a tsd init --upgrade command to seamlessly update to it - and that will always be the goal, making it as easy to use as possible.
In any case, the project does need refactoring and does need new ideas. Whether it's directly from #170 or we just pull some things from it, it's there to present some alternatives and directions. We need this because, as a new user even myself, it's very difficult to actually get started. In my first week using TypeScript I ran into issues getting definitions, then I ran into issues where they were out of date and had to hack in references to custom directories and copy and paste code, then I wanted to publish definitions of my own projects that depend on other definitions and that's not possible. Basically, I quickly ended up in a mess that tooling should have fixed. That fix is the goal of this.

Thanks for your very helpful answer. It's pretty clear that the promise and the reality of TS are a bit far apart. I think I still want to do it for core projects but it might be too much of a mess for application programmers to tackle right now.

@kenbrubaker I've been using it for all new projects and it's been great, minus the few getting started humps. I actually think it's better for application developers than library maintainers right now, just because of the distribution issues around it still.

@blakeembrey Can I add a few concerns to how tsd link is addressed?
One of the exceptions that can be thrown by TypeScript is having a module conflict.  You cannot have two angular.d.ts files.  Based on that premise, you should not include tsd install-ed project definition files into the bower/package.json files, because a down-stream module may have two dependencies that both depend on angular.d.ts. It has to be resolved by either: a) a flat dependency tree or b) every project needs to ensure all d.ts dependencies are resolved.
One of the other issues with tsd link is how the path linking works.  Currently, link updates the tsd.d.ts file to point at the ../bower_components/moduleA/moduleA.d.ts path.  But say that particular module also depends on xyz.d.ts that I can retrieve from tsd install.  It almost seems better to instead copy the "linked" files to the typings directory, rather than "linking" them with a path.  I see it being no different than installing from tsd, where my "typings" directory has moduleA/moduleA.d.ts.  This would fortunately better support a single structure for tsd (i.e. typings/module/module.d.ts)

@mtraynham the approach I have been taking is to not allow external dependencies and explicitly removing (via gulp) the references comment from my linked d.ts submodules. This does mean I have to make sure my main module has (at lease) the same dependencies as the submodule. It is a far from elegant solution but it works in the meantime.
I think that resolution of submodules should just work - ie duplicates are allowed but errors are not thrown. There is the possibility of conflicting typings files (eg if two versions are used), but typings files should theoretically be possible to merge (In PHPStorm when there is duplicate typings the type completion just reads from both files)

@xiphiaz Fair points, but I don't know if I can agree with that last comment:

I think having a flat file structure would be a mistake as there is a chance that the submodule depends on a typings file that has a total conflict (same name, different api), or a versioning difference (angular 1.3 vs 1.4 for example).

bower already uses this structure, and npm 3 will be maximally flat.  One of the more pertinent issues is resolving version conflicts for the browser.  Even if the future is to package npm dependencies, instead of bower, it would be important that a module, with two dependencies that use different versions of angular, likely resolve to a single version of angular.  With the current state of most client libraries, I don't forsee non-globably scoped dependencies being widely available...

@mtraynham @xiphiaz Absolutely agree with everything here. Unfortunately I haven't been able to work on it too much lately, but I think a flat structure will always be required.
However, in future iterations I think the goal will be to remove any possible conflict - for example, generating a single d.ts file from your dependency with its own dependencies inlined (without global modules). That would remove any conflict from ever happening. Having the declare module 'name' is kind of an anti-pattern here since it breaks interoperability with everything else, so the end goal would be to have that declare generated for you based on your dependencies. Of course, the only way things can work right now is with the declare, so we have a ways to go in between. Generating the d.ts will also be a huge improvement for module authors, since you'll finally be able to use the d.ts files generated by TypeScript - and I think this should be the primary goal of future work, making things work seamlessly.
As for copying versus implicitly linking and such, this shouldn't really matter. Preferably you'll publish your .d.ts library with no /// <reference>s and instead rely on imports and tsconfig.json.

does not look like we have a good progress there

@PLEEROCK You'll have to elaborate on that statement, I'm not sure what you're talking about.

Any plans for something like --save-dev so that we can separate test dependencies into their own bundle?

Yes, it's currently supported in branch I'm working on. There is no available release yet, as I'm closing up with the final piece which turned out to be quite tricky - that is, rewriting dependency typings into a single file to remove potential namespace conflicts.

I spent a lot of time trying to solve the features in DefinitelyTyped alongside the things I needed to solve with this issue creation, but it's just not possible with the current structure of DT. To avoid trying to make breaking changes to a monolith project, like DT, I'm releasing the work for this issue under a separate repository and organization: https://github.com/typings/cli.
The goal of typings is to use external module declarations (not ambient module declarations) that can resolve over any source to create a typed dependency tree without conflicts. A lot of the requests made in TSD exist there and it's built closer to an NPM-like API. I welcome anyone to try it and see what they think, but the registry needs a lot more typings to be implemented before the real value is visible.
Live examples: https://github.com/TypeStrong/tsconfig/blob/master/typings.json, https://github.com/TypeStrong/ts-node/blob/master/typings.json and the registry at https://github.com/typings/registry.

@blakeembrey awesome! This is a much more maintainable pattern. What is the plan for those typings that you have added for some projects under the  https://github.com/typings org? Is the idea that they will be removed when the respective source project include their own typings.json in their own project?

@xiphiaz Absolutely. Everything is an external module declaration so it should actually be extremely straightforward to open a bunch of PRs for this already and those module will start working with TypeScript module resolution. Also, anyone can create a typing and make a PR to the registry to include their entry until the module merges it :smile: On top of that, having separate repos means that maintenance of typings should be much simpler than having to subscribe to issues and PRs for over a 1000 typings.

@blakeembrey good to hear, is the plan to always have the registry or be able to have the project define it's dependencies on tags, like how bower does not have an official registry - it just inherits the git tag semvers so the typings developer doesn't have to publish to a registry; they just have to maintain sane tags.

@xiphiaz it can use tags or the commit hash. I'm using the commit hash right now since it's pretty much immutable which is what you want from the typings. The registry actually come after the CLI was done, but the plan is to always have the registry as the "official" source to find typings. There's also some other nifty things that can be done using the registry, such as auto-updating typings according the package.json and implicit installs of all missing typings.
Currently, the registry is used to populate the installation and it uses whatever the registry says for that version. To implement some of the more advanced features, I might have to implement a registry:... scheme (see https://github.com/typings/cli/issues/28) so that you can know when typings are out of date with the installed versions in package.json.


I have an absurd amount of stuff that could be sifted through for future content

https://docs.google.com/document/d/1lk0ffronOsdG-T0VaRMIc2ryMVOVC1AfSB36Q0ievcY/edit
Towards the end of the document, there are things that might interest you most, such as content backported from TC5 and TC6, and their addons. Also, the flying rug.
I had been in talks with another individual regarding this general insane idea, but implement what you want from the list, or expand on any ideas

It would be nice to have not just random integrations, but ones that have lore background according to add-on theme (society and how magic affects it)

Fair, since you are going for a specific theme, but I decided to bring these ideas here just in case any had any interest from you.
At the very least, why not port some content from TC5 + TC6, as well as stuff from older versions of TC?
I'll also give you some stuff that may fit here.
Flying Carpet - A flying rug, similar to those in old TC versions
Eldritch Scroll - Can be used to share 3 pieces of random research with another player, but doing so causes them pain. All pieces will be those that they can unlock already from pre-existing research, however. They will also be things you have already researched. New item entirely.
Wand Focus: Corrosion - Rapidly corrodes armor on a target, but deals no physical damage to the target. However, this focus is very good at combating heavily armored targets, and even destroying their armor. New item entirely.
Minecart with Hungry Chest
Minecarts with all chest variants added by Automagy (Requires TC4 + Automagy)
Note: Some of the upcoming content comes from either Thaumic Periphery or Thaumic Augmentation, on top of TC5 + TC6
https://www.curseforge.com/minecraft/mc-mods/thaumic-periphery
https://www.curseforge.com/minecraft/mc-mods/thaumic-augmentation
TC5/TC6 content:

Redstone Relays
Automated crossbows (including the advanced variant. They will also be able to take arrows from various mods and vanilla, to unleash havoc)
Rabbit Nuggets (If mods like Et Futurum are present)
Verdant Heart Band
Brass golems (If a mod that adds brass is installed)
Colored Nitor
Mutton Nugget - For compat with Et Futurum
Grappler Wand Focus
Autocaster - Note: Will come with a config to blacklist specific foci from being used in it, as not all modded foci will play nice with it.
Voidseer’s Pearl
Cloudstepper’s Ring
Headband of Curiosity

Thaumic Augmentation and Thaumic Periphery content:

Pauldron of Repulsion
Conjurer’s Quiver
Primal Cutter
Elytra Harness
Golem Core: Seal
Malignant Heart

Some minor notes on various magic mods that may be of interest:

I remember when Emoniph was still active, he said that the glyphs in Witchery are Enochian.
The symbol Thaumcraft uses on a lot of devices seems to be a stylized Pi symbol.
For stuff from TC addons, contact the original devs. It may be possible to get permissions for assets and such.

But if you want some lore for some of these things, in terms of reasoning why someone might try and make these things:
Cleansing Wand Focus - This is primarily a tool for builders, and so was sought out by thaumaturges, namely because it helped clean things up if things went wrong
Corrosion Wand Focus - A heavily armored foe is a dangerous one. Why wouldn't someone devise a way to handle such?
Vampiric Drain Wand Focus - Perhaps some vampires have dabbled with thaumaturgy... namely to increase their own power
Leonard's Urn Wand Focus - Maybe someone might try and figure out if the effects of this item can be put into a wand focus
Mending Wand Focus - While combat oriented, this also has uses outside of combat, and can be used for emergency repairs if someone needs their gear repaired.
Flying Carpet - Flight is a dream of humanity. This is just one of many ways to possibly achieve it, albeit in a magical fashion.
Eldritch Scroll - Sharing is caring... though it comes at a cost. But regardless, someone might want to give some excess research to help someone along.
Various Minecarts - Why wouldn't these exist?
The various keys - Of course, even a thief might try and benefit from these practices.
TC5/TC6 content - Many of these could exist fairly well in TC4, so I chose the best fitting ones IMO. Some also allow for stuff like extra compat.
TC5/TC6 addon content - See above.

Cleansing focus - wool can be dyed, leather armor can be cleaned with cauldron.
Corrosion focus - amount of mobs wearing powerful armor is close to zero.
Vampiric focus - makes low sense, I doubt vampires need any buff.
Leonard's Urn focus - makes zero sense, Urn is perfectly usable with mytic branch.
Mending focus - overpowered, Thaumic Restorer does his job well.
Flying carpet - useless, Thaumostatic Harness, Uprising focus, Flyte charm - all of them do their job well.
Eldritch Scroll - useless, Thaumic Tinkerer already has Tome of Knowledge Sharing.
Minecarts with automagy chests - idk, minecarts with inventories cause a lot of duplication glitches, also there are other options for item transfer.
Skeleton key - ain't Alohomora already does that? Also makes useless rowan doors more useless.
Devious key - same as above.
Sinister key - like what? Also will be instantly banned on all public servers, makes zero sense.
Thaumic Periphery doesn't add something that isn't already implemented.
Thaumic Augmentation just tries to make TC6 less shitty, TC4 already has half of its content.
Hymn of Harmony - useless, Botany already has Charm of the Diva


[FLINK-5348] [core] Support custom field names for RowTypeInfo

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[x] General

The pull request references the related JIRA issue ("[FLINK-XXX] Jira title text")
The pull request addresses only one issue
Each commit in the PR has a meaningful commit message (including the JIRA id)

[x] Documentation

Documentation has been added for new functionality
Old documentation affected by the pull request has been updated
JavaDoc for public methods has been added

[x] Tests & Build

Functionality added by the pull request is covered by tests
mvn clean verify has been executed successfully locally or a Travis build has passed

Hi @wuchong , in this case I think you should adapt getFieldIndex

Hi @tonycox ,  the field names of RowTypeInfo are guaranteed to be unique. So I think getFieldIndex  is fine with it. Do you have special case which getFieldIndex give a wrong result ?

@wuchong sorry, my fault, didn't spot duplicate field names checkers. What about cases, Is flink-table case-sensitive?

Thank you @fhueske ,  I think your points are very good. And I changed my code according to your suggestions.

Thanks for the update @wuchong!
PR is good to merge

merging


Misplaced MI:0789 (knock down), MI:0788 (knock out) is also a mutation

Knock downed (in contrast to knocked out) gene is not mutated but its level of expression is manipulated, typically, by siRNA or morpholinos. Thus the term should be made a child term of  MI:0223)  under expressed level.
Knocked out gene is a mutation and thus could be a child of MI:0113 (mutation). The problem is  mutation terms combine mutation (as gene change) with its effect (increasing/decreasing/etc) on one specific process.  In principle, mutation effects should be handled the same way as the effects of PTMs.

These terms are both under the 'genetic experimental form' branch, which is meant to capture a terms related to genetic interactions exclusively. As such, these terms should not be applied to experimental preparations in physical interactions.
If you are fine with that, I will keep them as they are and close the issue.

On 7/30/19 9:05 AM, Pablo Porras wrote:

These terms are both under the 'genetic experimental form' branch, which is meant to capture a terms related to genetic interactions exclusively. As such, these terms should not be applied to experimental preparations in physical interactions.
If you are fine with that, I will keep them as they are and close the issue.

Pablo,
the move of 'knock down' will be, effectively, also within 'genetic
experimental form' (223 is a child of, both, 221 and 803). knock down
is not a mutated gene as the cv seems to imply at the moment. this is
exactly how the cv is supposed to work.
lukasz
--
Lukasz Salwinski                             PHONE:<PHONE_NUMBER>
UCLA-DOE Institute                             FAX:<PHONE_NUMBER>
UCLA, Los Angeles                            EMAIL<EMAIL_ADDRESS>

I am not sure we are fully understanding the design choices behind this branch of the ontology. Perhaps @chris-grove can help here. Chirs, did you also work on this when you did your work for genetic interactions in PSI-MI?

@pporrasebi
I didn't build this branch of the ontology. I would agree that "knock down" does not necessarily mean a mutated gene, but it could. I agree that "knock down" should not be a subclass of "mutated gene" (as it isn't necessarily the case). Perhaps "knock down" ought to be a synonym of "under expressed level" (MI:0223). I'm not sure there would be a meaningful distinction between "under expressed level" and "knock down".

On 08/01/2019 08:52 AM, Chris Grove wrote:

@pporrasebi
I didn't build this branch of the ontology. I would agree that "knock down" does not necessarily mean a mutated gene, but it could. I agree that "knock down" should not be a subclass of "mutated gene" (as it isn't necessarily the case). Perhaps "knock down" ought to be a synonym of "under expressed level" (MI:0223). I'm not sure there would be a meaningful distinction between "under expressed level" and "knock down".

sounds ok although I'm not sure if utilizing native regulatory
mechanisms to decrease expression of a gene would be called a knock
down. the most common use of the term seems to be in the context of
siRNA-based depletion. apart from that, folding a term into a synonym
makes it, effectively, disappear. it might make these who actually
use it somewhat unhappy. though it would be still better than the
current version.
lukasz

I would say that the distinction could be in the mechanism used to generate the under expression. I agree with Lukasz that I wouldn't call a knock down something you do to alter expression of a gene that is not happening at a genetic level (with a drug, for example). Knock down seem to have a very specific meaning in that it needs to be achieved via alteration at the genetic level, right?
So what I think is that we need to get rid of 'mutated gene' term (MI:0804), seems fairly meaningless, but I do not know if it has been used in any context, so I am a bit reluctant to make it obsolete.
I would propose changing this term to 'alteration at genetic level' or something similar (I am terrible with names, so please do not hesitate to lean in for this one). The definition would be "A modification that alters a gene function or expression at genetic level directly.". The terms a-/anti-/hyper-/hypomorph could join KD/KO under this definition. KO/KD can both be under 'under expressed level' because they are specific cases of under-expression. We would keep the 'expression alteration' branch separated and under both 'genetic experimental form' (for use in genetic interactions).
Does that sound reasonable to both of you?

Sorry for the delayed response. Given that I/we don't know how this branch has been used, I agree that deprecating the term without such an investigation would be premature. On the same lines, I would be hesitant to change the term label. I do agree, though, that "knock down" needs to move out from under "mutated gene", particularly since "knock down" is defined as reduction in gene expression by "introduction of an external substance, e.g. by RNA interference".
The branch "genetic experimental form" appears to be a place to collect types of genetic perturbations. I feel that "alteration at genetic level" would be redundant with the existing purpose of this branch and it wouldn't be clear what "at genetic level" means from the label alone and would have to be carefully defined, as it could be liberally interpreted (some would likely interpret "at genetic level" to mean alteration to the DNA sequence itself).
I would say "knock down" should either be made a child term of "genetic experimental form" or it should be made a child term of "under expressed level", as opposed to being made a synonym of that term. I think the latter is the most expedient and most correct, for the time being.


enum types are ignored by AutoMapping

For this simple model:
public class X { public virtual int Id { get; set; }  public virtual EnumType E { get; set; } }
public enum EnumType { E1, E2 };

when using automapping functionality:
AutoMap.AssemblyOf<X>(new MappingConfiguration());

E is ignored. MappingConfiguration indicates that EnumType is a component - perhaps this is the problem, but without it, "missing Id property" exception is thrown.
When adding an explicit mapping (Map(x => x.E);) everything works as expected.
Related StackOverflow question: http://stackoverflow.com/questions/34667082/why-does-automapping-from-fluents-nhibernate-ignore-an-enum-type

Fair point, I will look into that

@chester89 Sorry for the confusion, the problem was solved as described in this comment: http://stackoverflow.com/questions/34667082/why-does-automapping-from-fluents-nhibernate-ignore-an-enum-type#comment57213196_34732522
My ShouldMap implementation was flawed, now everything seems to work fine :) Should I close the ticket?

I see. Please do
2016-01-12 13:38 GMT+03:00 bartoszkp<EMAIL_ADDRESS>
@chester89 https://github.com/chester89 Sorry for the confusion, the
problem was solved as described in this comment:
http://stackoverflow.com/questions/34667082/why-does-automapping-from-fluents-nhibernate-ignore-an-enum-type#comment57213196_34732522
My ShouldMap implementation was flawed, now everything seems to work fine
:) Should I close the ticket?
—
Reply to this email directly or view it on GitHub
https://github.com/jagregory/fluent-nhibernate/issues/335#issuecomment-170870431
.

--
Yours faithfully,
Gleb

Problem was due to incorrect ShouldMap and IsComponent implementations. Properties are not components, so IsComponent should return false, and so should do ShouldMap - "map" in this context refers to whole entities, not their properties.
So despite the fact that ShouldMap, roughly speaking, says that an enum should not be "mapped", it will be included in the model, as a property of its parent type.


Add support for Python 3.11

I like this project and I was hoping to see wheels get built for Python 3.11.

Thanks for contributing. I'm thinking of adding some more features and also updating some of the dependencies of this crate recently.

I think I'll probably need to do some dependencies update for this to work.

Thanks for getting back to me, looking forward to the changes.

The support for python 3.11 is added in merge request #24


Improving Backups

What does this PR do? Please provide some context
This PR makes general improvements to the setup of backups:

adds new backup upgrade deployment
adds support for azure cli 2
adds support for optional HA Proxy usage
adds error notifications for backup failures

Where should the reviewer start?
the change itself
How can this be manually tested? (brief repro steps)
N/A.
What are the relevant TFS items? (list id numbers)
[Pending]
Definition of done:

[x] Title of the pull request is clear and informative
[ ] Add pull request hyperlink to relevant TFS items
[ ] For large or complex change: schedule an in-person review session
[ ] This change has appropriate test coverage
[ ] Validate upgrade operation and clean STAMP install
[ ] Update deployment README

Reminders BEFORE merging

Get at least two approvals
If you're merging from a feature branch into the development branch then "flatten" or "squash" commits
If merging from the development branch into master (or porting changes from upstream) then use github's UI to get review feedback, but use the git command line interface to complete the actual merge.

Reminders AFTER merging

Delete the remote feature branch
Resolve relevant TFS items
(reverse merge) If you merged from the development branch into master then check to see if there are any changes in master that can be merged down to the development branch (like hotfixes, etc). In this case, use github's UI for feedback and the git command line interface for the actual merge.

Needs a bit of iteration. Closing for now and will re-open when confirmed ready.


Fix macOS download links in the client documentation

Wow I never noticed that. Thanks a lot for your PR! Much appreciated!

Merged and updated the documentation, thanks again!

You are welcome :pray:


[Bug]: Issues in App Font dropdown

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Below are issues in the App Font dropdown in Property Pane:

The dropdown does not highlight the selected option.
When we click on the dropdown, it overlaps with the property and the whole Font section

https://www.loom.com/share/36b886c8a9994897bd58a73f20511b2b
Steps To Reproduce

Go to any application.
Click on the App Font dropdown.

Public Sample App
No response
Version
Cloud

The second issue happens only on devices with low resolution or if you reduce the browser window size.
This happens since there is no space for the dropdown on those scenarios.


Cluster Deprovision job runs indefinitely when Cluster Provisioning fails

Hi,
I am trying to create a cluster on AWS, hive successfully creates EC2 instances, load balancers and other resources but the masters fail to bootstrap with errors logged in the machine config logs.
After this failure, the cluster is destroyed, all resources are deleted and no ClusterDeprovision resource is found in the management cluster but AWS resources related to the provisioned cluster are cleaned out.
Upon deleting ClusterDeployment, a deprovision job is run and it gets stuck in a loop trying to find and delete resources in AWS, as they do not exist. If I try to delete the deprovision job it creates another one and the cycle continues.
The troubleshooting doesn't help in this case either as resources are already deleted.

Assuming we're focusing on the deprovision job, is this a NoSuchHostedZone error?

Yes, it's the error with NoSuchHostedZone.

https://bugzilla.redhat.com/show_bug.cgi?id=1817201 and this fix is now picked up in Hive, if you update to latest master you should be good to go.

@hazim1093 if you're using the operatorhub.io release, we'll update that early next week to include the fix

@gregsheremeta yes, great 👍 Would love to try it as soon as it's out

Fixed in #915.
/close


[NSURL initFileURLWithPath:] performs blocking access to filesystem

When creating an NSURL instance via [NSURL initFileURLWithPath:] the filesystem is accessed during the init method when it calls _stringLooksLikeOrIsPathToDirectory(). This causes the method to block and has a big performance impact when you are creating a collection of NSURL instances.
Ideally the filesystem should not be accessed during the init process and only methods like [NSURL checkResourceIsReachableAndReturnError:] should do this.

also URLByAppendingPathComponent.

Hi @rupertdaniel , this is unfortunately part of the API contract of initFileURLWithPath: (https://developer.apple.com/reference/foundation/nsurl/1410828-fileurlwithpath?language=objc). While we could defer this process until a getter is used, as you recommend, doing so is fairly non-trivial, prone to error, and would place a burden of knowledge on developers who make future changes to the class's getters. As such, we'd like to avoid making such a change at this time.
If you're in a position where you can make certain assumptions about the URLs you're consuming, could you try initFileURLWithPath:isDirectory:NO, instead? Internal testing shows good performance improvements from this (cuts time nearly in half). Thanks!

Ahh thanks @ms-jihua for looking into this. I will give that suggestion try!


Variable replacement inconsistent within dependabot.yml config file

dependabot.yml file:
version: 2
registries:
  my-registry:
    type: 'nuget-feed'
    url: 'https://pkgs.dev.azure.com/my_org/my_project/_packaging/my_feed/nuget/v3/index.json'
    token: 'PAT:${{ nugetAccessToken }}'

updates:
  - package-ecosystem: 'nuget'
    directory: '${{ packageManifestDirectory }}'
    schedule:
      interval: 'weekly'

In the above file, ${{ nugetAccessToken }} is replaced correctly with the value, but ${{ packageManifestDirectory }} is not.
This behavior doesn't seem correct as just a few lines above, variable replacement works fine.

I think it has something to do with the usage of convertPlaceholder function used internally.
Only three properties seem to be using that function.
token property parsing:
https://github.com/tinglesoftware/dependabot-azure-devops/blob/17ac6eadf7f399a1c1f879ea6ab045b571c49036/extension/task/utils/parseConfigFile.ts#L271
directory property parsing:
https://github.com/tinglesoftware/dependabot-azure-devops/blob/17ac6eadf7f399a1c1f879ea6ab045b571c49036/extension/task/utils/parseConfigFile.ts#L162

Using the official parsing methods would severely limit the effectiveness of this extension, at least for my use-case which is build templates in Azure Pipelines. I essentially have one dependabot configuration for multiple pipelines while configuring certain parts with variables on a per-project basis.
Would you be willing to stray slightly away from official behavior?
Side note, I believe the README documentation could be more explicit about replacement only working for secret values within the registries section. The linked GitHub page wasn't really clear on this behavior (from my perspective):
https://github.com/tinglesoftware/dependabot-azure-devops/blob/17ac6eadf7f399a1c1f879ea6ab045b571c49036/README.md?plain=1#L51-L52

From the onset, the extension was not meant to run complex scenarios such as one pipeline for multiple repositories or dynamic settings in the configuration file. Maintaining a version close to the official one makes it easier long term because there are fewer moving parts; it gets worse over the years.
The extension best suits simple scenarios that do not require scheduling, and for one repository. Beyond that, I recommend the server component. Have you tried that yet?
Thanks for the docs recommendation, I have edited.

Understood, appreciate the quick response and edits!


How can I stop streaming and dispose player before start?

How can I stop streaming and dispose the player before starting the audio and completely loading the audio in Windows?
when I stop or dispose audio players object my app crashes.
Windows 10
audioplayers 5.2.1

It should be possible via stop or release. Once you have disposed your player, you have to create a new one via AudioPlayer().
Does this problem still occur with version 6.0.0?


Unpin ipython

Pull Request Checklist:

[x] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #1005

[ ] Tests for the changes have been added (for bug fixes / features)

[ ] (If applicable) Documentation has been added / updated (for bug fixes / features)

[x] HISTORY.rst has been updated (with summary of main changes)

[x] Link to issue (:issue:number) and pull request (:pull:number) has been added

[ ] bumpversion patch has been called on this branch
[x] The relevant author information has been added to .zenodo.json

What kind of change does this PR introduce?

Unpin IPython in environment.yml and requirements_dev.txt.

Does this PR introduce a breaking change?
No.
Other information:
I'm not sure when the issue was fixed, but the current version 8.2 fixes it.

Coverage remained the same at 91.603% when pulling fa8e36e0ef05c4d06fbded89edc8b6a185a85b46 on unpin-ipython into c65862b9c2384c97f9ba45a90d58dd1f28266647 on master.


pred_lc missing values when fit high order on DRW

https://github.com/dfm/celerite/issues/141

https://github.com/dfm/celerite/issues/141


Unable to add custom modules.

Version
@vueup/vue-quill version [e.g. 1.0.0-beta.5]
Describe the bug
I have tried the same example but I am getting an error
Expected behavior
add of the module
Browser (please complete the following information):
chrome
Additional context
I am adding the error log here
Uncaught TypeError: Cannot convert undefined or null to object
at Function.assign ()
at composeOptions (vue-quill.esm-bundler.js?93e8:203)
at initialize (vue-quill.esm-bundler.js?93e8:131)
at eval (vue-quill.esm-bundler.js?93e8:118)
at callWithErrorHandling (runtime-core.esm-bundler.js?5c40:154)
at callWithAsyncErrorHandling (runtime-core.esm-bundler.js?5c40:163)
at Array.hook.__weh.hook.__weh (runtime-core.esm-bundler.js?5c40:2909)
at flushPostFlushCbs (runtime-core.esm-bundler.js?5c40:357)
at render (runtime-core.esm-bundler.js?5c40:5793)
at mount (runtime-core.esm-bundler.js?5c40:4081)

I got this error too, here's what fixed it for me:
- <QuillEditor theme="snow" v-model:content="content" :modules="modules" />
+ <QuillEditor theme="snow" v-model:content="content" :modules="modules" toolbar="full" />

Looks like not using toolbar="full" doesn't allow the modules to be added or something...

Got this error too, and reinstalling the<EMAIL_ADDRESS>helped fix it


mandelbrot-vanilla.cc not compiling

Trying to compile the file 'mandelbrot-vanilla.cc' using GCC 7.1.0 on Linux Mint 18 Cinnamon 64-bit. I get the following errors:
cpp_paral/mandelbrot-vanilla.cc: In function ‘double Iterate(double, double)’:
cpp_paral/mandelbrot-vanilla.cc:36:42: error: ‘ESCAPE_RADIUS_SQUARED’ was not declared in this scope
const double escape_radius_squared = ESCAPE_RADIUS_SQUARED;
^~~~~~~~~~~~~~~~~~~~~
cpp_paral/mandelbrot-vanilla.cc:37:25: error: ‘MAXITER’ was not declared in this scope
const int maxiter = MAXITER;
^~~~~~~
cpp_paral/mandelbrot-vanilla.cc:37:25: note: suggested alternative: ‘WEXITED’
const int maxiter = MAXITER;
^~~~~~~
WEXITED
In file included from cpp_paral/mandelbrot-vanilla.cc:1:0:
cpp_paral/mandelbrot-vanilla.cc: In function ‘int main()’:
cpp_paral/common.inc:106:33: error: ‘PROG_NAME’ was not declared in this scope
auto& tab = timings[PROG_NAME];
^
cpp_paral/mandelbrot-vanilla.cc:73:5: note: in expansion of macro ‘MAINLOOP_START’
MAINLOOP_START(1);
^~~~~~~~~~~~~~
cpp_paral/common.inc:106:33: note: suggested alternative: ‘__LC_NAME’
auto& tab = timings[PROG_NAME];
^
cpp_paral/mandelbrot-vanilla.cc:73:5: note: in expansion of macro ‘MAINLOOP_START’
MAINLOOP_START(1);
^~~~~~~~~~~~~~
The compiler doesn't like that ‘ESCAPE_RADIUS_SQUARED’ and 'MAXITER' are not declared, could I get some inside into this issue? Would this program only work on DOS?

These are #defines you must pass on the compiler commandline. For convenience, use the supplied Makefile to build. Example:
$ make mandelbrot-vanilla
g++ -std=c++14 -Ofast -march=native -Wall -Wextra -DMAXITER=8000 -DESCAPE_RADIUS_SQUARED=6*6 -Wno-clobbered -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -lSDL -DPROG_NAME="\"vanilla\"" -pthread -lSDL  mandelbrot-vanilla.cc   -o mandelbrot-vanilla
mandelbrot-vanilla.cc: In function ‘double mylog2(double)’:
mandelbrot-vanilla.cc:8:77: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     std::uint64_t half_bits    = reinterpret_cast<const std::uint64_t&>(half);
                                                                             ^
mandelbrot-vanilla.cc:12:53: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     m = reinterpret_cast<const std::uint64_t&>(value);
                                                     ^
mandelbrot-vanilla.cc:16:42: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     x = reinterpret_cast<const double&>(m);```

This program will work on DOS if you can cross-compile SDL2 for DOS. In other words, it will not work on DOS.


LLM performance with quantized model

Describe the bug
LLM performance (prefill/decoding) does not seem to improve when running the model at lower precision (float16 vs int8)
To Reproduce
Steps to reproduce the behavior:

Run profiling script (llm_leaderboard.py) configure to compare few LLM models on a MTL NUC (Core Ultra 7 155H w/96GB DRAM)
Look at the generated chart, and observe no improvement, and sometimes worst on select LLM when running model at lower precision (int8)

Expected behavior
Expect running inference at lower precision (int8) to improve on prefill/decoding performance
Screenshots

Desktop (please complete the following information):

OS: Ubuntu 22.04
intel_npu_acceleration_library (mainline)

Is this expected ?

No it is not expected. Can you tell me what driver version do you have?

Here you go:
OS is Ubuntu 24.04.1 LTS
Kernel 6.8.0-49-generic
VPU FW: vpu_37xx_v0.0.bin version 20241025MTL_CLIENT_SILICON-release1830ci_tag_ud202444_vpu_rc_20241025_1830ae072b315bc
intel_vpu: 1.0.0 20230117

Can you update the driver? I think one of the latest is 1.10.x

I have tested with the latest intel-npu-driver (1.10), and i think the result is worse than the one i shared earlier. Any thoughts ?


Tabs

Reviewer: @subsymbolic
Asana:https://app.asana.com/0/0/350058423386223
Description: Add tabs to the project
Steps to test this PR:

Use the tab switcher to delete, select or create new tabs.
Ensure that each tab keep its state when switching, and is removed when deleted.
Check that the app keep its state on configuration change and app recreation after the process is killed, but is rebooted when swiped from the recent app.

Reviewer Checklist:

[ ] Ensure the PR solves the problem
[ ] Review every line of code
[ ] Ensure the PR does no harm by testing the changes thoroughly
[ ] Get help if you're uncomfortable with any of the above!
[ ] Determine if there are any quick wins that improve the implementation

PR DRI Checklist:

[ ] Get advice or leverage existing code
[ ] Agree on technical approach with reviewer (if the changes are nuanced)
[ ] Ensure that there is a testing strategy (and documented non-automated tests)
[ ] Ensure there is a documented monitoring strategy (if necessary)
[ ] Consider systems implications (Database connections, Grafana stats, CPU)

@subsymbolic since I made quite some changes in here after the bookmark PR are you ok if I close this PR and make a new one?

@fgei sure!


chore(deps): next 14 update

Alignment to OWA packages and node 20 to allow for Next 14 testing

Cheers for doing this. Before merging the build needs to be tested against a version of OWA which uses next 14 before publishing or else it will block pupil squad's work. This can be done using yalc (see publish:local in package.json)

@kimon-satan @johnrobeds are we satisfied this has been tested now?


Changes to xSQLServerSetup (resolves issue #38)

This PR

Incorporates the changes from PR #46
Also fixes issue #38

This PR is based on the work by @jpmnteiro in the PR #46 which was abandon. Now @johlju is continuing the work to get this merged.

This change is

@mbreakey3 I guess you want a test for this one now, and code cleaned up according to style guide line? 😉

Yes, that would be great 👍 :)

I will fix that. Might take a few days because of Ignite. :)

No problem!

@johlju @mbreakey3 What is happening here? Is this ready for review again?

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

README.md, line 351 at r1 (raw file):

### Unreleased
* Changes to xSQLServerSetup
  - Now `Features` parameter is case-insensitive.

Could you add a simple unit test for this change as well?

Comments from Reviewable

Just reviewed - label is correct now.

@johlju - sorry, no rush on the unit test, just thought I'd put the comment in Reviewable.

@mbreakey3 No worries. I feel a little bad that I haven't had time to finish the test yet, but I will. 😄  I have started, and my guess is that it is a day left of coding. I aiming at getting further with the test this weekend.
The weeks after MSIgnite has been busy. The little time I have been able to scrape together has been focused on helping others here with their reviews, to get things moving a bit more.
Wish I could do this (code and review) full time instead of just in my spare time 😉  This is fun! 😄

Glad you're enjoying it! Your contributions have been immensely helpful!

@mbreakey3 I finally added a test. Yay! 😄  It do covers the changes in this PR (and a bit more).
But unfortunately there is more to be done to make this test cover all of the resource.
My thought is to submit an issue for the below remaining items. Reason for that is it would be good to get this test reviewed and merged so other PR's can add to this test an be merged as well.

Need to test when SourceCredential is set. Must mock NetUse (Get-/Set-method) and Robocopy. I submitted an issue to discuss if this functionality is necessary at all.
Need to test when replication state is installed ($mockGetItemProperty_ConfigurationState is always set to $null now)
Need to test other products than just DBENGINE.
Need to test all parameters in Set-/Test-method
Can't test Set-method when state is present because the Set-method is not currently built that way.

@mbreakey3 the above comment isn't true anymore "It do covers the changes in this PR (and a bit more)".
After I did the style changes just now I did poke on lines that is not tested. If you want I will fix the test for that as well. I need to do test for basically the bullet points in the above comment 😉

Reviewed 1 of 2 files at r4, 1 of 2 files at r5.
Review status: 2 of 3 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

I would say, open a new PR for adding the rest of the unit tests for this resource, as your tests cover the main changes that this PR is fixing.

@mbreakey3 I raised the code coverage of the test from 60% to 88%. I submitted a issue for the rest. So I can get back to writing the last tests when this PR has merged. Or, if the review takes a while. I might have time to get the last tests in as well. 😄

Reviewed 2 of 3 files at r7, 2 of 2 files at r8.
Review status: all files reviewed at latest revision, 18 unresolved discussions.

xSQLServerHelper.psm1, line 61 at r8 (raw file):

}

function Connect-SQLAnalysis

Please add help information

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 2 at r8 (raw file):

$script:currentPath = Split-Path -Parent $MyInvocation.MyCommand.Path
Import-Module $script:currentPath\..\..\xSQLServerHelper.psm1 -ErrorAction Stop

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 3 at r8 (raw file):

$script:currentPath = Split-Path -Parent $MyInvocation.MyCommand.Path
Import-Module $script:currentPath\..\..\xSQLServerHelper.psm1 -ErrorAction Stop
Import-Module $script:currentPath\..\..\xPDT.psm1

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 5 at r8 (raw file):

Import-Module $script:currentPath\..\..\xPDT.psm1

function Get-TargetResource

Add help information

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 48 at r8 (raw file):

    }

    if ($InstanceName -eq 'MSSQLSERVER')

These could be aligned (style recommendation)

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 84 at r8 (raw file):

        if ($isReplicationInstalled -eq 1)
        {
            Write-Verbose 'Replication feature detected'

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 89 at r8 (raw file):

        else
        {
            Write-Verbose 'Replication feature not detected'

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 253 at r8 (raw file):

    }

    return @{

This would be a great opportunity to align the items in this hashtable

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 287 at r8 (raw file):

}

function Set-TargetResource

Add help information

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 419 at r8 (raw file):

    )

    $parameters = @{

Align these on the "="

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 766 at r8 (raw file):

}

function Test-TargetResource

Would you mind adding help information?

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 899 at r8 (raw file):

    )

    $parameters = @{

Align on "-"

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 908 at r8 (raw file):

    $sqlData = Get-TargetResource @parameters
    Write-Verbose "Features found: '$($SQLData.Features)'"

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 922 at r8 (raw file):

            if(!($sqlData.Features.Contains($feature)))
            {
                Write-Verbose "Unable to find feature '$feature' among the installed features: '$($sqlData.Features)'"

Add named param

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 931 at r8 (raw file):

}

function GetSQLVersion

Would you mind adding help information for this one?

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 944 at r8 (raw file):

}

function Get-FirstItemPropertyValue

Please add help information

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 967 at r8 (raw file):

}

function Copy-ItemWithRoboCopy

Please add help information

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 984 at r8 (raw file):

}

function Get-TemporaryFolder

Please add help information

Comments from Reviewable

Review status: all files reviewed at latest revision, 19 unresolved discussions.

README.md, line 351 at r1 (raw file):
Previously, mbreakey3 (Mariah) wrote…
> Could you add a simple unit test for this change as well?

@mbreakey3 I'm sorry, I don't follow you. Happy to do unit tests, but for what do you want me to do a unit test? The line you comment on is an already present test. :)

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 48 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> These could be aligned (style recommendation)

@mgreenegit I rather not do this until what you suggest is in the style guidelines. I think we can only enforce style changes that can be backed up by the style guideline. I we change this in the style guideline, then I'm happy to enforce this also. Until then I'm humbly decline changing this. :smile:

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 253 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> This would be a great opportunity to align the items in this hashtable

See previous comment regarding this.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 419 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Align these on the "="

See previous comment regarding this.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 899 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Align on "-"

See previous comment regarding this.

Comments from Reviewable

Reviewed 1 of 2 files at r8.
Review status: all files reviewed at latest revision, 20 unresolved discussions.

README.md, line 351 at r1 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> @mbreakey3 I'm sorry, I don't follow you. Happy to do unit tests, but for what do you want me to do a unit test? The line you comment on is an already present test. :)

Yeah, this looks fine.... not sure what I was referring to here. Must have missed it.

README.md, line 371 at r8 (raw file):

   - 1-SetDatabaseOwner.ps1
 * Added tests for resources
   - MSFT_xSQLServerDatabaseOwner.Tests.Tests.ps1

Just one '.Tests' here.

Comments from Reviewable

@mgreenegit appreciate the review! Please look this over again if you have a chance.

Reviewed 1 of 3 files at r7, 4 of 4 files at r9.
Review status: all files reviewed at latest revision, 19 unresolved discussions.

README.md, line 371 at r8 (raw file):
Previously, mbreakey3 (Mariah) wrote…
> Just one '.Tests' here.

Removed 'Tests' altogether since we list the tests (and other tests) under the list item 'Added test for resource'.

xSQLServerHelper.psm1, line 61 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Please add help information

I added comment-based help for all of the functions in this module.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 2 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 3 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 5 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add help information

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 84 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done. And also fixed all `Write-Verbose` to use the helper function `New-VerboseMessage` and made sure they does not use positional parameters.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 89 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 287 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add help information

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 766 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Would you mind adding help information?

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 908 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 922 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add named param

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 931 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Would you mind adding help information for this one?

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 944 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Please add help information

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 967 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Please add help information

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 984 at r8 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Please add help information

Done

Comments from Reviewable

Reviewed 1 of 4 files at r9.
Review status: all files reviewed at latest revision, 19 unresolved discussions.

Comments from Reviewable

@johlju You have the same issues than me.
AppVeyor or PSA will updated, maybe ?

Yes, this went thru AppVeyor yesterday. must be new test code. Asked @kwirkykat to look into it. Will file issue in repo also.

Unless there are no more review comments on this by Monday evening, I will merge this PR. We have other PR's waiting for the tests in this PR.

Reviewed 1 of 1 files at r10, 2 of 2 files at r11.
Review status: all files reviewed at latest revision, 19 unresolved discussions.

README.md, line 371 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Removed 'Tests' altogether since we list the tests (and other tests) under the list item 'Added test for resource'.

LGTM

xSQLServerHelper.psm1, line 61 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> I added comment-based help for all of the functions in this module.

LGTM

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 2 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 3 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 5 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 48 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> @mgreenegit I rather not do this until what you suggest is in the style guidelines. I think we can only enforce style changes that can be backed up by the style guideline. I we change this in the style guideline, then I'm happy to enforce this also. Until then I'm humbly decline changing this. :smile:

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 84 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done. And also fixed all `Write-Verbose` to use the helper function `New-VerboseMessage` and made sure they does not use positional parameters.

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 89 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 253 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> See previous comment regarding this.

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 287 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 419 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> See previous comment regarding this.

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 766 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 899 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> See previous comment regarding this.

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 908 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 922 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 931 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 944 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 967 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 984 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done

Done.

Comments from Reviewable

Review status: all files reviewed at latest revision, 18 unresolved discussions.

xSQLServerHelper.psm1, line 61 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> LGTM

Done

DSCResources/MSFT_xSQLServerSetup/MSFT_xSQLServerSetup.psm1, line 2 at r8 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> Done.

LGTM

Comments from Reviewable

@mgreenegit Could you please go an Acknowledge your review comments?

Review status: all files reviewed at latest revision, 19 unresolved discussions, some commit checks failed.

README.md, line 359 at r11 (raw file):

* Fixes in xSQLAOGroupJoin
  - Availability Group name now appears in the error message for a failed Availability Group join attempt.
* Changes to xSQLServerSetup

The Unreleased section has been moved to the CHANGELOG.md. Please move your entries to the Unreleased section in the new CHANGELOG.md when you do git rebase.

Comments from Reviewable

Reviewed 1 of 2 files at r12, 2 of 2 files at r13.
Review status: all files reviewed at latest revision, 19 unresolved discussions.

README.md, line 359 at r11 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
> The Unreleased section has been moved to the CHANGELOG.md. Please move your entries to the Unreleased section in the new CHANGELOG.md when you do `git rebase`.

Done.

Comments from Reviewable

Review status: all files reviewed at latest revision, 19 unresolved discussions.

Comments from Reviewable

There are conflicts that needs to be resolved on this one.

Reviewed 1 of 1 files at r14.
Review status: all files reviewed at latest revision, 19 unresolved discussions.

Comments from Reviewable


Failing rendering tests: ol.rendering.layer.Tile

tile layer with render listener
works with the canvas renderer ‣
Error: Uncaught Error: expected '2.84' to be below 2.6 (http://localhost:3000/node_modules/expect.js/index.js:102)

The test fails on chrome and firefox but not on slimerjs

One solution would be to increase the size of the test map and the reference image.

@ahocevar Thanks for the suggestion, see #5755


Remove -disable-experimental-parser-round-trip from @lifetime tests

Please test with following pull request:
https://github.com/swiftlang/swift-syntax/pull/2894
@swift-ci Please test

Please test with following pull request:
https://github.com/swiftlang/swift-syntax/pull/2894
@swift-ci Please test Linux platform

Please test with following pull request:
https://github.com/swiftlang/swift-syntax/pull/2894
@swift-ci Please smoke test macOS platform


[kube] Update ServicesMapper logic to be compatible with Kubernetes 1.3.x

What does this PR do?
The current kube_service mapping logic relies on the nodeName field in the EndpointAddress objects, that was added in Kubernetes 1.4. It matches endpointAddresses to Pods via the (IP, nodeName) tuple.
This PR adds a ServicesMapper.mapOnRef method matching pods via the targetRef field instead, that is consistently present since 1.3.
Set the new behaviour to default, as it would also allow the servicemapper to avoid querying the podlist, but provide a temporary opt-out option / envvar kubernetes_map_services_on_reference, that reverts to the current logic.
Migration plan:

ship 6.4.0 with the option (true by default, false to revert)
if 6.4.x bring no support ticket for the new logic, remove it from 6.5.0, and stop querying the podlist

Motivation
Kube 1.3 compatibility, reduce apiserver traffic

Test on OpenShift 1.3:
    {
      "metric": "docker.mem.swap",
      "points": [
        [
<PHONE_NUMBER>,
          0
        ]
      ],
      "tags": [
        "container_id:01573dded80b934a7db692289f1c380ea28380f49286141be8637a0864b1c542",
        "container_name:k8s_redis.3001a574_db2-3417816881-l3unn_default_c99c8e66-438a-11e8-8c13-525400daa710_e301aaf4",
        "docker_image:docker.io/redis:3.2",
        "image_name:redis",
        "image_tag:3.2",
        "kube_container_name:redis",
        "kube_deployment:db2",
        "kube_namespace:default",
        "kube_replica_set:db2-3417816881",
        "kube_service:redis-db2",
        "kube_service:redis-db2-bis",
        "pod_name:db2-3417816881-l3unn",
        "short_image:redis"
      ],
      "host": "oshift-xaviervello",
      "type": "gauge",
      "interval": 0,
      "source_type_name": "System"
    }

Removed e2e test as it's redundant with the new one in master


Fix #283: Fix Non functional nav links on landing page

This PR...
Changes

Changes the scroll effect to sections on the landing page

Fixes

#283

Checklist

[x] tested locally
[ ] added new dependencies
[ ] updated the docs
[x] added/updated a component
[x] fixed a bug
[ ] added/updated a new route
[ ] added or changed css styles

@t-bello7 Check the image attached for the circled portion under the Get Started button in the Hero Section. I was referring to that when I mentioned that features be removed and not the Features Link. Please reach out if it's confusing. Thanks

@t-bello7 Thanks. Your changes have been approved and the PR & Issue closed.


add method for tag collector

+1

See #7483

I will factor out the tag collect stuff outside ReqMgr2 as Eric suggested but merge this one first.


Documentation should include simple and advanced examples

Generally, docs should have two levels of examples:

The simplest, minimal, sunny-day solution
A more complex solution that showcases optional or advanced features.

This was noted when UX study participants asked if they needed to use the ListBlobOptions(maxResults:20) line from the copy-pasted example.

Closing in favor of individual issues: #372, #373, and #374.


RichString::setHtml doesn't support  and  tags

The code below doesn't work properly: sup and sub tags are ignored
  QXlsx::Document xlsx;
  QXlsx::RichString rich;
  rich.setHtml( "m2")
  xlsx.write("A1", rich);
  xlsx.saveAs("richtext1.xlsx");

please run clang-format


Remove extra space

There was an extra space in an error message, but this PR gets rid of it.

Oh my we test for the presence of that extra space. I guess it was more important than I gave it credit for.

Wait.  Who says that two spaces after a period constitutes an "extra space"?

Wait. Who says that two spaces after a period constitutes an "extra space"?

Nearly all style guides 😉

Wait. Who says that two spaces after a period constitutes an "extra space"?

But perhaps not science???

Wait. Who says that two spaces after a period constitutes an "extra space"?

But truthfully, the fact that in this specific message, and in the other GoFSH messages I was seeing, we used 1 space, so I just thought we should be consistent.

I refuse to approve this PR, but neither will I reject it.  I leave it to the gods to determine its fate.


SB-906: Implement search for Nuget group and proxy repositories [in-progress]

@carlspring , do we need OutputStream for proxy repositories here?

the build required JNuget SNAPSHOT to be updated from our fork.
I have asked @steve-todorov to deploy it.

The snapshot has been deployed and it appears the build is now passing successfully :)

@ steve-todorov many thanks! you're cool, as always! :)

@sbespalov ,
The pull looks good! Would you mind addressing the comments and remarks? Thanks! :)

Guys thank you for your reviews. I have finished, so please approve or proceed.

ok
maybe it will be enough to make TODO: SpringProfiles .... here?
2017-10-25 10:44 GMT+07:00 Martin Todorov<EMAIL_ADDRESS>
@carlspring commented on this pull request.
In strongbox-storage/strongbox-storage-core/src/main/java/
org/carlspring/strongbox/repository/AbstractRepositoryManagementSt
rategy.java
https://github.com/strongbox/strongbox/pull/361#discussion_r146748728:

@@ -94,4 +96,25 @@ public Configuration getConfiguration()
return configurationManagementService.getConfiguration();
}

public static boolean shouldDownloadAllRemoteRepositoryIndexes()

The thing is -- I've been trying really hard to keep Maven and NuGet
concepts separated so that there is no unnecessary confusion. I had finally
split things apart with the configuration file changes the other day... I'd
really like to keep things separate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/strongbox/strongbox/pull/361#discussion_r146748728,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVunQ_rCIJMNyklYxTZn6UTqZYcIwBbgks5svq6ogaJpZM4P6GNO
.

@carlspring I have also merged SB-910 here.
So I think it can be merged, if there is no more review comments.


Command to install the extension

Hi
Thanks for your extension! I noticed that the command line for installtion should be
quarto add parmsam/quarto-quiz
and not
quarto add parmsam/quiz
Best

Thanks for pointing this out! Should be fixed now.


Cart icon too far right (iPad Air Safari vertical)

Seen in iPad Air safari vertical

This is now fixed, breaking point is 767px wide, passing this width mobile view kicks-in, that is ... button changes to square shape and search bar disappears.

Saw the issue on mac, with a small viewport of 990x950 on an older build.
Tested the fix on dev19, with same viewport, and the issue is gone now.


[opensubdiv] Add feature opengl

Describe the pull request

What does your PR fix?
Fixes #26924, add feature opengl, feature test pass on x64-windows.

Depends on https://github.com/microsoft/vcpkg/pull/26933


Renable GCP Loadbalancer Example

As part of the 0.18.14 release, we noticed a regression in GlobalComputeForwardingRule. This is breaking our loadbalancer example because it cannot resolve the IP address
This is being tracked upstream https://github.com/terraform-providers/terraform-provider-google/issues/4072
When this has been resolved, we need to re-enable this example

Closed via #188


Update to <IP_ADDRESS> changes

Added line regarding PSOM connectivity fix that should be in this update per internal email thread.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@LanaChin PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Remove redundant constraint

I commented about this in the other PR. This is unsound.

https://github.com/Plutonomicon/plutarch/pull/186


OOM issue

My platform is ubuntu22.04, RTX3090 with 24GB VRAM
When I trained on Nerf-DS datasets at as_novel_view scene on default settting, I always run out of memory.
This also happends on GUI training.
It seems like the after certain iteration,the number of 3d gaussian start to increase, and causing OOM error.
Is there any solution for this?

Can you show me the command you ran? I've never encountered an oom issue on the NeRF-DS dataset.

Thanks for reply.
Sorry, I tried to reproduce this problem on Nerf-DS datset, but it never show again. So never mind :)
But it did happen on HyperNerf Dataset.It seems like the deformation field joint training stage trying to allocate incorrect memory space.
Here  is the command I used for training with GUI on HyperNeRF dataset .
python train_gui.py -s data/HyperNeRF/aleks-teapot -m output/aleks-teapot --eval --is_blender
After 3k iterations, it shows CUDA OOM error.
RuntimeError: CUDA out of memory. Tried to allocate 15.11 GiB (GPU 0; 23.69 GiB total capacity; 5.81 GiB already allocated; 14.26 GiB free; 7.06 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
-teapot [07/12 03:24:44]
Tensorboard not available: not logging progress [07/12 03:24:44]
Found dataset.json file, assuming Nerfies data set! [07/12 03:24:45]
Reading Nerfies Info [07/12 03:24:45]
 [07/12 03:24:47]
Loading Training Cameras [07/12 03:24:47]
Loading Test Cameras [07/12 03:24:48]
Number of points at initialisation :  11835 [07/12 03:24:48]
Training progress:   8%|██                         | 3000/40000 [00:46<18:32, 33.26it/s, Loss=0.1931091]Traceback (most recent call last):
  File "train_gui.py", line 776, in <module>
    gui.render()
  File "train_gui.py", line 513, in render
    self.train_step()
  File "train_gui.py", line 568, in train_step
    render_pkg_re = render(viewpoint_cam, self.gaussians, self.pipe, self.background, d_xyz, d_rotation, d_scaling, self.dataset.is_6dof)
  File "/home/lwy/3dGaussian/Deformable-3D-Gaussians/gaussian_renderer/__init__.py", line 115, in render
    cov3D_precomp=cov3D_precomp)
  File "/home/lwy/.conda/envs/gaussian_splatting/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/lwy/.conda/envs/gaussian_splatting/lib/python3.7/site-packages/diff_gaussian_rasterization/__init__.py", line 219, in forward
    raster_settings,
  File "/home/lwy/.conda/envs/gaussian_splatting/lib/python3.7/site-packages/diff_gaussian_rasterization/__init__.py", line 41, in rasterize_gaussians
    raster_settings,
  File "/home/lwy/.conda/envs/gaussian_splatting/lib/python3.7/site-packages/diff_gaussian_rasterization/__init__.py", line 92, in forward
    num_rendered, color, depth, radii, geomBuffer, binningBuffer, imgBuffer = _C.rasterize_gaussians(*args)
RuntimeError: CUDA out of memory. Tried to allocate 15.11 GiB (GPU 0; 23.69 GiB total capacity; 5.81 GiB already allocated; 14.26 GiB free; 7.06 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF

Hi, the situation with HyperNeRF is normal.
I found in my experiments that the camera poses of HyperNeRF are not accurate in many scenes, which can lead to an exponential increase in the number of point clouds. You can refer to the supplementary materials of the latest version of the paper.
Therefore, HyperNeRF is only used as a reference, and the dataset I used in the main text is the NeRF-DS dataset, which has more accurate camera poses. You can refer to the demo on the project page to filter out the usable HyperNeRF scenes.

Hi,@ingra14m
Sorry, I haven't noticed that. it already shows in README file.
Thanks for your answer :).


Add check links test

Thanks for nbsphinx!
This adds a minimal link checking step with https://github.com/minrk/pytest-check-links. Hooray tests!
Unfortunately, the reason I'm making this PR is I think there's a regression on 0.5.1 that generates broken links... but it's hard to provide a minimal reproducing test case (or explore a fix) when there's no tests!
Stay tuned for the follow on!

Thanks for this PR!
The links (including http links) are already tested on CircleCI (Hooray tests!):
https://github.com/spatialaudio/nbsphinx/blob/e9881922b782ae0b89e9d517cb7688b88501a75c/.circleci/config.yml#L79-L82
So your tests are checking the same links again, or am I missing something?

I think there's a regression on 0.5.1 that generates broken links... but it's hard to provide a minimal reproducing test case (or explore a fix) when there's no tests!

Well there are tests, and they are passing.
Granted, the Sphinx linkcheck builder checks the links without building the HTML files.
But if there is a bug in the rendering of HTML links, that's a Sphinx bug, which should be tested for in Sphinx (and I guess Sphinx has tests for this?).
How do those broken links look like?

Well there are tests, and they are passing.

Great, sorry: a quick check of README, CONTRIBUTING.md, and git grep test came back negative. Didn't think to look in the other CI for check. Perhaps adding something in one of those places about the test regime?

without building the HTML files.

That sounds great, for unit testing. At the end of the day, though, if style, scripts, images, etc. get added by this plugin (or plugins it brings along or advocates) with broken links, or it fails to generate things that sphinx even recognizes are links (it's rather cavalier about what extension things need to have) then the product the user builds can be broken even though sphinx is working exactly as designed.

How do those broken links look like?

It's in fact the latter example where multiple formats come into play: on this pr i've got ipynb pointing to md files (that unfortunately get generated). Docs files did not change (yet) during the pull request, but going back to nbsphinx==0.5.0 let the generated content actually pass. A concrete example is here, where this link:
Returns a [named map of starters](../schema/v2.md#definitions-group-all-starters), as loaded via `traitlets`.

is still coming up as md in the output on 0.5.1, but in one of the generated outputs (in this case rst). :
_ /home/vsts/work/1/s/docs/_build/doctrees/nbsphinx/notebooks/REST API.ipynb: ../schema/v2.md#definitions-group-all-starters _

So either there is new content being created in my build in 0.5.0 that is unwanted, or it's breaking something that I did want, for some reason. I confess, I'm not much of a sphinx hacker, and could really care less about rst... hence my use of nbsphinsx. This PR was initial attempt to get a small amount of integration testing added, which could be gradually expanded to include a repro of the case above of my experience 0.5.1, but better characterized and less complicated.

Perhaps adding something in one of those places about the test regime?

I've created #399, does that help?

At the end of the day, though, if style, scripts, images, etc. get added by this plugin (or plugins it brings along or advocates) with broken links, or it fails to generate things that sphinx even recognizes are links (it's rather cavalier about what extension things need to have) then the product the user builds can be broken even though sphinx is working exactly as designed.

Yes, something like this could happen ...
However, I hope nbsphinx doesn't do any of those bad things you mentioned.
It shouldn't ever create HTML links on its own without going through Sphinx first.

i've got ipynb pointing to md files (that unfortunately get generated).

As long as the .md files are in the source directory while Sphinx is running, this shouldn't be a problem.
I've tried your example locally (with the master branch of nbsphinx), and it seems to work fine.
Sphinx is actually quite picky regarding local links, but it only generates warnings if something is wrong. You should use the -W flag to turn warnings into errors.
But in your example, there are no warnings for the link you mentioned. There is an unrelated warning, though:
docs/notebooks/Use Cases.ipynb:25: WARNING: undefined label: /notebooks/starters.ipynb#starter%20tree%20url (if the link has no caption the label must precede a section header)

This is a legitimate warning, you should replace %20 by -, then it should work.

[...] but in one of the generated outputs (in this case rst).

What do you mean by that?
Are you expecting .rst output somewhere?
Can you please elaborate what's the actual problem?

@bollwyvl Can you please answer my questions? Is the problem still occurring?

@bollwyvl Do you think this PR should replace the existing link testing on CircleCI?
I don't think we should test the links twice, right?

Unfortunately, the reason I'm making this PR is I think there's a regression on 0.5.1 that generates broken links... but it's hard to provide a minimal reproducing test case (or explore a fix) when there's no tests!

Can you please provide an example for those broken links?

Stay tuned for the follow on!

I'm still tuned!


Feature request: Timeslice - Add description field

Hi @SOYOS the timeslice does not need a description because the activity has one. So the activity is your task and you are able to add some timeslices to it.


Missing dependency: tf_slim

tf_slim is used in the source code but is not listed in requirements.txt

>> pip3 install tf_slim

I'll make the PR to fix it in requirements.txt

Before you make a PR, I'd like you to know that pip3 install tf_slim didn't work for me. But I found an article that suggests this command to install tf_slim and it worked:
pip install git+https://github.com/adrianc-a/tf-slim.git@remove_contrib


Add support for a horizontal rule in Markdown.

The Markdown --- should get converted to an <hr> tag

Closed by https://github.com/mingming-ma/txt2html/commit/3fab6c9619e8876f7da7183522db445ac82cfb53


[Snyk] Upgrade marked from 4.1.1 to 4.2.3

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade marked from 4.1.1 to 4.2.3.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 4 versions ahead of your current version.
The recommended version was released 23 days ago, on 2022-11-20.

Release notes

Package name: marked

4.2.3 - 2022-11-204.2.3 (2022-11-20)
Bug Fixes

fix entity specs (#2652) (36a2b63)
fix link reference definitions specs (#2654) (b7eea95)
fix marked.use with multiple args (#2651) (73a7bf5)
fix multiline setext headings (#2655) (4aee878)

4.2.2 - 2022-11-054.2.2 (2022-11-05)
Bug Fixes

fix escape characters in links (#2628) (44a2a23)

4.2.1 - 2022-11-024.2.1 (2022-11-02)
Bug Fixes

Support escapes within emphasis (#2627) (377823a), closes #2280

4.2.0 - 2022-10-314.2.0 (2022-10-31)
Features

export bin/marked (#2629) (bd8aad9)

4.1.1 - 2022-10-014.1.1 (2022-10-01)
Bug Fixes

remove smartLists from docs and code (#2596) (f6ba2e3), closes #2582 #2582 #2582 #2582 #2582 #2582 #2582

    from marked GitHub release notes

Commit messages

Package name: marked

b430f8b chore(release): 4.2.3 [skip ci]
af31a99 🗜 build [skip ci]
73a7bf5 fix: fix marked.use with multiple args (#2651)
4aee878 fix: fix multiline setext headings (#2655)
b7eea95 fix: fix link reference definitions specs (#2654)
36a2b63 fix: fix entity specs (#2652)
57a2031 chore(deps-dev): Bump node-fetch from 3.2.10 to 3.3.0 (#2657)
a281de6 chore(deps-dev): Bump eslint-plugin-n from 15.5.0 to 15.5.1 (#2656)
620a02c chore(deps-dev): Bump rollup from 3.2.5 to 3.3.0 (#2658)
fdbbec6 chore(deps-dev): Bump rollup from 2.79.1 to 3.2.5 (#2646)
60c800c chore(deps-dev): Bump eslint-plugin-n from 15.4.0 to 15.5.0 (#2644)
a625d72 chore(deps-dev): Bump @ babel/core from 7.19.6 to 7.20.2 (#2643)
a8aa6f4 chore(deps-dev): Bump eslint from 8.26.0 to 8.27.0 (#2645)
5e38496 chore(deps-dev): Bump @ babel/preset-env from 7.19.4 to 7.20.2 (#2647)
48e28e7 chore(release): 4.2.2 [skip ci]
1a87b9f 🗜 build [skip ci]
44a2a23 fix: fix escape characters in links (#2628)
3d389d5 chore(release): 4.2.1 [skip ci]
5eee913 🗜 build [skip ci]
377823a fix: Support escapes within emphasis (#2627)
54410cd chore(release): 4.2.0 [skip ci]
c05218a 🗜 build [skip ci]
715f88a docs: add cli extension docs (#2632)
b5bdcf9 chore(deps-dev): Bump jasmine from 4.4.0 to 4.5.0 (#2637)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Are we thinking that we want this update?


Flow 0.54 breaks our attempt at a "non-maybe" type

We use a function to strip out any potential undefineds from arrays, like so:
function compact<T>(iterable: Iterable<Maybe<T>>): Array<T>

Since 0.54, this seems to break and the inferred type for the function allows undefineds to "slip through" somehow.  Before Flow 0.54, this behaved as we intended it.
Example illustrating the problem.
Please run the example against 0.53 and 0.54 and see the difference.
Do you consider this a bug in 0.54, or is there a better way of annotating this function that I'm unaware of?

Hmmm, I might be missing something, but is there any reason not to use the built-in maybe, ?T? This works for instance: function compact<T>(iterable: Iterable<?T>): Array<T>. Note that I switched the test for a item != undefined instead of item !== undefined, if you'd rather stay with the strict equality, you can test against both undefined and null.

This looks very brittle at best. You assume that T should always be inferred as not Maybe<Something>, but this is not guaranteed.

Thanks for the quick suggestion, @AugustinLF.  We've been using our Maybe type everywhere, mostly since we just prefer a single "missing value" type rather than two.  We don't use null in our codebase at all.  Your modified version will open up the function to accept nulls as inputs, which is something we'd like to avoid.
I'm not looking for an immediate workaround, but more interested to understand why this is a problem since 0.54, as it may indicate a bug.  As @vkurchatkin just mentioned (thanks!), this is indeed an assumption I'm well aware of.  I guess I'm looking for a better way to express it.
@vkurchatkin I understand how it leads to the error, but… how do you explain the difference between my version and @AugustinLF's example?  Shouldn't that have the same behaviour?

Shouldn't that have the same behaviour?

@AugustinLF's version is just as brittle, it just seems to work at this time

@vkurchatkin Is there an expression or utility type that would let me express "any <Something> except when void"?  Ideally something like:
function compact<T: $NonVoid>(iterable: Iterable<Maybe<T>>): Array<T>
Where $NonVoid would basically be like "any type without a void member in its union".  That way, if Flow tries to infer Maybe<Something> (= introducing a void member in its union type), then this extra condition would prevent it and it would capture the intent here more strictly.
The question thus becomes… would something like the $NonVoid type be possible—or does something like it exist already?

Does this not work for you?
function compact<T>(iterable: Iterable<Maybe<T>>): Array<$NonMaybeType<T>>

Wow. Consider mind = blown! TIL about the existence of $NonMaybeType. Why isn't this useful thing documented on the Utility Types doc page? This is a life-saver. Thanks, @jcready!

@nvie that is an excellent question. It seems that having up-to-date documentation is not one of the flow team's goals.


Fixed compilation of Adwaita-based GUI

Fixed the issue of the search path not including the libadwaita path when compiling. The issue was reported and discussed in #167.

Ah, that explains it. Thanks for the fix!


Fix some race conditions in the integration tests

bors r+

I found some other tests that need mutexes, too.
bors r-

bors r+


Track expense - Unable to upload receipt to track expense

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.17-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Action Performed:

Go to staging.new.expensify.com
Create a new workspace
Go to workspace chat
Click + > Track expense > Manual
Submit a track expense without receipt
Go to transaction thread
Upload a receipt
Note that the receipt cannot be uploaded
Dismiss the error
Click on the preview in main chat to go to transaction thread
Note that the header shows [Deleted report]
Upload a receipt again
Dismiss the error
Now the receipt shows a green thumbnail
Click on the receipt
Note that the receipt shows an attachment icon

Expected Result:
User should be able to upload a receipt to track expense
Actual Result:
User is unable to upload a receipt to track expense. Error shows up when uploading receipt to track expense
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/user-attachments/assets/a95dd8dc-fdbf-4d62-a737-bf917603c7ad
View all open jobs on GitHub

@twisterdotcom  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

We think that this bug might be related to #wave-collect - Release 1

Haven't gotten round to testing this yet.

Sorry, I still want to test this some more because I can't really get my head around the steps.

Unable to reproduce:
https://github.com/user-attachments/assets/37d7f3be-dcee-436b-b869-b83fa075a11e


Ldanzinger/symbolf

@lsmallwood please review and merge. I did a search locally to find all that had style: ". Fixing enums and using default properties for some symbols and renderers

LGTM


setuptools.readthedocs.io History missing 46.0.0

https://setuptools.readthedocs.io/en/latest/history.html doesn't list 46.0.0
Is some integration with RTD broken?

Builds appears to be failing https://readthedocs.org/projects/setuptools/builds/10574350/

Here is the last successful build.

Comparing the tree between the successful and failing build, there's nothing meaningful there that should have caused the build to start failing.

I see the same error when attempting to build docs locally (tox -e docs).

Even going back to the checkout for the last successful build, that code now fails, so probably it's some interaction with another internal factor, perhaps the release of Setuptools itself.

The error seems to be another bootstrapping/race condition related to the removal of Distribution._finalize_feature_opts. It seems that although the entry point was removed, the reference to it lingers.

It seems that for whatever reason, the egg-info remains pinned to an old version:
setuptools master $ grep ^Version: setuptools.egg-info/PKG-INFO
Version: 45.3.0.post20200308
setuptools master $ grep finalize_feature setuptools.egg-info/entry_points.txt
features = setuptools.dist:Distribution._finalize_feature_opts

After running git clean -fdx, the docs build is now working reliably again (locally).

After resetting the build environments for latest and stable builds, the builds are now working and the docs are up-to-date. This issue was transient and probably safe to ignore.

Thanks for the fix!