Project System: Please Consider POCO as Schema for Project File/Structure

From @Mike-EEE on May 12, 2016 8:5
I (unfortunately) made a lengthy, somewhat off-topic post/rant about this in another thread yesterday so I am going to throw it down here in a dedicated issue and see how it goes.
There's talk about the new build system.  There has been previous efforts over at MSBuild to examine the build system and improve upon its format.  These were ultimately denied, expressing a "better safe than sorry" (huh? :stuck_out_tongue:) perspective.  So, with all the energy/enthusiasm/magic over here, this appears to be the new lightning rod for developer creativity. :smile:
My ask is simple: Continue to use the XML format (or even JSON), but move away from the element mapping-to-POCO strategy and make the csproj/xproj/proj file a fully (XML or JSON) serialized POCO instead, so that at the very least we know the precise POCO (and definition/schema) that we are dealing with and constructing.  This helps not only developer experience (and thereby sanity :smile: ) but also any tools/designers that wish to build off of it.
Currently, the project file looks like something like the following:
<Project>
 <ItemGroup> ... </ItemGroup>
 <PropertyGroup>... </PropertyGroup>
</Project>

This is great for defining arbitrary data in a file, but it is completely useless for someone who opens up the file and wondering: "what the **** is a <Project /> element?!"
The above design requires at least three artifacts:

The data file itself, expressing the data constructs (.csproj)
The schema file, defining what is allowed (.xsd if in XML, and I have never seen one in my 15 years of .NET for a .csproj file!)
The POCO that ultimately gets created from reading in the data file.

Oh but wait, there's more!  Due to the above design, I bet you there is at least a fourth artifact!
4. The mapping class/utility that reads in the data file as an XmlDocument and laboriously reads in element by element, attribute by attribute to create and instantiate the POCO object(s) with their initialized values. OH THE INEFFICIENT HORROR!!
Conversely, if we take a page from Xaml file design, we have the data file's schema baked right into the file by way of the class definition.  As a result, we only require two artifacts:

The data file (.xaml)
The class definition file (.cs/.vb)

This is a MUCH easier to design to produce, maintain, and manage.  Tooling can tie right into the class file (using Roslyn??? :smile: ) and get all the information it needs.  Developers do NOT need to hunt and chase down schemas in some arbitrary, hidden location (registry?! LOL, might as well be!) to figure out the file they are working with!
This is a very (relatively) simple design improvement that will make a world's (universe's!) difference in project look and feel.  I cringe every time I have to go into the .csproj file because it is SO ARCANE AND MYSTERIOUS TO WORK WITH!
Finally, by using a class definition as the schema, another headache that this eradicates is the inconsistency between camelCase and PascalCase when declaring/using symbols/attribute names within the file (ALL THE INCONSIST!).
Anyways, thank you for any consideration and dialogue around this idea.
Copied from original issue: dotnet/roslyn#11263

From @bbarry on May 12, 2016 13:32

(.xsd if in XML, and I have never seen one in my 15 years of .NET for a .csproj file!)

The xsds are in your msbuild bin folder: C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild
It doesn't help much (the xs:documentation tags almost look like they are generated by some ghostdoc-like tool; for example  is documented as "An MSBuild Project" in Microsoft.Build.Core.xsd), but they are there. There are a few useful comments in the file though.

From @Mike-EEE on May 12, 2016 13:38

The xsds are in your msbuild bin folder: C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild

LOL... right, of course... EVERYONE knows that! ;)  thanks though, @bbarry.  One less mystery to worry about. :)
Does it make sense what I am saying with POCO definition vs. .xsd schema approach?  If POCOs were used then there wouldn't be a need to store these xsd's in these highly intuitive, accessible, and discoverable locations. :stuck_out_tongue:  I am open to feedback and would definitely appreciate another perspective!

From @bbarry on May 12, 2016 15:17
I suppose it means the POCO is the xsd...
I really don't care what format is used or what intermediates are involved between an on disk representation of a visual studio / msbuild project and some set of tasks occurring (as long as they work). I do care that the on disk representation is:

discoverable
play nice with source control (see #6556)
human readable and hand editable
assisted by tooling when modified in an appropriate editor (VS)
extensible
provides a single point to drive interoperability of various components used to build the system (by modifying this file I could define compiler directives for Roslyn, manage Nuget packages, drive Grunt, test runners, static analysis programs, generators, filesystem operations and whatever else someone creates a tool to do something related to my build process)

From @Mike-EEE on May 12, 2016 15:31
Excellent list @bbarry.  That sums it up nicely and captures my sentiment as well.

Another observation/key takeaway made this thread that I think is worth repeating/capturing here is that there is a conceptual difference in "project definition" (.NET Core approach) and "project build process" (MSBuild approach).  I think this is where a lot of angst resides currently between the two systems and what the two sides are battling.
As someone who has had their hands in MSBuild for over a decade, this is a big "aha" for me, personally, so I thought I would share/capture it here.
Improving/clearing up the separation between these two concerns would go a long way.  As well as having a POCO-based model that allows to describe them both in a tool-friendly way. :smile:

I wanted to check in with this thread.  Lots of really great discussion here, but not much over here. :)  Since there seems to be a project system underway here, I wanted to reach out and hopefully get some feedback on the matter. It would also be valuable to maybe get some perspective/background on how this project is integrating with MSBuild, and what its take is on a POCO-based project defintion.  This strategy/design of course will allow/support different data formats so that developers can utilize the best tools they are familiar with to work with those formats and, by virtue of the design, the model. :smile:
After looking around this repo's documentation, it does appear that this is going to serve as more of a project definition, rather than process, do I have that right?  So, there will be a conceptual separation between definition (here) and process (MSBuild)?  If so, that would really be handy/useful/synchronous as that is what a lot of developers seem to be requesting. :sunglasses:

How about keeping both project.json and .csproj, where project.json is hand edited and .csproj is generated by dotnet restore and not synced in version control by default? The difference will be, instead of dotnet restore generating "project.lock.json" (and do other things), it will generate (or modify) ".csproj" file. The upside is, both formats of project.json and .csproj can stay unchanged. That means new generated .csproj will be compatible with earlier version of tools. Then .csproj being auto generated and not in version control, developers do not have to deal with editing and merging .csproj.
When @Mike-EEE stated the difference between "project definition" and "project build process", this came to my mind.

Thanks for the ideas/feedback @gulshan!  Really the idea here is to make everything both hand-editable and designer friendly.  I reference Xaml as the perfect paradigm and example of this.  Even when you are not in a visual designer, the tooling "lights up" to present to you a properties window where further designer tooling may be available.  I provide a good example of this here.
The process/solution you describe is a good idea and one maybe worth exploring.  However, at the end of the day this still relies on existing implementations which are not POCO-based and are data file format dependent (JSON for the project.json model and XML for the .csproj model).  These are two incredibly prohibitive, counterproductive qualities for developers/development and ones that should be avoided in all future solutions, which is what this issue aims to accomplish. :+1:
BTW, the definition vs. process "aha" magic meme should go to the lovely and gracious @shederman. :smile:  It's quite accurate, isn't it!

@Mike-EEE I am opening a new issue for that- #181

@gulshan ... yep, got the notification!  I will be watching.  Remember in all things: POCO and agnostic data formats. :smile:

@Mike-EEE I appreciate your drive and enthusiasm on the project format, however, we have no intention of changing the project format to XAML or any other new format. You've got some great ideas, however, large sweeping and cross-cutting feature suggestions that affect many teams across Visual Studio are better filed on http://visualstudio.uservoice.com (which I believe this one already has). Issues, features and bugs filed in this repo are intended to be actionable work items that a dev on our team or the community can pick up and drive to conclusion. This is not one of those issues.
Based on the fact that we're sticking with the existing MSBuild format, if you have actionable suggestions help improve the existing format, or bring some of the project.json features across to csproj, feel free to file them. Otherwise, I'm going to close this issue.
Regards, Dave

@davkean Thank you for taking the time to explain your position and for providing some guidance.  As you noted I have already supplied a vote on UserVoice, currently having a vote for every day of the year. :smile:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system
So I guess I am a little confused here on the best course of action, or ensuring that I am speaking with the right team. Currently there is this project, and then there is also MSBuild.  There also seems to be a "tooling" team/project somewhere?  Then there is also the fact that the vote that has been submitted that shows support but not much feedback/discussion.  Is there a team and/or resource that you can recommend so that I am devoting my time and energy towards these ideas efficiently and effectively?
Thanks again!

The project format is used and consumed by lots of teams inside the Visual Studio group, and around Microsoft. While MSBuild owns the format itself - any change they make can impact 10's of teams, so it's not something taken lightly. Given that project.json/xproj was an attempt to change the project format, and was found to be too damaging and impactful on ecosystem, I think you'll have a very hard time convincing Microsoft to move to a new different project format after we just made the decision to move back to MSBuild.
Your efforts would be better focused on ideas on making the existing format's experience better. You mention tooling; think about the kinds of tooling we could add to make working with csproj easier without throwing the baby out with the bath water. These are the sorts of issues you should be filing.

@davkean I think something is getting lost in the translation here as this is indeed aiming to make the current format and experience better. project.json/xproj went off to try to re-invent the wheel so it is not surprising we have come full circle back to the original. :)
Conversely, what I want to do is make the current process/experience better.  This is done by first using a POCO-based method rather than a data-document model as it is now.  This simplifies the current experience as developers are working directly with a POCO model, and also the infrastructure no longer needs to map document data to the POCO elements.
Additionally, once this is done, developers will be free to use any serializer they wish to define and describe their project documents using the tooling they prefer.  Data formats are no longer an issue (make a lot of developers happy) and the system as designed has a better experience.

