For foreign key generation with getForeignKey(), use getTable(), taking into account the $table property.

This pull request addresses an issue where the getForeignKey() method in Eloquent models does not take the $table property into account when generating the foreign key name. Laravel uses the model name (class name) to generate foreign keys by default, but this behavior doesn’t align with custom table names defined using the $table property. As a result, developers using custom table names might experience mismatches between the table name and the foreign key name.
This fix ensures that the $table property is respected when generating the foreign key, making it more consistent and predictable when working with custom table names.
Key Points:
Benefit to End Users: This change improves the flexibility and consistency of Eloquent's behavior when working with custom table names. It ensures that developers can rely on Eloquent to generate a foreign key that matches their custom table naming conventions.
Backward Compatibility: This change does not break any existing functionality. If $table is not set, Eloquent will continue to use the default behavior of generating foreign keys based on the model name.
Improves Developer Experience: With this fix, developers no longer have to manually specify foreign keys in every relationship if they use custom table names, making it easier to work with non-standard table names.

I am closing this pull request because it lacks sufficient explanation, tests, or both. It is difficult for us to merge pull requests without these things because the change may introduce breaking changes to the framework.
Feel free to re-submit your change with a thorough explanation of the feature and tests - integration tests are preferred over unit tests. Please include it's benefit to end users; the reasons it does not break any existing features; how it makes building web applications easier, etc.
Thanks!


Use docker image hash to determine if build should rerun

previously the docker build would re-run if the user had pullBaseImage set to true. now it always checks the remote repository for a new version of the base image, but only re-runs the build if the base image hash has changed

@nrktkt Can you please reformat your changes?


Training bugs based on your updated lbs.py

Hi,
After training with your updated lbs.py, I got the error as follows:
File "./scripts/train_smpl.py", line 359, in main_worker
loss, acc17 = train(opt, train_loader, m, criterion, optimizer, writer)
File "./scripts/train_smpl.py", line 91, in train
loss.backward()
File "/mnt/lustre/shaorui/anaconda3/envs/hybrik/lib/python3.6/site-packages/torch/tensor.py", line 118, in backward
torch.autograd.backward(self, gradient, retain_graph, create_graph)
File "/mnt/lustre/shaorui/anaconda3/envs/hybrik/lib/python3.6/site-packages/torch/autograd/init.py", line 93, in backward
allow_unreachable=True)  # allow_unreachable flag
RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.cuda.FloatTensor [1536]], which is output 0 of IndexPutBackward, is at version 2; expected version 1 instead. Hint: the backtrace further above shows the operation that failed to compute its gradient. The variable in question was changed in there or anywhere later. Good luck!
I have checked that this bug happens after lbs.py was updated with 'use batch opertaion'.
May I ask how to fix this?
Thanks.

Hi, I revised the logic of rotmat_to_quat in lbs.py as follows and everything goes right.
def rotmat_to_quat(rotmat):
"""Convert rotation matrix to quaternion coefficients.
Args:
rotmat: size is [B, 3, 3]
Returns:
Quaternion: size is [B, 4] <===> (w, x, y, z)
"""
quaternion = torch.zeros([rotmat.size(0), 4], device=rotmat.device)
trace = rotmat[:, 0, 0] + rotmat[:, 1, 1] + rotmat[:, 2, 2]
flag = 1 + trace > 0
s = torch.zeros_like(trace)
# pos
s[flag] = 2 * torch.sqrt(1 + trace[flag]) + 1e-16
diag = torch.stack([rotmat[:, 0, 0], rotmat[:, 1, 1], rotmat[:, 2, 2]])
max_val, max_ind = torch.max(diag, dim=0)
s[~flag] = 2 * torch.sqrt(1 - trace[~flag] + 2 * max_val[~flag]) + 1e-16

s_pos = s[flag]
quaternion[flag, 0] = s_pos / 4
quaternion[flag, 1] = (rotmat[flag, 2, 1] - rotmat[flag, 1, 2]) / s_pos
quaternion[flag, 2] = (rotmat[flag, 0, 2] - rotmat[flag, 2, 0]) / s_pos
quaternion[flag, 3] = (rotmat[flag, 1, 0] - rotmat[flag, 0, 1]) / s_pos

# neg
f0 = ~flag * (max_ind == 0)
s0 = s[f0]
quaternion[f0, 0] = (rotmat[f0, 2, 1] - rotmat[f0, 1, 2]) / s0
quaternion[f0, 1] = s0 / 4
quaternion[f0, 2] = (rotmat[f0, 0, 1] + rotmat[f0, 1, 0]) / s0
quaternion[f0, 3] = (rotmat[f0, 0, 2] + rotmat[f0, 2, 0]) / s0

f1 = ~flag * (max_ind == 1)
s1 = s[f1]
quaternion[f1, 0] = (rotmat[f1, 0, 2] - rotmat[f1, 2, 0]) / s1
quaternion[f1, 1] = (rotmat[f1, 0, 1] + rotmat[f1, 1, 0]) / s1
quaternion[f1, 2] = s1 / 4
quaternion[f1, 3] = (rotmat[f1, 1, 2] + rotmat[f1, 2, 1]) / s1

f2 = ~flag * (max_ind == 2)
s2 = s[f2]
quaternion[f2, 0] = (rotmat[f2, 1, 0] - rotmat[f2, 0, 1]) / s2
quaternion[f2, 1] = (rotmat[f2, 0, 2] + rotmat[f2, 2, 0]) / s2
quaternion[f2, 2] = (rotmat[f2, 1, 2] + rotmat[f2, 2, 1]) / s2
quaternion[f2, 3] = s2 / 4

return quaternion

Hi @rshaojimmy , thanks for your revision. Actually, I don't meet this problem when training with the current code. Can you please let me know which PyTorch version you use?

Hi, I follow your conda virtual env setting with pytorch==1.2.0 torchvision==0.4.0.

Thanks, I see the problem here. When we update the implementation of rotmat_to_quat, we use PyTorch=1.6.0 to test. The reported error occurs in 1.2.0 but not 1.6.0. This is why we miss this bug. Thanks for your effort~ We will fix it later.

So in this way, do we need to update the version of Pytorch to 1.6.0?

It is not necessary. I think everything goes right after you revised the logic of rotmat_to_quat in lbs.py

Thanks. May I have your training curve for further comparison?


Image not keeping color after jpeg() format applied

Question about an existing feature
What are you trying to achieve?
We have an application that applies transformations to JPG and PNG images. After upgrading the system to Node 14 I updated the following libraries as well:

Sharp 0.22.1 -> 0.31.2
color 3.1.0 -> 4.2.3
imagemin 6.1.0 -> 7.0.1
imagemin-jpegtran 6.0.0 -> 7.0.0
imagemin-mozjpeg 8.0.0 -> 9.0.0
imagemin-optipng 6.0.0 -> 7.0.0

My current OS is macOS Monterey 12.3.1.
running Node version 12.3.1 for old sharp, and version 14.15.0 for new sharp.
I noticed that 3 of the tests in our unit tests started to fail, the test looks like this:
    const pointColor = Color('#ff00ff').object();

    const pointImage = await imageGenerator.imageBuffer(1, 1, pointColor);

    const image = await imageGenerator.extendedFromPosition(pointImage, 5, 5);

    const centerPixel = await pixelParser.getPixel(image, 'center');

    assert.deepEqual(centerPixel, pointColor, 'Color channels');

imageGenerator.imageBuffer simply creates a Sharp transform object using the passed color ({r: 255, g: 0, b: 255}) with 4 channels and the provided width and height (first two arguments). Then the first jpeg() formatting is applied sharpTransformation.jpeg({ quality: 100 })
  const transform = sharp(
    {
      create: {
        width,
        height,
        channels: 4,
        background: rgbaColor,
      },
    },
  );

  transform.jpeg({ quality: 100 });

  return transform.toBuffer();

At this stage the images are literally the same, but then we run into the first JPG formatting, and they now differ a bit.
Before formatting
image--SharpVersion0.31.2--original

image--SharpVersion0.22.1--original

After formatting
image--SharpVersion0.31.2--firstJpegFormatting

image--SharpVersion0.22.1--firstJpegFormatting

PD. sorry if the images are this small at this point of the script.
After formatting the newest version returns a total of 270 bytes for the image, while the old one stays at 268 bytes, with jpeg formatting of quality: 100.
Then we extend the image by retrieving extension options, for this specific case the extension options are as follows:
const extOpts = {
  top: 2,
  bottom: 2,
  left: 2,
  right: 2,
  background: { r: 0, g: 0, b: 0, alpha: 0 }
};
const transform = sharp(colorImageBuffer).extend(extOpts);
transform.jpeg({ quality: 100 });

Once extended both images do look and weight almost the same (296 and 297 bytes respectively), with the center pixel a more gray colored version of the original pink.
After extension
image--SharpVersion0.31.2--afterExtension

image--SharpVersion0.22.1--afterExtension

Then we apply the second jpeg formatting and in the old version ended up with a bright pink colored center pixel, which would make the test successful. But with the new version the center pixel is not even close to the original color (though it retains some traces of pink).
After second formatting
image--SharpVersion0.31.2--secondJpegFormatting

image--SharpVersion0.22.1--secondJpegFormatting

Images here are 387 and 412 bytes respectively, which would make in theory the old image bigger (retains more quality?) but if I mess with the settings for quality on the old version I'm able to match the color of the newer image with anything below 90%.
What could be possibly going on? While this is only affecting our tests, I fear that the library will end up doing unexpected manipulations on images, and from 95 tests only 3 are failing, one of them being described in this thread.
Failed tests output
  92 passing (4s)
  3 failing

  1) ImageProcessor: pixelParser
       should return center pixel from image buffer:

      Color channels
      + expected - actual

       {
      -  "b": 125
      -  "g": 89
      -  "r": 125
      +  "b": 255
      +  "g": 0
      +  "r": 255
       }

  2) ImageProcessor: WebP (THIS ONE IS DOING A RESIZE AND THEN APPLYING WEBP ENCODING TO THE SHARP OBJECT)
       should not resize image if no dpr, width and height provided (but does provide a byte reduction) :

      Image height
      + expected - actual

      -2986
      +2990

  3) ImageProcessor: resizer (THIS ONE IS DOING A SIMILAR PROCEDURE AS THE FIRST TEST, WHERE IT GENERATES A COLOR IMAGE TO PERFORM OPERATIONS ON)
       options: trim, trim_color
         should trim image by trim_color:

      Perceptually uniform color distance
      + expected - actual

      -55.26562668905151
      +2.5

