Small typo in quickstart

https://quickstarts.sigmacomputing.com/guide/embedding_03_secure_access/index.html?index=..%2F..index#0

Secure embedding is by far the most popular method Sigma customer use, as it works the Parent application's authentication, to pass user-level permissions and more at runtime.

https://quickstarts.sigmacomputing.com/guide/embedding_03_secure_access/index.html?index=..%2F..index#2

The link for User Account Types takes you to a page that says there are 4 default user account types: Lite/Essential/Pro/Admin.
But further down is says,

Are there 4 user account types, or 2?

(fyi, I'm really liking these quick starts.  They're very useful.)

Thank you for the kind feeback. We have migrated from the older account types to ones that match our licensing plans (Lite, Essential, Pro. The QuickStart will be updated later today to reflect this.


Support for read-only properties ?

Hello,
I wanted to check out the library real quick and scratched my head for a good while, and it turned out it didn't serialise read-only properties.
I did a dirty search and replace to add private setters everywhere to help the library out and it worked !
Would it be possible to modify these read-only properties through reflection by retrieving the backing field somehow ?

Hi,
if you add setters to the prop, then it's not readonly anymore, so that's why it works, private setters work as well as you mentioned.
So just so I get it right, you want Ceras to be able to serialize (and desrialize) this: ?
public string Name { get } = "abc";
It's true that there is a backing field, but it's not so easy to to do automatically.
The naming might change at any time, someone who's compiling the same exact code with mono, or some older c# compiler, or roslyn, or whatever might get an assembly that internally uses backing fields with a different name.
In the test I just did my compiler decides to name it like that:
https://i.imgur.com/0Ln1ELt.png
but it's not guaranted to be named like that.
Because of that Ceras skips fields marked as IsInitOnly or CompilerGeneratedAttribute.
But there are some options we could explore...

Here are some ideas:

Maybe we could allow serialization when the user explicitly asks for the backing field to be included. Like this:

Maybe there could be an additional entry in the TargetMember enum which is used in the MemberConfig attribute you can put on a class, as well as in the SerializerConfig.DefaultTargets.
We could add something like ReadonlyPropertyBackingFields to this enum.

Automatically including the backing fields of readonly props seems to be a bit wasteful because most people would not want it (and expect it to be skipped).
Also, if you have readonly properties then maybe you want a few of them serialized, but not all.
But in the rare case that you really want all your readonly props serialized, then you can still either add the MemberConfig attribute, or set the DefaultTargets in the config to globally include all of them.
That should cover all possible cases, what do you think?

Correct. Well it's a bummer that the name could vary between compilers/versions, but I would have hoped that the runtime would be able to expose the handle to the backing field in some way.
Idea 2 would be the most handy, as it doesn't require peppering attributes around, as I would be doing placing all the setters anyways.
Now, I can totally live without that feature, and adding setters everywhere is a small price to pay for serialising my complex hierarchy, but it would be nice to keep the intent of the code untouched.

Oh, I can totally understand you not wanting to add any "outside" stuff like serialization attributes.
In that case you should be able to manually handle the inclusion using config.ShouldSerializeMember.
I'm not sure if it gets called for backing fields / compiler generated members, but I could definitely change it so it always does get called. That'd be option 3.
That'd be another way to handle things globally at a centralized location (where the serializer / config is created), so you'd not have to change anything on your actual classes; and you still get fine-control.
Tbh I think all 3 options shouldn't take much time to implement, so I'll put them on my todo list... :)

I did place a breakpoint when I added a delegate to the ShouldSerializeMember config when I was troubleshooting my way into the library, but unfortunately it doesn't get called for those members, I eventually figured.
For the record, here's the quick and dirty implementation I'm testing:

(And the full diff)
It works wonderfully and is even faster than I would have expected given I'm compressing the data !
Thanks a lot for looking into this and making this amazing library :heart:

Hey again.

Thanks a lot for looking into this and making this amazing library :heart:
First of all thank you for saying that! It really makes me happy if people find this project useful :)

There are a few things I thought of in the meantime.
Automatic inclusion of hidden fields
While thinking about how to best make it possible to easily serialize hidden backing fields I realized that this would also include other 'spooky' things. There are many more things that can get compiler generated (hidden) fields. For example calling methods on dynamic objects can generate cached invokers, the enumerator and async-method statemachines, ...
So while in your case all of this doesn't apply, I feel hesitant about adding a way that would globally include fields marked as CompilerGenerated.
So right now I added an option SkipCompilerGeneratedFields to the serializer config which is true by default.
Turning it off will make it so ShouldSerializeMember will get called for all the compiler generated fields (so you can return ForceInclude if you want).
Further [field: Include] will work regardless of whether or not SkipCompilerGeneratedFields is true or false. Simply because that is pretty much the most explicit way to include something.
With those two options (in addition to simply adding {private set;} as you did) I think there are enough ways to handle this for now. Handling those fields in the ShouldSerializeCallback would make it so nobody has to change their classes themselves.
Actions, Funcs, ...
I was looking over your diff just out of interest and I noticed you have a Action or Func somewhere. I'm not 100% sure if that get's serialized right.
Normally I'd expect that there won't be a problem since Ceras can already correctly serialize MethodInfo and the captured variables (if there are any), so it is supposed to work since there's no real reason why it wouldn't be possible.
However I didn't try that so far, and I don't have a test case for it!
I'll add that as well and make sure serialization of arbitrary delegates/funcs/actions works as intended.
This also makes me wonder about events and if how they should be serialized...
I'll do some testing regarding that later.

Update:
There are some issues with directly serializing MemberInfos (and all the types that inherit from it, so FieldInfo, MethodInfo, ...). I'm tracking it in an issue. I have added that to my todo list.
The same issue is preventing MulticastDelegates from being serialize and deserialized correctly.
However serializing Actions, Funcs, and events in general has a large number of problems anyway.
Since delegates almost always have a target, that target is needed, and thus gets dragged into the serialization as well.
That will very quickly drag in pretty much every object in your program... which is of course pretty problematic to say the least haha. While I'm sure we won't find a general solution (other serializers would have thought of a general solution already), maybe we can find some compromise, or adding a new option or something...
But that's not all, there are many more issues with the idea of serializing delegates.

I actually thought for a bit and got scared due to my usage of what you'd call "wrapper" types which got included, and it somehow not breaking the state at all, impacting the performance or bloating the output much. I'll expand on this at the end of this long post.
Interface member serialisation
While I was checking back on the members being serialised by breakpointing on ShouldSerializeMember, I found that the serialiser did not walk through and save members of the underlying type of interface members, which can absolutely be an issue if, for instance, my coprocessor registers have vastly different configurations.
It didn't break outright on my quick testing since not much differs where I'm at in my project.

This ICoprocessor[] COP array contains references to both a SystemControlUnit coprocessor at index 0 and a FloatingPointUnit coprocessor type at index 1, and those contain members (mostly just registers) which need to be serialised in order to keep a consistent state.
As it is, the coprocessors are left in their unmodified state between saves and restores since Ceras doesn't register the members of these types.
Delegate serialisation
I do have quite a lot of delegates, both in the CPU's read and write system bus, but mostly every single one of the memory map accesses have delegates for reads and writes in the system.
They're usually only set once when initially setting up the system, and the only one that currently changes is when the CartridgeSwapped event gets called when the setter for the console's Cartridge is hit, which swaps a single memory map entry's read and write delegates that reads and writes to that cartridge reference (or to a safe delegate on null references), though I do not (and nor should anyone) make the cartridge member part of the serialisation process for a state, so it all works out !
Partial type name support
This shouldn't be noteworthy, but I'm glad you made use of FullType when recording type information !
I have a tonne of conflicting names, as for example each interface and processor within my RealityCoprocessor have their own Statuses flags enum partial type, and it would've been catastrophic if only Name were used.
I mention this because I've seen a project out there not supporting partial types, and the results were unusable (that reminds me I should fix it).

