Parent execution revision

This revises the parent execution ordering fix for https://github.com/tc39/proposal-top-level-await/issues/64 (previously https://github.com/tc39/proposal-top-level-await/pull/71), while also ensuring that cycles transition in a well-defined way.
This retains the parent chain execution semantics when an asynchronous dependency is added, without causing any execution ordering changes. For example with this approach, sync modules can provide polyfills that will execute before async dependencies in order. The spec diff has simplified down quite a lot in the process.
Consider for example:
main.js
import './dep.js';
console.log('main');

dep.js
console.log('dep');
Promise.resolve().then(() => {
  console.log('dep task');
});

the log when importing main is "dep", "main", "dep task".
If we add a dependency to dep.js that does not use top-level await, we retain the "dep", "main", "dep task" ordering.
But if we add an async dependency to dep.js:
dep.js
import 'async-dep';
console.log('dep');
Promise.resolve().then(() => {
  console.log('dep task');
});

then the ordering becomes "async-dep", "dep", "dep task", "main".
The problem with the above is that the timing of the parent modules relative to eachother is changed by introducing an async dependency.
This PR resolves that so that the execution semantics of the parent ordering and timings remains the same, to provide the output "async-dep", "dep", "main", "dep-task".
This is achieved with global completion handlers on module execution that manage the graph state transitions.

I've gone ahead and polished up the implementation quite a bit... the spec had a few gaps caught between refactoring. Some implementation notes to describe the approach further:

I ended up implementing an "evaluating-async" state here finally to ensure the handlers can easily tell when a module is completed by "evaluated" well and truly meaning evaluated.
[[AsyncParentModules]] are graph references created during InnerModuleEvaluation, representing the back-references on the exact acyclic post-order tree of execution for the unique initiating top-level execution job. This tree has no repeated dependencies or cycles, so is a direct representation of the execution ordering representing the graph of "responsibility for" the execution of the module. If any dependency is already "evaluating-async" when running InnerModuleEvaluation, then we add a listener to the [[EvaluationCapability]].[[Promise]] instead of registering in [[AsyncParentModules]], because the other top-level job got to own the execution ordering.
[[EvaluationError]] is now stored properly on async modules, although this is still something that could go either way and I'm open to feedback on this.
When there is an error, the error is propogated to the [[AsyncParentModules]] first, calling their error handlers in turn, before the [[EvaluationCapability]] rejection is fired. This [[AsyncParentModules]] reporting will go straight up the direct singular path up the tree to the top-level module causing its failure transition synchronously (and cycles will always fail synchronously together, a feature as a consequence of this PR approach). The rejection order also remains true to the importer order.
It might make sense to call [[AsyncParentModules]] and [[PendingAsyncDependencies]] something that more clearly explains their role in the top-level job. Perhaps [[ExecutionParents]] and [[PendingAsyncChildCnt]] or something like that? I'm open to suggestions here.
The call conventions around the way the builtin functions for AsyncExecutionRejected and AsyncExecutionFulfilled are created can probably be adjusted. I wasn't quite sure how to make it such that it could be called both as a method and a builtin function for resolutions.

The above is the simplest approach for this logic flattening to get better deterministic guarantees around sync completions in the semantics that I could find after experimenting with various different approaches.
Look forward to review in due course, and happy to answer any questions further.
//cc @GeorgNeis

Thanks for this detailed refactoring. Seems like there are a lot of good improvements in this version. I really appreciate how the volume of spec text keeps decreasing.
I am still wondering if it's possible to eliminate the [[Async]] internal slot, and to let the "evaluating-async" state just be "evaluated", as in the original #51, but it will take me some more time to think all this through.

I managed to add a further refactoring here to cut down on the number of fields and also to ensure evaluation errors always propagate synchronously through all subgraphs, effectively reducing the "memory footprint" of the algorithm.
I haven't gone into much detail yet on how better guarantees are provided around cycles with this PR, and with the current approach, cycle handling is pretty much the main complexity. So I wanted to just provide an example to hopefully clarify some of this logic.
Consider the following graph (excuse the terrible image):

Where A is the top-level module being imported, and the numbers next to each of the modules are the DFSIndex and DFSAncestorIndex. In this example, all modules except for E are in the same strongly connected cycle unit (DFSAncestorIndex 0). E is a dependency of this cycle. Assume every module is async for the purposes of this example since this example is about async cycles not the sync behaviour interactions which are the simpler ones :P
The execution order of this graph is D,B,E,C,A, where B, C and A will only execute after their depenencies have completed.
Synchronous Behaviour
Now usually if this were a sync graph and there was an execution error on any of the modules, say on D, we would have "stack" containing A,B,D, all three of which would immediately transition to an error state. C and E wouldn't actually be in the stack, and would thus remain in an "instantiating" state (since they haven't been visited yet), where instead they would throw if you tried to import them later on, since their dependencies have cached errors.
Asynchronous Behaviour
So what is the analog in the async cycle case?
Instead of relying on "stack", we populate AsyncParentModules for any async module in the graph that isn't executed immediately in InnerModuleEvaluation.
So B points to A. D points to both B and C. A has no AsyncParentModules as it is the cycle root for this top-level evaluation.
So if there is an error when asynchronously executing D, AsyncEvaluationRejected will propagate the error up through the AsyncParentModules, which is unique to this cycle. So we call AsyncEvaluationRejected on the modules in this order: D, B, A, C, immediately transitioning all those modules together as a strongly connected component to the failure state. This is very similar to the stack approach although slightly different in that we also transitioned C (although note that an error on B would not have transitioned C or D).
Top-level cycle dependencies
Where cycles get tricky is when we throw other top-level evaluation jobs into the mix.
If we had another module F dynamically imported after A, which imported say D, while the cycle modules are still asynchronously evaluating, what we don't want is for F to start executing on completion of D, even though the whole cycle has not finished yet. We want to ensure that F only executes after the entire cycle has finished executing.
The way we do this is by treating the first execution of the cycle as taking "ownership" of the cycle (and effectively owning the DFSIndex and DFSAncestorIndex values - these are never be changed by any future importers). Then when importing from a cycle that has already moved into an "evaluating-async" phase (a sync cycle would move straight to "evaluated" so we wouldn't have any of these problems), we attach the execution to the root of the cycle.
So we try import D, which is currently in an "evaluating-async" state. We then walk up the AsyncParentModules of D until the DFSIndex matches the DFSAncestorIndex representing the root of the cycle at A using the GetCycleRoot abstract method. We then add F to the list of AsyncParentModules list that should get completion handlers applied on resolution or rejection of the cycle.
If D completes successfully, but then E gets evaluated causing an error, that error is propagated up to A, and then propagates up to F, all in a well-defined way avoiding any partial states of the graph.
Hopefully that explains how these fields handle the complex edge cases quite elegantly. I've included lots of assertions around cycles in the algorithm to make these invariants clear.

Here's an interesting open question about cycles and error handling.
Let's consider the a graph where A depends on B and C, B depends on A, C depends on D, and D depends on A.
So the execution order is B, D, C, A, where B and D execute immediately, C executes after D completes, and A executes after both B and C have completed.
Now if there was an asynchronous rejection for B, while D was still in progress, should the completion of D's execution still go ahead and execute C, or should D's execution completion check and see that the cycle has errored and stop execution entirely?
I get the feeling we should probably do the latter?
The spec in this PR doesn't currently include that but we can add that check in roughly one or two lines.

I really like the simplifications in this patch version. Great job thinking through all the cases in https://github.com/tc39/proposal-top-level-await/pull/74/files#issuecomment-491547656 . After thinking it through a bit, I agree with your judgements there (especially the cycle root technique, which is tricky). @zenparsing previously asked about reentrancy for this algorithm, and I think you've done a good job there.
There are a couple issues with the way this is written up which I think could use some edits before landing:

When a sync module depends on an async one, and something else depends on that async module, I think the logic here breaks down. I think we should be using the parent dependency graph all the time, not just for [[Async]] modules, for this reason.
I'd like ExecuteModule to have a signature that can work for other module types. The current draft passes in the Promise capability into ExecuteModule, but this PR removes that and creates the capability inside. I'm wondering if we should do a third thing, and just expose abstract algorithms for reporting success and failure for module loading, which could be called either synchronously or asynchronously. Then, [[Async]] would actually be something in the Source Text Module Record, actually.
Seems like some cases are missing for resolving the [[TopLevelCapability]], resulting in a never-resolved Promise. For example, if Evaluate() is called while the module is already evaluated. I don't see a path for calling [[Resolve]] on synchronous modules, either (but presumably that'd go away per the previous point). I'm wondering if we should just make this Promise unconditionally, and maybe include a Note that it's not used anywhere except at the top level and can sometimes be optimized away.
Optional/later: I wonder if we should construct the graph pointing to the parents during the Link phase. I think this would let us get rid of the "evaluating-async" phase. On the other hand, it means that Link would pin things up to the graph to get executed, without waiting for the next phase to make that happen. I'm not sure what, if any, embedding environments might Link far before they Execute, in the context of multiple subgraphs coming in over time, though.
Optional/later: You wrote up some great text about motivation in https://github.com/tc39/proposal-top-level-await/pull/74/files#issuecomment-491547656 . Let's see if we can work this in in notes in the specification, or at least the explainer, so it's less cryptic to folks who come along later.

