Test embedded icons optimization with simple-icons SVGO config

Prevents https://github.com/simple-icons/simple-icons-website/pull/112#pullrequestreview-794781139

SVGO simple-icons repository configuration is downloaded using a CLI program that I've created: sdown. This package only contains a CLI utility to download a file in one line of code (678 bits compressed, including the README). I've created it because I've not found anything like it, a tiny CLI utlity to download a file without dependencies.
pug-lexer is a dependency of @prettier/plugin-pug which I'm including in #138, so this dependency is not really new.
svgo is a dependency of cssnano, which is a dependency of css-minimizer-webpack-plugin, so this neither is a new dependency.

Note that this download in postinstall sets a precedent for simple-icons repositories integration. For example, we can use this approach to download the scripts/utils.js of the main repository if we need it, so there is no need to create a new NPM package for this.

the idea is to have a tool to automatically optimize the icons used in the website?
If that's the case, I don't think there are enough icons for this to be really necessary. I will leave this review to @ericcornelissen or @sachinraja

Why is not really necessary? I don't see any objective reason behind your opinions.

I don't think there are enough icons for this to be really necessary.

If so, how much icons are needed to be this really necessary?

Why is not really necessary? I don't see any objective reason behind your opinions.

I don't think there are enough icons for this to be really necessary.

If so, how much icons are needed to be this really necessary?

