emscripten: Upgrade emsdk to 3.1.68

In line with commit https://github.com/rust-lang/rust/commit/2c38ecfc9077000db7de14bf501fa5294eeecedd.
While we're here, make the changes in commit 63b0d673eaf2a177ff208c5c50999738bdd1bf0d unconditional, which means that Emscripten 3.1.42 (released at 2023/06/23) is the minimum required version for Rust, assuming no breaking ABI changes occurred after that version.
Resolves: #3306.
Supersedes: #3569.
Cherry-picks a couple of changes from: #3307.

Thanks @kleisauke it would be nice to see time_t finally get fixed...

Could/should this PR keep the emcc version check to give a nice error at build time if a now-no-longer supported Emscripten is used?

I wouldn't want rust to generate an error when building with Emscripten 3.1.58 since that is the version that Pyodide is using with Python 3.12 and it would prevent us from upgrading. Though I suppose that it would just require us to use a patched rust/libc and we are already doing that, it would be nice to avoid additional patches.

But having a version check would be fine as long as there is an override.

I was thinking about the previous check for 3.1.42 when the ABI change happened, which previous libc versions still supported (now there would be an ABI break in the opposite direction).
I definitely agree that other than that pretty much any emcc version has to be allowed since there is no current indicator which versions are ABI compatible and which aren’t

How backwards compatible is emsdk? I think putting this on the 0.2 stable branch should be okay, but would like to know if there is any expected breakage here.

Updated now that PR https://github.com/rust-lang/rust/pull/131533 was landed. This is ready for review.

How backwards compatible is emsdk?

AFAIK, there were no ABI-breaking changes after Emscripten 3.1.42 (released at 2023/06/23), which was addressed in libc by commit 63b0d673eaf2a177ff208c5c50999738bdd1bf0d (but only when building with -Zbuild-std).

Could/should this PR keep the emcc version check to give a nice error at build time if a now-no-longer supported Emscripten is used?

I could address this within a follow-up PR, but perhaps its severity should be a warning instead? Simple programs that don't use filesystem operations will likely still work with Emscripten versions prior to 3.1.42. On the other hand, Emscripten 3.1.42 is already more than a year old.

AFAIK, there were no ABI-breaking changes after Emscripten 3.1.42

@kleisauke it would be really great if we could make some sort of tool to do ABI compatibility checks. For a static test, we could compare the contents of emscripten/src/struct_info_generated.json. Perhaps we could use emscripten/tools/maint/gen_struct_info.py to generate info about the layout of more standard library structs than just the ones that are in the default struct_info. For a dynamic test, maybe take the unistd test suite and build the tests as side modules with one emcc version then load them and call into them with a second emcc version.
This probably wouldn't be perfect, but it would be a lot better than the current method where we don't really know anything.

:umbrella: The latest upstream changes (presumably #3993) made this pull request unmergeable. Please resolve the merge conflicts.

I don't have any major concerns here but I'll defer to @hoodmane's review (I'll merge once you give it the checkmark)

One last thing: could you add the following section to README.md after "Rust version support" so we have this noted somewhere? I wanted to document everything we interface with at some point, might as well start here.
## Interface version support

`libc` targets being able to interface with the following minimum library
versions:

- Emscripten 3.1.42, released 2023-06-23

@rustbot ready

One last thing: could you add the following section to README.md after "Rust version support" so we have this noted somewhere? [...]

I think this should be done as a follow-up given that this PR does not raise the minimum Emscripten version (at least when building with -Zbuild-std), see:
https://github.com/rust-lang/libc/pull/3962#discussion_r1832494361


Inconsistent handling in QdrantVectorDbClient results in copilot-sample-app to fail when qdrant is used for Memories

Describe the bug
When MemoriesStore is set to qdrant, copilot-sample-app is non-functional due to handling of ISemanticTextMemory.SearchAsync when existing results are not found.  SearchAsync returns an IAsyncEnumerable object but will throw if a result is not found in the underlying source in all places where response.EnsureSuccessStatusCode() is not being implicitly caught.
Currently, for copilot-sample-app, it is impacted due to the Qdrant Skill as seen in this list below where this response method is used.

There is an inconsistency across QdrantVectorDbClient source for how response.EnsureSuccessStatusCode() is handled when performing a search.  Here is an example where it's being caught and tracing "not found" which I believe is the ideal way to handle this provided a collection is returned.  GOOD

