[CO] EEC reorganization and LUT as a daughter of XOutput

Hello all,
As a follow up of our discussions in https://github.com/Eomys/pyleecan/pull/481 and https://github.com/EOMYS-Public/pyleecan/pull/12, we would like to gather in a single issue a fully detailed proposal on how to organize the Electrical module, EEC and LUT objects based on @SebGue idea to have LUT as a daughter of XOutput.
The first point is regarding the EEC objects. For now, to store the parameters we use a dictionary which is flexible but not standard. EEC_SCIM, EEC_LSRPM and EEC_PMSM are linked to specific and unique equivalent circuit with a frozen list of parameters. We propose to replace the parameters dict by the correct set of properties (R1, R2, L1, L2…) with the proper type, description, and min/max in the corresponding EEC objects csv files.
Then we would use EEC objects both in Simulation.elec and in OutputElec (instead of the param dict). In a Simulation object, if a EEC value is at None it means that this parameter needs to be computed else it is enforced. comp_parameter would copy the simulation.elec.eec object and compute/enforce the corresponding parameters to get a full EEC (at the proper temperature and OP). So simu.elec.eec is the “initial state” of the EEC, Out.elec.ecc is the complete state for the corresponding temperature / OP. When a parameter is enforced, there is no computation to adapt the temperature and OP on this parameter, we assume that the user has provided the correct one.
If new EEC or variation of the existing ones needs to be added, other objects with the proper properties/methods can be added (including by using polymorphism).
Regarding the use of LUT in Electrical module it would be as follow:

the property would be moved from simu.elec.eec.LUT_enforced to simu.elec.LUT_enforced
LUT will contains an EEC at a given temperature and OP (known and stored in the LUT) and some tables (Phid, Phiq = fct(Id, Iq) for PMSM, Lm=fct(Im)  for SCIM)
LUT would have method named “get_EEC(T=X, OP=Y)” that would adapt the parameter of its EEC to match T=X, OP=Y (if a parameter is missing from the LUT EEC, it would be computed directly). This method would encapsulate a call to eec methods with the same purpose adapted to the eec actual properties.
Electrical.run would first check for Elut to adapt a EEC, if not provided eec.comp_parameters would be called. In both cases a output.elec.eec is generated and output.elec.eec.solve can be called.
These modifications should simplify the comp_parameter methods

With this new standard for EEC, the LUT organization as a daughter of XOutput can be defined as follow:

LUT.simu as for all XOutput it should be the “simulation that generated the XOutput”
We differentiate two kinds of LUT (same object different content):

the MLUT elec=None, mag != None var_simu=VarLoadCurrent
the ELUT elec != None, mag != None and var_simu=VarLoadVoltage.

There are two daughters of LUT, LUTdq and LUTslip that store some tables (Phid, Phiq = fct(Id, Iq) for PMSM, Lm=fct(Im)  for SCIM) and provide the dedicated methods to adapt the EEC
the machine is stored in LUT.simu.machine
the EEC is stored both in ELUT.simu.elec.eec and ELUT.elec.eec
The magnetic model needed to compute the flux, torque and inductances can be stored in LUT.simu.mag and the resulting data stored in LUT.output_list.mag
The usual DataKeeper (N0, Id, Iq…) can be added to enable some plot
All the plot are natively available since the LUT is a XOutput object

A method ELUT.get_electrical would enable to retrieve Data object of the eec parameters as a function of (N0, frequency) =>  Plot
@SebGue what do you think about this organization proposal? We are currently working on Manatee SCIM models and we would like to include the “LUT as a daughter of XOutput” to handle the retro-compatibility with our old format. We plan to work on that on next week, do you think that you would have some time to review this issue so we can agree on the LUT format and usage? If we both agree we can introduce these modifications directly within pyleecan otherwise we will work in Manatee and handle the merge latter one. For PMSM this rework won't have a major impact, it's only code refactoring around EEC. One part of the eec will be generated by the MLUT (values for Phid/Phiq/Phi_mag/Ld/Lq) and the other part by the eec itself (stator resistance accounting for temperature and skin effect).
As always we are open to any suggestion to improve/correct this proposal to make sure that it will be compatible with your usage as well.
Best regards,
Pierre

Hello @BonneelP,
I will take the time and review this issue and come back with a lot of questions soon ;-)

Thanks :)

Hello Pierre,
at first I think we got somehow different use cases for EEC and LUT. I guess you are more likely to analyse single OPs in terms of 'harmonic behavior' (for NVH, ...). While I mostly want to calculate general machine performance, i.e. datasheets with current, voltage and efficiency maps and so on. Therefore, there may be some inherent issues when trying to merge our ideas.
Nevertheless, I'm not quite sure about some aspects, e.g. the copying of the EEC you mention in section 3 of your proposal. Wouldn't this increase the amoung of data significantly? (OT: Have you tried H5 compression results when there is the same object is nested in another object multiple times?)
But the copying aspect may not be a problem if I use an independent 'Performance Charaterization' class for my purpose.
The maybe most important aspect I don't understand yet is the section regarding LUT. There you propose ...

LUT will contains an EEC at a given temperature and OP (known and stored in the LUT) and some tables (Phid, Phiq = fct(Id, Iq) for PMSM, Lm=fct(Im) for SCIM)
LUT would have method ...

Why should the EEC be in LUT? For now in my implementation the LUT is in the EEC. Where do you see the benefit of you proposal? Does your EEC have fixed parameter depending on only one OP?
In that context we should maybe also clarify what EEC means to both of us.
On the other hand, I really like your idea of dynamically extending the LUT if some parameter is missing.
For now, I think this is enough aspect to discuss. I really seeing forward for you answer.
Best regards, Sebastian

Hello Sebastian,
Thank you for your feedback :)
Regarding the usage of the EEC, our usual simulation will include a VarLoadVoltage to iterate on several operating point as we do for the VarLoadCurrent. We keep the assumption of Simu1 that each OP is independent and that each model is sequential (which for some usage won't be right). This is why we are more focusing on a "single OP" (and float parameters) approach for the EEC, but indeed we already have some scripts where we use array of Id/Iq/EEC parameters (Tests\Validation\Electrical\test_EEC_ELUT_PMSM.py) but we can provide dedicated methods to handle them.
Regarding the copying of the EEC, for now we have a eec.parameters that is duplicate to initialized the output dict of comp_parameters. If eec.parameters is set with all the parameters then the copy mechanism is already in the code. We want to remove this dictionary because it can be source of error and confusion for the user (which parameter of which type...). Having the parameters within the csv should be more clear. But then the output of comp_parameters should also be an EEC object to have all its output (the same as the enforced one) in a csv as well. We think about the copy to avoid updating the input EEC (which could create some error if running the simulation twice).
With your remark, I realized that maybe rather than introducing all the parameters property into EEC_X we should create a new object EEC_X_Param that will be included in the EEC_X object (to enforce or not) and in the OutElec (the result/updated values). This new object would only contains the parameters of the EEC (R1, L1, ...) as float so saving them shouldn't be too costly. Then we won't copy all the other property of the EEC object (like all the model related ones). Then in each OP of the VarLoadVoltage we need to adapt the parameter to the frequency/temperature and so these parameters can be different in each output_list then it would make sense to save them all for plotting. But as the next step after comp_parameter is eec.solve maybe it would be more convenient to return an eec object with completed parameters.
We haven't investigated H5 since the "type_handle_ndarray" modification but we know that we need to further investigate the save/load procedure to improve their performances.
For now the LUT contains the parameters of the EEC to be enforced/updated into the parameter dict. If EEC_X (or EEC_X_Param) contains the same properties then it would be more efficient to remove the properties of LUT and to use directly the EEC ones. Otherwise when introducing new EEC or extending the current ones with new parameters it would require to change the LUT csv. With a EEC object within the LUT, we can benefit from the polymorphism of the EEC class and we have the models to compute the missing parameters if needed.

Does your EEC have fixed parameter depending on only one OP?

For me the EEC_X_Param/EEC_X would be the parameter of an EEC at a given OP and a given temperature (stored within the EEC_X_Param). Then LUT would contain a "reference" EEC_X_Param that would be updated for each OP of the VarLoadVoltage.
Thank you again for your questions, they are always helpful :) I hope that our aim is more clear now and we can carry on the discussion if you have other questions.
Best regards,
Pierre

Hello Pierre,
I think I'm slowly getting used to your point of view. Further I think I can adapt to it. But first let me recap your proposal, skipping some details.
One got some LUT (a magnetic look up table with flux linkage and some losses, e.g. iron losses) and derive a single OP (i.e. fixed parameter) EEC by calling LUT.get_EEC(OP, ...). The EEC then will be used to calculate some machine behaviour, e.g. voltages, torque, ...
That seems resonable on the given assumptions but also has some drawbacks. I.e. with the 'float' parameters of EEC you can at most only simulate the small signal behavoir of the machine in the OP. You won't be able to e.g. simulate a ramp up or some changes in current. For (e.g. input voltage) harmonics calculations there had to be some frequency dependence in the parameters to get valid results.
But thats okay for me (at least at the moment). What I need would be some OPs with mechanical reference values and the possibility to imply some control strategy (mostly MTPA) to get the EECs.
What do you think, how can we go ahead with this issue?
BR S

One got some LUT (a magnetic look up table with flux linkage and some losses, e.g. iron losses) and derive a single OP (i.e. fixed parameter) EEC by calling LUT.get_EEC(OP, ...). The EEC then will be used to calculate some machine behaviour, e.g. voltages, torque, ...

Yes the user usually will provide all the EEC parameters at a given temperature/OP and then we will adapt that within the simulation.

ou won't be able to e.g. simulate a ramp up or some changes in current

That is also an assumption in the structure of the Simu1 and Magnetics models (which is fixed speed only and use time periodicity to speed-up). The "Variable speed" in pyleecan Simu1 is a superposition of fixed speed simulations. We plan to create dedicated models and simulations objects to handle transient simulation in the future for instance.
Regarding the harmonics in the current and voltage (cf PWM) we handle them by superposition but still within the previous assumptions.

What I need would be some OPs with mechanical reference values and the possibility to imply some control strategy (mostly MTPA) to get the EECs.