Please let me know if more info will be needed, I'm open to discuss on this and I really do need help to understand the reason for this behavior, without having to trail the manually go through the whole library logging the outputs to understand how is data being manipulated and where does it gets messed up.
Thanks for the help!
When you searched for similar issues, what did you find that might be related?
Didn't really found anything similar, nor any thread mentioning such errors from upgrades.
Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this question
Already provided code samples in the Issue, the code is private so I can't share it entirely.
Please provide sample image(s) that help explain this question
Already provided images.

There have been a lot of changes in the 4 year period since sharp v0.22.1. Perhaps you could try rolling forward a few versions at a time (similar to git bisect) to see if you can work out when the change first occurred.

Understood, yeah at the end of the day I believe I will have to go bug hunting through both repos to see how is the data behaving.
I will keep updating this with my findings. Thanks!

Hi again, as an update, I found out that the error started happening since version 0.26.0. Every other previous version would pass the test, but from this one onwards the errors posted here started happening.
I'm trying to figure out which of the changes could have impacted the results.

https://sharp.pixelplumbing.com/changelog#v0260---25th-august-2020

JPEG output quality >= 90 no longer automatically sets chromaSubsampling to 4:4:4.

Yes! After changing that property the output was correct and the failing tests passed.
Now I moved to the latest version and only tests is failing.

ImageProcessor: WebP
should not resize image if no dpr, width and height provided (but does provide a byte reduction) :
Image height

expected - actual

-2986
+2990

The test looks like this:
      const imagePath = '/test-image.jpeg';
      const expectedByteLength = 2990;

      const inputImage = getImageByPath(imagePath);

      const options = {};
      const outputImage = await webpProcessor(inputImage, options);

      assert.equal(outputImage.byteLength, expectedByteLength,
        'Image height');

In this test we aren't passing any options to the transformer object (webpProcessor(imagePath)), so it's just running something like this:
    sharpTransform.webp({
      quality: parseInt(compression || DEFAULT_COMPRESSION, 10),
      reductionEffort: WEBP_EFFORT,
    });

    const transformBuffer = await sharpTransform.toBuffer({ resolveWithObject: false });

Changing the WEBP_EFFORT won't change the returned bytes, but considering it's just a 4 bytes difference I think I can just update the test.
I'll identify exactly in which version from 0.26.0 to 0.31.2 this started happening and post it here as well.
But I can consider this solved! Thanks a lot!


[BUG] Fixes the index name dependencies in WindowSummarizer

Reference Issues/PRs

Fixes #2504
What does this implement/fix? Explain your changes.

Removed any dependency on level names. Only requires the agreed convention for pd-multiindex and hierarchical that the time dimension is the last level.
What should a reviewer concentrate their feedback on?

Validate the quality of the hierarchical case unit tests
PR checklist

For all contributions

[x] I've added unit tests and made sure they pass locally.

🎵 There's something happening here. What it is ain't exactly clear 🎵
Looks like a parallel processing error:
https://github.com/alan-turing-institute/sktime/runs/6207028528?check_suite_focus=true#step:7:40198

I manually re-run the failed jobs to see if I'm lucky this time.


How to skip unknown grammar, or listen the grammar only i Concerned

Hi:
I want use Lark to process text  but not realy to process a complete language.
can it work like Regular-expression only match the info i specified and skip which not specify
For example :
how to skip balabala info without lark.exceptions.UnexpectedCharacters
module  vau (clk,rstn,data_in,data_out);
input          clk      ;
input          rstn     ;
input   [7:0]  data_in  ;
output  [7:0]  data_out ;

balabala .....
here i dont not care (grammer cant recognize)
balabala .....

endmodule

i just only want match the struct or info which grammar already appointed in grammar.lark
module  vau (clk,rstn,data_in,data_out);
...
endmodule

and
input    [n:0]  data   ;

Thanks!

You could just use /.*/ to mark any text you don't care about, and run Lark with lexer='dynamic_complete'
It should work, but it might be a tad slow.

lexer='dynamic' is worked , but some times /.*/  conflict to other grammar.
My be my question is that :
I want match one grammar in one time,  not the complete grammar .
for example ,i want listen grammar
?input_declaration :  "input"  range?  port ";"
to find out  3 parser-tree matched
input          clk      ;
input          rstn     ;
input    [n:0]  data   ;

and listen grammar module_declaration : "module" module_idetifier list_of_port? ";" /.*/ "endmodule"
to find out  1 parser-tree matched
module  vau (clk,rstn,data_in,data_out);
...
endmodule

Ignore the information that is not needed
dose Lark can do this ?
Thanks！

I'm not sure I understand..


Fixed nesting of tests

Some test cases were required before corresponding index.js and therefore ran
outside their container. For example, constructor were before beginning of
Umzug in test results. See lines 389 and 471.

@sdepold Cosmetic change but I don't like merging anything without someone's :+1:.

@sdepold Cosmetic change but I don't like merging anything without someone's .

thanks :)

@jukkah Isn't the problem that we need to change the test structures in the test itself? https://github.com/sequelize/umzug/blob/112c7258a8bbabf9863e06467bd7fad8499342bc/test/index/constructor.test.js#L7. The referenced log line is just not nested under Umzug because the respective file doesn't specify it.

Isn't the problem that we need to change the test structures in the test itself?

Yep, it is.

The referenced log line is just not nested under Umzug because the respective file doesn't specify it.

We can't use describe('Umzug', ...) as a wrapper in every file since it produces multiple Umzugs instead of combining them all together under a single Umzug. (Tested some months ago.) In addition, I decided to not wrap all files with module.exports = function () { ... } as it makes impossible to run a single test file.
The solution is to describe one Umzug and then require all files within it. To work correctly, index.js needs to be required first before other files in the same directory.
Expected (index.js is required first and rest in alphabetical order):
Umzug         index.js
- constructor constructor.js
- down        down.js
- up          up.js