"Wrapper" type serialisation
You can think of them as high-level, friendly representation of properties of an underlying value (a register, or a series of bytes in RAM). They're essentially BitVector masking getters/setters. I use three kinds of those types.
The first two are entirely optional as they wrap an array value (a register or a multi-byte value of a member that gets serialised anyways (i.e. the SystemControlUnit.StatusRegister wrapper indexes the SystemControlUnit.Registers[RegisterIndex.Status] ulong value, and the PeripheralInterface.DeviceState struct wrapper implicitly casts a 4-byte value in PeripheralInterface.RAM[DeviceStateOffset]). I can simply discard those members from serialisation.
The third kind is an actual structure member with a single BitVector32 field, where each property of this structure will mask this field for their getters/setters.
For all of those cases, the serialiser will keep the actual value, as well as the high-level representation values these properties are sourcing from the actual value.
As long as the wrapper types are well-defined, this doesn't cause issues and simply adds a small overhead (i.e. BitVector32 is a 4-byte value, and DeviceState will have 5 1-byte properties, plus the BitVector32 field).

Re: delegates.
The dangers potentially outweight the usefulness of serialising them, but perhaps there could be some instances where they could work.
An option to enable storing them might be turned on if one would like to have an exact state if and only if it is run on the specific version of the software it has been created (i.e. either as a temporary state stored during the program's runtime, or as a permanent storage that is only supported for the version which created it).

Regarding Interface Members:
Oh no, that's definitely not supposed to happen, I think.
Ceras is definitely supposed to explore the real type of each entry in an array, as well as all the members inside that type.

Or does it maybe rather have something to do with the actual classes (FloatingPointUnit)?
Maybe something simple, like the members of that class being private and Ceras being set to only set public members?
Can you make a small repro code? Or copy paste your FloatingPointUnit class here along with your setup code for Ceras (like, the SerializerConfig that you're passing to it; if you do that)
Delegate serialization:
Ok, so no problem here, right? Or anything that could be improved?
That reminds me, if your methods are static that's a special case since there is no target.
Which means serializing 'myFunc' in here:  should work without capturing any unintended other objects. (well, as soon as I've fixed serialization of delegates)
Oh and also, if you ever run into a case where you have to serialize a delegate/Action/Func but you need to prevent the target-object of the delegate from being serialized as well: You can mark the target object as IExternalRootObject, and then manually resolve that later! It's pretty easy to do in case you ever have that kind of situation.
Wrapper types:
I'm not sure I'm completely following here. Maybe I'll have to take a look at the code you're working with (assuming there are any issues).
As for the BitVector32, there's no built in support for that one in Ceras. If everything works for you then I guess that happens because Ceras is actually serializing those helper properties (that use the bit vector as their backing data). But maybe it would be better to actually make it so Ceras only serializes the BitVector and ignores the properties. (adding an [Include] to the bit vector field, and adding a [MemberConfig(TargetMember.None)] to the class itself, to ensure only the [Include]'d bit vector is actually serialized)

Interface members
I'll provide a solution with the small instructions right below.
I have reduced the area of serialisation down to the CPU itself, where the COP array holds the coprocessor type instances in question that aren't getting serialised.

The COP property is privately settable, so it is getting probed by the serialiser, however it doesn't walk the underlying types (I believe only SystemControlUnit has a serialisable member, ulong[] Registers { get; private set; }).

Here, the types are instantiated and set to the array.
I thought it might have been because I didn't expose public parameterless constructors for those types (I don't get an exception for these types), but adding them still doesn't make Ceras go through them.
As a side-note, the Deserialize overload that returns a new object raises an exception for delegates with parameters, as the library needs parameterless constructors at the moment, but this is outside my current use-case, and I don't think I even need serialised delegates in the first place.
Though it makes me wonder: the CPU's constructor constructs those coprocessors by passing its own reference, which gets stored as a read-only field. Would the Deserialize<T>(ref T) maintain this link, as it seems to require a parameterless constructor at the moment ?
Test solution
DotN64.zip

Debug the DotN64.Desktop project (with an external terminal, for input) by passing --debug --no-video as command-line arguments.
Insert a breakpoint in DotN64/Diagnostics/Debugger.cs, at line 284 (ShouldSerializeMember delegate).
Type state save into the program's terminal and press Enter.
Hit F5 to cycle through the members getting probed.

Add these watches to see which members are getting probed:

m.MemberInfo
m.MemberInfo.ReflectedType

Delegate types
No problemo, I'm 100% okay on that point.
The Re: post up there could maybe-perhaps be of use to some people, however.
Wrapper types
It's all fine, I was just describing how lucky it was the serialisation test didn't blow up in million pieces.
I don't think it is even possible to detect this kind of use-case for "wrappers", where only a backing value has to be serialised, and the properties are all hitting on it. That's only on my part to fix (but even then it's negligible) :)

Just FYI, I opened an issue to keep track of all this delegate madness: https://github.com/rikimaru0345/Ceras/issues/11
I'll write up a detailed response to your recent posts soon! :)

It just dawned on me that I have the exact same dependency configuration (read-only passed in self-reference) in RealityCoprocessor, except that the members there are clearly defined in separate properties, instead of being put together in an array of a base type like in the VR4300.

The serialiser walks through each of these without issues, so this is very puzzling that it doesn't for the array of interfaces' case.
The read-only fields don't exactly matter so long as the deserialisation doesn't nullify the references from the existing instance I'm applying the state to, which works for the RealityCoprocessor as of now !
It's so damn near perfection... I have no idea why it doesn't work for the CPU's coprocessors.
If you replace nintendo64.CPU by nintendo64.RCP as the Serialize parameter (in DotN64/Diagnostics/Debugger.cs, line 297) and look at the members being probed by ShouldSerializeMember when doing state save, you'll see it traverses the whole graph for this object, no problems.
Interestingly, I didn't need to add parameterless constructors for those to be saved. If the deserialisation wouldn't have worked, then I wouldn't have been able to have video output, with the exact resolution due to the VideoInterface registers controlling it, but I did, so that means it does work.

No, thank you for helping me debug this ! :)
I feel like I'm kind of shoving my issues onto you, but on the flipside I guess it's a very good stress test at the same time, haha !
I just know it can magically do this, it already has done it for the RCP part, the only difference is that hecking weird array/interface thingy :p

Quick update:
I just started debugging your project. Starting, debugging and reproducing the error was no problem.
I'm currently checking out what exactly is going wrong.
My initial finding is that there's an IntPtr member somewhere, and Ceras does not know how to handle it, so it tries to use the dynamic formatter (that's already wrong, IntPtr should have built-in support), then it checks out what IntPtr is made up of and sees this: void* m_value; which reflection reports has having the type System.Void haha.
From the looks of it it seems like a very simple bug and straightforward to fix, but you never know, maybe I'll uncover something else.
I'll report back soon.

One issue I can see in your code is your type-check.
You've got excludedTypes but you're checking with Contains(), but no type will ever be of type IVideoOutput, instead some types my inherit from it.
Also, I noticed that it's serializing Actions and Funcs, so I've added typeof(Delegate) to the excluded types.
So this is what I have now:

That excludes the members: ReadySysAD, WriteSysAD

Seems to work, I guess. I don't know enough about the code to really judge what is supposed to happen (like what things can possibly be null or so).
So what I did was state save, restart program, state restore with a breakpoint on the deserialize, and before letting it deserialize I messed around a bit with the cpu by setting cpu.CP0.Registers = new ulong[1234]; to clear everything and makes the array the wrong size.
After continuing with the deserialization it seems that ceras has correctly restored the state. cpu.CP0.Registers is now back to, what seems like, the original state:

As I woke up, it all clicked !
Read-only reference type member serialisation
Considering pretty much all my read-only properties are reference types, and the fact that the Deserialize overload that takes a reference to an existing object does not require instantiating new objects, it means that the deserialiser does not need to access any setters or get any backing fields through reflection !
All it needs to do is use the getter to get the reference and modify the object itself !
Shouldn't it be expected behaviour since reference types are still absolutely mutable despite being read-only members ?
In hindsight it makes sense, as my emulator required the state of these read-only reference types, since when it runs it is able to mutate these read-only members.
Type checking
For the excluded type list, I initially checked if the type inherited from IVideoOutput, but when examining what Ceras passed to me, it looked like I received IVideoOutput itself as the type, so I figured I could unify everything into a single array. I'm pretty sure it worked as intended.

I made sure I set the VideoOutput reference to an actual type that implements IVideoOutput (Window) to be sure Ceras doesn't return the underlying type, but I guess it doesn't so long as you don't actually call the getter of that property and check the object type that the property returns, so it works as intended :)
Delegate exclusion
That is a good thing to keep in mind if I ever need to only synchronise the CPU state itself, but under normal circumstance it correctly pulled the console's RAM which I normally serialise with serialiser.Serialize(nintendo64) :)
FloatingPointUnit
Yes, this one indeed doesn't currently have serialised members (it ambiguously accesses the cpu for its couple registers), but I'll eventually move the FPU registers off the CPU into the FPU itself so it also has its own serialised state. Sorry about that !
Thank you so much for fixing this ! I'll check the new version out !

Read-only reference type member serialisation
Yeah that makes sense, but Ceras being able to overwrite/reuse existing objects is more like a "oh wow that's cool, saves some allocations" feature, than it being the primary intended use case.
Just to be sure, is this just an observation? Or are you asking for it to be possible to make it always assign members even when the "container" itself is readonly?
I mean it would work of course, but what is supposed to happen when the data says "the value in this object field should be an instance of type A", and then it inspects the thing and finds an object of type B? (so wrong type, but still possible to be in that field because the field type is object)? Or the more obvious case, what if the current value is null?
In those cases Ceras has to assign a new instance.
I could maybe add an option for it to explicitly allow this scenario. It's not too far fetched, and being able to restore state into an existing object-graph seems like something many people would want.
However I can't have it enabled by default as that would be just too confusing.
Also, what would you want Ceras to do in the cases where content of the field is null (or of a mismatching type)? Probably just an exception, right?
Type checking
Ah yes you're completely right. Ceras passes the field, not the actual object!
However there are two things that caused the misunderstanding.

Your field indeed IVideoOutput, and not an implementation type. So that's why it worked. Sometimes people use the concrete type instead of an interface of base-type (in that case, it wouldn't work with a direct comparison)
I was thinking about delegates as well, and your callbacks are indeed concrete types like Action and Func, so excluding delegates that way wouldn't have worked. That's why I (wrongly) assumed the same thing being the case with the IVideoOutput.

Glad we cleared that up :)
Delegate exclusion
But was it actually able to restore the RAM state as well?
If it got pulled into the serialization graph indirectly through some delegate, I'm not sure if Ceras would have been (or currently is) able to even restore that delegate.
Manually saving the RAM is definitely the way to go, but it would be interesting nonetheless to see if it would have worked at all :D