@Mike-EEE I can speak for both MSBuild and my team, we have zero plans to enable developers to serialize the project format into a data format of their choosing. Project files are XML, and will remain XML. Let's move past this format discussion and move onto discussions that focus on the our roadmap ahead.

I do appreciate you taking the time to discuss this @davkean.  I know you are busy. :)  I just want to make sure that you understand that this at its core is not a format discussion, but rather improving the way projects (and application objects in general) are described, not only from a conceptual perspective and also from a tooling perspective (where formats would then indeed come into play).
I also realize and understand you (currently) have zero plans around this, clearly. :wink:  We have been baked in this very backwards paradigm of configuration/object description for over a decade now.  It not only prohibits/impacts developer experience, but makes solutions overly complicated (not to mention, provides poor guidance for the other projects that copy/paste its flawed design).  My hope with this issue along with creating the UserVoice vote is that we start to provide awareness around this flawed concept and thinking, and start moving to a more Xaml-way of object description model that provides way less development friction (and improves adoption).
(I feel I must reiterated that am not locked into Xaml "as a format", but am locked into its approach and development paradigm.)
Again, I appreciate your time here.  It is always an honor to speak with a blue badge. :)

Hi @davkean I would rather not be a thorn in your side, and please know my intent is to help carry the conversation here, especially with all the project.json madness currently under way.  In fact, I saw that you are doing the right thing and inviting developers to join the conversation here.  It doesn't look good to invite developers to contribute ideas and foster that discussion and then shut them down (regardless of the political situation -- which I understand and respect, mostly. :smile: ).
The other consideration is that I am providing this link out there to the interwebs and inviting people to (also :) ) join the discussion here, and it will look bad if they click it to see it as closed.
So, I'm wondering, is it possible to mark this issue as a "discussion" or "future ideas" "suggestion" or something more appropriate?  I would also recommend doing this for other "issues" that might crop up that are not entirely bugs or work items.  I'm trying to help you out while also ensuring that others feel welcomed and part of the discussion to make the best of the products we know and <3. :)
Thank you for any thought and consideration!

Hey everyone, I think this proposal is a fantastic idea and the attempt and the same approach was just undertaken by the Gradle team (Android/Java build chain), with them implementing a Kotlin version of the build script - supporting refactoring, auto-complete and many other benefits that specifying configurations in a POCO can bring.
It's notable that EF (from EF 2 onwards) took the same approach with POCO definitions, moving config from XML into OO, and the effect was a clear deprecation of the old, outdated format.
MSBuild is long due for a rethinking, and if there's anything learned from the JSON .xproj format is not that we can't attempt at making it better, but that when we do make the step as a community we need to be bold and take the right step, all the way. I think that the POCO configurations ARE the the right step, that XML is heavily outdated, and that JSON was a poor choice for many reasons (no documentation tags being a deal-breaker right from the gate). Perhaps something like YAML would have been much more appropriate, or if we want to be daring enough - actually take on something in C# that the .NET community already knows.
@davkean way to push this forward, you have my votes and support from this all the way.

It's notable that EF (from EF 2 onwards) took the same approach with POCO definitions, moving config from XML into OO, and the effect was a clear deprecation of the old, outdated format.

Thank you for your support @marchy!  You are absolutely right in that EF moved to a POCO-model and dropped their XML format altogether.  That is a fantastic example, and one I wish to illustrate.  Because they did this, now I can define my EF objects in my application in any way I deem fit and necessary (prefer).
Here is my illustration of this principle in action.  In my case I prefer Xaml as I get built-in tooling and designer support right out of the gate.  (I explain this in detail here).
Accordingly, when I create my EF objects now, as they are POCO's, I simply create a Xaml file and describe them as such.  Here is an example installation file of the EF entities I am currently using in the project I am working on:
Installer.xaml
When working on these files I do not have to worry about the "document model" or "schema" or having to track down an .xsd somewhere, or head over to google/bing to track down what a certain element is and its child elements.  I can simple "Go to definition" on the symbol and get taken directly to the source code.  It all "lights up" because it is all based on the POCO class definition.  This is how I see/prefer/desire all application object definitions to be described, and a perfect example of what I am striving after.  Additionally, since it is making use of Xaml in this case, I can take advantage of the format-specific features, such as markup extensions (as you see throughout the file above).
Thanks for reminding me. :smile:

@Mike-EEE I understand that you're a fan of XAML, but what does the declarativity of XML actually bring to the table when it has to be backed by compiled a .NET object model to do anything? Wouldn't it be much better to just write against the .NET object model and scrap XML altogether?
That's how Cake works. You write C# "scripts" that operate directly on the build engine's .NET API without any abstraction layer. Cake uses Cake to build itself and its own build script is in my opinion quite elegant.
The stuff you actually want to be declarative, like dependencies, could exist in the .csproj or packages.config, but wanting (and actually enjoying) to procedurally program a build engine in a declarative language does not make any sense to me at all.
Also, that installer.xaml file you point to is large and messy with all its namespaces, GUIDs and whatnot. Whether that file could be made easy to edit with sufficient tooling is not a particularly interesting venture to explore, imho. We should instead focus as much energy as possible on making the format itself easy to view, author and diff, without any tooling at all. You should be able to edit it directly on GitHub if you need to.

Hey @asbjornu thank you for joining the conversation!

That's how Cake works. You write C# "scripts" that operate directly on the build engine's .NET API without any abstraction layer

You know, I saw you post this in another thread and I never did provide my comment, which is THAT LOOKS AWESOME. :)  In fact, I still have cakebuild.net open in a tab to check it out. :)

Wouldn't it be much better to just write against the .NET object model and scrap XML altogether?

There are two primary benefits from using a data format:

Language-agnostic expression (not having to know how to code in a certain language to describe data).  This is cheaper from a business perspective as a resource required to work on data formats (configuration/maintenance) are generally less expensive (and more abundant) than resources required to develop code.
Tooling.  Tools are better suited to work with data formats than with code.  Granted, Roslyn makes this conceptually easier, but by and large it is much easier (and less expensive) to build a tool (and/or designer) around a data format than a compiled coding language.  In my world I still see and believe the day when we have visual designers for our build definitions and workflows.  Basically what TFS Build/Windows Workflow tried to do but instead done right. :stuck_out_tongue:

Also, that installer.xaml file you point to is large and messy with all its namespaces

Ah to you it is, but to me it's pure bliss!  Here again we get into format preference, which is one of the topics this issue addresses.  With Xaml, I rest at ease knowing every single symbol in that file is connected to a .NET POCO somehow and somewhere.  I can easily navigate through it and go directly the to object it represents.  There is a 1:1 mapping between every symbol in that document and its .NET equivalent.  It's why tooling works so well with it. :)
As for GUIDs, etc.  It's a data (initialization/installation) file so it's going to have lots of data.  If you prefer something more terse, maybe you would prefer to have it described in JSON or YAML instead? :smile:  That is exactly one of the points of this discussion, so that once the backing project model is well-defined and accessible, then developers can develop/define/describe their projects/definition in the format they see fit.

@Mike-EEE I'm glad you like Cake. It is indeed awesome! :smile: And if we can agree to decouple programming the build engine from describing the project and its dependencies, I think we can agree to disagree on format preferences. Because then, in theory, the declarative configuration of your project can be done in XML, YAML, JSON or whatever and the programming of the build engine can be done in any language supported by the Roslyn and/or .NET language toolchain.
For most projects, this decoupling would mean they would only have a very minimal declarative config file in the format of their choice and people could optionally add a procedural build file written against MSBuild's .NET API in a language of their choice.

YES to all of the above, @asbjornu!  We (now :smile:) have shared vision!  Remember that the project file is simply a configuration file, it describes the data, not what to do with it (the build engine).  Much like in the referenced Xaml file above, it contains all the entities (data), but there is obviously no logic/processing there.  That is handled by an internal component.
The major problem we are running into here is that the data file has historically been defined by an arcane/obscure document object model, which is then parse and subsequently mapped to a POCO.  This pollutes the design and makes it very difficult to work with -- developer and tool alike!
Part of the problem we indeed have now w/ MSBuild is that it currently does both, this has been identified/explored already in this thread (and others) and we all agree this is a poor separation of concerns.
All the while, (exactly as you say), if you have the data file, then it is conceivable that build systems (including MSBuild but not exclusive to it) can utilize this file to perform their own processing with it.  Hey, even Cake, maybe? :smile:
All done in the format (and subsequent tooling) that is preferred by developers and the teams/organizations they work on/with, reducing cost, and a little bit of angst/anger/stress while we're at it. :sunglasses:

Yes! I have nothing left to add. I think we're done here.

SHIP IT!!! Oh, wait. :smile:

Maybe I'm dense and this discussion is simply way over my head, but it seems to me that at the end of the day there's no difference between a data model that is defined as a POCO and subsequently expressed as a data format, and a data model defined as an XSL and subsequently expressed as a set of objects. Either way, same data, two ways to express it.
Furthermore, this concept that the on-disk format can be "whatever the developer wants" is also nonsense. What if want X12? What if I want ASTM? Who is going to write the parser for that? Me? If the first step to using your build system is to implement major components yourself, it's not going places.
Lastly, Cake and other fluent APIs can die in a fire. The first question to be answered here is, is it better to implement a toolkit for a build system (Cake), or is it better to implement a file that defines a project and have a build system that's smart enough to figure out what needs to be done based on that project definition (MSBuild+csproj/project.json)?

Hey @godefroi thanks for jumping in. :smile:

Either way, same data, two ways to express it.

Correct.  Except that one requires at least three artifacts (XSD paradigm -- which actually makes four artifacts once you account for the element-to-POCO mapper) and the other only requires two (POCO-based)

What if want X12? What if I want ASTM? Who is going to write the parser for that? Me?

