"Dorobanțu" is listed in the drop-down menu

Description:
"Dorobanțu" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Dorobanțu" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Dorobanțu, CĂLĂRAȘI (Dorobanțu)".


Feature: add option " changing class only skills into oskills"

Folks saying d2mm was that and that was useful.

Also, add second checkbox "convert charges too"


std::runtime_error Exception with an error code: 0x1f (SPXERR_CHANGE_CONNECTION_STATUS_NOT_ALLOWED)

Describe the bug
I am using MicrosoftCognitiveServicesSpeech-iOS-1.5.0 on the iOS platform， there is chance ERROR:
#0 Thread
std::runtime_error
Exception with an error code: 0x1f (SPXERR_CHANGE_CONNECTION_STATUS_NOT_ALLOWED)

[call stack begin]
MicrosoftCognitiveServicesSpeech 0x00000001035baf64 participant_get_property_bag + 154208 4 MicrosoftCognitiveServicesSpeech 0x0000000103611b60 participant_get_property_bag + 509532 5 MicrosoftCognitiveServicesSpeech 0x0000000103611968 participant_get_property_bag + 509028 6 MicrosoftCognitiveServicesSpeech 0x0000000103611ee0 participant_get_property_bag + 510428 7 MicrosoftCognitiveServicesSpeech 0x00000001036146d8 participant_get_property_bag + 520660 8 libsystem_pthread.dylib 0x000000020b2f02c0 <redacted> + 128 9 libsystem_pthread.dylib 0x000000020b2f0220 _pthread_start + 44 10 libsystem_pthread.dylib 0x000000020b2f3cdc thread_start + 4
[call stack end]

Creation process
SPXSpeechConfiguration *configuration = [[SPXSpeechConfiguration alloc]initWithSubscription:MICROSOFT_SPEECH_KEY region:MICROSOFT_SERVICE_REGION];
configuration.speechRecognitionLanguage = tempFromLanguage;
if (!configuration) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
SPXAudioStreamFormat *format = [[SPXAudioStreamFormat alloc]initUsingPCMWithSampleRate:16000 bitsPerSample:16 channels:1];
if (!format) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
self.stream = [[SPXPushAudioInputStream alloc]initWithAudioFormat:format];
if (!self.stream) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
SPXAudioConfiguration *audioConfiguratian = [[SPXAudioConfiguration alloc]initWithStreamInput:self.stream];
if (!audioConfiguratian) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
self.speechRecognizer = [[SPXSpeechRecognizer alloc] initWithSpeechConfiguration:configuration audioConfiguration:audioConfiguratian];
if (!self.speechRecognizer) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
WEAKSELF
[self.speechRecognizer addRecognizedEventHandler:^(SPXSpeechRecognizer * recognizer, SPXSpeechRecognitionEventArgs * args) {
    //do something
}];
[self.speechRecognizer addRecognizingEventHandler:^(SPXSpeechRecognizer * recognizer, SPXSpeechRecognitionEventArgs * args) {

}];
self.connection = [[SPXConnection alloc]initFromRecognizer:self.speechRecognizer];
if (!self.connection) {
    self.errorCode = NETWORK_ERROR_CODE;
    [self errorEndTaskState];
    return;
}
[self.connection addConnectedEventHandler:^(SPXConnection * connection, SPXConnectionEventArgs * args) {
    weakSelf.connectioned = YES;
    [weakSelf.speechRecognizer startContinuousRecognition];
    [weakSelf speechRecorderStartTaskState];
}];
[self.connection addDisconnectedEventHandler:^(SPXConnection * connection, SPXConnectionEventArgs * args) {
	//do something
}];
[self.connection open:YES];

Called after each use recognition
1、[SPXPushAudioInputStream close];
2、[SPXSpeechRecognizer stopContinuousRecognition];
3、[SPXConnection close];

Hi -
can you add a listener to the cancel event and see if any other error is reported before this?
You also do not need a connection object, once you have a recognizer, you can start recognition and the connection will be managed under the cover for you.
Wolfgang

Hi, in addition to what @wolfma61 said, could you also turn on logging, and post the log file from when the error occurs? Thanks!

@237370905 - is there any more information on this issue you can give us?

@237370905 - is there any more information on this issue you can give us?

not more iusse informations
no expcetion occurred, no used SPXConnection

@237370905  - can you create a client log file?
what is the sessionid of the ongoing recognition, in what region?

I've run in to the same issue, running the Python SDK in a server. I believe in my case it is from incorrect usage of the Connection object.
Firstly, I am using the Connection object because I have another error that I periodically get -- Azure closes my SDK connection, and the cancel event is called with WS_UNDERLYING_IO_ERROR. I haven't been able to work around this issue, so I set up a Connection object so that I can at least see when the connection is being canceled, so I can maybe retry recognition.
My idea here was to simply re-open the connection, and re-call start_continuous_recognition. However, the Connection object throws SPXERR_CHANGE_CONNECTION_STATUS_NOT_ALLOWED when I try to call open on it a second time.

@Checkroth: This is not supported. If an error of any kind has occurred, the recognizer becomes invalid and a new one has to be constructed. The connection object can only be used to establish the initial connection, not to manually reconnect in case of a problem.

@chlandsi thanks for the response.
I did find that out on my own. I'm still using the Connection object so I can set an event callback specifically on dropped connections.
Would be good for a little more documentation surrounding these limitations. SDK Documentation and source code don't mention that at all.

Hi, I also met this issue in iOS.
libc++abi: terminating due to uncaught exception of type std::runtime_error: Exception with an error code: 0x1f (SPXERR_CHANGE_CONNECTION_STATUS_NOT_ALLOWED)
[CALL STACK BEGIN]

3   MicrosoftCognitiveServicesSpeech    0x0000000112b8507c GetModuleObject + 170600
4   MicrosoftCognitiveServicesSpeech    0x0000000112ca9c78 GetModuleObject + 1369700
5   MicrosoftCognitiveServicesSpeech    0x0000000112ca9c04 GetModuleObject + 1369584
6   MicrosoftCognitiveServicesSpeech    0x0000000112cabaa4 GetModuleObject + 1377424
7   MicrosoftCognitiveServicesSpeech    0x0000000112ca9ddc GetModuleObject + 1370056
8   MicrosoftCognitiveServicesSpeech    0x0000000112cacc18 GetModuleObject + 1381892
9   libsystem_pthread.dylib             0x00000001f525e06c _pthread_start + 136
10  libsystem_pthread.dylib             0x00000001f52590d8 thread_start + 8

I'm trying to start and close connection repeatedly, which will more easier to trigger this issue.


"Column to predict (Label)" not populated

System Information (please complete the following information):

Model Builder Version (available in Manage Extensions dialog): <IP_ADDRESS>7001
Visual Studio Version: 17.10.1

Describe the bug

On which step of the process did you run into an issue: I tried following the guide here https://dotnet.microsoft.com/en-us/learn/ml-dotnet/get-started-tutorial/data. Chose the yelp_labelled.txt file, "Data Preview" is populated.
Clear description of the problem: The drop-down menu "Column to predict (Label)" only contains "Select column" and not "col0", "col1" as expected. Since I cannot select a column to predict, I can't continue to the next step in the guide.

To Reproduce
Steps to reproduce the behavior:

Follow the steps in https://dotnet.microsoft.com/en-us/learn/ml-dotnet/get-started-tutorial/data
Selecting "Column to predict (Label)" is not possible

Expected behavior
I expected the "Column to predict (Label)" to be populated with the items "col0" and "col1"
Screenshots

Closing the solution and opening the model configuration guide again seems to have solved the issue


On Fast doc for stage peering one step is missing

In stage 'network peering' the documentation misses to mention the need to copy the tfvars file over, symptom is that security stage related provider file is not created if output location is set in tfvars file as that info is not passed from auto global tfvars.
Other network related doc page like separated envs mention it properly
cp ../00-bootstrap/terraform.tfvars .

Thanks for raising this. The user-defined tfvars file should not in fact be copied, since relevant values are already set in the generated globals tfvars and stage tfvars should be specific to the variable of each stage.
The only one missing there is the one you flagged, that controls output files generation and it's missing intentionally: output files are a per-stage decision, since they are not needed (and potentially problematic) when implementing CI/CD.
But I agree that we should be explicit about the need to set output_file variable in every stage.


Update planned enhancements in DG

Adds description and proposed implementation for the following planned enhancements:

Allow partial name search for find command
Ban users from entering non-alphanumeric keywords for find command

Not sure if we should include the second planned enhancements. Don't see it as a flaw.


Reload Log Files

