Restructure the wrapper

In order of commits:

build examples for .NET Core 5.0 instead of the outdated .NET Core 2.0
put Dispose() logic in a base class extending SafeHandle for more exception safety in multithreaded contexts and a single place for Dispose() instead of in every class wrapping a C-API object
apply code style to examples so the next changes aren't cluttered by formatting changes
some functions return StreamInfo[] arrays, so I added a function to dispose those in a single line
use using and DisposeArray() in examples
build all examples as a single target so that build options (version, target framework etc.) can be adjusted in a single place. This changes the usage, e.g. dotnet -p examples\FooBar arg1 becomes dotnet -p examples FooBar arg1. Adding an example is a matter of dropping the .cs file in the examples folder, no need to add a new project.
as previously discussed, rename the liblsl class to LSL and move classes from this class into the root namespace
adjust the examples to reflect the changes in the previous commit
bump the assembly version to 2.0 and (for David) print the wrapper version in the example code

Gee, thanks for including me! It is so nice to know that I get to contribute next to nothing after you shoot down everything I suggest and then scoop my contribution before I even have a chance to put any effort into it!
But to be less snarky, I must say that of all the github repositories I contribute to, this has become the most difficult, and mostly this is due to the Tristan's attitude. I realize that I have not done much work here in the last few years and that yours, @tstenner, has been both persistent and excellent, but you need to understand that you do not own this project. This is a community effort irregardless how much work you personally contribute. Maybe I don't need to issue this admonishment, but it certainly feels that I do. I am always happy to work towards a consensus on topics before making decisions and I am more than happy to accept yours and other people's opinions when they differ from mine or when they are better informed, but you must be sympathetic to how frustrating it is when one tries to reach a consensus about a suggested change, is confronted with nothing but negative one-line comments, and then gets excluded from the actual development which I was trying to volunteer my time to do in the first place!
With that out of the way, I have a few comments. One is about the Framework targets and I have requested a change.
The other has to do with the reshuffling of the examples. This project doesn't build in Visual Studio now.
The last is about versioning. This is a bit tricky. With pylsl there is Chad's pattern of piggybacking on the lib version and adding patch numbers specific to the wrapper. I like that idea, but it doesn't work here because the changes to the wrapper break the API (again, I complain that Tristan is allowed to do this, but I am not---these changes will also wreak havoc with unity clients and the style is still bad!). This warrants a new Major bump, so 2.0 is good, but it breaks with the pattern established in pylsl. Personally, I think that having meaningful versions for each wrapper is more important than establishing a pattern across all the wrappers, so I am in support of this.
SafeHandle was a very good idea as it is the proper way to do this with InterOp objects, as opposed to IDisposable.

I don't understand this at all. As far as I can tell, .NET Core only goes up as high as 3.1. .NET (without any suffix) goes to 5.0. It is possible that the dotnet command will revert to the right thing, but when I open the property pages in Visual Studio, the traget framework field is simply empty. In the previous version, it is .NET Core 2.0. I believe it should be .NET Core 3.1.

You're right, that should be either .net5.0 or .netcoreapp3.1. Neither Visual Studio (2019 Preview) nor the dotnet CLI tool complained, but the project property page didn't accept it. It's fixed in d8a0661.

I must say that of all the github repositories I contribute to, this has become the most difficult, and mostly this is due to Tristan's attitude. I realize that I have not done much work here in the last few years [..]

I went back to the previous discussion and I have to admit that you're right, sorry. In hindsight, I mixed up some of your concerns about the wrapper version and names and didn't explain enough for me to recognize that the liblsl class had to be renamed anyway.

[..] then turn around to see him do it his way without consulting anyone about it.

To be fair, one of my older PRs I've been told I'd get some feedback I should incorporate is getting close to its second anniversary and for almost everything I let the corresponding PR sit around for a few weeks. Also, if it were up to me, the support for ancient MSVC version would be dropped several years earlier, but I've been working around those quirks anyway.
Some of the PRs (this one included) aren't meant as Pull Requests in the original sense but rather Discussions With Attached Code, but DWAC doesn't sound as good.
I wanted to rush this along as I'd like to merge the changes into LSL4Unity so I can use it for a project I'm currently working on. Still, I scooped some of the work you wanted to do, so before merging we can see how to add you to the commits for attribution.

The other has to do with the reshuffling of the examples. This project doesn't build in Visual Studio now. I also think the examples are now less clear. At the very least, it needs to build in VS.
The consolidate examples commit doesn't build in Visual Studio. When building the examples project I get an error for each attribute in each of the example program assembly info files is a duplicate:

I'm not entirely sure, but I think you have an older AssemblyInfo.cs in the folder. With all the goodness (project files you can write by hand, metadata included in the project setup) the new csproj format brings, the automated globbing of everything, even files not included by git and stuff in old build folders and the inability of dotnet clean to remove old build objects, is a constant source of errors like these. I just ran a clean build on a different computer, but without CI builds I can't be sure that it's a) failing because you had some extra files in the folder or b) working for me because I had some extra files not checked in.
Could you delete everything in the liblsl-Csharp folder and rebuild after running git checkout restructure?

The last is about versioning. This is a bit tricky. With pylsl there is Chad's pattern of piggybacking on the lib version and adding patch numbers specific to the wrapper.

This is tricky indeed and part of the whole DWAC, i.e. just a proposal for discussion and amendment. In general, there can be breaking changes in liblsl as well as the wrappers (like in this case), so the versions should be somewhat independent. On the other hand, I want to avoid compatibility lists where wrapper XY 2.1.4-2.1.8 supports liblsl 1.14.1-1.14.5 and so on. As Chad noted, we don't have an 'official' release so we can't break anything officially released, but that's something that needs a solution not just in this case but also for future releases.
My quick and dirty proposal: liblsl is currently at 1.14.0, so we could version the wrapper like X.1.14.Y, where X gets incremented for breaking wrapper changes and Y for non-breaking wrapper changes. 1.14 corresponds to the minimum supported liblsl version, so it conforms to semantic versioning, allows breaking changes in wrapper (like this one) and it's more or less plainly visible which liblsl version is needed, even with something like <IP_ADDRESS>. Again, just a proposal and I'd be happy to get your input on it.

I also think that this makes the examples a bit harder to understand. From a newbie point of view, when learning an API I find that it's nice to be able to simply run one, drop in a breakpoint and see what happens. Pushing them all under the same umbrella muddies the waters a bit. I would prefer keeping them as is.

I agree that it's not ideal. I can see three options:

Every example as separate project, with its own csproj file (how it was). Changing the version, target framework etc. has to be done for every subproject separately.
As before, but common attributes in a Directory.build.props. Changes in one place, but copying an example folder fails in mysterious ways.
Every example in a single file, but all in one project. Running an example takes one more step, but the run configuration has to be changed so the working directory points to a folder with lsl.dll in it:

I changed the name of the main function back to Main in the examples so it's possible to copy the .cs file to a new project and start from it immediately. One other QoL-improvement would be a prompt like "You've passed no example name on the command line. Please enter an example name or example number to run it: " so it's easier to start.
I prefer Nr. 3, but the commits to move from 1 to 3 are separate from all others so it's easier to drop them if there's a consensus to keep it as it was.

Well I am sorry to have been so crabby about this and I appreciate your being big about it. And, for the record, I don't see much reason for supporting obscure ABIs and ancient compilers either.

Some of the PRs (this one included) aren't meant as Pull Requests in the original sense but rather Discussions With Attached Code, but DWAC doesn't sound as good.

Understood. Although I said I would, I never got around to proposing a standard workflow for these things anyway, so I shouldn't complain.  That is just bad UX.

I'm not entirely sure, but I think you have an older AssemblyInfo.cs in the folder....

I'm not entirely sure what happened either. Initially I did a clean pull of this submodule into its own working dir and checkedout this PR. The only thing I did before building was to change the Target framework in the properties (I'm in VS here) from empty to .NET Core 3.1. Error city. I did a clean pull of this PR again, did not change the Target framework and it worked---even before attempting to checkout your restructure branch. However, I don't understand why that would have caused all that assembly attribute collision nonsense. Also, I noticed VS built the examples for .NET 5.0, so I guess it is being cute and assumes that that is what you meant by netcore5.0.
I think your versioning proposal is very good, but I am not sure it makes sense until NuGet packages are implemented. Until then, underlying dlls could be swapped. It is probably pretty low risk to plow ahead with the system, though. At the end of the day, I only care about this for support's sake.
Re the examples, I still vote for option 1. There are not that many of them and we shouldn't have to update the target framework often. So for me, the simplicity of each project is worth the hassle of disunion. As I mentioned earlier, the wrapper itself could be slightly improved by using some newer features of C# that aren't supported in .NET Framework 2.0, but perhaps until that happens I guess it doesn't make sense to change the target.

However, shouldn't these different versions always be back compatible?

Yes and no. Apart from the minor incompatibilities, the major breaking changes on the source code level were between .Net Framework 3.5, .Net Framework 4.0 onwards and .Net Core. So far so good, but building requires the SDK / .Net Framework targeting pack for the specific version in the project configuration. I'll push this change to the examples in a separate DWAC so we can focus on the remaining changes.