Read-only reference type member serialisation
Yeah, I would like it to keep the members read-only and have the serialiser still serialise them as it could do this without reflection performance penalty for reference types.
Maybe it could fallback to using reflection in those edge cases you mentioned (where the types don't match, null, etc. and it has to assign a new reference).
If the field is null, wouldn't the serialisation mark it as null as well without issues ?
Delegate exclusion
Yeah, the Nintendo64 type has the RAM property, which the CPU unknowingly accesses through Read/WriteSysAD. Those delegates are connected to the RealityCoprocessor's memory maps (those have Read/Write delegates too), which for the RAM memory space (in RDRAMInterface) will go get the nintendo64.RAM.Memory reference.
Talk about indirection ! But it works as intended ! :smile:
The reason behind this indirection is to allow the VR4300 CPU to be a completely generic CPU which has no idea it is part of a specific device like the Nintendo64.
This decoupling makes it a potentially reusable component as a library, for completely different use-cases.
I don't remember how I found your project as I somehow have a bookmark that dates back to October:

But if I had to guess it was probably when I looked for serialisation libraries on NuGet.
Though what made me actually try it out a couple days ago was when I saw it appear in the GitHub dashboard's discover repositories features, which reminded me of its existence :laughing:
It's my first time using a serialisation library, by the way :p
It's just perfection ! :ok_hand:

Yeah, I would like it to keep the members read-only and have the serialiser still serialise them as it could do this without reflection performance penalty for reference types.
Maybe it could fallback to using reflection in those edge cases you mentioned (where the types don't match, null, etc. and it has to assign a new reference).
If the field is null, wouldn't the serialisation mark it as null as well without issues ?

Alright, I've put that on my todo list. It makes sense to have it and there really are valid use cases (such as yours).
Fallback to reflection will be needed, but as long as the intent behind the feature is made very clear to everyone there are no downsides.
Not sure I understand the last question correctly. You're asking if it would write null to the field if the data says it should be null? If so, yea, that's what would happen, but assigning null is still an assignment so it would have to use reflection for that too. (probably not what you meant... ?)

By the way, Ceras doesn't need to explicitly support BitVector32, since it has a UInt32 field it serialises:

That only happens because you have set TargetMembers.All in your code.
With an explicit formatter it will always work.
Which reminds me: maybe it would be good to have some sort of override list instead, where people could put in types+a member config. For our own types we can add [MemberConfig] to customize it, but there's no (easy) way to do it for types from other libraries.
Sure, you could use ShouldSerializeMember, or write your own formatter and provide it to the config, but that's pretty uncomfortable.

I cannot reproduce the pulling of RAM due to delegate captures when only serialising CPU with either version 1.2.21 or 1.2.23. How did this happen on your end ? Were you perhaps serialising the whole console instead of only the CPU when you noticed this ?

I'm not sure, the only thing I can say for sure is that I was always serializing the cpu, so no changes there.
But maybe it happened because I was working on some other stuff as well at the same time?

Further, was the VersionTolerance.AutomaticEmbedded not including the SystemControlUnit members supposed to be fixed in version 1.2.23 ? I have to turn versioning off for its members to be captured at the moment.

I'll take a look. Turning version tolerance on or off should not make a difference in what gets serialized, only how things are written (and that schema data is added as well), so something is not right here.

I just investigated the problem with version tolerance.
It pretty much only happens when you have an subobject, that is an array of interfaces, in that combination.
Stress testing indeed haha. If it weren't for your project it would have probably taken a while for someone to discover this haha.

So, in short, in my kind of case the speed would be retained as long as the object type of read-only members doesn't change across versions ? Even then, the worst case scenario could be some old state being loaded slower once, so this sounds like a very acceptable trade-off.

Pretty much, yeah.
But even though reflection has a reputation for being very slow, it's not that slow. An assignment using .SetValue() takes maybe as long as 50 normal assignments (which themselves take basically no time at all). And we're only dealing with a single reference here. So the difference would be imperceptible. Actually, if it's only a single assignment the difference might not even be measurable at all.

On re-reading this, it sounds like this would be what the option about using reflection for assigning to read-only members would be choosing.
If the option is disabled, it could throw an exception, is that right ?

Hmm, yes. I don't have a concrete plan for it yet. Initially I was thinking about some extra bool setting, but actually you're right, maybe it would be better to have an enum.
It's a little complicated because there are multiple cases.

Off meaning that readonly fields are completely ignored.
Members meaning that it would record the member-values of the object in the readonly field and set set them back to the recorded value on deserialization. But if there is some sort mismatch, it would throw an exception. That means it would only ever work when the user uses the ref deserialization constructor. Or if the data happens to tell us that the field should be null anyway.
ForcedOverwrite which is like members, but in case of a mismatch it would fix the mismatch "by force" (using reflection and SetValue).

Now as for what a mismatch is:

The field is currently null, but the data tells us it should not be null
The field contains an instance of some object, but the data tells us it should be null.
The field contains an instance, but the data tells us that there should be an instance of a different type inside that field. (Example: the field is like readonly ISomeInterface MyField; and it currently contains a  ImplementationA, but the data tells us it should be an ImplementationB)

Maybe the options as I outlined them above (off, members, forced) make the most sense, no? Or maybe I forgot something...

It all sounds good to me !
And I guess delegates will also have this similar optional treatment.
As for the fix, I'm absolutely not in a hurry (I've got many, many, many more stuff to deal with) :p

And I guess delegates will also have this similar optional treatment.

Eventually, yes.
In the next update Ceras will completely ban delegates for now (so you have to [Ignore] them).
That is to prevent many problems and unexpected situations other users might have. Allowing delegates at all in the current state is just not reasonable.
But I plan to allow them later, initially only static targets, and later maybe all types of delegates (assuming I can come up with something to assure that no completely unrelated things will get caught up in the serialization).

The fix for the interface array in combination with version tolerance is done.
There might be other edge-cases though, so keep that in mind.
I'll continue with that readonly overwriting feature now I think.
Also, if you want to, add me on discord: Bloodskilled/Rikimaru#0345 it's a bit faster to discuss things there :)

This feature is completed.
It will be present in a new release of Ceras soon :tm:


Intellisence Fail To Fetch Methods Inside A Class......

Please Fix This Issue First........

I am working with electron projects and when ever I create this :-
`
//This is Import Statement For Electron
const Electron = require("electron");
const url = require("url");
const path = require("path");
//Destructuring Electron Modules For Different Objects
const {
app,
BrowserWindow,
Menu,
} = Electron;
//Global Variable Declaration For All The Window Objects
let MainWindow;
//This is MainF Class And It Contain All The Main Functions
class MainF {
constructor(Main) {
this.MainWindow = Main;
}
setTitle() { //Setting Title The Main Window
    MainWindow.setTitle("Todo App");
}
LoadData() {
    MainWindow.loadURL(url.format({
        pathname: "../HTML/Main.html",
        protocol: "file:",
        slashes:true
    }));

}

}
//This Is The Entry Point For The Application
//It Define What Happens When
//The Program Get Executed On The System
app.on("ready", function () {
MainWindow = new BrowserWindow();
Main();
});
//This Is The Main Function It Create And Instanciate Class (MainF) And Call All Functions
function Main() {
const MainC = new MainF(MainWindow);
MainC.setTitle();
MainC.LoadData();
}
`
I've created this MainF class and when I use MainWindow object inside this class it doesn't show me methods associated with the MainWindow object but when I use it Outside the class it shows all methods and works fine please tell me what I am doing wrong is this code have some issues or this is a problem In the ide itself there are no electron plugin for vscode to use.........................Pleeeeeeease Help


About hyper parameters

Are batch_size and learning rate the same as stated in the paper during Fine-tuning stage? In the script file, batch 26, lr=2e-4 is set to be learned. On the other hand, the paper states batch 8, lr=1e-5.
This is the result of finetune with the provided FSC147.pth.
Batch 26, lr=2e-4 : 12.79 mae/ 86.49 rmse
Batch 8, lr=1e-5 : 13.77 mae/ 87.69 rmse

The code has been updated by @GioFic95, so the batch_size and learning rate should also be updated to achieve a better result.

The results reported in issue #26 are obtained by using the parameters described in the paper. I.e., I ran the finetuning with this command:
FSC_finetune_cross.py --epochs 1000 --batch_size 8 --lr 1e-5 --output_dir ./data/out/finetune --log_dir None --title CounTR_finetuning_paper --resume ./data/out/pretrain/checkpoint__pretraining_299.pth

In my changes I haven't touched the default values for batch size, learning rate or gradient accumulation, and neither the training itself. I just added another logger alongside tensorboard: W&B.

Sorry for my inconsistencies of the hyperparameters.
I modified the finetuning code to conduct ablation studies and forgot to recover it completely. So for all hyperparameters except the learning rate, please refer to the original paper. For the learning rate, I used batch learning rate in the code and calculated the corresponding learning rate myself in the paper. So the batch learning rate in the code is correct.
For learning rate, I use a batch learning rate of 2e-4 as I mentioned in the readme.md.
For batch size, I use 8, though I think a larger batch size will yield a better result.
Hope my description will help you.

Thank you for your answer.


Schema validation rejects *.json files in fileReplacements (Regression in 11.0.0 & 11.0.1)

🐞 Bug report
Command (mark with an x)

[x] build
[x] serve

Is this a regression?
 Yes, the previous version in which this bug was not present was: 10.2.3
Description
There are new changes in files<EMAIL_ADDRESS>and<EMAIL_ADDRESS>that restrict using *.json files in fileReplacements operations that were always available in previous versions.
These *.json files are normally used as configuration settings in the same way as *.ts files for different environments with the advantage that they are more easily parsable as standard JSON in the different platforms than TS.
There are no reasons why the new restriction should exist, and it's also unclear why it was changed at all.
New changes are:
"properties": {
	"src": {
		"type": "string",
		"pattern": "\\.([cm]?j|t)sx?$"
	},
	"replaceWith": {
		"type": "string",
		"pattern": "\\.([cm]?j|t)sx?$"
	}
}

and previous functional version:
"properties": {
	"src": {
		"type": "string"
	},
	"replaceWith": {
		"type": "string"
	}
}

🔥 Exception or Error

Schema validation failed with the following errors:
  Data path ".fileReplacements[0]" should NOT have additional properties(replace).
  Data path ".fileReplacements[0].replace" should match pattern "\.([cm]?j|t)sx?$".
  Data path ".fileReplacements[0]" should match exactly one schema in oneOf.

🌍 Your Environment

Angular CLI: 11.0.1
Node: 12.13.1
OS: win32 x64

Angular: 11.0.0
... animations, cdk, common, compiler, compiler-cli, core
... elements, forms, language-service, platform-browser
... platform-browser-dynamic, router
Ivy Workspace:

Package                          Version
----------------------------------------------------------
@angular-devkit/architect 0.1001.7
@angular-devkit/architect-cli 0.1100.1
@angular-devkit/build-angular 0.1100.1
@angular-devkit/core 10.1.7
@angular-devkit/schematics 10.1.7
@angular-devkit/schematics-cli 0.1100.1
@angular/cli 11.0.1
@schematics/angular 10.1.7
@schematics/update 0.1100.1
rxjs 6.6.3
typescript 4.0.5

Hi @mlc-mlapis,
I am assuming you are using resolveJsonModule and importing the JSON file in a .ts file correct?

@alan-agius4 Exactly.

@alan-agius4 Thanks for your quick reaction. 🍰

Hi, i have the same problem with files *.scss and *.css.
Example:

"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
},
{
"replace": "src/theme/variables.scss",
"with": "src/theme/variables.lite.scss"
},
{
"replace": "src/theme/one_kendo_theme/all.css",
"with": "src/theme/one_kendo_theme/all.lite.css"
}
],

Error:

Schema validation failed with the following errors:
Data path ".fileReplacements[1]" should NOT have additional properties(replace).
Data path ".fileReplacements[1].replace" should match pattern ".(([cm]?j|t)sx?|json)$".
Data path ".fileReplacements[1]" should match exactly one schema in oneOf.

Angular 10 this worked.


MARP-1333 Missing setup path for README_DE.md

Included README_DE.md in pom.xml and zip.xml

LGTM

No to me, the build is broken stating a readme problem

LGTM

No to me @vhhoang-axonivy , the build is broken stating a readme problem

Hi @ivy-rew, this PR will not be merged until the README_DE.md is added, for now me and @vhhoang-axonivy marked this as a pending PR.


Add MIT license

So it seems like we forgot to add this to the repository awhile ago.
Based on past conversations (including some that specifically mentioned/were based on the fact that porybox is MIT-licensed), my understanding is that there was a general knowledge that porybox is MIT-licensed, and we just forgot to add the license file to the repo.
That said, it would probably be best if all the contributors gave approval on this PR.