If it's not currently possible, could gitea re-open log files on SIGHUP? If it is possible, could somebody tell me what I'm doing wrong? At the moment, I have logrotate restarting the gitea service.

i have this problem too, seems gitea manages by own the log files and the OS vendor distribution cannot take care of to manage it as must be

You can use copytruncate option of logrotate.

I would consider copytruncate to be a workable hack, but the better solution would be to support re-opening log files.
@lunny This is a feature request, not a question.

@MTecknology I'm also handling log rotate myself, using logrotate. (Must do so, so can feed logs into log management stack.)
Have you found a workaround in the meantime?
The gitea container runs s6, so I would typically do this:
s6-svc -1 /etc/s6/gitea/

Which makes s6 send signal SIGUSR1 to the app. That should force the app to release and reopen the log file (which has just been rotated).

@MTecknology What do you use instead? 🤔 Gitea works so well for me.

Based on my packaging efforts, the number of modules I found with various forks with security patches, etc., I decided gitea is not secure enough to be production ready. It's a project that is more about cool new features than reliability or security.
I switched to gitolite3 + cgit, which is software that cares a lot about performance, stability, and security. I also wrote a custom nginx module that uses gitolite3 ACLs for cgit access.

@MTecknology Hmmm interesting points, thanks. However you know that gitolite3 has 1 major maintainer (😱), whereas here at gitea we have over 20 (🚀). Something to think about. I acknowledge though that every person's needs are unique.
Please leave the issue open if you don't mind, we still need to deal with it.

It's true that gitolite3 has one gate keeper, but he works well with others [1] and has a very solid grasp on the software. Further, gitolite has been reviewed by many security auditing firms, been given a stamp of approval, and deployed internally. If you want a true comparison to Gitea gate keepers, then you're really just talking about 3 vs. 1.
My experience with Gitea [2] is many features crammed in for the sake of cool new features with very little (or no) care to stability, license compliance, maintainability, security, or anything else I consider important. In fact... one of the "gitea owners" is where I was told that security problems get resolved when you update the software. There was absolutely no concern at all for auditing source and understanding security implications of design decisions.
[1] See other my Gitea PRs from me for why that matters...
[2] Note that I /did/ become one of those maintainers and chose to leave.
You're correct- we all have our own needs. I enjoy cool new features, but I prioritize every thing else.
I also agree this is worth leaving open because it's a legitimate problem. Since it's not a "cool new feature," I'm relatively certain it will never get resolved.

Interesting and valid points.

3 vs. 1

...Sounds like a cage fight! 😆 If you don't mind, I'm betting on Gitea!

One person that accepts feedback and criticism vs. three people that prevent improvement, allow features, and communicate poorly.... You're free to pick your bet, but one of us will be paying the other. :)


Implement PHP RFC 0001: PHP Start

Per https://github.com/paketo-buildpacks/php/issues/503 and the associated RFC , we should implement the PHP Start buildpack as a part of the PHP Rewrite.
This is a placeholder issuer for implementing the PHP Start buildpack, until the RFC is merged and the API  is solidified.
Cases to support:

[ ] HTTPD + FPM in one container
[ ] Nginx + FPM in one container
[ ] Later on: Nginx as a proxy for FPM in a separate container (associated with paketo-buildpacks/php-fpm/issues/8)
[ ] Later on: HTTPD as a proxy for FPM in a separate container (associated with paketo-buildpacks/php-fpm/issues/8)

Closing in favour of individual issues on the Paketo PHP Start repo.


Where is the doc website source ?

Hi,
First of all, your library is awesome !
I love the doc site, and I would love to be able to look at the source code of the doc website to learn in a real world example project :)
I understand if you don't want it to be public tho !

Hi, thank you for the kind words @beaussan!
The doc site's source is not open, simply because... it's a bit messy! And I wasn't sure if that'd be a good example or not.
I understand how useful it could be to see a 'real world example' though, so how about this: I can give you access to the windups docs repo, you let me know whether I'm worrying about nothing or not, and maybe we make it public from there?

Sure! I can look at it next week! Thank you for your trust :)

It looks great ! And I got a better feel for the library thanks to it ! Great work on both !! =D

Well that's good enough for me. The repo for the docs site is now public at https://github.com/sgwilym/windups-docs. I hope it makes a useful reference!


Fix Zipcode Bug in Stripe

From user Hunter Trujillo
Hey, I just tried donating, and after Stripe payment went through, I got an error in the title bar that said this:
Unexpected token < in JSON at position 0
And then in my console, I'm guessing you're using Redux, the action that failed was this:
DONATE_GROUP_FAILURE
There was a 503 from a request at this endpoint:
https://opencollective.com/api/groups/43/payments/
The page I was on was here:
https://opencollective.com/apex#support
User had changed ZipCode recently. No place in stripe path to change zipcode
Possible fixes:

enable the zip code field on the stripe form
disable declining cards that fail zip code verification on your stripe settings.

I'm not a fan of adding the zip code in the form because it will scare Europeans who aren't used to that.
I wonder what triggers this error. You had to basically already have your card registered in stripe and then change your zip code with the bank?
I've momentarily disabled the zip code verification at stripe level. Can you try again?

Yeah, that's exactly what happened, and I couldn't find a way to change that in Stripe, because they don't have a B2C login, afaik. It's just for their B2B service.
I tried it again and it worked now. That's a beautiful profile picker btw, is that custom? I generally leave that setting off on my Stripe settings, but the CVC verification on, it's pretty safe, imo, and people, especially devs, tend to move. 😸

Glad it worked and thanks for your support to Apex!
I've put the zip code verification back on. We'll see if we get more errors. What we definitely need to do is improve the error message. It shouldn't fail like that.
Thanks again for bringing this up to our attention! 👍

closing this issue until we receive more errors.


Fix for incorrect version sorting

Issue 64 (https://github.com/creationix/nvm/issues/64). Split nvm_version function into nvm_ls and nvm_version in order to fix sorting properly + add the ability to see all matching version with nvm_ls.

I think this is a better patch now - should cover all the cases mentioned in the previous comments


update README installation instructions

making this PR to also test the CI

neato, the ci actually worked 😄  and it downloaded the weights too!


KAFKA-6360: Clear RocksDB Segments when store is closed

Now that we support re-initializing state stores, we need to clear the segments when the store is closed so that they can be re-opened.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@mjsax, @guozhangwang, @bbejeck

LGTM! Merged to trunk.

Cherry-picked to 1.0, 0.11.0, and 0.10.2.


Update http4s-prometheus-metrics to 0.24.0

Updates org.http4s:http4s-prometheus-metrics from 0.23.12 to 0.24.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (0.23.12).
You might want to review and update them manually.
README.md

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-prometheus-metrics" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.http4s", artifactId = "http4s-prometheus-metrics" }
}]

labels: library-update, early-semver-major, semver-spec-minor, old-version-remains, commit-count:1

Superseded by #78.


Compiling the Solution

I can't compile the solution. Every time I try it fails, using visual studio 2019

same problem, I use visual studio code  and it shows lots of warnings .. can´t compile .. if you have any advise pls let me know

same problem has 77 errors and 0 of 92 warnings. please advise for a solution. thanks!


modified to able to parse code including multibyte chars

@LaoitdevOpen Hello, I am Rie Ono from Japan.
Thank you for the implementation of EMVCo library! I would like to use this library.
I noticed that I could not parse QR codes including multi-byte chars like Japanese.
The cause of this issue, utf8.encode() will return the bytes of only alphanumeric chars.
Could you check my fix?
Best Regards,

thanks for your pull request this issue fixed by #2


Not able to register a service as Eureka Client when using Custom autoconfiguration class

Hi,
I had an issue when trying to make a service as eureka client using spring profile and a custom autoconfiguration class which makes applies the @EnableEurekaClient annotation.
I raised the issue because I got an exception and also the service was not registered as Eureka Client during startup. I used Spring Boot 1.5.3 and Dalston.RELEASE for the service and spring cloud.
I raised the issue earlier for it. Spring Boot Service fails on startup when using custom autoconfiguration class for enabling/disabling eurekaclient #1933
The issue now seems closed which a fix in Dalston.SR1. I used Dalston.SR1 along with Spring Boot 1.5.3 and when I tested the exception is gone but the service is not getting registered as eureka client.
I made a comment about this in my original issue. I thought it would be better to track it as a separate issue even tho' my original issue still exists.
Anyway, the updated code used to reproduce the problem is as below.
https://github.com/bsridhar123/demo-code
Can you please help me with this.

Any updates on this issue.

Add
@AutoConfigureBefore(EurekaClientAutoConfiguration.class)
public class ServiceRegistryConfiguration {
    //...
}