This is an interesting workflow that we need to include in pyleecan somehow. Do you plan to carry on the computation into the Magnetic modules or can it be a "Electrical only" simulation ? We had several thought on how we could extend the Electrical module outside of Simu1. We could for instance have a Simu2 objects that would handle loops between an electrical/heat transfer models and have a dedicated Input object with a N0(t) axes in it. It will be really interesting to find ways of sharing objects and methods between several kinds of simulations with different structure/assumptions.
For the next steps we have the following strategy in mind:
First we update pyleecan models to match our latest work to make sure that the models are validated: #504
Then we update all 3 EEC to have the parameters as properties and the dedicated comp_X/adapt_X/get_X methods (basically we reorganized comp_parameters). (A dedicated PR will be done to close/validate this step)
Finally we reorganise the LUT object as a daughter of XOutput and to use EEC objects.
Best regards,
Pierre

Hello @BonneelP ,
so here are some thoughts, concerns and questions on some details of this issue and #506.
First I just realized that EEC_SCIM uses lookup tables while EEC_PMSM is float parameters only. Why's that?
Now with the actual implemention, I again question the benefits of your proposal (at least for PMSM). Maybe you could give me some more detail how you use Electrical/EEC and what your results are.

The inductances used are absolute inductances, i.e. (Psi_d - Psi_mag) / I_d. For calculation of e.g. PWM current harmonics (i.e. small deviations of current around the OP), the use of differential inductances would be beneficial. At least if there is some saturation of the machine.
The LUT EEC setup (EEC.update_from_ref) will only work if the current is known a priori. Otherwise the parameters will be off. Especially if Electrical is voltage driven. Do you see any chance to implement the above workflow with a torque reference OP? Maybe the EEC itself (EEC.solve in a loop or an optimization) could find the respective current here?! But then we also need some control strategy to apply here too.

Further EEC_PMSM should also include (iron) losses as EEC_SCIM do.
And last but not least, the LUT should adapt the EECs to 'similar machines', i.e. machines that fulfill certain critiria. E.g. if one modify the length or the number of turns of a maschine, it would be a waste of computational time if the LUT was recomputed. Rather the LUT should scale results to the new machine by length, winding factor, etc.
So, I think this is enough input for now. :-)
Best regards, Sebastian