Closing since it seems like we now agreed on Apache-v2.0 instead.


Using an actual apprise URL with a tag (POST) within ChangeDetection.io notification

Trying to use an Apprise-API REST POST endpoint/url or similar to accomplish sending notifications.
Is this documented anywhere? I'm trying to basically do:
curl -X POST \
-F "body=This is a test!" \
-F "tag=discord_backup" \
http://apprise-api:8000/notify/apprise

But the changedetection.io version. Which ironically, and confusingly, is the same as apprise-urls. Love the feature, but I didn't get it until I read it a few times.
In the documentation it seems to suggest writing the full discord URL with webhook+token, or signal call with sensitive info, but that goes against the whole point of what apprise-api config does. I've tested that, and it does work, but it has that caveat about not using apprise-api for what it's designed to do.
What is the best way to do this?
No version of:
post://apprise-api:8000/notify/apprise?+tag=discord_backup

When I click notification history, it just goes like:
2024/01/10 16:36:14,000 - SENDING - [{"title": "Test", "body": "hee", "url": "post://apprise-api:8000/notify/apprise?+tag=discord_backup", "body_format": "Text"}]
2024/01/10 16:09:28,000 - SENDING - [{"title": "Test", "body": "hee", "url": "post://apprise-api:8000/notify/apprise?+tag=discord_backup&+title=xyz&+body=yzxx", "body_format": "Text"}]
2024/01/10 16:08:25,000 - SENDING - [{"title": "Test", "body": "hee", "url": "post://apprise-api:8000/notify/apprise?tag=discord_backup&title=xyz&body=yzxx", "body_format": "Text"}]
2024/01/10 16:07:59,000 - SENDING - [{"title": "Test", "body": "hee", "url": "post://apprise-api:8000/notify/apprise?tag=discord_backup", "body_format": "Text"}]

In apprise-api logs...
2024-01-10 10:46:12,253 [WARNING] django.request: Bad Request: /notify/apprise
[pid: 147|app: 0|req: 462/598] <IP_ADDRESS> () {30 vars in 388 bytes} [Wed Jan 10 10:46:12 2024] POST /notify/apprise => generated 36 bytes in 2 msecs (HTTP/1.1 400) 5 headers in 291 bytes (1 switches on core 0)

Seems to work for me, although of course the curl command up top works fine when docker exec -it apprise-api bash.

Further into this, I cannot seem to make this work.
First tried to make apprise url talk to the host.
apprise://apprise-api:8000/notify?tags=discord_backup

No success.
Then I tried using the key api: https://github.com/caronc/apprise-api#persistent-storage-solution , no luck there either.
Working with key:
curl -X POST -F "body=HELLO" http://apprise-api:8000/notify/7a415742525gere2e8bf8c4361e9777d92f2dfad2359bbd8c9fbcd49

Not working:
post://apprise-api:8000/notify/7a415742525gere2e8bf8c4361e9777d92f2dfad2359bbd8c9fbcd49

Tried adding tags. That doesn't work either.
Tried adding body as a GET parameter in that link. Nope.
If I had to guess it looks like the body tag might just not be getting put in the POST, and thus, it's posting nothing to that.
Then getting HTTP: 204.
There has to be some way to do this.


Coop and Greenhouse are not reported in tile info

farm.tile on any position containing this buildings just reports null.

(May apply to other constructed buildings too.)

(Greenhouse ruins may suffice for testing this.)

The most recent version of the mod seems (on its face) to resolve this.
Advise "close - fixed" and listen for people to still complain about specific structures being missed by the implementation.
Source: I did the testing; it's in JoeStrout's Miniscript Discord Server logs here.

Agreed.


OMG Sindre!

Why you keep creating so much packages hmm?
Get get me wrong, i just wonder how you get the idea of making packages

I create most packages out of need. I make larger packages that I either extract functionality out of or make packages I need to solve problems in my bigger projects.

@vko-online see https://github.com/sindresorhus/ama/issues/13 and https://github.com/sindresorhus/ama/issues/1 (not answered yet, but hopefully soon)


Installation trouble (VirtualBox)

I've just installed VirtualBox on my Windows 10 laptop, downloaded Annif-tutorial and added the Annif-tutorial image to VirtualBox, - all  according to tutorial instruction video.
When trying to start the image (green arrow), I get the following error message:

Failed to open a session for the virtual machine annif-tutorial.
Not in a hypervisor partition (HVP=0) (VERR_NEM_NOT_AVAILABLE).
VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED).

Result   Code:
E_FAIL (0x80004005)

Component:
ConsoleWrap

Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

Any idea what to do?

Hi,
The message says that VT-x option is not enabled in BIOS of your computer, can you check that? This page has instructions for enabling VT-x (it is written for Access Commander case but never mind that).
Note also the last lines "if you have enabled these settings within the BIOS..." (more details on disabling Hyper-V can be found from this answer).
-Juho

Hi,
Thanks! Although I do not have administration privileges on my laptop, I was still able to access  to BIOS settings to enable VTx, - to my great surprise. And it worked! So far, so good.


Use flake8 to find undefined names in Python code

https://flake8.pycqa.org/en/latest/user/error-codes.html
On the flake8 test selection, this PR does not focus on "style violations" (the majority of flake8 error codes that psf/black can autocorrect).  Instead, these tests are focus on runtime safety and correctness:

E9 tests are about Python syntax errors usually raised because flake8 can not build an Abstract Syntax Tree (AST).  Often these issues are a sign of unused code or code that has not been ported to Python 3.  These would be compile-time errors in a compiled language but in a dynamic language like Python, they result in the script halting/crashing on the user.
F63 tests are usually about the confusion between identity and equality in Python.  Use ==/!= to compare str, bytes, and int literals is the classic case.  These are areas where a == b is True but a is b is False (or vice versa).  Python >= 3.8 will raise SyntaxWarnings on these instances.
F7 tests logic errors and syntax errors in type hints
F82 tests are almost always undefined names which are usually a sign of a typo, missing imports, or code that has not been ported to Python 3.  These also would be compile-time errors in a compiled language but in Python, a NameError is raised which will halt/crash the script on the user.

@all-contributors please add @cclauss for code and bugs :sparkles:


End date not honored by CLI/Python API

Change Summary
Overview
New Dependencies
When using the CLI/Python APIs to request data for a specific time period, the end date does not seem to be respected.
New Files
None
Deleted Files
None
Updated Files

cli.py: added end_date to list of valid arguments

Testing
Tested locally in Python and CLI.

Thanks for doing this!


Update wrapper to latest nightly

For the new configuration cache debug option.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.


Missing context menu item after install.

I installed Clang Power Tools as per the instructions on the website, then opened my CMake-based solution.
There is no context menu for CPT anywhere, on the solution, on the project, or any of the source files.
There's literally nothing showing up and no way to use this.

Hi @dtromb,
Does this happen on a simple test project too?
Can you give me an test project?
Can you try on a Visual Studio solution too?
If you open a test project as Solution, can you see the context menu?
Kind regards,
Marina

I also experience the same issue. I have Visual Studio 2019 and 2022 installed on my machine. That might be the root cause. I installed the extension for both IDEs and context menu item does not appear.

I am having a similar issue. After installation of the clang power tools in Visual Studio 2022, I can see the context menu, but everything is greyed out.
In VS2019 it is working fine (with the same projects as in VS2022). I also have both VS2022 and VS2019 installed.
@biomed12 Were you able to solve your problem?

Hi @JuliaGut,
If you can see context menu but is greyed out try to update the Visual Studio #1376 (see here the full solution)
Kind regards,
Marina

Hi @mariru27!
Thanks a lot, this solved the problem!


Crash in legalize input types

https://gist.github.com/GMNGeoffrey/c1da910992cedaaf92ce3184e77af6f1 has a repro that can be run with iree-tf-opt

assert.h assertion failed at llvm-project/mlir/lib/IR/Block.cpp:258 in mlir::Operation *mlir::B
lock::getTerminator(): !empty() && back().mightHaveTraitOpTrait::IsTerminator()

This is hit when running a transformer model through iree-import-xla

Scratch that, iree-tf-opt won't process it but iree-opt will (even though it's part of the import pipeline) :-/

The failure comes from:
https://github.com/google/iree/blob/303f865bbaafed4b73532987a6eb8f8bbab1590f/iree/compiler/Dialect/Flow/Transforms/LegalizeInputTypes.cpp#L124
Seems like having the verifier itself crash is pretty unhelpful...

Through the magic of printf debugging, I think the new op triggering the assert is
%1010:2 = "mhlo.sort"(%1008, %1009) ( {
^bb0(%arg66: tensor<f32>, %arg67: tensor<f32>, %arg68: tensor<i32>, %arg69: tensor<i32>):  // no predecessors
  %1014 = "mhlo.bitcast_convert"(%arg66) : (tensor<f32>) -> tensor<i32>
  %1015 = "mhlo.compare"(%1014, %26) {comparison_direction = "LT"} : (tensor<i32>, tensor<i32>) -> tensor<i1>
  %1016 = "mhlo.bitcast_convert"(%arg66) : (tensor<f32>) -> tensor<ui32>
  %1017 = mhlo.subtract %57, %1016 : tensor<ui32>
  %1018 = "mhlo.bitcast_convert"(%1017) : (tensor<ui32>) -> tensor<i32>
  %1019 = "mhlo.select"(%1015, %1018, %1014) : (tensor<i1>, tensor<i32>, tensor<i32>) -> tensor<i32>
  %1020 = "mhlo.bitcast_convert"(%arg67) : (tensor<f32>) -> tensor<i32>
  %1021 = "mhlo.compare"(%1020, %26) {comparison_direction = "LT"} : (tensor<i32>, tensor<i32>) -> tensor<i1>
  %1022 = "mhlo.bitcast_convert"(%arg67) : (tensor<f32>) -> tensor<ui32>
  %1023 = mhlo.subtract %57, %1022 : tensor<ui32>
  %1024 = "mhlo.bitcast_convert"(%1023) : (tensor<ui32>) -> tensor<i32>
  %1025 = "mhlo.select"(%1021, %1024, %1020) : (tensor<i1>, tensor<i32>, tensor<i32>) -> tensor<i32>
  %1026 = "mhlo.compare"(%1019, %1025) {comparison_direction = "LT"} : (tensor<i32>, tensor<i32>) -> tensor<i1>
  "mhlo.return"(%1026) : (tensor<i1>) -> ()
}) {dimension = 1 : i64, is_stable = true} : (tensor<1x134832xf32>, tensor<1x134832xi32>) -> (tensor<1x134832xf32>, tensor<1x134832xi32>)