SearchAsync() for Qdrant uses FindNearestInCollectionAsync() to return back a collection.  In the example below, there isn't the same try/catch handling and just below, you'll see a check for Any().  The code inside that block is unreachable as if there were not any results returned, response.EnsureSuccessStatusCode() would throw.    BAD

For the interim, I changed the semantics around how SearchAsync() is used in copilot-sample-app similar to below where its catching when SearchAsync() throws having a 404 not found.

The current handling in copilot-sample-app assumes SearchAsync() will not throw.  Because it does throw, it bubbles itself all the way up and fails the completion which resulted in this skill to be executed.  I believe this handling below is correct so long as we correctly ensure that SearchAsync()  will not throw if results are not found like the other operations in that class.

The ideal change that should occur, in my opinion, is to make the handling in QdrantVectorDbClient consistent when performing a search by adding the try/catch semantics to FindNearestInCollectionAsync() to match each other search operation which does the same.  This would mitigate the issues observed in the copilot-sample-app.
Looking at the definition for the method in question, there doesn't appear to be any intent to throw when a search doesn't return any results.  As mentioned above, other cases of vector search in the same class which return the same collection are explicit in catching to make sure an exception is not thrown.

The risk with this change would mean any consumers who are using qdrant and working around this issue by explicitly catching a 404 error as opposed to simply checking if the object has any results would need to update handling by switching from using a try/catch to checking if the collection returned has any results.  This is in line with all other search capabilities in this class.
If its thought that we should not make this handling consistent in the way described above, I would then propose that we add tags to the method to indicate the exception thrown and accept a pull request to convert copilot-sample-app handling to use the try/catch method I showed above as today its attempting to check if the resulting collection has Any().
Aside from any added tests, the change itself would amount to 4-5 lines, and also resolves current failures in copilot-sample-app when using qdrant.
I would like to submit a pull request to resolve this issue.
To Reproduce
Steps to reproduce the behavior:

Apply settings as specified in README for copilot-sample-app.
Change MemoriesStore in webapi appsettings.json from "volatile" to "qdrant".
dotnet run in webapi folder and yarn start in webapp folder.
Send a prompt in the web UI..
Observe Error in web UI.

Expected behavior
When a result isn't found in the vector database, it should create a new collection, and not result in an overall failure.
Desktop (please complete the following information):

OS: Windows 11
IDE:  [VS Code]

@cchighman , thanks for finding this.  @adrianwyatt  is this the PR you are working on to fix this issue?

@cchighman , thanks for finding this. @adrianwyatt is this the PR you are working on to fix this issue?

Sure thing.  Let me know if there is an opportunity here where I could make a contribution.  Very interested in getting involved.

If @adrianwyatt hasn't already covered this scenario, it's trivial change to make. I notice we dont have any unit tests for QdrantVectorDBClient either.  I'm open to add some to sweeten the deal.    :)

It looks like @adrianwyatt's commit is targeting behavior from IAsyncEnumerators when yielding that's not supported based on a documented upstream issue which is different from the behavior outlined above that occurs when an exception is thrown that's not expected.


Example jupyter notebook fails during estimation

Hello, when executing the simple notebook's steps, estimation fails with the following backtrace:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/lustre/t1/cl/lsst/tmp/henrique.almeida/miniconda3/lib/python3.11/site-packages/rail/estimation/estimator.py", line 97, in estimate
    self.run()
  File "/lustre/t1/cl/lsst/tmp/henrique.almeida/miniconda3/lib/python3.11/site-packages/rail/estimation/estimator.py", line 110, in run
    self._process_chunk(s, e, test_data, first)
  File "/lustre/t1/cl/lsst/tmp/henrique.almeida/miniconda3/lib/python3.11/site-packages/rail/estimation/algos/lephare.py", line 208, in _process_chunk
    output, pdfs, zgrid = lp.process(lp.string_dict_to_keymap(self.lephare_config), input, offsets=offsets)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lustre/t1/cl/lsst/tmp/henrique.almeida/miniconda3/lib/python3.11/site-packages/lephare/process.py", line 91, in process
    output = photz.build_output_tables(photozlist, para_out=None, filename=filename)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lustre/t1/cl/lsst/tmp/henrique.almeida/miniconda3/lib/python3.11/site-packages/lephare/_photoz.py", line 38, in build_output_tables
    outkeys = readOutKeywords(self.outpara) if para_out is None else readOutKeywords(para_out)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: Incorrect setting for PARA_OUT: can't open output parameter file /lustre/t1/cl/lsst/tmp/henrique.almeida/slurm-home/var/cache/lephare/data/examples/output.para

