Layout-dialect migration issues (thymeleaf 2->3,  layout-dialect 2.0-snapshot)

Hi,
i am a developer and trying to migrate an existing fully working website from thymeleaf 2 to thymeleaf 3 including the layout-dialect.  After a bugfix in the thymeleaf-data-extras, everthing seems to work except the styling of the website. After some research it looks that the layout:decorator causes the issue that the  of the main home.html page is always empty when adding a layout:decorator tag.
Below the part of code causing the issue (this structure causes the issue on every page of the website).
When i remove the layout:decorator tag, the  part is included in the output result of the page as-is.
However when adding the layout:decorator basic template (see below), the output result of the page is always  (empty head-content).  Even when the layout/2col_wide_left template is empty, or whatever i  place in there the result output page shows an empty .
Even if i also place a  xxx part in the base template (2col_wide_left), the  in the output result is empty.
Is verion 2.0-snapshot of layout-dialect not thymeleaf-3 ready ?  Or do i have to change something in my html templates (but then it should be explained in the migration guide ?).
Hope someone can help ;-)
!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org"
      xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"
      layout:decorator="'layout/2col_wide_left'">
    <head>
        <title>Title</title>
        [everything i put here like a href to load css is removed from the result,
          so also the title is not shown in the result of the page.]
    </head>
    <body>
.... etc.`

Hi @robvanderboom, please have a look at issue 110.

@robvanderboom, if you find that @retromuz's fix works, then there's a bug in my code that doesn't handle those self-closed elements properly, and I should fix that in a future snapshot version.

Hi, no sorry the project already loses links and meta tags with />.  And i also do not get exceptions.
Wish that was the problem but unfortunately  not ;-)

Loses=closes

is the snapshot version available on some maven repo ? dont see it on jitpack.io.

http://oss.sonatype.org/content/repositories/snapshots

Hi @robvanderboom, sorry for taking so long to get back to you.  I've recently finished getting the latest 2.0 snapshot feature-complete and in the process got through more tests and use cases that the layout dialect is supposed to do, including the one you've raised the issue about re: losing elements in the <head> section of your template.
Have you tried the latest snapshot to see if it helps at all?
Aside from the filling-out of more features, I think the next biggest thing that has changed since posting of this issue and now is that I've added a bit of backwards-compatibility code so that you no longer have to wrap template names in single quotes to get the layout dialect to treat it as a string like I see in your example, 'layout/2col_wide_left'.  In your case, the layout dialect will wrap something like layout/2col_wide_left as a Thymeleaf 3 fragment expression (wrapped in ~{...}), and emit a warning in the logs that you might want to do that yourself to future-proof your code.
Aside from that, all I can see is that your example has a missing < for the DOCTYPE, but I think that's just a typo.

Haven't heard back from the OP in a while 😢  Closing.


[Bug]Incorrect description on Dark Theme Inline Title Custom Text Color

Describe the bug
The description for the "Inline Title Custom Text Color" option in Style Settings indicates "Light Theme" in the Dark Theme section.
To Reproduce

Open Style Settings.
Click on Prism Theme > Editor > Headers > Header Text Color > Dark Theme.
The description of "Inline Title Custom Text Color" states "Make sure you selected 'Custom' in Light Theme..."

Expected behavior
As this is the Dark Theme section, it is expected that this description would state "Dark Theme" instead of "Light Theme".
Screenshots

Setup Information

Device Type: Lenovo laptop
Operating System: Windows 10
Prism version: 3.0.4
Color Schemes Used: Raven
Obsidian Version: v1.0.3
Obsidian Installer Version: v0.15.9
Related Community plugins: Style Settings

Additional context
Issue was not observed for other items in this specific section.

Hi @ZephiraZ,
Good catch! Thanks for reporting. I'll have it fixed for the next patch release.

Hi @ZephiraZ,
This issue should now be addressed in version 3.1.0.


change some errors into warnings

[@gavinking] Currently, unreachable code or a condition that can never be satisfied or is always satisfied results in an error.  Well, I guess I still don't really see the point of letting you write code that has no effect, and I've never been a big fan of compiler warnings, but now that we do have warnings for unused local declarations, I suppose we could change this class of error into warnings.
But then the backend would have to be a little bit smart about how it handles this stuff.
It's not clear to me how much priority I should assign to this change. It's a small thing but I'm inclined to leave it 'til after the 1.0 release.
[Migrated from ceylon/ceylon-spec#546]

Note that some related problems were already solved in #6056.


Automated cherry pick of #6702: fix: gcp默认创建允许所有地址访问的用户

Cherry pick of #6702 on release/3.2.
#6702: fix: gcp默认创建允许所有地址访问的用户

Codecov Report

Merging #6703 into release/3.2 will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@               Coverage Diff               @@
##           release/3.2    #6703      +/-   ##
===============================================
- Coverage         7.03%    7.03%   -0.01%
===============================================
  Files              650      650
  Lines           111812   111828      +16
===============================================
- Hits              7869     7864       -5
- Misses          103334   103355      +21
  Partials           609      609

Flag
Coverage Δ

#aFlag
7.03% <0.00%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/baremetal/tasks/bm_register.go
0.00% <0.00%> (ø)

pkg/baremetal/tasks/ipmiprobe.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/namevalidator.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/opslog.go
1.50% <0.00%> (-0.01%)
:arrow_down:

pkg/cloudcommon/db/scoperesource.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/tenantcache.go
2.93% <0.00%> (-0.35%)
:arrow_down:

pkg/cloudcommon/policy/resources.go
0.00% <ø> (ø)

pkg/cloudprovider/cloudprovider.go
1.53% <0.00%> (ø)

pkg/cloudprovider/instance.go
0.00% <ø> (ø)

pkg/cloudprovider/objectstore.go
2.48% <0.00%> (-0.01%)
:arrow_down:

... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d3f8c71...040a905. Read the comment docs.


[SPARK-20300][ML][PYSPARK] Python API for ALSModel.recommendForAllUsers,Items

Add Python API for ALSModel methods recommendForAllUsers, recommendForAllItems
How was this patch tested?
New doc tests.

cc @jkbradley

Test build #75745 has started for PR 17622 at commit abe6cfb.

Test build #75745 has finished for PR 17622 at commit abe6cfb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/75745/
Test PASSed.

Merged build finished. Test PASSed.

LGTM except for a doc comment.

Test build #76099 has started for PR 17622 at commit 7644e51.

Test build #76099 has finished for PR 17622 at commit 7644e51.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/76099/
Test PASSed.

If no other comments (@jkbradley) I will merge to branch-2.2 in a few days.

Merged to master/branch-2.2


png export

fixed in 04dd81e
note: typo on commit message, pdf is supported as well (svg already was)


Adding validation to fields in graphql api schema

** Which Category is your question related to? **
Amplify GraphQL API
Is it possible to add validation to fields in the schema file? So min/max length, min/max value etc? If I had a field on a Person type and wanted to limit their name field to 250 characters, is that possible using the schema file only? Otherwise how can this be done?

We don't package any transformers that allow you to do this out of the box but have discussed use cases like this in the past. If you want to do this purely using the schema.graphql today, you can write your own transformer that will augment the generated resolver template code. To make this work you will also need to write your own light-weight CLI that loads and runs the transformer. There are docs on this here https://aws-amplify.github.io/docs/js/graphql#writing-custom-transformers.
The way to implement this in AppSync is to write resolver code that validates inputs during mutations. For example, if you wanted to validate that the "name" is a max of 250 characters then you would add a snippet like this to createPerson and updatePerson resolvers:
## mutation.create/updatePerson.request.vtl **
#if( $ctx.args.input.name.length() > 250 )
    $util.error("Invalid name on Create/UpdatePersonInput.")
#end

If you provided a name longer than 250 characters this would cause the mutation to fail before saving the object to DynamoDB. This is how your custom transformer would work too, but you would be generating the above snippet in your transformer instead of writing it by hand.

What directives would you like access to? Over the long term, we can work on building a few transformers that tackle common issues but it would be helpful to hear more about the use cases you want to be solved.
For example, I would suspect these two would be useful:
@regex
directive @regex(expression: String!) on FIELD_DEFINITION

Usage
type Post {
  id: ID!
  title: String @regex(expression: ".*graphql.*")
}

@length
directive @length(min: Int, max: Int) on FIELD_DEFINITION

type Post {
  id: ID!
  title: String @length(min: 10, max: 255)
}

There are a lot of possibilities so let me know what you think and we will prioritize based on demand.

@mikeparisstuff  thanks for the code snippet. I'll take a look at this. As for the possible directives. I guess what you mentioned sounds reasonable with the addition of maybe:

@equals - equality check which would work for all/most types like int, ID, string etc
@notEqual - not equal to
@in - a set of values that it can be
@notIn - a set of values that it can never be (I wonder if this would actually be useful)
@lt - less than (should probably work with numbers/times etc)
@gt - greater than (similar to above)
@multipleOf - check if value is multiple of some input

there's also a few common simplified regex checks I guess. @startsWIth, @endsWith, @contains
also for the length implementation, should max be optional somehow? Maybe we want the value to be at least 10.

I would be interested for sure. I was looking for something like a @readonly directive which would cause the field to be excluded from the generated Inputs but available for "reading". I'd imagine a @writeonly field might be something we'd want as well. Maybe something like @toUpper @toLower, etc. It would be great to be able to create these on our own even if not available in core amplify-cli.

Do we have any update about those new directives? This is a very interesting matter if we want to build an complete application while writing the minimum of serveless code

This would be amazing! Hoping for news on availability soon... maybe re:Invent?!

This would be great and would really make writing complex models a breeze! Is there anything planned for above mentioned directives?

I would be interested for sure. I was looking for something like a @readonly directive which would cause the field to be excluded from the generated Inputs but available for "reading". I'd imagine a @writeonly field might be something we'd want as well. Maybe something like @toupper @tolower, etc. It would be great to be able to create these on our own even if not available in core amplify-cli.

I think this usage is covered by: https://www.npmjs.com/package/graphql-auto-transformer

I've made https://github.com/hirochachacha/graphql-assert-transformer
type Post @model {
  id: ID!
  title: String @assert(condition: """.length() > 3 && .matches("t.*")""")
  text: String @assert(condition: ".length() > 10")
  episode: Int @assert(condition: ". % 2 == 0")
}

Any updates on the custom field validations?

Fro custom field level validations, I would highly recommend looking at writing custom transformer directive plugins based on our docs here - https://docs.amplify.aws/cli/plugins/authoring#custom-graphql-transformers
Found a similar 3rd party custom directive plugin here for field level validations/operations - https://www.npmjs.com/package/graphql-default-value-transformer and the code for which is here https://github.com/trek10inc/graphql-default-value-transformer

Also, as @andreialecu mentioned there are some more 3rd party custom directives which you could leverage:
@readonly usage is covered by: https://www.npmjs.com/package/graphql-auto-transformer by @hirochachacha
@tolower: https://www.npmjs.com/package/graphql-lowercase-transformer by @hisham

any updates on this??

Any update on this? Is there any plan to integrate something like https://github.com/hirochachacha/graphql-assert-transformer within amplify? I suppose validation is quite a common use case for every one. I understand it is possible to write custom resolvers, but having the chance to declare it in the schema.graphql like shown in graphql-assert-transformer would be a great advantage I reckon.

+1

If I'm understanding correctly, there's no simple way to have a lambda function perform validation as part of an update action on a model, right?
I was hoping a directive like @function on a model would allow me to check the data that's about to be applied in the update and reject it if it fails my validation - currently this is not the case, but I would like to see something similar to this.  I feel like custom validation is essential but I'm not finding a straightforward way to accomplish it, any insight would be helpful. Thanks!

relevant in regards to constraints https://github.com/aws-amplify/amplify-cli/issues/4972


Bug: Navbar is not responsive

@aditya-bhaumik
To make the navbar responsive, we can incorporate a sleek hamburger menu icon for smaller screen sizes, which will elegantly display the navigation links when clicked.

Kindly assign this issue to me and add gssoc-extd and hactoberfest tag and level it.

@AkankshaSinghK i alrady told in discord not yo make issues on mavbar please join discord server


Regularly validate CNCF conformance of CAPI clusters

Acceptance criteria:

[ ] CNCF tests are being regularly ran for all providers against latest state of cluster and default apps app
[ ] Teams can easily find and access results
[ ] There is a notification mechanism for when tests fail

Implemented in https://github.com/giantswarm/tekton-resources/pull/93


Another disappearing advice window

Challenge http://beta.freecodecamp.com/challenges/waypoint-create-a-bootstrap-row has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
Another example of the advice window disappearing upon input.  Here is the initial window:

As soon as you start typing "<d", the window disappears:

@garysmeade Have you completed the Waypoint? Just typing ```<d```` would cause an error.