So we are locked in a legacy support loop yet again. C'est la vie.

Let me go through the checklist:

[X] One project per example
[X] David gets fame and fortune for cleaning up the messy class/namespace situation in d00412098066df42453323666021f284d6faa121 :wink:
[X] An additional launcher that compiles all example into one .exe that doesn't get noticed unless somebody opens the examples/LSLExamples.csproj directly
[X] All example .csproj files are identical so the .net version can be updated by changing one project file and running for f in *; do test -d $f && cp HandleMetaData/HandleMetaData.csproj $f/$f.csproj; done in the examples folder

It all looks fine to me.
Just a note, I would guess that since most users are using this for Unity projects at the moment that targeting .NET 5.0 will be ok. However, there are still many Windows users out there using .NET <=4.x and (the wonderfully named) .NET 5.0 (which is the successor to .NET Core 3.1) will have to change the target. For cross platform development, the newest version is definitely the way to go. The examples shouldn't really matter so much, but the lib should remain back compatible (which it is).
So is the next step writing async versions of all the methods? An awaitable pull_sample_async would definitely be a useful thing to have. It might be best just leave it to users to write their own wrappers. It is a pretty straight forward pattern:
public async Task pull_sample_async(...)
{
     await Task.Run(()=>pull_sample(...));
}

but it is a pain to have to develop this in over and over.
Another thing on my wishlist would be to get rid of the c-style array handling. I feel that pull_sample/chunk should return an IReadOnlyList instead of void. These two things taken together could be a whole other wrapper.

It all looks fine to me.

Thanks :-)
That leaves @cboulay to voice any objections or press the merge button.

Just a note, I would guess that since most users are using this for Unity projects at the moment that targeting .NET 5.0 will be ok. However, there are still many Windows users out there using .NET <=4.x and (the wonderfully named) .NET 5.0 (which is the successor to .NET Core 3.1) will have to change the target. For cross platform development, the newest version is definitely the way to go. The examples shouldn't really matter so much, but the lib should remain back compatible (which it is).

With the lib at .NET Standard 2.0 it can be used with anything since .NET Framework 4.6.1.
The examples should be what a fresh Visual Studio install defaults to, which is (afaik) .NET 5.0.

So is the next step writing async versions of all the methods?

Integrating that liblsl asio loop with the .NET loop will be… interesting. Async methods will make it a lot easier for users, but I'm not sure how to implement them efficiently.

Another thing on my wishlist would be to get rid of the c-style array handling. I feel that pull_sample/chunk should return an IReadOnlyList instead of void. These two things taken together could be a whole other wrapper.

It's not very ergonomic, but efficient. I think the best way to handle this would be a plain liblsl wrapper (basically, as it is now) and another wrapper that offers a nice interface.

I don't think we need to worry too much about people wanting to target .NET framework < 4. If need be, they can switch the target in the LSL project. I don't see anything too contemporary in there.
For the ASIO thing, this is precisely what modern .NET is good at. Nearly all async methods call other async methods so I don't see liblsl using boost/asio underneath as a conflict---rather a compliment---to using async. It really is just as simple as wrapping a function in a Task.Run lambda.
To me it also makes sense to wrap pull_sample (and even more especially resolve_streams) into async methods because it is a very convenient way to kick off a method that handles samples as they come in in the background. When a C# method hits await, it returns control to the caller. Then, anything that happens after await will kick off automagically once the task is complete:
private async Task PullAndProcessAsync()
{
    await Task.Run(()=>pull_sample(...));
   // at this point the caller is back on
   ProcessNewData(...);
}

Waiting on IO is exactly what async methods that return Task are meant for. CPU intensive tasks are meant to return Task. This also goes hand in hand with leaning on C# to handle allocating buffers and collecting garbage instead of the C-style array arguments for the output from pull_sample/chunk.
I am not sure if the best thing to do is to leave this library as it is and simply add a class that wraps everything in async methods, or just to roll a new wrapper. People are already using this one, but it is rather 2009.

For the ASIO thing, this is precisely what modern .NET is good at.

Well, yes and no. Ideally, it would be integrated somehow so it would at most need one thread to run the asio event loop and return control to the task with available data. The Task approach works, but (as far as I can see, please correct me) still uses one OS thread per inlet.


move sampler and pesterv5 into main

This is the first attempt to move the new way of working into the main branch
Ultimately, this will bring the new sampler build and deploy process, the pester V5 checks into preview and the dev container.
Lets see what we get right now

Invoking BDFL privileges!


Alert styling is off when used inside AboutModal

I'm seeing a padding/styling issue when I use Alert inside an AboutModal:

I think it's caused by .pf-c-content targeting the h4s. We need to use Alert like this in OpenShift -- any chance you guys can take a look?

@rebeccaalpert I wouldn't expect you to nest an alert inside of the content component. In that case, I would expect to use a content component followed by the alert, followed by another content component.

I think PF4 React places all of the children in a .pf-c-content div automatically. I don't see a way to override that as-is. Should I be opening an issue with patternfly-react instead?

I think so. @mcarrano is nesting the alert in the about modal like in the screenshot supported? If so do you agree that a user should be able to put any component they want in the body of the about modal, and if they want normal heading/paragraph/list/etc styling, they would explicitly use the content component?

Something else worth noting is that if you nest a content component and an alert (or any type of component) in the content area of the about modal, there will be no spacing between those components by default. You would need to use a layout, like a flex column layout or margin/padding utility classes to create the spacing.
A way we could support default spacing there would be to add a "body" element to the about modal box content area that could hold one or more components, and we create vertical space between those body elements. We do something similar for the card with multiple card bodies.

@mcoker @rebeccaalpert This is not something we support from a design standpoint. What is the use case here? The About modal was not intended to communicate dynamic content like this. If this is a requirement, then we should take a step back and consider how to communicate alerts and messages from within the About dialog

@mcarrano UX made these designs related to cluster updates. @bmignano, would you be able to speak to the use case?

@mcoker @mcarrano We designed this awhile back with @maryshak1996 and @kybaker. Kyle, can you chime in here? It was my understanding we could use inline notifications inline on a page or modal. Is that not the case?
It isn't a huge deal, but we felt it was good to show the available update next to places where the current version is listed since it's an important action to take that results in a version change.

@mcarrano I think it is totally valid to put an inline notification or other form elements here. I supect this just comes down the the way we are using the CSS. Could we allow the about to function like any other modal?

We could. But it was not something we considered during the initial design. I'll defer to @mcoker on what would be required to make this work. Is a change to the core CSS required?

@mcarrano the most simple fix is a react change so that you can put any type of content in the body of the modal. Currently the react component nests everything you specify in the body in a Content component. That wouldn't require an update in core, other than updating our documentation to remove the content component from the list of components used to construct the about modal.
I think they could do that on the react side by adding a prop that makes the component not nest the body content in a Content component. Though I think long-term, we might want that to be the default (like the Modal), so that if you want to use the Content component, you just pass that in with your body content.
@rebeccaalpert do you want to open an issue on the react side?

Yeah, no problem. Should I close this one or leave it open for the doc change?

@rebeccaalpert thanks! Let's leave this one open.

:tada: This issue has been resolved in version 2.6.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't enable climate in domoticz

Hello, on domoticz, I can set temperature but can't activate clim ( Marvel R )
"Error sending switch command, check device/hardware (idx=95) !"
Logs :
2024-02-25 11:41:18.593 Error: MQTT Disovery: climate device unhandled mode_state_template (***_vehicle_climate/MG Marvel R (Climatisation))

Is the log from domoticz? Or the python gateway?
I'm not a domoticz so I cannot help too much

Seems like domoticz doesn't support value templates in YAML format, but still honors the home-assistant auto configuration messages.
I'd suggest rasing a ticket to domoticz

Seems like domoticz doesn't support value templates in YAML format, but still honors the home-assistant auto configuration messages.
I'd suggest rasing a ticket to domoticz
Here's the auto-configuration message sent to the relevant topic
{
  "name": "Vehicle climate",
  "device": {
    "name": "MG MG4 Electric <VIN>",
    "manufacturer": "MG",
    "model": "MG4 Electric 2022 BLACK PEARL",
    "hw_version": "EH32 S",
    "identifiers": [
      "<VIN>"
    ]
  },
  "unique_id": "<VIN>_vehicle_climate",
  "object_id": "<VIN>_vehicle_climate",
  "availability": [
    {
      "topic": "saic/_internal/lwt",
      "payload_available": "online",
      "payload_not_available": "offline"
    },
    {
      "topic": "saic/<EMAIL>/vehicles/<VIN>/available",
      "payload_available": "online",
      "payload_not_available": "offline"
    }
  ],
  "availability_mode": "all",
  "precision": 1.0,
  "temperature_unit": "C",
  "mode_state_topic": "saic/<EMAIL>/vehicles/<VIN>/climate/remoteClimateState",
  "mode_command_topic": "saic/<EMAIL>/vehicles/<VIN>/climate/remoteClimateState/set",
  "mode_state_template": "{% if value == \"on\" %}auto{% else %}off{% endif %}",
  "mode_command_template": "{% if value == \"auto\" %}on{% else %}off{% endif %}",
  "modes": [
    "off",
    "auto"
  ],
  "current_temperature_topic": "saic/<EMAIL>/vehicles/<VIN>/climate/interiorTemperature",
  "current_temperature_template": "{{ value }}",
  "temperature_command_topic": "saic/<EMAIL>/vehicles/<VIN>/climate/remoteTemperature/set",
  "temperature_command_template": "{{ value | int }}",
  "temperature_state_topic": "saic/<EMAIL>/vehicles/<VIN>/climate/remoteTemperature",
  "temperature_state_template": "{{ value | int }}",
  "min_temp": 17,
  "max_temp": 33
}