Script was executed line by line in a python REPL shell.
Before submitting
Please check the following:

[x] I have described the situation in which the bug arose, including what code was executed, information about my environment, and any applicable data others will need to reproduce the problem.
[x] I have included available evidence of the unexpected behavior (including error messages, screenshots, and/or plots) as well as a descriprion of what I expected instead.
[x] If I have a solution in mind, I have provided an explanation and/or pseudocode and/or task list.

Hi, thanks for this. We have a quick fix that we will implement in lephare now. If you want to move on you can put the file in place manually getting it from here:
https://github.com/lephare-photoz/lephare-data/blob/main/examples/output.para

you could also run this line to put it in place while we wait for the change to lephare to propagate.
lp.data_retrieval.get_auxiliary_data(keymap=lephare_config, additional_files=["examples/output.para"])

This should have been fixed by https://github.com/lephare-photoz/lephare/pull/146
I'll wait to check this is working as planned after the pypi has updated...

Hello, I've repeated the tests using the up-to-date main branches with a clean cache directory, it's working now, thank you.

Great! Thanks again.


Open Source Development Metrics

Can we look into using a tool like Grimoire Lab to help us assess the health of our community?

This looks really interesting.  Do you have familiarity in setting it up and using it ?
Matt Hogstrom
<EMAIL_ADDRESS>+1-919-656-0564
PGP Key: 0x90ECB270
Facebook https://facebook.com/matt.hogstrom  LinkedIn https://linkedin/in/mhogstrom  Twitter https://twitter.com/hogstrom
“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

On Aug 19, 2018, at 9:34 PM, Tbr00ksy<EMAIL_ADDRESS>wrote:
Can we look into using a tool like Grimoire Lab https://chaoss.community/software/ to help us assess the health of our community?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/zowe/zlc/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/ACxXp6ie6tEr3AVJA1wnJSxl0u6SJGTEks5uShIMgaJpZM4WDN-0.

Any owners for this one ?  If not, I'd like to archive this and address when it comes up again.

We have a Grimoire Lab service launched. Please contact me or Tim Brooks for details if you want to reach the data.

Grimoire Lab default configuration is too aggressive and caused 2 issues:

consumed GitHub API calls too fast and reached quota limitation, which blocks others to make GitHub API calls,
the default logging is DEBUG level and used 20G per day for logging.

The service is temporarily shutdown until I figure out a way to configure it.

Two things here...

Would it make sense to use this ticket to align on the metrics of interest to the project?
Once that is aligned, I'd suggest having a service offering through Bitgeria that would we could manage here. This would free up the current team which is likely quite busy in pulling the releases together.

Thoughts?

The team at Bitergia put together a quick dashboard for review at http://cauldron.io/dashboards/zowe. Hopefully this gives the group a good idea of what's possible, and they are able to add into Slack and the mailing lists ( potentially also downloads of the binary ) to complete things out if folks are generally happy with the solution.

Closing ... as issues that require ZLC awareness arise new issues will be opened.


Fix the 'creatematrix' shader default output value.

The 'nodedef' elements for the ND_creatematrix_vector3_matrix44 and ND_creatematrix_vector4_matrix44 shader definitions have a typo in their default value for the "out" output. The last vector currently is (1,0,0,0) but should be (0,0,0,1), to form an identity matrix. This pull request fixes that.
P.S. this is pull request for the dev_1.39 branch.

Sorry, wrong destination branch was selected. Closing this pull request, as incorrect.


Error thrown when closing untitled query editor with connection

New query
Connect to and run query
Close query editor

Error shows up in console

This appears to repro in both stable 1.34 and insiders.

This is intentional and not an error - see https://github.com/microsoft/azuredatastudio/pull/17278
@alanrenmsft Do you want to keep this open and keep punting it milestone to milestone so we don't forget to clean this up down the line?
Alternatively if we could find some way to log this that doesn't look like an error that would be great. Even doing something like filtering out the "call stack: Error" text would be nice.