I'll be trying to fix these up.

At a high level, I do like the idea of this change. It's taken me some time to understand why we wouldn't want to use Promises for the reactions, but I do see the logic in the ordering that you start with here. This kind of change seems completely consistent with the possibility of host environments inserting more pauses/yielding to the event loop/microtask checkpoints, which they could do by wrapping Source Text Module Records in something which adds that logic. And some of that logic could also be added from JavaScript by wrapping one module in another which uses top-level await! So I'm getting convinced that doing these reactions synchronously is the most reasonable, least opinionated sort of way to do this, and forms a good basis for opinionated constructs on top.

There's an editorial choice we could make in organizing this specification: Should we build the dependency graph up front (and have all evaluation be based on it), or should we built it on-line, just for the edges that are necessary due to async-ness? This patch goes with the former choice, but I was initially thinking of the latter. I'm not sure which one is conceptually simpler, or easier to understand for various people reading it. I'll probably stick with the choice in this patch for now.

When a sync module depends on an async one, and something else depends on that async module, I think the logic here breaks down. I think we should be using the parent dependency graph all the time, not just for [[Async]] modules, for this reason.

We do do this in this spec, and that is done by checking the "evaluating-async" module status. When the sync module depends on the async module, its state is put into "evaluating-async". Similarly if any module depends on any evaluating async module, it attaches to the completion in the graph.
Note that the "evaluating-async" state is important exactly because this attachment only happens while the module is still executing. Once it is executed there is no attachment to the completion event, and "evaluating-async" moving to "evaluated" gives us this information.

I'd like ExecuteModule to have a signature that can work for other module types. The current draft passes in the Promise capability into ExecuteModule, but this PR removes that and creates the capability inside. I'm wondering if we should do a third thing, and just expose abstract algorithms for reporting success and failure for module loading, which could be called either synchronously or asynchronously.

The capability approach seemed the simplest and lowest-diff way to achieve this, but we could certainly look at other approaches. The capability approach was exactly used in the early 2014 draft of module algorithm briefly in ECMA262 by Jason Orendorff that specified the loader, and I remember finding it quite a useful pattern back then, but if you think there's a better way certainly let's do that.
Agreed it could be worthwhile to update this approach to ensure it works for other module types by lowering some of the loading information like AsyncParentModules and the other fields down to Cyclic Module Records or even Abstract Module Records to support this. If that seems odd, this information could even be its own "table" which represents the in-progress load state.
Happy to discuss this further / work on this as well, but I was just focusing on getting Source Text Modul Records right first!

Seems like some cases are missing for resolving the [[TopLevelCapability]], resulting in a never-resolved Promise. For example, if Evaluate() is called while the module is already evaluated. I don't see a path for calling [[Resolve]] on synchronous modules, either (but presumably that'd go away per the previous point). I'm wondering if we should just make this Promise unconditionally, and maybe include a Note that it's not used anywhere except at the top level and can sometimes be optimized away.

I wanted to avoid the need to create a promise for every single module, as that just seems like wasted memory overhead to me. Just having promises for top-level jobs to ensure cycle resolution matches is all we need really.
We could be populating a promise for every module, it's just wasted work that's all.
If a module is in the "evaluating-async" state (including sync parents of async modules, which synchronously transition to this state when Evaluate runs), then the attachment to the completion is handled entirely by AsyncParentModules, which also gives us a well-defined execution transition from one completion to all possible parents.

Optional/later: I wonder if we should construct the graph pointing to the parents during the Link phase. I think this would let us get rid of the "evaluating-async" phase. On the other hand, it means that Link would pin things up to the graph to get executed, without waiting for the next phase to make that happen. I'm not sure what, if any, embedding environments might Link far before they Execute, in the context of multiple subgraphs coming in over time, though.

Instantiate is effectively asynchronous as it happens while modules are fetching through HostResolveImportedModule I believe? As such, one slow module might hold up the tree, whereas another top-level evaluation job that shares a lower dependency could have already executed that dependency.

Optional/later: You wrote up some great text about motivation in https://github.com/tc39/proposal-top-level-await/pull/74/files#issuecomment-491547656 . Let's see if we can work this in in notes in the specification, or at least the explainer, so it's less cryptic to folks who come along later.

That would be great!

There's an editorial choice we could make in organizing  this specification: Should we build the dependency graph up front (and  have all evaluation be based on it), or should we built it on-line, just  for the edges that are necessary due to async-ness? This patch goes  with the former choice, but I was initially thinking of the latter. I'm  not sure which one is conceptually simpler, or easier to understand for  various people reading it.

This patch only builds up AsyncParentModules when there are pending executions, so is actually the second case you describe and not the former case.
Finally, did you have any thoughts on ensuring we stop executions of further async modules in a cycle after any error in that cycles as in https://github.com/tc39/proposal-top-level-await/pull/74#issuecomment-492010121? I'll gladly add a further commit to support this.

Correction: instantiation appears to be a synchronous operation in the spec, under the assumption that another mechanism has already ensured the dependencies are available it seems, so that HostResolveImportedModule must be sync.
If this is the case, we could certainly move some logic into instantiate, but please confirm this first?

I would be interested to see that patch. I can't form an opinion until I understand better the semantics you are thinking of.
Thanks for explaining the motivation for phrasing the patch as you did. As I explained above, there are several missing pieces of logic in the algorithms, and some logic should be moved from STMR to CMR to enable other module types, so I will try to write these up in a conservative way without those bigger changes.

Ok, I've pushed a commit with support for stopping execution if any modules in the cycle have failed, which requires its own specific check to support.
I believe the approach here is fully algorithmically correct. I tried to clarify above how ExecuteModule promise handling and sync modules depending on async modules are all well-defined, so if there's anyway I can answer further or discuss on chat I'd be happy to do that. The lowering would be great to see though, so thanks for working on this.

That last change LGTM. I suppose we could simplify that microscopically further because been only ever need to check the cycle root's evaluation error, not our own one, right?

Some edits at https://github.com/guybedford/proposal-top-level-await/pull/3 . I think these are required for correctness. Find details in their commit messages.

@littledan great, I've commented on the PR there.

I suppose we could simplify that microscopically further because been only ever need to check the cycle root's evaluation error, not our own one, right?

Unfortunately not, consider the example from https://github.com/tc39/proposal-top-level-await/pull/74#issuecomment-491547656, where D has completed execution, and B and E are in progress. If there is a failure on B while E is still in progress, it gets reported up the AsyncParentModules to the root, but because E is a leaf, it will still want to move to executing C unless we explicitly check the cycle root A for any error from other branches.

(So we need to check both C and A's completions because C doesn't participate in the cycle, it is just a dependency of it)

Landing this and will land guybedford#3 immediately afterwards.


Sourcing Directory in BirdNet under Batch Upload not Working

Describe the bug
Batch files do not load under the input directory (recursive). Certain folders will populate and are able to be analyzed, but other folders, some with fewer files and others with more files, are not located by the software. For example, a folder with 3,000 flac files was successfully analyzed, but for a folder with 2,800 files, no files were found by Bird Analyzer.
To Reproduce
Steps to reproduce the behavior:
I am not sure if this behavior can be reproduced on another device. It may have something to do with processing power, memory, or anti-malware programs.
Expected behavior
A clear and concise description of what you expected to happen.
I expected Bird Analyzer to be able to locate and analyze 2,800 files if it was able to find and analyze 3,000.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. MacOS, Win10]
Version [e.g. 1.0.2]

Windows 10 Enterprise, version 22H2
Additional context
I have also tried folders with varying numbers of files and there seems to be no pattern to what Bird Analyzer can locate and what it cannot. It could locate a folder with 1,200 files, but not a folder with 900. I am confused about what is stopping it in certain situations. Files do not seem to be corrupted, and the folders are saved to my device's hard drive.

Hi there! I have the same issue. It is confusing because whereas my files are hours long and WAY fewer (folders with only 10–15 files, for instance), it works 2/3 of the time like clockwork. I tried re-arranging the files from subfolders not reachable by their recursive inputs BUT BirdNET never works with the folders it previously "couldn't find" using the batch files. Almost like it remembers. I'm going to keep troubleshooting, but this is annoying! Hopefully, they have a workaround or just some general rule. Are there ANY known limitations to file size or number of files?
I would even be willing to process single files, but that option has never really worked for me either . . .