If there is a .NET serializer for those formats then you won't have to. :)  What you would have to account for is creating a provider that tells MSBuild how to use that serializer to load and save files.  Also keep in mind that the idea here is that all the major formats are accounted for up front so unless you REALLY REALLY REALLY like your format and want to dive into creating a provider for it (which really shouldn't be too difficult), you won't be spending a lot of time implementing "major" components.  The idea is to leverage existing components/infrastructure and make the system as flexible as possible to provide options that improve/increase favorability and ultimately adoption.

@godefroi:

The first question to be answered here is, is it better to implement a toolkit for a build system (Cake), or is it better to implement a file that defines a project and have a build system that's smart enough to figure out what needs to be done based on that project definition (MSBuild+csproj/project.json)?

In my view, the one does not exclude the other. Instead of the merged bastard format that is MSBuild XML we have today, the two needs should be split up in two different formats; one declarative (XML or whatever) for describing the project and its dependencies and one procedural (like Cake) for programming the build engine.
Having both of these needs covered by one declarative format makes it the worst thinkable format for both.

A little nugget article I happened across that demonstrates a POCO-based approach.  It's in ASP.NET Core/JSON, but it's the mindset I think is what is important.  It is placing a class definition as the configuration schema over a document model as the schema, which this leads to less code to manage/maintain.  It's just prettier. :)
Here's Rick Strahl: https://weblog.west-wind.com/posts/2016/May/23/Strongly-Typed-Configuration-Settings-in-ASPNET-Core

Whoooaaa... am I to understand correctly that the CPS project system already IS using Xaml in some capacity?
https://github.com/dotnet/roslyn-project-system/tree/master/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules
If that is the case, maybe sanity will rule the day after all. :stuck_out_tongue:

Yes, we use XAML to describe items in the the MSBuild project and how that gets passed to various services in the project system.

The irony.  So it's not exactly the project system that is the mitigating factor here, but rather MSBuild.  Hopefully over time (another decade or so? :stuck_out_tongue: ) your good practices/approach will spill over there and we can start moving in the right direction here. :sunglasses:

@Mike-EEE I just gotta say it... your heart's in the right place but all those emojis, lathered on github reactions, and slashes/between/shades/of/different/meaning (and parentheses with asides that are hard to follow), and unusually EMPHATIC styles of speech- lol! It's so distracting and hard to read...

Now I'm seriously regretting saying that. I'll keep it to myself. I'm sorry, @Mike-EEE.

Not sure if I got it right, but the proposal is to move from XML to XAML?

@304NotModified the idea/concept/goal is to move from an XML-mapping-DTO-to-POCO paradigm (complex) to a POCO paradigm (simple).  Any object and artifact is simply a serialized POCO with a well-defined and known schema: the class definition.
Please do not get focused on the Xaml, as if a POCO-based approach is used, then any format can theoretically be used: XML, Xaml, JSON, TOML, YAML, even INI if you would like.  I use "Xaml" as it is the best representation/implementation of what is desired here.  Hope that makes sense.
(And @jnm2 haha thank you for the -- ghostly -- feedback.  I indeed get carried away sometimes, all in good fun/nature though.  I'll try to keep it in check... try. :wink: )

@Mike-EEE Lol, nice! I felt like a terrible person after saying it. Thanks for being cool.

^^ For that, you get one GitHub reaction. :smile:   (Sorry, I really like the fact you can do more than one!)

Thanks for the summary @Mike-EEE!

Hey @Mike-EEE I've started looking at doing something like this via a custom msbuild task over at https://github.com/aL3891/CustomPackageReferences, i'd love your input :)

Very cool @aL3891 !  Thanks for the mention. 😄
FWIW I was/am working on a POC as well for https://github.com/Microsoft/msbuild/issues/613.  Just a real simple console app will read in a JSON/XML and yes XAML :) to launch a set of commands.  Ironically, I got caught up in XML as it didn't render it as pretty as JSON.  But hopefully you can see where I am going with that with the files provided.
As for your efforts, I guess I need to be caught up to speed on PackageReferences.  I am wondering how this will allow us to describe build/project files in our own preferred formats?

As for your efforts, I guess I need to be caught up to speed on PackageReferences.  The base class just emits the ProjectReference items to the msbuild pipeline that are then picked up by dotnet restore

OK I am seeing it now @aL3891.  So this is for project references, then?  So you can describe your project (package) references in any format you wish?  I like the approach here, my only concern is that there is much more to a project file than references. :)  Are you looking to add more of that here or do I have this misunderstood?

Well its for package references (I realize I said project references above, that was a typo)
currently it allows you to specify package references in any way you want.
It is only for package references at the moment, although you could set other build properties if you'd like. Even if there are some limitations on what you can do in a target. From what I've seen though, being able to specify packages is the feature people seem to be missing most.

Ah!  OK @aL3891 haha TBH I am not 100% up to date caught up with VS15 and all the new finangled nomenclature. :(  So package/project was confusing.  Thank you for clarifying.  I am still on VS2015 (not to be confused with VS15 ;) ;) ;)) so ATM not able to open that solution without a bombardment of errors in the IDE.
So I do have a suggestion and have opened your first issue to discuss it.  See you there. :)

I'm going to close out this discussion, we've released VS 2017 RTM - and enabled the new project system and format initially with .NET Core/.NET Standard projects, and then later to all C#/VB project types, see: https://github.com/dotnet/roslyn-project-system/blob/master/docs/repo/roadmap.md for information.
Any further feedback is better opened as individual issues on this repro, the SDK repo or the MSBuild repo.

Thanks @davkean.  All interest and discussion has indeed been moved over the MsBuild repo as you suggest.  I have appreciated your patience and dialogue in this matter. 👍


Docker abstraction

This is what we talked about @chiefwigms. I wanted to move away from having our users dealing with git and python. Most end users won't know these tools... yes they won't know docker either :trollface:. Though I feel just requiring a single containerized tool is better user experience (no git issues, allows us to package server however we want, can upgrade server dependencies without users doing anything with pip or pip3, etc).

I'll fix the merge conflicts due to the base_path refactor

Oh thanks @chiefwigms yeah I don't have much time during the day for changes. With a toddler and a preschooler I cant get much time "alone" or "to myself".
🍻


Translate Using TypeScript Page

Finally 😄
It take from me alt of time, I hope that it will be empty from errors and misunderstanding 😁❤

@mahmood601 Why did you close that?

@mahmood601 Why did you close that?

I don't know!
I'm beginner in using Github and git 😅

I don't have to close pull request and delete the branch, I have to send the changes on the same branch 🤦🏻♂

I saw you've already opened another pull request #526
Read this comment https://github.com/reactjs/ar.react.dev/pull/521#issuecomment-1686745528
It's like a cheat sheet of git

I saw you've already opened another pull request #526
Read this comment https://github.com/reactjs/ar.react.dev/pull/521#issuecomment-1686745528
It's like a cheat sheet of git

Thanks, I will read that sheet 😁


feat(Registry): add support for IAM role authentication

As described in AWS best practises, application running on EC2 should not use hard coded Access Key and Secret Key and instead use  attached IAM roles to authenticate to Amazon web services.
Here's some fixes I had to made for boto to connect using IAM roles. I've tried to be as backward compatible as possible but I did not test other workflows (help needed :pray:).
I've also updated the customizing deis -> registry settings doc to include the keys that were added with the Running Deis without Ceph feature and the new s3assumeRole key.

This looks like a great addition, @laurrentt!

Is an S3Bucket of "" a viable bucket?  If not why is that the default value for S3Bucket and if not why have assumeRole=true instead of assuming if S3Bucket is set to a value you want to use S3 and fall back to IAM Instance access if access/secret key pair is not yet?

@sstarcher I thought at first that if you didn't specify the S3bucket key a default one was created for you. Since it's not the case, I also think your solution would be better. I'll make the change ASAP.

@sstarcher Done, let me know what you think.

I've added a default S3 policy to kickstart people willing to move from Ceph to S3.

LGTM

Is there a reason we're using ~ in some places as the default nil value, and "" in others?

@carmstrong The difference is that ~ will result in a None value in python and "" will result in an empty string. The docker registry (here) will try to connect using access key even if the value is empty which is not the case if the value is None. I could change almost change every "" to ~ but I didn't want to fix what's not broken.

This is falling victim in CI to a concurrency issue pointed out by Go 1.5. Once we merge #4335, that problem should go away after a rebase from master.

@mboersma Done

LGTM

@carmstrong, @bacongobbler Any news on this PR ? It almost been a month since it was opened...

Was this ever merged?

@sstarcher No but I just noticed every PR was just closed so I think there's something wrong happening right now :open_mouth:

Accidentally closed the PR.

@sstarcher @laurrentt my mistake apologies for the inconvenience.

@kalbasit No problem ! This was so sudden :laughing:, did you mess with the github API or something ?

No, one of my git aliases thought it's very funny to delete the master branch rather than the branch issue_4477 which was not supposed to be pushed here anyway :( long day I guess.

@kalbasit Well no harm, no foul

Jenkins, test this please.

This needs a rebase now. Sorry @laurrentt, we really haven't forgotten this PR. :snail:

@mboersma Done, and I've included the changes made in 81a8e1f134d8523689153b33329062985e9e5827.


Redirect filehelpers.com to GitHub Pages

After finishing the redesign point to the GitHub pages the main domain

For testing purposes we are using now: http://www2.filehelpers.com

I just buy www.filehelpers.net and use it for the new page
I will close this issue and create a new one to redirect old filehelpers.com traffic here


index-y interaction mode + convert horizontal bar defaults to new mode

This new mode resolves #3905 and works much better for a horizontal bar chart when intersect: false

Some thoughts: instead of duplicating modes for both axes, maybe we should introduce a new interaction options to select the orientation (axis: 'x|y|xy')?

mode: 'point', axis: 'xy' would be the current 'point' mode
mode: 'point', axis: 'x' would replace the current 'x' mode
mode: 'point', axis: 'y' would replace the current 'y' mode