I don't understand though because that sure looks like a terminator to me. Maybe something isn't registered right?

Ok if I just disable verification of the new op in there, the reproducer then passes. Which is kind of weird because verify should be running as a separate pass afterwards. Regardless I shouldn't be able to crash the verifier here...

Yeah I can't figure out exactly what's going on, but by deleting all the sort ops I get this pass to run without error

But extracting the sort ops into a separate function doesn't reproduce the issue

If I get it to dump immediately before asserting. The dump it gives is actually for the entire func op. Here's a func op that crashes the verifier: https://gist.github.com/GMNGeoffrey/877336064cb6398f7b9b6acf5de080ea

Ok, a much smaller repro
func @main(%arg666 : tensor<1x134832xf32>, %arg667 : tensor<1x134832xi32>), %arg668 : tensor<i1>) -> tensor<1x7xi32> {
  cond_br %arg666, ^bb2, ^bb3
^bb2:  // pred: ^bb1
  %1010:2 = "mhlo.sort"(%arg666, %arg667) ( {
  ^bb0:  // no predecessors
    "mhlo.return"(%arg668) : (tensor<i1>) -> ()
  }) {dimension = 1 : i64, is_stable = true} : (tensor<1x134832xf32>, tensor<1x134832xi32>) -> (tensor<1x134832xf32>, tensor<1x134832xi32>)
^bb3:  // pred: ^bb1
}

Ok a much smaller repro for real this time
func @main(%arg666 : i1, %arg667 : tensor<1x134832xf32>, %arg668 : tensor<1x134832xi32>, %arg669 : tensor<i1>) {
  cond_br %arg666, ^bb2, ^bb3
^bb2:  // pred: ^bb1
  %1010:2 = "mhlo.sort"(%arg667, %arg668) ( {
  ^bb0(%arg66: tensor<f32>, %arg67: tensor<f32>, %arg68: tensor<i32>, %arg69: tensor<i32>):  // no predecessors
    "mhlo.return"(%arg669) : (tensor<i1>) -> ()
  }) {dimension = 1 : i64, is_stable = true} : (tensor<1x134832xf32>, tensor<1x134832xi32>) -> (tensor<1x134832xf32>, tensor<1x134832xi32>)
^bb3:  // pred: ^bb1
}

Somehow some part of verification is detecting mhlo.sort as maybe a terminator at one point and definitely not a terminator at another point. I wonder if registration is somehow happening part way through verification??
func @main(%arg666 : i1, %arg667 : tensor<1x134832xf32>, %arg668 : tensor<1x134832xi32>, %arg669 : tensor<i1>) {
  br ^bb2
^bb2:  // pred: ^bb1
  %1010:2 = "mhlo.sort"(%arg667, %arg668) ( {
  ^bb0(%arg66: tensor<f32>, %arg67: tensor<f32>, %arg68: tensor<i32>, %arg69: tensor<i32>):  // no predecessors
    "mhlo.return"(%arg669) : (tensor<i1>) -> ()
  }) {dimension = 1 : i64, is_stable = true} : (tensor<1x134832xf32>, tensor<1x134832xi32>) -> (tensor<1x134832xf32>, tensor<1x134832xi32>)
}

I tried setting preloadDialectsInContext to true to see if it was an issue with late loading of the MHLO dialect, but that doesn't seem to have fixed it

This has been identified as a bug in the MLIR verifier. I'll just quote @joker-eph:

I think I found the broken underlying assumption.
When the verifier starts on a module or a function, it'll first verify the nested region before looking for the ops inside the region.
But when you invoke the verifier on a non-isolated-from-above operation directly, it hasn't verified whatever is in the parent regions. But when it looks for SSA value, it'll check for dominance where these values are defined.
And dominance assumes that we first check the region.

Basically when trying to verify the sort op (which is not isolated from above) the function it's in is not complete yet. The verifier tries to verify the SSA values used in the sort op are dominated by it, but dominance checking relies on the function being well formed (specifically it calls getTerminator).

Should be fixed with https://github.com/llvm/llvm-project/commit/a6559b42cee2


Add datasetIndex and dataIndex properties to segment context

Feature Proposal
Currently the segment scriptable context has got references to p0 and p1 where datasetIndex and dataIndex are missing.
Inside the $context property I could get the dataIndex (even if being a property starting with $ sounds not really public) but datasetIndex is missing.
Maybe the context could have the dataset and data indexes for p0 and p1
Feature Use Case
I think a callback could use these values to understand which dataset the callback is managing.

The $context contains datasetIndex too, but its a inherited property so might not be visible in debugger.
Its a data context.
But as you figured, its not really public, so it could be renamed or moved elsewhere.

Maybe it should have actually been the contexts rather than the points that are passed. But changing that would be a breaking change.

@kurkle yes, I agree it is a breaking change. In the meanwhile, I have implemented as is, without dataset and data indexes.

If we duplicated the info into the segment context, could it stop from being a breaking change since it's only adding new fields?
Essentially change the type of the segment context from
export interface ScriptableLineSegmentContext {
  type: 'segment',
  p0: PointElement,
  p1: PointElement
}

to
export interface ScriptableLineSegmentContext {
  type: 'segment',
  p0: PointElement,
  p1: PointElement,
  p0Index: number,
  p1Index: number,
  datasetIndex: number,
}

@etimberg my 2 cents. Technically speaking, implementing as you describe is not a breaking change because you are adding new fields.
I have a doubt if make more sense to add "dataIndex" and "datasetIndex" to PointElement.
Anyway, if I may, I would prefer the following (to be more aligned with data and dataset context structure, even if the property names could seem too long!):
export interface ScriptableLineSegmentContext {
  type: 'segment',
  p0: PointElement,
  p1: PointElement,
  p0DataIndex: number,
  p1DataIndex: number,
  datasetIndex: number,
}

we could also just add the contexts to the interface:
export interface ScriptableLineSegmentContext<TType extends ChartType> {
  type: 'segment',
  p0: PointElement,
  p1: PointElement,
  p0Context: ScriptableContext<TType>,
  p1Context: ScriptableContext<TType>
}

we could also just add the contexts to the interface:

Sounds good for me


feature: PaaS 镜像部署适配 (closed #135)

Codecov Report

:exclamation: No coverage uploaded for pull request base (v1.0.12-rc@2d4bec7). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             v1.0.12-rc     #136   +/-   ##
=============================================
  Coverage              ?   53.77%
=============================================
  Files                 ?      180
  Lines                 ?     8731
  Branches              ?        0
=============================================
  Hits                  ?     4695
  Misses                ?     4036
  Partials              ?        0

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 2d4bec7...a50b70d. Read the comment docs.


Added desktop GUIs

Hey @rathboma 👋🏻
Great PR! I've suggested a few changes since it's been on my backlog to add a similar list. Hope you approve, thank you.

@notrab Nice! You guys are getting some good support :-).
Also -- nice to see a northerner, I used to live in Heaton (went to uni at Northumbria), now I live in Texas :cowboy_hat_face:

@notrab Nice! You guys are getting some good support :-).
Also -- nice to see a northerner, I used to live in Heaton (went to uni at Northumbria), now I live in Texas 🤠

haha that's amazing!


Plan at the end?

How would you feel about putting the "plan" output (1..n) at the end rather than the beginning of the run? The advantage is that you don't have to keep the user waiting before printing output. I agree with your choice not to force people to manually specify the number of tests, but I would prefer not to wait for the output. The plan at the end is still TAP-compliant, so for example, BATS could still work nicely with prove or other such tools.
If you're interested, I'm happy to help make it happen.

Closing after thinking it over more. Wish I could delete issues. Sorry.

No problem. For the record, you don't have to wait for the output. The result of each test is written to stdout immediately after it runs.
(When you run a Bats test, the interpreter counts all the test definitions and writes the plan line. Then it iterates over the list of tests, forking a new process for each one. Each test process is responsible for writing its own result.)

For the record, you don't have to wait for the output. The result of each test is written to stdout immediately after it runs.

Yup, this is why I closed (feeling like a complete idiot). I was half looking at the implementation and half trying out examples, and I got the wrong idea. Very dumb. Thanks.


EKS worker nodes failing to register as ALB target nodes

I have created an EKS cluster and added worker nodes using these instructions and the referenced CloudFormation template.
The alb-ingress-controller is logging an error event when attempting to register the worker nodes:
I0705 16:08:55.229718       1 session.go:35] [ALB-INGRESS] [session] [INFO]: Request: ec2/DescribeInstances, Payload: {  InstanceIds: ["i-073xxx","i-0b8xxx","i-0eexxx"]}
I0705 16:08:55.345216       1 session.go:35] [ALB-INGRESS] [session] [INFO]: Request: ec2/ModifyInstanceAttribute, Payload: {  Groups: ["sg-xxx","sg-yyy"],  InstanceId: "i-0b8xxx"}
E0705 16:08:55.381642       1 session.go:44] [ALB-INGRESS] [session] [ERROR]: Failed request: ec2/ModifyInstanceAttribute, Payload: {  Groups: ["sg-xxx","sg-yyy"],  InstanceId: "i-0b8xxx"}, Error: InvalidInstanceID: There are multiple interfaces attached to instance 'i-0b8xxx'. Please specify an interface ID for the operation instead.
The worker nodes are spread across 3 private subnets, each in a different AZ.
It's odd that the CF template is creating a public DNS name and IP for each node as well as 2 network interfaces.  The worker nodes on our Kops managed clusters do not have multiple network interfaces and the alb-ingress-controller is registering those nodes successfully.
Does anyone know of a workaround for registering a target node with multiple nics?

Also running into this same issue with EKS

I think this is a duplicate of #343. I'm working on support for this in #449 if you would like to test that out and see if it resolves your issues. There is some more work to do in there because as it is, you can not change the annotation from instance to pod or back without removing/creating the entire ingress.

Hi @bigkraig, this seems to be an issue for me still using quay.io/coreos/alb-ingress-controller:1.0-beta.3.
I had a 2 node cluster, created an ingress, and the alb ingress controller correctly made target groups with the two instances.
Then I added a 3rd node to the cluster and the ingress controller did not add the instance to the target group.
Nothing in the logs except:
I0714 18:44:26.360847       1 alb-controller.go:153] [ALB-INGRESS] [controller] [INFO]: Ingress update being attempted. (Forced from no event seen in 60 seconds).