Huh, I am glad someone else has experienced the same problem. It is frustrating for me too because ideally, I'd like to analyze 20,000 files at once. My recordings are 5 days long. BirdNET does seem to remember folders that it has already found. It can continually find and analyze those when it cannot find others. I am unsure about limitations to file size or number of files, but for me it has not been able to find any folders with over 3,000 files.

Reddit proved somewhat helpful in explaining why this happens: https://www.reddit.com/r/BirdNET_Analyzer/comments/1cv61lp/trouble_recognising_folder/
You will not enjoy the solution given the insane amount of files you're trying to process!

Thanks for providing a solution. It's much appreciated. Is the fix to delete the empty files? I looked through all of my files (surface level at least) and they all seemed to be around the same size (200-400 KB).

They may be the same size, but check the last file as it seems to have been created through some dying error on part of the ARU. The last file is my subfolders is consistently "empty" in terms of SOUND, despite having a data size and not appearing corrupt.
Hoping this helps you! :)

You might also give Chirpity a go, it handles large numbers of files and you can do your analysis using the BirdNET model. It's also much quicker to complete the analysis than using the BirdNET GUI. Chirpity is available here: https://chirpity.mattkirkland.co.uk

Thanks for the help y'all. I was looking through the files that Bird Analyzer was not able to find and the last file in every folder did have sound. Lots of crickets and a Tufted Titmouse. I can give Chirpity a try. Thanks for suggesting it!

Fixed in https://github.com/kahst/BirdNET-Analyzer/pull/389 around 3 weeks ago


[bug] [bitcoin-core test] Script sig push only with OP_DATA_X

Issue
The following bitcoin-core test is failing to give the correct result :
ScriptSig: '0x47 0x30440220781ba4f59a7b207a10db87628bc2168df4d59b844b397d2dbc9a5835fb2f2b7602206ed8fbcc1072fe2dfc5bb25909269e5dc42ffcae7ec2bc81d59692210ff30c2b01 0x41 0x0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 0x19 0x76a91491b24bf9f5288532960ac687abb035127b1d28a588ac', ScriptPubKey: 'HASH160 0x14 0x7f67f0521934a57d3039f77f9f32cf313f3ac74b EQUAL'

This code should be passing, but is giving a p2sh not pushonly error. Meaning the code incorrectly thinks there is a non push opcode executing in the script sig.
Replicate
To replicate the issue you can use the latest main branch with the following command:
scarb cairo-run '[[85638276393621973070440747833762038835109559404799393187910797674478057313,86909496337183863383784027065381492514903567749884832550003272325187200050,177363752697333587235310883696927306277866326243318851319289282961132958000,97524436451982317673892134732723748388322835445513126535154450177907057975,179136184789703560512717167442297186868911711012651864941955116552898752800,85638168247374406239538967717457551343685761391366490633594109526334989624,97510519539923601993761630086687932825421787774280843363255809817559839030,180606225255916961601221101003006194707792801503616537556620282464007775024,178791065229179536206708672940427288373183406912420293474234105050176698470,180896097882979158584260668067901388369312854335007770127238730398027888998,93989497426980796014993626649677710159089529955033602953281774031285543221],943219043,4,[127663847454887939587139309636239821037690053989400832659848678725247121252],353288535665911301610098168118721640775750166835370514396478341266096460,30,[],1345475400,4]'

This comment might help some with how to debug : https://github.com/keep-starknet-strange/shinigami/pull/192#issuecomment-2322981566

Hi @b-j-roberts  can I work on this?

@b-j-roberts let me figure this bug out

Hi @b-j-roberts can I work on this?

Hi @b-j-roberts can I work on this?

@jsandinoDev Yes, for sure, I can assign you! Thank you! Let me know if you have any questions

@jsandinoDev Any luck debugging this yet? Did you have any issues?

Hi @b-j-roberts Yes I have been able to debug.
I have found this and I have some questions
The problematic function is is_push_only in the src/engine.cairo file.
Specifically here:

I don't understand the reason for this validation because as I understand the Op_codes are until OP_PUSHDATA4 -> 78
But that doesn't seem to be the main problem, wich is that there are some OP_CODES in this script that are not recognized like:

Am I going in the right direction?


Context Menus

Feature
Please add context menus to the package
Ideal solution or implementation
So maybe add an option were we could choose between / and content when making our code. Here is an example
const { SlashCommandBuilder } = require('@discordjs/builders');
const Discord = require('discord.js')

module.exports = {
	data: new SlashCommandBuilder()
		.setName('ping')
		.setDescription('Replies with Pong!')
                .setType(type),
	async execute(interaction) {
		await interaction.reply('Pong')
	},
};

Context menus are already here since 0.7.0? Are you asking about something else?
https://github.com/discordjs/builders/releases/tag/v0.7.0

My apologies! I was not aware of this. Is there any documentation on how to use it as I was not able to find any?

Builder documentation is now available on the main docs page (select in the top dropdown) at https://discord.js.org/#/docs/builders/stable/class/ContextMenuCommandBuilder


feat: adding examples as part of integration tests and misc fixes

Status
READY
Description
This PR makes a few changes to the automated tests in ibm-generative-ai

Adds the example programs as part of the integration test suite
Modifies a few examples to prevent them from running indefinitely / a long time
Pushes Code coverage to coveralls
Refactors extension tests into their own directory and removes the need for individual pytest markings. Now all extension tests use the extension mark.

Impacted Areas in Library

GitHub Workflows
Extension tests
Integration Tests

Which issue(s) does this pull-request fix?
Closes: #22
Any special notes for your reviewer?

Checklist

[x] Automated tests exist
[x] Updated Package Requirements (if required, and with maintainers' approval)
[x] Local unit tests performed
[x] Documentation exists link
[x] Local pre-commit hooks performed
[x] Desired commit message set as PR title and description set above
[x] Link to relevant GitHub issue provided

Approved and merging!


Parse current s-expression instead of paragraph?

Hi! First of all thanks a lot for this extension, I'm finding it extremely useful.
A slight problem I usually run into is that my smt2 files have empty lines within a single top-level expression, such as this:
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not

(= (+ x y) (+ y x))

))

(check-sat)

Placing the cursor at the beginning of the assert and formatting gives this, which is broken.
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not (= (+ x y) (+ y x))))

(= (+ x y) (+ y x))

))

(check-sat)

So I now usually just remove all empty lines before working on a file, but if this worked out of the box it would be amazing :).
Come to think of it, the current behavior seems useful for formatting a whole chunk of s-expressions clumped together as a paragraph.. maybe there can be a binding to ask for formatting a single s-expression?

I'm glad you're finding it helpful, and thanks for reporting the issue :+1:
I've tried to reproduce the unexpected behaviour:

Formatting the current buffer works as expected but formatting the current paragraph yields a slightly different result.
However, in contrast to your report -- where we see (= (+ x y) (+ y x)) twice -- I'm getting this:
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not (= (+ x y) (+ y x))))

))

(check-sat)

What Vim version are you at? I wonder what exactly the bug is you wanted to report:

does formatting the paragraph really duplicate the expression (= (+ x y) (+ y x)) for you,
or was that a typo and you rather wanted to report the empty line 5 that does not appear when we format the whole buffer?

maybe there can be a binding to ask for formatting a single s-expression?

Sure, if you see need for it. Feel free to open a separate issue and give some examples of the expected behaviour. In particular, what shall happen when you try to format an already nested expression?

Hi Dimitri, thanks for replying. I seem to have left a whitespace in the middle line of the snippet I pasted... so it's not a completely "empty" line. Trying that exact snippet, I get the same behavior you show in the video, sorry about that (though it also shows a problem, as the result is syntactically invalid).
With this one, though, I get what I wrote before:
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not

(= (+ x y) (+ y x))

))

(check-sat)

goes into
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not (= (+ x y) (+ y x))))

(= (+ x y) (+ y x))

))

(check-sat)

So formatting really does duplicate the full expression for me, which makes the file syntactically invalid. The same happens in your video due to the extra )). I'm not sure I understood your (2) point but I don't particularly mind about empty lines, except for this issue of course :).
Vim version is the current one for debian testing
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 03 2023 07:45:49)
Included patches: 1-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919

With the new snippet I can reproduce the problematic duplication. I'll try to look into it.

@mtzguido: I think the new the new branch fixes your issues. To give it a try just go to ~/.vim/bundle/vim-smt2 and check fix/format-paragraph-with-empty-lines our instead of master.
Let me know what you think about it. It should handle even funky cases with multiple S-expressions in a line, such as  the following:
(declare-fun x () Int)
(declare-fun y () Int)