Lemme try with home assistant ;) thanks

Confirmed, work with home assistant, sorry for disturb


Stopped working 7.2-11

This appears to have stopped working as of 7.2-11.

thanks for the report @shinji257 should be working now on Proxmox VE 7.2-11

works again
thank you


Wizard.CastSpell(WizardSpells.License, "MIT")

Closes #26

Closing this - a different commit added this AND added it to the develop branch.

If I had remembered that you had submitted this pull request I would have used it instead. :) I got crazy busy at work and dropped this project altogether. I'm on vacation this week so I thought it would be fun to try to work through the remaining issues in the catch-up release.  However, enough time had passed that I'd forgotten the status of PR's until after I'd worked through the remaining issues in the milestone.

It's NP at all :)


SurveyJS as nested resources form

Are you requesting a feature, reporting a bug or ask a question?
question
What is the current behavior?
I am using surveyJS as a nested resources form exploiting its ability to dynamically add nested questions/resources. I am forced to complete a survey in order to send the data to the server
What is the expected behavior?
I'd like to send data to the server (save the survey) whenever I like and give a feedback to the user without change the state of the survey, I need to keep it rendered with data. I don't actually need the state at all in my use case

mmm ... maybe through completeLastPage function can do something.

@masciugo You have to call clear method on onComplete event
For example:
survey.onComplete.add(function (survey, options) {
  //save your data if needed.
  survey.clear(false, true); //set the state to running, keep the data and go to the first page
});

Thank you,
Andrew

I switched from react to jquery and cannot apply the same solution with success
https://plnkr.co/edit/gEzrkytROkSm0g50WbZj?p=preview

@masciugo Please add survey.render(); function: https://plnkr.co/edit/TYCOmTA4wStEz6ZfDb79?p=preview
Thank you,
Andrew


fix(): update default preview config to 'border' from 'float'.

Was throwing the following:
[Fzf-lua] fzf error 2: invalid preview window option: float
Now matches the docs.

Ty for fixing it! I’m not near the comp and couldn’t fix it rn :)
On another note, did you try the new 'float' scrollbar? If you did, which one do you prefer?

to be honest, i never used the scrollbar before in the preview window. the addition of the float option slowed down preview rendering big time for me, soooo, i turned it off.


Should future::zip drop completed futures?

I have found some strange and unexpected behavior with functions like future::zip and future::race when used together. I always expected that some future and async { future.await } should behave the same. But I realized that this is not the case.
Minimal code example:
use smol::{
    channel::{Receiver, Sender},
    future,
};

async fn product(tx: Sender<u32>) {
    for i in 0..20 {
        if tx.send(i).await.is_err() {
            break;
        }

        println!("sent {i}");
    }
}

async fn consume(n: u32, rx: Receiver<u32>) {
    println!("start task #{n}");
    while let Ok(i) = rx.recv().await {
        if i == 5 {
            println!("exit");
            break;
        }

        println!("received {i}");
    }
}

// Create a channel with minimum buffer size to reproduce the problem more clearly
let (tx, rx) = smol::channel::bounded(1);
let a = consume(1, rx.clone());
let b = consume(2, rx);

let tasks = future::race(a, b);

smol::block_on(future::zip(product(tx), tasks));

If you run this code it will stuck.
My expectation is once one of the tasks completes, it will end the entire race and drop all receivers. Then the sender will see its receivers have been dropped, then it will exit its loop and will drop with completing the entire zip. But it seems that it doesn't work because zip doesn't drop its futures until all of them are completed.
But I can wrap tasks in an additional future like this:
- let tasks = future::race(a, b);
+ let tasks = async { future::race(a, b).await };

And now it works as expected. After one task completes, all others complete after and the code no longer stucks.
However, I think it's not intuitive. It would be better if zip will drop completed futures itself.

I will accept a PR to fix this.


Issue #958 Use the same modified UTF-8 encoding as DataInput/OutputSt…

…ream for string encoding

Might break persistent cache storage - waiting for @chrisdennis to test compatibility between the two.


fix: In api QEval, need to trim ending whitespace from the result

A recent commit in gnolang/gno adds "\n\n" to the QEval result.

Close as not needed.


feature: add function GetAsString for SyncMap

Signed-off-by: Starnop<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #532 into master will decrease coverage by 0.08%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #532      +/-   ##
==========================================
- Coverage   53.67%   53.59%   -0.09%
==========================================
  Files          83       83
  Lines        4337     4344       +7
==========================================
  Hits         2328     2328
- Misses       1856     1863       +7
  Partials      153      153

Impacted Files
Coverage Δ

common/util/sync_map_util.go
25.3% <0%> (-2.34%)
:arrow_down:

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 5b46861...bd18c86. Read the comment docs.

LGTM


chore: bump node-ca-watcher tag

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 71.109%

Totals

Change from base Build<PHONE_NUMBER>6:
0.0%

Covered Lines:
2577

Relevant Lines:
3624

💛  - Coveralls

Overwriting the e2e check, seems to be flaky - across runs, all test cases have passed.


Can I run the code with only CPU?

Hello,
When I tried to do the sh make.sh, I got the error:
g++: error: Hypothesis.o: No such file or directory
hough_voting_layer
make.sh: 67: make.sh: nvcc: not found
g++: error: roi_pooling_op.cu.o: No such file or directory
roi_pooling_layer
make.sh: 77: make.sh: nvcc: not found
g++: error: triplet_loss_op.cu.o: No such file or directory
build triplet loss
make.sh: 87: make.sh: nvcc: not found
g++: error: lifted_structured_loss_op.cu.o: No such file or directory
build lifted structured loss
make.sh: 97: make.sh: nvcc: not found
g++: error: computing_flow_op.cu.o: No such file or directory
build computing flow layer
make.sh: 107: make.sh: nvcc: not found
g++: error: backprojecting_op.cu.o: No such file or directory
build backprojecting layer
make.sh: 117: make.sh: nvcc: not found
g++: error: projecting_op.cu.o: No such file or directory
build projecting layer
make.sh: 127: make.sh: nvcc: not found
g++: error: computing_label_op.cu.o: No such file or directory
build computing label layer
Those errors indicate that I need to have CUDA installed. That said, my machine does not have a dedicated GPU. Because tensorflow has a CPU-only version, I was wondering if I can also run this code without CUDA.
Thanks!

I meet the same problem with you, have you found a solution?
Thanks!

Hello @niwanli @YantianZha ,
Got the same Errors ->

installed Cuda 9.0 (Tensorflow requires 9.0!)
https://developer.nvidia.com/cuda-90-download-archive?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1604&target_type=deblocal
1.1 Add with nano ~/.bashrc the following line: export PATH=/usr/local/cuda-9.0/bin${PATH:+:${PATH}}

then install cuddn https://developer.nvidia.com/rdp/cudnn-download2.3.2. Installing from a Debian File
Navigate to your  directory containing cuDNN Debian file.
Install the runtime library, for example:
sudo dpkg -i libcudnn7_<IP_ADDRESS>-1+cuda9.0_amd64.deb
Install the developer library, for example:
sudo dpkg -i libcudnn7-dev_<IP_ADDRESS>-1+cuda9.0_amd64.deb
Install the code samples and the cuDNN Library User Guide, for example:
sudo dpkg -i libcudnn7-doc_<IP_ADDRESS>-1+cuda9.0_amd64.deb

now it should work. And i would recommend you to work with virtualevn.

hi， @Luedeke  I tried your method and still reported such a mistake..

@yuzw213 I'm sorry, but then I can't help you either.


Fix world map editor

This fixes the save feature of the world map editor, and makes it use a modded world_map.png if it exists.
Previously the editor would save everything upside down.

Do not merge, this isn't fixed yet apparently


namespace services by server, not by client

Previously it was possible to start a dependent service in one module API call, and then use it again in a later call, only to have it fail because it cannot resolve the service address, even though it's still running. This happened because each invocation has its own client ID, and client IDs were used to build service addresses. (Repro)
This change brings service addresses into alignment with the recent change to uniq them by service ID instead of client ID. The overall effect is that services are deduped within a Dagger invocation, even across module calls. So with this change, the service will just stay running and be re-used by a later call, thanks to the grace period.