chruby inside Docker - different shell approach needed?

I'm attempting to build a Dockerfile with multiple versions of Ruby to allow dynamic switching, but I think I'm hitting a shell interactivity problem.
Dockerfile:
FROM renovate/base

USER root

RUN apt-get update && apt-get install -y build-essential

RUN cd /tmp && \
  curl -L https://github.com/postmodern/ruby-install/archive/v0.7.0.tar.gz > ruby-install-0.7.0.tar.gz && \
  tar -xzvf ruby-install-0.7.0.tar.gz && \
  cd ruby-install-0.7.0/ && \
  make install

RUN ruby-install ruby

RUN chmod -R a+rw /usr

USER ubuntu

RUN cd /tmp && curl -L https://github.com/postmodern/chruby/archive/v0.3.9.tar.gz > chruby-0.3.9.tar.gz && \
  tar -xzvf chruby-0.3.9.tar.gz && \
  cd chruby-0.3.9/ && \
  make install

RUN echo "source /usr/local/share/chruby/chruby.sh" >> ~/.bashrc

Logs:
~/github/docker-bundler master*
❯ docker run --rm -it renovate/bundler chruby
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"chruby\": executable file not found in $PATH": unknown.

~/github/docker-bundler master*
❯ docker run --rm -it renovate/bundler bash -l -c chruby
bash: chruby: command not found

~/github/docker-bundler master*
❯ docker run --rm -it renovate/bundler bash
ubuntu@fbbaebe9ed05:/$ chruby
   ruby-2.6.0
ubuntu@fbbaebe9ed05:/$

As you can see, chruby runs once I explicitly run a bash session, but it doesn't run when called directly or even indirectly via bash. I guess it's something to do with aliases and shell interactivity?
Any help would be appreciated.

Hi @rarkins!  In this case, you'd want an interactive shell as opposed to a login shell.  This should do the trick:
docker run --rm -it renovate/bundler bash -i -c chruby

Thanks!


Fix edit obs bug, remaining link_with_query calls

The problem is in the edit page tabs “Cancel and show observation”, I missed one (actually two) when correcting for the new link_with_query syntax.
I changed link_with_query so it takes exactly the same signature as link_to; that means that if the link destination is a hash of args (rather than a path builder like observations_path) it needs to be sent as a hash proper, not implicit.
So, in the case of this bug: The “return to obs” tab on edit obs was being built with
link_with_query(:cancel_and_show.t(type: :observation),
                action: :show, id: @observation.id)

Note that action: and id: are not part of a hash. We could put brackets around them, but the better fix is just to send @observation.show_link_args, which is a hash.
There was only one other instance of link_with_query still built with separate controller args, in collection numbers. Also fixed here.
In link_with_query now, as with link_to, only the html options are implicitly scooped up as a hash. This allows you to write
link_with_query(:cancel_and_show.t(type: :observation),
                @observation.show_link_args, class: "text-danger")

The change was done to allow us to pass a block to link_with_query, which is essential for using icons.
link_with_query(:cancel_and_show.t(type: :observation),
                @observation.show_link_args, class: "text-danger") do
  [
    icon(args),
    text.l
  ].safe_join
end

Coverage: 93.669%. Remained the same when pulling 9f53efe7edc139fb38b4dd96cdc84a1b41ffed37 on nimmo-active-menu-items into e39d5fa4532efbc6bacf00369f60f6c0d4df743d on main.


How to automatically close active fired alerts once the issue is resolved?

We have the option called automatically resolve alerts for Metric Alerts. Is there anything similar for automatically closing the activity log alerts once the issue is resolved?

@rahul-subash Let me look into this and come back to you

Hi @rahul-subash I've liaised with the product group owners of these features and in short there is no ability for activity logs to automatically close these events as these need to be treated a little differently from metric alerts as activity log alerts are point in time alerts that if triggered need a response to acknowledge. I am advised there may be plans in future to address this but nothing confirmed yet.
Would love to understand your impact on your current situation of not being able to automatically resolve, my challenge back however, would be if you wish to automatically close the alert what is the value of the alert being triggered?