+1 on this.  we had the same issue.  The jump from camden to dalston broke service discovery auto config until we added the above annotation.

@jberk did you see my solution above?

@spencergibb - yes, that's what I was +1'ing :-)


Notice: Array to string conversion

Notice: Array to string conversion on registration
p7s1-ctf/7pass-php-sdk/lib/P7/SSO/ApiClient.php at line 191
191 | $message = empty($description) ? $message : $message . ' - ' . $description;

$body = json_decode($httpResponse->getBody());
$body
stdClass Object
(
    [status] => error
    [error] => stdClass Object
        (
            [message] => Validation failed
            [status] => 422
            [detail] => Array
                (
                    [0] => stdClass Object
                        (
                            [property] => emails
                            [detail] => Array
                                (
                                    [0] => stdClass Object
                                        (
                                            [property] => email_value
                                            [detail] => Email already in use
                                        )

                                )

                        )

                )

        )

)

This was backwards incompatibility on backend side and should be fixed now.


fix(signature_pad): fix race condition in _strokeUpdate

Since there is no initiative to release the patch on version 2.x.x I am trying to escalate this by creating the same patch from #481 into branch for major version 2.
@szimek can you please take a look on this and release a patch version? Thank you very much.

@szimek Any idea whether this will get merged and released as patch to version 2.x.x ?

@szimek any intention to merge this?

this will be fixed in v4 released soon.


Delete other stuff than worlds.

There is a major issue. You are able to do delete more than just worlds with multiverse. You can delete folders like plugins, logs, etc. Recently had someone come on a server I work for (used the bungee exploit) and wipe plugins folder and log.
What you do is you /mv import  (eg /mv import plugins/)
then you /mv delete plugins/
You can do the same with specific folders (eg /mv import plugins/Essentials/)
Then /mv delete plugins/Essentials/
A Fix to this would be great as soon a possible.
(Don't actually do this if you don't know what you're doing to anyone who's viewing this and doesn't understand :p)
Thank you!

Hi @xXkguyXx try the latest build. Checked a few previous issues and commits and it looks like it was fixed a year ago or so. You can download it from here: https://ci.onarandombox.com/view/Multiverse/
Let me know how you get on

Will do, thanks! :D

Hello
I just tried with the latest version.
I was still able to import the logs and delete the logs folder (I checked ftp and it was gone)
http://prntscr.com/k5v1g2
Thank you :D

Hi, I was able to reproduce this with the latest version.

/mv import plugins/ normal
/mv delete plugins/
It was then able to delete all that it could.

I assigned @dumptruckman to this because I consider it a high priority fix as it's exploitable for malicious admins (albeit is on the owner, nonetheless this shouldn't be allowed).

Thanks keep me posted!

@xXkguyXx In case you don't get notified of the closing, this issue has been fixed.


Bad Clashes

I was able to get Equibind running on GPU and CPU versions, however, I get pretty bad clashes using the default model. The models generally look like they could be plausible as a centroid, however.  Do you have any advice for how to best remove these clashes?  In the paper, you mention Equibind+S.  Is this done as two separate tasks or do you integrate it somehow? Is this generally what you would recommend, or are their options you would recommend to try, especially for bigger ligands such as this molecule (peptide at about 180 atoms including hydrogens)?
Finally, if the general recommendation is Equibind->SMINA, which it seems to be, do you have cmd-line arguments used in your benchmarking for SMINA?  I could not find a paper supplement with these arguments.
Example of a bad clash in the ligand is below.

I ran SMINA using the following, but it takes quite a while.  Did you run -minimize or -local_only for your paper?  Did you include any side chain flexibility? Did you increase exhaustiveness for your results?
smina -r receptor.pdbqt -l ligand.pdbqt --autobox_ligand ligand.pdbqt --autobox_add 6 --exhaustiveness 16 -o native_tuned.pdbqt  --cpu 8

Hi!
For the cmd arguments you can have a look at #15 .
Unfortunately, EquiBind's predictions can have clashes.
We used the default exhaustiveness

Thanks! This is very helpful! Probably could put it in supplemental for the paper.  I made the autobox_add as 5 to be around what you have - though it's probably a bit bigger than defining the x/y/z box directly.


Aspect ratio set

Please add an option to enforce card's aspect ratio, similar to HA's picture entity card.
My Hikvision camera's substream has an aspect ratio of 4:3 while the video itself is actually 16:9, and it appears vertically stretched.
If we could set the card height not to reszize automatically to video's aspect, but instead, with optional parameter allow setting a custom card aspect ratio (for 16:9 this is 1.78) it would be great.
VLC displays the stream correctly but I'm sure there's a glitch in the stream itself. No way to fix it in the camera (could use the main stream of 2K resolution, that has the correct ratio, but it's too much for Lovelace, useless here. Substream is enough.)

I've got partial results with:

set object-fit: fill; in the CSS of the video (I think here)
set width: 100%; for ha-card

Same as #21
If you know JS enough, you can propose the fix

Me neither. The problem is that the two changes above do the correct ratio, but in Lovelace bottom of the card remains black.

So we waiting some JS guru :)

Posted something to https://github.com/AlexxIT/WebRTC/issues/21#issuecomment-1008124553


Request for a Cleaner Format of the QA Test Dataset

https://github.com/richard-peng-xia/RULE/blob/f1bf7f7020918faab49e2dff12e01e7de41821bb/data/test/harvard_test.jsonl#L2-L4
Hi,
I’ve noticed that the current QA test dataset contains some responses that are not in a clean "yes/no" format. Is there a possibility of providing a more standardized dataset with a clearer format for the answers?
Thanks!

Hi @CC-aff ,
Sorry to bother you. The VQA datasets are obtained through GPT-4 based on medical reports. We will update an cleaner version later.
Thanks.


⚠ Processors has degraded performance

In 0d183c4, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 54 ms

Resolved: Processors performance has improved in 67849d8.


add "document.contentType"

Returns the MIME type that the document is being rendered as.  This may come from HTTP headers or other sources of MIME information, and might be affected by automatic type conversions performed by either the browser or extensions.

https://developer.mozilla.org/en-US/docs/Web/API/Document/contentType

MDN says "only supported by Gecko" but it also works in latest Chrome & Opera. Doesn't work in Edge (so I assume it doesn't work in IE either)

Looks like this is covered by MDN data:
https://caniuse.com/mdn-api_document_contenttype


Remove global hosts variable

Codecov Report

Merging #37 into master will decrease coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #37      +/-   ##
==========================================
- Coverage   96.47%   96.45%   -0.03%
==========================================
  Files           7        7
  Lines         142      141       -1
==========================================
- Hits          137      136       -1
  Misses          5        5

Impacted Files
Coverage Δ

ouroboros/cli.py
100% <100%> (ø)
:arrow_up:

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 aa3bc22...490dcf1. Read the comment docs.


CheckSequenceVerify with OP_DROP

According to the following issue: https://github.com/rust-bitcoin/rust-miniscript/issues/548, OP_DROP is never used in miniscript.
However, most of the scripts using OP_CSV are using OP_DROP to clean the stack after the verification. Instead, miniscript descriptor compiles to OP_CSV OP_VERIFY. This is not common, BIP112 itself never mention OP_VERIFY and it makes several onchain scripts not parsable by miniscript.
What's the idea of using OP_VERIFY after CSV ? Isn't useless to OP_VERIFY the input locktime ? It should never fail ?
Also, is there a way to compile older descriptor to CSV DROP script ?

It's definitely not a goal of Miniscript to support parsing all on-chain scripts. However, I do have a goal to write some sort of "extended Miniscript parser" that can interpret things like CSV with DROP (and skip pushes followed by DROPs, can evaluate fixed arithmetic fragments, etc) and convert them to the equivalent Miniscript fragments, to allow them to be analyzed and interpreted.
But that project would be separate from Miniscript (even if I put it into this library), and also I've never started it. Despite talking about it for many years.
As for the historical question of why we used VERIFY instead of DROP ... let me search my IRC logs. I believe it was as simple as "we wanted to minimize the total number of opcodes we were using" because that made our parser conceptually smaller, and if we one day attempted some sort of formal modelling of all the opcodes used by Miniscript, this would be one fewer do deal with.

Ah, no, there is a better reason than this.
If you look at https://bitcoin.sipa.be/miniscript/ you will see that there is no " CSV VERIFY" fragment. There is a " CSV" fragment and there is a " VERIFY" fragment, and together those provide the same functionality as " CSV DROP", without needing to define a whole extra fragment.
Minimizing the total number of fragments is definitely a design goal of Miniscript, because every fragment needs to be hand-verified to be exactly correct and satisfy exactly the properties that we claim for it. So extra fragments are opportunities for mistakes in the language design, and mistakes in the design can easily turn into critical money-losing bugs in users' code.