Forgot to mention my service is NodePort and I'm using the alb.ingress.kubernetes.io/target-type: pod annotation.
Thanks for the help!

With the target-type: pod  annotation it should only add the pods to the TG, so adding/removing nodes shouldn't change things, only adding/removing pods. LMK!

My service only has 1 pod running, but there are are two EC2 instances in my target group.
$ kubectl get all -l app=sa-web
NAME                          READY     STATUS    RESTARTS   AGE
pod/sa-web-68bc5f44f4-9k55h   1/1       Running   0          1d

NAME             TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
service/sa-web   NodePort   <IP_ADDRESS>   <none>        80:31056/TCP   1d

NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/sa-web   1         1         1            1           1d

NAME                                DESIRED   CURRENT   READY     AGE
replicaset.apps/sa-web-68bc5f44f4   1         1         1         1d
replicaset.apps/sa-web-6c57549584   0         0         0         1d

But then my target group has two instances, despite only 1 pod running, and 3 nodes in the cluster:
http://storage.stochasticbytes.com.s3.amazonaws.com/k4nag8pD.png
I'm confused.

If you are using pod targets you would see IPs rather than instance IDs in your screenshot. I fixed a bug after the beta.3 image that allows you to switch back and forth between the types, so either upgrade to the latest image e8035f4  or delete/recreate the ingress.

I'm encountering the problem referenced in the issue opener, using 1.0-beta.4 on EKS.
Upon registering the ingress:
I0728 18:42:31.100289       1 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"example2", Name:"nginx-ingress", UID:"f750787e-9295-11e8-866f-06cb9ba7be6a", APIVersion:"extensions", ResourceVersion:"6385418", FieldPath:""}): type: 'Warning' reason: 'ERROR' Error adding targets to target group c551063c-30000-HTTP-36b6499: InvalidInstanceID: There are multiple interfaces attached to instance 'i-09cf66774d18752d2'. Please specify an interface ID for the operation instead.
        status code: 400, request id: befc49a5-36b7-4f32-837c-77357819e763
I0728 18:42:31.207792       1 session.go:35] [ALB-INGRESS] [session] [INFO]: Request: ec2/DescribeInstances, Payload: {  InstanceIds: ["i-007197a4cadae8595","i-09cf66774d18752d2"]}
I0728 18:42:31.268899       1 session.go:35] [ALB-INGRESS] [session] [INFO]: Request: ec2/ModifyInstanceAttribute, Payload: {  Groups: ["sg-81dba8f0","sg-fc2f088c"],  InstanceId: "i-09cf66774d18752d2"}
E0728 18:42:31.314729       1 session.go:44] [ALB-INGRESS] [session] [ERROR]: Failed request: ec2/ModifyInstanceAttribute, Payload: {  Groups: ["sg-81dba8f0","sg-fc2f088c"],  InstanceId: "i-09cf66774d18752d2"}, Error: InvalidInstanceID: There are multiple interfaces attached to instance 'i-09cf66774d18752d2'. Please specify an interface ID for the operation instead.
E0728 18:42:31.314751       1 session.go:44] [ALB-INGRESS] [session] [ERROR]:   status code: 400, request id: b0956f8b-6bd5-4010-a7a2-4cd8be593fd5
E0728 18:42:31.314864       1 albingress.go:264] [ALB-INGRESS] [example2/nginx-ingress] [ERROR]: Failed to reconcile state on this ingress
E0728 18:42:31.314879       1 albingress.go:266] [ALB-INGRESS] [example2/nginx-ingress] [ERROR]:  - Failed TargetGroup modification. Unable to add targets: InvalidInstanceID: There are multiple interfaces attached to instance 'i-09cf66774d18752d2'. Please specify an interface ID for the operation instead.
E0728 18:42:31.314909       1 albingress.go:266] [ALB-INGRESS] [example2/nginx-ingress] [ERROR]:        status code: 400, request id: befc49a5-36b7-4f32-837c-77357819e763
E0728 18:42:31.314937       1 albingress.go:266] [ALB-INGRESS] [example2/nginx-ingress] [ERROR]:  - Failed TargetGroup modification. Unable to add targets: InvalidInstanceID: There are multiple interfaces attached to instance 'i-09cf66774d18752d2'. Please specify an interface ID for the operation instead.
E0728 18:42:31.314975       1 albingress.go:266] [ALB-INGRESS] [example2/nginx-ingress] [ERROR]:        status code: 400, request id: b0956f8b-6bd5-4010-a7a2-4cd8be593fd5
I0728 18:42:31.315003       1 controller.go:486] ingress backend successfully reloaded...
I0728 18:42:31.315034       1 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"example2", Name:"nginx-ingress", UID:"f750787e-9295-11e8-866f-06cb9ba7be6a",

We're using the instance target-type annotation. Changing to pod didn't seem to help the situation and presented another error that I'd be happy to share, but I don't think pods in the target group is ultimately what we want, anyway.
Happy to open a new issue.

Following up -- this seemed to be fixed by setting up proper network policies between Kubernetes worker EC2 instances and the ALB. I don't have details as I wasn't the one that implemented the specific fix that worked for me, but besides being a misleading error, I don't think there's anything to do here.

I'm using target-type: pod and everything is working for me now (using one of the beta5 images, forgot which one). 👍

@spacez320 Do you think you could get more info on the policies that fixed this? I'm also hitting this same error on EKS.

I an facing an issue once the deployment file is updated new pods are generated but the ip of the pod is not updated in the Target group (using EKS cluster).

@grahampfau Sorry, I wasn't involved in the actual diagnosis, so I don't have more details to share unfortunately.


Error not caught in transaction.

How do you use Sentry?
Sentry Saas (sentry.io)
Version
1.21.0
Steps to Reproduce
Have this example main.py:
import sentry_sdk
from sentry_sdk import Hub

def main():
    sentry_sdk.init(
        dsn="...",
        traces_sample_rate=1.0,
        debug=True,
    )

    with Hub.current.start_transaction(name="example-transaction"):
        raise Exception("Oh no!")

if __name__ == '__main__':
    main()

When you run python main.py then the transaction example-transaction is sent to Sentry but the exception Oh no! it not sent to Sentry.
Expected Result
Both, the transaction and an error should show up in Sentry.
Actual Result
Only the transaction ends up in Sentry.

only happening when ipdb is used. Normal run works as expected.


[stable/kong] Fix broken admin_gui_auth_conf value because of missing quotes

What this PR does / why we need it:
Fix broken admin_gui_auth_conf value because of missing quotes (when enterprise enabled)
Which issue this PR fixes
Haven't raised any issue but decided to fix it as I stumbled upon it
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @hbagdi

/ok-to-test

/retest

@hbagdi @shashiranjan84 the test is failing for reasons not to be related to my changes from the logs. Can you please take a look ?

Ok found the error, it was hidden from the logs which was showing another error ! fixing it...

closing to use rebase instead of merge

Replaced by https://github.com/helm/charts/pull/16408


[TASK] Add some more native return types

… as suggested by Rector 2.x.

coverage: 38.583%. remained the same
when pulling 92d25cf431846eef9f241ffe2f66d334200b4a09 on task/more-return-types
into 428a2ebc841a58e298782148bbc4cc34faa9eca6 on main.


[Enhancement](full compaction) Add run status support for full compaction

The usage is curl http://{ip}:{host}/api/compaction/run_status?tablet_id={tablet_id}
e.g. curl http://<IP_ADDRESS>:8040/api/compaction/run_status?tablet_id=10084
If full compaction is running, the output will be
{
"status" : "Success",
"run_status" : true,
"msg" : "compaction task for this tablet is running",
"tablet_id" : 10084,
"compact_type" : "full"
}

else the ouput will be
{
"status" : "Success",
"run_status" : false,
"msg" : "compaction task for this tablet is not running",
"tablet_id" : 10084,
"compact_type" : "full"
}

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

LGTM

run buildall

run buildall


test fails: updating the user email

Hello all,
I try to write a test for the updating of the user email. The test for updating the user's password works, but this here not. Somehow the email confirmation through PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp) does not work.
My controller test:
test "should update user email" do
    # set params for initial state of user in this test
    initial_params = %{
      "email" =><EMAIL_ADDRESS>      "password" => "oldpassword",
      "confirm_password" => "oldpassword"
    }

    # create intial user in the repo
    _user =
      %User{}
      |> User.changeset(initial_params)
      |> Repo.insert()

    # read user from repo and assign current_user to this user
    user = Repo.get_by(User, email<EMAIL_ADDRESS>    id = user.id
    conn = Pow.Plug.assign_current_user(build_conn(), user, otp_app: :myapp)

    # set params for the user.update
    update_params = %{
      "email" =><EMAIL_ADDRESS>      "current_password" => "oldpassword"
    }

    # update the user via the user.update controller
    conn = put(conn, Routes.update_user_path(conn, :update, user), user: update_params)
    PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp)

    assert conn.resp_body =~ "dashboard"
    # final check if user properties have been updated
    user = Repo.get_by(User, id: id)
    Logger.error("user after update and confirmation: #{inspect(user)}")
    assert user.email ==<EMAIL_ADDRESS>  end

The result is:
1) test should update user email (MyappWeb.UserControllerTest)
     test/myapp_web/controllers/user_controller_test.exs:71
     Assertion with == failed
     code:  assert user.email() ==<EMAIL_ADDRESS>     left<EMAIL_ADDRESS>     right<EMAIL_ADDRESS>     stacktrace:
       test/myapp_web/controllers/user_controller_test.exs:105: (test)

When I inspect the user, the unconfirmed email is still set to the new email.
When I go through the UI and set a new email and do PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp), it works, the unconfirmed email is set to nil.
I am a bit lost ... maybe you can help?

So, first I would try to pattern match the confirm email step, to be sure that it was confirmed:
assert {:ok, _user} = PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp)

But I think a controller test that makes more sense is to remove the above confirmation step, and just check that assert user.unconfirmed_email ==<EMAIL_ADDRESS>It's basically the same, but you prevent adding unnecessary logic to your test this way and just test exactly what happened in the controller action.
I'm not sure why you get the error though. The way you create the user fixture might be part of the problem. You haven't confirmed the e-mail before updating it. I'll look at the source to see what's going on, but I believe this structure may work better:
  test "should update user email" do
    # create user fixture
    user =
      %User{}
      |> User.changeset(%{
        "email" =><EMAIL_ADDRESS>        "password" => "oldpassword",
        "confirm_password" => "oldpassword"
      })
      |> Repo.insert()

    # confirm e-mail for user
    {:ok, user} = PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp)

    # assign current_user to this user
    conn = Pow.Plug.assign_current_user(build_conn(), user, otp_app: :myapp)

    # set params for the user.update
    update_params = %{
      "email" =><EMAIL_ADDRESS>      "current_password" => "oldpassword"
    }

    # update the user via the user.update controller
    conn = put(conn, Routes.update_user_path(conn, :update, user), user: update_params)

    assert conn.resp_body =~ "dashboard"
    # final check if user properties have been updated
    updated_user = Repo.get_by(User, id: user.id)
    Logger.error("user after update: #{inspect(updated_user)}")
    assert updated_user.unconfirmed_email ==<EMAIL_ADDRESS>  end