@rahul-subash I have raised this with the appropriate product group but this unfortunately in the short term will not be addressed.
we're archiving this repo, please could you add an issue on our new repo https://github.com/Azure/azure-monitor-baseline-alerts/issues as we unfortunately cannot transfer issues between repos and this will allow for you to get notifications and would welcome your impact as per above to help support the ask.


Update visual identity

Fixes #24

Codecov Report

Merging #136 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #136   +/-   ##
=======================================
  Coverage   99.72%   99.72%
=======================================
  Files          19       19
  Lines         739      739
  Branches       61       61
=======================================
  Hits          737      737
  Misses          1        1
  Partials        1        1

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 f9db72c...45d8098. Read the comment docs.


feat: sort card view by Alphabetical, Recently Modified, and Least Recently Modified

SUMMARY

sort card view by Alphabetical, Recently Modified, and Least Recently Modified

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

WIP
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #10601 into master will increase coverage by 4.18%.
The diff coverage is 96.96%.

@@            Coverage Diff             @@
##           master   #10601      +/-   ##
==========================================
+ Coverage   60.10%   64.28%   +4.18%
==========================================
  Files         775      776       +1
  Lines       36528    36559      +31
  Branches     3459     3464       +5
==========================================
+ Hits        21955    23503    +1548
+ Misses      14382    12944    -1438
+ Partials      191      112      -79

Flag
Coverage Δ

#cypress
54.13% <ø> (?)

#javascript
60.62% <96.96%> (+0.14%)
:arrow_up:

#python
59.86% <ø> (-0.02%)
:arrow_down:

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

Impacted Files
Coverage Δ

...rontend/src/components/ListView/CardSortSelect.tsx
95.65% <95.65%> (ø)

...erset-frontend/src/components/ListView/Filters.tsx
90.90% <100.00%> (-0.27%)
:arrow_down:

...rset-frontend/src/components/ListView/ListView.tsx
95.29% <100.00%> (+0.17%)
:arrow_up:

superset-frontend/src/components/ListView/utils.ts
75.00% <100.00%> (ø)

...perset-frontend/src/views/CRUD/chart/ChartList.tsx
76.02% <100.00%> (+3.61%)
:arrow_up:

...rontend/src/views/CRUD/dashboard/DashboardList.tsx
73.64% <100.00%> (+3.58%)
:arrow_up:

superset/db_engine_specs/presto.py
82.02% <0.00%> (-0.68%)
:arrow_down:

...src/components/FilterableTable/FilterableTable.tsx
81.77% <0.00%> (-0.41%)
:arrow_down:

... and 147 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 db88cec...b354a4a. Read the comment docs.

Impacts #8976


STM32: Add PWM support

Here is a first-cut at implementing PWM support for STM32 targets via the TIM peripherals. Currently this only contains pin configuration for the STM32G0 but it would be straightforward to extend to other platforms.

If it matters my https://github.com/embassy-rs/embassy/pull/455 just merged with a SequencePwm type (which you dont need to support), but that ended up renaming pwm to SimplePwm though @huntc isnt in love with that naming. It seems whatever name is decided on to have a constant name for the duty cycle style pwms that consistent with the e-h pwm trait whatever we choose...

bors r+

Thanks for finishing this, @Dirbaio !


[Feature Request] 数字进制转换工具

Checklist

[X] I searched exising issues and no one else requests similar feature.
[X] I think that 25%+ users are positive towards this feature.

Describe the feature
十进制，16，2，8进制之间的转换
Additional context
No response

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

https://tool.lu/hexconvert/


leaflet.label compiling only onclick

Hello,
First, thanks for this awesome directive !
I'm running something strange and i cannot find a solution.
I'm running angular-leaflet in a MEAN stack app and everything work perfectly.
I have 4 markers with option "getMessageScope: function() {return $scope; }," to let me use a ng-click directive in popup and its ok. by default, focus is set on false.
I want also have a leaflet.label with "nohide:true" and a custom class on the right of the marker and bind some content in the label.
Problem is, on page load, my labels are visible but the data content seems to be binded only when i click on the marker... Il i want it to be compiled on page load, i have to set my popup option focus to true. and i don't want that.
I want my popup hidden by default and my label visible with data binding by deflault...can someone knows how can i solve this ?
 m4: {
                        lat: 48.180913,
                        lng: 6.445758,
                         message: '<button style="width:100%" class=\'btn btn-tech\' ng-click="createAlert(\'input\')">Clic me ! </button>',
		    			getMessageScope: function() {return $scope; },
                        focus: false,
                        icon: local_icons.myicon,
                        label: {
                            message: '

',
                            options: {
                                noHide: true,
                                className : "customClass"
                            }
                        }
                    },