The right tests are failing - I was wondering whether they depended on this behavior. Will check back on this later and see what needs to change.

I took a look at the failures because this felt like it might overlap with what I'm working on right now to finish isolating sessions to each client.
Not 100% sure but the failures might be due to the fact currently nested execs get their own servers (whereas function execs are special cased to reuse the same server). That seems like it could explain the errors.
If so, fortunately part of the changes results in those nested execs sharing the same server (among a lot of other simplifications). I'll see if I can cherry-pick your commit here and test it out.

@sipsma Haha yeah that sounds like exactly it, what a nice coincidence!

@vito yeah those tests pass with my changes included. Unfortunately my changes won't be safe to merge until I finish up more of it, but I sent out a draft PR here https://github.com/dagger/dagger/pull/6916

This ended up getting cherry-picked into https://github.com/dagger/dagger/pull/7213 due to codependence between different changes, so closing out as it's merged


Revert openblas linking changes from #451

PR #451 introduced linking against both OpenBLAS and LAPACKE+Accelerate on arm macOS, which breaks re-compilation of certain user programs (like Shor's). The cause of the shared library conflict is unknown.
For now, we revert these linking changes, which were originally introduced due to Lightning not finding its OpenBLAS dependency when invoked through Catalyst:
FAILED frontend/test/pytest/test_measurements_shots_results.py::TestExpval::test_hermitian[lightning.qubit]

RuntimeError: [pennylane_lightning/core/src/utils/SharedLibLoader.hpp][Line:60][Method:SharedLibLoader]: Error in PennyLane Lightning: dlopen(libscipy_openblas.dylib, 0x0001): tried: 'libscipy_openblas.dylib' (no such file), '$ORIGIN/../scipy_openblas32/lib/libscipy_openblas.dylib' (no such file)

The above test will fail as a result of this, which we plan to fix with a PR on the lightning side.
[sc-80803]

@dime10 there were some documentation changes to reflect support for finite shot measurements of hermitian observables. If this comes into effect, we should also revert those documentation changes.

@dime10 there were some documentation changes to reflect support for finite shot measurements of hermitian observables. If this comes into effect, we should also revert those documentation changes.

Well in theory they are supported simply by upgrading the version of lightning (which will be forced by next release anyway) 🤔 The original PR had no functional changes on the catalyst side besides the erroneous linking.
We could consider it a known issue on macos that the lapack libs may clash, and try to resolve it in a follow up?

We could consider it a known issue on macos that the lapack libs may clash, and try to resolve it in a follow up?

Having said that it might not be possible to merge this if the failure is reproducible in the CI.

Just waiting on the lightning wheels to become available and we should be able to merge this!


Feat: end-to-end-security demo

This is a demo showcasing a bank scenario using as much security as possible :)
Documentation
part of:  https://github.com/stackabletech/issues/issues/530
needs https://github.com/stackabletech/release/pull/29

Can you please include a link to the documentation on this?

Linked the docs in the description (it needs to point to nightly docs)

The docs are a bit thin.
Especially under accessability aspects does it not contain any textual description of at least the stack.
Can I please ask you to extend it to include more details on what is contained in the demo?

This is waiting for https://github.com/stackabletech/demos/pull/49


python3Packages.snapcast: 2.1.1 -> 2.1.2

Motivation for this change
Update to latest upstream release 2.1.2
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 116562 run on x86_64-linux 1

2 packages built:

python38Packages.snapcast
python39Packages.snapcast

Result of nixpkgs-review pr 116562 at afb692eb run on aarch64-linux 1

2 packages built successfully:

python38Packages.snapcast
python39Packages.snapcast


libsidplayfp: init at 1.8.6

Motivation for this change
audacious uses it to play old commodore 64 files (https://github.com/NixOS/nixpkgs/pull/17543).
Things done

[x] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

If the documentation is big, consider putting it in its own output. Then, I think you could also build it unconditionally.

It was 198 graphviz dot files so I just didn't want to process those for such an obscure library... But ok; I moved the resulting 7.7MB docs to their own output and enabled the docs by default.

If the docs are worth having, it'd be annoying for a user to have to build it themselves to get them (and by extension, rebuild all reverse depenedencies), as opposed to just pulling in an additional output.

np. it was just switching false -> true anyhow since I've done all the work already ;)

What is the use case for disabling the docs? I'd build them unconditionally. If you prefer it this way, I guess that's fine though.

What is the use case for disabling the docs?

It's for maintenance. If I can't compile it fast enough, I won't update the package when a new version is released.

@fpletz Thanks!


Bug: lldb no longer auto completes

Describe the bug
At least in BwB (I have to verify in BwX), lldb no longer has any auto completion.
Versions

Bazel: 14.0.1
rules_xcodeproj: beed7163ea6168d228baeb5fd8060b0ea62216a6

I'm not seeing this anymore. Hmm.
@chiragramani Can you let me know if you still see this, and what the repro steps are?

I was able to reproduce this yesterday when I was adding a few tests to the generator. Steps:

Open the project generated by bazel run tools/generator:xcodeproj.
Put a breakpoint in any of the tests.
When the breakpoint is triggered, po variable.<some property name> - the UI shows no auto-completions but the expression evaluation works all fine.

Yeah, I have autocomplete there now 😕.

Oh okay, I tried on the latest main - sharing the exact test-case.

It works fine for me now. I feel embarrassed that I forgot to apply the clean up drill before :)

Yeah, I think it was an issue in Derived Data. Apparently that completion list comes from Xcode, so I bet indexing data drives it. Maybe there was a weird indexing mix up.


Remove dependency on primesieve

Refs #1133
Additionally, the code is now 100x faster and finds better solutions
in some cases. That's why the tests are adjusted.
Contributor Checklist:

[x] I have added or updated my entry in the creators.json file
[N/A] I have added a changelog entry for my contribution
[N/A] I have added/updated documentation for all user-facing changes
[x] I have added/updated test cases
[N/A] I have included the rebuilt production build of the client (only if changes were made to the GUI)

Reviewer Checklist:

[-] /azp run libertem.libertem-data passed
[x] No import of GPL code from MIT code

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

The test failure looked like an issue with our CI setup (full /dev/shm) - I guess we do need to restart the agents after some time...

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

/azp run libertem.libertem-data

Sorry for the comment spam, there were multiple issues with the CI setup, and some new issues caused by a sphinx release last week...

/azp run libertem.libertem-data

Note: also included a workaround for the ncempy issue, so CI now passes.

/azp run libertem.libertem-data


Fixes available options for mode in the hamming loss function.

Description
Brief Description of the PR:
Fixes available options for mode in the hamming loss function docstring.
Type of change

[ ] Bug fix
[ ] New Tutorial
[x] Updated or additional documentation
[ ] Additional Testing
[ ] New Activation and the changes conform to the activation contribution guidelines
[ ] New Callback and the changes conform to the callback contribution guidelines
[ ] New Image addition and the changes conform to the image op contribution guidelines
[ ] New Layer and the changes conform to the layer contribution guidelines
[ ] New Loss and the changes conform to the loss contribution guidelines
[ ] New Metric and the changes conform to the metric contribution guidelines
[ ] New Optimizer and the changes conform to the optimizer contribution guidelines
[ ] New RNN Cell and the changes conform to the rnn contribution guidelines
[ ] New Seq2seq addition and the changes conform to the seq2seq contribution guidelines
[ ] New Text addition and the changes conform to the text op contribution guidelines

Checklist:

[x] I've properly formatted my code according to the guidelines

[x] By running Black + Flake8
[ ] By running pre-commit hooks

[ ] This PR addresses an already submitted issue for TensorFlow Addons
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] This PR contains modifications to C++ custom-ops

How Has This Been Tested?
If you're adding a bugfix or new feature please describe the tests that you ran to verify your changes:
*

@ssaishruthi
You are owner of some files modified in this pull request.
Would you kindly review the changes whenever you have the time to?
Thank you very much.

Hey @SSaishruthi.
There is an error on the checks unrelated to the PR change.
ImportError: cannot import name 'Config' from 'pytest'

It might be related to having init.py in the tests folder:
https://stackoverflow.com/questions/41748464/pytest-cannot-import-module-while-python-can
Do you confirm?


Add neofetach.md

Add command: neofetach Neofetch is a command-line system information tool written in bash 3.2+. Neofetch displays information about your operating system, software and hardware in an aesthetic and visually pleasing way. For https://github.com/dylanaraps/neofetch

好吧，从现在开始合并流行的命令工具吧。


Create SASS version

I recommend to switch to Sass only, as the Bootstrap etc. did. Also the PostCSS might be a good way.

I'm doing this in LESS first because there aren't any good ones in less and for example where I work we use less and I do see your point but the outcasts need grids too :p
I intend to do a SASS and postCSS version, when I start the PostCSS version I'll see what people tell me are the best ways to accomplish that :)


element-ui的table组件使用sortable进行列排序，导致整个网页无法选中

Problem:

https://github.com/elo7/Sortable/commit/b11d38a73d594423ccf12dcbe9838baf12840683
_on(ownerDocument, 'pointerup', _this._onDrop);  这句话删除导致的
JSBin/JSFiddle demonstrating the problem:

Before you create an issue, check it:

Try master-branch, perhaps the problem has been solved;
Use the search, maybe we already have an answer;
If not found, create an example on jsbin.com (draft) and describe the problem.

Bindings:

Angular

2.0+: https://github.com/SortableJS/angular-sortablejs/issues
legacy: https://github.com/SortableJS/angular-legacy-sortablejs/issues

React

ES2015+: https://github.com/SortableJS/react-sortablejs/issues
mixin: https://github.com/SortableJS/react-mixin-sortablejs/issues

Polymer: https://github.com/SortableJS/polymer-sortablejs/issues
Knockout: https://github.com/SortableJS/knockout-sortablejs/issues
Meteor: https://github.com/SortableJS/meteor-sortablejs/issues

Please post in English


LNDG Automated channel rebalancing not working:

Hi,
we have been using the LNDG app in Umbrel for awhile now and love the user interface and use it often to maintain our node but we have never been able to get it to function as an auto rebalancer no matter what the combination we try, even when the sat amount is very low and the other tabs are also set low etc,,, Please help.  Thank you :)

Hi @BonzoDogDooDah, have you set AR to true in the UI?

Check the /rebalancing page to help visualize what channels are being used for Out/In and verify you have at least one Out and one In channel.
Also check the AR Max Fee Rate is high enough to rebalance your channels. The default is 100 ppm and many channels require a higher fee than this to rebalance. This value is a global cap for all rebalances.


Jitsi meet sdk upgrade

Pull Request Checklist

[x] Pull request is based on the develop branch
[x] Pull request updates CHANGES.rst
[x] Pull request includes a sign off

Thanks @adrian007n for this PR. Closing this, so that it looks like done in https://github.com/matrix-org/matrix-ios-sdk/pull/958


Added zoom & custom plot parts & coordinate conversion

Added zoom feature for XYCharts
Fixes #234
Partially implements #216
Zoom can be reset by double click or reset button. Both can be disabled.
See TestForSelectionZoom.java

Added coordinate conversion.
Given mouse point (x,y) returns chart values (x,y)
Given value (x,y) returns chart pixel values (x,y)
Fixes #263
Issuses

Logarithmic values does not work
In BarCharts returns absolute x values, not indices.
Does not work in Pie, Radar, Dial charts
See TestForCoordinateLookup.java

Added custom plot parts system.

Added ChartButton
Added ChartImage
Added ChartLine
Added ChartText

Fixes #288, fixes #281, fixes #212
See TestForCustomChartParts.java

@timmolter can you check when you have time please?

@hakantkn Yes, sorry. It slipped through the cracks...


Unable to connect to the extension services. Click here to check possible reasons.

Hi. I was not able to use the plugin.
I get error "Unable to connect to the extension services. Click here to check possible reasons."
I'm running it on windows. Is there any way I can troubleshoot? I have checked the port is not occupied by any other applications. Once I click refresh on the codegpt chat page, the port is shortly taken by codegpt and then released in seconds. The extension host logs shows the operation by codegpt is cancelled.

restarting the computer fixed it


Starred messages filter / feature

Now this is not technically a bug, but more of a UX issue / feature.
The Global Settings / Show Stars option works as it should, in that it disables or enables 'stars' or 'flags' in the message list pane.
However, it also enables / disables the star icon in the folder list pane, which filters the messages to only show starred messages.
My problem with that functionality is the following: I like being able to see dozens of messages at once in the message list pane, by decreasing font-size and putting sender and subject on one line (and disabling message preview lines to 0). However, if stars are enabled, they always take up 2 lines, irrespective of the other settings.
Either of the following two fixes for this problem would be amazing to me:

Always retain the option in the folder list to view only starred items, or
Create 2 separate options to allow control of 'view stars' in list, folder view, or both,
Reduce the size of the star icon in the message list view so it doesn't take up so much space if message_preview = 0,

I know it's a small niggle that might not bother many others, but I love k-9 and this would make it even better!
Great work all around in any case, A class email app!

This will most likely change in the future anyway. My current plan is to remove the number of starred messages from the folder list. In turn filtering messages in the message list will become easier.

Awesome, thanks cketti, that would be great!

Continued as #4330


Decide on deprecation strategy