the website has a handful of icons. I don't think we need to complicate it anymore just to optimize so few icons.
If the website had an undeterminate number of icons bound to grow (like the library) then sure, this would be necessary.
But since each icon needs to be added manually, and they are added quite sparingly (I think I have added the most in the last year, and I've added 6 or 7 at most) then I don't think an automated system for optimizing them is worth the maintenance complexity added.

My foremost priority with the website (besides closing all pending issues) is to simplify the code that needs to be maintained to the extreme.
The only reasons I'm not changing large chunks of code for the corresponding libraries is because @ericcornelissen is adamantly against it. The least things we introduce to the website, the better.

The only reasons I'm not changing large chunks of code for the corresponding libraries is because @ericcornelissen is adamantly against it.

As I said before, I'm not. If you want to do that, go ahead. I just won't review it.

The only reasons I'm not changing large chunks of code for the corresponding libraries is because @ericcornelissen is adamantly against it.

As I said before, I'm not. If you want to do that, go ahead. I just won't review it.
That said, I don't see how optimizing some SVGs is necessarily complicated. Plus, it has nothing to do with how the website works, just how it's build.

It's code. Everything is code that needs maintenance, including webpack configs, configuration files, everything.
The least, the better. Better to maintain, better to onboard other people, better to migrate the website when the time comes.
It's not that this change is extremely complex or something, my rationale is that what it tries to accomplish is not really something critical, it's just a "nice to have". And a nice to have for this, I wouldn't add it.
Having said all that, I'm not against it, I would just strongly prefer not to have it in there. But if @sachinraja or @ericcornelissen reviews it, then by all means merge it. It's not harmful.

As for adding libraries, we already discussed this, I told you that the pending features will keep the website more or less as is for the next year. That's the plan.
After that, who knows what will happen, but for the time being, addressing the issues is the most relevant thing, and for that your reviews are important.

The least, the better.

That's your philosophy, but I haven't heard an opinion like that so far on simple-icons. I like excelence in open source contributions, this is not a company so nor are we due to estimated development times. For me, this work has more to do with research, to learn how to solve problems and define reusable solutions, that's why I pay a lot of attention to the details, and I won't stop at it. If simple-icons converts itself in a rat race, I would leave.
Please, if you want to introduce another philosophy, at least let it be consensual.

The least, the better.

That's your philosophy, but I haven't heard an opinion like that so far on simple-icons. I like excelence in open source contributions, this is not a company so nor are we due to estimated development times. For me, this work has more to do with research, to learn how to solve problems and define reusable solutions, that's why I pay a lot of attention to the details, and I won't stop at it. If simple-icons converts itself in a rats race, I would leave.

I don't disagree, but my focus is on having a useful product up and running and making sure that it is maintainable beyond the involvement of present company. For that simplicity is key, and for simplicity the least things are added, the better.
I have made my opinion clear. Rely on @sachinraja and @ericcornelissen for reviews on this. Like I said, I'm not against it since it is not harmful, I just very much prefer if it wasn't in. It's a preference, not a rejection.

Please, if you want to introduce another philosophy, at least let it be consensual.

I don't want to introduce any philosophy. Keep at it as you have always done, I'll voice my opinion when necessary, and you do what you think it's best. That should be sufficient.

That's the plan.

Maybe I'm missing some discussion, could you give me some previously discussed context?

@ericcornelissen and I had discussed a few times in other threads about the usefulness of libraries and some things that can be done with much less code / work in the website. As a compromise to keep him engaged for the longest time in reviews as such (which is highly valuable for me), I'm refraining from introducing any libraries (with the exception of one for fuzzy search) in the website, as well as waiting for any big refactorings or website rewriting. The goal is therefore to keep the website with the current architecture, technology and design as it is until such time as it is stable, functionality wise, which is when all the issues are solved or 1 more year, whichever takes longer.
After that, if I'm here still, I will revisit the idea of refactoring the website and / or introducing libraries to it.
So the plan is to maintain the current website and solve all the extant issues that are of any relevance, and then, once that done, we can see if the website can or should be remade. But that's work for 2022-23, not for now. For now the website stays as is and we just need to add all the pending features already identified.

It seems that this pull is not very popular, I'm not sure really why, only @jorgeamadosoria have explained their opinion, and thanks for this. If someone wants to reopen this, feel free, but I'll not review things like ugly paths in embedded icons like https://github.com/simple-icons/simple-icons-website/pull/112#pullrequestreview-794781139 optimizing manually anymore. It seems to me that SVG optimizations are important and should be unified through the repositories as we maintain a project of SVG icons 🤔

I see no upside to pulling it in like this (and only potential downside if e.g. if it doesn't work for someone).

The problem of synchronization of files still continues, I've done my best to solve it. Nobody has proposed other solution apart from make another NPM package for simple-icons utilities, so this propably would stop third party extensions development (see this repeated and probably outdated function as an example). We can't add to main repo utilities nothing and we don't want downloads in postinstall, what's the alternative? Don't make it because couldn't work for someone? If it doesn't work, is it fixed, or can't it? What an empty argument!

There is no reason for this discussion to get this heated. We're all trying to achieve the same thing: a fast and well-functioning website. I would rather we continue to discuss it than abruptly close PRs. I agree with the principles of this PR and I am ready to review to continue discussion it.

Feel free to reopen it. I'm not heated at all, it is just that I avoid arguing when no argument is proposed. Sorry, but I feel that "the less, the better" or "and only potential downside if e.g. if it doesn't work for someone" are not arguments, because for the same reason why do anything else? Simple Icons is already working, no need to make any new improvement, review bug fixes and that's all.

The problem of synchronization of files still continues, I've done my best to solve it.

What is this referring to @mondeja ? Is this something that must be tied to this PR, or something that could be done separately?

 You don't have to fix them as you have done in the past (and thanks for doing that) but a review would be helpful if you come across them. The first step in fixing the error is noticing it.

Feel free to reopen it. I'm not heated at all, it is just that I avoid arguing when no argument is proposed. Sorry, but I feel that "the less, the better" or "and only potential downside if e.g. if it doesn't work for someone" are not arguments, because for the same reason why do anything else? Simple Icons is already working, no need to make any new improvement, review bug fixes and that's all.

"less is better" does not preclude adding new features. The idea is to keep adding things only when they are critical to the maintenance of the infrastructure, or when they amount to features that will be competitive / are requested by users.
For example, there was a request for initializing letters to the left of the icon list. Very pretty, but necessary? Not really.
There was a different request for more precise search results. No UI impact, but definitely a feature improvement.
Color search: Not really necessary, but since it's in and can't be taken out for the time being, might as well rewrite it to be more efficient.
See, in this cases we have worked on a request that was necessary and added code to the website; a request that was visually nice but contributed nothing to the functionality of the website; and a request that I personally disagree with it even existing but that putting that aside could use some improvement.
Less is better does not mean to stop working. It means to be very critical with the things we need rather than the things we want. Every line of code that can be taken out is one less line of code a new maintainer needs to learn and figure out. In the long term, adding only what we need and constantly refactor away things we don't will result in a product that contains exactly what's necessary, and nothing else. That's the best product possible, the one that only has what it needs without unnecessary additions.

Having said all that, I do not want me to be the cause of people checking out of efforts. We are too few for what this project needs already. I'm going to merge this so we can move on to more productive things.

The problem of synchronization of files still continues, I've done my best to solve it.

What is this referring to @mondeja ? Is this something that must be tied to this PR, or something that could be done separately?

We have a lot of duplicated code between projects. For example, simple-icons bump version scripts in simple-icons-website and simple-icons-pdf (see that pull where @adamrusted writes "Copying a load of code from the website repo"). I've an encoding function in simple-icons-drawio that is a duplicate from simple-icons/scripts/util.js, which has been outdated with a recent PR in main repo. If someones want to reuse, for example, the color sorting algorithm in another project, must copy and paste and will not receive updates, when has much more sense to put that in a folder in the main simple-icons repository (for example simple-icons/utils/color-sorting.js) and get upstream changes with whatever strategy like the one I'm implementing here. In the practice this discourage any developer any attempt to make new development around simple-icons. And this is just the beggining. For example, we are defining a standard for all our icons in the main repo through SVGLint, but .svglintrc.js can't be used nowhere else. And I'm sure that other extensions have related problems as well. But seems that no one cares.

Every line of code that can be taken out is one less line of code a new maintainer needs to learn and figure out.

I don't think so. A rational code structure along with other good practices avoid that. When I see in a project a file called search.js inside a folder named tests I don't need to read the whole file to know that functions stored there are tests for some search functionality. And I don't even have to open the file, whether it contains 20 or 20000 lines. When I read the whole file is to review that the search functionality is properly tested, but I ussually don't because I trust the previous reviewer has done their job. When I need some reusable pattern, I use a code editor search utility, I don't read whole files. For example, I've studied the code of this repository in one hour, and I don't know what does the jest function runAllTimers nor why it's there, but I don't care for now, I suppose that is doing something needed by copy functionality tests. And I think it is the only consistent way to proceed in the maintenance and development of projects that I have not written myself, at least if I want to maintain multiple projects. Makes this project unmaintainable for me that as a maintainer if I don't know what that function does? No because, when something related to it emerges, I will study it.
Explained these points, I know that we must prioritize, for that same reason I have not opened any pull that creates a new functionality. But the main point here is that nobody is taking into account the real integration problems in the simple-icons ecosystem, I'm ultimately encountering with slogans like "Less is better" when less could be worse if there are no structure nor desire to face the problems. And if you think that I'm being polemic here, it could be, but at least it cannot be criticized that I am not explaining why I have this opinion.

It means to be very critical with the things we need rather than the things we want.

And what we need? As I said in a previous comment, we don't need nothing if we follow your opinion. The website is usable, the main repo icons structure is well defined and linted, we need a PDF repo? No. We need a, for example, a Rust crate with simple-icons macros? We need what we want to add. If someone comes tomorrow with a perfect pull request, I won't say he, "hey, this is not really needed, maybe in the future". It is not what we need because nobody will be here to do nothing, much less to review it. At least for me, if someone needs it, the proposal is rational and I want to do it, it will be done.

The problem of synchronization of files still continues, I've done my best to solve it.

What is this referring to @mondeja ? Is this something that must be tied to this PR, or something that could be done separately?

We have a lot of duplicated code between projects. For example, simple-icons bump version scripts in simple-icons-website and simple-icons-pdf (see that pull where @adamrusted writes "Copying a load of code from the website repo"). I've an encoding function in simple-icons-drawio that is a duplicate from simple-icons/scripts/utils.js, which has been outdated with a recent PR in main repo. If someones want to reuse, for example, the color sorting algorithm in another project, must copy and paste and will not receive updates, when has much more sense to put that in a folder in the main simple-icons repository (for example simple-icons/utils/color-sorting.js) and get upstream changes with whatever strategy like the one I'm implementing here. In the practice this discourage any developer any attempt to make new development around simple-icons. And this is just the beggining. For example, we are defining a standard for all our icons in the main repo through SVGLint, but .svglintrc.js can't be used nowhere else. And I'm sure that other extensions have related problems as well. But seems that no one cares.

Please don't say that. I care. Abstracting code to a single dependency to avoid duplication is perfectly aligned with the less is better principle.
I just wasn't aware it was such a big problem, and I don't have command of all related technologies to help as much as I would like.
More importantly, I was under the impression that we were trying not to add a lot of things to the main repo? Don't get me wrong, I'm all for moving common code there, but I fear I'm not in the majority here.

Every line of code that can be taken out is one less line of code a new maintainer needs to learn and figure out.

I don't think so. A rational code structure along with other good practices avoid that. When I see in a project a file called search.js inside a folder named tests I don't need to read the whole file to know that functions stored there are tests for some search functionality. And I don't even have to open the file, whether it contains 20 or 20000 lines. When I read the whole file is to review that the search functionality is properly tested, but I ussually don't because I trust the previous reviewer has done their job. When I need some reusable pattern, I use a code editor search utility, I don't read whole files. For example, I've studied the code of this repository in one hour, and I don't know what does the jest function runAllTimers nor why it's there, but I don't care for now, I suppose that is doing something needed by copy functionality tests. And I think it is the only consistent way to proceed in the maintenance and development of projects that I have not written myself, at least if I want to maintain multiple projects. Makes this project unmaintainable for me that as a maintainer if I don't know what that function does? No because, when something related to it emerges, I will study it.

Notice the large amount of I statements there. Not everyone has your skill or approach. And the idea is to make the entry barrier lower. Sure, you don't need to review the 20k lines of code for a search file, but what that means is that when you have a ticket that needs to add a feature, you will never be completely sure if that case (or a similar one) is covered in those 20k lines of code. If you only had 2k, looking at that code and finding patterns is way easier and faster. Also, it makes refactorings easier, onboarding faster, it encourages people to contribute rather than discourage them from fear of breaking things that exist, etc.
There are multiple advantages to shorter code (within reason, of course).
Sometimes verbose code is more readable, that is true. Clever coding does not help. But I'm not trying to make the code clever, I'm trying to reduce the duplication and amount of code that deals with things that are not really critical.
This project, for the size it has, contains too many technologies (not the website, I mean across the different repos). If I find a way to simplify things and delete elements of infrastructure without affecting the deliverables, why wouldn't I do that?
For example, I still think that generating the PDFs on the fly is better than the current approach. It's not like it's so heavily used, and even if it is, it's generated on the client so that's his problem.
What that would have done is exchange some more JS code on an existing project (website) for a whole github repo and accompanying hooks, orchestration and tokens. You can't tell me that that is not simplifying the codebase and reducing the entry barrier for future collaborators.
Just because things are done one way now does not mean that that's the way they should be done. Trusting the way the code works is necessary at the beginning to get to know it, but at some point you need to start question the code line by line in order to improve it, in a process that should never end.
And less code helps a lot with that task.

Explained these points, I know that we must prioritize, for that same reason I have not opened any pull that creates a new functionality. But the main point here is that nobody is taking into account the real integration problems in the simple-icons ecosystem, I'm ultimately encountering with slogans like "Less is better" when less could be worse if there are no structure nor desire to face the problems. And if you think that I'm being polemic here, it could be, but at least it cannot be criticized that I am not explaining why I have this opinion.

Being polemic is fine. Solutions come from discussion. The project does have integration problems. I've tried to attack those with things like my aforementioned PDF generation PR. It didn't went through, but that reveals that we do care. go look at that PR to see that people do care, we may just have different priorities.
Also, less is better is not a slogan, is the principle I, and I alone, I'm using for the website and nothing else. I do not apply this elsewhere, and no one else does. Frustration is understandable but shouldn't be generalized.
Finally, it's fine to add new functionalities, but it would be better to open an issue first so it can be discussed rather than creating a PR and confronting us with a fait accompli. Less is better is not in opposition to that: I myself plan on adding PNGs as soon as the universal download type and the compact layout are done.
Don't think that reducing the amount of existing code means that no features can be added. That's not what it means.

It means to be very critical with the things we need rather than the things we want.

And what we need? As I said in a previous comment, we don't need nothing if we follow your opinion. The website is usable, the main repo icons structure is well defined and linted, we need a PDF repo? No. We need a, for example, a Rust crate with simple-icons macros? We need what we want to add. If someone comes tomorrow with a perfect pull request, I won't say he, "hey, this is not really needed, maybe in the future". It is not what we need because nobody will be here to do nothing, much less to review it. At least for me, if someone needs it, the proposal is rational and I want to do it, it will be done.

I understand your point. However, the problem is the starting point: you start from a position that the website as is can be used therefore needs no improvement according to my philosophy. Not quite. Since there are requests, then the site is perfectible and work must be done to do so.
However, perfectible does not mean that it should add everything. For example, There are two issues opened regarding non-JS users. Is that needed? I don't know. I don't think so, and I wouldn't be working on that because the people affected are imo very unlikely to be in the user demographics for this library. But, I could be wrong. Maybe if we had some analytics we could determine that.
So if tomorrow someone comes and makes an issue that says "add analytics" and says "we need analytics on the user behavior on the site to determine which features are more popular" that's something we unequivocally need.
If someone opens a PR that says "added a multicolored letter index to the left of the icon list" that's not really needed. The website gains nothing from it. You could say "but it doesn't conflict with the mission of the website, and since it can be integrated aesthetically in the Ui and I would like to see it, then I want to have it" and you will be right, but that's  what you want to have, not what you need to have.
Needing something to improve usability, reach, performance, maintainability or functionality is one thing. Wanting things because they would look good, add new features not requested by users or add libraries or technologies is another. A need is not a want, even though at times they can be both at ones (like the Compact Layout, which we need and I very much want).

My opinion has been made clear, this PR is merged, and in the end this is an open project without hierarchies. My goal remains unchanged: as less code as possible in the website, and closing all existing issues one way or the other.
I will recommend you to continue work on the file sync issue you've identified. I care, @sachinraja cares, I think @dirien  cares, and @runxel cares. Probably everyone else also cares, and it is a pressing issue. I wish I had your skills to help, but I can, so I have to stick to the website for the time being :(
If you have new features for the website don't be discouraged. Open issues and let's discuss them one by one. I'm probably against everything new to be added, but that's not a given and besides, I'm not the owner of the website or anything, I will always do what the majority chooses.
Let's get back to work! 👍

The problem of synchronization of files still continues, I've done my best to solve it.

What is this referring to @mondeja ? Is this something that must be tied to this PR, or something that could be done separately?

We have a lot of duplicated code between projects. For example, simple-icons bump version scripts in simple-icons-website and simple-icons-pdf (see that pull where @adamrusted writes "Copying a load of code from the website repo"). I've an encoding function in simple-icons-drawio that is a duplicate from simple-icons/scripts/utils.js, which has been outdated with a recent PR in main repo. If someones want to reuse, for example, the color sorting algorithm in another project, must copy and paste and will not receive updates, when has much more sense to put that in a folder in the main simple-icons repository (for example simple-icons/utils/color-sorting.js) and get upstream changes with whatever strategy like the one I'm implementing here. In the practice this discourage any developer any attempt to make new development around simple-icons. And this is just the beggining. For example, we are defining a standard for all our icons in the main repo through SVGLint, but .svglintrc.js can't be used nowhere else. And I'm sure that other extensions have related problems as well. But seems that no one cares.

Please don't say that. I care. Abstracting code to a single dependency to avoid duplication is perfectly aligned with the less is better principle. I just wasn't aware it was such a big problem, and I don't have command of all related technologies to help as much as I would like.
More importantly, I was under the impression that we were trying not to add a lot of things to the main repo? Don't get me wrong, I'm all for moving common code there, but I fear I'm not in the majority here.

Every line of code that can be taken out is one less line of code a new maintainer needs to learn and figure out.

I don't think so. A rational code structure along with other good practices avoid that. When I see in a project a file called search.js inside a folder named tests I don't need to read the whole file to know that functions stored there are tests for some search functionality. And I don't even have to open the file, whether it contains 20 or 20000 lines. When I read the whole file is to review that the search functionality is properly tested, but I ussually don't because I trust the previous reviewer has done their job. When I need some reusable pattern, I use a code editor search utility, I don't read whole files. For example, I've studied the code of this repository in one hour, and I don't know what does the jest function runAllTimers nor why it's there, but I don't care for now, I suppose that is doing something needed by copy functionality tests. And I think it is the only consistent way to proceed in the maintenance and development of projects that I have not written myself, at least if I want to maintain multiple projects. Makes this project unmaintainable for me that as a maintainer if I don't know what that function does? No because, when something related to it emerges, I will study it.

Notice the large amount of I statements there. Not everyone has your skill or approach. And the idea is to make the entry barrier lower. Sure, you don't need to review the 20k lines of code for a search file, but what that means is that when you have a ticket that needs to add a feature, you will never be completely sure if that case (or a similar one) is covered in those 20k lines of code. If you only had 2k, looking at that code and finding patterns is way easier and faster. Also, it makes refactorings easier, onboarding faster, it encourages people to contribute rather than discourage them from fear of breaking things that exist, etc. There are multiple advantages to shorter code (within reason, of course). Sometimes verbose code is more readable, that is true. Clever coding does not help. But I'm not trying to make the code clever, I'm trying to reduce the duplication and amount of code that deals with things that are not really critical. This project, for the size it has, contains too many technologies (not the website, I mean across the different repos). If I find a way to simplify things and delete elements of infrastructure without affecting the deliverables, why wouldn't I do that? For example, I still think that generating the PDFs on the fly is better than the current approach. It's not like it's so heavily used, and even if it is, it's generated on the client so that's his problem. What that would have done is exchange some more JS code on an existing project (website) for a whole github repo and accompanying hooks, orchestration and tokens. You can't tell me that that is not simplifying the codebase and reducing the entry barrier for future collaborators. Just because things are done one way now does not mean that that's the way they should be done. Trusting the way the code works is necessary at the beginning to get to know it, but at some point you need to start question the code line by line in order to improve it, in a process that should never end. And less code helps a lot with that task.

Explained these points, I know that we must prioritize, for that same reason I have not opened any pull that creates a new functionality. But the main point here is that nobody is taking into account the real integration problems in the simple-icons ecosystem, I'm ultimately encountering with slogans like "Less is better" when less could be worse if there are no structure nor desire to face the problems. And if you think that I'm being polemic here, it could be, but at least it cannot be criticized that I am not explaining why I have this opinion.

Being polemic is fine. Solutions come from discussion. The project does have integration problems. I've tried to attack those with things like my aforementioned PDF generation PR. It didn't went through, but that reveals that we do care. go look at that PR to see that people do care, we may just have different priorities.
Also, less is better is not a slogan, is the principle I, and I alone, I'm using for the website and nothing else. I do not apply this elsewhere, and no one else does. Frustration is understandable but shouldn't be generalized. Finally, it's fine to add new functionalities, but it would be better to open an issue first so it can be discussed rather than creating a PR and confronting us with a fait accompli. Less is better is not in opposition to that: I myself plan on adding PNGs as soon as the universal download type and the compact layout are done. Don't think that reducing the amount of existing code means that no features can be added. That's not what it means.

It means to be very critical with the things we need rather than the things we want.

And what we need? As I said in a previous comment, we don't need nothing if we follow your opinion. The website is usable, the main repo icons structure is well defined and linted, we need a PDF repo? No. We need a, for example, a Rust crate with simple-icons macros? We need what we want to add. If someone comes tomorrow with a perfect pull request, I won't say he, "hey, this is not really needed, maybe in the future". It is not what we need because nobody will be here to do nothing, much less to review it. At least for me, if someone needs it, the proposal is rational and I want to do it, it will be done.

I understand your point. However, the problem is the starting point: you start from a position that the website as is can be used therefore needs no improvement according to my philosophy. Not quite. Since there are requests, then the site is perfectible and work must be done to do so. However, perfectible does not mean that it should add everything. For example, There are two issues opened regarding non-JS users. Is that needed? I don't know. I don't think so, and I wouldn't be working on that because the people affected are imo very unlikely to be in the user demographics for this library. But, I could be wrong. Maybe if we had some analytics we could determine that. So if tomorrow someone comes and makes an issue that says "add analytics" and says "we need analytics on the user behavior on the site to determine which features are more popular" that's something we unequivocally need.
If someone opens a PR that says "added a multicolored letter index to the left of the icon list" that's not really needed. The website gains nothing from it. You could say "but it doesn't conflict with the mission of the website, and since it can be integrated aesthetically in the Ui and I would like to see it, then I want to have it" and you will be right, but that's what you want to have, not what you need to have.
Needing something to improve usability, reach, performance, maintainability or functionality is one thing. Wanting things because they would look good, add new features not requested by users or add libraries or technologies is another. A need is not a want, even though at times they can be both at ones (like the Compact Layout, which we need and I very much want).
My opinion has been made clear, this PR is merged, and in the end this is an open project without hierarchies. My goal remains unchanged: as less code as possible in the website, and closing all existing issues one way or the other.
I will recommend you to continue work on the file sync issue you've identified. I care, @sachinraja cares, I think @dirien cares, and @runxel cares (going by the PDF on the fly discussion on the PDF repo sync problems). Probably everyone else also cares, and it is a pressing issue. I wish I had your skills to help, but I can't, so I have to stick to the website for the time being :(
If you have new features for the website don't be discouraged. Open issues and let's discuss them one by one. I'm probably against everything new to be added, but that's not a given and besides, I'm not the owner of the website or anything, I will always do what the majority chooses.
Let's get back to work! 👍

The problem of synchronization of files still continues, I've done my best to solve it.

What is this referring to @mondeja ? Is this something that must be tied to this PR, or something that could be done separately?

We have a lot of duplicated code between projects. For example, simple-icons bump version scripts in simple-icons-website and simple-icons-pdf (see that pull where @adamrusted writes "Copying a load of code from the website repo"). I've an encoding function in simple-icons-drawio that is a duplicate from simple-icons/scripts/utils.js, which has been outdated with a recent PR in main repo. If someones want to reuse, for example, the color sorting algorithm in another project, must copy and paste and will not receive updates, when has much more sense to put that in a folder in the main simple-icons repository (for example simple-icons/utils/color-sorting.js) and get upstream changes with whatever strategy like the one I'm implementing here. In the practice this discourage any developer any attempt to make new development around simple-icons. And this is just the beggining. For example, we are defining a standard for all our icons in the main repo through SVGLint, but .svglintrc.js can't be used nowhere else. And I'm sure that other extensions have related problems as well. But seems that no one cares.

Please don't say that. I care. Abstracting code to a single dependency to avoid duplication is perfectly aligned with the less is better principle. I just wasn't aware it was such a big problem, and I don't have command of all related technologies to help as much as I would like.
More importantly, I was under the impression that we were trying not to add a lot of things to the main repo? Don't get me wrong, I'm all for moving common code there, but I fear I'm not in the majority here.

Every line of code that can be taken out is one less line of code a new maintainer needs to learn and figure out.

I don't think so. A rational code structure along with other good practices avoid that. When I see in a project a file called search.js inside a folder named tests I don't need to read the whole file to know that functions stored there are tests for some search functionality. And I don't even have to open the file, whether it contains 20 or 20000 lines. When I read the whole file is to review that the search functionality is properly tested, but I ussually don't because I trust the previous reviewer has done their job. When I need some reusable pattern, I use a code editor search utility, I don't read whole files. For example, I've studied the code of this repository in one hour, and I don't know what does the jest function runAllTimers nor why it's there, but I don't care for now, I suppose that is doing something needed by copy functionality tests. And I think it is the only consistent way to proceed in the maintenance and development of projects that I have not written myself, at least if I want to maintain multiple projects. Makes this project unmaintainable for me that as a maintainer if I don't know what that function does? No because, when something related to it emerges, I will study it.

Notice the large amount of I statements there. Not everyone has your skill or approach. And the idea is to make the entry barrier lower. Sure, you don't need to review the 20k lines of code for a search file, but what that means is that when you have a ticket that needs to add a feature, you will never be completely sure if that case (or a similar one) is covered in those 20k lines of code. If you only had 2k, looking at that code and finding patterns is way easier and faster. Also, it makes refactorings easier, onboarding faster, it encourages people to contribute rather than discourage them from fear of breaking things that exist, etc. There are multiple advantages to shorter code (within reason, of course). Sometimes verbose code is more readable, that is true. Clever coding does not help. But I'm not trying to make the code clever, I'm trying to reduce the duplication and amount of code that deals with things that are not really critical. This project, for the size it has, contains too many technologies (not the website, I mean across the different repos). If I find a way to simplify things and delete elements of infrastructure without affecting the deliverables, why wouldn't I do that? For example, I still think that generating the PDFs on the fly is better than the current approach. It's not like it's so heavily used, and even if it is, it's generated on the client so that's his problem. What that would have done is exchange some more JS code on an existing project (website) for a whole github repo and accompanying hooks, orchestration and tokens. You can't tell me that that is not simplifying the codebase and reducing the entry barrier for future collaborators. Just because things are done one way now does not mean that that's the way they should be done. Trusting the way the code works is necessary at the beginning to get to know it, but at some point you need to start question the code line by line in order to improve it, in a process that should never end. And less code helps a lot with that task.

Explained these points, I know that we must prioritize, for that same reason I have not opened any pull that creates a new functionality. But the main point here is that nobody is taking into account the real integration problems in the simple-icons ecosystem, I'm ultimately encountering with slogans like "Less is better" when less could be worse if there are no structure nor desire to face the problems. And if you think that I'm being polemic here, it could be, but at least it cannot be criticized that I am not explaining why I have this opinion.

Being polemic is fine. Solutions come from discussion. The project does have integration problems. I've tried to attack those with things like my aforementioned PDF generation PR. It didn't went through, but that reveals that we do care. go look at that PR to see that people do care, we may just have different priorities.
Also, less is better is not a slogan, is the principle I, and I alone, I'm using for the website and nothing else. I do not apply this elsewhere, and no one else does. Frustration is understandable but shouldn't be generalized. Finally, it's fine to add new functionalities, but it would be better to open an issue first so it can be discussed rather than creating a PR and confronting us with a fait accompli. Less is better is not in opposition to that: I myself plan on adding PNGs as soon as the universal download type and the compact layout are done. Don't think that reducing the amount of existing code means that no features can be added. That's not what it means.

It means to be very critical with the things we need rather than the things we want.

And what we need? As I said in a previous comment, we don't need nothing if we follow your opinion. The website is usable, the main repo icons structure is well defined and linted, we need a PDF repo? No. We need a, for example, a Rust crate with simple-icons macros? We need what we want to add. If someone comes tomorrow with a perfect pull request, I won't say he, "hey, this is not really needed, maybe in the future". It is not what we need because nobody will be here to do nothing, much less to review it. At least for me, if someone needs it, the proposal is rational and I want to do it, it will be done.

I understand your point. However, the problem is the starting point: you start from a position that the website as is can be used therefore needs no improvement according to my philosophy. Not quite. Since there are requests, then the site is perfectible and work must be done to do so. However, perfectible does not mean that it should add everything. For example, There are two issues opened regarding non-JS users. Is that needed? I don't know. I don't think so, and I wouldn't be working on that because the people affected are imo very unlikely to be in the user demographics for this library. But, I could be wrong. Maybe if we had some analytics we could determine that. So if tomorrow someone comes and makes an issue that says "add analytics" and says "we need analytics on the user behavior on the site to determine which features are more popular" that's something we unequivocally need.
If someone opens a PR that says "added a multicolored letter index to the left of the icon list" that's not really needed. The website gains nothing from it. You could say "but it doesn't conflict with the mission of the website, and since it can be integrated aesthetically in the Ui and I would like to see it, then I want to have it" and you will be right, but that's what you want to have, not what you need to have.
Needing something to improve usability, reach, performance, maintainability or functionality is one thing. Wanting things because they would look good, add new features not requested by users or add libraries or technologies is another. A need is not a want, even though at times they can be both at ones (like the Compact Layout, which we need and I very much want).
My opinion has been made clear, this PR is merged, and in the end this is an open project without hierarchies. My goal remains unchanged: as less code as possible in the website, and closing all existing issues one way or the other.
I will recommend you to continue work on the file sync issue you've identified. I care, @sachinraja cares, I think @dirien cares, and @runxel cares (going by the PDF on the fly discussion on the PDF repo sync problems). Probably everyone else also cares, and it is a pressing issue. I wish I had your skills to help, but I can't, so I have to stick to the website for the time being :(
If you have new features for the website don't be discouraged. Open issues and let's discuss them one by one. I'm probably against everything new to be added, but that's not a given and besides, I'm not the owner of the website or anything, I will always do what the majority chooses.
Let's get back to work! 👍


Submit Form ( POST ) after confirmation

Hi,
I have a bootstrap form with a submit button as below;
<button type="submit" class="btn btn-primary" name="button_deluser"  > Delete Selected User </button>
When the button is clicked - the form is submitted. I would like a confirmation box (Yes - Delete, No ).
I dont understand how to incorporate jquery-confirm into the button above from the documentation provided.
Any ideas ? Alert - Jquery newbie here.

Example form:

Your jconfirm handler:
$.confirm({
title: 'Confirm!',
content: 'Simple confirm!',
buttons: {
confirm: function () {
$( "#target" ).submit(); <--- Here's the needed code
},
cancel: function () {
$.alert('Canceled!');
},
   }

});
The new code line selects the form and creates a jquery object ("$('#target') and then calls the function "submit()" on this jquery-object.
Please check the jquery docs (https://api.jquery.com/submit/) for further details.

@marvinkueppers  - Many many thanks.
Will try and revert.
Next;
``
EDIT: If you want to use a button-click to send the form, you can do it with:
Your button (give it an id!!):
 Delete Selected User
Needed jquery inside your confirm-function:
$('#submitXY').click();
``
What is the better practice ? How do you do it ?
A. User gets a popup confirm box to cancel/ approve ?
B. Or use the button click to send the form right away ?
Once again many thanks for the input. Its very appreciated.

This is great...
but can not get the form to "close" after the submit
confirm: {
					text: 'Confirm',
					btnClass: 'custom-btn',
					action: function(){
						$("#start_long_ajax_loop").submit();
						$.close(); // not working
					}
				},

https://jquerys.space/questions/prompt-the-user-to-confirm-before-clicking-on-the-submit-button-using-jquery-dialog


Is it possible to do cache concept with queryDSL?

Hi all,Please help me to sort out this. I'm currently working in spring boot application with spring data JPA and to retrieving the results I'm using QueryDSL and I'm trying to apply ehcache concept here.
@CachePut(value = "ticketsearchcache", key = "#result.toString()", condition = "#result != null")
	public Person savePerson(Person p) throws Exception {

		Person test= serviceRequestRepository.save(p);
		return test;
	}

and to retrieve the results I'm using query dsl as well as I'm applying cacheable here.
@Cacheable(value = "ticketsearchcache", key = "#srchCriteriaCtx.toString()")
public List<Person> findByServiceRequestNumberAndDivisionAndDateCreated(SearchCriteriaContext srchCriteriaCtx) throws ParseException {

		QServiceRequest sr = QServiceRequest.serviceRequest;
		queryFactory = new JPAQueryFactory(em);
		BooleanBuilder where = new BooleanBuilder();
		List<Tuple> serReqList = new ArrayList<>();
		OrderSpecifier<Date> specifier = sr.dateCreated.desc();

		serReqList = queryFactory
				.select(sr.serviceRequestNumber, sr.dateCreated, sr.serialNumber, sr.trackingNumber)
				.from(sr).leftJoin(sr.pc, pc).leftJoin(sr.printer, printer).leftJoin(sr.storeClosing, storeClosing).where(where)
				.orderBy(specifier).fetch();

		List<Person > searchResults = new ArrayList<Person >();

		for (Tuple row : serReqList) {
			Person result = new Person ();

			result.setServiceRequestNumber(row.get(0, String.class));
			result.setDateCreated(row.get(1, Date.class));
			result.setSerialNumber(row.get(2, String.class));
			result.setTrackingNumber(row.get(3, String.class));
				searchResults.add(result);

		}

		return searchResults;
	}

When I'm doing this, the cacheput is not at all working and in other cases it throws classcast exception cannot cast to list like this. Any suggestions will be appreciated.

I think you'd be better off taking this to one of the spring forums. I believe they recommend asking on stackoverflow.com first.


Deployment: git clone<EMAIL_ADDRESS>Could not resolve host: username

I'm using the laravel homestead virtual machine (http://laravel.com/docs/homestead), that means Ubuntu 14.04 and git version 1.9.1. "rocketeer deploy" does not work because there is a problem with the cloning of the repo. After some investigation it seems that the following command is issued in the target machine:
git clone --depth 1 -b master<EMAIL_ADDRESS>/home/www/rocketeer/releases/20140712223030

I get the following error:
fatal: unable to access<EMAIL_ADDRESS>Could not resolve host: username

Seems like the username and password are not interpreted as such but seen as part of the domain. This could be an issue not related to rocketeer but I'm not sure where it should be reported otherwise, and anyway perhaps can be useful for rocketeer too :)

what was the answer? What did you do the fix it exactly???
command line example would help.
Thanks

I think he means there was per example a space in his username or password that needed to be %20, otherwise the URL was parsed wrong


Introduce stable branch

I propose that we track problematic extensions (looking at rust-analyzer) and only push these specific extensions to the stable branch when they have been checked after an automatic update.
specified: sha256-ttLGbPikx3khbjRiubNjlkEF5uX/T3NkpdpSCbELEKw=
got:       sha256-VHBxuVz7Dul/yIRnlhep3sKx9qCOOexVjLciBB1c23Y=

Is the problem with rust-analyzer specific to some versions? If I understand correctly, the issue is that we get files for different platforms some times. In that case, this is independent of the version. Even if we test the extension and it works, a user might still get a wrong hash later.
Please correct me if I'm wrong.

https://github.com/nix-community/nix-vscode-extensions/issues/5

What versions are different? Is it random? What do you mean different platforms? I might get a vsix for a different architecture, platform, or system double?


FIX-#5941: TEST: The test test_io.py fails on HDK

What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #5941
[ ] tests added and passing
[ ] module layout described at docs/development/architecture.rst is up-to-date

@YarShev let's merge without waiting for the end of all tests? (HDK tests are passed)


update dapr runtime to use v1.12.0-rc.1

Description
Update dapr runtime to use v1.12.0-rc.3 && dapr cli to use v1.12.0-rc.1 to test & validate the release candidate
Issue reference
https://github.com/dapr/dapr/issues/6899
Checklist

[x] The quickstart code compiles correctly
[x] You've tested new builds of the quickstart if you changed quickstart code

@cicoyle  - We create a release-1.12 branch in this repo. Can you retarget this PR against the new branch, so that we test this independent of master (main) branch.

Shouldn't the redis version also be pinned here?

Shouldn't the redis version also be pinned here?

Maybe, I pinned it to a version I saw in your PR here.

Interesting the bindings tutorial seems to be failing consistently.


The first execution keeps no response, but the follow-up is normal

When I first execute any program, it keeps no return state. It's like the picture below.

But when I cleared the variables and executed the same program again, the output was normal as follow.

It happens not every time, sometimes I reboot computer, the bug disappear, but sometimes it happens again.
Another bug, sometimes I run code, it return aborted execution, only if I open a new console, it could be solve.
However, in my another computer, it doesn't have the bugs mentioned above.
The Spyder version is 4.2.1.
Windows 10.

It seems to have been solved after I run conda update anaconda, BTW

Hey @Aegis1863, thanks for reporting. This looks like an an Anaconda installation issue, so you need to remove and reinstall it again.
Please see our video to learn how to do it.

@ccordoba12 Thank you, I will try it.

I solve this by code conda install anaconda-clean and then anaconda-clean --yes.


Pass through callback handlers to procaptcha

Procaptcha has various callback handlers.
export interface ProcaptchaEvents {
    onError: (error: Error) => void
    onAccountNotFound: (address: string) => void
    onHuman: (output: ProcaptchaOutput) => void
    onExtensionNotFound: () => void
    onExpired: () => void
    onFailed: () => void
}

Currently, none of these callbacks are passed through from procaptcha-bundle. A default callback of onHuman is created that binds to the parent form and an event is dispatched which the user must listen to in order to submit the form manually.
                        // submit the form
                        const procaptchaEvent = new Event('procaptchaSubmit')
                        // Dispatch the event.
                        element.dispatchEvent(procaptchaEvent)

This is incorrect logic which was created in an attempt to get the marketing website live. The data should instead be inserted into the form and the submit logic handled by the containing website.

Ended up having a dependency of #235 for some reason

Need to add a CSS parser to this


Release/0.22.1

release version 0.22.1

:+1:

👍

Current coverage is 81.58%

Merging #58 into master will not change coverage

@@             master        #58   diff @@
==========================================
  Files            11         11
  Lines           885        885
  Methods           0          0
  Messages          0          0
  Branches         21         21
==========================================
  Hits            722        722
  Misses          142        142
  Partials         21         21

Powered by Codecov. Last update 66a2307...7753137


.gitAttributes: Update .gitattributes to allow test .pfx files to be saved as binary type

Pull Request (PR) description
Updates .gitattributes to allow test .pfx files to be saved as binary type
Task list

[X] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #323 into dev will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev    #323   +/-   ##
=====================================
  Coverage   5.82%   5.82%
=====================================
  Files         38      38
  Lines       4448    4448
=====================================
  Hits         259     259
  Misses      4189    4189

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 1fd2670...b5df935. Read the comment docs.


Client error '404 Not Found' for url 'https://api.openai.com/v1/chat/completions'

i get an 404 error
readmeai --api-key "xxxxx" -o readme-ai.md -r  /home/ben/REPO/fv-deploiement-applicatif
INFO     README-AI is now executing.
INFO     Successfully validated OpenAI API key.
INFO     Model: {'endpoint': 'https://api.openai.com/v1/chat/completions', 'engine': 'gpt-4', 'encoding': 'cl100k_base', 'rate_limit': 5, 'tokens': 699, 'tokens_max': 3999, 'temperature': 0.9, 'api_key': '****************'}
INFO     Repository: GitConfig(repository='/home/ben/REPO/fv-deploiement-applicatif', name='fv-deploiement-applicatif')
INFO     Successfully cloned /home/ben/REPO/fv-deploiement-applicatif to /tmp/tmpl2vq0tfd.
INFO     Dependencies: ['', 'xxxxxx']
INFO     Total files: 42
WARNING  Ignoring file: README.md
WARNING  Ignoring file: ansible.cfg
ERROR    HTTPStatus Exception:
Client error '404 Not Found' for url 'https://api.openai.com/v1/chat/completions'
For more information check: https://httpstatuses.com/404
ERROR    HTTPStatus Exception:
Client error '404 Not Found' for url 'https://api.openai.com/v1/chat/completions'
requet to test the endpoint: (works)
(base) conf|main ⇒ curl --location 'https://api.openai.com/v1/chat/completions'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer sk-xxxxx'
--data '{
"model": "gpt-3.5-turbo",
"messages": [{"role": "user", "content": "What is the OpenAI mission?Put the result in JSON format"}]
}'
{
"id": "chatcmpl-80sisBYMJVhyvN40gpAGE9E7JPTHB",
"object": "chat.completion",
"created":<PHONE_NUMBER>,
"model": "gpt-3.5-turbo-0613",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "{\n  "mission": "The mission of OpenAI is to ensure that artificial general intelligence (AGI) benefits all of humanity. They aim to build safe and beneficial AGI or to aid others in achieving this outcome. OpenAI commits to long-term safety, conducting research to make AGI safe, and driving the broad adoption of safety measures across the AI community. Additionally, they strive to cooperate with other institutions to address AGI's global challenges and distribute its benefits equitably."\n}"
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 20,
"completion_tokens": 98,
"total_tokens": 118
}
}
conf file:
OpenAI API Settings
[api]
endpoint = "https://api.openai.com/v1/chat/completions"
engine = "gpt-3.5-turbo"
encoding = "cl100k_base"
rate_limit = 5
tokens = 669
tokens_max = 3899
temperature = 1.2
Repository
[git]
repository = "https://github.com/eli64s/readme-ai"
name = "readme-ai"

Hey @benherve! Have you tried exporting your API Key as an environment variable?
export OPENAI_API_KEY="my-key"

Also get the latest version using the command below
pip install --upgrade readmeai

Let me know if you're still facing issues, thanks!

Hello,
thanks with the last update and export api ley before, it works, thx
i get exception, do you know why ?
Processing prompt: group_vars/all.yml
Response: This code defines variables that store sensitive information like usernames and passwords from a vault. It also sets various paths and configurations for a server, SFTP, Nexus, localhost, and email. This configuration is used for managing deployments and interacting with different systems in a distributed environment.
ERROR    Exception:
INFO
Processing prompt: 1
Response: Deploy, Innovate, Simplify!
INFO
Processing prompt: 2
Response: The project is focused on automating the installation and deployment of various applications using Ansible playbooks. It includes tasks such as updating logs, pre-checks, retrieving and pushing packages, extracting files, configuring applications, starting and stopping services, and sending log files via email. The core value proposition of the project is to streamline the installation and deployment process, reducing manual effort and ensuring consistency across different components in a distributed system.
ERROR    Exception:
INFO     YAML setup guide: []
INFO     README file generated at: readme-ai.md
INFO     README-AI execution complete.

Awesome! There was probably an issue with one of the OpenAI API requests, which can happen due to a variety of factors.
Are you using a free account on OpenAI or did you setup a payment?

Bonjour,Payment account. After a relaunch it seems ok. No more error. Cordialement Benjamin Herve. On 26 Sep 2023, at 14:43, Eli Salamie @.***> wrote:
Awesome! There was probably an issue with one of the OpenAI API requests, which can happen due to a variety of factors.
Are you using a free account on OpenAI or did you setup a payment?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Cool, thanks for trying out the tool!
Eli


Exporters

In the section OTLP Endpoint there is a flaw in the code provided in the third and fourth code example. If this example is used then the data will not make it to the HTTP Endpoints.  This is because of a flaw in the .NET Library but there is a workaround.  Here's the example code for reference:
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry()
  .WithTracing(b =>
{
    b
    .AddOtlpExporter(opt =>
    {
        opt.Endpoint = new Uri("your-endpoint-here");
        opt.Protocol = OtlpExportProtocol.HttpProtobuf;
    })
    // The rest of your setup code goes here too
});

If this code is used with the default endpoint "http://localhost:4318" it will fail!  To workaround this issue the Endpoint can be specified using an Environment Variable instead.  To set the endpoint and get the default path set use the Environment Variable OTEL_EXPORTER_OTLP_ENDPOINT.

Thanks for the issue @cparkins -- I see you filed an issue here: https://github.com/open-telemetry/opentelemetry-dotnet/issues/5054
Is the nature of this issue that you must specify /v1/traces to the end of the URI string to make this work to a local collector?

@cartermp Yes, that is the problem; With traces. For Logs /v1/logs needs to be added and /v1/metrics for Metrics.  This isn't necessarily a problem with just local collectors though.  But the code in the example does not actually work when connecting to a local collector if you specify the Endpoint using the ExporterOptions.  I realize that there are other ways to set the endpoints for each Signal type; As this is how I'm addressing the issue in my Application.  I think setting the Endpoint should be consistent and do not understand why allowing it in one place is allowed and not in the other.  Otherwise I probably would have submitted a PR as well.

I'll defer to @open-telemetry/dotnet-approvers on what the intended behavior should be, and we'll document that.
In the interim, we can certainly accept a change that uses localhost:4318/v1/traces as the example and maybe a code comment saying that you can plug your own endpoint in there.
I can also buy the argument that if the environment variable correctly appends the right signal type to the URL, then that should also happen if you do this programmatically (and forget it to do it yourself). I'd also prefer that behavior, but that's also the .NET SIG's call.

@cartermp - There's only one problem with the Interim solution. You can only append the /v1/traces if you are only sending Traces. If you are sending Logs, Metrics and Traces the only way to set the Endpoint with the Exporter Options (which is what is in the Documentation) is to use the Environment Variable.  Obviously if you are specifying the endpoint for each Signal this problem goes away, and I assume that may be why it was written that way.

Today if you're doing things programmatically, you do need to specify an exporter for each signal. There's no current way to specify a single exporter with an HTTP endpoint for all signals - you need to add each signal support and within each configure an endpoint.

@cartermp - Sorry, you're right! I got confused with the .NET Library and the Library that our teams have been using which allows a single Exporter Options to be passed in for all three types! I think the interim solution is fine.  Just noticed the disparity between doing it one way versus another.


Plugins incorrectly loaded during test runs

I got a failing test which turned out to be because llm-ollama was installed:
>           assert not self._requests_not_matched, (
                f"The following requests were not expected:\n"
                f"{requests_description}\n"
                "\n"
                "If this is on purpose, refer to https://github.com/Colin-b/pytest_httpx/blob/master/README.md#allow-to-not-register-responses-for-every-request"
            )
E           AssertionError: The following requests were not expected:
E             - GET request on http://<IP_ADDRESS>:11434/api/tags
E             - GET request on http://<IP_ADDRESS>:11434/api/tags
E
E             If this is on purpose, refer to https://github.com/Colin-b/pytest_httpx/blob/master/README.md#allow-to-not-register-responses-for-every-request
E           assert not [<Request('GET', 'http://<IP_ADDRESS>:11434/api/tags')>, <Request('GET', 'http://<IP_ADDRESS>:11434/api/tags')>]
E            +  where [<Request('GET', 'http://<IP_ADDRESS>:11434/api/tags')>, <Request('GET', 'http://<IP_ADDRESS>:11434/api/tags')>] = <pytest_httpx._httpx_mock.HTTPXMock object at 0x33a424f40>._requests_not_matched

../../../.local/share/virtualenvs/llm-p4p8CDpq/lib/python3.10/site-packages/pytest_httpx/_httpx_mock.py:329: AssertionError
================================================================================================== short test summary info ===================================================================================================
ERROR tests/test_llm.py::test_llm_prompt_creates_log_database - AssertionError: The following requests were not expected:

That's not supposed to happen because of this code:
https://github.com/simonw/llm/blob/d34eac57d39c20d829a0c090cdda9e64705d9291/llm/plugins.py#L15-L17
And:
https://github.com/simonw/llm/blob/d34eac57d39c20d829a0c090cdda9e64705d9291/tests/conftest.py#L11-L14
But I added some print statements and saw this:
Gonna load those plugins False
Setting that sys._called_from_test = True

So those things are firing in the opposite order from what I expect.
diff --git a/llm/plugins.py b/llm/plugins.py
index 933725c..25d6bc3 100644
--- a/llm/plugins.py
+++ b/llm/plugins.py
@@ -14,6 +14,7 @@ LLM_LOAD_PLUGINS = os.environ.get("LLM_LOAD_PLUGINS", None)

 if not hasattr(sys, "_called_from_test") and LLM_LOAD_PLUGINS is None:
     # Only load plugins if not running tests
+    print("Gonna load those plugins", getattr(sys, "_called_from_test", False))
     pm.load_setuptools_entrypoints("llm")

diff --git a/tests/conftest.py b/tests/conftest.py
index 7eb3dd5..322666b 100644
--- a/tests/conftest.py
+++ b/tests/conftest.py
@@ -10,6 +10,7 @@ from typing import Optional

 def pytest_configure(config):
     import sys
+    print("Setting that sys._called_from_test = True")

     sys._called_from_test = True

This seems to fix it, by only loading plugins when a CLI command is invocated:
diff --git a/llm/cli.py b/llm/cli.py
index bb9075e..eb585f0 100644
--- a/llm/cli.py
+++ b/llm/cli.py
@@ -137,6 +137,9 @@ def cli():

         llm 'Five outrageous names for a pet pelican'
     """
+    from .plugins import load_plugins
+
+    load_plugins()

 @cli.command(name="prompt")
diff --git a/llm/plugins.py b/llm/plugins.py
index 933725c..5c00b9e 100644
--- a/llm/plugins.py
+++ b/llm/plugins.py
@@ -12,27 +12,36 @@ pm.add_hookspecs(hookspecs)

 LLM_LOAD_PLUGINS = os.environ.get("LLM_LOAD_PLUGINS", None)

-if not hasattr(sys, "_called_from_test") and LLM_LOAD_PLUGINS is None:
-    # Only load plugins if not running tests
-    pm.load_setuptools_entrypoints("llm")
-
-
-# Load any plugins specified in LLM_LOAD_PLUGINS")
-if LLM_LOAD_PLUGINS is not None:
-    for package_name in [name for name in LLM_LOAD_PLUGINS.split(",") if name.strip()]:
-        try:
-            distribution = metadata.distribution(package_name)  # Updated call
-            llm_entry_points = [
-                ep for ep in distribution.entry_points if ep.group == "llm"
-            ]
-            for entry_point in llm_entry_points:
-                mod = entry_point.load()
-                pm.register(mod, name=entry_point.name)
-                # Ensure name can be found in plugin_to_distinfo later:
-                pm._plugin_distinfo.append((mod, distribution))  # type: ignore
-        except metadata.PackageNotFoundError:
-            sys.stderr.write(f"Plugin {package_name} could not be found\n")
-
-for plugin in DEFAULT_PLUGINS:
-    mod = importlib.import_module(plugin)
-    pm.register(mod, plugin)
+_loaded = False
+
+
+def load_plugins():
+    global _loaded
+    if _loaded:
+        return
+    _loaded = True
+    if not hasattr(sys, "_called_from_test") and LLM_LOAD_PLUGINS is None:
+        # Only load plugins if not running tests
+        pm.load_setuptools_entrypoints("llm")
+
+    # Load any plugins specified in LLM_LOAD_PLUGINS")
+    if LLM_LOAD_PLUGINS is not None:
+        for package_name in [
+            name for name in LLM_LOAD_PLUGINS.split(",") if name.strip()
+        ]:
+            try:
+                distribution = metadata.distribution(package_name)  # Updated call
+                llm_entry_points = [
+                    ep for ep in distribution.entry_points if ep.group == "llm"
+                ]
+                for entry_point in llm_entry_points:
+                    mod = entry_point.load()
+                    pm.register(mod, name=entry_point.name)
+                    # Ensure name can be found in plugin_to_distinfo later:
+                    pm._plugin_distinfo.append((mod, distribution))  # type: ignore
+            except metadata.PackageNotFoundError:
+                sys.stderr.write(f"Plugin {package_name} could not be found\n")
+
+    for plugin in DEFAULT_PLUGINS:
+        mod = importlib.import_module(plugin)
+        pm.register(mod, plugin)

But... won't that break the Python library use-case, which also relies on plugins being loaded so that thinks like llm.get_model("claude-3.5-sonnet") work?
Maybe the llm.get_model() and llm.get_embedding_model() functions should also trigger load_plugins()?

@simonw This change broke unit tests that check if a plugin is registered.  Numerous LLM plugins have such a test: https://github.com/search?q="def+test_plugin_is_installed()%3A"+language%3Apython&type=code. What's the recommended way to fix this? Drop the test?

We can first call load_plugins() in test_plugin_is_installed (this could've used a mention in the release notes).

True. I re-added this test in llm-ollama: https://github.com/taketwo/llm-ollama/commit/d481ab31d732065c8ca1d068238c701750882730.


Allow std::unordered_map as ObjectType

This PR fixes the definition of object_t to allow to use std::unordered_map as ObjectType.
Fixes #2932.

Can I ask why this was closed?

It wasn't possible to implement at the time.  @nlohmann I wonder if the introduction of the intermediate data struct holding the value type means that it is possible to do this now, since the basic_json type could be complete.


Investigate: create and submit transaction to SDK/TM chain

Summary
Create and submit an IBC transaction to SDK/TM chain.
Problem Definition
relayer needs to submit transactions that include the IBC messages and packets.
Proposal
Evaluate https://github.com/iqlusioninc/crates/tree/develop/stdtx for submitting an IBC transaction.  Could be for ClientCreate or ClientUpdate, or other.
Keystore doesn't have to be part of this if a workaround is found. We will deal with this in another issue.
For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Let's start with a ConnOpenInit - https://github.com/cosmos/ics/tree/master/spec/ics-003-connection-semantics#opening-handshake

We should open a new issue listing the set of transactions so we can start knocking them off

Protobuf txs have not landed yet on the SDK so lets bump the milestone on this for now

Related:

stdtx: tracking issue for Protobuf transaction support (#459)
tmkms tx-signer: post-Stargate roadmap

This is effectively done in #242 but bringing it into the relayer-cli is now blocking on #243 or some other resolution of dependency hell.

Got a basic keystore working. You can test against branch andy/tx-sign. Running the command below
 ./target/debug/relayer -c ./relayer-cli/tests/fixtures/two_chains.toml keys restore ibc0 test "mixture fatigue fold federal hour frequent atom seek apart diesel armed start lawn hello milk say steak peasant wonder inquiry vague mind reduce rib"

Should give the result:
key restore result:  "55d4ae3492a831453fc273aff431fc76094e9b1c"

Next step is to use the private key to sign the message in the transaction.

I believe the tx signing is working but getting a internal error testing against stargate-4 chains (running with go relayer dev-env script)
./target/debug/relayer -c ./relayer-cli/tests/fixtures/two_chains.toml tx raw conn-init ibc0 ibc1 ibczeroclient ibconeclient ibczeroconn ibconeconn
     Message ConnectionOpenInitOptions { src_client_id: ClientId("ibczeroclient"), dest_client_id: ClientId("ibconeclient"), src_connection_id: ConnectionId("ibczeroconn"), dest_connection_id: ConnectionId("ibconeconn"), src_chain_config: ChainConfig { id: chain::Id(ibc0), rpc_addr: Tcp { peer_id: None, host: "localhost", port: 26657 }, account_prefix: "cosmos", key_name: "testkey", store_prefix: "ibc", client_ids: ["cla1", "cla2"], gas: 200000, trusting_period: 1209600s }, dest_chain_config: ChainConfig { id: chain::Id(ibc1), rpc_addr: Tcp { peer_id: None, host: "localhost", port: 26557 }, account_prefix: "cosmos", key_name: "testkey", store_prefix: "ibc", client_ids: ["clb1"], gas: 200000, trusting_period: 1209600s } }
TxRAW "0a9f010a9c010a2d2f6962632e636f72652e636f6e6e656374696f6e2e76312e4d7367436f6e6e656374696f6e4f70656e496e6974126b0a0d6962637a65726f636c69656e74120b6962637a65726f636f6e6e1a1c0a0c6962636f6e65636c69656e74120a6962636f6e65636f6e6e1a002205312e302e302a283235454635364341373935313335453430393336384536444238313130463232413442453035433212500a4e0a460a1f2f636f736d6f732e63727970746f2e736563703235366b312e5075624b657912230a2103af916c8d01cfdb919cc875539c759b4adb210f324d716c7ab4e4d74d408cc9ac12040a0208011a400bb6dd5cca614c3217eb75203e1b5559ee0f88d4f01314ec90223f2e50c4e1bd62fe531a1fb9311c989e227330274602c27f142f43ac70a2627f4387962c6e6a"
Tx Error Response: Response { code: Err(1), data: Data([]), log: Log("internal"), hash: transaction::Hash(D2969C20DA35EBA7B1883F1679BD3AE272B07DCCF3559B02FF41511DDD325AB4) }
conn init failed, error:  tx error: Message transaction failure: failed to initialize open connection: RPC error: RPC error: internal

if I send the tx via broadcast_tx_sync directly also get the error
curl localhost:26657/broadcast_tx_sync?tx=0x0a9f010a9c010a2d2f6962632e636f72652e636f6e6e656374696f6e2e76312e4d7367436f6e6e656374696f6e4f70656e496e6974126b0a0d6962637a65726f636c69656e74120b6962637a65726f636f6e6e1a1c0a0c6962636f6e65636c69656e74120a6962636f6e65636f6e6e1a002205312e302e302a283235454635364341373935313335453430393336384536444238313130463232413442453035433212500a4e0a460a1f2f636f736d6f732e63727970746f2e736563703235366b312e5075624b657912230a2103af916c8d01cfdb919cc875539c759b4adb210f324d716c7ab4e4d74d408cc9ac12040a0208011a400bb6dd5cca614c3217eb75203e1b5559ee0f88d4f01314ec90223f2e50c4e1bd62fe531a1fb9311c989e227330274602c27f142f43ac70a2627f4387962c6e6a

{
  "jsonrpc": "2.0",
  "id": -1,
  "result": {
    "code": 1,
    "data": "",
    "log": "internal",
    "codespace": "undefined",
    "hash": "D2969C20DA35EBA7B1883F1679BD3AE272B07DCCF3559B02FF41511DDD325AB4"
  }

The error doesn't show up in the chains log so not sure where it's happening. Haven't been able to debug it directly on gaia or cosmos-sdk yet.

The tx raw conn-init command works now. Signing the message is working and the gaia chain (stargate-4) accepts the transaction.
For now, I've added two parameters to the command

signer-key (-k) -> you specify a key file (name and location) that will be used as the signer. This key seed file has a mnemonic (seed phrase) that can be used to retrieve the private key (BIP-39)
account_sequence (-s) -> this is the account sequence value, basically every time a tx is committed by the account this number increases

Testing the transaction:

Start two chains using the dev-env script from the ovrclk/relayer (checkout stargate-4)
After you run the script, the Go relayer will create a data folder for the chains. Open the key seed file ./data/ibc1/key_seed.json for chain ibc-1 and look for the account value

{"name":"user","type":"local","address":"cosmos1tqzwwr5hrnq2ceg5fg52m720m50xpfy08at7l9","pubkey":"cosmospub1addwnpepq08wntxejcla5hd93stgudw02htdpa9vu5a2ds8xkvmgrkrrpwlj6sdhkz6","mnemonic":"[MNEMONIC WORDS"}

In order to find the account sequence run:

gaiad query account cosmospub1addwnpepq08wntxejcla5hd93stgudw02htdpa9vu5a2ds8xkvmgrkrrpwlj6sdhkz6 --home ./data/ibc1 --chain-id ibc1 --node tcp://localhost:26557
this will return the sequence number at the end. Make a note of that, you will need this number as an argument to the transaction command.
'@type': /cosmos.auth.v1beta1.BaseAccount
account_number: "0"
address: cosmos1tqzwwr5hrnq2ceg5fg52m720m50xpfy08at7l9
pub_key:
  '@type': /cosmos.crypto.secp256k1.PubKey
  key: A87prNmWP9pdpYwWjjXPVdbQ9KzlOqbA5rM2gdhjC78t
sequence: "12"

Run the transaction command. We will try to initialize an ibczeroconn2 connection

cargo run --bin relayer -- -c ./relayer-cli/tests/fixtures/two_chains.toml tx raw conn-init ibc0 ibc1 ibczeroclient ibconeclient ibczeroconn2 ibconeconn -s 12 -k key_seed.json
if you get an empty response it means the tx worked
conn init, result:  []

Check if the connection was created on ibc-1 using the Golang relayer

rly query connections ibc1 | jq .
you should see an entry in the JSON file that points to the ibczeroconn2 connection with state STATE_INIT
{
      "id": "ibczeroconn21",
      "client_id": "ibczeroclient",
      "versions": [
        "\n\u00011\u0012\rORDER_ORDERED\u0012\u000fORDER_UNORDERED"
      ],
      "state": "STATE_INIT",
      "counterparty": {
        "client_id": "ibconeclient",
        "connection_id": "ibconeconn",
        "prefix": {
          "key_prefix": "aWJj"
        }
      }
    },

Looks good. A few observations:

In order to find the account sequence run:
gaiad query account cosmospub1addwnpepq08wntxejcla5hd93stgudw02htdpa9vu5a2ds8xkvmgrkrrpwlj6sdhkz6 --home ./data/ibc1 --chain-id ibc1 --node tcp://localhost:26557

here we need to pass the address, cosmos1tqzwwr5hrnq2ceg5fg52m720m50xpfy08at7l9 in the example.

If we try to create the same connection twice we should get an error. You should call broadcast_tx_commit() in broadcast_tx(), this will return the Code (success or failure) and some Log and Data to show in case of failure.
Currently it returns creating the connection second time returns:
conn init, result:  []
Here are the current logs (removed some):
D[2020-10-27|13:31:55.968] Invalid tx                                   module=state code=2 log="\ngithub.com/cosmos/cosmos-...(*localClient).DeliverTxAsync
failed to execute message; message index: 0: connection handshake open init failed: ibczeroconn4: connection already exists"

With broadcast_tx_commit() it returns something like:
conn init, result:  TxResult { code: Err(2), data: None, log: Log("\ngithub.com/cosmos/cosmos-sdk/x/ibc/core/03-connection/keeper.Keeper.ConnOpenInit\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/x/ibc/core/03-connection/keeper/handshake.go:27\ngithub.com/cosmos/cosmos-sdk/x/ibc/core/03-connection.HandleMsgConnectionOpenInit\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/x/ibc/core/03-connection/handler.go:13\ngithub.com/cosmos/cosmos-sdk/x/ibc/core.NewHandler.func1\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/x/ibc/core/handler.go:36\ngithub.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runMsgs\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/baseapp/baseapp.go:692\ngithub.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runTx\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/baseapp/baseapp.go:653\ngithub.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).DeliverTx\n\tgithub.com/cosmos/cosmos-sdk@v0.40.0-rc0/baseapp/abci.go:271\ngithub.com/tendermint/tendermint/abci/client.(*localClient).DeliverTxAsync\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/abci/client/local_client.go:87\ngithub.com/tendermint/tendermint/proxy.(*appConnConsensus).DeliverTxAsync\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/proxy/app_conn.go:85\ngithub.com/tendermint/tendermint/state.execBlockOnProxyApp\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/state/execution.go:313\ngithub.com/tendermint/tendermint/state.(*BlockExecutor).ApplyBlock\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/state/execution.go:138\ngithub.com/tendermint/tendermint/consensus.(*State).finalizeCommit\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:1569\ngithub.com/tendermint/tendermint/consensus.(*State).tryFinalizeCommit\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:1487\ngithub.com/tendermint/tendermint/consensus.(*State).enterCommit.func1\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:1420\ngithub.com/tendermint/tendermint/consensus.(*State).enterCommit\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:1459\ngithub.com/tendermint/tendermint/consensus.(*State).addVote\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:2044\ngithub.com/tendermint/tendermint/consensus.(*State).tryAddVote\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:1846\ngithub.com/tendermint/tendermint/consensus.(*State).handleMsg\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:803\ngithub.com/tendermint/tendermint/consensus.(*State).receiveRoutine\n\tgithub.com/tendermint/tendermint@v0.34.0-rc4.0.20201005135527-d7d0ffea13c6/consensus/state.go:752\nfailed to execute message; message index: 0: connection handshake open init failed: ibczeroconn4: connection already exists") }

we will need to get a shorter explanation for that  Err(2)

Thanks @ancazamfir  I will look into those error cases for an existing connection.


requirements.txt

Hello. I wanted to try MARS for my project. I created a new environment via conda, which I called mars. Then I installed requirements.txt via conda again
while read requirement; do conda install --yes $requirement; done < requirements.txt 2>error.log
Then, when I ran the cellbench.ipynb, I got a lot of errors from the very beginning, while loading the required libraries. Looking at the error.log that I created above, I see that many libraries could not be found. For example,  annoy==1.16.0. Doing conda search annoy, I see that there is no package called just annoy, but python-annoy instead. I am wondering if the requirements.txt file is outdated...? And which python version is MARS built on? I have python 3.8 in my system.
I actually rarely use python, I am an R user, so I may miss something here.
Thank you very much!

I managed to work around the above. However, new incompatibilities have risen (see my new issue: MARS code problems)

I managed to work around the above. However, new incompatibilities have risen (see my new issue: MARS code problems)


You want the hover display to zoom in directly

like this

Direct zoom in
Links that help me focus more on the moment

Closing as duplicate of issue #70; please check existing issues before opening new ones, thanks.


Support for IE11, Edge and Firefox

This pull request introduce support for mentioned browsers.
It addresses issue #6 and probably #10 (this one should be checked).
If merged, please update on npm as well.

@CezaryDanielNowak any update on this PR?

@kkwiatkowski is this update containing some changes from Clamp.js forks? If so, please update comment at the top.
PR is OK

@CezaryDanielNowak nop, this update doesn't contain any changes from Clamp.js forks.

@CezaryDanielNowak Thanks for merge! I'm waiting for new release and npm update then :).


Flash of wrong scroll position

I am using scroll to top behavior. It works great and I'm no longer in weird scroll positions in a new route. However, there's a flash or wrong position before flashing back to the top.
I am using it with Redux-router:
reduxReactRouter({ routes, createHistory: useScrollToTopBehavior(createHistory) });
Thanks

Yeah, I have a better idea for how to handle scrolling. Won't work for async routes but actually even now I don't support async routes so it's no real loss.

Should be closed by #16.

still have this issue. how to solve it? plz advise! thx!

@hsin421 Using this library with redux-router through createHistory won't work and you'll have jumping (buggy) scroll.
I managed to get it working though:
acdlite/redux-router#261


Not working on OSX

Hey! First of all, thanks for this plugin!. In windows is working super nice, but i cannot make it work on OSX. The server is installed :

But it doesn't work:

Did you install pyright with pip or with npm?

With pip pip install pyright

It's strange because i'm using it on OSX with poetry also. Tomorrow I'll try to reproduce it in another mac and update you here.

To be precise, is only installing the server and having it on path, and install the plugin right?

@nstirnemann7 Yes. Should be it. I really tried here but couldn't reproduce this error. Here i just ran pip install pyright and it worked flawlessly. It's important to notice that pyright requires node.js to be installed, maybe this is the missing link.

Hey! I tested it with 18.12.1. Is there a way to debug this? Perhaps initializing lapce with a flag or something like that?

Am also getting same error on fedora. Installed pyright via npm

Okay so after a little investigation I was able to get it working under linux.
The problem seems related to flatpak sandbox and non-bundled python environments like pyenv (potentially the same problem occurs with OSX app sandbox).


Bind C-i to auto-indent

In Emacs C-i is bound to indent-for-tab-command, which is roughly the same as editor:auto-indent in Atom, I think.

Thanks!


JSP Vaildation Error after import to STS

We'd like to include PetClinic as a sample app on the STS dashboard.
Unfortunately it has a validation error when I import the current master branch to STS as an m2e project.
This is the error I am getting:
pageContext cannot be resolved	inputField.tag
/spring-pet-clinic/src/main/webapp/WEB-INF/tags
line 11
JSP Problem
Any idea what this error means and how to fix it?
It may very well be the problem isn't actually with the App but with the validations or Eclipse classpath. The app seems to deploy just fine to Tc Server in STS despite the error.

Hi ..... I would like to deploy this application in Cloud Foundry as a POC for CF implementation.
Could you please give the details steps to Deploy this application in cloud foundry ....

@naray89k You can just follow this tutorial: https://spring.io/guides/gs/sts-cloud-foundry-deployment/
Regards,
Michael.


Allow klusterlet to patch hostAliases when creating klusterlet-registration-agent deployment

Hi,
IF we want to add hostAliases in all deployments under the namespace open-cluster-management-agent. So the Managed Cluster can resolve hostname of hub cluster API.
# patch
spec:
  template:
    spec:
     hostAliases:
       - ip: a.b.x.y
         hostnames:
           - api.company.lan

We patched klusterlet deployment, it's fine.. but when we patched klusterlet-registration-agent , it get overriden.
There is a permanent way to patch klusterlet-registration-agent by hostAliases and in general by any Pod Spec.

you can set hubApiServerHostAlias in klusterlet resource, it will update the hostaliases field on registration/work agent.


Add eenv_appname:get_/1/2 [ENHANCEMENT]

Would it be possible to also generate get_/1,get_/2 functions like these:
% eenv_appname.beam
-module(eenv_appname).

-export([get/1]).
-export([get_/1, get_/2]).

get(ip) -> {ok, "<IP_ADDRESS>"};
get(_)  -> undefined.

%% extra API
get_(ip) -> "<IP_ADDRESS>";
get_(_)  -> undefined.

get_(Key, Default) ->
  case get_(Key) of
     undefined -> Default;
     Value -> Value
  end.

The idea with get_/1 is to return the value immediately, and avoid matching against the tuple {ok, Value} in the caller.
Second, get_/2 will return a default value instead of getting undefined.
As you may have noticed, I've added an underscore _ suffix to these new calls to not clash with the original get/1.

New eenv_router.erl module for consistency.
% eenv_router.beam
-module(eenv_router).

-export([get/2]).
-export([get_/2, get_/3]).

get(appname_1, Key) -> eenv_appname_1:get(Key);
get(appname_2, Key) -> eenv_appname_2:get(Key);
get(_, _) -> unload.

%% extra API
get_(appname_1, Key) -> eenv_appname_1:get_(Key);
get_(appname_2, Key) -> eenv_appname_2:get_(Key);
get_(_, _) -> unload.

get_(appname_1, Key, Default) -> eenv_appname_1:get_(Key, Default);
get_(appname_2, Key, Default) -> eenv_appname_2:get_(Key, Default);
get_(_, _,_) -> unload.

The whole purpose of erl-env is to speed up application:get_env, right?
So why not go one level down, and produce this instead:
% eenv_appname.beam
-module(eenv_appname).

-export([ip/0, port/0]).

ip() -> "<IP_ADDRESS>".
port() -> 8080.

get(Key, Default) ->
    case erlang:function_exported(?MODULE, Key, 0) of
        true -> Key();
        false -> Default
    end.

In my option:

It would not increase speed with cutting down the {ok, Value} to Value(The difference is too small to be measured).  But this will cause one confusion when it return undefined, this mean the key is missing or value is 'undefined' ?

ip() -> "<IP_ADDRESS>".
port() -> 8080.

This assuming that the Module find function is more efficient than function clause match?
I only know the function clause match is binary tree search. It's fast.
I don't know how module find function. maybe you can prove this by benchmark.
Inconvenient: Caller will make sure the key is exist. I think this will too low level down for normal user.

Make the Default into function clause.

The original method just have one atom argument. It make the search as simple as possible.
And It would not hit the default branch and only hit the match clause at most of time in production environment.
The new method increase one argument, and no use most of time， Not sure the compile can optimize
this function clause.
Change to new method is very simple, you can do it and add a small benchmark in eenv_benchmark.erl to see.
PR is welcome~


Changed deprecated slot syntax

In the wake of #359 there is a small PR which gets rid of the slot and slot-scope attributes which are strongly discouraged since Vue 2.6 and deprecated in Vue 3.
This PR was made as a small step towards #350 and #351 and is in fact the preliminary step before migrating to Vue 3 as stated in the official migration guide.
This should have no impact on any working Wegue application as deprecated syntax can still be used next to the new one but it should be tested on bigger and more complete apps just to be sure...

Hi @sronveaux, thanks a lot for providing this! I`m unfortunately a bit short currently for a full review but will do either in the upcoming weeks or maybe @chrismayer can?!
Do the commits 607c6a3373d5fa62918914ad1ce25c549b815903 and 49ea5f30f7c666397e25ceeba83b18a45df42a9c relate to slot syntax changes?
Maybe you should either change the title of this PR to something more general like "maintenance" or rather split it up into 2 separate PRs (can be nested).
Greets Felix

Hi @fschmenger and thanks for the comment, no problem, there is no hurry, this will be useful later when updating to Vue3 but it has no other purpose...
Concerning the two commits, it was kind of linked because when updating the workshop documentation with the new syntax, I came across the fact that the workshop code couldn't be run anymore because of linting errors. So it was no point to change just the slot syntax but have a code that can't be run on current version of Wegue...
No problem, this PR now just changes the slot syntax in code and documentation and I'm going to create another PR with the updates to the workshop...
Greets, Sébastien


Investigate automatic wasm copying for jupyterlab webpack

see this and this
"Basically, if you import a file that is prefixed by JUPYTERLAB_(RAW|URL|FILE)LOADER, it will use that particular webpack loader. So if in your build step, you copy the relevant files to your build directory and prefix them with JUPYTERLAB_FILE_LOADER_, they can be bundled up with webpack using its file loader"

Thanks, a fix for this has been merged and will be in the 0.1.18 release.
The Jupyter Lab plugin should no longer require additional assets.


Errors remain after running "flutter generate" to generate files in .dart_tool

This was raised by @szotp at https://github.com/Dart-Code/Dart-Code/issues/1970 but it seems like an analysis server bug.
The sample project uses the r_flutter package which generates a class for all Flutter assets when you run flutter generate. The lib/main.dart file looks like this:
import 'package:flutter/material.dart';
import 'assets.dart';

void main() {
  print(Assets.main);
  runApp(SizedBox());
}

The assets.dart file does not exist, but after running flutter generate it gets created at .dart_tool/build/generated/generation_sample/lib/assets.dart. If you start the server when the file already exists, the server (though some mechanism I'm not familiar with) knows that import "asserts.dart" refers to the file inside the _dart.tool folder and everything works.
However, if the file doesn't exist when the server starts, and you run flutter generate while the server is running, it does not seem to locate the file or remove the errors. The new file does show in the instrumentation log (though doesn't seem to trigger any analysis or anything):
1587477792255:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/pubspec.yaml:add
1587477794124:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/pubspec.lock:add
1587477794124:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/.packages:add
1587477794124:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/build/entrypoint/id:add
1587477794124:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/.dart_tool/package_config.json:add
1587477805034:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/.dart_tool/pub/bin/build_runner/build_runner.dart.snapshot.dart2:add
1587477805615:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/flutter_tool/.dart_tool/build/entrypoint/build.dart:add
1587477814083:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/build/entrypoint/build.dart.snapshot:add
1587477814974:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/build/generated/generation_sample/lib/assets.dart:add
1587477814975:Watch:/Users/danny/Desktop/generation_sample:/Users/danny/Desktop/generation_sample/.dart_tool/build/098d3ee73e6cc294616d3a2e2c3c81ad/asset_graph.json:add

Interesting, I did not know about flutter generate. I wonder when it got added? The docs:
run code generators.

don't seem particularly extensive.

Yeah, I couldn't find much on it either - I think it may have been to support codegen during hot reloads? (it came up in Dart-Code before because of some issues hitting breakpoints with it).
I'm not sure if the mechanism for generating the files matters here though - I suspect creating that file manually would show the same issue.
I don't know why the import "asserts.dart" can act like `import "../.dart_tool/build/generated/generation_sample/lib/assets.dart";. I presume it's deliberate, but I'm not sure what the rules are (so I'm not sure where to start to understand why the late-generated file doesn't work).

flutter generate was removed in https://github.com/flutter/flutter/pull/61475, so this doesn't seem like it can be an issue anymore.