(assert (not false)) (assert (not

(= (+ x y)
   y)

)) (assert (> x y))

(check-sat
)

Hi @bohlender, thanks! This works a lot better for me. I did find one small quirk though, with something like:
(assert (=

(+ x y)

5))
(assert (=

(+ x y)

5))

Using <leader>f on the second assertion will not format properly format either, I just get an extra line break.
(assert (=

(+ x y)

5
))
(assert (=

(+ x y)

5))

<leader>F also gives me a parsing error, but only when the cursor is on the second assertion.

Indeed! Everything seems to work now, thank you!


error: write udp sendto: no route to host

Describe the bug
I want to test udp tunnel and proxy ,with iperf3 , but failed with this "sendto: no route to host"
To Reproduce

run iperf3 server iperf3 -s

run shadowsocks server go-shadowsocks2 -verbose -s "ss://chacha20-ietf-poly1305:hellotheworld4@[<IP_ADDRESS>]:1025" -udp

run shadowsocks tunnek go-shadowsocks2 -c 'ss://chacha20-ietf-poly1305:hellotheworld4@[<IP_ADDRESS>]:1025' -tcptun :1090=localhost:5201 -udptun :1090=localhost:5201  -verbose

use iperf3 clinet to test udp iperf3 -c <IP_ADDRESS> -p 1090 -u

you can see the error log

Expected behavior
iperf3 test success
Screenshots

anyone could help? thanks

In the step 4, you should use the "localhost" as the address.
iperf3 -c localhost -p 1090 -u