Could also apply to nearest and index:

mode: 'index', axis: 'xy' would select items with same index horizontally and vertically
mode: 'index', axis: 'x' would select items with same index horizontally
mode: 'index', axis: 'y' would select items with same index vertically

(though not sure mode: 'index', axis: 'xy'` would be very useful)

@simonbrunel that would work. Axis x would do the current behaviour, axis 'y' would do the new behaviour. I don't know that 'xy' is needed but we could add it for completeness

Looks good (unit tests are failing though). Do we want unit tests for this new options?

I thought I fixed those tests. will check again

@simonbrunel i added some tests for index mode. if you like the style, I can add similar tests for dataset mode and nearest mode

Tests look fine, I would maybe also add tests for cases where it's supposed to return no elements (I don't know it that makes sense).

Updated per the comments. I cleaned up all the tests to use beforeEach where appropriate.

Awesome! Updated per your comment 😄


Issue updating from <IP_ADDRESS> to <IP_ADDRESS>

Getting this error when attempting to update:
Can't install lmagyar/aarch64-addon-mariadb-inmemory:<IP_ADDRESS>: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=<IP_ADDRESS>&fromImage=lmagyar%2Faarch64-addon-mariadb-inmemory&platform=linux%2Farm64: Not Found ("manifest for lmagyar/aarch64-addon-mariadb-inmemory:<IP_ADDRESS> not found: manifest unknown: manifest unknown")

Oh, gosh, I see, this is on the dev branch... And this image is nonexistent, because it's under development...
When I changed the default branch of the repo to master, HA's Supervisor hasn't refreshed it's internal database...
Proof:
~ docker exec -it hassio_supervisor /bin/bash
bash-5.1# cd /data/addons/git/45207088/.git
bash-5.1# cat HEAD
ref: refs/heads/dev

How to fix this (use the command line, eg. community ssh addon and putty):
docker ps                                                # just to test, that you have access to docker
ha core stop
ha backups new --addons 45207088_mariadb                 # WRITE DOWN (copy-paste) THE SLUG THAT IS PRINTED ON THE SCREEN
ha addons uninstall 45207088_mariadb
ha store delete 45207088
ha store add https://github.com/lmagyar/homeassistant-addon-mariadb-inmemory
ha addons install 45207088_mariadb
ha backups restore xxxxxxxx --addons 45207088_mariadb    # !!!!!!!! USE THE SLUG FROM THE BACKUP COMMAND ABOVE !!!!!!!!
ha core stop                                             # due to the restore, HA restarted, I think this is a bug in Supervisor, this messes up the database content
docker kill addon_45207088_mariadb                       # YES, KILL, the previously restored database export/dump will NOT be overwritten this way with the messed up database content
ha addons start 45207088_mariadb                         # usually unnecessary, but harmless, the add-on is restarted if watchdog is turned on
ha addons log 45207088_mariadb                           # check multiple times, that the log's end looks like this below, ie. the add-on is REALLY started, it can take up to 1 minute!

[12:42:22] INFO: Importing database content
s6-rc: info: service mariadb-core-post successfully started
s6-rc: info: service mariadb-backup: starting
s6-rc: info: service crond: starting
s6-rc: info: service mariadb-backup successfully started
s6-rc: info: service crond successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started

ha core start

Sorry, I'm not sure I understand.
Do I need to run those commands, or are you working on an update that will fix this for me?

Yes, we need to run those commands in the CLI to get rid of this error forever.
If you can wait for the next version, just wait a few days.
Situation:

HA remembers the outdated default branch name from this repo (I've changed it, I didn't know about this bug in HA), and I can't find a way to refresh it, only by completely removing and reinstalling the add-on. These are the commands above.
Now HA thinks that my "under development" new version is released. :(
I will try not to trigger this behavior in the future, not to modify the config.yaml file, only immediately before the release, so maybe I won't trigger this error too often if somebody doesn't reinstall the add-on. Sorry for the inconvenience, I'm also just a tinkerer, who sometimes messes up some things.

For those who use only the UI:

Use this if the current database content is not important.
Save the current configuration of the add-on. (Settings / Add-ons / In-memory MariaDB / Configuration tab / ... menu on the right side / Edit in YAML / copy-paste it somewhere)
Uninstall the add-on. (Settings / Add-ons / In-memory MariaDB / Info tab / Uninstall )
Remove the repository. (Settings / Add-ons / Add-on store / ... menu / Repositories / In-memory MariaDB add-on / Trash icon)
Add again the repository. (Settings / Add-ons / Add-on store / ... menu / Repositories / Add https://github.com/lmagyar/homeassistant-addon-mariadb-inmemory)
Install the add-on. (Settings / Add-ons / Add-on store / In-memory MariaDB add-on / Info tab / Install)
Restore the configuration (what was copy-pasted previously)
Start the add-on. (Settings / Add-ons / In-memory MariaDB / Info tab / Start)
Restart HA core (Setting / System / Restart)
NOTE: I didn't executed these UI steps myself. Though I'm sure there will be a lot of error messages from the recorder component in the HA log, that the database is not available during this reinstallation.


fix: support shufflenet

Description
This PR includes following changes

chunk.cpp: add a converter of aten::chunk op
conv_deconv.cpp: use ITensorOrFreeze(ctx) to pull ITensor
prim.cpp: fix errors in cases where Var is IValue containing a ITensor

After above changes, the shufflenet can be compiled successfully
import torch
import torchvision
import trtorch

model = torchvision.models.shufflenet_v2_x1_0(pretrained=True).cuda().eval()
input_data = torch.randn(1, 3, 224, 224).cuda()
scripted_model = torch.jit.script(model)
out = scripted_model(input_data)

compile_settings = {
    "input_shapes": [(1, 3, 224, 224)],
}

trt_ts_module = trtorch.compile(scripted_model, compile_settings)

Fixes #486
Type of change

Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project (You can use the linters)
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas and hacks
[ ] I have made corresponding changes to the documentation
[ ] I have added tests to verify my fix or my feature
[ ] New and existing unit tests pass locally with my changes

Hi, most of this looks good. We will review the changes. The first thing we need to do though is get your commits signed properly in accordance with the DCO (https://www.github.com/NVIDIA/TRTorch/blob/master/CONTRIBUTING.md)


Tighten python protobuf dependency to <=4.21.11 to fix potential segfault

Public-Facing Changes
Tighten python protobuf dependency to <=4.21.11 to fix potential segfault
Description
Reading an mcap file with mcap-protobuf-support can lead to a segfault which is very likely related to https://github.com/protocolbuffers/protobuf/issues/12047 (see https://github.com/protocolbuffers/protobuf/issues/12047#issuecomment-1622405787 for reproduction steps). This patch tightens the python protobuf dependency to <=4.21.11 as the segfault apprently only happens from 4.21.11 onwards.

Should we also add >3 or something to ensure a minimum compatible version?

Done, 3.8.0 is the lowest working version.


feat: adding zip as an output

Zip can now be selected as an output format, the compiled binary will be zipped up which can be directly uploaded to create an AWS Lambda function.
The --output-format paramters controls the output format, the two
current options are Zip and Binary with Binary being the default.
Example usage to create a bootstrap zip.
cargo lambda build --output-format Zip

Touched up the README.md and give an example using --output-format to produce a zip.

Touched up the README.md and give an example using --output-format to produce a zip.

When I run this command
cargo lambda build --output-format zip

in the rust template project from AWS SAM CLI, I get the following error.
    Finished dev [unoptimized + debuginfo] target(s) in 0.99s
Error:
  × Unknown file magic

If I just do cargo lambda build in that project, it does not throw the error.
Help appreciated!

Thanks! I kind of abandoned that and just used cargo lambda all the way and it worked like a charm.
This is an amazing tool and I really appreciate it.
At one point, the docs were a bit confusing for me because I couldn't understand what http-lambda was referring to, and found no description in the source, but all good now.
Question, is this tool officially supported by aws? I know they recommend it, but is it officially a part of it? (It should be, if it isn't)


Improve exception handling

Exception can be enhanced by passing causing exception as $previous when ApiException is created. Now it's impossible to get API response body from ApiException.

Expected Behavior
I'd like to get API response body from ApiException $e.
try {
...
} catch (ApiException $e)
(string) $e->getPrevious()->getResponse()->getBody();
}
Current Behavior
It's impossible to call $e->getPrevious()->... because previous exception is't stored.
Steps to Reproduce

Set editMode: $client->editMode(true);
Call $client->getStories($options)->getBody(); Now ApiException is thrown, because client is unauthorized.
Try to obtain serious information what's going on from ApiException $e.

Thank you @sharkodlak  for the valuable feedback.
Let me check it and come back to you with more information.


⚠ Auth has degraded performance

In 901a1f4, Auth (https://auth.k2lin.com) experienced degraded performance:

HTTP code: 200
Response time: 5498 ms

Resolved: Auth performance has improved in 20ffe6a.


MDC additions, and connection pool simplification

I thought I had already submitted / merged a PR for the connection pool simplification, but it came up here, so I'm submitting it again to make sure it goes through.
The rest of this is adding MDC information to make it easier to produce graphs for SLI analysis and tracking, along with production support (by adding parameters we can filter on and avoid all kinds of partial string searches). I'm also adding two new log statements in the MetricsInterceptor that will push the stats we're putting into our metrics system as MDC parameters. This might allow us to try out using ES / Kibana as a replacement (or refinement) for Graphite + Grafana.

Totally LGTM.
One little question. I just see that there is a new REST annotation added, but I did not see where it is used for handling (maybe I missed). Is it just a mark annotation to indicate rest services?

Oh, I missed the annotated in RestInterceptor. No problem now.


The Exact Command For Running The Flood

What is the Exact Command For Running The Flood?

root@pc:~/gocode/src/github.com/unixpickle/kahoot-hack/kahoot-flood# go run main.go
Usage: flood
exit status 1
root@pc:~/gocode/src/github.com/unixpickle/kahoot-hack/kahoot-flood# chmod +x main.go
root@pc:~/gocode/src/github.com/unixpickle/kahoot-hack/kahoot-flood# flood 451172 floodtest 10
flood: command not found
root@pc:~/gocode/src/github.com/unixpickle/kahoot-hack/kahoot-flood#

go run main.go


No Documentation on the size (length) that a parameter can be

Hi
The documentation does not detail the length that a parameter (eg ServerRelativePath) can be eg /sites/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz.aspx
Regards
Nigel
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 24abe9ef-b73c-515a-d41a-8f88b0c43880
Version Independent ID: 86b3d2ff-be86-42e6-6bd1-6735525f180e
Content: Rename-PnPFile (sharepoint-pnp)
Content Source: sharepoint/sharepoint-ps/sharepoint-pnp/Rename-PnPFile.md
GitHub Login: @techwriter40
Microsoft Alias: kirks

@officedocsbot assign @yogkumgit

@NPrice99 it would be the maximum possible based on the overall length limit for the location, up to 400 characters for the full unencoded URL. This would vary from tenant to tenant so an absolute number cannot be provided.

@tseward  Thank you very much for the contribution and sharing this explanation. @NPrice99
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Detect when code is reproducing a crash vs when it is fuzzing

Hi all,
I have a lot of fun using cargo fuzz on my projects! It lowers the barrier enough that fuzzing becomes simple, so well done :+1:
When I find a crash, I often need to debug it by adding extra dbg! or eprintln! calls to my code. Is there a way for me to leave this debug code in my fuzzer, but only activate it when I'm reproducing a crash?
I saw the #[cfg(fuzzing)] flag, but it is enabled equally in both cases (as it should be since reproducing the crash could rely on it). I looked at the command line arguments, but the only difference seems to be if the last argument is a directory or not. When I run cargo fuzz run backends_rust_generate I see:
[fuzz_targets/backends_rust_generate.rs:7] std::env::args().collect::<Vec<_>>() = [
    "fuzz/target/x86_64-unknown-linux-gnu/release/backends_rust_generate",
    "-artifact_prefix=/home/mgeisler/src/pdl/fuzz/artifacts/backends_rust_generate/",
    "/home/mgeisler/src/pdl/fuzz/corpus/backends_rust_generate",
]

vs when reproducing a crash with cargo fuzz run backends_rust_generate fuzz/artifacts/backends_rust_generate/crash-a3d9424297fe7b773102352b48b7bdd6b0457430:
[fuzz_targets/backends_rust_generate.rs:7] std::env::args().collect::<Vec<_>>() = [
    "fuzz/target/x86_64-unknown-linux-gnu/release/backends_rust_generate",
    "-artifact_prefix=/home/mgeisler/src/pdl/fuzz/artifacts/backends_rust_generate/",
    "fuzz/artifacts/backends_rust_generate/crash-c9b96795bcb23158a324f38824d56e24f04b6426",
]

Ideally, there would be another cfg value I can use to completely compile away the debug prints when fuzzing. Does that exist?

I would be in support of a cfg(fuzz_repro) or something.

I would be in support of a cfg(fuzz_repro) or something.

Cool, I opened #344 to implement this.

I highly recommend using tmin in these cases if you are not already... many times, I will learn more from the input than I will from the debugging :sweat_smile:

@addisoncrump, hehe, yeah I do use that and it's amazing to see it boil down my input :smile:
I've been fuzzing pulldown-cmark recently and there I found it super useful to be able to see the Markdown AST of inputs. I was able to order things so that I could print out the debug output only when I detect a problem, but it could have been nice to just sprinkle it all over the fuzzer instead.


Update README.md

Link has not been updated to the new package structure

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report

Merging #119 (b4eb9de) into master (d600328) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #119   +/-   ##
=========================================
  Coverage     45.98%   45.98%
  Complexity       72       72
=========================================
  Files            26       26
  Lines           511      511
  Branches         50       50
=========================================
  Hits            235      235
  Misses          266      266
  Partials         10       10

Continue to review full report at Codecov.

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


Null Reference Exception

We discovered the following NullReferenceException.
The command which is executed is executed every hour and deletes some records.
The code runs already for about a year exactly like this and we only saw this exception once.
One interesting detail:
The incoming HTTP request is logged at 8:15:07.000 AM and the exception at 8:17:10.049 AM
Exception message: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Data.SqlClient.SNI.TdsParserStateObjectManaged.ReleasePacket(PacketHandle syncReadPacket)
   at Microsoft.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
   at Microsoft.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
   at Microsoft.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
   at Microsoft.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
   at Microsoft.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at Microsoft.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at Microsoft.Data.SqlClient.TdsParser.ProcessAttention(TdsParserStateObject stateObj)
   at Microsoft.Data.SqlClient.TdsParserStateObject.ResetCancelAndProcessAttention()
   at Microsoft.Data.SqlClient.TdsParserStateObject.CloseSession()
   at Microsoft.Data.SqlClient.SqlCommand.EndExecuteNonQueryAsync(IAsyncResult asyncResult)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location ---
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQueryAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.ExecuteSqlRawAsync(DatabaseFacade databaseFacade, String sql, IEnumerable`1 parameters, CancellationToken cancellationToken)
   at OurAppCore.Persistence.AppDbContext.<>c__DisplayClass30_0.<<DeleteOldRecordsInBatches>b__0>d.MoveNext() in -:line 53