If this is a custom controller, then you should probably also ensure that the confirmation e-mail was sent.

Dear Dan,
thanks a lot for helping me out and of course for this great gift you are giving us.
I could get the test working. Huzzah! You are right with limiting the controller test to what the controller should do.
I have two observations and perhaps you can have another look:

user = User |> Repo.get_by(email: "old_email@example.com")is needed after the fixture was created.

I tried to set the email_confirmed_at via Repo.update, see alternative 2 below. Somehow I cannot update the email_confirmed_at attribute.

My user controller is calling the Pow.Plug.update_user(user_params) function BTW.
Full code of the test below.
test "should update user email" do
    # create user fixture
    user =
      %User{}
      |> User.changeset(%{
        "email" =><EMAIL_ADDRESS>        "password" => "oldpassword",
        "confirm_password" => "oldpassword"
      })
      |> Repo.insert()

    ### this one here is needed
    user = User |> Repo.get_by(email<EMAIL_ADDRESS>
    # confirm email for user
    # alternative 1
    {:ok, user} = PowEmailConfirmation.Ecto.Context.confirm_email(user, otp_app: :myapp)

    user = Repo.get_by(User, email<EMAIL_ADDRESS>    Logger.error("conn after assign_current_user: #{inspect(user)}")

    *# alternative 2*
    # changeset =
    #   User.changeset(user, %{
    #     email_confirmed_at: DateTime.utc_now(),
    #     current_password: "oldpassword"
    #   })

    # Logger.error("initial_params: #{inspect(changeset)}")
    # Result: [error] initial_params: #Ecto.Changeset<action: nil, changes: %{current_password: "oldpassword"}, errors: [], data: #myapp.Accounts.User<>, valid?: true>
    # {:ok, user} = Repo.update!(changeset)

    # assign current_user to this user
    conn = Pow.Plug.assign_current_user(build_conn(), user, otp_app: :myapp)

    # set params for the user.update
    update_params = %{
      "email" =><EMAIL_ADDRESS>      "current_password" => "oldpassword"
    }

    # update the user via the user.update controller
    conn = put(conn, Routes.update_user_path(conn, :update, user), user: update_params)
    assert conn.resp_body =~ "dashboard"

    # final check if user properties have been updated
    updated_user = Repo.get_by(User, unconfirmed_email<EMAIL_ADDRESS>    assert updated_user.unconfirmed_email ==<EMAIL_ADDRESS>  end

Oh right, you should use Repo.insert!/1, Repo.insert/1 returns the {:ok, user} tuple. You wouldn't have to load the user with this:
    user =
      %User{}
      |> User.changeset(%{
        "email" =><EMAIL_ADDRESS>        "password" => "oldpassword",
        "confirm_password" => "oldpassword"
      })
      |> Repo.insert!()

If PowEmailConfirmation.Ecto.Context.confirm_email/2 works then I would just use that. But alternative 2 could look like this:
user
|> PowEmailConfirmation.Ecto.Schema.confirm_email_changeset()
|> Repo.update()

Then you'll leverage PowEmailConfirmation.Ecto.Schema.confirm_email_changeset/1. The pow changeset methods in User.changeset/2 doesn't accept mass assignment, so it won't work passing in :email_confirmed_at. It's not a permitted value.

Thank you again, Dan, for your deep explanations and your time.
All is good now.
I will rework my arities. :)


add support for tables

Sometimes the answer of ChatGPT contains tables (<table> ... </table>),
but currently exportJSON.js does not support tables.
Tables are omitted from the exported json.

Thanks! Tables are now supported for JSON, markdown, and image exporting.
I've updated the /dist/json.min.js script so tables will now be included in the exported JSON.


Items being created in the wrong namespace

Trying to update Spartan Fire to 1.16.5 I have found multiple items being created in the spartanweaponry namespace instead of in the [modid] namespace, as shown below these include:
boomerang
tomahawk
heavy_crossbow
javelin
throwing_knife

[31Jul2021 13:07:18.335] [Worker-Main-8/WARN] [net.minecraft.client.renderer.model.ModelBakery/]: Unable to load model: 'spartanweaponry:tomahawk_dragonbone#inventory' referenced from: spartanweaponry:tomahawk_dragonbone#inventory: java.io.FileNotFoundException: spartanweaponry:models/item/tomahawk_dragonbone.json
[31Jul2021 13:07:18.335] [Worker-Main-8/WARN] [net.minecraft.client.renderer.model.ModelBakery/]: Unable to load model: 'spartanweaponry:throwing_knife_dragonbone#inventory' referenced from: spartanweaponry:throwing_knife_dragonbone#inventory: java.io.FileNotFoundException: spartanweaponry:models/item/throwing_knife_dragonbone.json
[31Jul2021 13:07:18.335] [Worker-Main-8/WARN] [net.minecraft.client.renderer.model.ModelBakery/]: Unable to load model: 'spartanweaponry:heavy_crossbow_dragonbone#inventory' referenced from: spartanweaponry:heavy_crossbow_dragonbone#inventory: java.io.FileNotFoundException: spartanweaponry:models/item/heavy_crossbow_dragonbone.json
[31Jul2021 13:07:18.335] [Worker-Main-8/WARN] [net.minecraft.client.renderer.model.ModelBakery/]: Unable to load model: 'spartanweaponry:javelin_dragonbone#inventory' referenced from: spartanweaponry:javelin_dragonbone#inventory: java.io.FileNotFoundException: spartanweaponry:models/item/javelin_dragonbone.json
[31Jul2021 13:07:18.335] [Worker-Main-8/WARN] [net.minecraft.client.renderer.model.ModelBakery/]: Unable to load model: 'spartanweaponry:boomerang_dragonbone#inventory' referenced from: spartanweaponry:boomerang_dragonbone#inventory: java.io.FileNotFoundException: spartanweaponry:models/item/boomerang_dragonbone.json

Hi, sorry for the late reply.
This is an known issue as I found out working on some of my own addon mods as well. That will be fixed in the next major release.
It's also good to see that Spartan and Fire is still being worked on.

This issue no longer occurs on the 2.2.0 release candidate 2


chore(docs): a better way to handle GitHub issues triage

Please verify the following:

[x] yarn ci:test jest tests pass with new tests, if relevant
[x] README.md has been updated with your changes, if relevant

Describe your PR
As a developer
I am forced to write well-documented issues
So that it sparks joy for maintainers
before

after

content shamely hacked from openpilot 🙈

:tada: This PR is included in version 7.15.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 8.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Withdraw to Binance Wallet

Withdraw Binance Address:
io1jjxy9l4uepzsa2j6f3ae5s4pxgrvh7py2puc65
https://iotexscan.io/action/3bdc1a5ad1b226d7a88d38571a45fefa0f115d171e0e6280129f95fe1db687c3
Wrong transaction and wrong address. Please give my balance 🙏🙏
Waiting For You replay

the issue has been resolved. please check the link again

the issue has been resolved. please check the link again

Resolved in https://github.com/iotexproject/iotex-explorer/commit/89bd6f1d4ad7b7a25b84a1729655f8947feab2e9
closing

Resolved in https://github.com/iotexproject/iotex-explorer/commit/89bd6f1d4ad7b7a25b84a1729655f8947feab2e9
closing


Needs more UI and graphical elements

I think we need more color and graphical elements?

Oh for certain.  This is purely in a build phase while I'm learning how to use jekyll.

Cool  :)
On Tue, Jun 23, 2015 at 10:48 PM, sqorandy<EMAIL_ADDRESS>wrote:

Oh for certain. This is purely in a build phase while I'm learning how to
use jekyll.
—
Reply to this email directly or view it on GitHub
https://github.com/Amplify-Social/Amplify-Social.github.io/issues/3#issuecomment-114734452
.

--
Jason Brody-Stewart-Stroeh


[hotfix] Stabilize python tests

These are some examples of failing python tests:

https://dev.azure.com/rmetzger/Flink/_build/results?buildId=5408&view=logs&j=dee070b7-d526-572b-39a4-ac3b24b600ee&t=b950229e-d858-5111-b60e-d71ec3d8da1d
https://dev.azure.com/rmetzger/Flink/_build/results?buildId=5409&view=logs&j=dee070b7-d526-572b-39a4-ac3b24b600ee&t=b950229e-d858-5111-b60e-d71ec3d8da1d
https://dev.azure.com/rmetzger/Flink/_build/results?buildId=5410&view=results
https://dev.azure.com/rmetzger/Flink/_build/results?buildId=5404&view=logs&j=dee070b7-d526-572b-39a4-ac3b24b600ee&t=b950229e-d858-5111-b60e-d71ec3d8da1d

They all have connection timeout errors:
INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13:04 min
[INFO] Finished at: 2020-02-21T12:23:36+00:00
[INFO] Final Memory: 265M/4463M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project flink-connector-elasticsearch7_2.11: Could not resolve dependencies for project org.apache.flink:flink-connector-elasticsearch7_2.11:jar:1.11-SNAPSHOT: Failed to collect dependencies at org.elasticsearch.client:elasticsearch-rest-high-level-client:jar:7.5.1 -> org.elasticsearch:elasticsearch:jar:7.5.1 -> org.apache.lucene:lucene-core:jar:8.3.0: Failed to read artifact descriptor for org.apache.lucene:lucene-core:jar:8.3.0: Could not transfer artifact org.apache.lucene:lucene-solr-grandparent:pom:8.3.0 from/to google-maven-central (https://maven-central-eu.storage-download.googleapis.com/maven2/): GET request of: org/apache/lucene/lucene-solr-grandparent/8.3.0/lucene-solr-grandparent-8.3.0.pom from google-maven-central failed: Connection reset -> [Help 1]

This hotfix introduces two mitigations:
a) we fail the build if maven fails
b) we use a cache for the python build, so that we don't have to excessively use the mirror