Actual (all files are required in alphabetical order):
- constructor constructor.js
- down        down.js
Umzug         index.js
- up          up.js```

Oh now I got the point of this change. I thought it was about JSCS and JSHint. Sure. Sure. Sure. You can merge as it is (or do whatever changes you want :D)


Add demo application for using lightweight atlas components

Add demo application for using lightweight atlas components

Paper: Human BioMolecular Atlas Program (HuBMAP): 3D Human Reference Atlas Construction and Usage
Paper: https://doi.org/10.1101/2<IP_ADDRESS>7041
Ensuring Atlas Sustainability

The HRA should use processes that encourage collaboration and guide future development to ensure long-term sustainability. This includes leveraging architectures with modular, lightweight components that can be easily shared (US#6) with metrics of success provided via an HRA dashboard to funders and the public in order to gain feedback and support (US#7).

Paper User Story Details

Feature: US#6. Develop lightweight atlas components
User Role: Programmers that support Researchers and Clinicians
User Activities: Implement usable and useful HRA components (interfaces and APIs) into other portals in the growing ecosystem of human atlases.
Added Value: Facilitate collaboration and data/code reuse between the HRA and other portals in support of FAIR data principles.

User Stories

As a programmer for a researcher/clinician, I want to explore HRA demonstration applications, so that I can see if this app would be useful to my team's research.
As a programmer for a researcher/clinician, I need quick access to the HTML of HRA components, so that I can embed visualizations on my team's website.

Design Notes

Katy is out of the office currently, so we still need her to approve this specification.

Please note that the text content and the image on the first page may change if she has suggestions. Thank you!

Figma Design Resources

Design File: Components & Styles
Design File: Start: Demo App 3
Design File: Results: Demo App 3
Prototype Presentation: Start: Demo App 3
Prototype Presentation: Results: Demo App 3

Approved Specification
Iterations were made today to get this specification approved:

The entry point was modified.

Mat-select: Use kidney as the default.
Add a button to generate the results

Text content on the results page has been modified. Please inspect all titles, title font sizes, and descriptions for the new text content.

Thanks so much!
Resources

Figma: App entry point
Figma: Component Results

Thanks so much!


Reorganise and refactor JS

The javascript admin-wide is somewhat untidy and isn't conducive to maintainability or intelligibility. wagtailadmin/js/core.js has for starters become a catch-all with a big ondomready() in which any number of arbitrary, unassociated scripts are run. Some scripts in the js root are specific only to the page editor, some contain comparatively neatly encapsulated functionality, some are a bit sprawling.
Within each of the apps, scripts have a semi-predicatable naming scheme, but no documentation of their dependencies or how they connect to or extend from other parts of the js environment.
Then there are the files like wagtailadmin/edit_handlers/inline_panel.js where we're serving js with django context vars, which is totally separate to the other js files,
There's also the files like wagtailadmin/pages/_editor_js.html which also feel a bit isolated and undocumented from a dependency perspective, despite their obvious significance.
My hope is that we can address all these issues by taking on a system that either more closely ties javascript to the elements and files to which it relates, splits up discrete js behaviours into individual files, and/or adds a modular, dependency based system like browserify.

You probably want to take a look over using Form Assets as a way to get CSS and JS that is coupled to forms/widgets/custom stuff into a template:
https://docs.djangoproject.com/en/1.8/topics/forms/media/ https://docs.djangoproject.com/en/1.8/topics/forms/media/
That may help with self-documenting and managing at least some of the CSS/JS by coupling it to the Django code rather than at the template level.

On 2 Apr 2015, at 09:33, Dave Cranwell<EMAIL_ADDRESS>wrote:
The javascript in admin-wide is somewhat untidy and isn't conducive to maintainability or intelligibility. wagtailadmin/js/core.js has for starters become a catch-all with a big ondomready() in which any number of arbitrary, unassociated scripts are run. Some scripts in the js root are specific only to the page editor, some contain comparatively neatly encapsulated functionality, some are a bit sprawling.
Within each of the apps, scripts have a semi-predicatable naming scheme, but no documentation of their dependencies or how they connect to or extend from other parts of the js environment.
Then there are the files like wagtailadmin/edit_handlers/inline_panel.js where we're serving js with django context vars, which is totally separate to the other js files,
There's also the files like wagtailadmin/pages/_editor_js.html which also feel a bit isolated and undocumented from a dependency perspective, despite their obvious significance.
My hope is that we can address all these issues by taking on a system that either more closely ties javascript to the elements and files to which it relates, and/or using a modular, dependency based system like browserify.
—
Reply to this email directly or view it on GitHub https://github.com/torchbox/wagtail/issues/1143.

I was thinking more like Reactjs et al, but yes I'll consider anything

Very exciting, Dave!
React makes a lot of sense – plenty of heavy hitters building good things with it.
Are you thinking we migrate the JS to a series of discrete React apps that are loaded as part of particular pages? We could use the Form Assets to ensure the correct entry point gets bundled for each view.
Springload have worked with the React + browserify workflow, but I hear that webpack is good at extracting/optimising common dependencies across multiple entrypoints, which might be very useful in the scenario above. Will need to look into it.
The great news is that there's not very much Javascript code. In fact, there's more SASS:
> cloc --exclude-dir=vendor .

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                         300           7368           3947          22884
SASS                            29            863            180           6022
HTML                           192            566             15           4838
Javascript                      50            645            342           4013
JSON                             3             16              0           3302
CSS                              2            100            187            251
Bourne Shell                     1             12              4             17
XML                              1              0              0             13
-------------------------------------------------------------------------------
SUM:                           578           9570           4675          41340
-------------------------------------------------------------------------------

One thing that will help (especially if we need Flux) is having a consistent API for the client-side to work against. This might be as simple as having each form throw back JSON if we set an Accept: application/json header, or providing API methods via django-rest-framework or similar.
Questions & conversation starters

Does this fit in with what you've been imagining?
How do we handle common deps across multiple React apps?
Do we need to implement some node.js pipeline tools (gulp/grunt) across the board, or do we drive all the builds from django, with something like django-webpack?
Do we need an API for the client-side? Is it easy for forms to give us back JSON?
Should we worry about runtime Dependency Injection or can we pre-compile everything?
ES6?

Cool ! ReactJS + Webpack is definitely the way to go.
Also forget about Grunt, Gulp is so much better.

Honestly I haven't put much more thought into the practicalities than what you see in this ticket. ReactJS and browserify are two tools I particularly want to learn as I know almost nothing about either, but it also means I can't objectively evaluate whether they're even suitable for Wagtail - they might not be (although your enthusiasm suggests otherwise!).
From Torchbox's perspective time is quite a significant consideration. We've little experience of many of the issues/questions you're raising and we'd need to start using some of these things from scratch before we're capable of making Wagtail infrastructure decisions that would stand the test of time. Finding the time to learn some of these technologies, e.g ES6 and React could prove a problem.
I'll discuss resourcing at our end and see what time we can allocate to this. Our approach thus far has been a "path of least resistance" one. This may mean that rather than applying React and Webpack in one fell swoop, we instead focus on incrementally upgrading our (possibly poor) code in stages. Firstly  wrapping current code with modular loading systems for use with Browserify or Webpack, then gradually upgrade modules over time, then adding React, then perhaps shifting our entire syntax to ES6 module by module.

I believe what @davecranwell is after here is a way to keep our existing Javascript code better organised, not to re-architect it completely around a new framework. My knowledge of React is entirely second-hand, but my impression is that adopting it would be more the latter than the former.
If there are specific components of React that can help towards the goal of organising our code better, then we should certainly consider them. However, I'd be reluctant to make any changes that involve adopting new build tools without very compelling reasons for doing so - and anything that adds node/npm as an end-user requirement would almost certainly be a showstopper.

Organisation is a priority, but consistency is also important to me. My understanding of React (and here my knowledge is similarly second-hand) is that it could bring a more consistent way to architect both our Modals and our Settings Sidebar for example, to pick two considerably different UI elements at random.
React does however feel like too much of a leap at the moment given how little experience we have of it.
Organisationally however I'd like us to consider front end tooling like the various Node-based offerings. We're already thinking about how to generate static CSS from SASS, and similar tools might be used for JS. We previously removed Coffeescript compilation because it felt wrong - and I stand by that decision - but i'm starting to think Coffeescript was the right idea, executed in the wrong place. (I'm aware ES6 and Coffeescript are incomparable, this is merely an example of where we could have used FE tools previously)
It sounds like @gasman is rightly concerned about developers having to jump through hoops to develop Wagtail, however I'd say anyone qualified to be editing Wagtail's CSS or JS will be a self-selecting bunch probably already familiar with tools like Grunt or Gulp, or at least eager to experience them.

anything that adds node/npm as an end-user requirement would almost certainly be a showstopper.
That would not be required by end-users (they would use the compiled bundles from the distribution). The gulp pipeline would only be required by Wagtail contributors.

@dperetti what @gasman and I obliquely reference is an internal quandary we've had about how to deal with the different environmental requirement of wagtail core development, and wagtail implementation. At present development and implementation are identical.

The great thing about React is that you can start slowly, with small components there and there, which can be integrated into the existing code base without having to refactor the whole thing.

You will absolutely love it !

+1 for the node-based tooling. The most annoying dependencies to deal with are libsass and phantomjs which about half of all node projects require. They require compiling from source which can add some time to the initial vagrant up or docker image build. Once they're done, they're done. Most CI pipelines will cache them too.
End users of the product would only have to load the node tooling if they were developing JS or CSS on the admin or contrib modules, but not in regular out-of-the-box use. We could make sure the assets are compiled and included in the package in a pre-publish hook.
The main thing we need is a module loader for Javascript, to allow us to separate out concerns and easily reason about the code. That also gives us a good starting point for dropping in other dependencies (react, an es6 compiler, lodash etc) if we need them.
I agree with dperetti that React is really nice – especially when dealing with complex interfaces. The approach scales well, and can be started on discrete components. But I don't think we need to jump in right away.
There's a few more immediate things that would be nice to clean up, such as moving {% include %} statements out of the JS code. I think we also need to address initialisation. Right now there's server-side for-loops printing Javascript code, which is a bit of an anti-pattern. Ideally any initial state that needs passing into components should be handled through serialising some JSON.
// Commonly this sort of thing is done in the JS...

$(function() {
    {% for form in formset.forms %}
        panel.initChildControls('{{ formset.prefix }}-{{ forloop.counter0 }}');
    {% endfor %}
});

We should move it to...
<!-- template.html -->
<script>
var formData = JSON.parse('{{formset.forms | jsonify }}');
formData.forEach(function(item, index) {
    panel.initChildControls(item, index);
});
</script>

I'd love to help sort out those things before we worry about adding more frameworks :)
Tasks

[ ] investigate implication of node tooling on standard django project workflow
[ ] move any django template logic out of javascript code
[ ] Implement browserify

Yeah that would be really appreciated if you could help rationalise that JS.
The inline JS we run for our edit handlers has always felt a bit unusually to me somehow. Not just the python vars, but the way it's just a function run manually rather than anything more jquery-esque. The form prefix for example, couldn't that be defined in a data attribute on the initialising element rather than passed in as a function parameter? I may be way off the mark here, it's just been a minor bugbear.

There were solid design reasons for the edit handler JS being the way it is. I'm not saying it's necessarily the best design, but changing it may be more than a simple matter of code cleanup...
At the time I designed the edit handler API, I had no preconceptions of what kinds of Javascript behaviour might be required. As such, I defined a panel to be "a fragment of HTML and an arbitrary Javascript function to initialise it", rather than "a fragment of HTML following certain JQuery-ish conventions to specify its behaviour".
The 'server-side code generating Javascript code' anti-pattern probably can be eliminated now. That was necessary because different kinds of panel could have differing Javascript initialisers, in ways that cannot be defined statically; for example, a 'carousel item' InlinePanel will need different Javascript initialisation code to a 'related link' InlinePanel, but there's no point at which a human writes specific Javascript code for those two things. I also left open the possibility that different instances of the same panel might have different JS code - think of something like StreamField where one instance might have an entirely different combination of edit widgets from the next - so the original code would have looked something like
{% for child in self.children %}
    panel.initChildControls("{{ child.form.prefix }}");
    {{ child.render_js_init }};
{% endfor %}

In practice A) this turned out to be a generalisation too far - when I re-did this for the StreamField blocks API it considerably simplified things to have all instances of a block type running the same JS code - and B) @timheap refactored this so that the per-child initialisation happens inline within the child's HTML, so the real dynamically-generated code is no longer present here.
Outside of edit handlers, there are a couple of places in the admin where this pattern was copied unnecessarily - group permissions and search term editor's picks, I think - and those could certainly be cleaned up.

Thanks for the explanation @gasman! I've made some small cosmetic changes to those scripts in #1174 (so the linter is happier), but after reading through the code base some more, I think we'd need to make some bigger changes to the modal workflow to eliminate the Django context vars from JS entirely, per Dave's original comment above.
It might be nice if, rather than registering the HTML and JS directly from the backend, we send a resource identifier  from the JS and the backend returns any step URLs and config vars over JSON. The front-end could then take care of how that component is loaded and implemented, and the endpoints would become more like a core API used to validate and expose data.
The current system does conveniently allow devs to share HTML markup between front-end and back-end via Ajax, but it's tricky to share the dynamic behaviours without implementing the UI logic twice, in Django templates and again in JavaScript (sprinkled with template vars).
Any eventual move towards react/angular/ember on the client would require a bunch of REST endpoints for these workflows (and for the UI language translations).. Not a small job :) But the modals do sound like a fairly good place to start - since they're well contained and discrete workflows.

Has anyone reviewed or worked with Methril (github link)?
I haven't worked with it yet, however based on this post: Mithril vs. Angular and React, it appears to unite the strengths of Angular and React with a simplified API.
React would still be a great choice otherwise! :-)

Would be nice if wagtail will use or offer some of django.js functionality. It offers nice front-end possibilities.

I've worked with Mithril. It's very fast, amazing for such a tiny library. I'd be concerned about support and community if we adopted it around here - do you know of any large-scale production apps written in it?

Hi Josh,
I don't know of any large-scale production apps written in Mithril so I've
asked about that here: https://gitter.im/lhorie/mithril.js
The concerns regarding support and community are well understood, however,
there are many support channels available to developers:
https://lhorie.github.io/mithril/community.html, which may help there.
On Sun, May 3, 2015 at 6:11 AM, Josh Barr<EMAIL_ADDRESS>wrote:

I've worked with Mithril. It's very fast, amazing for such a tiny library.
I'd be concerned about support and community if we adopted it around here -
do you know of any large-scale production apps written in it?
—
Reply to this email directly or view it on GitHub
https://github.com/torchbox/wagtail/issues/1143#issuecomment-98478878.

@JoshBarr My inquiry about large-scale apps in the mithril.js gitter.im chat room received a response with a Community Projects link. Still no clear use on a large-scale.
Interestingly an opinionated model layer based on Flux was mentioned in the chat thread, named Superflux. I find it evidence of community interest in the project.
Lastly, one of many features I like about Wagtail is its performance. Seeing this Todo app sample benchmark shows the speed you mention that Mithrill has is quite noteworthy. Since Wagtail is very close to being a true multi-device friendly CMS the JS performance over a device data connection might be worth considering.
I'm confident that with whatever choice is made Wagtail will be nothing but great :-)

Found a fairly good sized project using Mithril at http://demo.flarum.org/#/ with details here http://tobyzerner.com/mithril/. The community activity I've seen in the last month and MSX https://github.com/insin/msx tips me further in support of Mithril over React.

It's been a while! I'll review this and figure out how relevant this is with recent developments.

I'm closing this issue, considering developments have happened that go in the direction discussed here, making me feel like this discussion was succesful:

Webpack is part of the toolchain, even though I'm not sure how consistently it is used
React is a favoured approach to building components inside of the admin, even though this is still ongoing.

The other consideration is that this issue in its current state feels very broad and open-ended ("refactor and reorganise"). That said, I am very open to new issues (better yet, PRs) being opened for specific parts of this, for example:

Transition JS entry points to Webpack (not sure whether that should be done one by one or not)
Transition specific UI components to React (not just porting the code, but also considering best practices from UI dev in React – unit tests, 100% test coverage, 0 linting warnings, split into reusable components)
Document our "new way" of building the Wagtail admin's front-end: Webpack, React, etc.


Using batch variable

Hi there, amazing script. But I'm having some troubles. I'm not sure if it me, your script or something Adobe have done.
I'm using batch to process over 4000 images, each have 8 layers. I need to export said layers to images, hence why I'm using your script, but once it's setup I change the batch variable in you script to true and run my batch.
But it's just overwriting my images, so I only get the last layer from each image. Where am I going wrong?

Hi!
I have the same problem, the filename of the output should also include the original filename, not just the layer names.
F.e.
image1.psd with 3 layers (red/green/blue) should result in
image1_red.psd
image1_green.psd
image1_blue.psd
With that option it should be able to be placed inside an automation. Otherwise the next export of image2.psd with the same layers overwrite the former export.
Or is this feature already there and I missed it?

Oh - I just found the option {dn}!
Great job, thanks a lot!

Hi, you have made a great script, thank you for that.
But to use batch mode, I need to process all my images according to the settings I made. Now I have to click on the "Run" option for each image, is there a way to do the process automatically in batch mode without clicking?


fatal: unsafe repository ('/github/workspace' is owned by someone else)

I think it is related to this: https://github.blog/2022-04-12-git-security-vulnerability-announced/
Generated HTML documents output folder: .
+ echo 'Generated HTML documents output folder: .'
+ ConfigureGitUser
+ git config user.name 'github-actions[bot]'
fatal: not in a git directory
+ git config user.email<EMAIL_ADDRESS>fatal: not in a git directory
+ GetCurrentBranch
+ git rev-parse --abbrev-ref HEAD
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace
+ echo
+ CURRENTBRANCH=
+ '['  '!=' gh-pages ]
+ MigrateChanges . gh-pages ./
+ SOURCEDIR=.
+ DESTINATIONBRANCH=gh-pages
+ DESTINATIONDIR=./
+ git add --force .
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace
+ git stash save .
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace
+ git remote update
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace
+ git checkout gh-pages
fatal: unsafe repository ('/github/workspace' is owned by someone else)
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace
+ exit 1

Thanks for reporting. The last time I used doxygenize was couple of days ago which was working fine, but it seems this issue is quite new.
I am now monitoring the checkout action to see how they are going to fix it there. Besides that, it is better to update the alpine version to 3.15.4 that due to following commit has fixed the issue as well:
https://git.alpinelinux.org/aports/commit/?h=3.15-stable&id=b8465a8cc6281159e33226ef018d5dfaf0e62f4e
I need a couple of days to re-analyze the security of the action to the certain extend of my knowledge and also pick-up issue #8  as well before releasing v1.7.


set kubernetes.io/batch-cpu as milli-core

Ⅰ. Describe what this PR does

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in make test

/lgtm

/approve


Update talons and victors

This pull request is in response to confirmation regarding the specific ports of the TalonSRXs and VictorSPXs.


Code Of Conduct goes no where

Hey y'all, just clicking around and the code of conduct 1.4 link goes no where.

You mean the link here?
https://github.com/lyft/react-javascript-to-typescript-transform/blob/master/CODE_OF_CONDUCT.md

Which links here: http://contributor-covenant.org/version/1/4/code_of_conduct.md

Sorry ,this is in the wrong repo!


[BUG] Authentication JSON File Clears After Bad Pull Frequently

Description
Whenever I reauthenticate my Simplisafe using the instructions provided for Homebridge, the login works for 1-2 weeks before it crashes my Homebridge due to the dreaded "Unexpected End of JSON input" error for the authentication file. After deleting the file a couple times and reauthenticating, I investigated the JSON file itself and found that the file was completely empty, making me think that when the service attempted to reach Simplisafe to update a token, it received a null response and put that in the authentication file.
Expected behavior
The authentication for Simplisafe remains for an extended period of time.
Steps to reproduce

Authenticate with Simplisafe using the "com.simplisafe...." method.
Wait about two weeks
Homebridge will crash, saying the JSON file couldn't be parsed.

Homebridge logs
bridge/node_modules/homebridge-simplisafe3/lib/authManager.js:128:28)
    at new SimpliSafe3AuthenticationManager (/var/lib/homebridge/node_modules/homebridge-simplisafe3/lib/authManager.js:87:10)
    at new SS3Platform (/var/lib/homebridge/node_modules/homebridge-simplisafe3/index.js:68:24)
    at /var/lib/homebridge/node_modules/homebridge/src/server.ts:474:40
    at Array.forEach (<anonymous>)
    at Server.loadPlatforms (/var/lib/homebridge/node_modules/homebridge/src/server.ts:401:27)
    at Server.start (/var/lib/homebridge/node_modules/homebridge/src/server.ts:176:29)
[8/27/2023, 9:19:11 AM] Got SIGTERM, shutting down Homebridge...
[8/27/2023, 9:19:11 AM] AssertionError [ERR_ASSERTION]: Cannot generate setupURI on an accessory that isn't published yet!
    at Bridge.Accessory.setupURI (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:994:11)
    at Server.setServerStatus (/var/lib/homebridge/node_modules/homebridge/src/server.ts:155:45)
    at Server.teardown (/var/lib/homebridge/node_modules/homebridge/src/server.ts:199:10)
    at signalHandler (/var/lib/homebridge/node_modules/homebridge/src/cli.ts:93:12)
    at process.emit (node:events:514:28)
    at process.emit (/var/lib/homebridge/node_modules/homebridge/node_modules/source-map-support/source-map-support.js:516:21)
[8/27/2023, 9:19:16 AM] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null
[8/27/2023, 9:19:21 AM] [HB Supervisor] Restarting Homebridge...
[8/27/2023, 9:19:21 AM] [HB Supervisor] Starting Homebridge with extra flags: -I -P /var/lib/homebridge/node_modules --strict-plugin-resolution
[8/27/2023, 9:19:21 AM] [HB Supervisor] Started Homebridge v1.6.1 with PID: 3962466
[8/27/2023, 9:19:21 AM] Loaded config.json with 0 accessories and 4 platforms.
[8/27/2023, 9:19:21 AM] Loaded 17 cached accessories from cachedAccessories.
[8/27/2023, 9:19:21 AM] ---
[8/27/2023, 9:19:21 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:21 AM] Registering platform 'homebridge-nest.Nest'
[8/27/2023, 9:19:21 AM] ---
[8/27/2023, 9:19:21 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:21 AM] Registering platform 'homebridge-nest-cam.Nest-cam'
[8/27/2023, 9:19:21 AM] ---
[8/27/2023, 9:19:22 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:22 AM] Registering platform 'homebridge-simplisafe3.SimpliSafe 3'
[8/27/2023, 9:19:22 AM] ---
[8/27/2023, 9:19:22 AM] Loading 4 platforms...
[8/27/2023, 9:19:22 AM] [Nest] Initializing Nest platform...
[8/27/2023, 9:19:22 AM] [Nest-cam] Initializing Nest-cam platform...
[8/27/2023, 9:19:22 AM] [Nest-cam] Initializing child bridge 0E:1A:51:11:CB:98
[8/27/2023, 9:19:22 AM] [Home Alarm] Initializing homebridge-simplisafe3.SimpliSafe 3 platform...
[8/27/2023, 9:19:22 AM] SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at SimpliSafe3AuthenticationManager.parseAccountsFile (/var/lib/homebridge/node_modules/homebridge-simplisafe3/lib/authManager.js:128:28)
    at new SimpliSafe3AuthenticationManager (/var/lib/homebridge/node_modules/homebridge-simplisafe3/lib/authManager.js:87:10)
    at new SS3Platform (/var/lib/homebridge/node_modules/homebridge-simplisafe3/index.js:68:24)
    at /var/lib/homebridge/node_modules/homebridge/src/server.ts:474:40
    at Array.forEach (<anonymous>)
    at Server.loadPlatforms (/var/lib/homebridge/node_modules/homebridge/src/server.ts:401:27)
    at Server.start (/var/lib/homebridge/node_modules/homebridge/src/server.ts:176:29)
[8/27/2023, 9:19:22 AM] Got SIGTERM, shutting down Homebridge...
[8/27/2023, 9:19:22 AM] AssertionError [ERR_ASSERTION]: Cannot generate setupURI on an accessory that isn't published yet!
    at Bridge.Accessory.setupURI (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:994:11)
    at Server.setServerStatus (/var/lib/homebridge/node_modules/homebridge/src/server.ts:155:45)
    at Server.teardown (/var/lib/homebridge/node_modules/homebridge/src/server.ts:199:10)
    at signalHandler (/var/lib/homebridge/node_modules/homebridge/src/cli.ts:93:12)
    at process.emit (node:events:514:28)
    at process.emit (/var/lib/homebridge/node_modules/homebridge/node_modules/source-map-support/source-map-support.js:516:21)
[8/27/2023, 9:19:27 AM] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null
[8/27/2023, 9:19:32 AM] [HB Supervisor] Restarting Homebridge...
[8/27/2023, 9:19:32 AM] [HB Supervisor] Starting Homebridge with extra flags: -I -P /var/lib/homebridge/node_modules --strict-plugin-resolution
[8/27/2023, 9:19:32 AM] [HB Supervisor] Started Homebridge v1.6.1 with PID: 3962520
[8/27/2023, 9:19:32 AM] Loaded config.json with 0 accessories and 4 platforms.
[8/27/2023, 9:19:32 AM] Loaded 17 cached accessories from cachedAccessories.
[8/27/2023, 9:19:32 AM] ---
[8/27/2023, 9:19:32 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:32 AM] Registering platform 'homebridge-nest.Nest'
[8/27/2023, 9:19:32 AM] ---
[8/27/2023, 9:19:32 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:32 AM] Registering platform 'homebridge-nest-cam.Nest-cam'
[8/27/2023, 9:19:32 AM] ---
[8/27/2023, 9:19:32 AM] Loaded plugin<EMAIL_ADDRESS>[8/27/2023, 9:19:32 AM] Registering platform 'homebridge-simplisafe3.SimpliSafe 3'
[8/27/2023, 9:19:32 AM] ---
[8/27/2023, 9:19:32 AM] Loading 4 platforms...
[8/27/2023, 9:19:32 AM] [Nest] Initializing Nest platform...
[8/27/2023, 9:19:32 AM] [Nest-cam] Initializing Nest-cam platform...
[8/27/2023, 9:19:32 AM] [Nest-cam] Initializing child bridge 0E:1A:51:11:CB:98
[8/27/2023, 9:19:32 AM] [Home Alarm] Initializing homebridge-simplisafe3.SimpliSafe 3 platform...
[8/27/2023, 9:19:32 AM] SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at SimpliSafe3AuthenticationManager.parseAccountsFile (/var/lib/homebridge/node_modules/homebridge-simplisafe3/lib/authManager.js:128:28)
    at new SimpliSafe3AuthenticationManager (/var/lib/homebridge/node_modules/homebridge-simplisafe3/lib/authManager.js:87:10)
    at new SS3Platform (/var/lib/homebridge/node_modules/homebridge-simplisafe3/index.js:68:24)
    at /var/lib/homebridge/node_modules/homebridge/src/server.ts:474:40
    at Array.forEach (<anonymous>)
    at Server.loadPlatforms (/var/lib/homebridge/node_modules/homebridge/src/server.ts:401:27)
    at Server.start (/var/lib/homebridge/node_modules/homebridge/src/server.ts:176:29)
[8/27/2023, 9:19:32 AM] Got SIGTERM, shutting down Homebridge...
[8/27/2023, 9:19:32 AM] AssertionError [ERR_ASSERTION]: Cannot generate setupURI on an accessory that isn't published yet!
    at Bridge.Accessory.setupURI (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:994:11)
    at Server.setServerStatus (/var/lib/homebridge/node_modules/homebridge/src/server.ts:155:45)
    at Server.teardown (/var/lib/homebridge/node_modules/homebridge/src/server.ts:199:10)
    at signalHandler (/var/lib/homebridge/node_modules/homebridge/src/cli.ts:93:12)
    at process.emit (node:events:514:28)
    at process.emit (/var/lib/homebridge/node_modules/homebridge/node_modules/source-map-support/source-map-support.js:516:21)
[8/27/2023, 9:19:37 AM] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null
[8/27/2023, 9:19:42 AM] [HB Supervisor] Restarting Homebridge...

Homebridge config.json contents
{
    "bridge": {
        "name": "Homebridge E985",
        "username": "USERNAME",
        "port": PORT,
        "pin": "PIN",
        "advertiser": "bonjour-hap"
    },
    "accessories": [],
    "platforms": [
        {
            "name": "Config",
            "port": 8581,
            "auth": "form",
            "theme": "auto",
            "tempUnits": "f",
            "lang": "auto",
            "platform": "config"
        },
        {
            "name": "Nest",
            "googleAuth": {
                "issueToken": "ISSUE_TOKEN",
                "cookies": "COOKIE"
            },
            "options": [
                "HomeAway.Disable"
            ],
            "platform": "Nest"
        },
        {
            "platform": "Nest-cam",
            "options": {
                "ffmpegCodec": "libx264",
                "motionDetection": true,
                "streamingSwitch": true,
                "disableAudio": false,
                "streamQuality": 3,
                "doorbellAlerts": true,
                "doorbellSwitch": false
            },
            "googleAuth": {
                "issueToken": "ISSUE_TOKEN",
                "cookies": "COOKIE"
            },
            "_bridge": {
                "username": "USERNAME",
                "port": PORT_NUM
            }
        },
        {
            "name": "Home Alarm",
            "cameras": true,
            "debug": true,
            "sensorRefresh": 15,
            "persistAccessories": true,
            "cameraOptions": {
                "enableHwaccelRpi": true
            },
            "platform": "homebridge-simplisafe3.SimpliSafe 3"
        }
    ],
    "disabledPlugins": []
}

Screenshots
No response
Plugin version
1.10.13
Homebridge version
1.6.1
Node.js version
18.17.1
Host OS
Debian

In almost 3 years of maintaining and using the plug-in I have never seen this (myself or reported). Aka I cant reproduce it

That's fair! I still am going to try to use this plugin but thought it wouldn't hurt to bring up just in case.

If you are able to provide logs from when the issue actually starts that could be helpful

I will reauthenticate and keep a close eye on when it errors and grab logs as soon as I see it happen again.On Aug 27, 2023, at 13:38, shamoon @.***> wrote:
If you are able to provide logs from when the issue actually starts that could be helpful
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Yea just reviewing the code i don’t see why SS would return a null response for this and even if it did it shouldn’t write a completely empty file, see
https://github.com/homebridge-simplisafe3/homebridge-simplisafe3/blob/master/src/lib/authManager.js#L186
Yea keep me posted on what you find

Also one other thought is something with file perms or even corruption


Error Compilation

Hello ,
I get the following error while compiling the codes:
rc/mhtest.cpp: In function ‘int main(int, char**)’:
src/mhtest.cpp:101:9: error: ‘aes’ has not been declared
aes::AesCtr<uint64_t> gen1(13), gen2(1337);
I tried including #include "aesctr.h" in the code, but it produces a large number of errors.
Can someone help?

My guess is that you didn't clone this repository recursively, otherwise aesctr/aesctr.h would be present. You can fix this by running git submodule update --init --recursive . from the sketch folder or by removing and re-cloning recursively, e.g., cd .. && rm -rf sketch && git clone --recursive https://github.com/dnbaker/sketch.

My guess is still that this is the same error as this other issue, so I'll close it for now, but if your problem is different, feel free to reopen it.


Fixing build

Merging since unit tests are fixed. Ignoring the check because of how the build is setup


Dodo core logger

Coverage decreased (-71.5%) to 16.899% when pulling e7e406975270cb836d3f70247a1f12a9ef4d0943 on elhigu:dodo-core-logger into a0f7e125c0681c0d089210322c70633f27dab14f on Vincit:master.

Coverage increased (+1.4%) to 89.758% when pulling 2fb44b9a7f74ecb89a2e99ccaf106295a75675a9 on elhigu:dodo-core-logger into a0f7e125c0681c0d089210322c70633f27dab14f on Vincit:master.

Coverage increased (+1.4%) to 89.758% when pulling 2fb44b9a7f74ecb89a2e99ccaf106295a75675a9 on elhigu:dodo-core-logger into a0f7e125c0681c0d089210322c70633f27dab14f on Vincit:master.

Coverage increased (+1.4%) to 89.758% when pulling c1f955bb576f47d38b85468ba7d9ba3db99b7a18 on elhigu:dodo-core-logger into a0f7e125c0681c0d089210322c70633f27dab14f on Vincit:master.

Coverage increased (+1.4%) to 89.758% when pulling 0fcd62d069b7f48a29af9f34d3d8529832a15734 on elhigu:dodo-core-logger into a0f7e125c0681c0d089210322c70633f27dab14f on Vincit:master.


rewrite the readme.md

Could you please add the TiSpark architecture diagram from [user guide] into ./docs
I will pr the English version of Spark User Guide soon.

need a better format of the doc, anyone can help on it? many thanks


oem: ibm: Set next boot side attribute

During a rename, set the next boot side to Perm (same as current) so
that in case of a failed update, PHYP knows to boot from the Perm side.
The next boot side would be set to Temp on a successful update (via the
Priority callback function).
Update the next boot side attribute (fw_boot_side) whenever the next
boot side value is set or changed so that in error scenarios, PHYP knows
which side to boot from.
Setting fw_boot_side attribute automatically calls the function to set
the next boot side because the attribute can be also be set externally
by PHYP, therefore check the requested next boot side already has the
highest priority, in which case there's no need to set the Priority.
Also checking the current priority allows to catch if the alternate
version may not exist because of a code update that failed or is in
progress. Once an image is uploaded, set the non running version to the
uploaded image since the current non running image will be deleted
during the update.
Tested: Verified the fw_boot_side attribute matched the information in
the persisted bootSide file. The Priority value was only set when needed
(the requested next boot side was different than the current next boot
side). During a rename, both current and next are set to Perm.
Change-Id: Ibf44f53769a3394826796b1d101fcc39bdd2a4ef
Signed-off-by: Adriana Kobylak<EMAIL_ADDRESS>

Added a second commit to this PR to avoid merge conflicts. The 2nd commit removes the flag check for a Rename event. The change is mostly space formatting bu github doesn't show the diff very well, here is the high level overview:
Before:
if Activation value is Ready && update in progress:
    // inband update
    nonrunning = path;
else if Activation value is Ready && oob not in progress:
    nonrunning = path;
    oob = true;
    do rename;

With change:
if Activation value is Ready:
    nonrunning = path;
    if (update in progress)
        // inband update
    else
       // out of band, do Rename


Create a tool that gets the latest starter tasks

This feels like a "scripted" part of the newsletter; it would be nice to automate this.
I can imagine a script that you pass in the previous issue's "latest" start bug number and then gets all new ones since then (read: with a higher number).
https://docs.atlassian.com/software/jira/docs/api/REST/7.12.0/

Just throwing ideas out there but, you could use peril's scheduler to set up a daily task to analyze the apple/swift repo.
You could check the current state of PRs such as:

New PRs opened
PRs merged
PRs closed

You would need some sort of mongodb store to use the scheduler, mLab's 500mb free should suffice. It would also be useful to keep some daily state of the PR numbers in play.
I have zero time for open source at the moment, but always free to bounce ideas off of

@fassko Is this issue still relevant? It seems to me Bas is describing a workflow he used and you nowadays are not?

We can close it now.

I never figured out how to automate this, unfortunately.


Support for specifying minimum TLS version in Azure MySQL and Azure Redis

Implements https://github.com/pivotal/cloud-service-broker/issues/69

Fixes #69


World map of electronic passports

Create a world map visualization of countries' signature algorithms we can host at map.proofofpassport.com.
Hovering over a country should display:

if it issues electronic passports
the signature algorithms it uses to sign passports, and ~ how many passports have been signed with each
if they are currently supported by proof of passport

At first, it can be based on this json, which shows the number of intermediate certificates (DSCs) issued by each country and their signature algorithm. We can assume for now each DSC is used to sign in the order of 100k passports. This json has been created by parsing the ICAO registry but we should extend it to other registries. It should be easy to add new data.
Other relevant docs on e-passports here, and here.

Hey can i work on this one?

I don't know if I'm wrong or something. But the tech stack of the project changed? I remember to see a lot of kotlin and a little bit of Rust.

Hi
You would do this in typescript, this is purely UI, not part of the mobile app.

hi @0xturboblitz, can i work on this as a part of ODHack?
i would use following reference for map visualization,
https://www.react-simple-maps.io/

hey @Vignesh-PS
Yes you can work on this for the ODHack, please inform us if you start working on this so we can suspend the issue for a time.

Hi @Vignesh-PS
Do you have any updates to share with us?

hi @remicolin , few changes made for visualization as a map with tooltip info with dummy data. formatting signature_algorithms.json data to given as input to a map now.

Do you have some code/demo to share with us?

sure, added preview screenshot here
https://github.com/Vignesh-PS/proof-of-passport/tree/map-passport/map-passport

https://github.com/zk-passport/pop-landing-page/pull/1

Closing, done here: https://github.com/zk-passport/pop-landing-page/pull/1


Reduce exception message for loading missing files?

Suppose I have
file_spec_a = 'path_to_files_a/*.nc'
file_spec_b = 'path_to_files_b/*.nc'

if file_spec_b doesn't point to any existing files, then iris.load([file_spec_a, file_spec_b]) rightly produces an exception in iris.io.expand_filespecs.  However, the exception message includes all the filenames matching file_spec_a, as well as telling me that file_spec_b expanded to empty.  This can sometimes be a lot of output, which I have to search through to find the "empty" so I can fix the problem.  Could this exception message be reduced to only list the file specifications which don't expand?

#2014 is actively addressing this code now, this would be useful input for that work. Ping @davidnmurray.

#2325 touched this most recently. I'm completely up for capping the length of the matched file list so that you aren't flooded when you have thousands of matches. I'd want to keep it there if you have a small number though.

@pelson could you explain the rationale for including the matches?  My basic assumption is that the exception message only needs to tell the user about what went wrong, so including what went right seems superfluous.

That's a fair point. I guess the reason for showing all is that it will often be the case that if you're supplying multiple glob patterns they will probably follow a similar pattern, and it is useful to get feedback if one has worked but the other hasn't - normally this will occur in two scenarios:

the user has subtly changed their glob pattern, and it's broke/excludes more files than they intended
the glob pattern is fine, but the user has got the directory wrong

In either case, getting some feedback of a successful case is useful knowledge for fixing the broken case. I completely agree that the successes aren't quite as important as the fails though... so I'd be up for capping the length of the files matched...

OK, that makes sense.  If it’s just to help the user understand the difference between what works and what doesn’t, would something like this suffice?
One or more of the files specified did not exist:
42 files match path_to_files_a/*.nc
path_to_files_b/*.nc expanded to empty


Stream pod logs

Is your feature request related to a problem? Please describe.
Currently, Cyclops UI supports fetching logs of a pod, but logs are not streamed in real time. The scope of the issue is to implement log streaming for pods on both the backend and frontend.
Describe the solution you'd like
You can use SSE to stream updates. https://github.com/cyclops-ui/cyclops/pull/544 implements streaming for resources so similar libs can be used.

hi @petar-cvit, I would like to pick this up, can you please assign it me?

Sure! You can add a checkbox to the logs modal that would indicate that the logs need to be streamed

hi @petar-cvit,  had a doubt regarding this -
Should I reuse the SSE implementation from #544 (wait for it to get merged) or work on the same branch as yours or start from scratch?

Hey @naineel1209, you can create a branch from my branch and continue on my changes


Broken link on homepage

It seems, the website of "Centroy" no longer exists.

Fixed with commit https://github.com/zendframework/zf3-web/commit/ef7fe4d39da521a2f02027ee081bfdd83f49bdcc


Use GitHub code scanning

Remove LGTM and embrace GitHub code scanning
Ref: https://github.blog/2022-08-15-the-next-step-for-lgtm-com-github-code-scanning/

Closing as it is already added.


Store and Auto population of Health Authority attributes (new field notification URL)

Has_Backend
Change API spec and publisher form to include the new following fields: Notification URL to safe_paths.json
Save Notification URL via API Spec
On Load of Redacted trails, retrieve Notification URL
No_Backend
Change publisher form to include the new following field: Notification URL to safe_paths.json
Add "Load safe_paths.json" option in the Publisher tool to specify the location of an existing safe_paths.json.
Still support "loading redacted" to add to the lat/long/time data points prior to publishing a new safe_paths.json
Update API Spec to reflect new attribute: Notification UR
Update backend to store/retrieve new attribute: Notification UR

@kylemtowle
Has_backend is description is clear and should be doable.
No_Backend description is not so clear.  Could we maybe have a mockup of what you mean?

This might be tougher to explain without a mockup:
Change publisher form to include the new following field: Notification URL to safe_paths.json
Add "Load safe_paths.json" option in the Publisher tool to specify the location of an existing safe_paths.json.
Still support "loading redacted" to add to the lat/long/time data points prior to publishing a new safe_paths.json
Because the values of the fields themselves would only be in safe_paths.json file, that's why I'm suggesting we provide that option. It will also load all current concern points. Plus we allow load single redaction file (current functionality) to be done after loading an existing safe_paths.json (if this wasn't the first use)

Got it.
I suggest we table the No_backend case for dev_react
The problem is that the server spec GET /redacted_trails and safe_paths.json are formatted differently (whyyyy?)
This means that we can't reuse Steve's code to import concern points from safe_paths.json. We'd have to write a new parser to do this and this would take time, and potentially introduce bugs.
Also, sounded like Robert and Adi might be able to get dev_react out soon.

That's fine...we would need to make sure we can update the demo version of the tool with a backend = true capability (when we switch to react version) to gain this auto-populate at some point. I agree with your conclusion though.
On Wednesday, April 29, 2020, 08:31:33 AM PDT, Satoshi Kawase<EMAIL_ADDRESS>wrote:
Got it.
I suggest we table the No_backend case for dev_react
The problem is that the server spec GET /redacted_trails and safe_paths.json are formatted differently (whyyyy?)
This means that we can't reuse Steve's code to import concern points from safe_paths.json. We'd have to write a new parser to do this and this would take time, and potentially introduce bugs.
Also, sounded like Robert and Adi might be able to get dev_react out soon.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I just tested this on the dev_mvp with a backend.  Notification URL is populated in the UI but the POST on publish doesn't include the field:
{"datetime_created":"Fri, 27 Mar 2020 04:32:12 GMT","organization_id":"a88309c2-26cd-4d2b-8923-af0779e423a3","safe_path":{"authority_name":"Fake Organization","concern_points":[{"latitude":12.34,"longitude":12.34,"time":123},{"latitude":12.34,"longitude":12.34,"time":456}],"info_website":"https://www.something.gov/path/to/info/website","publish_date_utc":1584924583},"user_id":"a88309c1-26cd-4d2b-8923-af0779e423a3"}

@AdamLeonSmith Fixed on staging.


Cross-compiling should be easier

I am able to cross-compile for the Raspberry pi like this:
CROSS_PREFIX=arm-linux-gnueabi
make \
  CC=$CROSS_PREFIX-gcc \
  SHLIB="$CROSS_PREFIX-gcc -shared" \
  AR=$CROSS_PREFIX-ar \
  RANLIB=$CROSS_PREFIX-ranlib \
  SIZE=$CROSS_PREFIX-size \
  STRIPLIB=$CROSS_PREFIX-strip

This is a lot of variables to specify.  It would be easier if:

Some of the redundancies were eliminated (using $CC in SHLIB, for example)
All of the tool names were constructed with a common variable (such as CROSS_PREFIX, which would be blank by default)

I also have difficulty installing into my cross-compile environment due to the use of install -s to strip binaries.  install tries to run the host compiler's strip command, which fails for cross-compiled binaries.  It would be very helpful if install -s were not used.  Binaries could be stripped by $STRIP or similar in build rules instead.
If there are no objections, I will submit a PR to address these issues.

I welcome anything which makes life easier as long as it doesn't break anything and I have a vague understanding of what it is doing and how it works.  I'll certainly have a look.
I'm pushing out a new version shortly.


Unify errors

So if the app is using RPC or Sidcar it should return unified errors. Still they should contain information that they come from SIDECAR or RPC (some field source: RPC | SIDECAR). But with this we will be able to handle smaller number of error types on the frontend.

Possible it will be removed from 1.3.0.


Remove unused imports

Clean up the code by removing unused imports

Coverage remained the same at 91.517% when pulling 4643613dab9d91c17f0b821314885f869144aeb9 on mureinik:imports into d1a0a0d1142f796a6a3baf89c5e2fac21219d964 on JosePaumard:master.


OpenGL not supported

Hello, I have a problem during the installation, do you have any solutions?
Thanks in advance !
root@gaetan-SATELLITE-PRO-C50-J:/home/gaetan/Téléchargements/mac-on-linux-with-qemu-main# sudo ./run.sh
*** Checking for firmware files
*** Checking for Base System files
*** Check if dmg2img is available
/usr/bin/dmg2img
*** Check if BaseSystem dmg is downloaded. If downloaded convert to img
*** BaseSystem dmg available.
*** Check if BaseSystem dmg has been converted to img before.
*** BaseSystem img available.
*** Checking for disk image
*** Check if installer has been run
*** Looks like the install hasn't been done yet, lets install
*** Install!
qemu-system-x86_64: OpenGL is not supported by the display

PS: I've been looking for a solution for several hours but can't find a fix.

Is there are a reason you are trying to run this as root?
This script doesn't require root access or sudo.

By default i'm Connect in root

Some suggestions that I have:

ensure that your drivers are properly configured and verify it using glxinfo. Download glxinfo with your distributions package manager.
Try using the sdl display replacing gtk with sdl in the qemu options.

If it doesn't work after the above steps, I don't have any solutions at the moment. You could look into this project https://github.com/myspaghetti/macos-virtualbox
which uses virtualbox instead. One of the main problems we face that is qemu is not uniformly packaged in different distributions.

unfortunately I have the same problem through virtualbox..
So I'm going to reinstall a clean version of ubuntu hoping that it works... because I have the impression that version 22 poses a lot of problems.
Do you have an ubuntu version or are you sure it works? I'm going to use it as a base I think...

I can't verify that. I personally run Endeavour OS.
Before a reinstall also check out:
https://github.com/kholia/OSX-KVM
This repo also uses qemu. I should have shared this last time.
Regardless, I wish you all the best.


change background and font color

Hi dev,
first of all thanks you for sharing the script.
i would appreaciated if you could help me how to change the color background and the font color.
looking forward to hearing from you soon
best regards,
Minh Tam

Hi it has image background and for changing font of any part please refer to line 282 to 301.

Hi how can change the circle row color because the daytime blue bacgrand I culdn't see info.
e.g white

This is the problem for me. Daytime color I think is wrong because I couldn’t see

This is the problem for me. Daytime color I think is wrong because I couldn’t see. How can change e.g white I think is better than.

You can change opacity as well as colors.

Ok I find it.. two row can change: databtm, and databtmtxt. I set default and now is white and I see yeah….

Hi I tested new iPad os 15 and the widget different color why can I fix this or not.
this is iPad os 15 2. beta

This is iphone iOS 14.6

hi how can I fix the cloud color same white like iOS 14.8?

@italoboy pld help me. how can set SFSymbol async fix this bug, but I don't know how.


Configure fonts

Configure the font type and size for each section of the website (e.g. person profile, markdown content, pages title, hamburguer menu).

I found this documentation that might help
link1
link2
link3


Use temp file for test data.

Create a temporary file, write a little data to it, and then make sure it gets cleaned up afterwards. It will probably remove itself, but always good to verify.

Integrated into Issue 11.


Wrong condition

Hi Eligarf, amazing module, i want point out that, when you failed your stealth check you are not observed, you are hidden, only when critical failure happen you are observed.
So vs Perception DC:
Unnoticed if u beat init and perception DC as you said in the options.
Success: You are Undetected.
Failure: You are Hidden.
Critical Failure: You are Observed.
I'm using pf2e perception too.
Thanks!.

Thanks for reporting it, I missed the subtle use of Sneak vs Hide in the initiative rule for failure cases; I guess our group was playing this wrong!
Fixed in 1.2.3


Elevation error

Hello,
On OSX 10.11.4 I cannot launch Etcher : As soon as it starts, I am prompted for root password, but l ways get back an Elevation error :
User did not grant permission
(which I did)

@loranger That's strange, I'm thinking you could have some weird sudo configuration, or you're hitting an edge case on sudo-prompt, the module that we use to handle elevation.
Can you try running the .app with sudo directly?
sudo open path/to/Etcher.app

Does that work?

Thanks for you reply, @jviotti
I'm afraid it doesn't work either.
As you can see, as I type your command and give my password, Etcher is launching (at least in the Dock), then prompt me again for my password. I give it again, and then get the error message above.

Hi @loranger
This is indeed something I never saw before. The fact that even explicitly running the .app with sudo insists in elevation is a red sign.
Can you the following gist: https://gist.github.com/jviotti/a97604a30c5e025430930e14c15f4e4d?
Assuming you have NodeJS installed:
cd path/to/gist
npm install

And give it a go with and without sudo:
node app.js
sudo node app.js

I get false and true, respectively, in OS X 10.11.4.

I get the same result as your :
Merlin ~/D/d/a97604a30c5e025430930e14c15f4e4d ⎠⎠⎠ la                                                    ⏎ master
total 16
drwxr-xr-x  12 loranger  staff   408B 12 avr 17:31 .git
-rw-r--r--   1 loranger  staff    56B 12 avr 17:30 app.js
-rw-r--r--   1 loranger  staff   295B 12 avr 17:30 package.json
Merlin ~/D/d/a97604a30c5e025430930e14c15f4e4d ⎠⎠⎠ npm install                                             master
<EMAIL_ADDRESS>/Users/loranger/Desktop/debug_etcher/a97604a30c5e025430930e14c15f4e4d
└──<EMAIL_ADDRESS>
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
Merlin ~/D/d/a97604a30c5e025430930e14c15f4e4d ⎠⎠⎠ node app.js                                           master ◼
false
Merlin ~/D/d/a97604a30c5e025430930e14c15f4e4d ⎠⎠⎠ sudo node app.js                                      master ◼
Password:
true
Merlin ~/D/d/a97604a30c5e025430930e14c15f4e4d ⎠⎠⎠                                                       master ◼

(It sounds good, isn't it ?)

@loranger Yeah, looks good. I suspect this might be an issue with the module we're using to provide the elevation dialog (sudo-prompt).
Can you try running the following gist now and see what it outputs?

Another good experiment to make would me replacing the whoami command in that gist for node -e "console.log(process.getuid())", and see what it outputs as well.
Notice that if you ran the dialog once and it succeeded, the sudo session will be cached and you might get inaccurate results. I recommend running sudo -k each time before running the gists.

I'm sorry but the last gist does not work :
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠ npm install                                             master
<EMAIL_ADDRESS>/Users/loranger/Desktop/debug_etcher/d47c1f20dddd7337d1a672af838e2a88
└──<EMAIL_ADDRESS>
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠ node app.js                                           master ◼
/Users/loranger/Desktop/debug_etcher/d47c1f20dddd7337d1a672af838e2a88/app.js:7
    throw error;
    ^

Error: User did not grant permission.
    at /Users/loranger/Desktop/debug_etcher/d47c1f20dddd7337d1a672af838e2a88/node_modules/sudo-prompt/index.js:21:38
    at ChildProcess.exithandler (child_process.js:209:5)
    at emitTwo (events.js:100:13)
    at ChildProcess.emit (events.js:185:7)
    at maybeClose (internal/child_process.js:850:16)
    at Socket.<anonymous> (internal/child_process.js:323:11)
    at emitOne (events.js:90:13)
    at Socket.emit (events.js:182:7)
    at Pipe._onclose (net.js:475:12)
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠                                                     ⏎ master ◼

The graphical sudo did prompt, and I filled it, but it ends with this error.
Then I tried with the node -e and got the same error :
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠ cat app.js                                        ⏎ master ✱ ◼
var sudo = require('sudo-prompt');

sudo.exec('node -e "console.log(process.getuid())"', {
  name: 'Sudo Prompt Test'
}, function(error, stdout, stderr) {
  if (error) {
    throw error;
  }

  console.log('STDOUT: ' + stdout);
  console.error('STDERR: ' + stderr);
});
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠ node app.js                                         master ✱ ◼
/Users/loranger/Desktop/debug_etcher/d47c1f20dddd7337d1a672af838e2a88/app.js:7
    throw error;
    ^

Error: User did not grant permission.
    at /Users/loranger/Desktop/debug_etcher/d47c1f20dddd7337d1a672af838e2a88/node_modules/sudo-prompt/index.js:21:38
    at ChildProcess.exithandler (child_process.js:209:5)
    at emitTwo (events.js:100:13)
    at ChildProcess.emit (events.js:185:7)
    at maybeClose (internal/child_process.js:850:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:5)
Merlin ~/D/d/d47c1f20dddd7337d1a672af838e2a88 ⎠⎠⎠                                                     ⏎ master ◼

By the way, here is my environment :
node version: v5.10.1
npm version: 3.8.6
platform:  Darwin Merlin 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64 (OS X 10.11.4)

Hi @loranger ,
That's great news. At least we know the issue is in sudo-prompt. I'm not very familiar on the internal workings on this module for OS X, but @jorangreef, the author, might be able to provide some insight.
I encourage you to create a new issue in that module, explaining what happens, describing your platform and linking back to this issue, so I can stay involved and hopefully be able to help further.

Thanks @loranger, would you please test the following on that machine:

Open a Terminal window
sudo -k
sudo mkdir -p /var/db/sudo/$USER
sudo touch /var/db/sudo/$USER
Quit the Terminal window
Open another Terminal window
sudo touch /var/db/sudo/$USER

Does step 7 ask for your password?

@jviotti Thanks for your support, I've created a ticket in the sudo-prompt repository.
@jorangreef Thank you for digging in my issue. I did run your test, and yes the step 7 did ask for my password. Is my issue related to the OS X 10.10.5 kernel local privilege escalation issue I did fix by adding a Defaults tty_tickets in my /etc/sudoers ?

Yes, if step 7 asked for your password it's because tty_tickets are enabled. This is an issue in sudo-prompt (https://github.com/jorangreef/sudo-prompt/issues/13). I hope to have support for tty_tickets on OS X in the next few days.
Thanks @loranger and @jviotti for your help debugging this.

Awesome, thanks for the great help @jorangreef. Let me know if there is anything I can collaborate with on that issue.

Thanks @jviotti, I made a few major changes in https://github.com/jorangreef/sudo-prompt/commit/0b5c7d736188643a37250f56bdeaf82a356e69e8, would you mind testing on OS X (with and without tty_tickets) and Linux? It's not yet published on NPM.

Hi @jorangreef,
Thanks for the quick fix. I've tested this in OS X. It works fine with and without tty_tickets, however I can't pass relative paths to sudo.exec anymore given they will resolve to a new location under /private/.

Maybe you can preserve the current working directory?
I don't have access to a Linux box atm, but will post back my results probably later today.

I borrowed an Ubuntu 14.04 AMD64 laptop, and I confirm it works fine there as well.

Thanks @jviotti, I added a commit to preserve the cwd on OS X. It may or may not always be the case on Linux. I would like to test the various binaries on Linux further in future to address this properly. Perhaps we can use the same applet.app sub-shell approach for Linux that we are now using on OS X (see sudo-prompt-script within the MacOS directory of the applet). That should make it possible to support setting custom ENV variables and cwd via options.

@jorangreef I confirm OS X is working fine with relative paths again. The sub-shell approach makes sense for Linux as well. We don't use sudo-prompt for Linux over here so I guess we're safe to update once you publish, but feel free to ping me if you want me to test any Linux functionality (I have two Ubuntu 14.04 boxes and a Fedora 22).


[Feature Request] onBlur prop

Seems that Datepicker does not propagate addiitional props such onBlur, and using it with Formik for example, does not take into account whether Datepicker was touched or not...
Any idea how to overcome the issue?
Thank you

Hello @nic-iw 👋
Thank you for using our package.
So sorry for the delay. Thanks for the feature request. Rest assured that we will implement it very soon.
RPs are always welcome 🎉.

Hello @onesine, any update on this? Would be great to incorporate other event handlers as well...


need nodes

Hi! 0 connections, need nodes!

Hi there, I'm working on that right now.
there are no releases released because I had some problems with the compiling for Windows and MacOS.
I am also working on a block explorer and a mining pool.
if you have any more questions, feel free to ask them!


Fix fs::dir iterator with the linux_raw backend can cause memory explosion

Description 🐛
When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application.
Since <Dir as Iterator>::next calls Dir::read, which in turn calls Dir::read_more, this means an IO error encountered during reading a directory can lead to rapid and unbounded growth of memory use.
PoC:
fn main() -> Result<(), Box<dyn std::error::Error>> {
    // create a directory, get a FD to it, then unlink the directory but keep the FD
    std::fs::create_dir("tmp_dir")?;
    let dir_fd = rustix::fs::openat(
        rustix::fs::CWD,
        rustix::cstr!("tmp_dir"),
        rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,
        rustix::fs::Mode::empty(),
    )?;
    std::fs::remove_dir("tmp_dir")?;

    // iterator gets stuck in infinite loop and memory explodes
    rustix::fs::Dir::read_from(dir_fd)?
        // the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`
        // therefore if the implementation ignores the error (or otherwise continues
        // after seeing the error instead of breaking), the loop will not halt
        .filter_map(|dirent_maybe_error| dirent_maybe_error.ok())
        .for_each(|dirent| {
            // your happy path
            println!("{dirent:?}");
        });

    Ok(())
}