Minimizing the total number of fragments is definitely a design goal of Miniscript, because every fragment needs to be hand-verified to be exactly correct and satisfy exactly the properties that we claim for it. So extra fragments are opportunities for mistakes in the language design, and mistakes in the design can easily turn into critical money-losing bugs in users' code.

I totally understand this, but practically It seems to me that most HTLC-like scripts are implemented with CSV DROP. So this design makes impossible potential migration to miniscript in a lot of cases. I don't realize the implications and the work needed to add a new DROP fragment but maybe the pain is worth the gain ?
anyway, I get the point and I have an answer, thanks, let's close the issue if out of scope

Sounds good, will close.
Compatibility with existing scripts was never a goal -- and indeed, it's not just the use of CSV DROP that makes us incompatible with HTLCs. There is also the fact that HTLCs use a branch to interpret an object either as a public key or a hash preimage, something which Miniscript can't express.


Remove netgo build constraint

With netgo build constraint added (which removes cgo-based DNS resolution), users are seeing that azd auth login now fails on Windows with VPN enabled due to localhost DNS resolution failing. Removing this build constraint allows azd auth login to work even under VPN conditions. Verified the behavior locally
Fixes #1994

Azure Dev CLI Install Instructions
Install scripts
MacOS/Linux

May elevate using sudo on some platforms and configurations

bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010 --version '' --verbose --skip-verify

pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010' -Version '' -SkipVerify -Verbose

Windows
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010' -Version '' -SkipVerify -Verbose;"

MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"

Standalone Binary

Linux -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-linux-amd64.tar.gz
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-linux-arm64.tar.gz

MacOS -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-darwin-amd64.zip
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-darwin-arm64.zip

Windows - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-windows-amd64.zip

MSI

https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2010/azd-windows-amd64.msi

Container
docker run -it azdevcliextacr.azurecr.io/azure-dev:pr-2010

Documentation

learn.microsoft.com documentation

title: Azure Developer CLI reference (preview)
description: This article explains the syntax and parameters for the various Azure Developer CLI Preview commands.
author: hhunter-ms
ms.author: hannahhunter
ms.date: 04/24/2023
ms.service: azure-dev-cli
ms.topic: conceptual
ms.custom: devx-track-azdevcli
Azure Developer CLI reference (preview)
This article explains the syntax and parameters for the various Azure Developer CLI Preview commands.
azd
The Azure Developer CLI (azd) is an open-source tool that helps onboard and manage your application on Azure
Options
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
  -h, --help         Gets help for azd.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
azd config: Manage azd configurations (ex: default Azure subscription, location).
azd deploy: Deploy the application's code to Azure.
azd down: Delete Azure resources for an application.
azd env: Manage environments.
azd init: Initialize a new application.
azd monitor: Monitor a deployed application.
azd package: Packages the application's code to be deployed to Azure. (Beta)
azd pipeline: Manage and configure your deployment pipelines.
azd provision: Provision the Azure resources for an application.
azd restore: Restores the application's dependencies.
azd template: Find and view template details.
azd up: Provision Azure resources, and deploy your project with a single command.
azd version: Print the version number of Azure Developer CLI.

azd auth
Authenticate with Azure.
Options
  -h, --help   Gets help for auth.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth login: Log in to Azure.
azd auth logout: Log out of Azure.
Back to top

azd auth login
Log in to Azure.
Synopsis
Log in to Azure.
When run without any arguments, log in interactively using a browser. To log in using a device code, pass
--use-device-code.
To log in as a service principal, pass --client-id and --tenant-id as well as one of: --client-secret,
--client-certificate, or --federated-credential-provider.
azd auth login [flags]

Options
      --check-status                           Checks the log-in status instead of logging in.
      --client-certificate string              The path to the client certificate for the service principal to authenticate with.
      --client-id string                       The client id for the service principal to authenticate with.
      --client-secret string                   The client secret for the service principal to authenticate with. Set to the empty string to read the value from the console.
      --federated-credential-provider string   The provider to use to acquire a federated token to authenticate with.
  -h, --help                                   Gets help for login.
      --redirect-port int                      Choose the port to be used as part of the redirect URI during interactive login.
      --tenant-id string                       The tenant id or domain name to authenticate with.
      --use-device-code                        When true, log in by using a device code instead of a browser.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd auth logout
Log out of Azure.
Synopsis
Log out of Azure
azd auth logout [flags]

Options
  -h, --help   Gets help for logout.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd config
Manage azd configurations (ex: default Azure subscription, location).
Synopsis
Manage the Azure Developer CLI user configuration, which includes your default Azure subscription and location.
Available since azure-dev-cli_0.4.0-beta.1.
The easiest way to configure azd for the first time is to run azd init. The subscription and location you select will be stored in the config.json file located in the config directory. To configure azd anytime afterwards, you'll use azd config set.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
Options
  -h, --help   Gets help for config.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config get: Gets a configuration.
azd config list: Lists all configuration values.
azd config list-alpha: Display the list of available features in alpha stage.
azd config reset: Resets configuration to default.
azd config set: Sets a configuration.
azd config unset: Unsets a configuration.
Back to top

azd config get
Gets a configuration.
Synopsis
Gets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config get <path> [flags]

Options
  -h, --help   Gets help for get.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list
Lists all configuration values.
Synopsis
Lists all configuration values in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list-alpha
Display the list of available features in alpha stage.
azd config list-alpha [flags]

Options
  -h, --help   Gets help for list-alpha.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config reset
Resets configuration to default.
Synopsis
Resets all configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable to the default.
azd config reset [flags]

Options
  -h, --help   Gets help for reset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config set
Sets a configuration.
Synopsis
Sets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config set <path> <value> [flags]

Examples
azd config set defaults.subscription <yourSubscriptionID>
azd config set defaults.location eastus

Options
  -h, --help   Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config unset
Unsets a configuration.
Synopsis
Removes a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config unset <path> [flags]

Examples
azd config unset defaults.location

Options
  -h, --help   Gets help for unset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd deploy
Deploy the application's code to Azure.
azd deploy <service> [flags]

Options
      --all                   Deploys all services that are listed in azure.yaml
  -e, --environment string    The name of the environment to use.
      --from-package string   Deploys the application from an existing package.
  -h, --help                  Gets help for deploy.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd down
Delete Azure resources for an application.
azd down [flags]

Options
  -e, --environment string   The name of the environment to use.
      --force                Does not require confirmation before it deletes resources.
  -h, --help                 Gets help for down.
      --purge                Does not require confirmation before it permanently deletes resources that are soft-deleted by default (for example, key vaults).

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd env
Manage environments.
Options
  -h, --help   Gets help for env.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

Back to top