@zentol looks like Ci bot didn't find the second build for AZP: https://dev.azure.com/rmetzger/Flink/_build/results?buildId=5447&view=results


feat(side-navigation): add react component

Used for the new React demo site in development

@FlorentDinet Did you test this component already in the new demo layout POC?

Test ok!


Make ExprReducer faster

Signed-off-by: yatinmaan<EMAIL_ADDRESS>Pull request
Description
Add post_walk_expr method to the ImutExprIntVisitor trait.
Refactor ExprReducer work recursively.
Related

[ ] The RFC, if required, has been submitted and approved
[ ] Any user-facing impact of the changes is reflected in docs.tremor.rs
[ ] The code is tested
[ ] Use of unsafe code is reasoned about in a comment
[ ] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[ ] The performance impact of the change is measured (see below)

Coverage increased (+0.008%) to 85.256% when pulling 29bfce22cdfef4d4e1900b2cd54b2d9a7b63db8b on yatinmaan:expr_reducer_go_brrrrr into 6faec85bb41cefb81123a535917e769d628c8473 on tremor-rs:main.


Add a 'titlecase' executable that capitalizes its command-line arguments.

$ cabal -v0 run titlecase -- titlecase is a useful shell utility to have
Titlecase Is a Useful Shell Utility to Have

Ping?

@peti Pong. I'm extremely busy these days, but I'll try to resolve all the issues ASAP. I wanted to do it 7 days ago but didn't find the time.

@peti I've just tested it and pushed to master. I'd like to clean up some things before releasing a new version, so feel free to poke me if I forget or something. Thanks!

@peti Just released a new version.


Editor crash when select multi lines and do some actions..

VS Code Version:1.56.0(user setpup)
OS Version:<IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.18362

Steps to Reproduce:
1.Select multi lines
2.ctrl+k,ctrl+c
3.ctrl+k,ctrl+u
4.Click the selected character..

Does this issue occur when all extensions are disabled?: Yes/No

@ifeuille I could not reproduce. Do you have additional information or maybe a screen recording to demonstrate the problem:
https://user-images.githubusercontent.com/5047891/121002278-76f44180-c78c-11eb-869f-f7c2e44de504.mp4


Use with React

Can meteor-mysql be used with React rendering in Meteor? I have a problem with a subscription that requires a parameter. I tried the following:
  ...
  mixins: [ReactMeteorData],

  getMeteorData() {
    let rooms = new MysqlSubscription('myPub','parameter (changing)');
    return {
      rooms: rooms.reactive(),
      ready: rooms.ready()
    };
  },
  ...

but it throws Error: Subscription failed!. Another thing I tried is having one global subscription and updating it with .change():
  ...
  componentWillUpdate() {
  	console.log('component will update');
  	eventsOnDate.change(this.getParams().date);
  },
  ...

but this results in rooms.ready() staying false forever.

If you want me to take a look, give a link to a repository with the minimal code to reproduce the issue that I can clone.

I'm also wondering about this. You call depend() and reactive() inside of template helper functions as per documentation which works great with the default templating, but what would it look like inside of a react component?

ah nvm after a bit more research I've added react-template-helper to our project and it complements this very well. thanks!

I have run into this issue as well. To test it, I've created a Meteor-React-Mysql version of the Tasks app from the tutorial using mysql and put it into a repository, meteor-react-mysql-tasks.
I can publish/subscribe and select all rows from a table, but whenever I try to use a parameterized subscription, e.g. filter tasks by owner, completed or public/private, I run into issues.
Part of this might be my misunderstanding of where the calls like foo = new MysqlSubscription('bar', params) should go in React. In getMeteorData() it throws "Error: Subscription failed", but it has to live in a place where the parameters it needs to get are scoped, whether they be state values, or the Meteor.user().
Here's the full exception:
Exception from Tracker recompute function:
debug.js:41 Error: Subscription failed!
at Array.MysqlSubscription (MysqlSubscription.js:40)
at React.createClass.getMeteorData (app.jsx:19)
at meteor-data-mixin.jsx:89
at Tracker.Computation._compute (tracker.js:323)
at new Tracker.Computation (tracker.js:211)
at Object.Tracker.autorun (tracker.js:562)
at meteor-data-mixin.jsx:76
at Object.Tracker.nonreactive (tracker.js:589)
at MeteorDataManager.calculateData (meteor-data-mixin.jsx:75)
at ReactMeteorData.componentWillUpdate (meteor-data-mixin.jsx:22)

Another thing, in the Tasks implementation above, I make a call to change() on the subscription when the user toggles Hide Completed tasks. It seems to work once. Clicked again, it doesn't update the results.

I know it's too late :) but am having same issue any one fixed that @hectoroso @numtel @areim3r @tvogels
any help will be greatly appreciated


ShouldContainXXX: allow to replace "elements" by a more specific name

Summary
ShouldContainOnly is used in a few places where we know what kind of elements we are dealing with, in this case instead of using the term element we could use a more descriptive name.
Example
Spliterator<?> actual = createSpliterator(SORTED | ORDERED);
spliterators.assertHasOnlyCharacteristics(INFO, actual, DISTINCT, SORTED);

fails with this error
Expecting:
  <["ORDERED", "SORTED"]>
to contain only:
  <["DISTINCT", "SORTED"]>
elements not found:
  <["DISTINCT"]>
and elements not expected:
  <["ORDERED"]>

but we could have
Expecting spliterator characteristics:
  <["ORDERED", "SORTED"]>
to contain only:
  <["DISTINCT", "SORTED"]>
characteristics not found:
  <["DISTINCT"]>
and characteristics not expected:
  <["ORDERED"]>

Same thing for ShouldContain.

Hi,
I would like to work on this issue.

Go for it @WuYff!

Hi @joel-costigliola ,
I tried to implement this improvement.
My idea is: If the method is called through the class of Arrays/Maps/Spliterators, it will print the corresponding name. If not, I will use the class name of the parameter Object actual as the name.
The problem is that I find some existing tests would fail, because they check for the output in a hard code way. For example:
 @Test
  public void should_be_able_to_catch_exceptions_thrown_by_map_assertions() {
    // GIVEN
    Map<String, String> map = mapOf(MapEntry.entry("54", "55"));
    // WHEN
    softly.assertThat(map).contains(MapEntry.entry("1", "2")).isEmpty();
    // THEN
    List<Throwable> errors = softly.errorsCollected();
    assertThat(errors).hasSize(2);
    assertThat(errors.get(0)).hasMessageStartingWith(format("%nExpecting:%n"
                                                            + " <{\"54\"=\"55\"}>%n"
                                                            + "to contain:%n"
                                                            + " <[MapEntry[key=\"1\", value=\"2\"]]>%n"
                                                            + "but could not find:%n"
                                                            + " <[MapEntry[key=\"1\", value=\"2\"]]>%n"));
    assertThat(errors.get(1)).hasMessageStartingWith(format("%nExpecting empty but was:<{\"54\"=\"55\"}>"));
  }

with test failed message:
java.lang.AssertionError:
Expecting:
 <"
Expecting map:
 <{"54"="55"}>
to contain:
 <[MapEntry[key="1", value="2"]]>
but could not find:
 <[MapEntry[key="1", value="2"]]>
">
to start with:
 <"
Expecting:
 <{"54"="55"}>
to contain:
 <[MapEntry[key="1", value="2"]]>
but could not find:
 <[MapEntry[key="1", value="2"]]>
">

I also find that similarly hard code tests in ShouldContain_create_Test.java and ShouldContainOnly_create_Test.java
Should I modify the existing tests? Do you have any suggestions or ideas?

The failing tests should be refactored by using shoudContain to build the error message.
For the given example the message assertions can be replaced by:
assertThat(errors.get(0)).hasMessage(shouldContain(map,
                                                   newLinkedHashSet(MapEntry.entry("1", "2")),
                                                   newLinkedHashSet(MapEntry.entry("1", "2"))).create());

Let me know if you have other questions.
Don't hesitate to raise a pull request even if it is not complete if you want to discuss a specific implementation point.

Done in the the above PRs.


convert.back() not respecting return from function?

I am working on a Koa v1 app and would like to implement new routes with async/await instead of generator functions. I found this library has convert.back() which is mostly working for me. However, the following example code will illustrate my problem:
router.get('/endpoint',
async function(next) {
    const token = this.request.headers.token;
    if (!token) {
        this.response.status = 401;
        return;
    }
    // I assume next is a Promise so this is not an issue?
    await next;
},
async function(next) {
    // This code still executes, even if there is no token defined on the headers.

    // Do something important that shouldn't execute with invalid auth...
});

return convert.back(router.routes());

If there is no token defined, the endpoint does return a 401 and exits the first function, but the second function is still executed. If I set up the first function as a generator function and use yield next, it works as would be expected.
Versions:
node: 6.13.1
npm: 3.10.10
├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>

I think<EMAIL_ADDRESS>is still using koa-v1 signature (generator function) and does not support koa-v2+ signature (async await function).
How about using koa-router@7 (it support koa-v2+ signature) with following code ?
//<EMAIL_ADDRESS>router.get('/endpoint',
async (ctx, next) => {
    const token = ctx.request.headers.token;
    if (!token) {
        ctx.response.status = 401;
        return;
    }
    await next();
},
async (ctx, next) => {
    // This code still executes, even if there is no token defined on the headers.

    // Do something important that shouldn't execute with invalid auth...
});

// `router.routes()` will return async-await style middleware in koa-router@7
// `convert.back` will convert async-await style middleware to generator function style middleware
// then it can be used for koa-v1 app.
return convert.back(router.routes());

Or if you have to use<EMAIL_ADDRESS>you can convert each individual async functions like following:
//<EMAIL_ADDRESS>router.get('/endpoint',
convert.back(async (ctx, next) => {
    const token = ctx.request.headers.token;
    if (!token) {
        ctx.response.status = 401;
        return;
    }
    // I assume next is a Promise so this is not an issue?
    await next();
}),
convert.back(async (ctx, next) => {
    // This code still executes, even if there is no token defined on the headers.

    // Do something important that shouldn't execute with invalid auth...
}));

// no need `convert.back` here because it's already koa-v1 style middleware
// and it can be consumed by koa-v1 app directly.
return router.routes();

Thanks for the quick response. Makes sense!
I think the easiest router forward at this point is to just stick with 5.4.2 and wrap them all until I have the time to upgrade to v7 and test everything.
Was there somewhere I could have found this in documentation? I was struggling to find info about properly implementing the convert.back() feature. This issue will at least exist for anyone stuck in this situation in the future.