The current plan is to develop the new TUF alongside the old TUF (see #1126).
How long after the refactor is complete will we continue to support the old code base? What does support look like? Bug fixes? Security fixes? We need a roadmap there. The main reason to keep the old code base around is to have a client that supports Python 2.7 (see  #1125). Not sure if this is a good reason for very much longer.
Independently of the refactor, we might generally want to think of a deprecation strategy for the future. E.g. do we want to display deprecation warnings for n releases before we drop interface functions? This probably only makes sense if we follow a stricter release schedule than we do now.

There's also a difference between accepting bug and security fixes, and making releases that include them, and actually fixing bugs and addressing security issues.
I don't think we have the resources to maintain two versions of the codebase, so I'd like us to end up on a path that means that once the refactor is complete we delete the old code and forget about it ASAP.
I'm absolutely in favour of defining and adhering to a stricter release schedule and having a deprecation strategy so that we aren't removing API without warning.

I agree that we want to focus our efforts on the new code. I'd propose that we continue to review bugs and security fixes for some period of time (maybe a year), and possibly contribute security patches during this time. Then, if anyone still really needs that code, they could fork and maintain themselves so that we can focus on the new version.

I'm absolutely in favour of defining and adhering to a stricter release schedule and having a deprecation strategy so that we aren't removing API without warning.

Even if we don't have a strict schedule, we should have some way to communicate to users when the API will change (maybe something like tap 14, but for the API)

I think we need both a deprecation strategy for the current release series (particularly as we expect the refactor to do away with support for older Python versions), and a deprecation/API stability strategy for releases after the refactor.
For the current release series, I think what would make most sense is to focus any maintenance efforts on the client. That is the piece of the current series which is most difficult to upgrade (repository owners can switch to Python3 easily but might not be able to influence repository users to make the same upgrade).
One strategy for the client might be to create a branch of the repository which removes all of the non-client code and commit to maintain that for at least one year. I'd propose the maintenance strategy clearly define expectations:

that we will review any functional bug and security fixes proposed to the branch (PRs)
that severe security issues and functional bugs will be addressed on a best effort basis
that we will release updates with any generated fixes in a timely fashion

I think it might also make sense to have that branch produce a separate PyPI package for the Python2 supporting client which is clearly marked (on PyPI) as not actively adding new features and only supporting Python 2.7.

I think we need both a deprecation strategy for the current release series (particularly as we expect the refactor to do away with support for older Python versions), and a deprecation/API stability strategy for releases after the refactor.
For the current release series, I think what would make most sense is to focus any maintenance efforts on the client. That is the piece of the current series which is most difficult to upgrade (repository owners can switch to Python3 easily but might not be able to influence repository users to make the same upgrade).
One strategy for the client might be to create a branch of the repository which removes all of the non-client code and commit to maintain that for at least one year. I'd propose the maintenance strategy clearly define expectations:

that we will review any functional bug and security fixes proposed to the branch (PRs)
that severe security issues and functional bugs will be addressed on a best effort basis
that we will release updates with any generated fixes in a timely fashion

pip's deprecation of Python 2.7 phrases this quite nicely

bugs reported with pip which only occur on Python 2.7 would likely not be addressed directly by pip’s maintainers. Pull Requests to fix Python 2.7 only bugs will be considered, and merged (subject to normal review processes). Note that there may be delays due to the lack of developer resources for reviewing such pull requests.

Agreed. We have finite resources, and this is a reasonable policy.

a deprecation/API stability strategy for releases after the refactor.

Does anyone have any opinions on API stability/deprecation policy?
Python has a policy of annual releases (PEP 602) with a promise of "at least two releases before a deprecated feature is removed from Python or a __future__ behavior is enabled by default."
I don't think that's an exact model for us to follow, two years sounds like a long time for a small team to maintain deprecated API. However, waiting at least a couple of releases with the API being marked as obsolete/deprecated before it's actually removed seems reasonable.
That does somewhat require us to have decent, online documentation which our users might read these obsoletion notifications in (see #1053, should probably move that into the 1.0 project board).
Related to a proposed deprecation policy, we might also want to think about release schedule:

Do we anticipate major releases of the reference implementation being tied to a major release of the specification? If yes, that would tie our major releases to the specification. We don't expect the specification major version to change often.
How frequently do we expect to make non-major releases?  With the frequency dependabot PRs I think we should strive for regular releases, even if they are only patch releases which bump pinned dependencies. Our extremely outdated ROADMAP.md suggests we will release every 3 months. It seems reasonable to strive for releases at least every three months, with more frequent releases when we have changes to release, or more urgent fixes.

I think we have three questions to answer and document:

what's our proposed release schedule? or at least our worst case release scenario i.e. a release at least once every 3 months, to include dependency updates.
what's our proposed API stability/deprecation policy? i.e. API to be marked as obsolete and not removed for at least two significant releases after the release where it is first marked obsolete (where significant releases are major or minor, not patch).
what's our release versioning strategy? will we tie major version to specification versions? If yes, we might confuse users unless we also match minor version – why does python-tuf 1.2.3 implement TUF specification 1.0.15?

Do we anticipate major releases of the reference implementation being tied to a major release of the specification?

This sounds like possibly a bad idea. You already mentioned the confusion on minor number, but also: Software version should reflect changes in the software. Major changes to the software may be required without any changes to the spec.
Also, as a thought exercise I can imagine a spec revision that is in some way incompatible with previous version, but that the following python-tuf releases supported both versions of the spec in some manner (like possibly the client could work as spec v1 client and spec v2 client).

what's our proposed release schedule?

Does this need to be documented? Your proposal of "Planned maximum release cadence of 3 months" sounds good but as you said this follows from dependency changes so could change over time...

what's our proposed API stability/deprecation policy?

This is very tied to the question what is our API? Currently this is not really defined and then it's quite hard to make promises about supporting the API... This also ties into publishing the documentation: I like some level of documentation for all functionality but once it's on readthedocs or something, the internal functionality should be clearly marked as such if it's published at all.
Sorry, no great answers to the actual question...

Do we anticipate major releases of the reference implementation being tied to a major release of the specification?

This sounds like possibly a bad idea. You already mentioned the confusion on minor number, but also: Software version should reflect changes in the software. Major changes to the software may be required without any changes to the spec.
Also, as a thought exercise I can imagine a spec revision that is in some way incompatible with previous version, but that the following python-tuf releases supported both versions of the spec in some manner (like possibly the client could work as spec v1 client and spec v2 client).

👍

what's our proposed release schedule?

Does this need to be documented? Your proposal of "Planned maximum release cadence of 3 months" sounds good but as you said this follows from dependency changes so could change over time...

Perhaps not. The reason I suggested it is because I thought that promising to not remove deprecated API for two releases probably isn't very meaningful unless those release map to some notion of time. If we make two releases in two weeks, then remove the deprecated API that won't be very useful. Maybe this just indicates that any deprecation policy should include a notion of time?

what's our proposed API stability/deprecation policy?

This is very tied to the question what is our API? Currently this is not really defined and then it's quite hard to make promises about supporting the API... This also ties into publishing the documentation: I like some level of documentation for all functionality but once it's on readthedocs or something, the internal functionality should be clearly marked as such if it's published at all.

Which suggests we might want to consider this before 1.0, where the deprecation policy would apply, but after we've done some more of the development work and have a better idea of what we're committing to.

Part 1 of this issue (deprecation of "legacy" implementation) has been formalized in ADR 2 and finalized with the release of 1.0.0.
Do we want to have a written statement for future deprecation? (see 2nd paragraph in issue description above)

I think we should have a deprecation strategy where warnings are added (at least to release notes) before the change... But it's not something I would document very strictly: API removal/change situations are so different and hard to estimate.
In other words I'm not sure if we can be more specific than "we aim to not break existing code without warning at least a release before". That feels like what any reasonable 1.0 library would do so maybe it doesn't need to be stated?

Agreed. I think the commitment to semver along with an initial stable release already goes a long way.

Maybe @joshuagl also wants to weigh in? Otherwise I suggest to close this issue.

Let's file a new, more specific, issue if we decide we want to change anything.


⚠ Bofrost.at has degraded performance

In 673b246, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 3233 ms

Resolved: Bofrost.at performance has improved in b6cd9e1 after 13 minutes.


Avoid redundant HEAD requests for identical layers on push

pushV2Tag already deduplicates layers, but the scope of this
deduplication is only for a particular tag. If we are pushing all tags
in a repository, we may check layers several times. Fix this by moving
the layersSeen map from the pushV2Tag function to the v2Pusher struct.
In addition to avoiding some useless round-trips, this makes the "docker
push" output less confusing. It formerly could contain many repeated
lines like:
124e2127157f: Image already exists
124e2127157f: Image already exists
...

Add test coverage based on the "docker push" output: a hash should not
appear multiple times when pushing multiple tags.
Fixes #14873
Signed-off-by: Aaron Lehmann<EMAIL_ADDRESS>

@dmcgowan @stevvooe PTAL

LGTM

LGTM after doc fix.

Fixed the comment, thanks for the review.

Thanks @aaronlehmann!
Waiting on CI: feel free to merge once green.


feat: expose connection options for sql meta store

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
It would benefit shared clusters in the rw cloud. To utilize a single RDS for a free-tier/standard cluster without impacting its performance, we can manually configure it.
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Shall we cherry-pick the PR to 2.1 release?

Shall we cherry-pick the PR to 2.1 release?

Yes sure.

Shall we cherry-pick the PR to 2.1 release?

Yes sure sir.

Passion!


Error when using MPS: "Expected elements.dtype() == test_elements.dtype() to be true, but got false."

Self Checks

[X] This template is only for bug reports. For questions, please visit Discussions.
[X] I have thoroughly reviewed the project documentation (installation, training, inference) but couldn't find information to solve my problem. English 中文 日本語 Portuguese (Brazil)
[X] I have searched for existing issues, including closed ones. Search issues
[X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
[X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
[X] Please do not modify this template and fill in all required fields.

Cloud or Self Hosted
Self Hosted (Source)
Environment Details
macOS = 15.2 (Apple M3), python = 3.10, torch=2.4.1
Steps to Reproduce

run the command python tools/api_server.py

✔ Expected Behavior
The server starts using MPS
❌ Actual Behavior
If use MPS:
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/torch/amp/autocast_mode.py:265: UserWarning: User provided device_type of 'cuda', but CUDA is not available. Disabling
  warnings.warn(
INFO:     Started server process [98040]
INFO:     Waiting for application startup.
2024-12-27 15:43:48.722 | INFO     | tools.server.model_manager:__init__:41 - mps is available, running on mps.
2024-12-27 15:43:57.305 | INFO     | tools.llama.generate:load_model:682 - Restored model from checkpoint
2024-12-27 15:43:57.306 | INFO     | tools.llama.generate:load_model:688 - Using DualARTransformer
2024-12-27 15:43:57.312 | INFO     | tools.server.model_manager:load_llama_model:100 - LLAMA model loaded.
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/vector_quantize_pytorch.py:445: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/vector_quantize_pytorch.py:630: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/finite_scalar_quantization.py:147: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/lookup_free_quantization.py:209: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
2024-12-27 15:43:58.504 | INFO     | tools.vqgan.inference:load_model:43 - Loaded model: <All keys matched successfully>
2024-12-27 15:43:58.505 | INFO     | tools.server.model_manager:load_decoder_model:108 - Decoder model loaded.
2024-12-27 15:43:58.517 | INFO     | tools.llama.generate:generate_long:789 - Encoded text: Hello world.
2024-12-27 15:43:58.519 | INFO     | tools.llama.generate:generate_long:807 - Generating sentence 1/1 of sample 1/1
ERROR:    Traceback (most recent call last):
  File "/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/kui/asgi/lifespan.py", line 36, in __call__
    await result
  File "/Users/leaf/Demo/fish-speech/tools/api_server.py", line 77, in initialize_app
    app.state.model_manager = ModelManager(
  File "/Users/leaf/Demo/fish-speech/tools/server/model_manager.py", line 66, in __init__
    self.warm_up(self.tts_inference_engine)
  File "/Users/leaf/Demo/fish-speech/tools/server/model_manager.py", line 122, in warm_up
    list(inference(request, tts_inference_engine))
  File "/Users/leaf/Demo/fish-speech/tools/server/inference.py", line 25, in inference_wrapper
    raise HTTPException(
baize.exceptions.HTTPException: (<HTTPStatus.INTERNAL_SERVER_ERROR: 500>, "'Expected elements.dtype() == test_elements.dtype() to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)'")

ERROR:    Application startup failed. Exiting.

When I manually modify /tools/server/model_manager.py:
        # Check if MPS or CUDA is available
        # if torch.backends.mps.is_available():
        if False:
            self.device = "mps"
            logger.info("mps is available, running on mps.")
        elif not torch.cuda.is_available():
            self.device = "cpu"
            logger.info("CUDA is not available, running on CPU.")

and run python tools/api_server.py again, it works:
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/torch/amp/autocast_mode.py:265: UserWarning: User provided device_type of 'cuda', but CUDA is not available. Disabling
  warnings.warn(
INFO:     Started server process [98127]
INFO:     Waiting for application startup.
2024-12-27 15:48:35.950 | INFO     | tools.server.model_manager:__init__:44 - CUDA is not available, running on CPU.
2024-12-27 15:48:43.325 | INFO     | tools.llama.generate:load_model:682 - Restored model from checkpoint
2024-12-27 15:48:43.325 | INFO     | tools.llama.generate:load_model:688 - Using DualARTransformer
2024-12-27 15:48:43.328 | INFO     | tools.server.model_manager:load_llama_model:100 - LLAMA model loaded.
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/vector_quantize_pytorch.py:445: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/vector_quantize_pytorch.py:630: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/finite_scalar_quantization.py:147: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
/Users/leaf/Demo/fish-speech/.venv/lib/python3.10/site-packages/vector_quantize_pytorch/lookup_free_quantization.py:209: FutureWarning: `torch.cuda.amp.autocast(args...)` is deprecated. Please use `torch.amp.autocast('cuda', args...)` instead.
  @autocast(enabled = False)
2024-12-27 15:48:44.036 | INFO     | tools.vqgan.inference:load_model:43 - Loaded model: <All keys matched successfully>
2024-12-27 15:48:44.036 | INFO     | tools.server.model_manager:load_decoder_model:108 - Decoder model loaded.
2024-12-27 15:48:44.042 | INFO     | tools.llama.generate:generate_long:789 - Encoded text: Hello world.
2024-12-27 15:48:44.042 | INFO     | tools.llama.generate:generate_long:807 - Generating sentence 1/1 of sample 1/1
  3%|███▍                                                                                | 29/1023 [00:02<01:35, 10.37it/s]
2024-12-27 15:48:48.053 | INFO     | tools.llama.generate:generate_long:861 - Generated 31 tokens in 4.01 seconds, 7.73 tokens/sec
2024-12-27 15:48:48.054 | INFO     | tools.llama.generate:generate_long:864 - Bandwidth achieved: 4.93 GB/s
2024-12-27 15:48:48.066 | INFO     | tools.inference_engine.vq_manager:decode_vq_tokens:20 - VQ features: torch.Size([8, 30])
2024-12-27 15:48:48.524 | INFO     | tools.server.model_manager:warm_up:123 - Models warmed up.
2024-12-27 15:48:48.524 | INFO     | __main__:initialize_app:88 - Startup done, listening server at http://<IP_ADDRESS>:8080
INFO:     Application startup complete.
INFO:     Uvicorn running on http://<IP_ADDRESS>:8080 (Press CTRL+C to quit)

And all functions works properly on CPU.

Same error in #779 when using webui

encountered the same issue on my M1 Pro mac.

Same on M1 Pro. I would like to discover how running in MPS can accelerate the process.

Same issue happen in mac mini M2


clutter is now stackable

Stuff can spawn with its center of mass outside whatever its on. Should be fixed

Clutter spawns in the way of doorways, its happening too often. Should be adjusted.


fix(ci): deny feature check

Motivation
Deny check is failing for cli's openssl feature as expected.
Solution

Disable default --all-features on the deny action

@mattsse deny check didn't get triggered


checkboxes list

Hi
I try to add a checkboxes list to jsonSchema
sample:
items: {
"type": "string",
"enum": ["foo",
"bar",
"fuzz"]
}
UISchema:"
multipleChoicesList": {
"ui:widget": "checkboxes"
},
but I also need value and name together , NOT just name show up to list of checkboxes.
do you know how do I need value to schema?
Thank you so much for help!

Maybe enumNames is what you are looking for? https://github.com/mozilla-services/react-jsonschema-form#custom-labels-for-enum-fields

yes.


Jenkins jobs on GitHub are marked failed when at least one really fails and others succeed - this dismays

What we see

What should be
GitHub must show succeeded jobs as succeeded, failed as failed. Jobs statuses must correspond.

polite ping to @kamilsa @BulatSaif @lebdron

The problem is in this line (https://github.com/hyperledger/iroha/blob/main/Jenkinsfile#L70), it is using the global variable currentBuild.currentResult, any build which runs in parallel(https://github.com/hyperledger/iroha/blob/main/Jenkinsfile#L488) can edit it.
possible fix:

create a global map customBuildStatus and store the build results there, and use it to notify git:
gitNotify ("Jenkins: " + build.name, customBuildStatus[build.name]:?currentBuild.currentResult, 'FAILURE')

or

Remove all git Notify and left only one, since the results are the same

And the other similar problem
there are only 2 tests failed but github reports 7 failed 2 succeeded and 3 started but never finished.
screenshots from https://github.com/hyperledger/iroha/pull/943 and https://jenkins.soramitsu.co.jp/blue/organizations/jenkins/iroha%2Firoha-hyperledger/detail/PR-943/78/pipeline

3 started but never finished.

This happens then GitHub is down or not available and it didn't receive notification about the finish


How to disable movement of a Node [QUESTION]

How to disable movement of a Node. Thank you

You can use a css class with:
pointer-events:none;

Currently we cannot tell if a node is draggable or not.


feat: accessible search bar

You can now focus on the search bar with 's' or '/', and use the up and down arrow keys to scroll through the hits. This also brings back the magnifying glass icon that, when clicked, either goes to the search page of the highlighted hit.
Closes #36693

Thank you for checking this out, @xyozio. I think you caught it while I was making some changes. Had to move some stuff around to add a bit more functionality. Please give it another look if you have a chance.

@raisedadead, yes, that sounds good to me. Right now focusing on the search bar is handled by Algolia's <SearchBox> component, but everything else is a bit hacked together. I'll look into a library to handle the up and down arrows and possibly focusing the search bar.

@ojeytonwilliams, thank you for your detailed review. I'll go through and implement your suggestions as soon as possible.

@ojeytonwilliams, not overly picky at all. I don't have a whole lot of experience with React, so I appreciate you and @RandellDawson going through this. I'll take all the help and suggestions I can get!

Okay, cool, I'm glad it's helpful!
I have one general observation, though I don't think it should happen in this PR.  It looks like there's quite a lot of direct manipulation of the DOM (assigning ids via lifecycle methods, querying for elements by class and so on).  It might be a little easier to maintain if it's refactored into a more standard React style.  A custom component with the id as an attribute for the former and passing around the elements as props for the latter .  That sort of thing.
As I said, I don't want to delay this PR, but I'd be happy to help with the refactor after it's landed.

@ojeytonwilliams, that sounds great. Any help with refactoring this to be more standard React would be greatly appreciated.

Went back to the earlier implementation of passing hits from SearchHits.js to SearchBar.js so it's not querying the DOM from lifecycle methods. Shouldn't throw errors now that the handleHits function is inside the useEffect hook.

@scissorsneedfoodtoo it's looking great, nice work!
@raisedadead I'm happy for this to be merged, if you are.

Code looks good to me. We could use some tests, I will go ahead and merge this first and @scissorsneedfoodtoo you could add some tests.

@ojeytonwilliams, thank you for reviewing this and all of your helpful suggestions! I learned a lot along the way.
@raisedadead, I'll start writing tests for the search bar ASAP.


android deployment fails with INSTALL_FAILED_NO_MATCHING_ABI

Describe the bug
Building on a Fedora Silverblue (linux, intel) system, targetting a Moto G6 with Android version 9, kernel 3.18.120...2020
.. FAILS with INSTALL_FAILED_NO_MATCHING_ABIS

Build machine (Linux Desktop):
$ uname -a
Linux fedora 6.11.8-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 20:38:18 UTC 2024 x86_64 GNU/Linux

Building on Linux, trying to deploy on real android device...
$ core install android
xcrun xcodebuild -version
/tmp/gomobile-work-1036905224/lib/arm64-v8a/libCogent_Core_Gui.so: no symbols
adb install -r /var/home/.../bin/android/Cogent Core Gui.apk
Performing Streamed Install
adb: failed to install /var/home/.../bin/android/Cogent Core Gui.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]
core install failed: install: failed to run "adb install -r /var/home/.../bin/android/Cogent Core Gui.apk: exit status 1"
How to reproduce
just try to build this on linux (amd64) and deploy on Moto G6 (Android 9, arm?). It runs locally on the linux desktop, but not on the android device. Are there any target flags that I need to provide? (Love the project by the way!)
$ cat main.go
package main

import "cogentcore.org/core/core"

func main() {
	b := core.NewBody()
	core.NewButton(b).SetText("Hello, World!")
	b.RunMainWindow()
}

Example code
No response
Relevant output
No response
Platform
Android

Thank you for reporting this. This error message indicates that the architecture it is compiling for does not match the architecture of the Android device. The default target architecture is arm64, so I would just try these commands until one of them works:
core install android/arm
core install android/amd64
core install android/386

I will update the documentation to clarify the architecture behavior when compiling for mobile. Please also note that core build android makes a fat apk with all architectures included by default.


Allow the document end marker omitted

The current fkYAML doesn't allow the document end marker (...) omitted before a new YAML document like the following YAML snippet (extracted from the yaml-test-suite's 35KP/in.yaml):
--- !!map
? a
: b
--- !!seq
- !!str c
--- !!str
d
e
# Note that the last multiline plain scalar isn't supported by fkYAML yet.

Parsing the above YAML with fkYAML causes a false parse error which says "invalid end-of-directives marker (---) found in the contents.".
To resolve the false error, this PR has changed the implementation to allow the document end marker omitted, and the library thus assumes no directives preceeded in the next YAML document instead.

Pull Request Checklist
Read the CONTRIBUTING.md file for detailed information.

[x] Changes are described in the pull request or in a referenced issue.
[x] The test suite compiles and runs without any error.
[x] The code coverage on your branch is 100%.
[x] The documentation is updated if you added/changed a feature.

Please don't

The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
Please refrain from proposing changes that would break YAML specifications. If you propose a conformant extension of YAML to be supported by the library, please motivate this extension.
Please do not open pull requests that address multiple issues.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>8:
0.0%

Covered Lines:
3969

Relevant Lines:
3969

💛  - Coveralls


CAMP requirements

We need to add another page where we can view information about a camp.

Need taluk and village options in camp registering.
Click on a camp name to view additional details
Text field for "Requirements in Camp"
Number of people for each gender

Edit: Taluk and village was added

Anyone working on it?

join slack for this

Taluk and village added by me earlier

Hi @nithinjos , @biswaz ,
I have started on this.
If anyone started on this other than me. Please DM at slack jinojossy93

can you check slack before doing

Duplicate of #300

I am starting work on this issue

Do you know where we get the name of camps ? I have names of 42 camps in Kakkanad and Trippunuthura. Working on it to get more details about it

https://drive.google.com/file/d/0B87GnrHsMIX0OXZEZVp0SkVBV3ROOXNNdkw1UW5tb3VuV1Y4/view?usp=drivesdk

Done in PR #406


add latest ES TN/ITN and tests

Signed-off-by: Mariana Graterol Fuenmayor<EMAIL_ADDRESS>What does this PR do ?
Add a one line overview of what this PR aims to accomplish.
Collection: [Note which collection this PR will affect]
Changelog

Add specific line by line info of high level changes in this PR.

Usage

You can potentially add a usage example below

# Add a code snippet demonstrating how to use this

Before your PR is "Ready for review"
Pre checks:

[ ] Make sure you read and followed Contributor guidelines
[ ] Did you write any new necessary tests?
[ ] Did you add or update any necessary documentation?
[ ] Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)

[ ] Reviewer: Does the PR have correct import guards for all optional libraries?

PR Type:

[ ] New Feature
[ ] Bugfix
[ ] Documentation

If you haven't finished some of the above items you can still open "Draft" PR.
Who can review?
Anyone in the community is free to review the PR once the checks have passed.
Contributor guidelines contains specific people who can review PRs to various areas.
Additional Information

Related to # (issue)

Thanks for the feedback, @yzhang123 !

Copyright files updated
Checked that all subfolders have an init.py file
Removed unused imports per codeQL

Thanks for the feedback, @yzhang123 !

Copyright files updated
Checked that all subfolders have an init.py file
Removed unused imports per codeQL

thanks @mgrafu . But am I missing something, the folder inverse_text_normalization/es/data/electronic does not have init file

Thanks for the feedback, @yzhang123 !

Copyright files updated
Checked that all subfolders have an init.py file
Removed unused imports per codeQL

thanks @mgrafu . But am I missing something, the folder inverse_text_normalization/es/data/electronic does not have init file

@yzhang123 the init.py file for this directory exists in main (it was an already existing directory before this pr) so it's not reflected in these changes :)


update to Makefile.questa to support win7 in VHDL mode

I'm using Win7 and questasim.
When running a VHDL test,, line 50 of the Makefile.questa should not have the explicit file extension on libfli.so but libfli.$(LIB_EXT)

@diarmuid , simple change but if you could test I would appreciate it. 441d71

Ok. I've forked the repo and I'm making some updates to add support for Aldec Active-HDL. Works ok for me so I'll test and commit them all back in one go

@stuarthodgson, just tried the endian swapper example and it runs fine using either VPI or FLI.
However, I had to make following change to line 133 of Makefile.questa to make it run:
INT_LIBS := $(COCOTB_VPI_LIB) $(COCOTB_FLI_LIB)

With this change windows and linux versions of INT_LIBS are the same.
In addition, there is an issue with the runsim.do not being updated when only the variables passed from the command line are changed between different runs. eg. changing TOPLEVEL_LANG=vhdl to TOPLEVEL_LANG=verilog will not work correctly.
I've solved this a while ago by changing runsim.do to a PHONY target. I can bring my old PR (Fli under windows #214 ) up to date if that would be of interest.

@elgorwi I'll make the change to line 133 and close this off, thanks for the testing.
As for #214 does much of that apply any more? Been quite a few changes to FLI and the quests/modelsim makefiles of late. If you think it does though then please update the PR and I'll take a look.
Stu

@elgorwi have added your changes (a bit late sorry). reopen if not fixed.

@stuarthodgson,
Thanks for the update.
However, the updating of runsim.do was already fixed in #408 similar to Makefile.aldec (c8bdb8df877bba5e7f7ff10f721801775f3cc8e6)
Not sure if the .PHONY target is still necessary now.
Thanks


ci: fix ci release

Fix CI release by consolidating release jobs because the latest generated release notes are not available to the second job because it is working off the single event commit.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Question] Hardware Requirements

If possible, can you mention the minimum and ideal systema and hardware requirements to run this.
Thanks.

Hi, I intentionally didn't mention any requirements, because code will work even on very weak hardware.
I think (but haven't tested it yet) it will work on AWS t2.micro and greater instances.


Issue Report: SUMMARY HERE

live-sass-compiler-doesn't-work.zip

Can I have details of your issue? Thanks

Live SASS refuses to compile SCSS files in CSS. When I started a project everything was great, but in moment (in the middle of the work) it's just stopped to compile.

What's the output from the compiler?

I'm guessing
Compilation Error
Error: Undefined mixin.
   ╷
38 │                             @include greenarrow;
   │                             ^^^^^^^^^^^^^^^^^^^
   ╵

I have a problem with main.scss, I didn't check any other files yet.

That's where the problem is
Here you're trying to use greenarrow but you haven'e defined it. That's why the compiler is outputting the warning I have copied in above. Define the mixin and the error will go away. Does that make sense?
.btn-text1::after {
    @include greenarrow;
}

Your

The problem is it doesn't compile in css, I'm trying to set style but it doesn't work

And it's not compiling in CSS.

It worked, I found in CSS. Fixed that mistake thank you.

No problem


Meta for Twitter Summary Card with Large Image

I realised that current OG image is large enough to be used as Twitter Summary Card with Large Image. So, I created this PR.
Added meta for Twitter Summary Card with Large Image. https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/summary-card-with-large-image
Suggestion: Create a better image. The current OG image is may create confusion. It would be better if it is replaced by a generic one.

Thanks!


feat: pilvo v4 support

Closes #28

Still does not appear to support plivo/plivo-php ^4.3

As in, you get an error or it doesn't allow you to install?

As in, you get an error or it doesn't allow you to install?

Correct.  Won't install.

As in, you get an error or it doesn't allow you to install?

Correct. Won't install.

Please post the error

As in, you get an error or it doesn't allow you to install?

Correct. Won't install.

Please post the error

Here is error I am getting when trying to install:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires laravel-notification-channels/plivo ^2.3 -> satisfiable by laravel-notification-channels/plivo[v2.3].
- laravel-notification-channels/plivo v2.3 requires plivo/plivo-php ^1.1 -> found plivo/plivo-php[v1.1.0, ..., v1.1.7] but it conflicts with your root composer.json require (^4.18).
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Could you send me your composer.json?

Could you send me your composer.json?

{
"name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"require": {
"php": "^7.3|^8.0",
"bugsnag/bugsnag-laravel": "^2.0",
"fideloper/proxy": "^4.4",
"fruitcake/laravel-cors": "^2.0",
"guzzlehttp/guzzle": "^7.0.1",
"inertiajs/inertia-laravel": "^0.3.5",
"laravel/framework": "^8.12",
"laravel/jetstream": "^2.3",
"laravel/sanctum": "^2.6",
"laravel/tinker": "^2.5",
"laravel-notification-channels/plivo": "^2.3",
"plivo/plivo-php": "^4.18",
"tightenco/ziggy": "^1.0"
},
"require-dev": {
"facade/ignition": "^2.5",
"fakerphp/faker": "^1.9.1",
"laravel/sail": "^1.0.1",
"mockery/mockery": "^1.4.2",
"nunomaduro/collision": "^5.0",
"phpunit/phpunit": "^9.3.3"
},
"autoload": {
"psr-4": {
"App\": "app/",
"Database\Factories\": "database/factories/",
"Database\Seeders\": "database/seeders/"
}
},
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
},
"scripts": {
"post-autoload-dump": [
"Illuminate\Foundation\ComposerScripts::postAutoloadDump",
"@php artisan package:discover --ansi"
],
"post-root-package-install": [
"@php -r "file_exists('.env') || copy('.env.example', '.env');""
],
"post-create-project-cmd": [
"@php artisan key:generate --ansi"
]
},
"extra": {
"laravel": {
"dont-discover": []
}
},
"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"sort-packages": true
},
"minimum-stability": "dev",
"prefer-stable": true
}

You're not actually installing this PR just the main version of the package. you'll have to set up a composer repo to my gh and select the branch to do so.

You're not actually installing this PR just the main version of the package. you'll have to set up a composer repo to my gh and select the branch to do so.

Sorry to be such a bother, but can you write down steps to do this?  Thanks.