I have fixed this in the master (it's not in the release yet). Check that out, you can also now use:
getLabelScope: function() { return $scope }

Thanks a lot, you're my hero !!! ^^
I'll try this and let you know.

this is probably related to #657 as well, but I notice that when using Leaflet.markercluster the $compile call in _manageOpenLabel will often be called when there is no marker.label._container if a marker is part of a cluster. In this case the message is never successfully compiled, and when the marker is revealed any binding is not functional.

@nickolas1 I have looked at your plunkr and have used the current dist that has my changes to the labels in.
It appears to function better, as in the labels are actually being compiled atleast. However I can see if you do click on a marker within a cluster the label is not compiled.
I will be using some of this functionality so I will more than likely have to fix it.

@jessertaylor , update :
awesome !!! works perfect, tested with last commit version ! Thanks a lot !
markers: {

                    m2: {
                        lat: 49.120359,
                        lng: 6.173937,
                        message: 'goooood',
		    			getMessageScope: function() {return $scope; },
		    			getLabelScope: function() { return $scope },
                        focus: false,
                        // icon: local_icons.metz,
                        label: {
                            message: '<button ng-click="var2 = var2 + 1">Say Hello</button>',
                            options: {
                                noHide: true,
                                className : "class1"
                            }

                        }
                    },
                    m3: {
                        lat: 49.358059,
                        lng: 6.167519,
                        message: 'gooood',
		    			getMessageScope: function() {return $scope; },
		    			getLabelScope: function() { return $scope },
                        focus: false,
                        // icon: local_icons.thionville,
                        label: {
                            message: '{{var2}}',
                            options: {
                                noHide: true,
                                className : "class2"
                            },
                        }
                    }
                }

@lleoooell
that great. @nmccready did some work on it aswell, team effort!

This is resolved right?

@nmccready Yes

@jessertaylor
Thanks for the fix. Label picks up scope data only if it noHide is set to true. This issue still exists if noHide is set to false. On mouse over, label doesn't have compiled data.

@durga-telsiz please could you provide an example / plunkr using master? Thanks

This issue was moved to angular-ui/ui-leaflet#149

I'm going to rework&redesign angular-leaflet-directive to be compatible with Leaflet v1.0. It will mantain almost all its functionality, and will be compatible with the current features of the directive, but I must start from a fresh point, so I'm going to close this issue. If you think it must be worked with the new version, please reopen it.


feat: #202 Expose L2 distance to Rust

Expose the L2 (Euclidean) distance bindings to Rust

Thanks, @GoWind! Will merge tomorrow 🤗


chore(env): use node 8 / npm 5 / styled-components 2 / storybook 3

Deploy preview ready!
Built with commit 8d2b49638c431c01cf869341897a0711f72698fd
https://deploy-preview-22--react-progressive-bg-image.netlify.com


Add back build_image keyword arg for create_build()

This is needed for allowing e.g. the koji-containerbuild plugin to set the build_image.

Can't koji-containerbuild pass it to Configuration object like this? https://github.com/release-engineering/koji-containerbuild/blob/master/koji_containerbuild/plugins/builder_containerbuild.py#L336
The configuration is getting a bit messy ...

Oh... right. I got lost in the code. Thanks for pointing out that way of doing it.


Skip wait nodes during master provisioning

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

LGTM


Allow multi provider or custom icons

Allow multi provider of icons or custom icons

fixed on v1.0.9


fix: remove redundant about title

This PR fixes #106
Changes

Removed redundant title from About us Markdown
Changed About => About Us

Current

After Fix

Yes, check the contact page also!


(Almost) same hidden variables for all nodes

❓ Questions & Help
Hi. I'm using a simple message passing network while the graph is complete. I will get the same feature vector for all nodes after the propagation part, is it because of the complete graph or something else?
class GCNConv(MessagePassing):
    def __init__(self, in_channels, out_channels):
        super(GCNConv, self).__init__(aggr='mean')  # "Add" aggregation.
        self.message_func = Seq(Linear(2*in_channels, out_channels),
                                ReLU(),
                                Linear(out_channels, out_channels),
                                ReLU())

        self.lin = Linear(in_channels, out_channels)

    def forward(self, x, edge_index):
        edge_index = add_self_loops(edge_index, num_nodes=x.size(0))
        x = self.lin(x)
        return self.propagate(edge_index, x=x)
    def message(self, x_i, x_j):
        m = self.message_func(torch.cat([x_i, x_j], dim=1))
        return m

    def update(self, aggr_out, x):
        return aggr_out

Following is the x matrix after the propagation part.

Is this without training? How does your graph and initial node features look like?

Actually, I had some problem in training, then I decided to simplify the problem to debug. Currently, I'm using a totally random x and the graph is a complete graph which means:
edge_index = [i for i in product(range(N), repeat=2)]
edge_index = torch.tensor(edge_index, dtype=torch.long)
edge_index = torch.transpose(edge_index, 1, 0)

P.S. Even when I had the training process, it wasn't changing! Although I considered the parameters in the optimizer!

Given a complete with self-loops and mean aggregation, all node features should be the same after aggregation.

Right. Then what can one do to prevent it? I want to have a complete graph. Should I change the message function wrt to the edge features? Or maybe message passing is not the right choice in this case? Thanks for your answer btw.

Also, I had another problem. Assume node 1. Regardless of the input (x) the output of the GNN is (almost) the same! I had the intuition for the previous problem but for this one, I don't know honestly.

IMO, for conplete graphs, edge information should be crucial. I do not understand your second concern.


Bug: changing the sim, and then modifying values, upon reload the values are ignored or error

Noticed while working on #30.
I think it triggers if you change the sim at some point in the modifications; the machinery that unpacks shortNames is using a different (old) simulator to unpack it. If it asks for the default value, it's just dropped. But if it explicltly sets a value to the shortName, then the config will barf because it doesn't recognize that property.
Fix is likely to make it so the machinery that exapnds the shortNames also notes the change of sim and uses that.

Yeah, packModificationsForURL has a similar problem; it uses the final value of the simulator, not the intermediate value so if you have a modification, then change the sim, and then have another modification, the earlier pieces are not shortened.
... One simple, hacky solution would be that if we see the sim has changed in the modification list, just don't do shortening...

modfifiedConfigData in selectors.js has a similar problem, and it creates intermediate simulators to do the processing... :-[

There's another problem: selectRequiredSimulatorsLoaded only loads the FINAL states of simulators requested, not any intermediate ones, so the simulator might not be loaded.
Solution si likely to change selectRequiredSimulatorsLoaded (and the machinery that decides which ones to load) to be aware of every sim in rawConfig, and modified configs, even intermediately. Then pack/unpack modifications should take rawConfigs, and then we should do the modifications on each rawConfig so we have a live simulator at every point

Another problem: by the time we unpack modifications from the hash, we STILL won't know how to unpack all of them, because new simulators won't be loaded yet

[ ] Keep track of simulators that are being loaded so we don't fetch them again
[ ] pack and unpack from URL should keep track of the current simulator at each time step to prase.


Upgrade jws to 3.0.0

On Apr 14, 2015, when I installed gcloud with npm, I got:
npm WARN deprecated<EMAIL_ADDRESS>Security update: Versions below 3.0.0 are deprecated.

I think you should upgrade jws to 3.0.0.

@ryanseys I believe this is from gToken. Just upgrade, make a patch release, and it should be fixed for new installs.

Done. https://github.com/ryanseys/node-gtoken/commit/e4e613553a06c5ba71c4edaa5b795f7cef425534


Support DELETE statement

https://www.sqlite.org/lang_delete.html

sqlite> explain delete from example;
addr  opcode         p1    p2    p3    p4             p5  comment
----  -------------  ----  ----  ----  -------------  --  -------------
0     Init           0     3     0                    0   Start at 3
1     Clear          2     0     -1    example        0
2     Halt           0     0     0                    0
3     Transaction    0     1     2     0              1   usesStmtJournal=0
4     Goto           0     1     0                    0
sqlite> explain delete from example where col = 0;
addr  opcode         p1    p2    p3    p4             p5  comment
----  -------------  ----  ----  ----  -------------  --  -------------
0     Init           0     11    0                    0   Start at 11
1     Null           0     1     0                    0   r[1]=NULL
2     OpenWrite      0     2     0     1              0   root=2 iDb=0; example
3     Explain        3     0     0     SCAN example   0
4     Rewind         0     10    0                    0
5       Column         0     0     2                    0   r[2]=example.col
6       Ne             3     9     2     BINARY-8       81  if r[2]!=r[3] goto 9
7       Rowid          0     4     0                    0   r[4]=example.rowid
8       Delete         0     1     0     example        2
9     Next           0     5     0                    1
10    Halt           0     0     0                    0
11    Transaction    0     1     2     0              1   usesStmtJournal=0
12    Integer        0     3     0                    0   r[3]=0
13    Goto           0     1     0                    0

Clear database
/* Opcode: Clear P1 P2 P3
**
** Delete all contents of the database table or index whose root page
** in the database file is given by P1.  But, unlike Destroy, do not
** remove the table or index from the database file.
**
** The table being clear is in the main database file if P2==0.  If
** P2==1 then the table to be clear is in the auxiliary database file
** that is used to store tables create using CREATE TEMPORARY TABLE.
**
** If the P3 value is non-zero, then the row change count is incremented
** by the number of rows in the table being cleared. If P3 is greater
** than zero, then the value stored in register P3 is also incremented
** by the number of rows in the table being cleared.
**
** See also: Destroy
*/
case OP_Clear: {
  i64 nChange;

  sqlite3VdbeIncrWriteCounter(p, 0);
  nChange = 0;
  assert( p->readOnly==0 );
  assert( DbMaskTest(p->btreeMask, pOp->p2) );
  rc = sqlite3BtreeClearTable(db->aDb[pOp->p2].pBt, (u32)pOp->p1, &nChange);
  if( pOp->p3 ){
    p->nChange += nChange;
    if( pOp->p3>0 ){
      assert( memIsValid(&aMem[pOp->p3]) );
      memAboutToChange(p, &aMem[pOp->p3]);
      aMem[pOp->p3].u.i += nChange;
    }
  }
  if( rc ) goto abort_due_to_error;
  break;
}

/*
** Delete the entry that the cursor is pointing to.
**
** If the BTREE_SAVEPOSITION bit of the flags parameter is zero, then
** the cursor is left pointing at an arbitrary location after the delete.
** But if that bit is set, then the cursor is left in a state such that
** the next call to BtreeNext() or BtreePrev() moves it to the same row
** as it would have been on if the call to BtreeDelete() had been omitted.
**
** The BTREE_AUXDELETE bit of flags indicates that is one of several deletes
** associated with a single table entry and its indexes.  Only one of those
** deletes is considered the "primary" delete.  The primary delete occurs
** on a cursor that is not a BTREE_FORDELETE cursor.  All but one delete
** operation on non-FORDELETE cursors is tagged with the AUXDELETE flag.
** The BTREE_AUXDELETE bit is a hint that is not used by this implementation,
** but which might be used by alternative storage engines.
*/
int sqlite3BtreeDelete(BtCursor *pCur, u8 flags){

/*
** Remove the i-th cell from pPage.  This routine effects pPage only.
** The cell content is not freed or deallocated.  It is assumed that
** the cell content has been copied someplace else.  This routine just
** removes the reference to the cell from pPage.
**
** "sz" must be the number of bytes in the cell.
*/
static void dropCell(MemPage *pPage, int idx, int sz, int *pRC){

/*
** Return a section of the pPage->aData to the freelist.
** The first byte of the new free block is pPage->aData[iStart]
** and the size of the block is iSize bytes.
**
** Adjacent freeblocks are coalesced.
**
** Even though the freeblock list was checked by btreeComputeFreeSpace(),
** that routine will not detect overlap between cells or freeblocks.  Nor
** does it detect cells or freeblocks that encrouch into the reserved bytes
** at the end of the page.  So do additional corruption checks inside this
** routine and return SQLITE_CORRUPT if any problems are found.
*/
static int freeSpace(MemPage *pPage, u16 iStart, u16 iSize){

Done: https://github.com/kawasin73/prsqlite/commit/c80e43c1121f295052fe0835d498081ac81b5665