azd env get-values
Get all environment values.
azd env get-values [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for get-values.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env list
List environments.
azd env list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env new
Create a new environment.
azd env new <environment> [flags]

Options
  -h, --help                  Gets help for new.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env refresh
Refresh environment settings by using information from a previous infrastructure provision.
azd env refresh [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for refresh.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env select
Set the default environment.
azd env select <environment> [flags]

Options
  -h, --help   Gets help for select.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env set
Manage your environment settings.
azd env set <key> <value> [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd init
Initialize a new application.
azd init [flags]

Options
  -b, --branch string         The template branch to initialize from.
  -e, --environment string    The name of the environment to use.
  -h, --help                  Gets help for init.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment
  -t, --template string       The template to use when you initialize the project. You can use Full URI, <owner>/<repository>, or <repository> if it's part of the azure-samples organization.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd monitor
Monitor a deployed application.
azd monitor [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for monitor.
      --live                 Open a browser to Application Insights Live Metrics. Live Metrics is currently not supported for Python apps.
      --logs                 Open a browser to Application Insights Logs.
      --overview             Open a browser to Application Insights Overview Dashboard.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd package
Packages the application's code to be deployed to Azure. (Beta)
azd package <service> [flags]

Options
      --all                  Deploys all services that are listed in azure.yaml
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for package.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd pipeline
Manage and configure your deployment pipelines.
Options
  -h, --help   Gets help for pipeline.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline config: Create and configure your deployment pipeline by using GitHub or Azure Pipelines.
Back to top

azd pipeline config
Create and configure your deployment pipeline by using GitHub or Azure Pipelines.
azd pipeline config [flags]

Options
      --auth-type string        The authentication type used between the pipeline provider and Azure for deployment (Only valid for GitHub provider). Valid values: federated, client-credentials.
  -e, --environment string      The name of the environment to use.
  -h, --help                    Gets help for config.
      --principal-name string   The name of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-role string   The role to assign to the service principal. (default "contributor")
      --provider string         The pipeline provider to use (github for Github Actions and azdo for Azure Pipelines).
      --remote-name string      The name of the git remote to configure the pipeline to run on. (default "origin")

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline: Manage and configure your deployment pipelines.
Back to top

azd provision
Provision the Azure resources for an application.
Synopsis
Provision the Azure resources for an application.
The command prompts you for the following values:

Environment name: The name of your environment.
Azure location: The Azure location where your resources will be deployed.
Azure subscription: The Azure subscription where your resources will be deployed.

Depending on what Azure resources are created, running this command might take a while. To view progress, go to the Azure portal and search for the resource group that contains your environment name.
azd provision [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for provision.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd restore
Restores the application's dependencies.
azd restore <service> [flags]

Options
      --all                  Restores all services that are listed in azure.yaml
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for restore.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd template
Find and view template details.
Options
  -h, --help   Gets help for template.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template list: Show list of sample azd templates.
azd template show: Show details for a given template.
Back to top

azd template list
Show list of sample azd templates.
azd template list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details.
Back to top

azd template show
Show details for a given template.
azd template show <template> [flags]

Options
  -h, --help   Gets help for show.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details.
Back to top

azd up
Provision Azure resources, and deploy your project with a single command.
azd up [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for up.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd version
Print the version number of Azure Developer CLI.
azd version [flags]

Options
  -h, --help   Gets help for version.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

it would make sense to have the redirect url be <IP_ADDRESS> instead of "localhost"

Redirection to localhot or <IP_ADDRESS> should not be ever allowed in Prod.
There should be a service for azd to receive the token and the azd cli should be pulling from that server to get the token.
The az cli should be doing that as well.

@ellismg Please call me out if I'm not looking at this correctly. netgo was added as part of this commit.
We did not make changes to netgo as part of #1599. The change there was a debug change that wasn't removed, removed subsequently in #1647 with the change to remove alpinefrom testing, as there are inconsistencies between the c library used. The decision there was to continue enablingcgo` since it is indeed used in deep parts of *nix systems. I was not sure about the usage on Windows.
My personal preference is that azd should work on most systems. The cost of maintaining cgo is worth it (until we hit a real technical hurdle).


Workloads - Deployments UI enable the Create button without a Name but Name is required

Rancher version v2.5-alpha1 (08/28/2020)

Rancher version: master-head (09/17/2020) _ 33f755f_
Validated all the workload types Create view. Filling all the required inputs in the UI form in different order also honors the rules to enable the Create button.
Checked the Edit for completeness.
Cancelling and Preview YAML works too.


update list of selenite games

What links though?

https://selenite.cc
https://selenite.pages.dev/
https://selenite.skysthelimit.dev/
https://selenite.is-a.dev/
https://all-about-science.onrender.com/
https://robotics-docs.onrender.com/
https://contact.deleesportsmedicine.com/
https://learn-at.undo.it/
https://fediverse.faefox.org/
https://projects.blueshadows.cl/
https://contact.zverovich.net/

You might want to make new onrender links, they don't work.

i should remove the onrender links, theyre gonna change a lot bc i hit bandwidth limits quickly


Ping protocol in uAgents

We need a ping protocol in uagents. This will allow AI Engine to filter out agents that are not active. Today AI Engine picks up any agent. This can include agents that are not reachable and active.
cc: @ejfitzgerald

I feel it might be worth discussing alternatives, so here are my thoughts:
Assuming we have a ping protocol, sending out a ping message can result in 2 things: 1) the target agent is active/online and returning a ping or 2) the target agent is not active and the connection times out.
Without a ping protocol one would get the same behaviour by sending the intended request message. The only difference is that in case the target agent is active, the reply can directly be used.
I assume that the reason for thinking about a ping protocol is that when looking for agents for a task, the ai engine does not know yet which agent the user will choose, but we want to no the active state before suggesting it to the user. So what about the alternative of sending an actual request even before user selection? In the positive case (target agent is active) there are again 2 possible situations: 1) the ai engine can already compute a valid context or make a useful guess. In that case the result can be cached and directly returned / used should the user select this task. 2) Ai engine has too little information and needs to create a bogus context/request. In this case the reply only indicates the lifeness, but a new and useful request must be created. In the negative case we don't send more messages compared to the ping scenario at the cost of precomputing potentially wasted contexts. In the positive case we save a message and gain some responsiveness upon task selection.
@qati needs to advise how often it might be feasible in general to precompute contexts before selection and the overhead this might induce.
We had similar concerns a while back and discussed to add a deregistration functionality to the almanac such that it only returns active agents. However, this obviously doesn't change the situation for agents that are simply abandoned or drop out due to connectivity issues, if we don't tighten the almanac registration timeout or include a heartbeat protocol at this level.
Key question here: Does the ai engine always resolve via the Almanac API or does it only check it's own listings DB? (I.e. would you even try to contact agents that already timed out on the Almanac?)
Conclusion at that time was that the inherent timout of the almanac registration period would be enough to deal with inactive agents.
Long story short, I can see the requirement but it feels a bit like a workaround of our own intended architecture and functionality and I think it's worth resuming the discussion to extend/change Almanac functionality, or considering wrapping such functionality that is only needed in the context of the ai engine into a separate module outside of the core microagent framework to only be included by agents connecting to the ai engine.


Where is arm64 v8 version from IzzyOnDroid?

In the GitHub releases.
On Wed, 19 Jun 2024, 00:45 DeadSecTr, @.***> wrote:

—
Reply to this email directly, view it on GitHub
https://github.com/deckerst/aves/issues/1053, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKBEXN2YL5QCG54M7IAEULZICZ6ZAVCNFSM6AAAAABJQ5DJBCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DAOBWGU3DQMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Izzy repo does not host large APKs, and a "fat" APK containing all ABIs would be beyond their accepted threshold. The v7 APK is compatible with more devices than the more recent v8.
In any case, if you prefer a specific artifact only available in the GitHub release, you can use something like Obtainium.


[Helios Solarized Light] Popover shouldn't have opacity

Managed to get this on VS Code web using SCM (Git) commit input.

I think I know which workbench settings these are, but I can't trigger the popover on my end.

Remove any custom settings in VS Code web or better clean or better clean like shown below and CMD+SHIFT+R and you should see it.

Feel free to reopen if this patch doesn't fix it.

@santoso-wijaya It works fine now. Thank you ❤


more predictable routes

the routes for the viewer API are currently a bit hectic. I think they could be organised more clearly. Something like
Proposed              Current
=================     ==================

/thread/:id           /msg/%:id
/hashtag/:hashtag     /tag/:tagName

/blob/:blobId         /blob/:blobId

/feed                 /get-profiles
/feed/:id             /profile-by-id/:id
/feed/:id/counts      /counts-by-id/:id
/feed/:id/threads     /feed-by-id/:id

/user/:name           /profile/:username
/user/:name/counts    /counts/:username
/user/:name/threads   /feed/:userName

?                     /default

I'd be very interested which APIs are currently used

what is /default ?
do we need the user/ username ones?


fix: turn off wherever

Description
The whevever widget was completely rugging us with their wagmi version, which was using an old version of walletconnect.
This PR disables wherever until they fix their SDK (I tried updating it to the latest version, but it did not fix the issue).
This also gives us significant performance improvements, as the wherever sdk gets in some kind infinite loop and makes wallet connection super laggy.
Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
Risk
None, except maybe angry users if they use wherever.
Testing
Connect a native shapeshift wallet and check that the console spew has stopped.
Engineering
☝
Operations
☝
Screenshots (if applicable)
N/A

Current dependencies on/for this PR:

develop

PR #4873   👈

This comment was auto-generated by Graphite.


after refactor server attach another project which does not support workspaceFolder

Description
tsserver does not support workspaceFolders, even the server does not support workspaceFolder it still return true.
https://github.com/neovim/nvim-lspconfig/blob/064221eed39e7dc81cf1d27c0d016f4b29a9aad1/lua/lspconfig/manager.lua#L134-L145
simply made _notify_workspace_folder_added return a boolean it will cause another prolem vsplit open two file which in two projects and mksession then nvim -S Session.vim print existing_client.initialized it will be nil when second buffer attached . that mean we can not get the
server_capabilities at that time  reuse_client will return false. before use a timer to wait first server initialized then check it support workspacFolder or not . refactor mentioned add in new_config hook that doesn't make sense.

Is this the successor to https://github.com/neovim/nvim-lspconfig/issues/3456? I'm also having an issue where multiple vtsls servers attach to a buffer upon open.
From my investigation, the issue is repeated (programmatic) calls to vim.cmd.LspStart. Previously, they seemed to be idempotent, but now more LSPs are started with each call to :LspStart.
I ran a bisect:
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
8d9fd3581ac07a2e1940435e13bda31a0cdeb795 (this commit does not run for me at all, it gives a long error)
2eccb418f2f972ad1167f8491a8180acdeb02384


Zoom+Regions example shrinks vertical, not just zooms horizontal (Chrome for Mac)

Bug description
I've noticed that, when using Chrome or Brave,  in both my own code that uses Regions and the Regions Demo, if I move the "Zoom" slider in & out while the audio is playing, the waveform shrinks vertically.  And it keeps shrinking the more you move the slider back & forth  to the point where the waveform's  vertical extent approaches that of  a horizontal line. (Screenshot Below)

This strikes me as unexpected behavior, as having the waveform get smaller & smaller as one adjusts a horizontal slider (and never rescaling back to full height) can pose a problem for repeated usage.
I don't notice any such behavior with the regular Zoom example https://wavesurfer.xyz/examples/?zoom.js
So, somehow the inclusion of Regions is related to this.
Environment

Browsers:

Chrome Version 124.0.6367.208 (Official Build) (arm64) for MacOs
Brave Version 1.66.110 Chromium: 125.0.6422.60 (Official Build) (arm64)] for MacOs

Does not happen with Safari

Minimal code snippet
https://wavesurfer.xyz/examples/?regions.js
Steps to reproduce

Go to Regions example.
Click on the first region marked "Resize me" to begin playing audio.
While audio is playing, move the Zoom slider back & forth.
Observe that waveform shrinks vertically as you do this.

Expected result
Zooming horizontally, i.e., changing pixels-per-second, would not result in (irreversible) changes to the vertical extent of the overall waveform.
Obtained result
Tiny vertical extent to waveform after repeated zooms in & out, with no way to restore full height.
Screenshots

Just updated to Chrome Version 125.0.6422.61 (Official Build) (arm64) and the problem went away!
Brave is at the latest version and still shows problematic behavior, but presumably they'll push an update in the next week.
Since this behavior is demonstrably browser-(version-)specific, this Issue is seems worthy of closing immediately.
Feel free to close.

Thanks! Good to know!


Visual Studio 2005 build fails on IEEE754ExceptionsPlugin.cpp

...\cpputest\src\CppUTestExt\IEEE754ExceptionsPlugin.cpp(34) : fatal error C1083: Cannot open include file: 'fenv.h': No such file or directory
This is the latest code pulled today. Could you fix this as soon as possible. Note: we also compile with 2013 for some projects, but I haven't test that yet.

Unfortunately, VS2005 is not available on Appveyor, so that build doesn't get checked normally.  The project files do get checked since the VS2008 build uses them, just the VS2008 (VC8.0) compiler never gets run.
Actually, looks like the IEE754 files never got added to any of the Visual Studio projects.  With a bit of trial and error, I've narrowed down the version fenv.h was added in to 2013.  I'll submit a pull request containing the various changes to update the project files and build this logic when possible.

Any update? Thanks.

@BillDenton do you actually need the plugin? Or just want to compile? If it is the first, I'm afraid this is not a trivial matter, because the availability of fenv.h is essential to the plugin. If the latter, just remove the plugin and its associated tests from your project.
@Andne if they were never added, how come they are part of the VS2005 build? I think the best option would be to remove them for now. Does VC support checking the IEEE754 floating point flags in any form at all? If so, as of which version?
@basvodde would it be okay with you if we omit the plugin for older version of Ms VC?

@arstrube Fine. Also, the plugin fails on my Mac. One test :) should_not_fail_again_when_test_has_already_failed. But only on some builds.