--- End of stack trace from previous location ---
   at OurAppCore.Persistence.BatchOperationStrategy.ExecuteBatchOperation(Func`1 command, Int32 batchSize, CancellationToken cancellationToken) in -:line 16
   at OurAppFeatures.VolleAdresseRecordsCollection.Housekeeping.VolleAdresseRecordsHousekeeping.CleanupAsync(CancellationToken cancellationToken) in -:line 56
   at OurAppFeatures.VolleAdresseRecordsCollection.Housekeeping.HousekeepingController.Cleanup(RunJobCommand runJobCommand) in -:line 24
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)"

To reproduce
We are not able to reproduce it.
Expected behavior
No null reference exception is thrown.
Further technical details
Microsoft.Data.SqlClient version: Microsoft.Data.SqlClient, Version=2.0.20168.4, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5
.NET target: .NET 5
SQL Server version: SQL Server 2019
Operating system: Docker Container (Alpine Linux)

Can you tell us which version of the library, and which library you're using? I remember that there were some changes recently to make releasepacket safer in edge cases which might fix this issue.

I posted the version of the Microsoft.Data.SqlClient already in the issue.
Which additional information do you need?

Your csproj would be nice.

Unfortunately, this will not be helpful. But I guess this is what you are looking for?

Very helpful!
Add an explicit reference to MDS 2.1.2

I'm not sure how I missed the version number. @ErikEJ has the correct solution I think, force the use of the latest package and that should resolve it if it's the recently fixed issue.

Thanks for your help. I assume that EF.Core is going to update the dependency to MSD 2.1.2 and as we saw this exception only one time, I will not explicitly set the reference but wait.
However, if we see this exception more often, I will update to MSD 2.1.2 and let you know if the exception occurs again.


Unsupported version of macOS detected '10.13'

If you are using 10.13 you'll currently get this error message, as referenced in https://github.com/duo-labs/EFIgy/issues/1#issuecomment-334033244

Thanks for the note, but as noted in the Readme the dataset (and the research in general)  only covers 10.10-10.12. It will be updated with data for 10.13 in due course but with Ekoparty and travel overlapping with the 10.13 release we haven't had time to get the analysis done and into the EFIgy dataset as yet.
We will add in 10.13 data once that analysis has been completed and verified.


About map_reduce.py

System Info
When I'm using "gpt-3.5-turbo-16k" model,This model supports 16k token.However, using the mp-reduce algorithm, if the answer obtained at A time exceeds 4000 tokens, this will be reported. "A single document was longer than the context length,we cannot handle this." Error.

I don't think the token_max parameter changes for different models
Who can help?
@hwchase17 @agola11 Hope to get help, this is very troublesome for my use
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[X] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction
My code:
chain_one = load_summarize_chain(chat, chain_type="map_reduce",return_intermediate_steps=True,verbose=True, map_prompt=PROMPT, combine_prompt=combine_prompt)
x = chain_one({"input_documents": documents},return_only_outputs=True)
documents chunk_size is 4000 tokens
ERROR:File D:\conda\envs\ai\Lib\site-packages\langchain\chains\combine_documents\map_reduce.py:37, in _split_list_of_docs(docs, length_func, token_max, **kwargs)
32     raise ValueError(
33         "A single document was longer than the context length,"
34         " we cannot handle this."
35     )
36 if len(_sub_result_docs) == 2:
---> 37     raise ValueError(
38         "A single document was so long it could not be combined "
39         "with another document, we cannot handle this."
40     )
41 new_result_doc_list.append(_sub_result_docs[:-1])
42 _sub_result_docs = _sub_result_docs[-1:]
ValueError: A single document was so long it could not be combined with another document, we cannot handle this.
Expected behavior
I hope that when I use the large token model, these errors will not occur

I tried to add a new model to openai under langchain framework

I temporarily solved the problem by directly modifying the value, hoping for a better solution

@hwchase17  @agola11  does anyone on the langchain team, has a better solution than changing the source code ? thank you

@SinaArdehali I have contacted the langchain team, they are working on some of the fixes around this issue.

@SinaArdehali I have contacted the langchain team, they are working on some of the fixes around this issue.

Good news！ thank you

@Ooho1997 @SinaArdehali My discussion with them is more about the mapreduce implementation itself. If you want to be able to set token_max here is how you can do that :)
res = await chain(inputs={'input_documents': texts, 'token_max': 12000}, return_only_outputs=True)

@Ooho1997 @SinaArdehali My discussion with them is more about the mapreduce implementation itself. If you want to be able to set token_max here is how you can do that :)我与他们的讨论更多是关于mapreduce 实现本身。如果您希望能够设置 token_max 这里是您可以做到的:)
res = await chain(inputs={'input_documents': texts, 'token_max': 12000}, return_only_outputs=True)

thanks, Now I know my problem

@Ooho1997 Awesome! If you don't mind please close your related issues solved by my comment, it would help keep it clean for those of us tracking related changes around the mapreduce / token_max implementation.


WebSocket client support

v0.15 will not feature client support but will be added later on together with proper Http client. It would make sense to add client support in a separate release just for that.

Will it support http/2 ?

+1 to a client

would be nice a ws client

for those who need a sample client websocket , it wraps https://libwebsockets.org/ (pure C)
https://github.com/maurodelazeri/bitmexcpp

It seems like you're going to handle this in the next version.  I was wondering if there would be any issues if I use libcurl multi stuff with the Loop's defer in order to be a simple http client for now.

uWebSockets is the fastest ws client library out there. Adding ws client support to 0.18 would allow people using 0.14 to upgrade to the new version.
One possible API, based on @AdrianEddy third suggestion:
// WebSockets to https://example.com/ws
uWS::SSLApp({})
.ws<UserData>("*", {
    .open = [](auto *ws, auto *req) {
        // ...
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    }
}).connect("example.com/ws", 443, [](auto *token) {
}).run();

Status on this? Thanks.

Nobody is paying for a client and I haven't come up with any good interface for clients yet.

Please write a few examples of how it could look like in code

I think your (server) APIs are really nice and close to what nodejs has. Perhaps, client should also follow what works well in nodejs?

Problem with these proposed client interfaces is that they break the entire idea with uSockets: to hold a socket context and then instantiate a socket referring to that context.
In other words; you have to first define a shared behavior (the context) then from that context create a socket.
You cannot do both in one function call because then the entire point of all memory hierarchy is wasted.
So the app.ws call needs to be separate from the app.connect call but the app has to be able to hold many different contexts and app.connect has to refer to what context it should use.
The only proposal that remotely follow this rule is this one:
uWS::SSLApp({})
.ws<UserData>("*", {
    .open = [](auto *ws, auto *req) {
        // ...
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    }
}).connect("example.com/ws", 443, [](auto *token) {
}).run();

Is it suppoed to map outgoing URL "example.com/ws" to the pattern "*"? Like an inverted Http router?

Perhaps, client should also follow what works well in nodejs?

Absolutely not. Node.js is the anti-inspiration in every sense.

I'm trying to wrap my head around what you're saying.  When I referred to uWebSockets14 client the way the connections happened were with Hubs like so:
uWS14::Hub* hub = nullptr;
uWS14::Group<uWS14::CLIENT> *hubGroup = nullptr;

hub = new uWS14::Hub(0, false, 16777216);
hubGroup = hub->createGroup<uWS14::CLIENT>();

hubGroup->onConnection([](uWS14::WebSocket<uWS14::CLIENT> *ws, uWS14::HttpRequest req){
  std::cout << "Connected" << std::endl;
  std::string workerInfo = fmt::format("workerinfo-mastersignature:{}/workername:{}/");
  ws->send("hello", 6, uWS14::OpCode::TEXT);
});

hubGroup->onMessage([](uWS14::WebSocket<uWS14::CLIENT> *ws, char *message, size_t length, uWS14::OpCode opCode) {
    std::cout << "Got reply: " << std::string(message, length) << std::endl;
    ws->send(message, strlen(message), uWS14::OpCode::TEXT);
    //ws->terminate();
});

hubGroup->onDisconnection([](uWS14::WebSocket<uWS14::CLIENT> *ws, int code, char *message, size_t length) {
    std::cout << "Disconnect." << std::endl;
});

hubGroup->onError([](uWS14::CLIENT::type errorType){
  ERROR("HubGroup Error, couldn't connect: {}", errorType);
});

hub->connect("ws://someservice.local:3333", nullptr, { }, 5000, hubGroup);
hub->connect("ws://someOtherService.local:3334", nullptr, { }, 5000, hubGroup);  // note the reuse of hubGroup

It seems to me that the HubGroup from the past is similar to the socket context that you're talking about.  The slick thing about the current version of uWebSockets is that the websocket context is built into the server application initialization.  At first glance I don't think that's easily possible to do on the client side.  Each connection needs its own handlers unless you want to heavily generalize it.
I think a modified version of https://github.com/uNetworking/uWebSockets/issues/791#issuecomment-585656572 would work best.  No .connect(), just .run().
uWS::SSLApp({})
.wsClient<UserData>("wss://example.com:443", {
    .connection = [](auto *ws, auto *req) {
        // ...
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    },
    .disconnection = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    },
    .error = [](errorType error) {
        // ...
    },
}).run();

That rvalue reference settings object is essentially the aforementioned HubGroup from what I can tell.  Can you just either have an array of them or allow multiple callings of wsClient to set the handlers and context for different connections?  If it's possible to refer to the SSLApp later then we can connect to a bunch of stuff from within the handlers or with some kind of functionality inside the UserData.  I think HubGroup isn't really a good name for it btw.  I have no suggestions for names.

I would like to add that I have not dropped down into the uSockets internals much so I don't know how reusable the us_socket_context_t is or what can be derived from them but from the hammer test https://github.com/uNetworking/uSockets/blob/577c822ac2e27d297eb6ea8712c84db5bbfe3b44/examples/hammer_test.c it seems like they share something.

Last post for the night, but I think that settings object would work for choosing if we're sending a get, post, or put as well if it's just an http request instead of a websocket initialization request. That would be a Client instead of wsClient.  I think doing it that way would make it easier to fold both the client and the server together into one run loop.  Whether you want to do that or not is still up in the air though.

OK so I looked into doing some rough socket work with uSockets and I think I understand what you're getting at by saying that the app.connect needs to understand what context it should refer to.

struct user_data {
    char *backpressure;
    int length;
    int testvalue;
};

struct us_socket_t* s = us_socket_context_connect(SSL, client_context, other_host, other_port, NULL, 0, sizeof(struct user_data));

struct user_data *usr = (struct user_data *)us_socket_ext(SSL, s);

That usr right there is separate from any other connection you create even with the same client_context so that equates to the UserData from my previous suggestion.  Is the socket_context for connections only used to connect the loop, handlers and ssl options to the socket?

It's a hierarchy from most general to most specific. Only the most specific memory is kept per socket. The most general is kept per loop, which is kept per thread. Every part can have user data, even loop and socket context.
So all settings and callbacks are stored per socket context, not per socket. That's why sockets are down to 90 byte or so. This is very different from how most other implementations do it

The socket context is the "behavior". Sockets are created using a specific "behavior". Therefore the API needs to work like this; first you define the behavior then you instantiate from that behavior a socket

If it's meant to work like that then the previous suggestion is definitely clunky.  Maybe this makes more sense? C++20 allows string literals as a template parameter.  I think that feature makes this possible.
Here's how it should be initialized
uWS::SSLApp({})
.context<"ContextName", UserData>({
    .open = [](auto *ws) {
        // ...
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    },
    .ping = [](auto *ws) {
        // ...
    },
    .pong = [](auto *ws) {
        // ...
    },
    .close = [](auto *ws, int code, std::string_view closeVal) {
        // ...
    }
})
.context<"ContextName2", UserData>({
    .open = [](auto *ws) {
        // ...
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        // ...
    },
    .ping = [](auto *ws) {
        // ...
    },
    .pong = [](auto *ws) {
        // ...
    },
    .close = [](auto *ws, int code, std::string_view closeVal) {
        // ...
    },
})
.run();

Here's how it could be used while looping.
This should work for the websocket client
struct SocketUserData{
    void* something = nullptr;
};

uWS::connect<SocketUserData>(std::string_view contextName, std::string_view host, uint16_t port);  // if the template literals don't work
uWS::connect<"ContextName2", SocketUserData>(std::string_view host, uint16_t port);  // if the template literals work

These should work for http requests since the signatures are different.  The API is clean but I don't know about its clarity.  Maybe you can do something with contexts here as well for default handlers.
uWS::get(std::string_view host, uint16_t port, fu2::unique_function<void(uint8_t*)> &&handler);

uWS::post(std::string_view host, uint16_t port, uint8_t* data, fu2::unique_function<void(uint8_t*)> &&handler);

uWS::put(std::string_view host, uint16_t port,  uint8_t* data, fu2::unique_function<void(uint8_t*)> &&handler);

uWS::patch(std::string_view host, uint16_t port,  uint8_t* data, fu2::unique_function<void(uint8_t*)> &&handler);

uWS::del(std::string_view host, uint16_t port, fu2::unique_function<void(uint8_t*)> &&handler);

Input would be appreciated.

I can't help but feel you've already thought of this solution before but it's the best I can seem to come up with.

The idea currently is that you attach behavior (context) to routes (URLs), then listen to incoming connections.
Doing the opposite for clients, attaching behavior to whole URLs and then referring to that behavior when connecting could be a natural extension.
This is close to, or identical to what @AdrianEddy proposed.
This makes sense because your behavior is very likely to be grouped by URLs, not by any individual connection. So for instance, all websockets connecting to wss;//api.bitfinex.com are very likely to have the same behavior.
SSLApp().wsClient("api.bitfinex.com", {the behavior here, defined once}).connect("wss://api.bitfinex.com", [](auto *error) {}).
I think this solution has the same benefits and drawbacks as the current incoming router has, for instance, defining the same behavior for many different routes or URLs requires duplicated contexts - but by using wildcards this could be mitigated in similar ways as we already do.
I think this is the best and cleanest API to build on, for now. It makes a lot of sense in my mind, and allows to efficiently re-use contexts when establishing many connections to the same URL/service.

You could have "" wildcards for all outgoing URLs, ".bitfinex.com/*" for semi-wildcards, or entirely static "api.bitfinex.com" ones. "wss://" or "ws://" should be excluded, or ignored if present.
This does make a lot of sense to me. Clearly the best API!

To those wondering about status - as you can see we have a rough idea about the APIs, but this remains a low priority issue that is not being worked on.
I don't have any customers who want or need client support, they are all on the server side and only care about server side performance. If you want client support, you can order it by paying for contracting hours required to make this happen. I would say 2 weeks or less.
It's not going to happen by waiting for it to happen, so if you need this it's up to you. I have no intention to work on things I have no use for. And frankly, if something is not paid for that means it has no commercial value, hence shouldn't exist. It's basic capitalism at play.

As you prefer. But the client support would make the library more complete and allow people like me to use it instead of discard it. Cheers ;)

As you prefer. But the client support would make the library more complete and allow people like me to use it instead of discard it. Cheers ;)

Go ahead, use an inferior, poorly conceived websocket library since you don't care about quality.  If you cared about your work you'd use this one.

But I only need to build a secure version of a client websocket. So why should I use this one that does not provide it to me?!

Then it isn't for you and you have discarded nothing.   Doesn't change anything.

the server is where all the performance needs to be, you could use any old client for the websocket client, if you use javascript Deno 1.4 was just released with websocket client https://deno.land/posts/v1.4#websocket-api

The above clarifications about the use-case and intention of providing server, but not client, support was very helpful and potentially worth summarized inclusion in the README, though not necessary given the callout in the heading as being a "web server".

Any status updates?
I'd be willing to provide some funding for the development of a client if that is an option.

Any status updates?

"You want a lever for your gearbox? Pfft, here's the cog you can slide it with your bare hands".
And for SSL, the code is different! Wow!

@alexhultman Hi Alex, can you create a grant on Gitcoin? So that people who need client APIs can support you

@alexhultman any update on this?  We've reached the point where we're running other websocket and http clients in a separate thread and we're piping them in via Loop::defer and to be honest, it's pretty nasty.  Seems there are a few people willing to sponsor this feature - is this something you're still interested in doing for cash?

Status is as it was last time someone asked for a status.

The last status update you gave contained this:

I don't have any customers who want or need client support, they are all on the server side and only care about server side performance. If you want client support, you can order it by paying for contracting hours required to make this happen. I would say 2 weeks or less.

So does that mean you are, or are not interested in doing paid contract work to implement this feature?

I have to check, can you contact me over email

FWIW, my codebase is pure C++17, for both the client and the server. With the former used to test and drive the latter.
(custom industry-specific protocol using WebSocket as the transport). I understand most people use clients
directly in the browser, or in Node.JS, so I get why you do just the server. Still, there's definitely (non-paying...)
interest for a C++ client with the quality and speed of your server. Not having two 3rd parties for WebSocket is
in part what's holding up adoption here (not that you care either :)).

I finally know why my question was rejected. It turns out that the developers don't intend to make the framework better, but just want to provide only a few interfaces, that's fine. I understand. But there is really no need to speak ill.

+1 for client support.
@alexhultman would you be open to accepting PRs that gradually implement a client? I'd be willing to chip in time towards this effort!

To those wondering about status - as you can see we have a rough idea about the APIs, but this remains a low priority issue that is not being worked on.
I don't have any customers who want or need client support, they are all on the server side and only care about server side performance. If you want client support, you can order it by paying for contracting hours required to make this happen. I would say 2 weeks or less.
It's not going to happen by waiting for it to happen, so if you need this it's up to you. I have no intention to work on things I have no use for. And frankly, if something is not paid for that means it has no commercial value, hence shouldn't exist. It's basic capitalism at play.

Let's say, we would be interested in this.
About how much are we talking here?

What is your company?

Does it have to be a single company that pays for this? If we can get an estimate for how much it'll cost, one of us could start a gofundme or something.
I know I'd be willing to contribute some. I don't have a use-case for both a server and client right now, but this seems to be the best cpp websocket library and I'd rather integrate it into my current project from [close to] the beginning, since I do have future plans that involve both a server and client. (Right now it's just a client, so I can't use this)

If you do some kind of crowd funding there's 25% VAT added, and again it highlights the underlying problem; no commercial interest

Triasmus
Does it have to be a single company that pays for this? If we can get an estimate for how much it'll cost, one of us could start a gofundme or something.
I know I'd be willing to contribute some. I don't have a use-case for both a server and client right now, but this seems to be the best cpp websocket library and I'd rather integrate it into my current project from [close to] the beginning, since I do have future plans that involve both a server and client. (Right now it's just a client, so I can't use this)

Given that the rates are between SEK 800 - SEK 900 you can assume it will take "at least" 1 month (maybe 2) to complete (approx. 167 h per month). That translates to SEK 167000 - SEK 187875 VAT included, just to give you a hint what kind of money it will cost. My company charge the same amount per hour so that's what you usually have to pay for a professional to develop.

I'm in the US, so there wouldn't be VAT added based on the source of the money (unless you have some weird laws...). If I were to organize the GoFundMe it'd just be a "Help me pay for uWebsockets to implement client capability."
I assume your problem with "lack of commercial interest" is more along the lines of "no one will be paying you to maintain it after implementation?" There are obviously people willing to put some money towards it, and we won't know how much until we could get some sort of pledge going, but a lack of funds for ongoing maintenance would put a damper on things.

@Triasmus I think the discussion went a bit off topic, things that might or might not be true.

@uNetworkingAB I will add H3App experimental suporte to C API and after this can I send an PR for a client?

wouldn't be VAT added based on the source of the money (unless you have some weird laws

We have weird laws. There is 25% added VAT to anything that touches individuals, regardless where in the world they are. Swedish companies must pay this fee straight to the Swedish state.

You have developed the Ferrari of websockets
Not having a client is like owning a Ferrari and using it on a gravel bumpy road
Your benchmarks could include not only the best serving but also the best performant and stable links

@pha377 calm down bro, @uNetworkingAB i'm working in an WS Client based on uWS, can i open an PR for this when i have something more stable? I will try to collab with uWS on my free time. In this case this client is for my personal usage, but can evolve with time.


[Style Enhancement] Adding typing animation on header of pages

Description
@apoorvaron How about adding typing animations for About, Faq, and Privacy Policy Headers??
In my opinion, it will improve the aesthetics of the site and will look great.
We can make the animation run only once after the page load or make it run infinitely, let me know in which way do you want if you agree upon this feature.
Screenshots
I want to add Typing animation similar to below:
https://github.com/apoorvaron/Shorty/assets/86224794/d6779187-2d9d-451f-a813-edfb37d6c4b0
I want to add this animation in the below header section of about, faq, and privacy policy

Additional information
No response

@AlfiyaSiddique I don't think so , animation is good but not for navbar links.

@AlfiyaSiddique I don't think so , animation is good but not for navbar links.

Just to clarify, I was not asking to implement animation in navbar links but the title which says ABOUT on the dark blue background and not the one on the navbar.
But if you think it won't look better their as well then it's okay we won't implement👍

@AlfiyaSiddique Okay , do it for one page. if this will be approved then will tell you to add on another pages too

I will update the level accordingly

@AlfiyaSiddique Okay , do it for one page. if this will be approved then will tell you to add on another pages too

Okay sure 👍

@AlfiyaSiddique Update ?

@AlfiyaSiddique Update ?

@apoorvaron I'll complete this by end of day or till tomorrow afternoon, don't worry!

Okay

can u assign this issue to me

@Pavithra-ks-06 I'm working on this issue. And I'm going to submit a PR by this night or tomorrow afternoon.
But yeah, you can feel free to find new issues or bugs on this cool repo or propose new ideas. 👍🏻

Sure

@apoorvaron This is how the animation looks:
https://github.com/apoorvaron/Shorty/assets/86224794/895d6722-8b04-4f76-8edc-0ab8cb3b8126
We can increase or decrease the typing speed as per our need and we can make it infinite or run only once after load.
In my opinion, it should run only once after load. Tell me yours.
Also provide your feedback on this .

@AlfiyaSiddique Make a PR, will remove there (Reason: I can run locally)

@AlfiyaSiddique Make a PR, will review there (Reason: I can run locally)

Okay, I have implemented this only in About Page for now, I will raise a PR, then once you review and approve this feature then I'll implement the same for FAQ and Privacy Policy page as well.

Yes


Add ability to change the default dispatch queue for all promises

This PR allows you to change the default dispatch queue for all promises in Swift and in ObjC.
It fixes: #280 and allows you to use Zalgo in unit tests so that you don't have to depend on dispatch_async so you can get fast deterministic tests (http://martinfowler.com/articles/nonDeterminism.html)

I like it.

I think there should be just one function, do it in objc so it is accessible from both
I think it should be named PMKDefaultDispatchQueue() since that is more consistent with other such things in PromiseKit.

@mxcl I changed the name, made it accessible from both, and all tests pass (aside from an existing Issue which I submitted a separate PR for). Thanks!

Looks good to me.

LGTM! Many thanks.

No problem! Thanks! Do you know when this would be merged into master?

Tomorrow morning if not tonight!

Squashed and merged. Closing manually.
Thanks again, @programmerdave!


fix: npe in sync controller

Fixes nil-pointer error in the sync controller

lgtm

I am going to try closing and reopening to trigger the cla check again


Remove staff from Calendar (Derek Edit)

As a User I when I remove a staff member from the list I want this to also remove the staff member from the Calendar so that I can see the update in both components.

[x] #91
[x] #92

continue to trouble shoot in Sprint 4


Latex error handling

Problem

Markwon version: {4.2.1}

Good day to you,
I was trying to get a listener/callback to get Latex errors back to my UI code.
This is useful, because then I can display error messages to users in the event of wrong latex code.
The errors are caught here:
https://github.com/noties/Markwon/blob/8d3f0e908db36d4cc4517aee1d76169ec5f9593f/markwon-ext-latex/src/main/java/io/noties/markwon/ext/latex/JLatexMathPlugin.java#L278-L285
and I see there is no way to plug in an error listener. Not even by creating a child of this JLatexMathPlugin.java which overrides this part of code, as the code is annoyingly package-private/private.
You can trigger referenced code by rendering some latex like:
\sum_{i=0}^\infty x \cdot 0 \rightarrow \iMightNotExist{0}

My question
Is there any way to get latex errors I am not yet aware of?
If so, perhaps you could update the documentation to show how.
If not, perhaps this is a good enhancement for a future implementation?
It really is easy enough to add it to the source code for JLatexMathPlugin.java.

Hello @Sebastiaan-Alvarez-Rodriguez !
You are right, latex module currently lacks error handling. I'm thinking of similar error handler to the images module:
public interface ErrorHandler {
    @Nullable
    Drawable handleError(@NonNull String latex, @NonNull Throwable throwable);
}

Latest 4.3.0-SNAPSHOT version has it

Hi,
thanks for the quick response and code enhancement!
I will try to use 4.3.0 and use this new feature.


Fetch latest version

Related to #34 , could we have a function for

detecting latest version
Perhaps set  load_austraits to by default get the latest version?

close with 734f42


New version: Redisant.IEC104ServerSimulator version <IP_ADDRESS>

Created by 🥟 Dumplings in workflow run #10068.

Log
Updated: <IP_ADDRESS> → <IP_ADDRESS>
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Socket parsing from strace does not appear to capture all sockets

The strace parsing appears to be missing sockets.
For example: gs://ossf-malware-analysis-results/pypi/argpars/0.0.0.json
Clearly there is a wget http://80.78.25.... but the IP address does not appear in the socket output.

Is there any way we can recover the argpars package in question to reproduce / debug this issue?

Found it, the link still seems to work for now - https://files.pythonhosted.org/packages/b8/0f/d78e840184b553c6e463e1d1c98cafd7119fa8bd8f0f47a724fe4aaa7de6/argpars-0.0.0.tar.gz

Okay after some investigation, it seems like the wget command was not running because the package tried to run it under sudo which was not installed. I modified the package to remove sudo and run wget on its own (and also add --timeout=3 --tries=1 to prevent wget from retrying infinitely since the URL was no longer valid), and once I did so, the socket appeared in the strace output and the results json file.


[Arbimon Legacy] Table templates, remove uri column

We can remove uri column since it is a combination from other columns

template_id
project_id
uri

160
1200
project_1200/templates/160.png

uri is a combination of template_id and project_id
Expect

Get project_id and template_id then combine to uri
Replace the usage of current uri into above string

the size of the table is 12.39 MB. it is not worth cleansing at the moment.


clone event when add new event

when add new event, clone it will keep the event is unique in event list.

Thanks for your PR :) what does this change aim to do?

In current version, after add an event,  I can not add new event by click "發佈".
I debug the code, the added two events is one object, so I change the code to clone the event when add to events array, then it works.
I don't know what cause the problem, maybe it's behaviour of vue, right?


[C#] Enforce the property setter for non-nullable properties

For both nullable and non-nullable properties, bond simply generates the default getter and setter, we'd prefer to add the null validation for the setter of non-null properties. For example,
struct Foo
{
    0: string ID;
}

it generates code like below, this allows setting the ID to null but the serialization will fail later since the ID is not defined as nullable<string>.
public partial class Foo
{
	[global::Bond.Id(0)]
	public string ID{ get; set; }
}

We prefer a result like below. Since we are using bond over GRPC and the serialization failures are out of the scope of the service implementation, it's hard to catch that error and it's not possible to correlate the error with requests. Generated code like below allows us to catch the failure earlier when we return the response.
public partial class Foo
{
	private string _ID;
	[global::Bond.Id(0), global::Bond.Type(typeof(global::Bond.Tag.nullable<string>))]
	public string ID
	{
		get => _ID;
		set
		{
			 if (value == null)
			 {
				 throw new ArgumentNullException("xxx");
			 }
			 _ID = value;
		}
	}
}

Using C# 8.0's non-nullable reference types would be more in the spirit of C# Bond. They would only be analyzed at compilation time. I believe they can be added in a way that is backward compatible all the way back to .NET 4.5: they're just ignored by compilers that don't understand them.
Explicit checking could be added to codegen behind a switch. However, any codegen switch like this needs to be carefully considered, as it doubles the test matrix. Right now, my inclination would be only to add the appropriate annotations for non-nullable reference types, since they can be added--I believe--unconditionally.


support for dyld shared cache

See: http://iphonedevwiki.net/index.php/Dyld_shared_cache for more info.

If you need to get copies of a dyld_shared_cache_ file then you can follow the steps here (http://newosxbook.com/articles/OTA.html) to extract one for yourself from one of the updates here (https://www.theiphonewiki.com/wiki/OTA_Updates)
Note that the files taken from actual phones are a) encrypted (I believe?) and b) have some form of ASLR pre-applied to them.

Blocking on #133

Apple OSS'ed their latest version of dyld, plus you could probably look at how the Ghidra loader works. https://github.com/apple-oss-distributions/dyld

Thanks -- we've got some other references for this too I thought I posted on this issue but it must have been a different one. I did at least tag this for 3.3 which is when we expect to be working on it again.

https://github.com/cxnder/bn-dyldsharedcache
here you go

Resolved in dev builds >= 4.2.6279
We've shipped a preview 'alpha version' of our SharedCache processing plugin which you can start to work with now 🎉
It currently has first class support for iOS 11-17, partial support for iOS 18 (missing objc selector optimizations)
It has partial support for macOS x86_64 and arm64e caches as well.
It should be usable for RE in all cases.
Support for other arches/formats, misc features, and bugs (which will exist) will be tracked in separate issues, and we look forward to feedback as we continue working on this.


WebApp not working on ARM / M1 pro CPU

I tried to run all services in a Kubernetes cluster on my Macbook with an m1 pro chip. I built all images locally, all services start up except the webapp service.
The pod is showing the following error:
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly '/Pitstop.WebApp.dll'. The system cannot find the file specified.
File name: '/Pitstop.WebApp.dll'

There is a file with that exact name in the root directory of the container.
Running that file with dotnet after i exec into the container throws the same error.
The strange thing is that if i run dotnet publish -c Release -o out on my system (Not in a container) and then run the dll on my system the webapp will work as expected. So it's specifically not working in Docker it seems.

I have created a PR that seems to fix the issues I was having.
https://github.com/EdwinVW/pitstop/pull/120

Fixed by PR #120.
Thanks @mve!


Add redirect param to showError and createError

Describe the feature
I'm working on the project which uses i18n and facing an issue with redirection - unable to redirect user with chosen locale when he/she catches a response error from API
As it says in docs, I can only use statusCode to define redirection path
It would great to define a path where user should be redirected
Additional information

[ ] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

+1


Maya: Fix unique_namespace when in an namespace that is empty

Brief description
This is a moved implementation of https://github.com/pypeclub/avalon-core/pull/412
Testing notes:

See the tests in https://github.com/pypeclub/avalon-core/pull/412 and run those
Load some assets, make sure it works and namespaces come in fine

Thanks @m-u-r-p-h-y - even better would be the full set of tests in the comment below it. 🥇


NIFI-12688 Upgrade mysql-connector-j to 8.3.0

Summary
NIFI-12688
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

https://dev.mysql.com/doc/relnotes/connector-j/en/news-8-3-0.html


Doc Feedback: endpiont --> endpoint

Location : https://ei.docs.wso2.com/en/7.0.0/micro-integrator/references/synapse-properties/inbound-endpoints/event-based-inbound-endpoints/rabbitmq-inbound-endpoint-properties/
"Optional Properties"
The following optional properties can be configured when [creating an RabbitMQ inbound endpiont]
endpiont --> endpoint

This is fixed in MI docs
https://mi.docs.wso2.com/en/latest/reference/synapse-properties/inbound-endpoints/event-based-inbound-endpoints/rabbitmq-inbound-endpoint-properties/


Add filter box

Add a filter box to the top of the "Lodash Replacements" page, to make it easier to filter through all of the content.
I'm thinking that it would be more useful if it only searches through function names, not descriptions. Users can always use ctrl-f to search through all page content.

Resolved in https://github.com/theScottyJam/snap.js/issues/3


Remove deprecated restic old config schema

This issue is to remove old restic top level config and use nodeagent only. This will also involve removal of restic logs in the tests and other places.
Originally posted by @mateusoliveira43 in https://github.com/openshift/oadp-operator/pull/1174#discussion_r1347374829

not stale

/lifecycle frozen

As discussed, we will only remove fields from our APIs, when those APIs version update
For cases like restic, where the field is not used anymore, we left them present in YAML, but error out if user tries to use them


hxdiscord does not work on windows.

Issues:

hxdiscord refuse to work under windows

Troubleshoot:

Switching to the git version
Copied an example from README.MD
Re-Installing hxdiscord

Descriptions:

When I run the bot, It would gave me an error about "Invalid field access : stop" and the terminal would hang until I force quit neko. Seems to only occurred on Windows, As It worked fine under linux. I already have all intents enable on my bot.

Operating System: Windows 11 23H3 Build 22631.4169
HAXE Version: 4.3.6

it's a bug with Neko, and plus Neko has been dead for a long time, idk why you would still be using it

✅ Neko (RECOMMENDED)

Just confirmed this, The bug only occurred on Windows.