Changing entity data doesn't update contentState, and changing selection state or entity data does not cause decorators to run

Type
Bug
Current Behavior

Changing entity data (via Modifier.applyEntity for example) does not change the contentState (it mutates it).
Decorators do not re-render after changing entity data (likely due to above). They DO render if you create new entities and apply them with the same data though.
Decorators do not re-render after changing selection state (common workaround to above is to forceSelection, but this does not work with decorators)

Steps to Reproduce
This existing issue's fiddle goes over the contentState not updating due to mutable entities:
https://github.com/facebook/draft-js/issues/1256
And this existing issue's fiddle can be re-used to observe the decorator not rendering:
https://github.com/facebook/draft-js/issues/1047
The discussion in that second issue is highly relevant to this as well, but in my case, forceSelection did not resolve the issue. It wasn't until either the text changed or a new entity was applied that the decorators rendered.
Expected

Changing either entity data or selection state should trigger decorators to re-render

Versions

draft-js 0.10.4
draft-js-plugin-editor: 2.0.3
Chrome, Firefox (both latest)
various versions of 0.10.x have the same issue

Encountering this with my external button onClick handlers as well. Have been using Modifier's insertText and can confirm that the contentState of my editor is updating, but is not triggering a rerender.

The moment I commented here was the moment I found how to work around this.
I was using a component that is position: absoluted on top of the editor, and the event was propagating down to the editor. I think it was a race condition between the onClick's update that I was doing and the natural focus event.
Calling stopPropagation on the onClick event solves this for me.

Can replicate in 10.5.0 too.
`const updateEntity = (patch) => {
const mergedContent = editorState.getCurrentContent().mergeEntityData(entityKey, patch);
    let changedContentState = Modifier.applyEntity(
        mergedContent,
        editorState.getSelection(),
        entityKey
    );

    onChangeEditorState(EditorState.push(editorState, changedContentState, 'insert-characters'));
};

`
Entity decorator doesnt re-render, so text inside editor field doesnt change. But i can see it new inside editorState itself.

Can replicate in 0.11
const editorState = blockPropsRef.current.editorStateRef.current;
const content = editorState.getCurrentContent();
const contentWithNewData = content.mergeEntityData(entityKey, entityData);

// replace entity with block data , is work
// const contentWithNewData = Modifier.mergeBlockData(
//   content,
//   content.getSelectionAfter(),
//   Map(entityData)
// );

const newEditorState = EditorState.push(
  editorState,
  contentWithNewData,
  EditorChangeTypeEnum.ChangeBlockData
);

console.log(newEditorState === editorState);  // the value get true, not tigger a re-render
blockPropsRef.current.setEditorState(newEditorState);

https://draftjs.org/docs/v0-10-api-migration/#content

Any changes to entity data will trigger a re-render.

I saw it in the document introduction, I do n’t know if it ’s a version problem

As mentioned by @tolerance-go calling mergeEntityData does not cause a re-render as specified in the documentation. Can someone please advise if there is a fix or workaround? Using v 0.10.5

Same here.

same here.

Can replicate in 0.11
const editorState = blockPropsRef.current.editorStateRef.current;
const content = editorState.getCurrentContent();
const contentWithNewData = content.mergeEntityData(entityKey, entityData);

// replace entity with block data , is work
// const contentWithNewData = Modifier.mergeBlockData(
//   content,
//   content.getSelectionAfter(),
//   Map(entityData)
// );

const newEditorState = EditorState.push(
  editorState,
  contentWithNewData,
  EditorChangeTypeEnum.ChangeBlockData
);

console.log(newEditorState === editorState);  // the value get true, not tigger a re-render
blockPropsRef.current.setEditorState(newEditorState);

https://draftjs.org/docs/v0-10-api-migration/#content

Any changes to entity data will trigger a re-render.

I saw it in the document introduction, I do n’t know if it ’s a version problem

The fact that merging entity data doesn't update the content state its a problem on its own, but I thought that maybe push could provide a workaround. If you were to apply an entity change and then call an EditorState.push with a specific change type (entityModified for example) you could in theory recognize that change and handle it in the onChange function of the editor.
However because of this check: https://github.com/facebook/draft-js/blob/master/src/model/immutable/EditorState.js#L442
we can't even do that.
I'm wondering if maybe allowing us to "force" a state update via push could be a possible solution to this issue.

I managed to get it to rerender by replacing the text with itself:
        contentState = Modifier.replaceText(           contentState,           selectionState,           block.getText().substring(start, end), // start and end are the same as the selection state anchor and focus offset           undefined,           entityKey,         )`

contentState.mergeEntityData(entityKey, { ...values })

setState(EditorState.forceSelection(state, state.getSelection()))

helped to me.

Same problem. Using replaceEntityData or mergeEntityData changes the editorState but does not trigger rerender as expected. Version 0.11.6.

@lxpowers33 it seems like it's expected behaviour (looking through the code it just merges the data using immutable). I switched to using forceSelection instead of my previous replaceText suggestion since it's actually quite the cpu cycle drain to use modifiers to do no-ops when editing lots of entity data.
So far forceSelection seems to work well for me 👍

I'm running into a situation where I would like to update my Decorator component for an entity based on the current selection state - if the selection intersects the entity, I want to change how I render.  Is using entity data the suggested way to accomplish this?  It seems a bit odd to me to use entity data and then forceSelection afterward to rerender my Decorator component - I would have to add logic to only forceSelection if the selection was changed, I suppose.
I have been trying to solve passing props using React context, but that is causing a major problem for me in managing the selection state of the Draft editor.  It looks like if I provide context above the Draft editor and then useContext in my Decorator component, extra rerendering occurs and the current selection state of the editor breaks.  I'm guessing that Decorator components are not designed to be used with React context?  But if so, I'm not sure how to create a feature rich entity that updates in response to editor state changes.

The workaround I have for this is to delete / recreate the entity. This works nice, but code is less clear.


Debuger doesn't work anymore

Hello

VSCode Version: 1.43.2
OS Version:  macOS 10.14.6

Steps to Reproduce:

Click on the green arrow "Start Debugging"

Hello, when i try to run the debugger i have those two error :

It worked well before i install python3.7 (but i have a doubt if the last time was before or after 3.7). I had 3.6 before.
The files not found are here (the third one is the one i'm trying to debug so obviously it's here !) :

Thanks

/extPython


Takes about 3x the time running stryker after this change in code.

Question
Running jest takes a few seconds, but infection testing takes very long.
It seems its cause the following change, but i have no idea why
from
public async process(
    request: ServerRequestInterface,
    handler: RequestHandlerInterface,
): Promise<ResponseInterface> {
    try {
        return await handler.handle(request);
    } catch (e) {
        return this.handleError(e);
    }
}

to
public async process(
    request: ServerRequestInterface,
    handler: RequestHandlerInterface,
): Promise<ResponseInterface> {
    return new Promise((resolve) => {
        handler
            .handle(request)
            .then((response) => {
                resolve(response);
            })
            .catch((error) => {
                resolve(this.handleError(error));
            });
    });
}

Do you have any idea why?

Stryker environment

+--<EMAIL_ADDRESS>

+--<EMAIL_ADDRESS>

Thanks for opening this issue! How many mutants are generated in both cases?

Its not 3x time in this run, but close to 2x
await: killed 37, timeout: 2 (27 Seconds)
promise: killed 27, timeout: 13 (47 Seconds)

13x timeout is probably the reason

It is most likely yes. During performance testing some time ago we have noticed during timeout process is being restarted which gives some overhead, and timeout means it couldn't finish work in given time (which means it was stuck for that time),
So if we assume you run 30tests,
Good takes .1s and timeout 3s:
20good/10timeout - 32s
10good/20timeout - 61s
Unfortunately the only thing we/you could do is reduce timeout time

@kmdrGroch thanks for clarification

I can't remember the option on top of my head, but try looking for timeout configuration in Stryker. Change value there and see results in both cases :)


ti-connect-ce-software-np: Fix executable name

Closes #83

[x] I have read the Contributing Guide.

/verify

... I don't suppose anyone is home?


Add choropleth support

Basic implementation of choropleth map-type with ChoroplethViz and choropleth.html; addresses #4

@ryanbauman Thanks for the feedback! Haven't worked with vector or raster data in the Mapbox or Leaflet environments before so I'll familiarize myself and continue working on this PR. Looks like #21 is also working on raster layers so I don't want to duplicate implementation. Maybe classes for raster or vector layers that can be stacked with the other viz types?
Are you looking for complete replication of Mapbox's example chloropleth style, hover, etc?  That would include the HTML stationary popup that calls out the color-property on hover.

@akacarlyann

Looks like #21 is also working on raster layers so I don't want to duplicate implementation.
Correct.  You're spot on in this PR - lets keep the choropleth viz type in mapboxgl-jupyter to vector data.

Maybe classes for raster or vector layers that can be stacked with the other viz types?

Yes, working on that feature in another issue here https://github.com/mapbox/mapboxgl-jupyter/issues/34#issuecomment-363304930

Are you looking for complete replication of Mapbox's example chloropleth style, hover, etc? That would include the HTML stationary popup that calls out the color-property on hover.

Yes, that's a great reference starting point.  Ideally, the default choropleth would have this basic format: https://bl.ocks.org/ryanbaumann/2636bf33c7f1f6c53eca8fd34675f0bb

@ryanbaumann  Made some progress today wrt adding chloropleth-line and chloropleth-label layers to ChloroplethViz and its template.  Still need to add tests/docs and support for vector tile sources.

Awesome progress @akacarlyann!  I'm happy to help with the vector tile source code if you can hit docs and tests for the existing functionality.

@akacarlyann if you've already started on Sphynx docs, let me know.  We're planning to use a simpler approach to docs as a markdown page in the first release.  See the PR at https://github.com/mapbox/mapboxgl-jupyter/pull/46

@ryanbaumann I'm happy to add to the markdown development (familiar with that format) and documentation of the code I've contributed.  Haven't written up anything in Sphinx yet but I have some notes. Let me know how you me want to integrate the chloropleth  docs (fork and PR the current markdown PR?).

Markdown docs are merged into master @akacarlyann
https://github.com/mapbox/mapboxgl-jupyter/tree/master/docs-markdown

Great. I'll see what I can do with that this weekend :)

@ryanbaumann I've pushed commits for adding ChloroplethViz to the markdown docs.  I'm at the 85% solution for supporting vector tile sources.

Amazing @akacarlyann.  Vector tile sources with data joins are going to be super powerful for users.  Thanks for pushing on this - let me know when you're ready for a review.

@ryanbaumann There is no polygon data in the tests/ module.  Do you have a polygon dataset that fits well with the existing tests?  Otherwise I'll build in something like
@pytest.fixture()
def polygon_data():
    with open('tests/polygons.geojson') as fh:
        return json.loads(fh.read())

probably using the US states population density info I've been working with.

@akacarlyann that's excellent re: using a small local tileset like US States.  Natural Earth is a great source of simplified small polygon boundaries for testing - http://www.naturalearthdata.com/downloads/110m-physical-vectors/

This is awesome work! I'll use it immediately.
And, apologies for the random nit from the internet, but as far as naming goes, what's the difference between "chloropleth" and "choropleth" (which I've seen more often)?