Disable failing markdown-link-check for bundesregierung.de site (closes #542)

This PR disables link checking for the links:

[bundesregierung.de]https://www.bundesregierung.de/breg-en/federal-government/federal-press-office)
[bundesregierung.de](https://www.bundesregierung.de/breg-de/bundesregierung/bundespresseamt) and

in

https://github.com/corona-warn-app/cwa-documentation/blob/master/README.md and
https://github.com/corona-warn-app/cwa-documentation/blob/master/translations/README.de.md

The npm package markdown-link-check fails when checking any links to bundesregierung.de due to new security on this site. The check returns a 503 error and declares the link dead. This causes the complete pull_request check to fail, marking any new commits with a failed red ❌.
See https://github.com/corona-warn-app/cwa-documentation/issues/542#issuecomment-795571682 for more information about the reasons behind the error.
The checks have been disabled in this PR using comments in the .md files, only for the paragraphs with the problematic links. All other links are checked as before.
<!-- markdown-link-check-disable --> disables markdown link check. <!-- markdown-link-check-enable --> reenables markdown link check.

@MikeMcC399 Awesome! Great work!

@MikeMcC399 Thank you very much!


OSC Tag creation/Deletion Breaks after having 1 tag

Issue is pretty straight forward, was trying to make tags to consolidate my OSC animations (like combining all off the Pneumaticcraft tools down into one tag) then discovered that since i already had a tag created i was unable to make or delete the original tag. To test this theory I just made a new model and messed around with the tags. Issue persisted after updating from CPM 0.6.16b to 0.6.16c, and CPMOSC 1.5.1 to 1.5.2
https://github.com/tom5454/CustomPlayerModels/assets/59518595/c17c773d-c44b-45c4-84ef-b1e18acc08bb
Luckily im pretty sure i can still make and delete tags via directly messing with the project file outside of MC, but would prefer having it work without the need to do external file manipulation

Ok so small discovery, you can create tags and they will only appear after reloading the model, and they appear in the items.json file inside the CPMProject tags folder.
https://github.com/tom5454/CustomPlayerModels/assets/59518595/91787feb-d39f-4053-a96d-19bbd8b163bd
So, appears i can still MAKE tags, they will just need to be deleted via file manipulation

Looks like i need to do all of my work within a text editor
https://github.com/tom5454/CustomPlayerModels/assets/59518595/d8629bcf-b38e-4a14-99cf-56eb5bf815fc
Error just appears to be that the tag menu doesn't properly respond to changing between tags, and deleting tags doesn't work


Standardize logging in ZetaClient

Describe the Issue
A clear and concise description of what the issue is.
Our log messages are often free-form strings that are difficult to parse at scale. There a number of values that are commonly used different parts of the code and they should be logged and specific metadata. Such as inbound or outbound tx, chain_id, etc.
The cosmos SDK already appends useful metadata in some cases but none of the custom modules or zetaclient do.
Examples (from zetaclient):
[OK] RPC status: latest block num 19441604, timestamp 2024-03-15 16:41:59 +0000 UTC ( 14s ago), suggested gas price<PHONE_NUMBER>7
This could be
{
"type":"rpc_status",
"status":"ok",
"timestamp":"2024-03-15 16:41:59 +0000 UTC",
"suggested_gas_price":"43756052117",
"chain_id":"5",
 }

fail to send signature to peer 16Uiu2HAkuaNDfW7s89tmiFA25YwVKWRh7Y2f7a7dACUcW8atnadT
If peer were a field we could easily track errors on a per peer basis.
{
"error":"fail to send signature to peer",
"peer":"16Uiu2HAkuaNDfW7s89tmiFA25YwVKWRh7Y2f7a7dACUcW8atnadT",
}

leader(zetapub1addwnpepqvzlntzltvpm22ved5gjtn9nzqfz5fun38el4r64njc979rwanxlgq4u3p8) is not reachable
Becomes
{
"error":"leader is not reachable",
"leader":"zetapub1addwnpepqvzlntzltvpm22ved5gjtn9nzqfz5fun38el4r64njc979rwanxlgq4u3p8",
}

Benefits

Ability to better trace all logs related to a specific transactions or event type
Can attribute events to specific operators or nodes
Easier for developers to know what to include in the log and how to format it.

Example that @ws4charlie already implemented: https://github.com/zeta-chain/node/pull/1790#discussion_r1500014253
Expected Outcome
A consistent approach to logging that makes it easy to parse and trace logs at scale.

observeInTX: lasstScanned heights for chain 56 ZetaSent 39505941 ERC20Deposited 39505941 TssRecvd 39505941
As it is written it should move to debug and fix the typo in lasstScanned.
A new log should be emitted when when the three values don't match and go as a warning or error.


Pytorch implementation?

Hi,
I'm really excited about this project. The corresponding paper outlines exactly some of the goals I have for a specific model. I was glad to find the paper and this repository.
I've been reviewing the code in preparation to write a pytorch implementation. But since I don't want to redo work that someone's already done, I'd like to ask if you're aware of an existing pytorch implementation before I get too deep into writing code.
And if you're not aware of a pytroch implementation of a neuralHMM, would you be interested in collaborating to write one?
Thanks,

I have been able to implement Baum-Welch and pytorch neural networks to estimate all parts of a HMM (prior probability vector, emission probabilities, and transition matrix). This means that each of the HMM components can be a vector/matrix, or a neural network which uses some kind of input data to yield a vector/matrix/parameterized distribution, very much like the neural network-HMM models implemented in the NeuralHMM paper. These networks are trained by gradient descent. In my experiments, I've found that the networks are successfully able to recover the true parameters for some simple toy problems (with both Gaussian and multinomial observed data).
However, the details of the implementation differ slightly from the methods of the Lua implementation. I'm not fluent in Lua, so it's possible that this Lua implementation and my pytorch implementation are doing the same thing, just with different mechanisms. Specifically, my pytorch implementation solely uses the negative log-likelihood obtained from the BW forward pass. The Baum-Welch backward pass and associated statistics are not used. To be explicit, the training process is to do the BW forward pass to get the log likelihood as from https://github.com/ketranm/neuralHMM/blob/master/BaumWelch.lua#L198 , take the negative of the log likelihood,  calling backward() on the negative  log-likelihood, and then the optimizer takes a gradient step.
I can't tell if this is different from how the Lua code works. Specifically, the Lua code takes some statistics from the Baum-Welch backwards pass, and these are used by the update methods for the emission, prior and transition networks to rescale the gradients. The purpose of this is opaque to me. The Lua code I'm referring to begins at https://github.com/ketranm/neuralHMM/blob/master/main.lua#L174
In my experiments, emulating the gradient-rescaling behavior from the Lua implementation did not help, and actually stopped the network from improving at all. (Of course, I might have not implemented it correctly.) By contrast, simply using the negative log-likelihood directly as a loss without taking any special steps to rescale the gradients trains a network seems to work just fine. Moreover, the network parameters converge to their true values in test some simple problems. Of course, this is not a definitive proof of correctness, but it is consistent with the desired behavior.
Is the requirement to use the statistics obtained from the backward pass of Baum-Welch in Lua just a matter of differences in how Lua and Pytorch work? Or am I missing a key fact about how the gradient updates should be carried out in neural network-HMM models?
Thanks,

Hi,
The Lua implementation exists before Pytorch, I don't think you need to translate Lua code to pytorch one. The reason that I had to write manually backward and forward of Baum-Welch is that Lua does not support auto-diff. The backward pass of Baum-Welch is equivalant to calling loss.backward() in pytorch, where the loss is computed by the forward pass of Baum-Welch via dynamic programming. The detail can be found in this paper: https://aclanthology.org/W16-5901/ . Having said that, the whole computation that collects statistic from backward Baum-Welch is exactly what you get implicitly in your implementation when you call backward on the negative log-likelihood.
The purpose of scaling factor is just to speed up training with Lua code. Pytorch perhaps has efficient way of backtracking computational graph, so I don't think you need to emulate Lua code at all.
If you want to use HMM in pytorch, I'd recommend torch-struct: https://github.com/harvardnlp/pytorch-struct
Cheers,

Thank you so much for clearing this up. It's incredibly helpful to have this confirmation. Cheers!


[BUG] RichHandler unexpected green log output

Describe the bug
Certain combinations of logger name and text cause RichHandler to output text that is unexpectedly colorized.
To Reproduce
import logging

from rich.logging import RichHandler

logging.basicConfig(
    level=logging.INFO,
    handlers=[RichHandler()],
)

for c1 in "abcdefg":
    for c2 in "abcdefg":
        logging.getLogger(c1).info(c2)

(screen shot for "efg" only, "abcd" also display as green)
Platform
macOS / iTerm
Diagnose
<console width=178 ColorSystem.TRUECOLOR>
color_system = 'truecolor'
encoding = 'utf-8'
file = <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
height = 31
is_alt_screen = False
is_dumb_terminal = False
is_interactive = True
is_jupyter = False
is_terminal = True
legacy_windows = False
no_color = False
options = ConsoleOptions(
    size=ConsoleDimensions(width=178, height=31),
    legacy_windows=False,
    min_width=1,
    max_width=178,
    is_terminal=True,
    encoding='utf-8',
    justify=None,
    overflow=None,
    no_wrap=False,
    highlight=None,
    markup=None,
    height=None
)
quiet = False
record = False
safe_box = True
size = ConsoleDimensions(width=178, height=31)
soft_wrap = False
stderr = False
style = None
tab_size = 8
width = 178

platform="Darwin"
WindowsConsoleFeatures(vt=False, truecolor=False)

rich @ file:///Users/[me]/Library/Caches/pypoetry/artifacts/86/d4/e6/4b64e2da645c0db113dd0a98eea75adb255570e4f0e3f597b6c5c0f557/rich-10.2.2-py3-none-any.whl

They are probably being highlighted as IpV6 addresses which are colons with hex digits between.
You can supply a custom highlighter to the RichHandler, so it will only highlight according to your tests. I'd suggest reading the docs on highlighting and perhaps customizing the default highlighter.

They are probably being highlighted as IpV6 addresses which are colons with hex digits between.
You can supply a custom highlighter to the RichHandler, so it will only highlight according to your tests. I'd suggest reading the docs on highlighting and perhaps customizing the default highlighter.

IPv6 addresses have more than two octets, perhaps a more robust regex would help?

It might, but to do it precisely its a quite ridiculous regex. If you want to propose a change, I'd welcome a PR.
Another option, if you don't care about ipV6 would be to theme the "repr.ipv6" style to "default".


💡 Allow query of multiple types in Anime and Manga

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem?
Requested multiple times over discord. Latest one here: https://discord.com/channels/460491088004907029/462992340718583814/1187797767213568080
Describe the solution you'd like
?types=tv,movie
Describe alternatives you've considered
No response
Teachability, Documentation, Adoption, Migration Strategy
Filter support in the UI, better data filtering

My idea for this was to add odata protocol implementation, and it would live under a different prefix other than /v4.
https://github.com/flat3/lodata
like: https://api.jikan.me/odata/v1/
Odata already has the concept of "multiple selections for a filter parameter" and you can easily transform that to ORM calls.
More on OData here:
https://learn.microsoft.com/en-us/odata/
Some examples of would request urls would look like:
https://learn.microsoft.com/en-us/odata/concepts/queryoptions-overview

@pushrbx ODATA would be an interesting implementation especially for users who want a more fine control over the filters.
I think there are some prerequisites that we'd have to meet for this:

Migrate to Laravel (as lodata supports laravel and Lumen is most likely going to be discontinued in any case)
Combining data of resources that have subpages into one collection (anime details, episodes, etc. all into one collection/entry rather than how it's currently sprawled out. This would allow us to cater to https://github.com/jikan-me/jikan-rest/issues/462 as well with ODATA and it would improve the request lifecycle.

While ODATA does seem like a feasible approach moving forward I still think we should still have type to have multiple support as a feature of our current search approach.


Add support for poolConfig in Salesforce connector

Description
fixes: https://github.com/wso2-enterprise/internal-support-ballerina/issues/815

@ayeshLK
https://github.com/ballerina-platform/module-ballerinax-twitter/blob/main/ballerina/types.bal We put the client init as same as the generated clients.
Major version release is not possible at the moment with how urgent this fix is needed. (There are lot more to be fixed with the next major release: https://github.com/ballerina-platform/ballerina-library/issues/6697)
Anyway this is up for debate whether or not we are doing a major release just for this.
cc: @NipunaRanasinghe

Please find my inline comments:

@ayeshLK
Used the same client init/configs as same as the Open API tool generated clients: https://github.com/ballerina-platform/module-ballerinax-twilio/blob/17b45c8c2b4d0c846d4f338eedfe6be71abec597/ballerina/types.bal#L25 as requested for the fix.

We are anyway editing this code manually and hence no need to follow the same thing in the generated clients IMO. This just adds new set of records without reusing the existing one's.

Major version release is not possible at the moment with how urgent this fix is needed. (There are lot more to be fixed with the next major release: ballerina-platform/ballerina-library#6697) Anyway this is up for debate whether or not we are doing a major release just for this. cc: @NipunaRanasinghe

The version should not be determined based on the urgency of a fix or improvement. If a change is breaking, it’s not justified to call it urgent and proceed with it in a patch or minor release. We’ve done this before and have faced consequences as a result. A more effective approach would be to start a discussion to outline the factors we should consider for the next release and establish appropriate versioning for the module.


Fixing single values of lengthscale or W (in coregionalization). Error AttributeError: 'numpy.float64' object has no attribute 'constrain_fixed'

How do I fix a single value of W when coregionalising? (I imagine this is the same as if I need to fix a single value of a lengthscale vector).
For example:
kern1 = GPy.kern.Linear(1)**GPy.kern.Coregionalize(input_dim=1,output_dim=2, rank=2)
kern2 = GPy.kern.RBF(1, lengthscale=0.06)**GPy.kern.Coregionalize(input_dim=1,output_dim=2, rank=2)
m = GPy.models.GPRegression(X,Y,kern1+kern2)

Maybe I believe that the first region is linear and the second region is wiggly. So I might want the second row of W to be fixed to zero in the first region. Or just fix one value.
 However if you access it as a tiny array (of size 1) the way things are overloaded etc(?) means you can access the method, just for that element.
So use, for example, this instead:
m['sum.mul.coregion.W'][0,0:1].constrain_fixed(0)
Notice the use of 0:1 makes the output remain an array, not a single float.


fixed wrong path causing view:cache command to fail

Thanks for that !

You can update to v1.3


arm64 support

It would be nice to have arm64 support in order to use on arm64 servers but also to be able to try it localy on arm computers like M1/2 macs or raspberry pi.
Regards,

i assume you talk about the karavan-cloud app that you can install in kubernetes ?

Yes, karavan-cloud to run in kubernetes.
Sorry for not being clear.

Works fine on Mac M2. Both Docker and Minikube


systemd cgroup paths not being handled correctly

Description of problem
We currently fail to support systemd managed cgroups on the host (at least when sandbox cgroups only is utilized). We should auto-detect the cgroup manager being used on the system, and properly create sandbox cgroup accordingly.
We should be able to detect based on the format of the path being provided.
Expected result
A cgroup created under the system.slice for the appropriate subsystems, ie:
systemd.slice/docker-SHA

Actual result
Group created next to system.slice of format system.slice:docker:SHA

/cc @amshinde @devimc @jcvenegas


Move file downloads into the files table

https://unclibrary.atlassian.net/browse/BXC-4756

Should also fix https://unclibrary.atlassian.net/browse/BXC-4778 now.


Fix ARM build failure

This is breakage was introduced by the following commit0.
Fixes: #2753
Signed-off-by: Fabiano Fidêncio<EMAIL_ADDRESS>

/test-ubuntu

/test-arm


Reference latest documentation and Update allowed_models lists for LLM Models

[ ] AI21StudioModel
[ ] AnthropicModel
[ ] Anthropic Tool Model
[ ] Cohere Model
[ ] Cohere Tool Model
[ ] DeepInfra Model
[ ] DeepSeek Model
[ ] GeminiPro Model
[ ] Gemini Tool Model
[ ] Groq Model
[ ] Groq Tool Model
[ ] Mistral Model
[ ] Mistra Tool Model
[ ] OpenAI Image Generator
[ ] OpenAI Model
[ ] OpenAI Tool Model
[ ] Perplexity Model
[ ] ShuttleAI Model
[ ] ShuttleAI Tool Model

include links to the model documentation in the docstrings of the models

I have started working on this

[X]  AnthropicModel
[X]  Anthropic Tool Model
[X]  Cohere Model

include links to the model documentation in the docstrings of the models

Should I include anything else in the doctrings, or just the link to the model's documentation?


[docs] Add CheckboxLabel TypeScript demo

[x] I have followed (at least) the PR section of the contributing guide.

@donigianrp Thanks for working on these. Much appreciated.


Add Documentation to the project

Add documentation to README in forms of architecture diagram, to code in terms of method comments, with doc generation


Fix a small typo regarding the release date, in CHANGELOG.md

5.0.1 was released on 22 Aug 2019 , not on 2020! 😀
See: https://github.com/Geal/nom/commit/c326e077b83c62f81b717c80a281cb453cb914e7

Coverage remained the same at 87.592% when pulling 828604d2622570f7b23abd615273aca2fb23dd80 on snawaz:patch-1 into 47fdc2dd94bd113f4a95dd0c29188616ab83e182 on Geal:master.

thanks!


fix: misaligned terms conditions textview

Fixes: #1458.
Changes:

Sets the layout_gravity to center_vertical of checkbox and textview in fragment_attendee.xml
Removes following properties for Checkbox layout_gravity="center" and gravity="center" as layout_gravity="center_vertical" achieves what is required.

Screenshots for the change:

Merged latest upstream


Address comments from #383

Shouldn't this be ready for review already?

LGTM, couldn't find any secrets in URLs.


Add Quadrature Decoder support for S32K3

This driver configures and programs Lcu, Trgmux and Emios_Icu modules to get the rotations reported by the quadrature encoder in radians on CANHUBK3 board
We have raised following new PR in hal_nxp to support this code -
https://github.com/zephyrproject-rtos/hal_nxp/pull/297

@Dat-NguyenDuy could you please have a review on this PR? mostly related to how this will affect the existing eMIOS/PWM support.
(btw, @Dat-NguyenDuy is added as collaborators in maintainers file but still cannot be added as reviewer, we are checking on that).

We have raised following new PR in hal_nxp to support this code -
https://github.com/zephyrproject-rtos/hal_nxp/pull/297

@sumitbatra-nxp pls add pull/297/head as revision of hal_nxp module in west.yaml to link both prs.

On a first look to this pr, IMO the drivers for the peripherals TRGMUX, LCU and eMIOS needs to be further split into individual drivers so that the QDEC sensor driver integrates them together to perform the quadrature specific functionality.
Particularly eMIOS is a versatile peripheral that has multiple uses. We have already supported PWM based on eMIOS, so there is already some generic functionality/initialization for the eMIOS module itself abstracted. This should be further extended to support your use-case. Another reference of this pattern that you can find in tree, is the QuadSPI memory controller (memc) and the flash-technology-specific QuadSPI NOR driver (flash) using the S32 QSPI controller.

@manuargue .. As discussed, due to the urgency for this code. I'll be taking up this driver split up activity in a follow up PR

Just left some minor comments from my side

On a first look to this pr, IMO the drivers for the peripherals TRGMUX, LCU and eMIOS needs to be further split into individual drivers so that the QDEC sensor driver integrates them together to perform the quadrature specific functionality.
Particularly eMIOS is a versatile peripheral that has multiple uses. We have already supported PWM based on eMIOS, so there is already some generic functionality/initialization for the eMIOS module itself abstracted. This should be further extended to support your use-case. Another reference of this pattern that you can find in tree, is the QuadSPI memory controller (memc) and the flash-technology-specific QuadSPI NOR driver (flash) using the S32 QSPI controller.

@manuargue .. As discussed, due to the urgency for this code. I'll be taking up this driver split up activity in a follow up PR

As far as the NXP S32 integration goes, I'm okay to accept a first version to get the QDEC functionality working provided a github issue is logged to address all improvements mentioned above.

@MaureenHelm .. Can you kindly review.. This feature is urgent for us..

Please address the twister failures https://github.com/zephyrproject-rtos/zephyr/runs/18844110050

@manuargue @MaureenHelm @Dat-NguyenDuy ..Twister errors have started coming after -
https://github.com/zephyrproject-rtos/zephyr/pull/62755/
https://github.com/zephyrproject-rtos/zephyr/pull/65173

Please address the twister failures https://github.com/zephyrproject-rtos/zephyr/runs/18844110050

These checks have passed

You are making a binding and driver called nxp,s32-qdec and enabling on the board using the s32k3 chip. But there is no QDEC on the k3 chip. Can you please explain this.

@decsny  I would assume this is not different than naming choices for these, I am not aware of the exact feature portfolios of these but do all "mcux" have qdec or all "stm32"?

nxp,mcux-qdec.yaml

atmel,sam-tc-qdec.yaml

st,stm32-qdec.yaml

I misunderstood slightly what is going on here. In this case, the s32 makes sense in the binding name, since it is using a combination of peripherals on the s32. But, it seems like the LCU and TNGMUX be separate nodes in DT?

@MaureenHelm .. For - static uint32_t Clockwise_overflow_count, CounterCW_overflow_count;
I have taken a 2D array - emios_overflow_count[emios_inst][emios_hw_ch_cw]
I should be able to operate on the overflow counters per emios inst and channel (programmable from Device Tree) by this now.
I have also made all the variables unique as per device instance

Hello @manuargue  @MaureenHelm  - I'm trying to follow this PR as it is blocking some other activity on our side. Are there still unresolved changes that need to be made or has @sumitbatra-nxp  addressed them at this point?


How to install google play store or APKs in ChromiumOS for rpi4

Hi! I would like to know if it is possible to install APKs or google play store in ChromiumOS for rp4 as it can in chromeOS for example. Thanks.

While this is open I'd like to know too if possible, lol. I Have a rp3

it won't be possible with Chromium OS (the open-source version) unless the Chromium Authors decided to change the status quo. Sorry guys. There is a chance with FydeOS if we can resolve some of the key performance issues, but not at the moment.


Support virtualenv environments for remote interpreter

The remote Python interpreter might be installed in a virtualenv environment. This environment should be activated prior to executing the Python command. See https://github.com/mdklatt/idea-ansible-plugin/issues/2 for an implementation of this.

Commit 2f943efcef56964c4bc108274d455268ac9af9ea includes revamped tests that use Docker containers to test remote execution for Docker and SecureShell run configurations. Not sure how to test Vagrant run configuration, especially on platforms that do not support it (e.g. Apple Silicon).

Issue resolved by commit 0abf3af906b6f670d69dfd78a30cfc7627784ab5.


Allow Cube Query to opt-out of flattening redundant children

See issue: https://github.com/xh/hoist-react/issues/3843
Seemed like a quick win, that would allow us to clean up some code at a flagship client app. Wasn't sure about the name, its tricky to describe what this does in just a couple of words - any suggestions welcome!
Hoist P/R Checklist
Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

[x] Caught up with develop branch as of last change.
[x] Added CHANGELOG entry, or determined not required.
[x] Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
[x] Updated doc comments / prop-types, or determined not required.
[x] Reviewed and tested on Mobile, or determined not required.
[x] Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

We discussed, and I like this change al ot, as it also helps document a bit of a subtle behavior.
One unfortunate/confusing thing is that it is a lot like an omitFn, and I suppose we might have been able to implement it as an omitFn, although because of its recursive nature of zapping multiple nodes in a chain, I am not sure how straightforward that would be.
Perhaps we should call it omitRedundantNodes or flattenRedundantNodes?

I think it really is an omitFn.  We could make it the default omit function on cube e.g. Cube.omitFn = omitRedundantNodes but that would be a breaking change for anyone overriding the omitFn, who would now have to also refer to the default implementation.
Maybe best to just call it omitRedundantNodes and have omitFn and omitRedundantNodes just mention each other in their docstrings.


Configuration Field for Task-ID not visible

Really great work! I've started a similar project months ago, but lost motivation to finish it.
Only problem: I had to remove the data-actions="start_task" in the file propertyInspector.html in order to see the entry field for the task id.

Thanks for the feedback - (finally) fixed in 9bf8c53


Initial commit with first animation

Added

New logo art
ui.js
canvasAnimations.js

Changed

site.css
README.md
index.html

Removed

Logo_Full.svg
manifest.json
pwa.js
sw.js

Approved


For Item 7, "Microsoft Account" should be changed to "OAuth2"

Hi,
On Item 7 for this page:
7. On the next screen, select Microsoft account as the Authentication method > Sign in. If you choose any other authentication method, the connection to the template app will fail.
I think this is incorrect or outdated: "Microsoft Account" was not an option. User should select "OAuth2"
Options were "Anonymous, Basic, OAuth2"
OAuth2 worked for me and authenticated using my Microsoft Account
Thanks
Stuart Jacobs

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 65732911-21e9-0902-51fa-0d3ae0caaa7a
Version Independent ID: 3682fff5-36fc-1d69-96ef-88f7f73225d5
Content: Enable Microsoft 365 usage analytics - Microsoft 365 admin
Content Source: microsoft-365/admin/usage-analytics/enable-usage-analytics.md
Service: o365-administration
GitHub Login: @Sirkkuw
Microsoft Alias: sirkkuw

@stuart2155 Thank you for your feedback. We will test this and update the document accordingly.
Thanks
Sri

@stuart2155 Thank you for your feedback. I have another Pull Request for the same document. So I have added this fix as well to the PR# https://github.com/MicrosoftDocs/microsoft-365-docs/pull/2802
Thanks
Sri


fix(build-compile): allow skipping langs in a fresh build

Currently, running  gulp build-compile --dgeni-log=error --lang='' with no previously full (all langs) build will result in these errors:
[17:52:57] Error: ENOENT: no such file or directory, stat 'D:\work\angular.io\www-backup\docs\ts\latest\api'
[17:52:57] Error: ENOENT: no such file or directory, stat 'D:\work\angular.io\www-backup\docs\js\latest\api'
[17:52:57] Error: ENOENT: no such file or directory, stat 'D:\work\angular.io\www-backup\docs\dart\latest\api'

This PR fixes that behaviour. This is especially relevant for setups where a full build is never created.
/cc @chalin

As we discussed elsewhere: this failure is by design to ensure that @naomiblack and @kwalrath don't deploy a partial site unknowingly.
I'm ok with this fix if we we guard it with an extra command line flag, say:
    if (fs.existsSync(backupApiSubdir) || argv.forceSkipApi !== true) {
     // ...
   }

So developers building a partial site (say, w/o Dart API docs) would use the --force-skip-api flag.

Ah I didn't quite get that it was by design. I'll update with your recommendation.

@chalin updated per your comment.

LGTM


“Feed on found” on seemingly valid RSS feed

In NNW 6.1.4 macOS I’m getting a Feed not found error for a WordPress-generated RSS feed that seems relatively well-formed: https://theplantbasedschool.com/feed/

Using Feedly, by any chance? That seems to happen sometimes with Feedly (for reasons we don’t understand yet).

Having the same issue on with the macOS client (6.1.4 ) with a WordPress site as well:
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>BrooklynVegan</title>
	<atom:link href="https://www.brooklynvegan.com/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.brooklynvegan.com</link>
	<description>Music, Photos, News and more</description>
	<lastBuildDate>Wed, 21 Feb 2024 00:15:49 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.4.3</generator>

The feed stopped refreshing about a month ago but I had previously had it integrated within the client without issue. Not using Feedly or iCloud, only local.

Unfortunately, the server is responding with a 403 Forbidden to NetNewsWire (see below). It might be a good idea to contact the site owner.
HTTP/1.1 403 Forbidden
Date: Thu, 22 Feb 2024 04:21:06 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
CF-Ray: 859470b88be23098-SEA
CF-Cache-Status: DYNAMIC
Vary: Accept-Encoding
Set-Cookie: __cf_bm=g7txTbKr4h3nDB_eRHYNprhjKLOCjT4iq8vZIKoWPQU-1708575666-1.0-AXNfkcxeEbTx7jZEkJTzTOZm8FZ0nOAFMBfsCbLDeH72wik3oAKc6WSj73lIZE0rlonuJma+nQhChPpWmqP631M=; path=/; expires=Thu, 22-Feb-24 04:51:06 GMT; domain=.www.brooklynvegan.com; HttpOnly; Secure; SameSite=None
Server: cloudflare
Content-Encoding: br
alt-svc: h3=":443"; ma=86400

<title>403 Forbidden</title>

403 Forbidden

nginx

i am seeing the very same message "feed not found" on some github atom feeds like this one:
https://github.com/adoptium/temurin22-binaries/releases.atom
if the issue is with Feedly, how to add the feed to the "on my Mac" category instead?


helpful error message when multiprocessing dir env is unset

On head it fails with:
ERROR in app: Exception on /metrics [GET]
AttributeError: 'NoneType' object has no attribute 'endswith'

With this change:
  File "build/bdist.linux-x86_64/egg/prometheus_client/multiprocess.py", line 16, in __init__
    raise ValueError('env prometheus_multiproc_dir is not set or not accessible')
ValueError: env prometheus_multiproc_dir is not set or not accessible

@brian-brazil  I've changed the code to check for directories, I can squash the commits if you prefer.


Rate limiting not looking at correct resource/endpoint

When calling /users/by/username with multiple usernames, the limits are set for the full URL (e.g. /users/by/username/x, not the endpoint (/users/by/username), so subsequent calls see the default 900 calls remaining and carry on until Twitter responds with 'Too Many Requests'.
With this particular endpoint, stripping out the username from the URL in url_to_endpoint() resolves the issue, but I'm unsure whether it will break other endpoints:
	def url_to_endpoint(url) -> Endpoint:
		resource = urlparse(url).path.replace("/2", "", 1)  # only replace api version
		resource = resource[:resource.rfind('/')]
		for endpoint in PATH_VAR_ENDPOINTS:
			if re.fullmatch(endpoint.regex, resource):
				return endpoint
		return Endpoint(resource=resource)

oh i will check this and fix it.


Modules

Codebase Modularization and API Streamlining
The idea of this PR is to make development of Alpha as well as applications using Alpha less cumbersome by partitioning the existing code into smaller, easier to understand packages, as well as providing a better public API for applications using Alpha.
Modules
The codebase is divided into the following modules: alpha-api, alpha-commons, alpha-core, alpha-solver and alpha-cli-app.
Module alpha-api
The api module consists mainly of interfaces specifying the objects API consumers (i.e. applications using Alpha) interact with, such as programs, rules, atoms, literals and answer sets. It also holds implementations of some configuration classes that are used across modules.
The rationale for specifying all API objects through interfaces and keeping these in a separate module is that it should be possible for implementations to be switched out or changed without affecting applications using the API.
Module alpha-commons
The commons module holds implementations of the "basic building blocks" of ASP programs, such as terms, atoms, literals, etc. which are used across all other modules. These implementations can be instantiated through factory methods (such as Atoms.newBasicAtom(...)), but are not visible to other modules themselves in order to avoid accidental dependencies on implementation-specifc behavior in code using those implementations.
Module alpha-solver
This module provides an implementation of the Alpha interface which is the main API entry point for applications. It is separate from commons and core to avoid API clients having compile-time dependencies against types from alpha-core. alpha-core is an "implementation" scoped, i.e. "internal" dependency of alpha-solver, which means that it is a runtime- but not a compile-time-dependency of code depending on alpha-solver.
Module alpha-core
alpha-core implements Alpha's core functionality, i.e. program parsing, program transformations, grounding and solving. It depends on alpha-commons and alpha-api. While the core module is by far the largest, it is not intended for applications to directly depend on alpha-core, but rather use it through the public API realized in the  api, commons, and solver packages.
Module alpha-cli-app
The cli-app module uses the public API to provide Alpha's functionality in a commandline application. It holds a Main class, commandline argument parsing and various utilities for use of Alpha as a commandline-application.

Hey @madmike200590! Happy to see that you decided to jump in and continue. To be honest I anticipated the split to go much smoother. Turns out that I forgot that we need to split the API from implementations (which causes quite a number of changes), and there are some rough edges like the "Standard Library".

Hey @madmike200590! I am happy to see that you decided to jump in and continue. To be honest I anticipated the split to go much smoother.

Thank you for getting this off the ground! I've wanted to do something in this branch for some time now, but was tied up with PR #268.

Turns out that I forgot that we need to split the API from implementations (which causes quite a number of changes), and there are some rough edges like the "Standard Library".

Yeah, I also only fully realized that when looking at your changes. Still not sure about the nicest way to go, but here are my thoughts so far:

We definitely want a split between "core API" (what the solver uses) and public API, because we don't want methods like FixedInterpretationLiteral#getSatisfyingSubstitutions in public API types.
On the other hand, we have to make sure that everything used in the solver itself conforms to the "core API", ideally that can be statically guaranteed without weird instanceof constructs that only blow up at runtime.

So what I'm trying to do now is to create a separate hierarchy of "Core" types, i.e. CoreLiteral, CoreAtom, etc. that do not extend the "public API" types, but are created from them using mapping methods, e.g. CoreLiteral#fromLiteral or something like that. While that undoubtedly adds some overhead and very similar code in a few places, it's the neatest way I see to fully decouple the public API from internal workings of our backend and vice-versa. I expect to have a first working draft of that by end of this week, let's see how it looks when it's actually there and doing something...

I see. Aggregates are definitely very useful as well!
And yes, I also ran into the same troubles (public API and internal/core API). I wanted to resolve it with generics, but this is very tedious so I gave up. Your approach with mapping the public types to core types is very valid, too, give it a spin!
I can't wait to add Alpha (just the solver, not the CLI) as a Gradle dependency in some application project for the first time 😆

@lorenzleutgeb, I have a gradle-noob-question that formed in my head while fiddling apart public and "core-internal" APIs...
Ultimately, I think we want to ensure that the core module is only ever a runtime dependency for any application using Alpha through the API defined in api. Especially, I think we want to ensure that it is not (easily through a "normal build workflow") possible for an API consumer to directly compile against types from core (e.g. InternalProgram etc).
In order to achieve that, we need to have all relevant functionality exposed through interfaces in the api module.
However, we also need users to be able to instantiate implementations. Considering the following code snippet from a hypothetical application api-using-app:
class App {
    public static void main(String[] args){
        Alpha alpha = new AlphaImpl();
        alpha.solve(....);
        ....
    }
}

Since AlphaImpl resides in core, our hypothetical API consumer would need a gradle config looking something like
dependencies {
	implementation group: 'at.ac.tuwien.kr',     name: 'alpha-api',      version: '1.0.0'
	implementation group: 'at.ac.tuwien.kr',     name: 'alpha-core',    version: '1.0.0'
}

In my opinion, this would be a problem, since it would make expose the types meant for internal use from alpha-core while the only type that should be exposed is AlphaImpl.
The only way around this that I currently see is to have an additional module, let's call it alpha-solver that basically just contains AlphaImpl and has the following dependencies:
dependencies {
	api group: 'at.ac.tuwien.kr',                        name: 'alpha-api',      version: '1.0.0'
	implementation group: 'at.ac.tuwien.kr',    name: 'alpha-core',    version: '1.0.0'
}

As far as I understand gradle dependency scopes, that would mean applications depending on alpha-solver can (as intended) compile against alpha-api as well as AlphaImpl, but get alpha-core (against which alpha-solver is compiled) only as runtime dependency, thereby ensuring they cannot accidentally use types from alpha-core in their application code.
Since I'm much more confident with maven than gradle,

Is this the right way to go about this in gradle?
Can you think of an alternative that achieves the same without the additional module? I can't think of anything simpler, but still feels like a bit much overhead...

Hmm, I am not sure whether Gradle is the correct layer to address this. I guess it should be JPMS which allows us to specify which packages of our module should be visible to the outside. And then being careful about marking classes pubic.
I think adding another module or adding JPMS config can also be done rather independently once modularization is done.

~350 files changed. That might be ... all of them? 😂

~350 files changed. That might be ... all of them?

pretty much :joy: . Just getting everything to compile took quite some adaptations. Right now we have a lot of interfaces in the API module, a number of which I don't think should actually be exposed, but I couldn't keep everything straight in my head all at once. So now that it compiles, I'm in the process of getting all tests to pass, then cut down on publicly visible interfaces.

The commons module is confusing me, as it contains some very, very core concepts like the Interner.java, which is the implementation ensuring that same-term-is-same-object. This should be in the core and not be visible outside.
The commons module also contains factory methods for terms/predicates/atoms which looks good to me. But I do not understand why all the api-implementations of those objects reside in the commons module. Especially given the fact that all those api-implementations are also in the commons module, hence those factories are not much else than constructor-wrappers when the constructors themselves have the same visibility as the factory methods.
I also wonder why construction methods for programs are not part of the commons module. Gtiven that terms and atoms are there, I would expect that at least some ways to construct  an InputProgram are in commons.

Okay. I think we're on the same page now. Please bear with me, as I am attending a summer school this week and the schedule is quite tight. I'll find make time for a proper session on 2021-10-19.

General question at @madmike200590: have the tests in this PR been converted to use junit 5?

Yes.

It seems to me that this branch is still on junit 4 (and if we proceed with a step-wise modularization of master, it maybe won't be necessary to merge junit5 changes into this branch).

The juni4 dependencies that you saw where accidental leftovers that were there because I overlooked something in the build config. I fixed that now, everything runs on junit5 (only).

I guess at.ac.tuwien.kr.alpha.grounder.rete.* can be deleted?!

Okay, I am done with the reviewing, all files viewed, finally. There are some of my comments in the last week that should be addressed and there is a git conflict with the build.gradle. But besides that, this PR is ready for merging! Very good work, thank you @lorenzleutgeb and @madmike200590 !

Regarding the conflicting file build.gradle. The conflict is as follows:
CONFLICT (modify/delete): build.gradle deleted in modules and modified in master.
                          Version master of build.gradle left in tree.

This is just because we have changes to build.gradle on master, and deleted it in modules. Funnily enough, GitHub opines that "These conflicts are too complex to resolve in the web editor".
I merged master into modules ("control merge") to resolve, resulting in c65b8ea67420cf8e0a2d862264a48e39b44c3796.

Looks like we're good to merge, yay!
@madmike200590 do you want to rebase this branch, to clean up the history? There are commits messages starting with "WIP" or "Intermediate commit". I'd like to avoid such commits on master. At the same time, I'd also like to avoid squashing this rather large branch into one single commit.

Looks like we're good to merge, yay!
@madmike200590 do you want to rebase this branch, to clean up the history? There are commits messages starting with "WIP" or "Intermediate commit". I'd like to avoid such commits on master. At the same time, I'd also like to avoid squashing this rather large branch into one single commit.

Great! While I see your point about the WIP commits, I don't really want to do a rebase only for that - especially since it's not like it'd be useful to try checking out "halfway done" versions of the modularization. If that's ok with everyone, I'd just go ahead and squash everything.

I took the liberty to squash and merge, cutting down the merge commit message a lot. I used Co-authored-by (also used in the Linux kernel) to indicate that we share authorship of the commit. I'm really happy that we made it :)

Great, thanks! It's a huge step forward and after all the time this took, it's great to have this finally "live" :D


Fixed invalid syntax in includeResultsetResponses #136

This PR addresses the invalid OpenAPI syntax in the includeResultsetResponses parameter.
For more info see issue #136.

HI @datsirul, please, can you update fix-136 branch with the last updates from schema-urgent-fixes so we don't have conflicts when making the PR? Thanks.


Refactor dataverse

Remove .map() and .flatMap() (use prisms instead)
Remove ConstantDerivation (use a prism instead)
Re-formulate AbstractDerivation's state for clarity

Closing in favor of #345


Question about Custom Example

I am wondering if it is required to change the other settings on the custom example shown on the readme when the ja3 string is changed or if they can be kept the same. I'm not quite sure keeping them the same make the requests look sus or not.
If i need to change the values depending on the ja3 string, how would i be able to do this?

In order to make the fingerprint look realistic, you'll probably have to update other values if you change the ja3. Thats correct. :)

In order to make the fingerprint look realistic, you'll probably have to update other values if you change the ja3. Thats correct. :)

okay so i can't just take a random ja3 from a file of ja3's? in which way would i need to change the other values based on the ja3 string?


Make the ultra_honk_tests target operate on both UltraFlavor and UltraKeccakFlavor

This would be ideal to enable us to test the UltraKeccak flavor without needing to run the honk_sol flow

Resolved by https://github.com/AztecProtocol/aztec-packages/pull/8243


recconnecting wireless

sir pansin ko lang. pag pinatay ung AP kung saan naka konek ung ESP8266. hindi na sya mag rereconnecting pag lumabas na ung juanfi setup..

@bastewifi it will try to connect until 45 sec, if not it will go to JuanFI setup, so i made this changes at
https://github.com/ivanalayan15/JuanFi/issues/66
to do some change in logic and much longer timeout

thanks sir..

closing this issue to avoid duplicate