If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Is there an upstream PR for https://github.com/bytecodealliance/rustix that references this? Especially if you're CVSS scoring it I'm surprised to not see any mention in the changelogs.

Hi thanks for the respond, sry for CVSS is typo


[Bug] CodeCop vs. Compiler - Problem in Reports with AA0005

The warning "AA0005: Only use BEGIN..END to enclose compound statements." is ignored by the codecop in object type report.
The compiler show the warnings without problems.
Runtime 8.0.
AL Compiler version <IP_ADDRESS>9

Thanks for reporting this issue. Sorry we haven’t completed it yet, but we’ve had to prioritize elsewhere. We’re planning to give the CodeCop engine and its rules an overhaul in a future major release. Thanks for your patience.


The video tutorial is out of date and as a result examples that do not run in the current version of Angular

This video on the develop page: https://www.youtube.com/watch?v=i9MHigUZKEM
The video is from 2012 and a bit out of date as a result. As I was going through it I got to the section on controllers (~minute 28) and it was showing a way to create a global controller which apparently is no longer supported in the current version of Angular.
Stack overflow article here: http://stackoverflow.com/questions/28875575/angularjs-data-ng-controller
As I'm a beginner, I don't have a solid replacement video to suggest, but wanted to surface this information.
Thanks!

Thanks for bringing this up. It has been noted before, so let's discuss it here: https://github.com/angular/angular.js/issues/9174