Hello @SebGue,
The EEC_SCIM uses a look up table for the magnetizing inductance that the user fills as a prerequisite. It could also be calculated with Pyleecan of course.
In EEC_PMSM.solve_PWM(), PWM current harmonics are calculated using absolute inductances as a first approximation. No problem to add new methods to calculate differential inductances from the LUTdq and then add a new solve_PWM() to the EEC_PMSM object, or create another EEC_PMSM object.
For voltage driven and torque driven workflows, I think that we just have to include the methods that you developed on your side. The EEC_PMSM can call different solve() method depending on Input type (InputCurrent / InputVoltage / InputTorque or InputPower that we don't have for now) and a control strategy (e.g. MTPA or other strategy), and find a solution as long as the input LUT is relevant.
Finally, I don't see any problem to extend existing EEC_PMSM object to iron losses and adapt it to similar machines, we just need to include your methods that already account for that.
Best regards,
Emile

Hello @EmileDvs,
the question about EEC_SCIM mag. table was, why you use a table there but don't want to use it in EEC_PMSM.
Is EEC_PMSM.solve_PWM() somehow limited to PWM. Looking though the code it doesn't seems to be. So my proposal would be to rename it more general 'solve_harmonics'.
Further I would vote for the use of differential inductances (including cross coupling) right now, since EEC also has OP's fluxlinkage as a parameter too. With current driven EEC_solve() you use fluxlinkage anyway. For voltage driven mode if the current is off the inital guess by some small amoung, differential inductance results should be better.
Since differential inductance is not always known (e.g. if there is no LUT), we could allow some sparse input of parameters (eigther fluxlinkage or inductance) and assume/set differential inductance equal to absolute inductance.
Regarding the workflows, I think you got to decide on how and where we integrate that in the organization of the objects and the actual implementation. (One way could be the use of EEC methods itself as in 2. of my previous answer.)
For the actual algorithym and control strategy, we should discuss that seperatly, since I'm not too much satisfied with my implementation. (Robustness seems to be an issue.)
So if you got further things to do for me, other than discussion, just tell me.
I'm really interested in your response.
Best regards, Sebastian

Hello Sebastian,
Regarding the MTPA we thought about the following solution (it would be available with the LUT as a daughter of XOutput):

First we compute a LUTdq on a Id/Iq grid with a VarLoadCurrent and a MagFEMM to get the Phi_wind (we may introduce a "XOutput.to_LUT" method)
Then we add a method to LUTdq to compute the MTPA from the Id/Iq/Phi_wind table.
The Electrical / EEC_PMSM objects could then be adapted to call this method within an InputVoltage/InputTorque (we need to clarify the workflow for that)

We could also call a the MTPA method of the LUT to generate a VarLoadCurrent to create a new simulation.
Best regards,
Pierre

Hello Pierre,
I think, getting MTPA curves from LUT is a great thing.
I just wonder if/how we can adapt the resulting workflow to other strategies as well, i.e. MTPV (min. voltage) or some minimal loss (or even temperature) strategy. For now maybe some 'type_control_stratey' property is sufficient.

The Electrical / EEC_PMSM objects could then be adapted to call this method within an InputVoltage/InputTorque (we need to clarify the workflow for that)

Still this point is the most interessting for me (see above).
BR S

the question about EEC_SCIM mag. table was, why you use a table there but don't want to use it in EEC_PMSM.

We need the tables to be copied from the LUT object to the EEC_SCIM object because they are used inside the solve() method to solve the circuit accounting for non-linear magnetizing inductance. It is also something we can do for EEC_PMSM if some tables are required in the solve() method.

Is EEC_PMSM.solve_PWM() somehow limited to PWM. Looking though the code it doesn't seems to be. So my proposal would be to rename it more general 'solve_harmonics'.

It is something I wanted to do first but then I realized that inputs to calculate current harmonics due to PWM voltage harmonics or due to BEMF/saturation voltage harmonics are not the same, and also the EEC differs somehow since we have to account for harmonics in the flux linkage whereas it is not required for PWM calculation.  That's why I created a specific method to only deal with PWM harmonics, and I was more inclined to add another method "solve_BEMF" if needed to include them in the current calculation as well.
Concerning differential inductances I've never used them so. I think it's would be very interesting to have another method to calculate current harmonics based on their knowledge, while keeping the model with absolute inductances.
Once we'll have reworked the LUT as child of XOutput, we'll have the possibility to call several methods to get (Id,Iq) for a given control strategy using the LUT methods.

Done in #507


FEATURE - implement realtime alert functionality

What it Does
Wire the implemented UI for realtime alert system with the server so that it gets updated each time new alert is arrived

Closes #107
Describe what your change does
Add functionality to realtime alert system by:

listening to the server for newly added alerts
Add a query to get only ONE alert with isOn: true, and if there are viewed alerts previously, append to the query to exclude all alerts that ids match the persisted ids
if the alert is new, present it and save its id locally so that it gets filtered next time when new alerts are received

How I Tested

Install the app and run it for the first time
An alert should appear on the screen
Dismiss it
Reopen the app
Notice the behavior

Notes

When running the app for the second time, there will be an error from the firebase in the console as shown in the screenshot below, as per the answer here, @mikaelacaron should open that link so that it gets created automatically afterwards. (please let me know if there is something else I should do about it)

Screenshot

Add a screenshot of your new feature! OR show a screen recording of it in action. (On the simulator press Cmd + R to record, and the stop button when done). This video should be no longer than 30 seconds.

showing \n\n rather than as line breaks

the title is clipped


Add retry logic to support temporary redis cluster failure

This changes are trying to complete the retry logic in order to increase the tolerance to a temporary unavailability of a redis cluster.
Tests are slow (retries...), so I added the to group "slow":
vendor/bin/phpunit --group slow --filter RedisClusterTest
Related to PR #732

Hi tillkruss,
I have updated the unit tests to take into account your latest changes.


feat: allow multiple position in a workplace

This PR adds support for multiple position/team in one workplace. Could you please recheck the updated JSON schema? I am afraid I missed one or two 😅

@jskherman I have updated the PR. Could you please check it again? Thank you.
Anyway, actually I'd like to reorder the section so Work -> Education instead of Education -> Work (which I felt a bit weird since we have the example.yml and Typst output arranged differently 😅). What's you preference: should I just add the commit in this PR or create a separate PR?

@jskherman I have updated the PR. Could you please check it again? Thank you.
Anyway, actually I'd like to reorder the section so Work -> Education instead of Education -> Work (which I felt a bit weird since we have the example.yml and Typst output arranged differently 😅). What's you preference: should I just add the commit in this PR or create a separate PR?

It could really go either way for me, but Work => Education makes more sense.

Updated with work and education switched.

I think that's all for now. Thank you for your help!


Transactions tutorial: CARDANO_NODE_SOCKET_PATH not set

In order to execute the command from step 5 from the Transaction tutorial (https://github.com/input-output-hk/cardano-tutorials/blob/master/node-setup/tx.md) we first need to set the CARDANO_NODE_SOCKET_PATH environment variable
cardano-cli shelley transaction submit \
>      --tx-filepath tx001.signed \
>      --network-magic 42
Lookup of environment variable "CARDANO_NODE_SOCKET_PATH" failed.

Thanks.  I noted this issue, but the tutorial wasn't yet ready.  I assumed it was because my node wasn't running


Symbols path for Inkscape OS X Native

Just a note for possible add to the README.md. For Inscape OS X native version, not the XQuartz version. The path is: ~/Library/Application Support/org.inkscape.Inkscape/inkscape/symbols

Experimental unstable "OS X native builds" are not "official" Inkscape packages. The location of the inkscape user profile used with those packages may change any time (since those packages are still work-in-progress, and the changes have not been merged into Inkscape trunk). As packager of osxmenu builds, I would rather not see that path mentioned in README files of other projects at this stage.

I find the path strange as well. However it took me a moment to figure out why the symbols were not loading. When following the README.

[off-topic]
@noorstudies wrote:

I find the path strange as well. However it took me a moment to figure
out why the symbols were not loading. When following the README.

TBH I do not find it that strange (I chose that location myself ;-) ), but since the osxmenu branch is work-in-progress, do not rely on any detail being final. The osxmenu packages include a custom extension BTW which opens a Finder window at the location of the user inkscape profile (to ease testing unstable experimental osxmenu builds). Also, the exact location of the user inkscape profile can be looked up in 'Edit > Preferences > System > User config' (this information is present in experimental osxmenu, stable 0.91 and unstable 0.91+devel builds on all supported platforms).
Besides above details - users who actively chose to install experimental unstable osxmenu builds IMHO are -- to some degree at least -- expected to figure out themselves where certain things are. If that's too much of a burden, I would strongly recommend to stick with stable release builds for now (yes, they are X11-based, we know).
[/off-topic]

I understand what your saying. I learned about osxmenu from someone less puter savvy then myself. Which isn't saying alot. Since I don't know all/much. This was actually the first time I 'needed' to open up Inkscape's preference panel/window/whatever-doo-hicky. BTW I find r12896 to be very stable. Aside from occasionally refusing to quit right away. Oh and org.inkscape.Inkscape/inkscape threw me a 'wtf?' moment. Thought I was being joshed with. Thinking russian doll scenario.

Thanks @su-v for your help! :+1:

@noorstudies

BTW I find r12896 to be very stable.

Latest is r12911 (based on Inkscape trunk r14020), and a newer upload is planned for this week. Inkscape-osxmenu r12902 and later no longer include custom themes for now (defaults to regular GTK2 Adwaita and Inkscape's default icons).
@Xaviju - on another unrelated topic: I had been working on (manually) converting GNOME symbolic icons (from Adwaita icon theme) to (fully re-colorable) Inkscape symbol sets, but am not fully satisfied yet with the result (it would be great to have more automated steps during that conversion, even if the source isn't sufficiently "clean" to convert "as is"). Any comments on the usability of the current state would be welcome: bzr repo (WIP, for now hosted at launchpad)

@su-v great extension! I'll test it as soon as possible. I've also downloaded the icons you created from the bzr repo and test how the generated code looks like. :)

@Xaviju - the current symbols sets of the gnome symbolic icons were created manually (in inkscape, but with heavy usage of the built-in XML editor). The extension I then started working on (not finished) is in most parts based on that experience, trying to minimize a few of the repetitive tasks.
The largest part of the work I spent time with when working on the symbol sets for those icons though is not trivially automated / auto-generated AFAIU (at least not addressed by the work-in-progress extension):

relocate each icon at the SVG origin and remove preserved transforms (including those on parent layer groups)
flatten nested groups within the icon
manually fix rounding errors / floating point issues with integer values
clean-up of unneeded style and other attributes (inkscape can help with that)
etc.

Just a quick example of Font-Awesome as (re-colorable) Inkscape symbol set, created (with Inkscape 0.91+devel) based on the SVG sprites file from https://github.com/encharm/Font-Awesome-SVG-PNG (sprites.svg), with help of the utilities provided by the symbol tools extension (WIP):
Result: https://www.dropbox.com/sh/dy5r4ehll0rgyh4/AAB4wMRh8oI7n0CFvN1JxWM9a?lst

@su-v as I use the icons mostly for frontend development I use to do some more repetitive tasks than usual but this is more or less the pains that my team found, probably not very different from yours:

Creating the icons from the UI requires doing it one to one. In any case, if its not done one per one, it's hard for the UI to know what is an icon and what is not when them are composed of more than one path, I guess.
If the icons have already a color, the color becomes uncolorable. Need to remove fills and strokes manually. (I think you already solved that)
I have to save the as plain SVG to get rid of all the inkscape/sodipodi code I don't need. Lots of inskcape metada that can be fixed if exported as plain SVG instead of inkscape SVG.
I have to remove all the groups and forms to create a basic path, I do it from the code editor but it would be more useful with a simple <path> insted of a bunch of <g> and forms when its not needed. I could use this symbol later for my web developement (this is my perdonal case)
Weird IDs all over the SVG file (is this needed?) <title id="212131">. I use to remove all of them and just keep the item-slug ids.

From the result you share, just watching the code:

I'll remove the inkscape sodipodi metadata about the inkscape page, zoom...
I'll remove the <g> wrapper if not needed (if only contains a single <path>)
I'll remove this inkscape:connector-curvature="0" if not needed.
The <use> tag from line 3146 to 3664 its not needed in the symbol SVG.
Same with the <text> from 3665 to 5221 path, could be removed and save space.

Hope my experience creating this icons is useful for you!
Side-note: I am trying to install your extension. I copied the files to the extension directory and made the py files executable. What shoul I do next? Is there any documentation on how it should work?

@Xaviju
I won't comment right now on what are inkscape-specific questions (I am not a core inkscape developer myself, and topics like for example why Inkscape enforces IDs on all elements (IIRC mentioned in the Inkscape FAQ), and what plans might be in this regard for the future (maybe make this optional) is certainly getting really off-topic here).

What shoul I do next? Is there any documentation on how it should work?

There is no documentation available at this stage - the extension is very much work-in-progress (I'm adding new features as soon as I encounter a need for it), and probably much based on my personally preferred work flows (there's not a single button to apply a sort of 'Do all the magic for me, I don't bother with details' function/effect).
A few comments to the remaining items:

I'll remove the <g> wrapper if not needed (if only contains a single <path>)

The inner wrapper in the example case (font-awesome sprites.svg converted to Inkscape symbol set) was added intentionally (as test) to be able to use the original path data (aka as is), while at the same time being able to scale (down) all original items by the same amount - the original paths (from the sprites file) are huge, and likely not useful when inserted as symbols at their original size e.g. in mockups for web sites drawn in Inkscape. Ideally, the extension would apply the scale factor to the path data (coordinates) directly, but that's somewhat out-of-scope for this extension.

I'll remove this inkscape:connector-curvature="0" if not needed.

Inkscape tends to add these attributes back whenever paths are touched/updated (I dislike that fact too) - maybe I'll add an option to the extension to remove them (though they'll likely get added back as soon as the symbol set file is edited again in Inkscape).

The <use> tag from line 3146 to 3664 its not needed in the symbol SVG.

These have been added intentionally - the symbol sets distributed with inkscape have them too. This is intended as kind of a self-documentation of the symbol set when viewed/edited directly (not via Inkscape's custom 'Symbols' dialog). The symbol instances (<use> elements) are not needed for the 'Symbols' dialog itself.

Same with the <text> from 3665 to 5221 path, could be removed and save space.

Optional, see above (I originally worked on converting Inkscape icon sets to symbol sets, and had the need to know the IDs of the original icons (those IDs are used as icon names when loading icons in the interface, and thus important). For this reason it was added as optional feature to the extension to display the <title> content per symbol on-canvas). Originally I implemented the feature as text with a <tref> child element which references the content of the <title>element (so that it auto-updates), but then I discovered that <tref> won't be part of SVG 2.0 (so Inkscape's buggy handling of such <tref> elements is unlikely getting fixed).


Fix error-state windows on certain placements

About the PR
Fixes the semi-common error sprites that would appear when Colony/Reinforced-Colony windows changed to state 7

Why / Balance
Error bad.

Technical details

When the base colony windows (normally found planet-side) were in a plus configuration, but missing the left side, the middle window(s) would try to display state 7 in the .rsi, which didn't exist. This just duplicates the state 0 png and puts in place of state 7 to prevent this.

(The flip situation of this configuration uses state 0, so thats why I'm just duping it. Yes it looks weird, but the window sprites probably need a look over to fix certain connections/possible configurations)

((also re-ordered the states in the meta.json file because messy/OCD))

Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Merging this will fix https://discord.com/channels/1168210010233376858/1249463155361452143


AzureMLPipelineDataSet not compatible with pipeline_ml_factory method from kedro-mlflow

The pipeline_ml_factory method in kedro-mlflow is a useful method to store artifacts (transformers, models) automatically (using kedro-mlflow hook). However, this method calls the method extract_pipeline_artifacts which requires the _filepath attribute to be available (see here).
AzureMLPipelineDataSet class does not provide this attribute.
Wouldn't it be possible to add it to the class attributes?
Do you have any other suggestion to store the Mlflow Pipeline ?

If adding _filepath helps, then no problem. We're open to PRs :)
@Galileo-Galilei any other suggestions?

Added _filepath in https://github.com/getindata/kedro-azureml/blob/2e5836b72256d7455d8525c7769a68d4c844ccf7/kedro_azureml/datasets/pipeline_dataset.py#L100
It's already released in 0.4.0. @jpoullet2000 please let me know if it fixes the problem.

currently out of office. I'll come back to you in 2 weeks.

Sorry for the late reply, I was on holidays too. Just to understand, what does this dataset is intended to do?
Actually, kedro-mlflow should only check the filepath for the datasets it needs to use as artifacts for mlflow. So either this is a bug (kedro-mlflow does check the filepath on a dataset it should not) or this solution won't work (kedro-mlflow won't complain, but if there is no data at the given filepath, it will not be able to log it in mlflow nor to fetch it at inference time). What does your pipeline look like? What are you trying to do?

Hi. Sorry for the late reply. The goal is to store a mlflow pipeline while running a azureml pipeline wrapping a kedro pipeline. I'd like to use the pipeline_ml_factory method for that. It seems that the issue comes from the fact that kedro-azureml decomposes the kedro nodes in azureml nodes and the transformers and models (pickle files) are not shared between the training pipeline and the inference pipeline.  That's the reason why I wanted to use the AzureMLPipelineDataSet which should pass the data from one node to the other. But I'm still not convinced that it solves the issue (still testing)..

It's specific to kedro-mlflow, any hints @Galileo-Galilei ?

It seems that the issue comes from the fact that kedro-azureml decomposes the kedro nodes in azureml nodes and the transformers and models (pickle files) are not shared between the training pipeline and the inference pipeline.

As for that - we indeed split the kedro nodes into Azure ML nodes, but I don't understand the "are not shared between training and inference". Data is shared via Kedro's Data Catalog, so when any node needs to load something, it goes to the Data Catalog. While running on Azure ML, if the entry is missing from the catalog, our plugin automatically loads the data from the temporary storage set in azureml.yml https://github.com/getindata/kedro-azureml/blob/a040b3c65c57a38cf6a64ca0d0792e471abe6911/kedro_azureml/config.py#L95
If you've opted in the preview feature pipeline_data_passing, then the data will be passed via Azure ML-mounted files.
Maybe it's a problem in kedro-mlflow, that it cannot recognize that the data is passed implicitly. Have you tried explicitly defining your inputs/outputs (e.g. scaler, rf_model etc) in the catalog? If they will be defined, then there should be no issue with loading them from any node.

PIpeline Inference Model contains both the scaler and RF model and is generated by the pipeline_ml_factory.
I also have the feeling that the kedro hooks at the pipeline level are not usable with kedro-azureml. @marrrcin , can you confirm ?


Extend Support for More Image Types

The tool supports a limited set of image types. We need to add support for more types like BMP, TIFF, etc.

Hello! Can I be assigned this issue?

Yeah sure!


Incorrect number of statements in python 3.8.0

Describe the bug
Coverage gives different results in python 3.8.0 than what it did in 3.7.4
Output from Python 3.7.4:

Name
Stmts
Miss
Branch
BrPart
Cover

TOTAL
5078
511
1251
132
87%

245 passed, 36 warnings
Output from Python 3.8.0:

Name
Stmts
Miss
Branch
BrPart
Cover

TOTAL
7981
3737
1482
588
53%

245 passed, 36 warnings
It seems like in 3.8 statements are being counted more than once.
To Reproduce
I'm having this issue in a private repo that I'm not allowed to share and I haven't been able to isolate the problem to just one file to be able to reproduce it in a different code base.
I'm doing this in Python 3.7.4 and 3.8.0
Using coverage-4.5.1, pytest-5.2.1 pytest-cov-2.7.1
I'm also using hypothesis-4.41.3 if that helps.
I get the same number of statements with out without branch = True and show_missing = True.
I get the same result if pytest prints the coverage report to the terminal than using coverage run and then coverage report.

I'm not surprised that the numbers might change a little bit from version to version, but these numbers are changing a lot.
The first thing to do is try using the latest coverage (4.5.4) or even the latest alpha of 5.0 (5.0a8).  There are fixes for 3.8 in each of them that are not in 4.5.1
If that doesn't clear it up, can you compare the specific results for the same file in the two versions to see how the lines are categorized differently? In the HTML report, you can turn on the green line markers to get a better idea.

Thanks for the comment @nedbat I'll try the latest version of the library and se if that fixes it.
I also noticed that the HTML report is not displaying the missed things. I can see the green and yellow lines, but it's not displaying the red lines.

I don't understand why the HTML report would be different than the text report.  Did you try the buttons at the top of the page, like these:

"8 missing" is clickable, and toggles the red lines on and off.

I tested again with python 3.8 but this time using the latest version of coverage and everything is working fine again. Sorry for not checking this in advance.
When I created this issue I thought I was using the latest version of coverage but it was just the latest one I had access to on an offline system.
Just to clarify the issue with the html report in case is relevant, the square saying 8 missing is showing the same number as the text report. But no lines are actually marked red. I did try the buttons at the top. Even without clicking the button I should be able to see the red color on the left margin but it's not showing.
I'm closing this now as it is not an issue on the latest version.

https://github.com/CastixGitHub/i3-workspace-names-daemon/runs/6442335256?check_suite_focus=true
I had the same issue with python 3.8.12-final-0 and coverage 6.3.3


Use EvaluateError to throw exceptions

Currently EvaluateError isn't being used as it wont work well with error messages, so consider using it to throw exceptions instead.

Fixed in c23da907b7f9325eee2bddcc993df95ffc7cac26


Bus stops styling and behavior: center to stroke and make clickable with same styling of bike infrastructure

Bus stops are clickable now.

Excellent!


Remove redundant unalias_nested calls for creating Filter's

Which issue does this PR close?
Closes https://github.com/apache/datafusion/issues/11339
Rationale for this change
In https://github.com/apache/datafusion/pull/11307 we changed Filter to remove any aliases within the expressions.
Thus it is no longer necessary to unalias the expressions prior to calling Filter::try_new
What changes are included in this PR?

Remove the unalias_nested calls when calling Filter::try_new()

Are these changes tested?
By existing CI
Are there any user-facing changes?
No

Thanks again @jonahgao


Speed up, possibly pare down tests

Is your feature request related to a problem? Please describe.
Tests are taking a really long time to run. Some of the test runs on Windows take more than 2 hours. However, the new arrangement of travis-ci tests, with some parallelization, finishes faster than anything else at this point.
Describe the solution you'd like

Run some of the testpkg and testcmd CircleCI tests in parallel, as is done in the travisci.
Run the container builds and tests in parallel, instead of running them all sequentially
Figure out how to run more relevant tests for certain PRs
Consider a way to rerun only tests in the area of a failure; often failures are due to external dependencies, and it would be nice to just run those again.

Anyway, we spend a lot of time and effort and even money on the tests, and it would be nice for them to complete a little sooner and use less resources.

To reduce usage of our buildkite test runners, we can

Create a dynamic pipeline which only actually executes if golang code has changed
Stop using so many buildkite permutations. Just do mac NFS and Windows NFS (and later we'll have WSL2)

To reduce usage of our buildkite test runners, we can

Create a dynamic pipeline which only actually executes if golang code has changed
Stop using so many buildkite permutations. Just do mac NFS and Windows NFS (and later we'll have WSL2)

I turned off all the macOS and Windows tests except one each for the full tests under NFS. We expect people to be using NFS anyway, and so we might as well focus our tests there.

I turned off all the macOS and Windows tests except one each for the full tests under NFS. We expect people to be using NFS anyway, and so we might as well focus our tests there.

@rfay Is there anything we can do in order to have green status from the CI overall? Otherwise sane PRs are red due to BuildKite.
Should we try the dynamic pipeline route that you suggested above?

Mostly, the problem is not buildkite, but Docker Desktop, which is flaky in Windows and especially on macOS arm64. It's also where people do most of their work. If you have a specific problem or worry I can help with it. I look at every test situation and retest if I don't know the flaky failure intimately. On important PRs I normally get everything green before pulling. I can easily grant you retest privs on buildkite if you have a specific worry.

I happened to examine a Windows NFS buildkite build and there were some amazing offenders.
TestDdevXdebugEnabled takes more than 11 minutes!
--- PASS: TestGetFreePort (126.91s)
--- PASS: TestComposer (560.36s)
--- PASS: TestComposerVersion (103.60s)
--- PASS: TestExtraPackages (150.52s)
--- PASS: TestDdevStart (454.97s)
--- PASS: TestDdevStartUnmanagedSettings (471.01s)
--- PASS: TestDdevXdebugEnabled (683.87s)
--- PASS: TestDdevXhprofEnabled (248.60s)
--- PASS: TestDdevImportDB (159.11s)
--- PASS: TestDdevAllDatabases (267.51s)
--- PASS: TestDdevFullSiteSetup (137.89s)
--- PASS: TestDdevRestoreSnapshot (192.21s)
--- PASS: TestHttpsRedirection (109.17s)
--- PASS: TestWebserverType (134.79s)
--- PASS: TestMutagenSimple (1056.15s)
--- PASS: TestPortOverride (121.46s)
--- PASS: TestConfigMariaDBVersion (414.67s)
--- PASS: TestCmdMutagen (164.03s)
--- PASS: TestCmdPauseContainers (115.75s)
--- PASS: TestPoweroffOnNewVersion (116.53s)
--- PASS: TestCmdSnapshotRestore (104.56s)

I'm going to close this for now, as a number of things have been addressed and there's always more room for work on this. It's an ongoing priority, not an issue. But the recent improvements are good.

Buildkite and circleci don't waste time on docs now
The github actions tests are more focused


This is still a developing project, not even alpha

Hi,
This project is still under development, the PyPI package and GitHub repo are both just placeholders.
I do have a full plan to re-implement it in an open-source way, but it may take some time.
whatever, the idea in the readme should be enough, it should be able to help you create your own generator that fits your needs.

Version 0.0.1 has been successfully launched, acknowledging that there is still a substantial scope for further development and enhancements.


make failed to compile project

One year ago compile this project successfully,
but now have the next error:

configuration:
Ubuntu 20
CUDA 11.4
(cuda toolkit install and all other recommend lib for this project)

change cuda version to cuda10.2


CFv2 requirements

CFv2 will be a substantial restructuring tracked with the 2.0 milestone. The theme of this release is speed. Using CF quickly, contributing to CF quickly, squashing CF bugs quickly.
Guiding Stories
As a CFPB front-end web developer,
I want to copy/paste CF HTML snippets,
So that I can quickly and confidently build UIs.
As a CFPB front-end web developer,
I want CF source code to live in one place,
So that contributing to the framework is straightforward.
Acceptance Criteria

[ ] All CF source code exists in a single repo.
[ ] All open CF GH issues are part of this repo with the component name in brackets in the title.
[ ] A GH issue label exists for every component and issues are labeled appropriately.
[ ] All CF usage docs exist in a single location. See docs management strategy discussion. Contribution docs will be left in CONTRIBUTING.md in this repo.
[ ] Transition to a proper git release flow.
[ ] Make a decision on Bower (see known obstacle below), either:

[ ] Drop support and move to npm
[ ] Auto-push component updates to discrete component repos using a bot
[ ] Publish CF as a whole to Bower and don't separate components

[ ] More ASCII art, preferably of animals and/or robots.
[ ] ...

Known obstacles:

Maintaining Bower support will be tricky. Bower, unlike npm, doesn't store package tarballs. This means every component needs its own repo. Some frameworks handle this through scripted pusher bots. Other frameworks simply don't support independent component installation via Bower.

See #168 for a history of what went into CFv1.

@cfpb/front-end-team-admin Concrete user stories came out of yesterday's discussions. Acceptance criteria is still emerging. Hit me up here or on chat with any questions/concerns.

This is great.
A couple thoughts:

Speed - the point of a framework is to help us implement solution quickly. When using the framework I find the opposite happening. I think moving everything under the one repo, moving to only npm (not sure what this does to other teams), and clean HTML snippets will help here.
The build - whatever build tool is used, grunt/gulp/scripts, simple is great. The fewer options, the better. If tasks can't be removed, something like load-grunt-config goes a long way toward making tasks more manageable.
Speed - yes, again. But this time for contributing. This ties pretty closely to 'the build', but just in general it should be really straightforward for us to make updates.
Docs - seems like there should be a way to integrate the design manual with the framework docs, so that both get generated at the same time (or are even the same?). Using npm it's easy to ignore docs for publishing but still have them available in Github, less clutter doing a npm install.
Variables - all in one place please.

@contolini mentions most of this already, just want to second it and mention some of my pain points.

Thanks for your thoughts, @awolfe76!

Speed - the point of a framework is to help us implement solution quickly. When using the framework I find the opposite happening.

What slows you down with the current stuff we have?

Variables - all in one place please.

If you use the generator, you get that in the form of our cf-vars-overrides.less file. Is there a more elegant way to handle this?

What slows you down with the current stuff we have?

To be honest, it was a while back and I would have to try to build something with it again to really try to give you details. Which I'll do to be more helpful.
But from what I do remember, it took me a while to wrap my head around everything that was happening in the build process (maybe that was me?) but I don't think that it should take time to do. Could be more apparent. I did need to make tweaks to the Grunt tasks for my project needs ... all related to my 2nd bullet.
Where to place overrides and have them included. I think you and I together eventually worked through this. :smile: But this seems like it shouldn't be required, at least very much, when working on a CFPB project.
I found it hard to discover what was possible. Maybe some cleaner documentation would help. Documentation seems like an ongoing pain point for most. Using bootstrap as an example, their docs are easy to navigate and easy to see exactly what you can do, and how to do it. But also, having built things with bootstrap in the past I don't think the documentation was always required. Something about the code base made it clear what you could do with it. Hard to say exactly what that was/is, but again, I'll try something with CF again to see.

If you use the generator, you get that in the form of our cf-vars-overrides.less file. Is there a more elegant way to handle this?

Having one repo, so only one file with variables, seems to do this better. May even remove the need for the generator? If it's one repo, you build and include the right files.
I tend to dig through Github to find things quite a bit (prior to use and even during) and tracking down where a variable was set proved difficult at times.

@awolfe76 I really like the theme of "speed" for this release. And I think you're right that having clear documentation in a single location will do wonders.

it took me a while to wrap my head around everything that was happening in the build process (maybe that was me?)

🙋🏽I've been working in CF since March and I still struggle to debug the build process. I keep forgetting about cf-grunt-config and it's not really clearly documented anywhere. Moving to one repo removes the need for that forgotten grunt repo. We have all our gulp tasks in one separated out folder and it's nice. 👌🏽

There's an interesting parallel discussion thing happening now. @awolfe76 is talking mostly about consuming the framework, but @KimberlyMunoz's point (and the driving force between all the "single repo" talk), is about making it easier for contributors to CF.
@awolfe76 On vars/overrides: This is where the generator shines. It provides you with a project ready to roll that is set up with CFPB styling in a single cf-vars-overrides file, in which you can override any variable you need to. It may not have been that way when you last started a new project, though.
All your points about unclear/missing documentation are definitely well-taken!

@Scotchester Agreed and those two discussion points conveniently align nicely with the two user stories at the top of this page.

There's an interesting parallel discussion thing happening now. @awolfe76 is talking mostly about consuming the framework, but @KimberlyMunoz's point (and the driving force between all the "single repo" talk), is about making it easier for contributors to CF.

I think of these as the same, we build it, we use it, we build it while using it. Using it is the only way to understand how/what to contribute back, outside of design change of course. A lot of the things I've seen mentioned, here and in other issues, help all around. Documentation, cleaner build, cleaner structure, etc.

CFPB styling in a single cf-vars-overrides file

The only issue is when you don't know where a variable came from or what it does. Having everything in one vars file would make it a lot easier to understand relationships, especially when we use one variable as the value for another variable.

The only issue is when you don't know where a variable came from or what it does. Having everything in one vars file would make it a lot easier to understand relationships, especially when we use one variable as the value for another variable.

I'm not clear what you're proposing. How do all the vars get more in a single file?

Not to speak for @jimmynotjim ... but from a contributing stand point they aren't in one file. They are scattered through repos and difficult to track down.
When consuming and using the generator, yes, one file can't be made smaller. :wink:

@awolfe76 Yeah, clarified that with @jimmynotjim via chat. Again, the consumption/contribution tension...
I suggest that we put this specific discussion (variables all in one file) on hold until we figure out if the single-repo solution is viable. That will definitely impact what can/can't be done.

:+1:  one step at a time.

@contolini not sure where else to put this but i added some fixes to yr VZ branch https://github.com/contolini/capital-framework/compare/voltrazord...cfarm:voltrazord?expand=1

@cfarm You could submit a PR to his fork with those :)

@cfarm @Scotchester Let's open PRs against cfpb's voltrazord branch because there's some history wonkiness with mine.

Didn't know which issue was best for this, but just came across MailChimp's Doc site and a few things I think we could borrow. First is breaking apart the more friendly guides and the more technical docs. This would make the project much more approachable to new users while still allowing seasoned users to find code details. Second is the playground. Hosting a live playground on CodePen and embedding them into our site would allow anyone to test out the project, or even just a component, without having to dive in and build it locally, again, making it much more approachable to new users.

I believe this is closed now that Voltrazord is done. @jimmynotjim Could you move your last comment to a more doc-centric issue?


proposal: x/playground: support SVG images in output

The Go playground currently supports displaying images if your output consists of the string "IMAGE:" followed by a base64-encoded PNG (or, presumably because browsers are permissive, GIF).
It would be nice to support SVG images too. The patch is very small: in fact, I created a change (in the wrong place!), but @dmitshur suggested a discussion here would be appropriate. The necessary diff can be seen here.

I would also appreciate guidance on where exactly to make the change(s). I see three places in the golang org that seem to include the IMAGE-rendering code.

One further note. I believe scripting is disabled in SVG images embedded using the <image> tag. MDN states it explicitly for Gecko, and in my tests, Chrome does the same thing, although I'm not familiar enough with the blink sources to validate it in code (despite trying for a while!).


Update configuration.rst

Importing actstream.registry inside the ready function prevents the issue in django 1.9 where the error "django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet." is raised, preventing from starting the server (as mentioned in issues #270, #272 and #274)

Coverage remained the same at 90.877% when pulling 0501c419126e8724728df08389821a3a62cbc56d on hanuprateek:patch-1 into cb77c06b4879f6b4c30b07a02a5e3d69a714252d on justquick:master.


bundle dump missing formulas?

Description
I always used brew bundle dump --force to create Brewfile and sorted manually. My last Brewfile is 4 months old but when today tried it shown much less (almost 2x less) results. Is something wrong with my trying or something was changed in last 4 months?
 This quite likely affects the bundle dump, as the code before these PRs incorrectly assumed formulae in certain circumstances were "installed on request", and therefore needed to be listed in the bundle dump.

Are there formulae you're missing from the new bundle that you'd want to be installed?

I don't know specially package we're missed by this but i did collect those packages long time to being my system worked properly. I do not want then search again to packages those required by any of my program
Can i manually revert old behavior temporarily?

without a reproduction case we're pretty limited on what we're able to do here. can you please provide a minimal Brewfile or steps that reproduce the behaviour you're seeing here?

The Brewfile and how new and old Brewfile looks already included in original post. I will close issue. When appears some package missed, i will re-open. Thank you everyone


Consider how we should write copyright notices

Opened by this comment: https://github.com/autowarefoundation/autoware/pull/29#discussion_r790972404
Reference links:

https://opensource.google/docs/copyright/#the-year
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
https://www.apache.org/legal/src-headers.html
https://www.apache.org/foundation/license-faq.html
https://infra.apache.org/licensing-howto.html
https://www.apache.org/licenses/LICENSE-2.0

I think we can refer to the iceoryx's way as well. It looks nice.
https://github.com/eclipse-iceoryx/iceoryx/blob/master/NOTICE.md
https://github.com/eclipse-iceoryx/iceoryx/blob/master/CONTRIBUTING.md#header

My proposal:
For new files
Rule:

Prepare NOTICE.md and use Copyright yyyy The Autoware Contributors..

Rationale:

As LF says, We don't want to pay a lot of maintenance costs for updating copyright notations.

For existing files
Rule:

Accept the as-is style.
We can change the copyright notation to Copyright yyyy The Autoware Contributors. if we can agree with the original authors to do so.

Rationale:

Since we'll clean up the architecture for Autoware Core, we don't have to care about the existing Universe code so much.
(I guess) We can't change the copyright notations without some agreements with the original authors.

For all files
Rule:

Add SPDX-License-Identifier.
Will accept any other proposals in the future.

Rationale:

SPDX is useful for automatically analyzing licenses.
Since we are not legal professionals, there are a lot of things we don't know.

@xmfcx @kmiya What do think about this?

(I guess) We can't change the copyright notations without some agreements with the original authors.

For this, I think it's a good idea to agree with people who want to write their names to NOTICE.md, that "if you want to write your name here, you have to remove your name from each Copyright notation or agree that the maintainers will remove them.", how about this?

From looking at the Apache examples given, they all say "Copyright yyyy The Apache Foundation" rather than "The Apache Contributors".
Is there some reason why we cannot say Copyright yyyy The Autoware Foundation ?

@LalithVipulananthan (Although I'm not sure I'm right...)

From looking at the Apache examples given, they all say "Copyright yyyy The Apache Foundation" rather than "The Apache Contributors".

The ASF uses Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements..
https://www.apache.org/legal/src-headers.html
I guess why they do so is because they sign a CLA. (But I'm not sure.)

Is there some reason why we cannot say Copyright yyyy The Autoware Foundation ?

I feel if we use The Autoware Foundation then it seems the AWF has the copyright.
But actually, since we don't use CLA and only use DCO instead, I think the copyright will remain with the original author, so The Autoware Foundation isn't correct.

TSC members will talk about this issue.
https://gitlab.com/autowarefoundation/autoware-foundation/-/issues/204

@filiperinaldi Thank you for your information.
Did you recommend replacing the NOTICE file with CONTRIBUTORS.md? Just showing another way?

The PR has moved from #29 to https://github.com/autowarefoundation/autoware-documentation/pull/44.

As https://github.com/autowarefoundation/autoware-documentation/pull/44 is merged, I'll close this issue.
However, everyone can reopen this and propose a change if necessary.


Added Shoot_Single_Bullet_Between_Coords

Added Shoot_Single_Bullet_Between_Coords

Just push in your branch and it will automatically update this pull branch.

Pull from git@github.com:crosire/scripthookvdotnet.git to your repo, resolve conflicts (if they are) and push.


Fix webhooks logging of excessive events

I want to merge this change because it limits logging of send_webhook_request - it no longer logs error, it handles failure and logs on debug level that it happened.

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migration files are up to date
[ ] The changes are tested
[ ] GraphQL schema and type definitions are up to date
[ ] Changes are mentioned in the changelog

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@8955e9c). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head fd1f472 differs from pull request most recent head e784819. Consider uploading reports for the commit e784819 to get more accurate results

@@           Coverage Diff           @@
##             main    #8265   +/-   ##
=======================================
  Coverage        ?   93.02%
=======================================
  Files           ?      489
  Lines           ?    36711
  Branches        ?     4106
=======================================
  Hits            ?    34149
  Misses          ?     1735
  Partials        ?      827

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 8955e9c...e784819. Read the comment docs.


API

Does expresscart have an API?

Its not properly documented. If you check the tests you can see the API's available.


[Feature][connector][kafka] Support read canal format message from kafka

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
Support read canal format message from kafka
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

please assign to me; thx。

It is suggest to add new implment to here
https://github.com/apache/incubator-seatunnel/tree/dev/seatunnel-formats/seatunnel-format-json/src/main/java/org/apache/seatunnel/format/json

ok

hi, do you need help?

@hailin0 Thanks, no need for now


Norm calculation failing

Unit tests for norm calculation are failing on my system since the last merge:
Running main() from /home/gflegar/Sources/ginkgo/public/clang-all/third_party/gtest/src/googletest/src/gtest_main.cc
[==========] Running 13 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 13 tests from Dense
[ RUN      ] Dense.SingleVectorCudaScaleIsEquivalentToRef
[       OK ] Dense.SingleVectorCudaScaleIsEquivalentToRef (399 ms)
[ RUN      ] Dense.MultipleVectorCudaScaleIsEquivalentToRef
[       OK ] Dense.MultipleVectorCudaScaleIsEquivalentToRef (165 ms)
[ RUN      ] Dense.MultipleVectorCudaScaleWithDifferentAlphaIsEquivalentToRef
[       OK ] Dense.MultipleVectorCudaScaleWithDifferentAlphaIsEquivalentToRef (165 ms)
[ RUN      ] Dense.SingleVectorCudaAddScaledIsEquivalentToRef
[       OK ] Dense.SingleVectorCudaAddScaledIsEquivalentToRef (8 ms)
[ RUN      ] Dense.MultipleVectorCudaAddScaledIsEquivalentToRef
[       OK ] Dense.MultipleVectorCudaAddScaledIsEquivalentToRef (165 ms)
[ RUN      ] Dense.MultipleVectorCudaAddScaledWithDifferentAlphaIsEquivalentToRef
[       OK ] Dense.MultipleVectorCudaAddScaledWithDifferentAlphaIsEquivalentToRef (164 ms)
[ RUN      ] Dense.SingleVectorCudaComputeDotIsEquivalentToRef
[       OK ] Dense.SingleVectorCudaComputeDotIsEquivalentToRef (7 ms)
[ RUN      ] Dense.MultipleVectorCudaComputeDotIsEquivalentToRef
[       OK ] Dense.MultipleVectorCudaComputeDotIsEquivalentToRef (119 ms)
[ RUN      ] Dense.CudaComputeNorm2IsEquivalentToRef
/home/gflegar/Sources/ginkgo/public/repo/cuda/test/matrix/dense_kernels.cpp:238: Failure
Relative error between dresult and expected is 1
	which is larger than 1e-14 (which is 1e-14)
dresult is:
	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
expected is:
	31.952294028324967	31.400715206705375	32.338397097522396	30.544220340899564	32.475808466485496	32.246221735946591	31.843521729376377	30.988619520089923	31.633529154325675	31.267590375693963	30.755741475929881	31.453243612568375	32.393257169749674	32.233859624276448	32.755649930407444	31.323731816026424	32.100962398290442	31.38714287220639	31.267140451711249	30.905785196977362
component-wise relative error is:
	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1

[  FAILED  ] Dense.CudaComputeNorm2IsEquivalentToRef (120 ms)
[ RUN      ] Dense.SimpleApplyIsEquivalentToRef
[       OK ] Dense.SimpleApplyIsEquivalentToRef (18 ms)
[ RUN      ] Dense.AdvancedApplyIsEquivalentToRef
[       OK ] Dense.AdvancedApplyIsEquivalentToRef (19 ms)
[ RUN      ] Dense.IsTransposable
[       OK ] Dense.IsTransposable (15 ms)
[ RUN      ] Dense.IsConjugateTransposable
[       OK ] Dense.IsConjugateTransposable (17 ms)
[----------] 13 tests from Dense (1382 ms total)

[----------] Global test environment tear-down
[==========] 13 tests from 1 test case ran. (1382 ms total)
[  PASSED  ] 12 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] Dense.CudaComputeNorm2IsEquivalentToRef

 1 FAILED TEST

(Some solver tests also fail, but I assume that is just this same problem manifesting itself there.)
System info (more or less the same setup we have on the CI in terms of software, just different hardware):

NVCC 9.2
clang 6.0.1 / gcc 8.2.1
GTX965 GPU
CMakeCache.txt (clang), CMakeCache.txt (gcc)

Can anyone confirm this?

I can confirm this. NVCC 9.1 , gcc 7.3. The tests which fail are:
Dense.CudaComputeNorm2IsEquivalentToRef
ResidualNormReduction.WaitsTillResidualGoal
only in CUDA though, the reference and omp pass.
And the CG and FCG fail for for me as well. But I think this is a problem with the setting of tolerance as the error seems to be of the order of 1e-14 for me.
It is quite weird that all the tests pass on the CI system.

Hm, so it seems that on the CI system, we are not build/ running for GPU's. Is this intentional ?

We build GPUs, but do not run the tests because more needs to be done (creating NVidia-enhanced docker containers, also with different compiler version).


Timed explicit returns

Allow explicit returns in timed blocks. Previously, metrics would not be sent if you explicitly returned from a method from inside a timed block. E.g.
$statsd = Statsd.new '::1', 9125
def some_method
  $statsd.time('test') do
    sleep 1
    return "Explicitly returned string"
  end
end
puts some_method

Thank you for the PR. I reimplemented this a little for simplicity.


[Fix #4143] Prevent Style/IdenticalConditionalBranches from registering offenses when a case statement has an empty when.

Fixes the issue seen in #4143 where empty cases are not accounted for in the Stype/IdenticalConditionalBanrches cop. The case below will no longer registered as an offense:
case foo
when 1
  3
when 2
else
  3
end

The same as this case:
case foo
when 1
  3
when 2
nil
else
  3
end

Before submitting the PR make sure the following are checked:

[X] Wrote good commit messages.
[X] Commit message starts with [Fix #issue-number] (if the related issue exists).
[X] Used the same coding conventions as the rest of the project.
[X] Feature branch is up-to-date with master (if not - rebase it).
[X] Squashed related commits together.
[X] Added tests.
[X] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[X] All tests are passing.
[X] The new code doesn't generate RuboCop offenses.
[X] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[X] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

👍


Auto-size graph

Hello again @nyurik!
Please, can you help me to discover why is kibana and vega-vis not adjusting the size of the visualization?
Here is what I am viewing:

As you can see, a square is showing and not resizing when I minimize the visualization.
Thank you very much!

@chuski92 take a look at the sizing and positioning section in the readme. Your graph has to have the right sizing model, and use width/height signals to calculate proper font sizes and positioning of the elements.

And how can I disable that frame? Can I hide it? It worked to auto-resize, but it is annoying to see that frame in that visualization.

@chuski92 what do you mean by frame?  You create the Vega graph, and make that graph dependent on the size of the graph's container. E.g., if the container gets smaller, you reduce the font size, and remove some details.


Fix scraper AG

Do we have some clever solution for parsing hyphenation in other parsers?

Closed in favour of https://github.com/openZH/covid_19/pull/743.


DiffGrad Optimizer

What do you think about the DiffGrad optimizer?
Do you think it is better than AdamW?
I heard that it can be a couple of percent more efficient, but I couldn't find it in popular forks.

What do you think about the DiffGrad optimizer? Do you think it is better than AdamW?
I heard that it can be a couple of percent more efficient, but I couldn't find it in popular forks.

while it works as a drop-in replacement, it does not seem to provide much benefit. Granted I only tried it with 100 epochs and 4 min audio.
Perhaps with some tweaking it may, but good luck with that.


Fetch Vsphere instanceUuid

This PR add fetching of the instanceUuid to About model.

Please link some issues showing why/where you need it.
It does not need to be issue directly on Forklift but could be from your project.

As part of ticket: https://issues.redhat.com/browse/ECOPROJECT-2376
We need to have unique identification of the Vcenter.
So far @tupyy solved it inside our code here: https://github.com/kubev2v/migration-planner/pull/81
We need it so we can distinguish where the generated OVA is connected to so we don't gather it twice for same Vcenter, so Vcenter UUID is unique identification for us.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 15.65%. Comparing base (840fa31) to head (8a08a19).
Report is 2 commits behind head on main.

Files with missing lines
Patch %
Lines

...controller/provider/container/vsphere/collector.go
0.00%
3 Missing :warning:

pkg/controller/provider/web/vsphere/provider.go
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1224      +/-   ##
==========================================
- Coverage   15.65%   15.65%   -0.01%
==========================================
  Files         112      112
  Lines       23075    23077       +2
==========================================
  Hits         3612     3612
- Misses      19178    19180       +2
  Partials      285      285

Flag
Coverage Δ

unittests
15.65% <0.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add Kevin Villanueva to Contributors list

Just going through the process, thank you!

Hi  @VillanuevaK, I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added social share  to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.


[Improvement] flagd json schema files should be namespaced under resources

Background
flagd provider utilizes schema files to validate flags when working in in-process mode. Currently, these json schema files are copied when building the binary to resources and kept in the root level [1]. And they are named flags.json & targeting.json.
Problem
In an application that uses flagd Java provider for feature flagging, there can be conflicting JSON files with similar names to the above schema files in the classpath. This especially concerns the name flags.json as many flagd examples use flags.json as a flag source file.
Improvement
Given our underlying library (seems to) support namespaced locations [2], we should improve our schema locations with an appropriate namespace to avoid classpath conflicts.
AC
Provider works & validates flags correctly with the namespaced schemas in the classpath.
[1] - https://github.com/open-feature/java-sdk-contrib/blob/dev.openfeature.contrib.providers.flagd-v0.8.3/providers/flagd/pom.xml#L236-L258
[2] - https://github.com/networknt/json-schema-validator/blob/master/doc/schema-retrieval.md#configuring-mappings

@Kavindu-Dodan I can take a stab at this.
Can we finalize on the new namespace locations to use?
I propose classpath:schemas/flagd/{flags|targeting}.json and classpath:/schemas/flagd/inprocess/{flags|targeting}.json

I can take a stab at this

Nice.
Regarding the schema, I think flagd/schemas is better. And then place the json schema files targeting.json & flags.json under that resource directory.
flagd/schemas/flags.json , flagd/schemas/targeting.json

Assigned the issue to you @mehtasankets . Let me know if you have further doubts

@Kavindu-Dodan for review: https://github.com/open-feature/java-sdk-contrib/pull/850

@mehtasankets thanks for the PR. Will include this with the next release :)


New design or CSS theme feature

Hi! I love this app and find it very good for keeping track of upcoming media I want to see/play in the future so thanks a lot for all your work!
I don't know if this is something you looking for help with but I took a swing at making the design of it a bit more modern by making some CSS styling, see below how it looks. Would you consider adding a feature to inject custom CSS by the user to be able to override the current look or even implement something similar as the default design? I am happy to help if I can in any way if that would be the case. I also attached the CSS I made if you find it interesting.

css.txt

Thank you,
I am currently working with a professional designer on new UI

Can I also ask for adding a favicon so adding a bookmark to the bookmark bar looks a bit nicer :)

Any updates on the new UI?


Runtime 9.1 and 9.2 is missing

Runtime 9.1 and 9.2 is missing from this page.
9.1 works from BC20.1 (ref. https://www.yammer.com/dynamicsnavdev/threads/1867199253872640)
9.2 works from BC20.4 (but not on SaaS currently, it seems - ref. https://www.yammer.com/dynamicsnavdev/threads/1876697947463680)

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

ID: 1bac24fa-c9eb-695a-bdd5-3dbe4109a0dc
Version Independent ID: a09fc47a-123f-a136-d4e5-e986dfc94522
Content: Choosing Runtime Version in AL - Business Central
Content Source: dev-itpro/developer/devenv-choosing-runtime.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Thanks for catching this. Will be fixed with the next refresh of the docs.


[SR SQL Planner Summer Camp] add show repositories analyze

What type of PR is this：

[ ] bug
[x] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #7951
Problem Summary(Required) ：

add show repositories analyze

[FE PR Coverage Check]
:heart_eyes: pass : 14 / 16 (87.50%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/ast/AstVisitor.java
0
1
00.00%
[397]

:large_blue_circle:
com/starrocks/sql/analyzer/ShowRepositoriesAnalyzer.java
10
11
90.91%
[11]

:large_blue_circle:
com/starrocks/sql/analyzer/Analyzer.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/analysis/ShowRepositoriesStmt.java
1
1
100.00%
[]


"nodes is forbidden" error and EKS issues

I work with a cluster that is overly locked down for security reasons and it seems that its having issues with the actions performed by this utility when adding said cluster.
nodes is forbidden: User<EMAIL_ADDRESS>cannot list resource "nodes" in API group "" at the cluster scope

Note<EMAIL_ADDRESS>is a dummy value I've replaced in this paste.

I'll note also that I ran into this while attempting to add a cluster which uses EKS. I have found the following about it, but I'm unable to try it out:
https://github.com/txn2/kubefwd/issues/62#issuecomment-496630133
If I ignore the error mentioned, add the cluster anyway and try to connect to it, I am met with
Pod "svc/iotconsole-backend" forbidden.

which is usually the message I get in the command line if my AWS token is expired or non-existent. This is however not the case, even if I freshly generate a new one right before trying.
Shouldn't it still work even if the app failed to execute its commands to seek out existing nodes? Wouldn't the two be unrelated?

@Laptopmini what command are you using to run kubefwd? Also, I am not familiar with that dialog box.

I am not familiar with any of the output you have provided. This issue may be referring to another project. Closing unless we can determine how this relates to kubefwd. Thanks


Update to windows-sys 0.52.

@lambda-fairy The Rust ecosystem is starting to migrate to windows-sys 0.52, which has an MSRV of 1.56. 1.56 is still a pretty conservative MSRV to update to at this time; for example, current Debian stable has Rust 1.63, however I wanted to raise this in case anyone has any concerns.

@sunfishcode SGTM, thanks!
In the past I have set MSRV informally, by looking at the MSRV of dependent packages, and raising to the community on each bump (like you've done here). Up to you whether you want to keep doing that or adopt a more explicit policy.

This is now released in errno 0.3.8.


Verify token based on x5c

Is it possible to verify a JWT based on the x5c?

Hi @AlexZeitler, this library is based on https://github.com/brianloveswords/node-jws which does not support it so far.


Improvement: Single source of version truth

Description
Note: This ticket is purely about implementation.
Currently the version numbers are determined via multiple ways depending on the config and the called method.
Depending if get_current_version, get_next_version, and more, different ways to determine this version are used:
based on tags, based on parsed commit messages, the version file (and maybe more?).
I understand the need for this in the current implementation, but it feels a bit error prone and I think it would make the code easier and cleaner if we could come up with a single way how versions are determined / parsed / found.
I would like to open a discussion about this...

If tags are always created, regardless of the version_source setting, then it would make sense to only use those to read the version.

@danth jup, tags would need to always be created. I think that is a fair requirement (in the future we could think of a plugin solution to enable different and more complex version sources)...
This breaks with a feature I introduced as well -> https://github.com/relekang/python-semantic-release/pull/341, but as stated in the PR, this was for the usecase of monorepos, something this package is currently not made for and also probably should not be used for. So I would be fine with removing this features again.
(the whole prerelease feature seems to be a lot more useful and for a bigger audience as well)

One more feedback on this one. The chamgelog seems to still rely on commit messages which would be against the single source of truth as well IMHO.
So the chamgelog should determine the log messages based on Tags as well.

@jacksbox I'm working my way through refactor & would love your input (+ feedback down the line) - I have #487 open for it

Just another voice here for using tags if possible (I see there were discussions about monorepos, but maybe another way to parse that makes sense).
I'd actually get rid of get_current_release_version_by_commits entirely - people use dependabot/renovate and it seems like that could always interfere when other semvers appear in commits, as well as changing commit message patterns throughout the history of a project etc. I also had trouble migrating an existing project using this approach, as there's no good way of reusing changelogs/tags to bump versions while still committing things.
There seems to be some refactoring going on and I haven't full read all the context so sorry if this is a repeat :) I help maintain python-gitlab and we use each other's libraries so I'd definitely like to have things work smoothly, will try to contribute at least some gitlab-related stuff if you decide to keep that in the core library.

@nejch I think this is already happening as a part of #487 👍

This is definitely happening in #487 - it will be tags only. @nejch the Gitlab implementation in PSR is definitely lagging behind Github and Gitea - would be great to have your input!

Implemented with the release of v8.


Upgrade 1.25.5->1.25.7: AutoMigrate returns the error "insufficient arguments"

GORM Playground Link

https://github.com/go-gorm/playground/pull/1
Description

I'm using the postgres backend and ran into this error. Updating gorm.io/driver/postgres from v1.5.4 to v1.5.7 seems to resolve the issue.

v1.5.7

gorm.io/driver/postgres v1.5.9
gorm.io/gorm v1.25.12
Here is my version, and it still has this error  pq: got 2 parameters but the statement requires 1


⚠ Bofrost.be has degraded performance

In cdf7d90, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1611 ms

Resolved: Bofrost.be performance has improved in 3ed02de.


customData from the Analytics.Provider is undefined in the useAnalytics.subscribe() functions

What is the location of your example repository?
No response
Which package or tool is having this issue?
Hydrogen
What version of that package or tool are you using?
2024.4.3
What version of Remix are you using?
2.1.0
Steps to Reproduce
Per the docs, you can pass custom data into the Analytics.Provider like:
<Analytics.Provider
  cart={data.cart}
  shop={data.shop}
  consent={data.consent}
  customData={{foo: 'bar'}}
>

Expected Behavior
That should populate the data.customData object in the useAnalytics subscribe events.
Actual Behavior
data.customData is undefined.

Bug confirmation: https://github.com/Shopify/hydrogen/pull/1789#issuecomment-2154903772

Thank you for creating an issue to track this.


[BUG] Incorrect result request in OMAS Subject-Area

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
If you run queries. Anything can be substituted for the category guide
https://<IP_ADDRESS>:9443/servers/xxx/open-metadata/access-services/subject-area/users/admin/categories/a8883fbd-0707-416f8/categories?sequencingOrder=ANY&startingFrom=0&exactValue=false&ignoreCase=true
https://<IP_ADDRESS>:9443/servers/xxx/open-metadata/access-services/subject-area/users/admin/categories/nonsense-not-meaning/terms?sequencingOrder=ANY&startingFrom=0&exactValue=false&ignoreCase=true
Response:
{"class":"SubjectAreaOMASAPIResponse","relatedHTTPCode":200,"result":[]}
Expected Behavior
And a 404 error should be returned, indicating that the category was not found or does not exist
Steps To Reproduce
No response
Environment
- Egeria: 3.0
- OS: CentOS 7
- Java: 11
- Additional connectors and integration: https://github.com/odpi/egeria-connector-xtdb

Any Further Information?
No response

I will include the change to the getEntityNeighbourhood to return entity not known when the supplied guid is not known.

Note this change will not include any change to the xtdb repository connector, which lives in another repository

The problem is in these places.
https://github.com/odpi/egeria/blob/c8f44fafbc6dd629f0d9077ef08739a662283da0/open-metadata-implementation/access-services/subject-area/subject-area-server/src/main/java/org/odpi/openmetadata/accessservices/subjectarea/handlers/SubjectAreaCategoryHandler.java#L517
https://github.com/odpi/egeria/blob/c8f44fafbc6dd629f0d9077ef08739a662283da0/open-metadata-implementation/access-services/subject-area/subject-area-server/src/main/java/org/odpi/openmetadata/accessservices/subjectarea/handlers/SubjectAreaCategoryHandler.java#L594
Here only 200 code is checked, but if suddenly another code, then the method will return SubjectAreaOMASAPIResponse empty
{"class":"SubjectAreaOMASAPIResponse","relatedHTTPCode":200,"result":[]}

the EntityNotFound should end up as an invalidParameterException for the OMAS. Currently I have started prototyping a fix but am getting propertyServerException - which is not correct. I think there need to be more server side logic to make sure the invalid parameter exception is flowed back on the rest call and is thrown from the client OMAS API

Is there any movement on the issue?


update: updated the get activelsat function to get lsat based on issuer

@tobi-bams I merged this into the refactor branch and I will include in next release going out today.
Please let's try to respect indentation and spaces based on what it's used in the project. If each developer working on it implements its own indentation and spaces rules the code becomes really hard to be read for new developer that might work in the project in the future


The cost function of MDN

Hi,
I do not get the idea of the cost function.
y was generated by Normal distribution but it is fed to tf.distributions.Normal again?
Is it correct?
Regards,

Hi @nhatuan84 , y is originally generated by a Normal distribution - but in real life you do not know the original distribution. It can be anything. Normal distribution is just simple and easy, and therefore we used it in this demo as the noise to y.
We use the Normal distribution in the cost function because we want the model to try and fit the input to a Normal distribution. We do that because, again, in real-life we don't know the real distribution of the data, and a Normal distribution is something we usually use when trying to generalize some unknown distribution.
So, to conclude - y is generated using a Normal distribution for the sake of the demo, but is modeled as a Normal distribution because this is what we'll try to do when we do not know the real data's distribution.
Hope this helped!


Avoid writeable check when in mode 'none' to run on readonly filesystems

On our CI, symfony sources are on a read-only filesystem and we certainly don't want php-vcr to update any fixtures. We switch to mode "none" based on an environment variable that is only present on CI. However, we would need this fix to avoid the writeable check (which makes no sense in "none" mode anyways).
/cc @thormeier

thanks for the feedback. i updated the code, constants on VCR make more sense indeed.
once this is released, we should also update the documentation to use the constants.

thanks @adri - can you tag another release with this?

Done already, forgot to post it here https://github.com/php-vcr/php-vcr/releases/tag/1.2.4

great, thanks!


Move away from using digga

While digga is a nice all-whistles-included library, its absolutely huge. It is designed for managing your own NixOS dotfiles ant not so much for creating importable flake modules. So when you are creating a flake that is designed to be imported, you are indirectly putting this huge library on everyone who will import your library.
The non-digga solution would be to use nix flake's native outputs section to create a nixosModules and packages parts. If i get some time i may try to PR in this change myself.

This change would remove a whole 16 inputs
• Added input 'nix-minecraft':
    'github:Infinidoge/nix-minecraft/67d394fba0b7d4e04f12389bcff99abd51fa2b00' (2022-07-12)
• Added input 'nix-minecraft/digga':
    'github:divnix/digga/e2bb8ea28c5bbc7bb46ac91df3ac846ce9a3964c' (2022-04-06)
• Added input 'nix-minecraft/digga/blank':
    'github:divnix/blank/5a5d2684073d9f563072ed07c871d577a6c614a8' (2021-07-06)
• Added input 'nix-minecraft/digga/deploy':
    'github:serokell/deploy-rs/9a02de4373e0ec272d08a417b269a28ac8b961b4' (2021-09-28)
• Added input 'nix-minecraft/digga/deploy/flake-compat':
    'github:edolstra/flake-compat/12c64ca55c1014cdc1b16ed5a804aa8576601ff2' (2021-08-02)
• Added input 'nix-minecraft/digga/deploy/nixpkgs':
    follows 'nix-minecraft/digga/latest'
• Added input 'nix-minecraft/digga/deploy/utils':
    'github:numtide/flake-utils/74f7e4319258e287b0f9cb95426c9853b282730b' (2021-11-28)
• Added input 'nix-minecraft/digga/devshell':
    'github:numtide/devshell/0e56ef21ba1a717169953122c7415fa6a8cd2618' (2021-11-22)
• Added input 'nix-minecraft/digga/flake-compat':
    'github:edolstra/flake-compat/b7547d3eed6f32d06102ead8991ec52ab0a4f1a7' (2022-01-03)
• Added input 'nix-minecraft/digga/flake-utils-plus':
    'github:gytis-ivaskevicius/flake-utils-plus/be1be083af014720c14f3b574f57b6173b4915d0' (2021-12-13)
• Added input 'nix-minecraft/digga/flake-utils-plus/flake-utils':
    'github:numtide/flake-utils/74f7e4319258e287b0f9cb95426c9853b282730b' (2021-11-28)
• Added input 'nix-minecraft/digga/home-manager':
    'github:nix-community/home-manager/4daff26495ca9ac67476cba8cf15c3e36d91ab18' (2021-11-26)
• Added input 'nix-minecraft/digga/home-manager/nixpkgs':
    follows 'nix-minecraft/digga/nixlib'
• Added input 'nix-minecraft/digga/latest':
    'github:nixos/nixpkgs/8a308775674e178495767df90c419425474582a1' (2021-11-29)
• Added input 'nix-minecraft/digga/nixlib':
    follows 'nix-minecraft/nixpkgs'
• Added input 'nix-minecraft/digga/nixpkgs':
    follows 'nix-minecraft/nixpkgs'
• Added input 'nix-minecraft/nixpkgs':
    follows 'nixpkgs'
• Added input 'nix-minecraft/packwiz':
    'github:packwiz/packwiz/0d8c1762a373f9da9b14cb4b8156082bbbe14de8' (2022-06-20)

Hmm, good point, I used digga since I was familiar with it.
I'll likely switch to instead using flake utils or flake utils plus, since I prefer their structure over raw flakes, and they don't have the same dependencies.

I've gone ahead and moved to flake utils plus locally, just going to test it out first before pushing to master.

Going to test in my server setup first, but feel free to look over this commit:
https://github.com/Infinidoge/nix-minecraft/commit/06051dbe42595971422387df6aab010f1317e698

I see no issue with it personally from a quick skim, other than the use of fup.lib.mkFlake. But it is a nice improvement overall from digga.

What would the issue with fup.lib.mkFlake be?

Its mostly due to the absurd abstraction its doing on an already simple system. Where a similar amount of code could be used to create the relevant outputs that mkFlake would generate (output.nixosModules and output.packages).
While mkFlake's seemingly major strength to newcomers is actually its greatest weakness, it completely redefines flakes to use its own handling of output definition. Much different from the standard and quite sane layout of output.<option>.<system_arch>.<name>.
Some examples of a standard flake.nix file include naersk and poetry2nix.
If you would like, i could probably set off some time to create a PR of this when i get time.

Hmm, fair enough, I suppose. I can rewrite it away from the mkFlake.

This is looking great. I put a comment on the commit.


Closing a ping

hello could you add to your script the ban of ping following the example of these rules iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -j DROP

No, thanks you


Don't create unnecessary paths on forEachAtom (MLDB-1846)

Small optimization to reduce allocations in a very heavily used codepath.

+1


Rename dir and add dist to gitignore

LGTM but it is important to check whether compiling is working or not


Support for kubernetes v1.27.1

Hello,
I tried installing the plugin on a kubernetes v1.27.1 cluster.
But it seems that it requires PodSecurityPolicies which have been deprecated in 1.21 and removed in 1.25.
I patched the chart to not create the PSP in a fork of this repository but the operator itself is looking for it and thus fails to start.
Is there plans to support more recent clusters ?

Hi Sir,
Thanks for your suggestions.
QNAP is scheduled support v1.27.1 into official release version.
Once official release we will announce by E-news, thanks

This is true for Kubernetes 1.25 and later, and so it's not possible to use this CSI provider for any currently supported version of Kubernetes.

Hi @gizmotronic
QNAP CSI driver support 1.21 to 1.27 Kubernetes version in v1.1.0, for your reference

Will this also duspport 1.28? Have been trying to get this to work, but without success so far.

I'm pleased to announce that the newest QNAP CSI plugin has been released!
It supports Kubernetes versions from 1.24 to 1.30.
For more information, please refer to the release notes:
https://github.com/qnap-dev/QNAP-CSI-PlugIn/releases/tag/v1.3.0


Update AfternoonClass

added Josh Winter haiku

Hey! Thanks! Can you make this change to Morning haiku please?


Running error

ModuleNotFoundError: No module named 'rospkg'

Hi,
This error just means that you do not have rospkg package installed. Make sure your ROS installation is correct. You can also install rospkg separately http://wiki.ros.org/rospkg

it shows errors like this
File "/DRL-robot-navigation/TD3/velodyne_td3.py", line 7, in
from velodyne_env import GazeboEnv
i installed all the ros packages properly but even though it shows the error like "ModuleNotFoundError: No module named 'rospkg'

If you are missing a package that means you do not have it installed or your sources are not set up properly. Make sure packages are installed and sourced properly. Rospkg is not part of this repo and should be part of ROS.

Hi sir , we done the training process but after that i don't know how to run the process and get the result

You can load the network parameters as explained here: https://github.com/reiniscimurs/DRL-robot-navigation/issues/17
What kind of process do you want to run and what results to you want to achieve?

That is normal behaviour.  You can start the Gazebo automatically by setting https://github.com/reiniscimurs/DRL-robot-navigation/blob/be811a4050dfcb5c800a0a0e4000be81d48cfbc5/catkin_ws/src/multi_robot_scenario/launch/empty_world.launch#L7 to true

hi sir, can you please tell me how to give movements to the robot

The movements to the robot are given by the neural network with calling the step() function in https://github.com/reiniscimurs/DRL-robot-navigation/blob/be811a4050dfcb5c800a0a0e4000be81d48cfbc5/TD3/velodyne_td3.py#L280
This executes 1 timestep in the simulation with the calculated action by the actor network.
In simulation, the robot movement is executed by a ROS publisher in https://github.com/reiniscimurs/DRL-robot-navigation/blob/be811a4050dfcb5c800a0a0e4000be81d48cfbc5/TD3/velodyne_env.py#L180

Please, provide specific and detailed information about your computer/software setup, installation steps, steps you took to run the program, outputs, steps you have taken to solve your issue.
It is impossible to say what is and isn't working without you providing any information.

Respected sir, I have followed all the instructions ( All the setup which is needed for the execution of the code) which was provided, and till now everything works good like the environment but the robot couldn't move and stays on the same place, i request you to like resolve my query thank you

Once again, I cannot help you if you do not provide any information about a specific problem. What exactly is happening? What have you tried? What is the terminal output? Take a look at how other people have asked questions in other issues (closed and open ones) and try to follow their example.

Closing due to inactivity


Override lineColor props is not working

H,
I appreciate your attempt to upgrade Timeline with "FlatList".
When I try to override lineColor in my view it is not working. Both lineColor and dotColor are using the default colors. Thanks.

Thanks for reporting this.
A new version (1.0.1) has now been released and addresses this.

Thank you @Johan-dutoit . You made my day!


Expand constraint on Faraday gem to allow for version 0.17.3

Faraday has recently released 1.0, and faraday_middleware is progressing that direction too. I'd like to upgrade these dependencies, and there does not seem to be any obstacle for this gem to allow its consumers to do so.
Regarding the decision on constraints, I chose 1 as the upper bound. Faraday_middleware's constraints do not yet permit version 1 of faraday. Version 0.17.3 is the highest version currently reachable by this constraint. That version introduces optional deprecation warnings useful to developers wishing to prepare the way to upgrade to 1.0, so it seemed a good point.

Thank you!


PUT operations in OAM layer should return 204

Current implementation returns response code 200 for all OAM PUT operations.
However,  these operations should return 204 based on OAS.

Issue fixed and merged by @MartinSunal


Server Crash with Hydrogen Generator and EnderIO Conduits

http://pastebin.com/pQwPN8Mw
Mekanism <IP_ADDRESS>
Not sure if this is EnderIOs fault, but it happened upon placing the Gas-Burning Generator next to EnderIO gas conduit line. Fixed it by removing the generator.

Yes, looks like lab EnderIO integration issue - they should have a public fix out soon


Progress Bar

Hi Codeido and thanks for your work!
There is a way to add a progress bar to the header view?

Hi @Channel76!
Yes, you can use the headerView property for this!