@ajfriend Ha! The difference is mine have been the only eyes on this so far and now I'm just going to go update spelling throughout. Thanks for the comment!

@ajfriend Ha! I think the main difference is mine have been the only eyes on this PR so far.  Seems like Mapbox uses the Choropleth spelling (how did I miss that?), so I'll probably update spelling, though I originally found Chloropleth at https://python-graph-gallery.com/chloropleth-map/  .  Thanks for your comment!

The choropleth notebook included in this PR is giving me some sort of formatting errors. I cannot open it with nbviewer either:
http://nbviewer.jupyter.org/github/akacarlyann/mapboxgl-jupyter/blob/ac8c1000833e56cd7d806c56894e5df2f694aa45/examples/choropleth-viz-example.ipynb

Trivial fix, probably due to find 'n' replace
--- a/examples/choropleth-viz-example.ipynb
+++ b/examples/choropleth-viz-example.ipynb
@@ -44,9 +44,7 @@
     "    [10000.0,'rgb(128,0,38)']\n",
     "]\n",
     "   \n",
-    "viz =
-
-ChoroplethViz('us-states.geojson', \n",
+    "viz = ChoroplethViz('us-states.geojson', \n",
     "                     color_property='density',\n",
     "                     color_stops=sample_color_stops,\n",
     "                     color_function_type='interpolate',\n",
@@ -80,9 +78,7 @@ ChoroplethViz('us-states.geojson', \n",
     "    ['California', 'rgb(142,68,173)'],\n",
     "]\n",
     "    \n",
-    "viz =
-
-ChoroplethViz('us-states.geojson', \n",
+    "viz = ChoroplethViz('us-states.geojson', \n",
     "                     color_property='name', \n",
     "                     color_stops = match_color_stops, \n",
     "                     color_function_type = 'match', \n",

cc @akacarlyann 👆

@ryanbaumann I've found and been able to implement examples of the data-join technique that rely on generating colors based on a numerical property (index, density, unemployment rate...). This method is problematic for ChoroplethViz because colors generated in this way will override the user-defined color_stops argument and cause a mismatch with the map's legend.

https://www.mapbox.com/mapbox-gl-js/example/data-join/
https://bl.ocks.org/ryanbaumann/.../

Looks like you were involved in all of these!
I'm most interested in this map:
https://www.mapbox.com/labs/dataset-join/#3.03/36.45/-90.02
https://blog.mapbox.com/visualize-the-usas-economic-recovery-with-client-side-data-joins-2aeab23ee9b0
Can you provide some insight into the actual color calculation function for this example?  Is this still the categorical property function method?  The color-stops in the legend lead me to believe that it might be possible to preserve our current color-stop paradigm.
TL;DR I want a choropleth visualization made with either a geojson or vector polygon source to result in identically colored maps.  Thoughts on that?

Great question @akacarlyann - are your latest changes pushed to this branch?  Happy to do a PR review to help recommend an approach.

@ryanbaumann I've pushed a couple of options (this makes me nervous since I don't want anyone to take this as a finished product).  My sense is that we would hope to generate a single color function for either vector+data-join or the current color_stops paradigm.
With so many additional arguments only necessary for if the polygons come from a vector layer, I'll obviously need to design some new tests and/or set up more robust defaults in case one is missed.  I didn't invest any time in this yet, as I can still see this branch going in several somewhat different directions.
Thanks in advance for taking a look!  I've updated the example notebook at examples/choropleth-viz-example.ipynb to include two samples using vector source for the polygons.

Excellent @akacarlyann.  No need to worry about the PR being in an evaluation state still - I'll get you feedback by the end of the week.  Thank you!

@akacarlyann added replies to your comments above.  It sounds like the biggest decision points right now are to:

Whether or not to separate out a mapboxgl.viz class for a choropleth viz from a vector tile source vs. a geojson source.

My preference here is no, as it would cause class sprawl.  We'd follow this same paradigm for other viz types too, like extrusions and linestrings.
If we use the same class for both geojson and vector sources, whether or not to create new style properties to the class specifically for the vector source vs. the geojson source.

How to calculate the data-join match between vector tiles and local data in Python - should it be in Python or in JS?

My preference here is to do this in Python using the Chroma library.

Let me know your thoughts on the approach to ^^

@akacarlyann are you planning on wrapping up this PR, or would you like some assistance?

This is looking amazing, @akacarlyann!  Great job coalescing the various different geojson vs. vector tile methods of creating fill maps into one ChoroplethViz syntax.  I took a quick look and pushed a small doc update to keep track of the syntax - all looks good.
Final items to hit before merge that I'm sure you're tracking:

[ ] "Use  chroma.js scales to calculate color values for the match style from the user-specified color stops
[ ] Update tooltips to reference data passed to the visual, in addition to properties in the vector tiles.
[ ] Update the vector tile join example to use ^^

I think that's it - nice work!

Thanks! The tooltips do append the joined data property. Are you wanting additional features to also migrate to the vector features tooltips? If so that's not too much to add, just didn't realize it was in the scope.
And yep still on the color matching. I'll push an update later today most likely.

Excellent @akacarlyann !
RE:

The tooltips do append the joined data property. Are you wanting additional features to also migrate to the vector features tooltips? If so that's not too much to add, just didn't realize it was in the scope.

They should, I but they wern't showing up running the example notebook.  I narrowed it down to two items to fix - added comments to your latest commit.

@ryanbaumann  I finally got the color logic working over the weekend!  I'm cleaning up my last commits now.

Amazing @akacarlyann, thank you!  Let me know when you're ready for a review.

@ryanbaumann It's ready for review now :) I took a stab at tests for the new functions I introduced but I need a little help getting those on track. I also noticed when merging master back in to my branch that there is an import from colour that conflicts with mine from chroma-py, so I renamed one of the Color classes. I'm happy to refactor if these serve similar purposes, just let me know!

Awesome - I'll get you a PR review by Saturday, thanks @akacarlyann

@ryanbaumann Thanks, I'll get those in today :)

Alrighty, @ryanbaumann , tests and your requested changes ready for review!

@akacarlyann this is so good.  Thanks for pushing through a difficult PR, laying the foundation for all sorts of new viz types with the data-join technique packaged up!


Uncaught (in promise): TypeError: System.import is not a function

After running npm run serve.prod and Browser complaining
"Uncaught (in promise): TypeError: System.import is not a function"

@chaplin The build tools for production are setup to bundle the app in a way that does removes the need for System module loader. Did you modify /tools/config/seed.config.ts or anything in tools/task/seed/ directly?

@RoxKilly thank for your quick reply
No I did't modify anything in /tools/config/seed.config.ts and tools/task/seed.

But I do modify tslint.json according issues #12120

If in /tools/config/seed.config.ts, you replace the line:
    { src: 'systemjs/dist/system.src.js', inject: 'shims', env: ENVIRONMENTS.DEVELOPMENT },

With
    { src: 'systemjs/dist/system.src.js', inject: 'shims'},

Does the error still occur?
Secondly, did you edit index.html, in particular the block of code around System.import? If so, how?

the System.import is not a function error is disappear but got another one

Does the app work when you use serve.dev task?

This issue is caused by misconfiguration. The production build does not use SystemJS but instead bundles tp cjs modules.
For support requests you can use gitter or take a look at project's the wiki page in order to get more complete idea on how the it works.

I am having the same issue with prod .Has anyone found a fix ?

This happens when i try to lazy load the modules

export const routes: Routes = [
...HomeRoutes,
...AboutRoutes,
{
path: '',
loadChildren:'./app/account/account.module#AccountModule'
},
];

@gomesNazareth I don't know how to use this seed to deploy lazy loaded modules. I don't think it's supported

Have a look here, this is not a seed issue, but rather how to use the angular router: https://youtu.be/QLns6s02O48?t=6m27s

@TheDonDope what systemjs has to do with the router ?

Great...

In the lazy branch we have experiments with bundling for lazy loading. The production works, I need to spend some more time making it work with AoT enabled.

@mgechev thanks, I will check it 👍

lazy loading prod build  work well on mac and linux . but  on windows  it fails .. file paths  are not correct. .

I run into the same problem as @chaplin  (using the lazy branch)
For some reason it does not resolve the lazy loaded files with the proper extension:
EXCEPTION: Uncaught (in promise): Error: (SystemJS) Unexpected token <
SyntaxError: Unexpected token <
at eval ()
Evaluating http://localhost:5555/app/components/content/dashboard/dashboard.module
Error loading http://localhost:5555/app/components/content/dashboard/dashboard.module
Any ideas?


Spans logged to stdout are completely opaque.

Requirement - what kind of business use case are you trying to solve?
Trying to use the tracing system as much as possible while avoiding duplication of code for logging the same info we trace.
Problem - what in Jaeger blocks you from solving the requirement?
It seems as though the logging system is indeed logging info to stdout when I configure JAEGER_REPORTER_LOG_SPANS="true". We are also using this (abridged) pattern to configure our tracer:
cfg, err := jaegercfg.FromEnv()
cfg.NewTracer(jaegercfg.Logger(jaegerzap.NewLogger(logger))) // logger is a *zap.Logger

So, on std out we are seeing some stuff like this:
{"level":"info","ts":1585943947.7758605,"caller":"zap/logger.go:38","msg":"Reporting span d446f0017b23aca:ba8e6b046d97460:d446f0017b23aca:1"}
{"level":"info","ts":1585943947.7803075,"caller":"zap/logger.go:38","msg":"Reporting span d446f0017b23aca:d446f0017b23aca:0:1"}
{"level":"info","ts":1585943947.7819207,"caller":"zap/logger.go:38","msg":"Reporting span 2787e9fe71ca9f60:73bdb7a68f1625f:2787e9fe71ca9f60:1"}

Looks like the span is being shown in a hex format due to being in protobuf or thrift format. I would love to be able to just serialize the contents as JSON so that we can see this information clearly during development and from within our log aggregation system. To be sure, all of the traces are landing in Jaeger correctly, and we can see them in the Jaeger UI just fine.
Proposal - what do you suggest to solve the problem or improve the existing situation?
This could be a simple solution. Perhaps I need to use a different logging mechanism for this, or implement a mechanism to serialize the span body as needed. Just let me know.
Any open questions to address
N/A

The LOG_SPANS option exists for debugging purposes to ensure that your application is generating spans. It's not actually logging the spans, only their IDs.

Ahhh :'(
@yurishkuro are you familiar with any tracing reporters which are compatible with this system and which will log the traces to stdout?

I am not sure what value there is to log traces to stdout. What is it that you're trying to accomplish?

I can agree. It is a duplication of data. The primary benefit may just be in terms of immediate access to the data. For example, when tailing the logs of a service during development. Typically not every library/framework will have tracing integration, so being able to log the spans to stdout in a human-friendly way is a boon in terms of immediate access and uniformity.
Eg, I use the https://docs.rs/tracing/0.1.13/tracing/ crate (I know, different lang) and have had great success with having a reporter configured to log to stdout, and then another reporter configured to send traces to Jaeger and such.

You can always implement your own reporter that does that. I am skeptical of its value because trace data is pretty rich and structured, not really suited for stdout.

@yurishkuro I'm trying to find some docs on where the opentracing lib, or this lib, exposes a mechanism for implementing a reporter. If it is not documented that's fine, I don't mind diving into the code. Either way, I'll close this issue as you've resolved the misunderstanding on my end.
I will say, the docs are a bit deceptive though haha. It definitely seems as though logging a span would indeed log the contents of the span, not just the ID.
Regardless, thanks for the great work here!

https://pkg.go.dev/github.com/uber/jaeger-client-go?tab=doc#Reporter found it.


ServerFn validator not inferring inputs for consumers

Which project does this relate to?
Start
Describe the bug
When making a createServerFn() and using .validator() chain, types are inferred for the following .handler() call, but not for any consumers of the serverFn later on.
const dataSchema = z.object({
  foo: z.literal('bar'),
})

type DataType = z.infer<typeof dataSchema>

const zodDirect = createServerFn()
  .validator(dataSchema)
  .handler(({ data }) => data.foo) // type inference is fine here

const zodVerbose = createServerFn()
  .validator((d: unknown) => dataSchema.parse(d))
  .handler(({ data }) => data.foo) // type inference is fine here

const manual = createServerFn()
  .validator((d: unknown) => {
    if (typeof d !== 'object' || d === null)
      throw new Error('data must be an object')

    if (!('foo' in d)) throw new Error('data must have a foo property')

    if (d.foo !== 'bar') throw new Error('data.foo must be "bar"')

    return d as DataType
  })
  .handler(({ data }) => data.foo) // type inference is fine here

// @ts-expect-error
const r1 = zodDirect({ data: { bad: 42 } }) // incorrect input data, but no error thrown
//                       ^ 'unknown' type

// @ts-expect-error
const r2 = zodVerbose({ data: { bad: 42 } }) // incorrect input data

// @ts-expect-error
const r3 = manual({ data: { bad: 42 } }) // incorrect input data

Your Example Website or App
https://github.com/mckamyk/serverfn-no-inference
Steps to Reproduce the Bug or Issue

clone the repo
open editor to app/routes/index.tsx -or- run bun tsc, npm run tsc, etc.
the // @ts-expect-error statements trip tsc, because there are not errors by the invalid calls

Expected behavior
In this case,

bun tsc should result in no error`s
hovering over the data portion in zodDirect({ data: ... }) should have type hints, but it does not
Editors should get suggestion as to the keys of the data object inside the function call.

Screenshots or Videos

Platform

OS: macOS Sanoma 14.7
Browser: NA
Version: 1.82.6

Additional context
No response

@schiller-manuel

unfortunately for zod you need an adapter package to correctly infer input types
import { zodValidator } from "@tanstack/zod-adapter";

const dataSchema = zodValidator(z.object({
  foo: z.literal("bar"),
}));

then it works as expected

Still seems to be the case with the manual typing?
Copy-pasting the example from the docs for manual validation doesn't lead to inferred inputs.
export const greet = createServerFn({ method: 'GET' })
  .validator((person: unknown): Person => {
    if (typeof person !== 'object' || person === null) {
      throw new Error('Person must be an object')
    }

    if ('name' in person && typeof person.name !== 'string') {
      throw new Error('Person.name must be a string')
    }

    return person as Person
  })
  .handler(
    async ({
      data, // Person
    }) => {
      return `Hello, ${data.name}!`
    },
  )

function test() {
  greet({ data: { name: 'John' } }) // OK
  greet({ data: { name: 123 } }) // No error here
//        ^ unknown
}

The input type is specified as unknown currently. You would have to provide another, more narrow input type to get the error you expect.
Trivial one would be:
validator((person: Person): Person => {

I think I understand now.
validator's input type -> consumer's arg type
validator's output type -> .handler(...) arg type


Support custom RSS feed url

I am using RSS feed service to manage my rss subscription.
This allows user to add custom rss url to the header in config.

Thank you @imjm!


added initial .travis.yml

What is the purpose of this? We already have this: https://builds.apache.org/job/maven-plugins/

I don't know if there is some progress about pipeline/mutibranch/.... usage on builds.apache.org but we could setup jobs detections with Jenkinsfile if we want something automatic to reduce the maintenance

Perhaps Jenkinsfile or .travis.yml could be a good solution to build & link to SonarQube platform on each GitHub PR (even if git.apache.org fork) with GitHub plugin on SonarQube.com, to verify/improve quality of contributions ?


Metricbeat won't start

Problem description

Metricbeat won't start up due to an error in metricbeat.yml

Exiting: error initializing publisher: can not convert 'object' into 'string' accessing 'output.elasticsearch.password' (source:'metricbeat.yml')

I have run the setup to make sure all user/passwords were setup.

docker-elk-setup-1  | [+] Waiting for availability of Elasticsearch. This can take several minutes.
docker-elk-setup-1  |    ⠿ Elasticsearch is running
docker-elk-setup-1  | [+] Waiting for initialization of built-in users
docker-elk-setup-1  |    ⠿ Built-in users were initialized
docker-elk-setup-1  | [+] Role 'heartbeat_writer'
docker-elk-setup-1  |    ⠿ Creating/updating
docker-elk-setup-1  | [+] Role 'metricbeat_writer'
docker-elk-setup-1  |    ⠿ Creating/updating
docker-elk-setup-1  | [+] Role 'filebeat_writer'
docker-elk-setup-1  |    ⠿ Creating/updating
docker-elk-setup-1  | [+] Role 'logstash_writer'
docker-elk-setup-1  |    ⠿ Creating/updating
docker-elk-setup-1  | [+] User 'filebeat_internal'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'kibana_system'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'logstash_internal'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'heartbeat_internal'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'metricbeat_internal'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'monitoring_internal'
docker-elk-setup-1  |    ⠿ User exists, setting password
docker-elk-setup-1  | [+] User 'beats_system'
docker-elk-setup-1  |    ⠿ User exists, setting password

I have to hard code the passwords for the following users on metricbeat.yml for metricbeat container to start correctly.

monitoring_internal
metricbeat_internal

It looks like Metricbeat was started before the passwords were added to the .env file.
Now that you added them (and ran the setup to enable those users), the issue should disappear after recreating the metricbeat container:
docker-compose -f ... stop metricbeat
docker-compose -f ... rm metricbeat
docker-compose -f ... up

You didn't fill in the issue template. What versions of Docker and Compose are you running?
This is what we do in our automated tests:
https://github.com/deviantony/docker-elk/blob/c6978b0e996adccb40ab74c26e04218279b895fd/.github/workflows/ci.yml#L42-L69
The result, with Metricbeat starting without issue and sending data to Elasticsearch: https://github.com/deviantony/docker-elk/actions/runs/4874413077/jobs/8695300021

You didn't fill in the issue template. What versions of Docker and Compose are you running?

Here is my Docker version; compose is now a built-in command:

Client: Docker Engine - Community
Version:           24.0.1
API version:       1.43
Go version:        go1.20.4
Git commit:        6802122
Built:             Fri May 19 18:06:21 2023
OS/Arch:           linux/amd64
Context:           default
Server: Docker Engine - Community
Engine:
Version:          24.0.1
API version:      1.43 (minimum version 1.12)
Go version:       go1.20.4
Git commit:       463850e
Built:            Fri May 19 18:06:21 2023
OS/Arch:          linux/amd64
Experimental:     false
containerd:
Version:          1.6.21
GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
runc:
Version:          1.1.7
GitCommit:        v1.1.7-0-g860f061
docker-init:
Version:          0.19.0
GitCommit:        de40ad0

I wiped and reloaded the stack and it works now. Not sure where I went wrong before...anyways closing issue.

Glad it worked in the end!


Moved snyk to devDependencies

As part of the 0.9.14 release, the addition of snyk to the dependency tree really blows up the dependency list. Based on how it is used, I believe this dependency should be moved to the devDependencies section of the manifest as there are no runtime requirements for this package.

One of the dependencies of snyk requires Node 10.
<EMAIL_ADDRESS>still works with Node 8. Adding snyk broke this dependency.
It still won't work with Node 8, no matter if it is added to dependencies or devDependencies.

Came here after seeing snyk blow up our dependencies. snyk's isntallation docs say to install it with:

Install the Snyk utility using npm install -g snyk.

so, it definitely shouldn't be in dependencies

I suggest moving snyk to "optionalDependencies" section so we can choose to use "--no-optional" flag

Can we please merge this asap? We use fossa to checkout the licenses in our production dependencies and we are getting 17 warnings for GPL-only licenses that are introduced by node-vault -> snyk -> snyk-python-plugin

Moving snyk to devDependencies (instead of optionalDependencies) will result in the "prepublish", which runs after install, to break.
What the snyk-protect does: It runs after packages were installed an manually patches security issues (modifies source code) of unsecure versions inside npm_modules directory.
It makes more sense to remove snyk from dependencies altogether, and leave it's GitHub integration to get notifies of new updates.

I removed snyk completely for now.


Tag diff

Adding TagDiff
Why is this change required? What problem does it solve? Describe your changes in detail:
This is used to perform a diff of the tags in Stockroom and create a neat representation of the same.
If it fixes an open issue, please link to the issue here:
#9
Screenshots (if appropriate):
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Documentation update
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: hhsecond:x: jjmachanYou have signed the CLA already but the status is still pending? Let us recheck it.

Closing since inactive and since it has been stalled


@sofiaq2201 need help on the same error.

Hey, do we need to run flutter create bug in the app folder?

for the Execution failed for task ':app:generateDebugBuildConfig'. error which I saw you got resolved.

@ShivamSingh22
Please ask support questions on StackOverflow.
Closing from here.


test(arrow-ord): remove duplicate logic and make it easier to add tests

Rationale for this change
While working on #6911 and I started to write tests, I found out I just duplicated the logic, and it was messier, so cleaning up to make it easier to create new tests.
Background: all sort arrays test helper were given 2 vectors with native rust types (e.g. Vec<Option<bool>>), one for the input and the other for the expected output.
and the sort test helper convert it to the input and expected arrays to Arrow arrays (e.g. BooleanArray), and then call sort (or sort_limit depend on the input) and assert that the expected match the sorted.
this is done to help make the test simpler by just providing what the actual arrow array represent without messing with converting to arrow type.
the problem is that some Rust types can have multiple Arrow types, for example Vec<Option<Vec<u8>>> can be BinaryArray or LargeBinaryArray or FixedSizeBinaryArray or BinaryViewArray (same for lists and string).
in that case each sort helper function convert the input data to some of the arrow type (like FixedSizeBinaryArray) or to multiple arrow type (BinaryArray and LargeBinaryArray)
and then do the same as described above.
for the cases that fixed_length was provided it will test FixedSizeBinaryArray
The problem with this is that there are a lot of duplication and adding tests to new type is just adding a lot of boilerplate instead of just starting to write code
What changes are included in this PR?
So instead of this approach I created a single test_sort_array function that is given the input, expected  and a function to convert that rust input type (e.g.  Vec<Option<Vec<u8>>> like explained above) to all variants from that type (e.g. BinaryArray and LargeBinaryArray and FixedSizeBinaryArray and BinaryViewArray)
then created for each test type a new helper to convert that rust type to arrow type
for creating binary array I returned FixedSizeBinaryArray if all element have the same size, this will no allow to avoid only testing fixed or variable length types.
and moved all the build array helpers to sub module for more organize code.
But why do I pass a function to build the array and not using Rust trait system? this will surely be cleaner as you can have the actual function implementation hidden behind the input type and it would make the test cleaner.
You (basically my other self) are right. The problem is that I tried and it can't work without implementing for each primitive type manually (I think), because let's see the following example:
Let's say I have a trait called ConvertToArray
trait ConvertToArrays {
	fn convert_to_array(input: Vec<Option<Self>>) -> Vec<ArrayRef>;
}

and then I implement it for primitive type to create primitive array:
impl<T> ConvertToArrays for T::Native
	where T: ArrowPrimitiveType,
	PrimitiveArray<T>: From<Vec<Option<T::Native>>>
{
	fn convert_to_array(input: Vec<Option<Self>>) -> Vec<ArrayRef> {
		vec![Arc::new(PrimitiveArray::<T>::from(data)) as ArrayRef]
	}
}

all good and it works. the problem is I can't implement it for bool when I want to test sorting BooleanArray because ArrowPrimitiveType can be implemented in the future for bool and this would cause duplicate implementation. and for that reason Rust disallow that
Are there any user-facing changes?
nope, only tests

Thank you for these PRs @rluvaton  -- I know we are seriously behind on PR review in arrow-rs. I hope that we will have more capacity after next week. We just need to find more people willing to help out with reviews

I'm willing to help, although currently my codebase knowledge is not the greatest but I think it's getting better

I'm willing to help, although currently my codebase knowledge is not the greatest but I think it's getting better

Thank you 🙏  -- the most helpful thing would be to review outstanding PRs and ensure the description is understandable, the code is commented and covered with tests, and you think the code does what the description says
If you find such PRs, feel free to @ mention me and I'll try and give it a look asap


Add Resource Request: PsychOpen CAMA

What is the resource called?:
PsychOpen CAMA
What is the link to the resource?:
https://cama.psychopen.eu/
Please provide a short description of the resource (1-3 sentences):
PsychOpen CAMA enables accessing meta-analytic datasets, reproducing meta-analyses and dynamically updating evidence from new primary studies collaboratively.
Which step of the research cycle does the resource belong to?:
Study design
If possible, please provide the exact path where you want this resource to go?:
Open (i.e., everything in the resource is free and open to use)

Added


Allow for more than 3 dimensions in the bbox

The GeoJSON spec recommends 2 or 3 dimensions, but does not forbid geometries that have more.  See https://www.rfc-editor.org/rfc/rfc7946#section-3.1.1.
In addition, the bbox length is 2*n where n is the number of dimensions.  See https://www.rfc-editor.org/rfc/rfc7946#section-5.

See my comment at https://github.com/opengeospatial/geoparquet/pull/88#issuecomment-1320479016, we currently only allow 2D or 3D.
This description was added in https://github.com/opengeospatial/geoparquet/pull/45

Thanks for the clarification, @jorisvandenbossche.


Update from 3.5.0 to 3.5.1 fails

Describe the bug

Update from 3.5.0 to 3.5.1 fails on Android 7.1.1 and Android 9.0. I've seen this bug on two different mobiles and Android versions.
To Reproduce
Try to update via Play Store from 3.5.0 to 3.5.1.
Expected behavior
Update to 3.5.1.
Screenshots

Devices and Versions
Your Rocket.Chat.Android version: 3.5.0 -> 3.5.1
Mobile device model and OS version:  Aquaris X5 Plus, Android 7.1.1 and OnePlus 7 Pro, Android 9.0

@localguru  known problem.   You should see the bad image size of 8 MB.   Should be fixed shortly.  Thanks for the report.

@Sing-Li yes, 8 MB size. I deinstalled and reinstalled (~ 56 MB), that worked.

@localguru We're sorry for the inconvenience! We have introduced a break change that keeps the users unable to upgrade the app. The way to go is really uninstalling the app and downloading it again. The good news is that besides the bugs fixes and improvements we have done the app size is now much smaller than the older versions (from ˜60mb to up to 30MB now).
Thanks for your comprehension.

I'm still unable to update but the update size is not the same as the previous update which errored out. First showed about 8MB and this one is around 24MB. I can look at adb logs later maybe but I'd rather not have to reinstall the app in order to update it.


Regent: __demand(__index_launch) does not support non-interfering region access

My understanding is that __demand(__parallel) should work for loops over independent tasks, but I've been getting errors when I try to use it with reductions.
import "regent"

task reduce(value : int,
            sums  : region(ispace(int1d), int))
where
  reduces +(sums)
do
  for v = 1, value do
    sums[v % 5] += v
  end
end

task top_level()
  var values = region(ispace(int1d, 5), int)
  var sums = region(ispace(int1d, 5), int)
  fill(values, 8)
  fill(sums, 0)

  __demand(__parallel) -- loop optimization failed: argument 1 is not side-effect free
  for i in values.ispace do
    reduce(values[i], sums)
  end

  __demand(__parallel) -- works
  for i = 5, 10 do
    reduce(i, sums)
  end

  for i = 0, 5 do
    regentlib.c.printf("%d ", sums[i])
  end
  regentlib.c.printf("\n")
end

regentlib.start(top_level)

And the error message
...pos/legion/language/src/regent/optimize_index_launches.t:632: Errors reported during typechecking.
bug.rg:21: loop optimization failed: argument 1 is not side-effect free
    reduce(values[i], sums)
          ^

stack traceback:
	[C]: in function 'error'
	src/terralib.lua:388: in function 'finishandabortiferrors'
	/home/ellis/repos/legion/language/src/common/report.t:56: in function 'report_fail'
	...pos/legion/language/src/regent/optimize_index_launches.t:632: in function 'optimize_loop_body'
	...pos/legion/language/src/regent/optimize_index_launches.t:777: in function 'fn'
	src/asdl.lua:16: in function 'map'
	...pos/legion/language/src/regent/optimize_index_launches.t:847: in function 'block'
	...pos/legion/language/src/regent/optimize_index_launches.t:857: in function <...pos/legion/language/src/regent/optimize_index_launches.t:853>
	/home/ellis/repos/legion/language/src/regent/passes_hooks.t:41: in function 'optimize'
	/home/ellis/repos/legion/language/src/regent/passes.t:52: in function </home/ellis/repos/legion/language/src/regent/passes.t:48>
	bug.rg:13: in main chunk

It's complaining because you're accessing the region values inside the loop itself (i.e. values[i]). This is probably something the optimizer could accept because you're only accessing values, not passing it into the task.
In the mean time, you could pass values (or a subregion of values, if you're worried about that getting big) into the task instead of an individual element of the region.

I'm actually think it's better to discourage this since even if we support it, it would defeat the constant-time launch optimization which is important for scalability to extreme node counts. Since it hasn't come up recently I'm inclined to close this.


Use username instead of email to login

Hello,
I would like to use username instead of email on login page.
Can you give me an hand ?
Regards

Just remove type="email" and put type="text"
<input
    v-model="form.email"
    class="form-control form-input form-input-bordered w-full"
    :class="{ 'form-input-border-error': form.errors.has('email') }"
    id="email"
    type="text"
    name="email"
    autofocus=""
    required
  />

But then the name should also be unique.
I have also added a method to register pages in Nova.
I just have to write a readme for it....
There the login page is also edited.
https://www.youtube.com/watch?v=kVoYtmVgmOs

ref: https://github.com/laravel/nova-issues/discussions/3954

https://github.com/Muetze42/nova-assets-changer/blob/main/docs/register-page.md

A way to realize without changing Nova assets:
https://github.com/Muetze42/laravel-nova-example-projects/tree/feature/custom-login

@Muetze42 I am trying to adapt the custom login to my needs from the custom login from the example project that you provided but somehow it does not work without specifying the root like this Inertia::setRootView('app'); just before returning the view. It looks like its trying to load the Nova one because I can see [NOVA] Initiating Nova countdown... in the console. Any idea why is that? I downloaded your example project and it works.
I have gone through your commits that you suggest and done everything. I even have views/app.blade.php root file that inertia should choose it by default but without explicitly telling it it does not work


Issue while trying to convert markdown to Html ( with pipelines)

Hello,
I'm trying to convert some markdown to html using this code:
var pipeline = new MarkdownPipelineBuilder();
MarkdownPipeline markdownPipeline = pipeline.UseAdvancedExtensions().UsePipeTables().Build();
StringWriter tw = new StringWriter();
MarkdownObject doc = Markdown.ToHtml(markdown, tw, markdownPipeline);

After that i have to update links in the Markup from relative to absolute paths.
So, after that i'm trying to convert the MarkdownObject to string using this code:
var builder = new StringBuilder();
var textwriter = new StringWriter(builder);
var renderer = new HtmlRenderer(textwriter);
var t = renderer.Render(doc);
return builder.ToString();

so what?
Pipe Tables are parsed as paragraphs.
Some example:
| abc | def | ghi |
|---|---|---|
| 1 | 2 | 3 |

this markdown table is parsed as:

abc

def

ghi

1

2

3

However if i use this code everthing works (but i can't update links in an easy way)
string html = Markdown.ToHtml(markdown, markdownPipeline);
How can i convert this markdown?
Thank you so much.

Just look at ToHtml, likely you forgot to setup the renderer with the pipeline:
https://github.com/lunet-io/markdig/blob/ea99cd6115a0d1e48759214c27c4a5cfde37d02e/src/Markdig/Markdown.cs#L98-L105

Thank you so much!!
I forgot to setup the renderer with the pipeline, now it works correctly!


MacOS 10.13.6 command line, MacOS Keybase client, and Android 8.1 client Facebook Proof is unreachable

I've followed the steps numerous times to try to prove my Facebook account on Android, the Mac client, as well as the Mac command line. All fail with this message after making the public fb post:
Error 500. Something is not right. We will look into it.
I get that error on the https://keybase.io/_/facebook_post_redirect?sig_id_med=... url after making the fb post.
Link to public fb post here:  https://www.facebook.com/Pyrrhusignius/posts/2316997828329536
I let it go for a few hours and then got this in an email:
Hi, pyrrhusignius, your attempted facebook identity proof of pyrrhusignius never succeeded. We've been checking it repeatedly, and from our perspective, it's either (a) not there, or (b) not posted precisely.
In between each attempt, I would delete the previous fb post and remove the Keybase app from my fb account settings here:  https://www.facebook.com/settings?tab=applications

Exactly same issue here using Keybase client 2.10.0-20181115161429+c6828495b9 on macOS Mojave 10.14.1 with default browser being Chrome 70.0.3538.102.

Fixed! See comment https://github.com/keybase/client/issues/14537#issuecomment-435939898
I had to revoke the proof and try again after their fix and it fixed it for me.

No it's not fixed (as I also commented in the above linked issue. First time I ever tried this was yesterday and it did not work (even though the comment you linked to is from 11 days ago saying it was fixed then).

I tried revoking my FB proof multiple times and doing it again but still it doesn't work.

Ok sorry. This was an issue for me but last week when they said it was
fixed, I tried it again and it worked. I just forgot to close out my Github
issue here when it was resolved for me.
On Fri, Nov 16, 2018, 3:08 AM Kari Söderholm<EMAIL_ADDRESS>wrote:

I tried revoking my FB proof multiple times and doing it again but still
it doesn't work.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/14571#issuecomment-439345088,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJB837bTk2ROX9phaw1_4iBX0XG3hoc6ks5uvo6CgaJpZM4YNklI
.

Maybe it worked for a while but is broken again.

I just went and looked at my Keybase profile and even though my fb proof started working a week ago, it now says that my fb proof is unreachable.

If it's the Keybase server trying to verify the proofs, maybe they're hitting some FB limits and FB is blocking their requests?


Languaje issues - I want to have QGIS in English!!

Tools
Languaje issues - cannot get rid of user interface translation. I want my QGIS in English
Summary
Hello. I love QGIS, being used it from over 10 years now.
i´ve just developed the  3.34 version (I was still usin Pi). As I´m now in Spain, it´s recognized the area and self-instaled in Spanish. Thus, suddenly, I cannot properly follow the software. I´ve tried to changed it to English, unsuccessfully, in the "configuration/option" section. Well, that´s how I would translate it, how I read it is "Configuración/Opciones". There´s not an option for me to reject the user interface translation.   BTW, some of the sentences are in English there.
Thus, it seems I have to uninstall the software, connect to the UK via VPN, then download and install again. Not very handy..
Thanks!!!

@alicialedo, you need to report the issue to the QGIS Desktop/Server GitHub repository at https://github.com/qgis/QGIS/issues providing all the detailed info requested in the issue report form.

and before this, triple check. I had it work in 3.38 without any issue :

And to get there in English you can start QGIS from the command line with qgis -l en  (eg. from the OSGeo4W shell; perhaps qgis-ltr -l en depending on the version) and goto Settings/Options and set the override.

Great thanks! Yes, I had tried the override system before posting, but for an unknown reason didn´t work. that´s my problem.
In the end, I´ve just uninstall and re-install using a different VPN connection and that worked - Probably due to the new installation itself and not the VPN, but for whatever reason, it´s solved.
Thank you very much, really apreciated!!

On Fri, 27. Sep 2024 at 00:27:12 -0700, Alicia Ledo wrote:

Great thanks! Yes, I had tried the override system before posting, but for an
unknown reason didn´t work. that´s my problem.

In the end, I´ve just uninstall and re-install using a different VPN
connection and that worked - Probably due to the new installation itself and
not the VPN, but for whatever reason, it´s solved.

There are no language specific downloads.  The installer should be identical
no matter how you download it.
Jürgen
--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                 IRC: jef on Libera|OFTC
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/

yes, true. - I (wrongly) tried to explain that was the change in the IP location during installation (not downloading, you´re totally right) what might have worked. Connected from London, I had the QGIS in Eng. as I had wished, whereas with a local (Spanish) connection, I had it in Spanish and the "override system" did not work for an unknown reason.
cheers,


Promote to Known / Add Peer does not clear error message

Describe the bug
Error message from promote to known is not cleared in dialog.
To Reproduce
Clicked [Promote to known] on a existing unknown peer. Clicked on OK and received the error "Failed to promote peer forbidden"
Then copied the info and pasted into add peer dialog. The add peer dialog still had the Failed error message before I entered any info (attached screenshot)

Fixed in the dashboard https://github.com/iotaledger/node-dashboard/commit/cdb7bc1fc3abb819d28d8ce70edfda6a28e29122

Was fixed somewhere along the way :sweat_smile:


⚠ Bofrost.es has degraded performance

In 434aded, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1197 ms

Resolved: Bofrost.es performance has improved in a2f35f5 after 8 minutes.


Fix double exporting output pin

Thanks to @joltmode for original solution.
I have modified it a bit to use FileSystemInterface and fixed tests.

Hey - I'm really sorry for missing this.
This looks like a really good fix - I'm holding fire on merging this for the moment as I don't have time to properly review.
I'm looking for someone to maintain this repository and if I can't find someone I'll probably mark the repository is inactive and then provide instructions for users on how to run this bugfix in the README.

@svpernova09 rebased 😄

Thanks for the PR!


Disable binary metrics for continuous traits

e.g. Height + odds ratio -> weird empty plots
@remomomo I think only r2 and beta should be enabled for continuous traits, right?

Yes 👍 On Oct 6, 2023, at 15:12, Benjamin Wingfield @.***> wrote:
e.g. Height + odds ratio -> weird empty plots
@remomomo I think only r2 and beta should be enabled for continuous traits, right?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Replace /assign with Opening Draft Pull Request

I think it makes sense to only allow a bounty hunter to "call dibs" and assign themselves to a task when they open up a draft pull request. Reasoning below:

Bounty hunters will spend more time deducting how to self assign an issue via a draft PR compared to the straight /assign command.

We currently have the capability for the bot to respond with the help/tutorial message whenever the user writes their first comment on any new repository. Within this tutorial message we can simply explain that in order to be assigned to the bounty now, they must open a draft pull request and associate it with the issue.

most of the issues are assigned via the /assign command.

The reason why I am not a fan of this approach is because I've seen a handful of instances where bounty hunters will reserve a task (disincentivizing anybody else from working on it) and then proceeding to not start on the task at all.
If they have a pull request opened, they at least got started with the task which I anecdotally observed as having a higher completion rate.

Originally posted by @pavlovcik in https://github.com/ubiquity/ubiquity-dollar/issues/690#issuecomment-1607006170

Make sense. But how about this situation: 4 hunters open draft prs? assign whom?
And also, we need to think about this thing -> opening draft pr and doing nothing is same and /assign himself and doing nothing.

Make sense. But how about this situation: 4 hunters open draft prs? assign whom?

The chances of 2 hunters opening draft PRs in the same millisecond in the same repository is extremely unlikely.

opening draft pr and doing nothing is same as /assign himself and doing nothing.

If they have a pull request opened, they at least got started with the task which I anecdotally observed as having a higher completion rate.

/assign

@pavlovcik , Should we disable /assign command then?
only assign the bounty hunter when he opens a linked draft pull request?

Yes let's disable it and see how it goes.

Assigning bounty hunter when he opens a pr -> Seems this is already implemented.
https://github.com/ubiquity/ubiquibot/blob/48e006da17c46cc172263fe9a3924cd90a0f3bcb/src/handlers/assign/auto.ts#L7C1-L52C3
What we need to do is just disable /assign command.
What do you think?
@pavlovcik ?

Assigning bounty hunter when he opens a pr -> Seems this is already implemented.
https://github.com/ubiquity/ubiquibot/blob/48e006da17c46cc172263fe9a3924cd90a0f3bcb/src/handlers/assign/auto.ts#L7C1-L52C3
What we need to do is just disable /assign command. What do you think? @pavlovcik ?

I was thinking on this more during the weekend. I want to modify the specification actually to retain this feature if projects really want it, because it seems that some of us really like it (but I want to try an experiment without for a little while to measure performance differences.)

Let's make the default configuration option assign-command: boolean disabled for this
If it is disabled, it must be removed from the bot help menu for that repository.
If it is disabled, then leave the "open pr auto assign" capability (perhaps we can make a config for that in the future as well)

Sounds good @wannacfuture ?

Sounds great! @pavlovcik


Lots of flickering under Wayland on Nvidia

System Details

OS: Pop_OS 22.04, Gnome 42.9, Nvidia drivers 545.29.02
Thorium Version 117.0.5938.157

Problem
I am experiencing a lot of flickering (often windows behind the browser momentarily popping up over the browser window).  This especially happens when watching videos on YouTube, although it occassionally happens elsewhere, particularly when popping up dialogs (e.g., saving a file).  Also, dropdown menus initially appear blank, but if I move the mouse down over them, the menu text appears.
These issues are not occurring with  Chromium 119.0.6045.159,
Additional Notes
The problem seems to have gotten noticeably worse since upgrading my nvidia drivers to 29.02.  This may be a weird interaction between Thorium, Wayland/Gnome and the Nvidia driver.

System:
  Host: nobara Kernel: 6.5.9-201.fsync.fc38.x86_64 arch: x86_64 bits: 64
    compiler: gcc v: 2.39-15.fc38 Desktop: KDE Plasma v: 5.27.9 tk: Qt
    v: 5.15.11 wm: kwin_wayland dm: SDDM Distro: Nobara release 38 (Thirty
    Eight) base: RHEL 38
    Graphics:
  Device-1: NVIDIA TU104 [GeForce RTX 2080 SUPER] vendor: eVga.com.
    driver: nvidia v: 535.113.01 arch: Turing pcie: speed: 8 GT/s lanes: 16
    ports: active: none off: DP-2,HDMI-A-1 empty: DP-1,DP-3,Unknown-1
    bus-ID: 08:00.0 chip-ID: 10de:1e81

Similar issues on Fedora (Nobara) 38.

This may not just be a linux issue, it might be something with nvidia itself. I've had a similar issue for a while now where everything flickers. I'm on Win 11, and just resorted to running thorium via AMD iGPU

I am unsure what the NVidia control panel has for options on linux, but on windows following the suggestion mentioned https://github.com/Alex313031/Thorium-Win-AVX2/issues/112 in the AVX2 build worked to fix it on Win11
I suspect MFAA being enabled might be the cause as I had everything else they suggested already set

I'm no expert, but this issue reminds me of a problem with the chromium engine. Have you try to enable Wayland support in chrome://flags on the browser ?
Steps
1. Open a new tab in your browser

2. Enter **chrome://flags**

3. In the search bar type **wayland**

4. **Enable** WebRTC PipeWire support and Preferred Ozone platform if they aren't.

5. Restart your browser

Yes, this worked for me

I have the same issue in Google Chrome. E.g. in GMail, a page content is flickering when I'm scrolling. Also when I'm switching between browser tabs, very often the tab where I'm switching + its content isn't refreshed until I move mouse.
The issue doesn't happen in X11.
And never had such issue in Wayland with Ryzen (AMD) graphics.
A change from "Default" to "Auto" in the Chrome option "Preferred Ozone platform" helped me. Thanks @Thoutmose

My OS is Ubuntu 24.04 and graphics MSI RTX 4060 (nVidia), driver 550.107.02

I'm no expert, but this issue reminds me of a problem with the chromium engine. Have you try to enable Wayland support in chrome://flags on the browser ?
Steps

Open a new tab in your browser
Enter chrome://flags
In the search bar type wayland
Enable WebRTC PipeWire support and Preferred Ozone platform if they aren't.
Restart your browser

Is there some similar thing for Microsoft Edge ?

I have the same issue in Google Chrome. E.g. in GMail, a page content is flickering when I'm scrolling. Also when I'm switching between browser tabs, very often the tab where I'm switching + its content isn't refreshed until I move mouse.

I upgraded nVidia driver to the latest beta 560.35.03 and the issue has gone. So now it's working even without changing of the flags in Chrome.


Not Work with theantiadblocker.com

Hi.
Not work with this
https://theantiadblocker.com/

Thanks jpBenfica,
I think that now with version 1.5 it's already working against theantiadblocker.com


default oversampling parameter defined in multiple places, inconsistently

How oversampling of wavefronts in image planes is handled is defined in multiple places, and the default are not all the same. This may need to be rationalized a bit.

The Detector class has a default oversample=1.  This applies to the Detector object itself when created, and can be overridden when calling __init__.

The OpticalSystem class has a default oversample=2. This is applied to objects when added to the optical system, either a FITSOpticalElement added in addPupil, or an analytic optical element created from a function name inside addImage, or an empty image plane created via addImage, or a Detector added via a call to addDetector.  It is also passed to the Wavefront class's __init__ in inputWavefront().

The Wavefront class has its own default oversample=2, consistent with OpticalSystem.

The practical result of the above is that while Detector(npix=npix,pixelscale=pixelscale) creates a detector with oversample=1, on the other hand some_opt_sys.addDetector(npix=npix,pixelscale=pixelscale) creates a detector with oversample=2.
This seems like an inconsistency we should fix, but I'm not sure which of the defaults makes the most sense to change.
N.B. WebbPSF makes an explicit distinction between "detector oversampling" (affects final image planes created via MFT) versus "FFT oversampling" (affects intermediate image planes created via FFT, implemented via zero-padding of arrays prior to FFTs).  This distinction isn't formally maintained in POPPY - but maybe it should be?
Note also some of the above usage of oversample by OpticalSystem is vestigial. For instance passing oversample to FITSOpticalElement() does nothing. The sampling is set by the contents of the FITS file, and that parameter isn't even used.  So that should be cleaned up, and there may be other similar instances.

@josePhoenix , any opinion on this one?

(From #44)
From poppy.Instrument.calcPSF:
        Output sampling may be specified in one of two ways:

        1) Set `oversample=<number>`. This will use that oversampling factor beyond detector pixels
           for output images, and beyond Nyquist sampling for any FFTs to prior optical planes.
        2) set `detector_oversample=<number>` and `fft_oversample=<other_number>`. This syntax lets
           you specify distinct oversampling factors for intermediate and final planes.

        By default, both oversampling factors are set equal to 2.
....
        oversample, detector_oversample, fft_oversample : int
            How much to oversample. Default=4. By default the same factor is used for final output
            pixels and intermediate optical planes, but you may optionally use different factors

The default oversampling is set to 4 when using Instrument.calcPSF, but if you're using an OpticalSystem class directly it's 2. I think oversampling should required explicitly when using calcPSF on an OpticalSystem, and all the business of choosing defaults limited to the Instrument.calcPSF level.

I think we should try to eliminate the oversampling keyword argument defaults where ever we can, and handle it all in one place. Where that should be is unclear...

Refactoring this is definitely something we should leave for 0.4, not right now.
So as currently implemented here's how this works under the hood inside an OpticalSystem and Wavefront:

when propagating via FFTs, what matters is the Wavefront's oversample parameter. This has to be an attribute of the wavefront so it retains knowledge of how much zero-padding to add (or later to remove) from the wavefront arrays.
also when propagating via FFTs, it is asserted that the Wavefront's oversample attribute equals the target OpticalElement's oversample attribute.  There's no handling of the case where they don't agree; that would just raise an error.  (This also means there's no way to support having an OpticalSystem with different oversampling parameters for different optics, so it's not clear at all why it should be an OpticalElement attribute, and nowhere in optics.py does anything use this attribute. So it's clear that part could be removed)
when propagating via MFT to a detector plane, the Detector's oversample attribute is used when calculating the desired pixel sampling.

Then on top of that, there are some important differences between the two calcPSF functions, despite their overlap in name. Most significantly:

OpticalSystem.calcPSF takes an existing OpticalSystem (clearly enough!) and propagates a wavefront through it.
Instrument.calcPSF first constructs some appropriate OpticalSystem based on the instrument parameters, then propagates the wavefront through it.

So in the Instrument case it has to be set via function call because the optical system doesn't even exist beforehand, but in the OpticalSystem case it could go either way.
Come to think of it, maybe the right way to approach this all would be to have the oversampling be an attribute only of the wavefront itself? Which would probably need to gain the distinction between the FFT and MFT oversampling parameters but that could be OK.  That would make the OpticalSystem itself independent of the sampling used when propagating something through it.

So in https://github.com/mperrin/poppy/pull/55, it looks like you have made the oversampling an attribute of the opticalsystem, rather than something that's specified during the call to calcPSF?  Can you explain some of your reasoning for doing it that way?
It would seem more intuitive to me to say that an OpticalSystem is independent of a given oversampling factor, and given that OpticalSystem you could calculate multiple PSFs through it with different samplings, if so desired.

I think your intuition is right, and we should add an oversampling argument to calcPSF. I'm not sure that passing an oversampling factor to OpticalSystem.calcPSF actually did anything when I started working on that branch, though. It didn't raise an exception because there were **kwargs catch-all arguments in a few function signatures, but it didn't have any effect.
I removed the **kwargs catch-all from some function signatures and noticed that I broke some tests. The broken tests seemed to be specifying oversampling to OpticalSystem.calcPSF, but OpticalSystem.calcPSF didn't appear to be accessing this keyword argument.
So, while I agree with your reasoning for keeping it as an argument, I think that's not how it actually worked before. It looks like sampling was always determined from OpticalSystem.oversample (OpticalSystem.inputWavefront() seems to use it to set oversampling, and your description above seems to indicate there's no case to handle when an OpticalElement doesn't match that sampling.)

Right, I was more speaking about how it ought to work, not how it actually worked before.
Make it an input to calcPSF, which then gets handed to inputWavefront? Or inputs, rather, given the different FFT and MFT factors. Which I think are needed for enough cases of coronagraphic calculations that we need to preserve the functionality.

I like the idea of setting sampling on the Wavefront, actually. So we'd have oversample, fft_oversample, and mft_oversample keyword arguments to Instrument.calcPSF and OpticalSystem.calcPSF. In OpticalSystem.calcPSF, we'd implement the whole "use fft_oversample if given else oversample else some default value" logic.
OpticalElements wouldn't know about sampling unless they were FITS-based, in which case they'd check the incoming wavefront for compatible sampling during propagation. The only thing I can think of off the top of my head that would have to change is saving or displaying OpticalElements... we'd have to specify sampling there too, right?

I think all the logic might be able to go on the Wavefront class - all the heavy lifting is done in its various propagation methods rather than the OpticalElements. The OpticalElements just have to be capable of in getPhasor evaluating themselves on the sampling provided by the Wavefront.  calcPSF would just have to pass the keyword arguments along to the creation of the Wavefront.
I don't think anything would need to change in the saving or displaying of OpticalElements. For FITSOpticalElements the sampling is fixed already. For AnalyticOpticalElements, the display method of AnalyticOpticalElement already lets the calling function specify a number of pixels to discretize onto.  This could maybe be improved but as a first pass I don't think anything would be needed immediately.

Here is a rather complex older issue. Not sure if we want to look at this or not right now, but better sooner than later?

This issue is too complex to do anything about for right now.
I checked in the code and the defaults are all consistently at 2 right now, so that's at least one less potential stumbling block than originally back in January.
The SemiAnalyticCoronagraph and new MatrixFTCoronagraph classes add further complications, since they may want to heavily oversample the intermediate image plane more so than the final output planes.


Kafka fails on arm64

When deploying on arm64, the kafka pod fails with exec /tmp/start-node.sh: exec format error

@EinarArnason Hello, please describe your case in more detail. In which environment you tried to deploy the Kafka container? What deployment file did you use?


Add ui-components package

References
Fixes #124

Code changes
Add a new ui-components to expose the icon and wordmark.
TODO

[x] Bootstrap the package
[x] Replace the JupyterLab main logo plugin
[x] Replace the RetroLab main logo plugin
[x] Add doit task to copy the icons from the source in docs

User-facing changes

Backwards-incompatible changes
None

Add a new ui-components to expose the icon and wordmark.

They could then be used in #60 to implement the about dialog.

Very cool!
So it's kind of a gross dependency, but perhaps instead of copying them, we should svgo the assets as they are shipped? Keeping them in full editable form in inkscape in the docs feels good, but as release assets, they are pretty bloated.

So it's kind of a gross dependency, but perhaps instead of copying them, we should svgo the assets as they are shipped?

Sounds like it would be fine to optimize them with svgo yes. Also to automatically remove leading <?xml> tag which might cause some issues when using it with react in the about dialog.

using it with react in the about dialog.

Gross. Sounds like a react problem.

Another worry is all that other junk i left in the wordmark... if nobody's sad about the colors, etc. we can just stick with what we got, and dump all the other stuff. Though I did like the canary yellow.

Though the canary doesn't have a symbolic name in the jp-icon-colorN names...

Sorry, shoulda said i'll do some tweaks on here. While the icon is good (4kb) the wordmark is still 140kb... might need some more finesse to get it down. I'll go ahead an update with the yellow...

wordmark.svg:
Done in 102 ms!
35.574 KiB - 60.9% = 13.912 KiB

i don't like the outline on dark, trying the semantic themes...

Much better with jp-icon3 (lower is still too shouty):

No further changes planned, but happy for review!

Thanks!


update the AlmaLinux description.

@microsoft-github-policy-service agree company="AlmaLinux OS Foundation"


feat: Update to Vite v5 and Vitest v1

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (499db13) 87.92% compared to head (ad30724) 90.10%.
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6587      +/-   ##
==========================================
+ Coverage   87.92%   90.10%   +2.18%
==========================================
  Files          87        8      -79
  Lines        2931       91    -2840
  Branches      804        4     -800
==========================================
- Hits         2577       82    -2495
+ Misses        295        9     -286
+ Partials       59        0      -59

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


Change protocol types to use a param for the point type

Instead of relying on the Point type family, paramaterise the protocol
types over a point type paramater. We still choose to use the protocols
at the same types, using Point, but it lets us write protocols at other
types.
In particular in the cardano-api where we want to present the node's
client protocols in as simple a way as possible, we would like to use
specific a monomorphic type for ChainPoint, rather than the (somewhat
complicated) Point type family used by the network and consensus layer.
So by allowing the protocol types to be instantiated with this surface
type we can both present a simpler interface, and still map it down to
the underlying types used by the consensus and network layers.

Draft for now since it should be rebased after #2713 is merged. Also it there's a lot of small mechanical changes here. It might be easier to follow if I changed each protocol in separate commits. There's three protocols we're changing here.

bors merge

I would squash the fourth and fifth commit.

bors merge

(I have actually squashed the last commit too.)


Receipt Status Code

The receipt information that prints to the console has "Status { code: 22 }..."
the code should actually print what status code 22 stands for i.e. "Success" (https://github.com/hashgraph/hedera-sdk-js/blob/master/src/proto/ResponseCode.proto)
Simis-MacBook-Pro-2:JS SDK V1.1.0 simihunjan$ node transferCrypto.js
TransactionReceipt {
  status: Status { code: 22 },  //***Here is what I am referencing above***
  _accountId: null,
  _fileId: null,
  _contractId: null,
  _topicId: null,
  _exchangeRateSet:
   { currentRate:
      { hbarEquiv: 30000,
        centEquiv: 120000,
        expirationTime: 1970-01-19T07:06:39.600Z },
     nextRate:
      { hbarEquiv: 30000,
        centEquiv: 120000,
        expirationTime: 1970-01-19T07:06:39.600Z } } }
Simis-MacBook-Pro-2:JS SDK V1.1.0 simihunjan$

@SimiHunjan Can you share how you are printing the receipt?

Sure - it was the transfer-crypto.js example (https://github.com/hashgraph/hedera-sdk-js/blob/master/examples/transfer-crypto.js)
const { Client, CryptoTransferTransaction } = require("@hashgraph/sdk");
require("dotenv").config();

async function main() {
    const operatorPrivateKey = process.env.OPERATOR_KEY;
    const operatorAccount = process.env.OPERATOR_ID;

    if (operatorPrivateKey == null || operatorAccount == null) {
        throw new Error("environment variables OPERATOR_KEY and OPERATOR_ID must be present");
    }

    const client = Client.forTestnet();

    client.setOperator(operatorAccount, operatorPrivateKey);

    const receipt = await (await new CryptoTransferTransaction()
        .addSender(operatorAccount, 1)
        .addRecipient("0.0.3", 1)
        .setTransactionMemo("sdk example")
        .execute(client))
        .getReceipt(client);

    console.log(receipt);
}

main();

@SimiHunjan Merged a fix to master to help clean that up. Running the example now prints:
❯ node transfer-crypto.js
{
  "status": "SUCCESS"
}

Running the create account example ( I added a console.log(receipt) call )
❯ node create-account.js
receipt = {
  "status": "SUCCESS",
  "accountId": "0.0.168512"
}
accountId = 0.0.168512


Implement functional tests for listObjectParts()

Current cover profile is 55% for api-list.go

@harshavardhana is this issue still valid?

Closing this..


3.0release

Codecov Report

Merging #2537 (6951ec5) into 3.0release (2431e0b) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           3.0release    #2537   +/-   ##
===========================================
  Coverage       52.33%   52.33%
===========================================
  Files              84       84
  Lines           26940    26940
===========================================
  Hits            14098    14098
  Misses          12842    12842

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2431e0b...6951ec5. Read the comment docs.


Update deploy-4x.yml

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 91.069%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
11836

Relevant Lines:
12493

💛  - Coveralls


Launching Minecraft

As mentioned in #2, we must have a way of launching Minecraft. Various versions are supported via Spigot launcher and similar, but reverse-engineering of the launch procedure itself could also be sourced as a means of determining what must be done. So, summarily, how do we launch Minecraft?

Some of the launching process can be seen within https://github.com/TechnicPack/MinecraftCore/blob/master/src/main/java/net/technicpack/minecraftcore/launch/MinecraftLauncher.java, where the Technic Launcher feeds in parameters to create a game process.

A lot of information seems to be available at http://wiki.vg/Game_Files, with specific URLs to follow and other useful utilities. Importantly, the same wiki also carries a programmatic means of launching Minecraft.

I have added some basic DTOs derived from the linked wiki's information in 0af5c561c054055dee9a035e1be8e3ec30455cff. I have also added basic asynchronous extensions for IServiceClient to allow more modern usage of NServiceKit's ServiceClient implementations.

Elimination of NServiceKit's ServiceClient in favor of HttpWebRequest and creation of internal classes which more-effectively represent the data the DTOs have transferred are next in line for implementation.

The previously mentioned internal representations of the data to be transferred have been solidified as the only used representation for these types. Anything else feeds through serialization via Json.Net as of the closing of #13.

Minecraft client now launches as of c89974f99653f3bbb0eecb63395d7c2e72e6739b!
Server remains, then adaptation to allow Forge to launch as well begins.

Minecraft server and client can both launch, including automatic EULA creation after prompting the user for first-launch / newly-installed servers.


add validation for page_no

invalid literal for int() with base 10. at packages/search?type=deb&name=&page=/
So I add the correct validation to it.

I couldn't find any previous test for view so a create view_test.py .


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 1968 ms

Resolved: Bofrost.be performance has improved in 6504e09.