I'm updating our internal copy of CppUTest the latest version so we have some of the newer macros. So I just need it to compile. I don't think we have used this plugin has I don't think it was in release 3.7.2 so we can't have used it. If it can't be supported in 2005, then just remove it from the build.

@BillDenton What do you use to run the build?  Are you using the Visual Studio solution or CMake?
@arstrube Looks like it supports fenv.h as of 2015, but there's a test failure then.  I have the float exception logic suppressed in all other versions, just introduced a bad comment that broke everything else.  Excluding the files from the solution works, but not if someone is using cmake I suspect and we'd have to always remember why they're excluded.

@basvodde I new I would regret making this part of CppUTestExt, rather than keeping it as a standalone plugin....... :-(

@arstrube I don't :)

It is built from within our build system that uses scons. It builds all the .cpp files in src/CppUTest and src/CppUTestExt. We use 2005 and 2013, but I've only tested 2005 so far. It needs to work for both of these.

PR #948 is merged now, so VS 2005 should build and execute tests fine.  VS 2013 builds but it actually tries to test the plugin, so there's a couple failures there.  The failures are only in the IEEE 754 exception flag logic, so unless you're trying to use it, I doubt you'll see them in typical project usage.

@Andne we aren't going to leave the failing tests as a permanent feature though, are we?

No, we need to fix it, I'm just waiting to see what @basvodde thinks about your proposals on the pull request.  I don't know why the flags work differently, short term it may just be best to disable the fenv tests completely like Watcom does.  I've opened issue #954 to track these test failures and how to resolve them.
@BillDenton Can you please pull the latest code and verify that it works for you now?

Msvc doesn't pick up FE_INVALID. That's basically its only fault. I think it's an understandable one, because I have a sneaking suspicion that the code in functions like sqrt() sets it "manually"; I don't think the processor ever sets it, which is probably why it can't be generated by any simple arithmetic operation.

I've imported the latest code (380450dee251fbc5583cf24ff7932b7991d62bd9) and built with both 2005 and 2013. All successfully compiled and our unit tests passed. We were previously using release 3.7.2.
As far as I'm concerned this issue is closed. Would you like me to close it, or is it useful to keep open to discuss the remaining issues?

I opened a different issue to track the FE_INVALID test, so my vote is that this issue can be closed.

@Andne Will do. Could you or some other Visual C++ person fix the project files and add one file?


Slack OSS Workspace Invite

Hi, my apologies for posting this on the issue tracker (it’s not a code issue), but I’m trying to follow the instructions in the README for joining the Velox Slack OSS workspace. I’ve tried sending an email to<EMAIL_ADDRESS>but I’ve not received an acknowledgement in a couple of days. If it’s just a matter of waiting then I will wait, but if there’s anything that can be done to expedite the process then I would appreciate it.

CC: @jijufb

Hi Christopher, sorry for the delay. We did not receive email for your request. Checking with IT on the actual reason.
Can you share your email address to send slack invitation?

I have give access. Please check.

I can confirm I have access, thank you.


Incorrect URL in 'Back to directory' link within subPages

This bug involves all of the subPages within the subDirectory. The link that is required in the template, ie: the link back to the directory root page needs to be updated. The details are below
Fixing this involves going into everyones subDirectory page. and changing absolutely nothing except for
href="https://github.com/LearnDevelopmentPublic/ReallyAnnoyingDirectory"
to be
href="https://devvit.io/ReallyAnnoyingDirectory/"

I'll take this on 😊


separation of eo, os and sat

Related Issue(s): #722
Proposed Changes:

eo contains sun_azimuth and sun_elevation
new extension os, Overhead Sensor for containing azimuth, off_nadir, and incidence
removal of fields from sat
dropping redundant _angle suffix

PR Checklist:

[ ] This PR has no breaking changes.
[x] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[x] API only: I have run npm run generate-all to update the generated OpenAPI files.

@matthewhanson @m-mohr @anayeaye - could you all review this and let me know what you think? Seems like we should get this in before release, since we've not yet put out anything except rc1 that had our grouping overhaul. See #722 for the context / background on it.

Hmm, for me a RC is something that is basically feature-freeze except for bug fixes. This to me looks like a bit too much to change between RCs. On the other hand, I wouldn't want to change this again for 1.0 and the separation mostly seems to make sense.
Let's get through them one by one:

eo contains sun_azimuth and sun_elevation

That feels reasonable if there's no other data/extensions will be using these terms. SAR is not, but I can't tell whether other extensions would use it. Can anybody think of an upcoming extension that would also be related to sun angles? I'm especially thinking about Sentinel 3+, but most seems only EO related.

new extension os, Overhead Sensor for containing azimuth, off_nadir, and incidence

The prefix os seems not so intuitive and helpful. I'm thinking whether there's a better prefix that describes the fields better?

dropping redundant _angle suffix

Hmm, especially for incidence and azimuth I found the _angle prefix good in better describing the field. Incidence is a bit ambiguous (maybe only for me as a non-native speaker) and azimuth is just all over the place (azimuth[_angle], sun_azimuth[_angle], sar:(looks|pixel_spacing|resolution)_azimuth). So I think I'd prefer to leave the suffix in.
This PR HAS breaking changes so I unticked the box.

The prefix os seems not so intuitive and helpful. I'm thinking whether there's a better prefix that describes the fields better?

Is it that the abbreviation makes it confusing? If it is that Overhead Sensor isn't a good field we could use Capture Angles?

Hmm, especially for incidence and azimuth I found the _angle prefix good in better describing the field. Incidence is a bit ambiguous (maybe only for me as a non-native speaker) and azimuth is just all over the place (azimuth[_angle], sun_azimuth[_angle], sar:(looks|pixel_spacing|resolution)_azimuth). So I think I'd prefer to leave the suffix in.

Azimuth, incidence and nadir as concepts are specifically about angles, so the _angle usage seems redundant.

This PR HAS breaking changes so I unticked the box.
Understood. I'd created an issue and made suggestions for changes, I didn't want someone else to have to slog through the work of making the changes.

Also, this PR needs some more work. stac_extensions fields are often not updated for example.
If you could point out to me the places where I need to fix it up, I'm happy to do the work.

Don't get me wrong, I really appreciate all your background work on this, @davidraleigh .
Absolutely! I'm stoked to help get this sorted for 1.0 release

I've added some comments here: https://github.com/radiantearth/stac-spec/issues/722#issuecomment-584195639
Summarizing:

I'm good with removing _angle if other people agree
I still think all angles, including sun angles, belong in one extension

I like the name overhead_sensor for the extension, and the prefix os seems fine to me.

@m-mohr - yeah, I'm conflicted on RC being 'bug fix', but I think from the standpoint of a user who is just using our stable releases 0.9.0 is going to be the first time they see a lot of changes in prefixes. Like I view all the common changes we've made as 'unreleased' as of yet. So it seems better to me to get the first release 'right', then to put out 0.9.0 and then turn around and do a 0.9.1 or wait till 1.0-beta to do these changes, if we agree they're the right one. And I'd guess I see release candidate as 'this is what we believe the release should be', and if the feedback is more than a bug fix we should change it.
As for specifics in this:

I agree with @m-mohr on the os prefix not being great. The key point to me is that seeing a prefix like 'sat' or 'eo' you know what it is about. I'd interpret 'os' as 'open source' or 'ordnance survey' - though I think overhead sensor is the right name it is not a well known name / abbreviation. I'm not sure that I have any better idea, and I think it may be ok if it's just a less good prefix. One idea might be to use the prefix 'angles:' - a bit longer than normal, but then we could take off the suffixes. Perhaps then go with 'capture angles' for the prefix name.

I did like the angles suffix, as it makes things quite clear. So I'd say keep it, unless we go with the angles prefix, in which case it'd be pretty redundant.

And I'm nuetral on all angles being in one extension.

Okay, fine to do it for 0.9, @cholmes .

Is it that the abbreviation makes it confusing? If it is that Overhead Sensor isn't a good field we could use Capture Angles?

Overhead sensor in general seems to be about right for grouping the fields. It's just that "os" is a bit overloaded as Chris said and not self-explaining. "overhead_sensor" is probably too long and "sensor" too broad.
In general, I'd like the prefixes to me more descriptive, for example we once had "dtr:datetime_start", which I'd have preferred to be "datetime:start". Then, when moving fields to core, you'd in general just need to replace the ":" with "_". I'm even not a fan anymore of my own "cube:dimensions" and think it should be "datacube:dimensions". We already have this problem with "eo", which is electro optical, but most people think "earth observation". It may have been better to use the "spectral" prefix or so. But overall that's a matter of taste and @matthewhanson for example preferrs shorter obviously.
I'm not a fan of using the "angle" prefix as it would limit the extensibility of the overhead sensor extension to just contain angles. Would be a different thing if we group all angles. I'm undecided whether that's a good idea or not.

Azimuth, incidence and nadir as concepts are specifically about angles, so the _angle usage seems redundant.

Only if you think about incidence in our context. In general, I'm thinking about software incidence management and other things first. It only really bugs me with incidence, the others are mostly fine as is although for SAR it could be a bit confusing with so many occurances of "azimuth". So I'm leaning towards adding _angles again. We don't really loose anything, just make it a bit more clear. Or is there any disadvantage in having them?

If you could point out to me the places where I need to fix it up, I'm happy to do the work.

In all example files you edited you need to check whether it needs to be changed. Also, you need to add the extension prefix to the JSON Schema for items. I'm just about to head home so don't have the time to request the changes explicitly now, but will see what's left to do the next day(s).
Thanks!

The overhead sensor fields are really "viewing geometry", but that's not any shorter, and 'geometry' is way too overloaded to use.
What about "view". It would be a viewing extension, and provide fields such as view:sun_azimuth_angle.

Things to do:

Update stac_extensions for items (not collections), for example here: https://github.com/radiantearth/stac-spec/blob/e6df7a1556342b766074f942abfd3bb71bbb3ab4/extensions/eo/examples/example-landsat8.json#L4 and probably in most of these files: https://github.com/radiantearth/stac-spec/tree/e6df7a1556342b766074f942abfd3bb71bbb3ab4/item-spec/examples
Update JSON Schema to include the new extension: https://github.com/radiantearth/stac-spec/blob/e6df7a1556342b766074f942abfd3bb71bbb3ab4/item-spec/json-schema/item.json#L72
Similarly update the API spec and regenerate it later using npm: https://github.com/radiantearth/stac-spec/blob/e6df7a1556342b766074f942abfd3bb71bbb3ab4/api-spec/openapi/STAC.yaml#L741

Hope it helps.

@m-mohr @matthewhanson @cholmes
updated pull request. (I don't know Alex's github handle).
@m-mohr I made the changes, but I'm not sure I addressed what you pointed out before:

In all example files you edited you need to check whether it needs to be changed. Also, you need to add the extension prefix to the JSON Schema for items.

Addressed items 1, 2, and 3 in https://github.com/radiantearth/stac-spec/pull/734#issuecomment-584754359

Thanks @davidraleigh.
I checked it more precisely today, there's still files to update:

collection-spec\examples\landsat-item.json
commons\examples\landsat-item.json
2nd and 3rd example in extensions\commons\README.md
Example in extensions\view\README.md
Same file and minor, but it says in the table for view:incidence_angle: "The incidence_angle angle is the angle". I'd remove the underscore: "The incidence angle angle is the angle"
The JSON Schema still says: "Overhead Sensor Extension" in title and description.
There's no link from the extensions README to the new extension.
8 A separate full example in an example folder for the view extension is missing and would be great to have according to the extension guidelines. Maybe it's just moving one over from the item spec (there are quite a lot anyway). Or extend and move the one that is inline in the README.md.
You also still need to run npm run generate-all.

Unfortunately I can't push to your branch, otherwise I'd just committed the changes.

@m-mohr I didn't want to add in any changes that I hadn't seen made when the sat extension was merged in. I'll go ahead and add the additional changes for stac_extensions and other changes now.

Yeah, it seems the sat PR was also a bit flawed, but a good time to fix things. Thanks!

@m-mohr the other pull request wasn't as flawed as the pull request I dropped in your lap. Thanks for putting your eye on it all and identifying the errors.


Bump poetry to 1.7.0

Like the title says, use poetry 1.7 instead of 1.5
Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Docs

[ ] Link to documentation:

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases

@patrys Looks unrelated to your changes but Pytest is falling here.

@maarcingebala It's a flaky test. I sent it to @aniav yesterday, so I didn't restart it to allow some investigation to happen.


The parser doesn't recognize file names when stored in a variable.

pkger parse or pkger list doesn't work when the file name is stored in a variable.
var fileName =  "/bin/file.txt"

// This doesn't work
pkger.Include(fileName)
// This works
pkger.Include("/bin/file.txt")

It seems a solution is to use pkger.Include("/bin/file.txt") for all files you need, then you can use variables elsewhere the program knowing the assets are already loaded.

Yup, that's how I did it eventually, but thank you for the reply. :)


Link bug

@ https://developers.google.com/web/fundamentals/codelabs/your-first-pwapp/#what_is_a_progressive_web_app

Further Reading:
[Using app install banners]

is not sending us to the correct page. I just get sent to the homepage of web fundamentals: https://developers.google.com/web/fundamentals/

Hi!
Thanks for the feedback. I've rewritten the codelab from scratch and believe I have fixed this issue. The code has been updated, and the new guide is now live.
If you find any issues with the new codelab, please let us know!
Thanks!


glGetString(GL_EXTENSIONS) gives EXC_BAD_ACCESS on macOS 10.12

This piece of code terminates with segfault.
sf::ContextSettings settings(24, 0, 4, 4, 1, sf::ContextSettings::Attribute::Core);
sf::Window win(sf::VideoMode(1366, 768), "OpenGL", sf::Style::Default, settings);

std::cout << glGetString(GL_EXTENSIONS);

Encountered this problem when trying to create sf::Shader objects.
Adding window.setActive() doesn't help. Trying another >3.2 contexts doesn't work either.
Console gives always this output:
Error. Unable to create the context. Retrying without shared context.
Warning. New context created without shared context.

Please use the forum for discussing issues with your code. We like to reserve the issue tracker for confirmed bugs and features only as stated in the mentioned Contribution Guidelines.
32bit depth is most likely not supported, given that it's a rather uncommon mode.

This is not a problem with 32bit depth, also tried with 24, there is 32 because I tried every option to make it work and forgot about it.
I've already consulted this on your IRC. If you're closing issues just like that, with no interest in solving problems, then I should stop using SFML and look for other library with helpful community around it. I've spent over an hour on this, I've made myself sure there isn't mistake in my code and I am not interested in registering on some forum. GitHub should be used for issues, not some bulletin boards.
Really disappointed, I liked SFML until this moment.

If you're opening issues just like that, with no interest in helping properly identify problems, then you should stop and consider how many hours we lose with false report, why we decided to have some guidelines to report issues, and follow them to be helpful to our community. Thank you.


Revert "nixos/gitea: set service type to notify"

Description of changes
This reverts commit b61919e5e0b4a6ad12eededfee4af703a9182c4e. of #243883.
As it breaks Forgejo who does not support this feature yet.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@ofborg test gitea forgejo

I gotta say, I'm not a very big fan of this. Can't we create a forgejo module which does these kinds of fixups and uses services.gitea internally? Or at least do an if-else on cfg.package for that?
Disclaimer: my personal opinion of forgejo isn't very high. To me it mostly seems like a rebranded clone that releases a few days to weeks after gitea and I'm not very faithful that such a fork will last in the long-term, so I'm not very keen on having to having to look after it whenever I have to touch the gitea module & package.
But to be clear my stance is heavily influenced by my personal - granted, rather negative - opinion (and I wouldn't call it objective because of that), so if everyone else has a different take on this, I'm fine with getting overruled here.

ofborg test failure on x86_64-linux is unrelated.

Quoting @RaitoBezarius from #244840

We made the decision in the past to share Gitea and Forgejo codebase [...]

I guess we could reconsider that.
I am not against separating them.
If anything, probably slightly in favor of doing so.
But it would lower the Bus factor slightly.

If you will, let's do a separation and we can revert the revert, once
everything is good, does that work for you all?
Le sam. 22 juil. 2023 à 16:38, Emily @.***> a écrit :

@.**** approved this pull request.
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/244843#pullrequestreview-1542103526,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACMZREUTGAX5MQV7WR66XTXRPQVPANCNFSM6AAAAAA2T3SNBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Can we please not hastily revert things because they broke something somewhere else when we alternatives like making things conditional? Thanks

Can we please not hastily revert things because they broke something somewhere else when we alternatives like making things conditional? Thanks

No, reverts are fine whenever they break something because they were merged hastily.

@ofborg test gitea forgejo

@Ma27 is it okay for you if we proceed with this revert and then we follow up with the split, then revert the revert?

No, reverts are fine whenever they break something because they were merged hastily.

With all due respect, I have to disagree here:

the new version was running on at least my infra for a few days
there was no indication from CI that something's off
I'm pretty sure that I wasn't even really aware of the situation: just checked, I'm not subscribed to the init PR (https://github.com/NixOS/nixpkgs/pull/207796) and I've seen an alternative PR earlier which also added a new module (I think I've seen that the tests were recycled somehow, but I haven't payed close attention here, because I'm not a forgejo maintainer)

@Ma27 is it okay for you if we proceed with this revert and then we follow up with the split, then revert the revert?

Go for it.
Me being unhappy with the situation is not a reason to let forgejo admins suffer (considering that we have a workaround that is OK and also quite trivial) :sweat_smile:
However, for the future we should do some things differently:

it should be made sure that on CI runs both forgejo and gitea get tested as long as parts of the module are shared
I'd like to see a "forgejo-fixup.nix" (or something similar) that basically makes sure that forgejo works fine (e.g. systemd.services.gitea.serviceConfig.Type = mkIf (cfg.package.pname == "forgejo") (mkForce "simple") - just as an example) that should be maintained by the forgejo maintainers.

Also, I don't really have the time (nor am I really interested in investing time into forks of the software I use), so I'm not up for the job I'm afraid.

No, reverts are fine whenever they break something because they were merged hastily.

With all due respect, I have to disagree here:

the new version was running on at least my infra for a few days
there was no indication from CI that something's off
I'm pretty sure that I wasn't even really aware of the situation: just checked, I'm not subscribed to the init PR (forgejo: init at 1.18.0-rc1-1 #207796) and I've seen an alternative PR earlier which also added a new module (I think I've seen that the tests were recycled somehow, but I haven't payed close attention here, because I'm not a forgejo maintainer)

Ma27, I think you do a great job and I believe you very well tested the Gitea part, I think what is important to see here is how Forgejo maintainers feels regarding the whole situation.
A PR was opened to bump the Gitea version, this is usually fine as long as it does not touch the Gitea module as it was decided in https://github.com/NixOS/nixpkgs/pull/210790#pullrequestreview-1249115932 by @SuperSandro2000 to not share the module. Moving on, you introduced 2 days ago the change that caused this breakage here: https://github.com/NixOS/nixpkgs/pull/243883#issuecomment-1644559805 and it was merged yesterday after an approval 3 hours after.
This is a premature merge from the views of Forgejo maintainers and a frustrating one because they are not put in reviewers list, they have to actively monitor any change and they don't necessarily proactively set code owners to get pinged.
Now, I can agree there is a communication problem lurking, but from end-users perspective, those changes could have led to more problematic issues. This is why I qualify this as a premature merge and one that is usually reverted as soon as possible because it also reduce the breakage until all stakeholders can discuss and figure out a path forward.
The whole problem with "something in CI is off" is hard to use as an argument when ofborg is broken and I believe you when you say you were not aware of the situation.
Again, no offense — you are doing, in my opinion and experience, an amazing job, nevertheless, I sympathize with @emilylange here who can be understandably unhappy with the whole situation and this is not your "fault" per-se.
So please do not take this personally.

Go for it.
Me being unhappy with the situation is not a reason to let forgejo admins suffer (considering that we have a workaround that is OK and also quite trivial) sweat_smile
However, for the future we should do some things differently:

it should be made sure that on CI runs both forgejo and gitea get tested as long as parts of the module are shared
I'd like to see a "forgejo-fixup.nix" (or something similar) that basically makes sure that forgejo works fine (e.g. systemd.services.gitea.serviceConfig.Type = mkIf (cfg.package.pname == "forgejo") (mkForce "simple") - just as an example) that should be maintained by the forgejo maintainers.

Also, I don't really have the time (nor am I really interested in investing time into forks of the software I use), so I'm not up for the job I'm afraid.

Let's do a complete split up as it should have happened in that previous PR I mentioned so that both maintainers will not have to interact directly in the same environment.
To all stakeholders: feel free to put load on me to coordinate the split-up/reviews/etc. I want to ensure that everything goes smoothly for everyone and so we can move on.

Why did you merge this!?

This is a premature merge from the views of Forgejo maintainers and a frustrating one because they are not put in reviewers list, they have to actively monitor any change and they don't necessarily proactively set code owners to get pinged.

Nothing was merged premature. The PR was open for 4 days and contained a security update. We had at least 4 people involved in the reviewing process.

How does everybody feel about updating to a forgejo release candidate early? See https://github.com/NixOS/nixpkgs/issues/244866

For completeness I'd also like to leave a message here: even though it got a little more heated than usual in here this thread was good to understand each others' issues in the entire gitea/forgejo topic.
My concern was that people would get a wrong impression of how things were handled on the initial package bump[1], but it was also an important reminder for me that things became pretty frustrating for the forgejo maintainers recently (and that's totally understandable!) which is why I attempted to reduce the tensions in #244866 .
Yes, that's just a summary of things that I felt were good to be mentioned in here as well, but I still felt it's important for full context and because I don't take all of this lightly.
[1] yes, the forgejo thing happened and another regression - see #241497 - was because of a misunderstanding from my side missed and I'm perfectly fine with admitting that! What I stated above and I'd like to restate here is that I think we've taken our job serious in the package bump PR even though things slipped through.