examples/with-mobx : Fix and simplify

I spent far too much time fiddling with this example project before realizing it contained a bug in the store initialization logic and it was a bit more complex than it needed to be.

The custom server was not needed
The store-initialization did effectively the same thing twice for no reason
And wrapping MyApp component in a HOC was wholly unnecessary indirection

My changes are split into four discrete commits for clarity.

@maranomynet do you have any experience with this issue? https://github.com/mobxjs/mobx-react/issues/526?

No. So far I've been using smallish stores so I haven't noticed any performance problems. I'll keep following that discussion.


README Update - Frontend

Is your feature request related to a problem? Please describe.
Current README in the frontend folder is quite basic and could be developed further.
Describe the solution you'd like
A more descriptive breakdown of the frontend section of the repository.

Assigning to @5hr1ganesh

Closed by #253


error on get live tv list

i have this error
`[PROCESS][M3U8]:: Starting with URL: http://<IP_ADDRESS>:8080 ...
Process Process-2:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 1348, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 1286, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 1332, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 1281, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 1041, in _send_output
self.send(msg)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 979, in send
self.connect()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/http/client.py", line 1458, in connect
self.sock = self._context.wrap_socket(self.sock,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ssl.py", line 517, in wrap_socket
return self.sslsocket_class._create(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ssl.py", line 1108, in _create
self.do_handshake()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ssl.py", line 1379, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
self.run()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/vxparser/services.py", line 129, in loop_m3u8
vavoo.sky_m3u8()
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/vxparser/utils/vavoo.py", line 206, in sky_m3u8
response = urlopen(req)
^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 216, in urlopen
return opener.open(url, data, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 519, in open
response = self._open(req, data)
^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 536, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 496, in _call_chain
result = func(*args)`

You have a SSL certificate Problem, i think you need to Install openssl or Something in this way

self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)


referencing static float

static float value = 1.23;
sol::state L;

int main()
{
   L.open_libraries();
   L["value"] = &value;

   // run lua script:
   // print(type(value))
   // print(value)
}

print(type(value)) -> "usertype"
print(value) ->
stack index 1, expected number, received sol.float *: not a valid floating point number
stack traceback:
	[C]: in ?
	[C]: in function 'base.tostring'
	[C]: in function 'base.print'
	[string "return print(value)..."]:1: in main chunk

it's not possible reference c/c++ float value this way?  why it's not valid floating point number? what is correct way?
thank you

Copy-pasted from someone who asked the exact same question in the Discord yesterday:

You cannot take pointers to Lua variables that are "primitive" or "built in" types (float/double/int/strings/etc.)
Only tables.

To be clear, this is a Lua limitation, not a sol2 limitation. You can't write Lua code that treats that like a number, or references/points to a float and updates it without creating a special "Proxy" type.

thank you


Not compatible with filament v3

Are there plans to start working on a version that is compatible with filament v3?
Currently I replaced this package with code that uses PHP sessions to store a specific users primary color based on some parameters.

It's not necessary to adapt this package for filament v3.
Because you can directly configure the primary color palette in the panel configuration
See https://filamentphp.com/docs/3.x/panels/themes#generating-a-color-palette