Import/export corpus definitions

There should be a method to import/export corpus definitions, where the file and database have a one-to-one mapping. Export could be json or yaml (or something else?).
This is useful for offering user support, debugging, transferring data between local, test, acc and production servers. It can also be useful to curators who want to create different version of a corpus.
This should be accessible from the interface (for curators), but would also be useful as a command line tool.
For development purposes, we should probably develop this this before the option to enter corpus definitions via a form, as the latter will take up much more development time.
We can consider if we want a centralised location to save exported corpus definitions. This could be the current corpora module, but perhaps it makes more sense to make this a separate repository.
To do:

[ ] Function to import a JSON definition (#1519)
[ ] Function to export a JSON definition
[ ] Some method to use import/export functionality.

What is the easiest way to make the JSON import/export usable in practice?
In the short term, we want to be able to use this import/export to test things out. In the long term, we do need an easy way to import/export the JSON-serialised corpus, since that makes it easy to transfer corpora between servers.
Options:

Add this to the admin site. This is a good place to have such an action, but I'm not very familiar with customising the Django admin like this. Perhaps as an action that provides an intermediate page? That looks appropriate for an export option (that's actually the example in the documentation), but I'm not sure how an import could work.
Use Django REST framework's API interface. Since the frontend will use the same JSON schema, this can be recycled as the actual view.
Add a custom command
Build a (very rudimentary) frontend component with just the JSON import/export. Can be expanded with a proper form later.
?


We should be using the actual label name in Robotoff questions

What
We should be using the actual label name in Robotoff questions

@teolemon I guess we do, except when we don't:

Here in Smoothie there's no added value: we just print what we've been provided.

ok, good, I wasn't sure, going to file on the Robotoff Side

@raphael0202 any idea why we're getting those ?

Closed as the error does not come from Smoothie.

Indeed it comes from Robotoff side.


Consider using newer ES6 instead of CoffeeScript

@aabenoja and I forked bless earlier this year and converted the project to ES6 using babel as the transformer. Are there any objections to bringing in the ES6 changes from css-band-aid.
A few benefits to this is that that codebase has the following already:

Source Map Support
Cleaner codebase using ES6 generators
Some addition CLI options:

One that chunks files
One that only counts with no changes for reporting

I think this can be closed.

I don't see any coffeescript files, so...


Method descriptors

Nominal type descriptors for protocols and classes contain an array of method descriptors. This PR defines symbols pointing at these descriptors, allowing them to be referenced from outside the module.
Method descriptors will be used in two places:

Resilient witness tables. Previously resilient witness tables used protocol dispatch thunks as keys, but this is problematic because we don't want to rely on function pointer identity.

Resilient method overrides. Here again we don't want to use dispatch thunks as keys; classes have the additional issue that resilient overrides are sometimes needed for methods that don't have dispatch thunks.

@swift-ci Please smoke test


serial: fix memory requests and free resources on target node

The memory alignment test was expecting to find a message in the pod events indicating that although the pod resources were available on compute node level, alignment of both containers could not be achieved on a single numa node, one container per numa as per the assumption that the tests run only when TMscope=container.
The test failed to find that expected message because there were no candidate nodes in the first place, the reason was a lack of memory resources. The pod was requesting 9Gi, while the free resources left on the target node were only 8. The reason it was set to 8 is because of the false thought that there will be base memory on that node, which is usually 4.5Gi, which makes sense that 4.5Gi + 8Gi is way more than enough, but that is a mistake. because when noderesourcefit filters the nodes it compares the actual available resources on the node with the pod requested resources, if the available resources can accommodate the pod resources then it will mark the node as a possible candidate, if not it will reject it. The result we get from Fit when the test fails is that there is only 8.3 free memory on the target node, hence it is rejected.
To fix the test, first set minimum free resources on the first numa of the target node: 1Gi, because we know for sure that the baseload will be added to the first numa upon padding the node. the base memory is around 4.5Gi, so we need to consider that both pod containers requests at least 6Gi so none of them could fit into the first numa. To be on the safe side, let both containers request 7Gi.
OTOH the target node should have total free memory that matches the total memory requested by the pod, which is 14Gi, thus let the second numa on the target node have the rest of 13Gi free memory.

please make sure to fix the PR title ("resuests")

/test ci-e2e


OSError: [Errno 8] Exec format error

hi：
everybody，I get a error,when I compile the code for mininet。and I have not error.but when I run "mn",I can't get true response。the following is my error：
*** Creating network
*** Adding controller
Caught exception. Cleaning up...
OSError: [Errno 8] Exec format error
*** Removing excess controllers/ofprotocols/ofdatapaths/pings/noxes
killall controller ofprotocol ofdatapath ping nox_core lt-nox_core ovs-openflowd ovs-controller udpbwtest mnexec ivs 2> /dev/null
killall -9 controller ofprotocol ofdatapath ping nox_core lt-nox_core ovs-openflowd ovs-controller udpbwtest mnexec ivs 2> /dev/null
pkill -9 -f "sudo mnexec"
*** Removing junk from /tmp
rm -f /tmp/vconn* /tmp/vlogs* /tmp/.out /tmp/.log
*** Removing old X11 tunnels
*** Removing excess kernel datapaths
ps ax | egrep -o 'dp[0-9]+' | sed 's/dp/nl:/'
***  Removing OVS datapathsovs-vsctl --timeout=1 list-br
ovs-vsctl --timeout=1 list-br
*** Removing all links of the pattern foo-ethX
ip link show | egrep -o '([-_.[:alnum:]]+-eth[[:digit:]]+)'
*** Killing stale mininet node processes
pkill -9 -f mininet:
*** Shutting down stale tunnels
pkill -9 -f Tunnel=Ethernet
pkill -9 -f .ssh/mn
rm -f ~/.ssh/mn/*
*** Cleanup complete.
if I need to install nox？but I install nox and still is error。

The half part of your message seems like a "clean" step.
Do you have all command you type and all detail output?

I according to:
1、git clone https://github.com/mininet/mininet
2、modify install.sh to standy by centos
3、mininet/util/install.sh -a to compile get all is not error
and I can use mn command

Do you have install the OVS ?
Since the centos is not supported by the mininet by default.
Maybe you should try to use other distribution like Ubuntu and it can save your time.

yes,I installed ovs ,maybe is the operating system's error,I'll try to use Ubuntu,Because I can't savle the problem temporarily。thanks

This doesn't sound like a Mininet problem, and you seem to be ignoring the actual error message from the exception! It also sounds like you are running on CentOS and have modified the installation script, so it also probably isn't a problem with mainline. If you think that there is some Mininet error, you can reopen this but please provide the detailed debug output.


feat: Support load cubemap in ktx loader

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Enhancement.
What is the current behavior? (You can also link to an open issue here)
load cubemap with 6 ktx file.
What is the new behavior (if this is a feature change)?
load cubemap with 1 ktx file.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Yes.

delete KTXCubeLoader
delete AssetType.KTXCube
AssetType.KTX will return Texture2D or TextureCubeMap

Other information:

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev/0.5@21bb632). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             dev/0.5     #336   +/-   ##
==========================================
  Coverage           ?   40.72%
==========================================
  Files              ?      328
  Lines              ?    18288
  Branches           ?     2403
==========================================
  Hits               ?     7447
  Misses             ?    10841
  Partials           ?        0

Continue to review full report at Codecov.

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


Version numbering

In the tagged versions of the code is it possible to change the version numbers in the setup.py file? Same for the main branch? At least for the main branch of the code and for the tagged version v0.9 the versions in setup.py are both 0.1. Therefore, running pip install . or equivalently python setup.py install on both branches appears to install the same version of the code e.g. running pip show ares returns version 0.1.
This makes version control quite difficult e.g. making sure I'm running the same version of ares on different machines.

@mirochaj thanks for the quick reply! Perhaps it's not possible to change a file on a tagged branch but maybe in the future e.g. for #61 the version number could be included in the setup.py?
Ohh wow that get_hash() code is very cool! I will check that out, thanks.
A colleague implemented version increment and release workflows (https://github.com/htjb/globalemu/pull/16) for my globalemu code. The workflow basically blocks pull requests if the version hasn't been bumped and makes a release (equivalent of your tagged versions I think) with the version number when the PR goes through. Seemed to work really well and I think a few other colleagues have adopted it for their code bases as well.

Thanks for passing that along, I'll take a look.


startmode on stop

In the xml file I can set the start mode of the service with demand.
But what I would like to be able to do is this:

when I start the service, startmode should be auto
when I stop the service, startmode should be demand (to make sure that service is not started again if the windows server restarts)

Is this possible now?

No, it's not possible in WinSW, but technically it could be implemented in a compatible way (by adding opt-in flag). Feel free to propose a pull request

Ok, but I worked around it, and I feel the solution is better than to change the startmode on stop.
What I do now is:

Install the service
Start the service

And when I'm going to shutdown the service:

Stop the service
Uninstall the service

@oleg-nenashev As discussed in the gsoc-sig meeting I would like to start with some beginner friendly issues.
In the defaultSettings.cs the default for the startMode is already auto, when the service stops can we change the mode to demand in StopIt().
                  public StartMode StartMode { get { return StartMode.Automatic; } }

I don't think this feature is related to the existing stop command though. Maybe new commands like enable/disable or set which allows more modifications on demand.


Bluetooth: Host: Fix L2CAP EINPROGRESS refs

Fix discrepancy in reference management between calls to bt_l2cap_chan_ops.recv when the application returns -EINPROGRESS.
There are two call sites, l2cap_chan_le_recv_sdu and l2cap_chan_le_recv, that were inconsistent.
l2cap_chan_le_recv_sdu moves the reference, and this patch updates l2cap_chan_le_recv_sdu to do the same.
This behavior is also now documented.
This bug has existed since the introduction of this feature in 3151d265726fb528d31d8e1ee8b35004e901cfc4.
Signed-off-by: Aleksander Wasaznik<EMAIL_ADDRESS>

GitHub doesn't allow me to do inline review of commit messages, so I'll do it here:

l2cap_chan_le_recv_sdu moves the reference, and this patch updates
l2cap_chan_le_recv_sdu to do the same.

The second function reference there should be l2cap_chan_le_recv, shouldn't it?

Added test and fixed the commented-on issues.

I'll delete the tester code, and rewrite the test. Basing it on a different test was a mistake.


Variables {cpu_name}, {gpu_name} and {gpu} not working, I can't see CPU/GPU name and GPU % value

I tried several times but it failed (see the following picture)
The CPU's % value shows up, but not the GPU's.
And neither CPU nor GPU names are displayed (Use Google Trans if you don't understand this sentence)

my config (with variable {cpu_name} and {gpu_name})

the result

Thank you, I tried in 1.19.2 and it's interesting to see CPU name showing :D but GPU name not (I'm using Intel HD 510 iGPU) and I'm not sure if using discrete GPU it shows market or not

Từ: Jakob @.>
Đã gửi: 25 Tháng Giêng 2023 2:53 SA
Đến: Minenash/CustomHUD @.>
Cc: Itzz Parsher @.>; Author @.>
Chủ đề: Re: [Minenash/CustomHUD] Variables {cpu_name}, {gpu_name} and {gpu} not working, I can't see CPU/GPU name and GPU % value (Issue #76)
Sorry for late reply.
This is because {gpu} was added in the 1.19, as that's when Minecraft added it and I can the info from that. It's wouldn't be an easy task to completely add the GPU utilization tracking thing from scratch, it's no where as simple as CPU end ram
For future reference, if something like like it's not working, these a good chance the log will tell you why
—
Reply to this email directly, view it on GitHubhttps://github.com/Minenash/CustomHUD/issues/76#issuecomment-1402513679, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZ2PAVSFYIXYFNQBIPV7DKDWUAXKBANCNFSM6AAAAAAS3VMHQI.
You are receiving this because you authored the thread.Message ID: @.***>


Global search loses focus on layout switch during typing

I found a bug being caused by the plugin. It's very annoying, and can also result in unintentional changes to notes. To replicate:
Open Joplin and set up the plugin to default to Split View. Add a tag (let's call it "Rendered" here) for rendered markdown editor view.
Navigate to a note that is set to go to default view.
Go to the search box, and start typing text that will cause the search results list to bring a note with the Rendered tag to the top of the search results list.
Watch the note switch to the rendered view as it should.
The search box loses focus and the note gains focus! This shouldn't happen.
The loss of focus in the search box is a significant issue. There are two big problems with this:
When typing in the search box, partial results display as one types. For example, if I am searching for "schoolbus", "school" might cause the results list to update and the search box to lose focus, making it impossible to type "schoolbus" without clicking back into the search box. This sort of thing happens all the time, since a few characters in the search box very often brings up results that cause a change in the viewer layout.
If the search results in a note switching from rendered view to split view or markdown view, the note body gains focus. Characters being typed into the search box now begin appearing in the note body, causing unintended changes to the note.
Disabling the plugin makes the above issue go away.

Copied from forum: https://discourse.joplinapp.org/t/persist-editor-layout-plugin/14411/45

This bug allows unintended changes to notes (data loss). Is it being addressed?

Fixed in latest App pre-release version v2.9.1.

I'm on v2.9.4 and I'm still losing focus during search. Can someone else test please?


Update README.md

This PR cleans up spacing and adds quotes around the docs entries such that the content from the example can literally be copied and used.

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
d748ed6179b4480b92028dfc9e0b9189d55e70ca
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery I made a small typo fix for this This field describes the are of Istio that the note affects. line, which should be area. let's see, which PR gets merged first, then might need a rebase.

/test release-notes_istio

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-multicluster-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-multicluster-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-multicluster-k8s-tests_istio

integ-telemetry-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-pilot-k8s-tests_istio

integ-multicluster-k8s-tests_istio
e96f8431fa9e8f1157259e921fae7bf321a2b1eb
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


block number limit and bug fixes

TL;DR
Added ability to set block limit for polling. Added additional logging for RPC method support checks and added safeguards for block data serialization.
What changed?

Added logging for RPC method support checks in rpc.go
Introduced POLL_UNTIL_BLOCK environment variable to limit polling
Modified block range calculation to prevent skipping the genesis block
Updated GetLatestPolledBlockNumber to return math.MaxUint64 when no block is found so next block polled will overflow to genesis
Added a null check for WithdrawalsHash in block serialization

How to test?

Set the POLL_UNTIL_BLOCK environment variable to test polling limits
Verify logging output for RPC method support checks
Ensure polling starts from genesis when no last polled block is found
Test block serialization with and without WithdrawalsHash data

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#19  👈
#18
#17
#16
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @iuwqyir and the rest of your teammates on  Graphite

Merge activity

Sep 19, 5:02 AM EDT: @iuwqyir started a stack merge that includes this pull request via Graphite.


Counter clockFace shouldn't init with previousDigit

If I start a counter at say 9995 then I get strange results on first load. The first value seen on the counter will be 8884 and then it will flip to 9995. On the Counter face, the expected behavior would be to see the current value of the counter and only see it change when the counter increments or decrements.
I can override this behavior by explicitly setting lastDigit = 0 in createList, but I'm sure there's a better way of doing that.
I'm also not convinced that when using the Counter face that it should flip on first load, and should only flip when it increments or decrements. Thoughts?

Did you manage to solve this issue, I am currently facing the same issue with the count's down, when I use a number like 100 it shows 199 at the beginning then 100 and then it starts going down. is there any way to stop the initial flip with the strange numbers?
for example in Daily counter, there is no flip at the beginning

I'm also experiencing this issue with counting down and navigating between bootstrap togglable tabs that have the countdown clocks inside them.

the official demo has this problem too,hope to be fixed .

This is fixed in the newest versions. js-es6 branch currently has the v1 draft release. Closing this issue.


how to make this work with zsh-syntax-highlighting?

Hi,
I tried to use this script and found that there was no syntax highlighting in visual mode.
But it seems that highlighting works in your demo gif.
Could you tell me how to achieve this? Thanks!

I have figured out a solution of this.
Close the issue.


Question: Update API Layer

is there a guide how to update the API Layer?
I got the schema for layer 121 and I can convert it based on the implementation however I don't know how to generate the file descriptor is there any guide for it?

only support layer 86

I see..I'm having issues building the old telegram version on new Android Studio..any suggestions/recommendations?

hi @wubenqi
I have found the client perhaps this server supports(https://github.com/nekohasekai/NebulaAndroid) but the API layer is mismatched the version in the client is far more updated than the server is supported..
can you suggest which of the SHA in that repo does match with this server or release version? thank you


github.com/greenpau/versioned v1.0.18 not found

I had to apply this to build:
diff --git a/go.mod b/go.mod
index 9ad7470..f68bf81 100644
--- a/go.mod
+++ b/go.mod
@@ -5,7 +5,7 @@ go 1.14
 require (
        github.com/Masterminds/semver v1.5.0
        github.com/cpuguy83/go-md2man/v2 v2.0.0 // indirect
-       github.com/greenpau/versioned v1.0.18
+       github.com/greenpau/versioned v1.0.22
        github.com/mattn/go-zglob v0.0.2
        github.com/pkg/errors v0.9.1
        github.com/sirupsen/logrus v1.6.0

@cventers , thank you for the issue! I just pushed the latest version https://github.com/greenpau/gorpm/releases/tag/v1.0.5
It should work fine. How did you like the tool? Was it difficult to use? Any feedback? Suggestions?


Build utilities docker image on each push to master

What type of PR is this?
/kind feature

Any specific area of the project related to this PR?
/area build

What this PR does / why we need it:
This will create rolling release for kilt utilities.

Fixes #

Build docker.pkg.github.com/falcosecurity/kilt/utilities:latest on push to master

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign admiral0
You can assign the PR to them by writing /assign @admiral0 in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 5f09685c10cc08cbfd381271258063d8e2d16333

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: fntlnz
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [fntlnz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Update InFlightRequests.java

if not iff
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[x] Verify design and implementation
[x] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks for the PR. "iff" is actually correct here. It means "if and only if".
Closing the PR.


ReDoS in validator

Ensure we're using validator 9.4.1 or later to avoid Regular Expression Denial of Service (ReDoS) in validator dependency.
https://snyk.io/vuln/npm:validator:20180218

https://github.com/leepowellcouk/mongoose-validator/pull/47

Merged. Thanks 👍


Is this project dead?

Looking to use it in shiny bling-bling new LitElement application, but last updates are in 2017 and there is no major version yet.
In what status is this project?
UPDATE:
Some article: An Introduction to the Redux-First Routing Model

@mksarge if you'd like, I'm willing to maintain

@mksarge bump on this if you'd like :)

I don't think so. I've been using this for a relatively production-grade project for a while and things seem to work just fine (at least for my use). There don't seem to be many updates that are needed (low issues count) so I'd personally attribute the old modification dates on the code to this repo being "done" moreso than it being out of date

what a coincidence that as soon as I say that I end up running into issues. Since it seems like there arent many great substitures for the simplicity of this repo that aren't also unmaintained, I have started a fork of this repo to hopefully provide a place where fixes can be centralized and published. I cant guarantee i'll maintain it forever or be able to keep publishing in every format that this repo made available, but I'll do at least what is needed for my project and will try and be active for at least the near future in case anyone wants to make contributions


Misleading docs on modules.

Describe the bug
Docs here: https://www.scramjet.org/docs/scramjet-modules are outdated and don't point to the right information. Additionally this one: https://github.com/signicode/scramjet/blob/master/docs/modules.md is not available on the website (where it definitely should be in the docs section)
Expected behavior
Modules docs should preset the same documentation across all entries. There should also be a reference to the articles on the website.

Done.

Great, now we have a 404... needs fixing... :P


Proposal: Add TryGetStateAsync method for non-actor state management operations

Describe the proposal
When accessing a state store from a non-actor, there exists a GetStateAsync<T> method. Unfortunately, if the key doesn't exist, this returns a default(T), which, depending on the type of T doesn't necessarily tell you much about whether the state actually exists or not.
When accessing state from an Actor, there exists, a TryGetStateAsync<T> which addresses this very problem since it returns a ConditionalValue<T>, indicating whether the key exists or not.
I would like to propose that TryGetStateAsync<T> be added to the non-actor state store API. It should return a ConditionalValue<T> like that of the actor API. Most importantly, it fills a gap in the API right now in that there appears to be no definite way to confirm that a given key otherwise exists or not.
I'd be happy to contribute a PR, if this is an acceptable addition.
Proposed breaking change
Today, ConditionalValue exists only in Dapr.Actors. To avoid having two identical types, this should be refactored out to a more common project like Dapr.Client.
Should be it - this looks to just be an issue in how the .NET API works and I don't see that it requires any changes to the sidecar itself.

While I'm personally not fond of ConditionalValue<T> in the first place--I'd rather rely on overloads of GetStateAsync<T>() that use Nullable<T> for non-reference types and nullable contexts for reference types--we are where we are.  It seems reasonable to me to have a TryGetStateAsync<T>() method on DaprClient that matches what currently exists on IActorStateManager.
Since Dapr.Actors references Dapr.Client, it should be ok to move ConditionalValue<T> to the latter assembly.
I do wonder if/how that might impact the bulk get state operations (e.g. in light of #1173).  Do they also need a means of indicating that the state was not found? (Off the top of my head, I don't recall whether bulk get state operations omit entries for keys that do not exist, and the API docs don't explicitly state one way or the other.)

This whole proposal evolved from reading through the SDK code to answer the question "What happens if the key doesn't exist in the state?".  The docs don't mention it, but after completing this work, I'd be happy to clarify this either way in the docs as well.
I wasn't a huge fan of ConditionalValue<T> in the first place either and favored returning a null instead of the value, but I think that ship has sailed as it wouldn't make sense to handle state operations in actors vs non-actors differently, I think.
Another method that could be addressed here: GetStateAndETagAsync does the same thing as GetStateAsync right now (returns a default(T) if not found), so I'd propose adding a TryGetStateAndETagAsync and just wrap the result in a ConditionalValue<T>.
With regards to #1173 , I'm going to have to dig through what's happening in the sidecar as I just look at look at the .NET SDK and it's just enumerating the returned items, so any exclusions for missing keys happen external to the SDK. That said, I'd be happy to take a stab at making changes there as well (if necessary) to better support a Try variant of the GetBulkStateAsync methods as well.

/assign


LLVM 18 breaks 128-bit integers in the interpreter

An interpreter built with a LLVM 18 compiler crashes with invalid memory access when using a 128-bit integer type.
The reproduction requires a compiler with LLVM 18 which builds a compiler with interpreter. Using a 128-bit integer value in that interpreter causes an invalid memory access:
$ crystal --version
Crystal 1.13.1 (2024-07-12)

LLVM: 18.1.8
Default target: x86_64-unknown-linux-gn
$ make crystal interpreter=1 release=1
Using /usr/bin/llvm-config-18 [version=18.1.3]
CRYSTAL_CONFIG_BUILD_COMMIT="" CRYSTAL_CONFIG_PATH='$ORIGIN/../share/crystal/src' SOURCE_DATE_EPOCH="1720742400" CC="cc -fuse-ld=lld" CRYSTAL
_CONFIG_LIBRARY_PATH='$ORIGIN/../lib/crystal' ./bin/crystal build -D strict_multi_assign -D preview_overload_order --release  -o .build/cryst
al src/compiler/crystal.cr -D without_openssl -D without_zlib -D use_pcre2
$ bin/crystal i
Using compiled compiler at .build/crystal
Crystal interpreter 1.13.1 (2024-07-12).
EXPERIMENTAL SOFTWARE: if you find a bug, please consider opening an issue in
https://github.com/crystal-lang/crystal/issues/new/
icr:1> 1_i128
 => Invalid memory access (signal 11) at address 0x0
[0x55c5918c6629] ?? +94307038815785 in /app/.build/crystal
[0x55c5918c65e0] ?? +94307038815712 in /app/.build/crystal
[0x7f83b0326320] ?? +140203573535520 in /lib/x86_64-linux-gnu/libc.so.6
[0x55c591f72740] ?? +94307045812032 in /app/.build/crystal
[0x55c591d8ca5b] ?? +94307043822171 in /app/.build/crystal
[0x55c591f981f6] ?? +94307045966326 in /app/.build/crystal
[0x55c59235c83d] ?? +94307049916477 in /app/.build/crystal
[0x55c5923591cc] ?? +94307049902540 in /app/.build/crystal
[0x55c5922b34e5] ?? +94307049223397 in /app/.build/crystal
[0x55c59186773f] __crystal_main +36271 in /app/.build/crystal
[0x55c59186ddc9] main +73 in /app/.build/crystal
[0x7f83b030b1ca] ?? +140203573424586 in /lib/x86_64-linux-gnu/libc.so.6
[0x7f83b030b28b] __libc_start_main +139 in /lib/x86_64-linux-gnu/libc.so.6
[0x55c59185e8c5] _start +37 in /app/.build/crystal
[0x0] ???

The bug does not reproduce when building the interpreter in debug mode, nor in non-release mode.
This is likely related to LLVM changing the alignment of 128-bit integer types to 128 bits in LLVM 18: https://reviews.llvm.org/D86310

When Crystal is built with LLVM < 18: alignof(UInt128) == 8.
When built with LLVM >= 18: alignof(UInt128) == 16.

The interpreter may expect the old alignment somewhere.
So far it has only materialized in the interpreter and it's quite likely that this is an interpreter-specific bug.
But at this point we cannot certainly exclude any effect on other applications.
This issue appeared while trying to update the previous Crystal release to 1.13.1: https://github.com/crystal-lang/crystal/pull/14810

This method is suspicious; does it calculate the alignment on a 8 bytes boundary?
https://github.com/crystal-lang/crystal/blob/master/src/compiler/crystal/interpreter/context.cr#L455-L462

Yeah, looks like it. I've stumbled over that as well.

Ah, no that indeed is a problem. align is solely based on size, not on the current stack pointer.
It needs to take the current stack pointer into account. If the address is not aligned to 16 bytes, we won't be able to get a 16-byte alignment.
The interpreter stack does not seem to anticipate an alignment larger than 8 bytes.

IIRC the interpreter memcpys the stack contents rather than dereferencing the stack pointer directly, so if there is an aligned 128-bit load/store at a misaligned address, it is probably somewhere else

https://github.com/crystal-lang/crystal/pull/14843 seems to fix the memory access error. However, it does so by simply avoiding misaligned stack access errors. However, the misalignment still exists.
So it does feels a bit like a workaround. It does not fix the underlying issue that 128-bit integers are not properly aligned.
# interpreter with patch #14843 and LLVM 18
pad = 1_i8
x = 1_i128
pointerof(x).address % alignof(typeof(x)) # => 8

Note: This issue only depends on the LLVM version of the interpreter itself, not of the parent compiler. The interpreter's LLVM version determines the alignment value.
If the alignmed was correct, we would not need #14843 to make the interpreter work.
It's probably still a good idea to merge #14843, though. It removes a dependency on the alignment policy of the parent compiler. This seems like a good idea anyway.


Squash some warnings in MSVC build.

In particular, "defined but not used" (caused by GRAPHICS_DISABLED),
double constants being truncated to floats, and implicit casts.

thanks

This PR contains several type casts of old type which either should be replaced by C++ type casts or be avoided by other means.

@stweil: I fixed this, but AFAIK there are more code to be changes...

I build Tesseract/Leptonica as part of MuPDF. So they are minimal builds for just what I need. I don't build the command-line tools etc (except on Linux for testing).
The commits haven't quite made it to our main repo yet (https://git.ghostscript.com/?p=mupdf.git;a=summary), but they can be found on my personal repo, here: https://git.ghostscript.com/?p=user/robin/mupdf.git;a=summary
If you:
git clone git://git.ghostscript.com/user/robin/mupdf.git --recursive
you should get everything checked out, with thirdparty/leptonica and thirdparty/tesseract being git repos for leptonica and tesseract respectively.
Open platform/win32/mupdf.sln in VS2019, and there should be libtesseract and libleptonica projects. You'll need to use the {Debug,Release,Memento}Tesseract configurations for them to actually be built.
Any problems, just let me know! If you want to talk to me direct, I am generally on the #mupdf irc channel, that you can reach here: https://webchat.freenode.net/?channels=mupdf


Null displayed when person invites you to a room

Could replicate on mobile & desktop Firefox

What do you do to replicate?

Create a room (In this case I used a private room)
Get the creator of the room to invite you to the room
You will see "null invited you to a room, would you like to join?"
Initially I found this while testing with a friend, however to test again I created an alt and followed it but it did not appear online for me and as such I could not invite it to a room.
I had to drag my friend back to test; issue still present.

I think this should be fixed


TabView Gestures

The TabViews (e.g. Notifications) have to be swipeable for the users from left to right and vice versa.

Done.


Example inference script?

This project looks very interesting! Is there an inference script available or should we alter one of the test scripts?

Looks like the current main branch is in a broken state. There are references to GPTran / gptran.yaml files which I believe have been renamed.
The first commit of this repo appears to be running (although I don't have access to csv line files etc to test it. I am currently in the process of  getting this to run on a non SUN360/GSV image.

As a follow up, if anyone is interested on trying this on their own images, you'll need to run your image through LSD (line segment detector) as noted in the paper. One implementation I found was: https://github.com/theWorldCreator/LSD. Note that this implementation gives back the data in a space separated format, you will need to convert it to comma separated. From there I made some slight alterations to the test_hlw/hlw dataset for inference (mainly removing error calculations on horizon lines etc).
I am still in the process of building this out, but it appears to be giving me back results in line with what I would expect.

As a follow up, if anyone is interested on trying this on their own images, you'll need to run your image through LSD (line segment detector) as noted in the paper. One implementation I found was: https://github.com/theWorldCreator/LSD. Note that this implementation gives back the data in a space separated format, you will need to convert it to comma separated. From there I made some slight alterations to the test_hlw/hlw dataset for inference (mainly removing error calculations on horizon lines etc).
I am still in the process of building this out, but it appears to be giving me back results in line with what I would expect.

I am also interested in trying this work. Glad to see you have made some progress. Would you mind updating you progress here and let us know how we should proceed? many thanks.

@ydzhang12345 the prediction results have been quite promising from the images I have tried it on, so I'm going to build this out further (there are currently manual steps involved). Assuming all goes well, I will put a PR up with an inference script in the next couple of days.

Awesome! I will keep an eye on here then. Thank you joel!

Thank you for your interest. I wrote a script that can test a single image. You can test it with the code below.
python test_image.py --sample 'sample.jpg' --opts OUTPUT_DIR 'outputs'

@jwlee-vcl thanks for that! Looks like I took a similar approach, so I won't bother adding a PR :)


Do not deadlock

The messagesLock can't be held forever. This adds some backoff to the
process so if the message channel is full we'll not deadlock during a
terminate.

cc @drtall @pingihu @adamfaulkner ready for re-review.

LGTM, although per f2f I think there's still a race in messagePump writing to the closed messages channel.


Coverage integration test for PR #25

@kwonoj I hope you'll add tests for your PR #25 soon 😉 . If you need some more explanations for creating it - feel free to ask here.
After that we'll bump version of ts-jest package.

Yes, it's on my plate and I should fill those up asap.

@kwonoj I still have some issues, one is the configuration file can be different from the package.json, the other is that the report still give me the old results to be used in the coverageThreshold.

@CarlosSoares we haven't updated ts-jest package yet. Are you testing using sources?

Yes I'm using the source code.

@CarlosSoares

one is the configuration file can be different from the package.json

: this is already supported, I'm using separate json for jest configuration.

the other is that the report still give me the old results to be used in the coverageThreshold.

: this one is not clear to me, but current implementation does not honor coverageThreshold options.

I tried the first one and didn't work, but I'll try later to see what's the problem.
When I execute the jest -c my.config.json --coverage not print the remap result.

as noted in readme, please check with --no-cache. Jest does not execute preprocessor if cache hits transpiled code, coverage processor won't work.

Also one more thing (just in case) - if you're using text reporter, that won't print out remapped result. It's current limitation of how result processing work, jest process coevrage and write out to reporter including text and there is no way result processor can change it.

Related to the config issue.
command: jest -c jest.config.json --coverage --no-cache
TypeError: Cannot read property 'coverageConfig' of undefined
    at processResult (***/node_modules/ts-jest/dist/coverageprocessor.js:9:64)

command: jest --config jest.config.json --coverage --no-cache
TypeError: Cannot convert undefined or null to object
    at ***/node_modules/ts-jest/dist/coverageprocessor.js:14:85

Please include config as well.

{
  "rootDir": "./",
  "scriptPreprocessor": "<rootDir>/node_modules/ts-jest/preprocessor.js",
  "testResultsProcessor": "<rootDir>/node_modules/ts-jest/coverageprocessor.js",
  "testRegex": "/specs/.*\\.spec\\.(ts|tsx|js)$",
  "testEnvironment": "jsdom",
  "coverageReporters": ["html", "json"],
  "coverageDirectory": "./coverage",
  "moduleFileExtensions": ["ts", "tsx", "js", "json"],
  "collectCoverageFrom": ["src/**/*.tsx", "src/**/*.ts"],
  "coverageThreshold": {
    "global": {
      "statements": 95
    }
  }
}

fixed by #33


Add VEI slider

This PR adds a VEI slider to the controls panel that ranges from 1 - 8.  Slider can be shown/hidden from the model options.  When adjusted, slider also updates the ejected volume and the column height so they are in sync with the selected VEI value.  Full VEI widget with updated display based on VEI slider value will be handled in a subsequent PR.

@sfentress Good points.  I would vote to address some of that in a new story since there are other related issues tied to ensuring that controls have proper ranges (which I agree is complicated now that one control can adjust the value of other controls).  For example, the column height slider has a min value of 1, but if VEI is set to 1, it tries to set a corresponding column height value of .1 (which cannot be shown on the column height slider).  Similarly, the VEI block tells the user to enter a value from 0 - 8 instead of the 1 - 8 allowed on the slider.  I think, in general, we should look at these value ranges and add new stories for cases where a control doesn't have the proper range or should update it's current value based on some other app change.  I'll post some of this to Slack.


can't get full call tree

I've written a test bean ,the call graph is following :
w1.jsp->wzy.TestWrapper:test-> wzy.jdbc.TestBean:testJdbc (jdbc call)
->wzy.TestSleep:test: (jdbc call)
-> sleep
->sleep
The call graph get from appdynamics is complete,but the call graph from pinpoint is incomplete
call graph of pinpoint :
Tomcat Servlet Process
REMOTE_ADDRESS
invoke(Request request, Response response)
connect(String string, Properties properties)
executeQuery(String string)
connect(String string, Properties properties)
executeQuery(String string)
call graph of appdynamics :
JSPBaseervlet:service: Unknown (execution time: 20 ms of 10299 ms total, wait time: 0 ms of 9984 ms total)
Servlet - w1.jsp:_jspService: 115(execution time: 0 ms of 10279 ms total, wait time: 0 ms of 9984 ms total)
java.lang.Thread:sleep: Unknown (execution time: 4998 ms of 4998 ms total, wait time: 4998 ms of 4998 ms total)
wzy.TestWrapper:test: 11(execution time: 0 ms of 5281 ms total, wait time: 0 ms of 4986 ms total)
wzy.jdbc.TestBean:testJdbc: 9(execution time: 184 ms of 1180 ms total, wait time: 0 ms of 996 ms total)
JDBC (150ms):  [0]
java.lang.Thread:sleep: Unknown (execution time: 996 ms of 996 ms total, wait time: 996 ms of 996 ms total)
wzy.TestSleep:test: 11(execution time: 111 ms of 2105 ms total, wait time: 0 ms of 1994 ms total)
JDBC (88ms):  [1]
wzy.TestSleep:test2: 43(execution time: 0 ms of 997 ms total, wait time: 0 ms of 997 ms total)
java.lang.Thread:sleep: Unknown (execution time: 997 ms of 997 ms total, wait time: 997 ms of 997 ms total)
java.lang.Thread:sleep: Unknown (execution time: 997 ms of 997 ms total, wait time: 997 ms of 997 ms total)
wzy.TestWrapper:test2: 33(execution time: 0 ms of 1005 ms total, wait time: 0 ms of 1005 ms total)
java.lang.Thread:sleep: Unknown (execution time: 1005 ms of 1005 ms total, wait time: 1005 ms of 1005 ms total)
java.lang.Thread:sleep: Unknown (execution time: 991 ms of 991 ms total, wait time: 991 ms of 991 ms total)

Hi @wzy25
The reason the call graphs are different is because the scope of what Pinpoint traces is different from AppDynamics. Pinpoint selectively defines which methods to trace as tracing, and this will be different from what AppDynamics chooses to trace (such as the Thread.sleep() method).
Tracing more will add more details but it will also add a lot of clutter in the call stack (and overhead), and it's the balancing act between these that leads to design decisions such as why we don't trace methods like Thread.sleep().
That said, I don't think the scope of what we trace is perfect, so we'll continue to work on areas where we could trace more (or less).
Thanks!


[Request] Shinobi, Koi Utsutsu (Nintendo Switch)

https://github.com/0xDC00/scripts/commit/425765d80448bc64cdc155fa509813f79e343140


chore: adapt existing code to our needs

Description

[!IMPORTANT]
Work in progress

Tweaks the code based on our needs.
Changes

Remove node_modules
Use yarn and set nvm version
Add a test workflow

Closing in favor of smaller PRs


'Talk-To-NPC' Quests giving 'No more Quests available' msg.

Basically what the title says, when there is a 'Talk to NPC' Quest stage, when you right click on the NPC, the 'No more quests available.' message pops up in the chat, can just be a bit annoying and maybe confusing for some players, can this be fixed?

Already fixed in https://github.com/FlyingPikachu/Quests/commit/a7d6ea8885c6eca89c67a438433844a74ffd06ce


Closed adding initial support for CSV batch ingest. dams5-cc-pilot #47

Related to https://github.com/ucsdlib/dams5-cc-pilot/issues/47

@ucsdlib/developers Please review, comments ... Thanks

@mcritchlow I've added commit https://github.com/ucsdlib/horton/pull/10/commits/db3662735228ddf6557949ae3a809bf2b5f100de to address the issues you suggested above. Please let me know if I miss anything. Thanks.

:+1:

👍


[msh3] update to 0.7.0

Library name
msh3
New version number
0.7.0
Other information that may be useful (release notes, etc...)
it needed to change also msquick:
https://github.com/microsoft/msquic/blob/v2.3.5/src/inc/quic_platform.h#L574
That needed c++ define:
https://github.com/microsoft/msquic/blob/v2.3.5/src/inc/quic_platform.h#L498
Not sure how to do that.
When I tried to update:
msh3.cpp.obj : error LNK2001: unresolved external symbol CxPlatGetSelfSignedCert
msh3.cpp.obj : error LNK2001: unresolved external symbol CxPlatFreeSelfSignedCert
bin\msh3.dll : fatal error LNK1120: 2 unresolved externals

ninja: build stopped: subcommand failed.

I am not sure how to compile these symbol. I know they are depends on define cpp: QUIC_TEST_APIS
https://github.com/microsoft/msquic/blob/v2.3.5/src/inc/quic_platform.h#L498
I tried to add it via port config with VCPKG_CXX_FLAGS with both define in msquic and msh3, but without success.

I create issue on upstream of msquic:
https://github.com/microsoft/msquic/issues/4569
I also suggested some solution:
https://github.com/microsoft/msquic/pull/4574
Let's see what happen.

Fixing by https://github.com/microsoft/vcpkg/pull/42788.


Create a label for discovery handlers issues/PRs and exclude it from stale bot

Create a new label to track issues and PRs related to adding a new discovery handler.
We can also update the stale action to use that to exclude it from the stale marking since those are ones that we will like to keep alive.

This is more of an enhancement/good to have rather than a bug IMHO.

Work to be done here:

Create new label for discovery handler work
Modify Akri stale bot
Add new issues template or extend feature issue template to recommend adding the label to the issue. But not everyone has permissions to add labels so unique issue template for discovery handlers could automatically add it (maybe?! this works for the default bug template)


feat: support wildcards and extensions in binary types

This PR adds support for wildcards in the binaryMimeTypes parameter. This allows for more flexibility when defining which responses should be base64-encoded.

Nice! I was going to add this this month. Could you add tests for this?

@brettstack I added two tests for wildcards and extensions.


ModuleNotFoundError: No module named 'PyQT5'

I keep getting this error and I am not sure why. I am running it in a virtual environment and below I have listed all the packages installed on the environment (Note pyqt5 is installed). I am just really confused.
(CS2316) D:\Varun\College\CS 2316 - Data Input and Manipulation\Participation>conda list
WARNING: The conda.compat module is deprecated and will be removed in a future release.
packages in environment at C:\Users\varun.conda\envs\CS2316:
Name                    Version                   Build  Channel
ca-certificates           2020.7.22                     0
certifi                   2020.6.20                py38_0
icu                       58.2                 ha925a31_3
jpeg                      9b                   hb83a4c4_2
libpng                    1.6.37               h2a8f88b_0
openssl                   1.1.1g               he774522_1
pip                       20.2.2                   py38_0
pyqt                      5.9.2            py38ha925a31_4
pyqt5                     5.15.1                   pypi_0    pypi
pyqt5-sip                 12.8.1                   pypi_0    pypi
python                    3.8.5                h5fd99cc_1
qt                        5.9.7            vc14h73c81de_0
qtpy                      1.9.0                      py_0
setuptools                49.6.0                   py38_0
sip                       4.19.13          py38ha925a31_0
sqlite                    3.33.0               h2a8f88b_0
vc                        14.1                 h0510ff6_4
vs2015_runtime            14.16.27012          hf0eaf9b_3
wheel                     0.35.1                     py_0
wincertstore              0.2                      py38_0
zlib                      1.2.11               h62dcd97_4
(CS2316) D:\Varun\College\CS 2316 - Data Input and Manipulation\Participation>python PE03.py
Traceback (most recent call last):
File "PE03.py", line 3, in
from PyQT5.QtWidget import QApplicaton, QWidget
ModuleNotFoundError: No module named 'PyQT5'

Hello,
Were you trying to run the GUI when the error occurs ? It seems that none of the pyleecan dependencies are installed. Did you run the command "pip install pyleecan" or did you download the software from Github ? More informations are available on the installation page: https://pyleecan.org/get.pyleecan.html
Can you also detail the content of your PE03.py script ?
Best regards,
Pierre

Hello,
It seems that you tried to import PyQt5 with an uppercase T. from PyQt5.QtWidget import QApplicaton, QWidget should solve this problem.

(CS2316) D:\Varun\College\CS 2316 - Data Input and Manipulation\Participation>python PE03.py
Traceback (most recent call last):
File "PE03.py", line 3, in
from PyQT5.QtWidget import QApplicaton, QWidget
ModuleNotFoundError: No module named 'PyQT5'

Best regards,
Cédric

Hello,
Thank you Pieere and Cedric for the responses. I had not installed pyleecan, only pyqt (that was the direction given to me by my teacher). Now I installed pycleecan from 'pip install', but that still didn't fix the issue. Additionally changing PyQT5 to PyQt5 didn't fix the issue. My environment now had the following packages:
Name                    Version                   Build  Channel
appdirs                   1.4.4                    pypi_0    pypi
ca-certificates           2020.7.22                     0
certifi                   2020.6.20                py38_0
cloudpickle               1.6.0                    pypi_0    pypi
cycler                    0.10.0                   pypi_0    pypi
deap                      1.3.1                    pypi_0    pypi
h5py                      2.10.0                   pypi_0    pypi
icu                       58.2                 ha925a31_3
imageio                   2.9.0                    pypi_0    pypi
jpeg                      9b                   hb83a4c4_2
kiwisolver                1.2.0                    pypi_0    pypi
libpng                    1.6.37               h2a8f88b_0
matplotlib                3.3.2                    pypi_0    pypi
meshio                    4.2.0                    pypi_0    pypi
numpy                     1.19.2                   pypi_0    pypi
openssl                   1.1.1g               he774522_1
pandas                    1.1.2                    pypi_0    pypi
pillow                    7.2.0                    pypi_0    pypi
pip                       20.2.2                   py38_0
pyfemm                    0.1.1                    pypi_0    pypi
pyleecan                  1.0.0                    pypi_0    pypi
pyparsing                 2.4.7                    pypi_0    pypi
pypiwin32                 223                      pypi_0    pypi
pyqt                      5.9.2            py38ha925a31_4
pyqt5                     5.15.1                   pypi_0    pypi
pyqt5-sip                 12.8.1                   pypi_0    pypi
python                    3.8.5                h5fd99cc_1
python-dateutil           2.8.1                    pypi_0    pypi
pytz                      2020.1                   pypi_0    pypi
pyvista                   0.26.0                   pypi_0    pypi
pywin32                   228                      pypi_0    pypi
qt                        5.9.7            vc14h73c81de_0
qtpy                      1.9.0                      py_0
scidatatool               1.1.2                    pypi_0    pypi
scipy                     1.5.2                    pypi_0    pypi
scooby                    0.5.6                    pypi_0    pypi
setuptools                49.6.0                   py38_0
sip                       4.19.13          py38ha925a31_0
six                       1.15.0                   pypi_0    pypi
sqlite                    3.33.0               h2a8f88b_0
vc                        14.1                 h0510ff6_4
vs2015_runtime            14.16.27012          hf0eaf9b_3
vtk                       9.0.1                    pypi_0    pypi
wheel                     0.35.1                     py_0
wincertstore              0.2                      py38_0
xlrd                      1.2.0                    pypi_0    pypi
zlib                      1.2.11               h62dcd97_4
Unfortuatly PE03.py is an assignment from a class and I am hesitant to post it online. However the issue is with this line:
from PyQt5.QtWidget import QApplicaton, QWidget
I appreciate the help.
Varun

Hello Varun,
An "s" is missing in PyQt5.QtWidgets. The line from PyQt5.QtWidgets import QApplication, QWidget doesn't raise any error on my side.
By the way, could you give us your teacher's email ? We are really interested in the educational resources using pyleecan and it would be great to share them to help people learn how to use it.
Best regards,
Cédric

Hello Cedric,
That managed to fix the issue, Thanks. I can't believe that all the time of troubleshooting was due to a simple spelling error. I want to let you know that I was a little confused earlier, I downloaded pyleecan as I felt it was necessary to run pyqt. My class isn't using pyleecan, simply pyqt for a GUI. If you are interested in reaching out to professors who use pyleecan I would recommend checking out the electrical engineering branches of various colleges. I know that pyleecan is used at my college, but I am not aware of any professors (just a few forum posts). If I do find someone who uses pyleecan I will let you know. Once again, thank you so much and sorry for the confusion.
Varun


cannot install on debian 10

Hi,
I was trying to install in this way but it did not work
alex@host:~$ sudo dpkg -i ./wireguird_amd64.deb
dpkg-deb: error: archive './wireguird_amd64.deb' uses unknown compression for member 'control.tar.zst', giving up
dpkg: error processing archive ./wireguird_amd64.deb (--install):
dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
./wireguird_amd64.deb

i just tried the version v1.1.0, the result:
alex@laptop:~/Downloads/deb$ sudo apt install ./wireguird_amd64.deb
Reading package lists... Error!
E: Sub-process Popen returned an error code (2)
E: Encountered a section with no Package: header
E: Problem with MergeList /home/alex/wireguird_amd64.deb
E: The package lists or status file could not be parsed or opened.

Debian 11:
alexbh@apfelbaum:~/Downloads/deb$ sudo apt install ./wireguird_amd64.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'wireguird' instead of './wireguird_amd64.deb'
The following NEW packages will be installed:
wireguird
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/2,682 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /home/alexbh/Downloads/deb/wireguird_amd64.deb wireguird amd64 1.1 [2,682 kB]
dpkg-deb: error: archive '/home/alexbh/Downloads/deb/wireguird_amd64.deb' uses unknown compression for member 'control.tar.zst', giv
ing up
dpkg: error processing archive /home/alexbh/Downloads/deb/wireguird_amd64.deb (--unpack):
dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
/home/alexbh/Downloads/deb/wireguird_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Adding support to mtex2MLL for mathml generation

Including the mtex2MLL C library for fast offline MathML generation.
I included the sources and updated the makefile to compile with the library, updated the html to generate (when chosen) the MathML .
However could be cleaner to simply depending from the library instead of including the sources it in the project.

any chance to have a release ?


Make experimental feature PSAMSIMethodInvocationLogging stable

PR Summary
PS-Committee reviewed this and agreed that based on validation by AMSI team, this feature is ready to be stable for 7.3
PR Context
Per https://github.com/PowerShell/PowerShell/issues/17962 making this feature non-experimental
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

Please look #18033 before merge.

@SteveL-MSFT  I verified issue #18033, and we should address it before we make this feature non-experimental.

Convert to draft until #18033

Turns out it has a big negative impact on performance even if it is slightly improved in #18060>
In #18060 I made my arguments in more detail and I am against this feature.

/backport to release/v7.3.0-rc.1

/backport to release/v7.3.0-rc.1


texvc to tex conversion table

@pkra are you still interested in texvc... I reimplemented everything from scratch really minimal
Please also check the licensing issue and the minified javascript… I could not find documentation on this is done for mathjax

Yes definitely still interested in this (especially if it helps your work on MediaWiki/Wikipedia!).
Can you make the pull request to the develop branch, please? master is our stable release branch.
Would be ok to rename this to something like "MediaWiki.js"? I think people are more likely to understand what's behind that and it would make it easier for contributors to identify.
(Just FYI, we don't need packed versions; we repack for testing and releases anyway. And thanks for the demo file; our test suite is separate but for now we can proceed without tests).

Changing to develop is not possible (see https://github.com/isaacs/github/issues/18)
So I close this pull request. See #1003 for the new pull request.


pkg/action: needs a way to use cached(once) kube client

Background
In latest  v3.7.1 release codebase , when helm inits the action Configuration helm also inits the kubeClient Factory provided by the kubectl there . For using helm as cli for most scenario ，it's ok because the process will return and the CachedOpenAPIParser created by kubectl will be released at mostly once .
However , for using helm as SDK(library) scenario , we Init the action.Configuration at every deployment reached , we saw that the memory grows rapidly when we have some more concurrent deploy tasks(use helm action upgrade and install) but the Go[^1] GC follows slowly , so our build pipeline service OOMed and then exited.
Here is the (alloc_space) pprof (related part):

The memory spike should be bigger , sorry I lost the most spike one and replaced with the middle one :(

Just-work-solution
we now work out a solution that make the per [cluster,namespace] as keyed Configuration cached at our pipeline service side . So that it will just create one kubectl Factory per [cluster,namespace].
And it just works , but since we cannot init the kubectl Factory by ourself , the duplicate kubectl Factory created by Configuration.Init still exists .
Suggestion for helm codebase
It's better that Configuration.Init can let sdk developer to pass the cached kubectl Factory in or package action can provide us the self cached kubectl Factory . Something maybe like this:
func InitWithKubeClient(c *kube.Client,namespace, helmDriver string, log DebugLog) error {
	if c == nil {
		return errors.New("kube client is nil")
	}
	c.Log = log

	lazyClient := &lazyClient{
		namespace: namespace,
		clientFn:  c.Factory.KubernetesClientSet,
	}
	...
}

Let me know if you need more additional details  and I am free for raising PRs these days if you need .
[^1]: Go version: 1.16.1

Hi @scbizu. A similar question was asked in https://github.com/helm/helm/issues/9913.
The code path you identified comes from packages produced by the Kubernetes project that Helm imports in order to interact with Kubernetes clusters. It looks like they have to do with one of two things:

Loading the OpenAPI schema
Validating manifests against the OpenAPI schema

If it's 1), then yes, re-using a cached OpenAPIParser may reduce the overall memory footprint.
If it's 2)... Then the memory spike occurs when the manifests are being validated against the schema. Not much you can do there except optimize the validation code.
Disabling OpenAPI schema validation altogether with the --disable-openapi-validation flag may also reduce the memory footprint, but then your manifests would not be validated before sending it to the cluster which can result in very odd edge cases.
An alternative approach may be to limit the number of concurrent jobs your build pipeline service can run at any given time to ensure it will not run out of memory. Not ideal, but it would prevent these issues from occurring.

we now work out a solution that make the per [cluster,namespace] as keyed Configuration cached at our pipeline service side . So that it will just create one kubectl Factory per [cluster,namespace].

I'm curious... If you run the profiler with those changes intact (re-using a cached OpenAPI client), what's the result?

I'm curious... If you run the profiler with those changes intact (re-using a cached OpenAPI client), what's the result?

we optimize these changes last week and the spike goes down ,  we haven't analyzed the pprof since then , but after this approach tested in my local test env ,via pprof this should work (not perfectly as I expected) .

An alternative approach may be to limit the number of concurrent jobs your build pipeline service can run at any given time to ensure it will not run out of memory.

Yep , we do this at once . But the 「limit number」 should be differ from every manifests size , we can not determine a right 「magic number」to cover it .
I think I can self-follow this topic and work out a version to see whether it's worth to cache the parser at helm side ?


Readme wording suggestions

This is a suggested fix for #197.
I've also included undocumenting the watcher here as well, but can remove that if we do want to keep it too.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #202   +/-   ##
=======================================
  Coverage   67.87%   67.87%
=======================================
  Files          12       12
  Lines         579      579
=======================================
  Hits          393      393
  Misses        186      186

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 69b6031...a32382d. Read the comment docs.


findOne with Object Id with toString filter fails

The following currently fails where the insertedId is of type ObjectId :
const doc = await db.collection(collectionName).findOne({ _id: insertedId.toString() });

More context here: https://github.com/stargate/stargate-mongoose/pull/214/files#diff-4405e0935552ddb1ffac14d14f5d399dec7b7094df2d7a1810414d5f6685568bR199
cc: @vkarpov15

@kathirsvn I opened up issue for this here: https://github.com/stargate/data-api/issues/1045. Looks like it is expected behavior in data-api. I'll put in PR to remove this test.


Seungheonoh/npm submodule

Closes #1457.
Pre-review checklist

[x] All code has been formatted using our config (make format)
[ ] Any new API features or modification of existing behavior is covered as defined in our test plan
[ ] The changelog has been updated under the ## Unreleased header, using the appropriate sub-headings (### Added, ### Removed, ### Fixed), and the links to the appropriate issues/PRs have been included

Fixed

package.json and package-lock.json are expected to be a file to be used in node2nix. Not much can be done here

@aciceri bump

Thanks for the review. I haven't consider using output of derivation as a submodule. Mainly, it was intended for subdirectories.
Because I was mainly considering subdirectories, builtins.baseNameOf was good as it gave concise and consistent paths to be imported in package.json. That being said, I'm also happy with explicit path.

@klntsky In my opinion it's already mergeable.

Once again bumping this PR :)
@klntsky
If it needs a rebase, or whatnot I'd be happy to help.


Cannot work with pnpm

After upgrading to 0.9.2, can't use with pnpm any more.
Reproduce:
npx create-electric-app@latest test
cd test
# change version of electric-sql to 0.9.2
pnpm install
pnpm add zod
pnpm backend:start
pnpm db:migrate
pnpm client:generate
pnpm build

Error:

><EMAIL_ADDRESS>build /private/tmp/test2/test
> tsc && vite build

src/generated/client/index.ts:3:38 - error TS6133: 'Relation' is declared but its value is never read.

3 import { type TableSchema, DbSchema, Relation, ElectricClient, type HKT } from 'electric-sql/client/model';
                                       ~~~~~~~~

src/generated/client/index.ts:63:14 - error TS2322: Type 'ZodObject<{ value: ZodOptional<ZodString>; }, "strict", ZodTypeAny, { value?: string | undefined; }, { value?: string | undefined; }>' is not assignable to type 'ZodType<ItemsWhereUniqueInput, ZodTypeDef, ItemsWhereUniqueInput>'.
  Types of property '_type' are incompatible.
    Type '{ value?: string | undefined; }' is not assignable to type 'ItemsWhereUniqueInput'.
      Type '{ value?: string | undefined; }' is not assignable to type '{ value: string; } & { value?: string | undefined; AND?: ItemsWhereInput | ItemsWhereInput[] | undefined; OR?: ItemsWhereInput[] | undefined; NOT?: ItemsWhereInput | ... 1 more ... | undefined; }'.
        Type '{ value?: string | undefined; }' is not assignable to type '{ value: string; }'.
          Types of property 'value' are incompatible.
            Type 'string | undefined' is not assignable to type 'string'.
              Type 'undefined' is not assignable to type 'string'.

63 export const ItemsWhereUniqueInputSchema: z.ZodType<Prisma.ItemsWhereUniqueInput> = z.object({
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~

Found 2 errors in the same file, starting at: src/generated/client/index.ts:3

The first issue occurs because our generator does not remove the import for Relation if it is not used by the actual schemas. You can fix the issue by removing the import for Relation while waiting for us to fix the generator accordingly. I'm not exactly sure why the second issue occurs. Hard to tell without knowing your DB schema. If you can provide your DB schema we can try to reproduce these errors. In any case, these are type errors in the generated client, you can unblock yourself for now by adding a // ts-ignore above line 63.

@kevin-dp The DB is very simple
/* This is an example of an SQL DDL migration. It creates an `items` table and
 * then calls an `electric.electrify` procedure to expose the table to the
 * ElectricSQL replication machinery.
 *
 * Note that these statements are applied directly to the *Postgres* database.
 * Electric then handles keeping the local SQLite database schema in sync with
 * the electrified subset of your Postgres database schema.
 *
 * See https://electric-sql.com/docs/usage/data-modelling for more information.
 */

-- Create a simple items table.
CREATE TABLE IF NOT EXISTS items (
  value TEXT PRIMARY KEY NOT NULL
);

-- ⚡
-- Electrify the items table
ALTER TABLE items ENABLE ELECTRIC;

(It's just created by create-electric-app)

This doesn’t seem to have any particular issue. It should just work. @kevin please try to run commands from 0.9.2

The second issue looks like the same problem as in issue #1001, and thus potentially solved by PR #1016.

Closing this in favour of keeping https://github.com/electric-sql/electric/issues/1001 open as they refer to the same issue.
Make sure that your tsconfig.json compiler options has strict set to true (and strictNullChecks not set to false as it invalidates some of the "strictness" required by Zod, the schema validator).
The Related unused import will be fixed by https://github.com/electric-sql/electric/pull/1117.


S.identifier after S.attachPropertySignature is ignored, makes errors less useful

What version of @effect/schema is running?
0.56.0
What steps can reproduce the bug?
const NoAttachedProperty = S.struct({
  $ref: S.string,
}).pipe(S.identifier("NoAttachedProperty"));

const works = S.parseEither(NoAttachedProperty)("foo");

// The expected schema identifier is rendered by `formatErrors`:
// error(s) found
// └─ Expected NoAttachedProperty, actual "foo"
console.log(
  Either.isLeft(works) ? formatErrors(works.left.errors) : ""
);

const AttachedProperty = S.struct({
  $ref: S.string,
}).pipe(S.attachPropertySignature("_tag", "a"), S.identifier("AttachedProperty"));

const noWorks = S.parseEither(AttachedProperty)("foo");

// error(s) found
// └─ Expected <anonymous type literal schema>, actual "foo"
//                  ^ The expected schema identifier is not rendered
console.log(
  Either.isLeft(noWorks) ? formatErrors(noWorks.left.errors) : ""
);

What is the expected behavior?
I would expect formatErrors to render the following tree with the passed identifier:
error(s) found
└─ Expected AttachedProperty, actual "foo"

What do you see instead?
error(s) found
└─ Expected <anonymous type literal schema>, actual "foo"

Additional information
AST.to recurses into the to child from the Transform parent node ignoring the annotations, resulting in significantly less useful error messages. I've described this issue with regard to a particular situation I ran into but this would apply to any similar situation where annotations are added to a transform node.

https://github.com/Effect-TS/effect/pull/1842


elvish is not killed when terminal is closed

If you open and close terminal again and again, you will get many elvishes.
uiyiqun 21511  0.0  0.1<PHONE_NUMBER>4 pts/1    Ssl  13:56   0:00 -elvish
huiyiqun 26272  0.0  0.2<PHONE_NUMBER>4 pts/3    Ssl  14:03   0:00 -elvish
huiyiqun 27529  0.4  0.1<PHONE_NUMBER>4 ?        Ssl  14:05   0:00 /usr/bin/elvish
huiyiqun 27536  0.0  0.0   4160   672 ?        S    14:05   0:00 ps aux | grep elvish
huiyiqun 27711  0.5  0.2<PHONE_NUMBER>8 ?        Ssl  14:05   0:00 /usr/bin/elvish
huiyiqun 27717  0.0  0.0   4160   640 ?        S    14:05   0:00 ps aux | grep elvish
huiyiqun 27771  0.5  0.1<PHONE_NUMBER>2 ?        Ssl  14:05   0:00 /usr/bin/elvish
huiyiqun 27777  0.0  0.0   4160   628 ?        S    14:05   0:00 ps aux | grep elvish
huiyiqun 27843  1.0  0.1<PHONE_NUMBER>4 ?        Ssl  14:05   0:00 /usr/bin/elvish
huiyiqun 27849  0.0  0.0   4160   624 ?        S    14:05   0:00 ps aux | grep elvish
huiyiqun 27897  1.0  0.1<PHONE_NUMBER>6 pts/6    Ssl  14:05   0:00 /usr/bin/elvish
huiyiqun 27904  0.0  0.0   4160   724 pts/6    S+   14:05   0:00 ps aux | grep elvish
huiyiqun 27957  0.0  0.0  12496  2156 pts/6    R+   14:05   0:00 /usr/bin/grep --color=auto elvish

Perhaps related to handling of SIGHUP.

This seems partially fixed by 36271874d8ddb2519739aa431564e857b5a52945.
Currently, simply starting and closing window will make elvish killed, however, if I running some external
command in elvish, it will not be killed.
For example:
~> sleep 100

then close the terminal, and open another one:
~> ps aux | grep sleep
huiyiqun  3625  0.0  0.0   8568   672 ?        S    21:08   0:00 /usr/bin/sleep 100
huiyiqun  3655  0.0  0.0  13508  2192 pts/2    S+   21:08   0:00 /usr/bin/grep --color=auto sleep

If I run esleep, the elvish will be killed.

I'm using Tilix as a terminal emulator and I'm experiencing the following problem:
when I close a pane running elvish inside of tilix, the shell doesn't seem to be killed:
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=10912, si_uid=1000} ---
futex(0x55a6470387c0, FUTEX_WAKE, 1)    = 1
rt_sigreturn({mask=[]})                 = 202
futex(0x55a64701ca70, FUTEX_WAIT, 0, NULL

I.E. SIGHUP is not honored as it can be seen from strace output.

This is fixed in #494.


DistanceJoint getReactionForce function not working

I get an error when using getReactionForce with distance joints because this.m_u is undefined
/**
 * Get the reaction force on bodyB at the joint anchor in Newtons.
 */
DistanceJoint.prototype.getReactionForce = function (inv_dt) {
    return Vec2.mulNumVec2(this.m_impulse, this.m_u).mul(inv_dt);
};

Also these functions need a timeStamp as input (I think) which could be better documented.

p5play discord user @ metamere said that the .initVelocityConstraints(step) function needed to be run

I guess we need to initialize m_u to zero so that getReactionForce returns zero before the joint is activated. @zOadT what do you think?
Thanks for the feedback for the doc, I will update it.

Hey! Haven't looked too much into it, but I also think initialising m_u to zero should be fine and reflect what the C code does. Maybe we also should do this for other Vec2 etc properties?
Later we could think about whether we want to reuse the vector instead of reassigning a newly created one or if we want to keep the vector constant.


History error with UNC

Issue Type: Bug
Similar to https://github.com/eamodio/vscode-gitlens/issues/208
Looks like the bug was reintroduced in 9.0.0 or 9.0.1
The history is shown but errors are being produced while you browse:
fatal: Invalid path '//ServerIpOrName//ServerIpOrName': No such file or directory
cannot open file://ServerIpOrName//ServerIpOrName/c%24/File.ps1. Detail: A system error occurred (UNKNOWN: unknown error, stat '\\ServerIpOrName\ServerIpOrName\c$\File.ps1')

Extension version: 9.0.1
VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:13:36.375Z)
OS version: Windows_NT x64 10.0.17134

@ili101  if this was helpful to you, consider giving a reward to the issue solver using Speedoss.com


repo: add branch_upstream_remote refname doc (#1055)

Adds the full refname format for the documentation
Closes #1055

This is my first time contributing to a Rust project so please let me know if the doc format is wrong or if any changes are required!


[feat] Reentrancy Guard

Reentrancy Guard

i'd like to work on this

Hi, I'd like to work on this one; I went through the linked issue in the description; but could you please elaborate on this issue a bit please. Which contract(s) do we have to apply the modifier to?


Google Maps Workaround?

[x] Issue does not already exist
Identify exactly what aspect your issue is about

[?] ignite base application
[ ] ignite the cli
[?] ignite generated code

So I realize Google Maps View generator was removed about a month ago because issues, however I really really need to get maps working with this here. I'm trying to use react-native-maps library... Somebody mentioned a way they got it working here(#237), but it doesn't work for me. I have started a clean ignite-less react app, followed the install instructions for manual installation of native dependencies, and got it working. However when I try to bring that code to my Ignite-based app and follow the same steps, I get "Unfortunately MyApp has stopped" whenever I try to start the app (app is successfully built tho). I would seriously appreciate any help. Thanks!
Also, here's the output from ignite doctor:
Computer
  Platform: darwin

Ignite
  Version: 1.5.0
  Path: /Users/Charlieigg/.nvm/versions/node/v6.3.0/bin/ignite

Node
  Version: v6.3.0
  Path: /Users/Charlieigg/.nvm/versions/node/v6.3.0/bin/node

NPM
  Version: 3.10.6
  Path: /Users/Charlieigg/.nvm/versions/node/v6.3.0/bin/npm

Yeoman
  Version: 1.8.4

React Native CLI
  Version: 1.0.0

App
  React Native Version: 0.31.0

Sounds like you have multiple versions of Google's app compat library.
Try this:
rm -rf android/build
rm -rf android/app/build
grep appcompat-v **/*.gradle

If you run this from your project directory (where your packages.json lives), it should descend into your node_modules and pick up anywhere where 3rd party libs want to use app compat.

TYVM for your answer @skellock. I tried exactly those lines in the root of my project but only get the following output without the mention of appcompat as it show in your screenshot:
android/build.gradle:// Top-level build file where you can add configuration options common to all sub-projects/modules.
android/build.gradle:
android/build.gradle:buildscript {
android/build.gradle:    repositories {
android/build.gradle:        jcenter()
android/build.gradle:    }
android/build.gradle:    dependencies {
android/build.gradle:        classpath 'com.android.tools.build:gradle:1.3.1'
android/build.gradle:
android/build.gradle:        // NOTE: Do not place your application dependencies here; they belong
android/build.gradle:        // in the individual module build.gradle files
android/build.gradle:    }
android/build.gradle:}
android/build.gradle:
android/build.gradle:allprojects {
android/build.gradle:    repositories {
android/build.gradle:        mavenLocal()
android/build.gradle:        jcenter()
android/build.gradle:        maven {
android/build.gradle:            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
android/build.gradle:            url "$rootDir/../node_modules/react-native/android"
android/build.gradle:        }
android/build.gradle:    }
android/build.gradle:}
android/settings.gradle:rootProject.name = 'RNTaxi'
android/settings.gradle:
android/settings.gradle:include ':app'
android/settings.gradle:include ':react-native-vector-icons'
android/settings.gradle:project(':react-native-vector-icons').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-vector-icons/android')
android/settings.gradle:include ':react-native-i18n'
android/settings.gradle:project(':react-native-i18n').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-i18n/android')
android/settings.gradle:include ':react-native-device-info'
android/settings.gradle:project(':react-native-device-info').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-device-info/android')

Note: I had to type in grep appcompat -v **/*.gradle instead of grep appcompat-v **/*.gradle to get any output at all. Your help and ideas are appreciated.

Just got 0.31 working with latest maps.  Here's some info, not sure if it's help :)  Always hard to debug without the code on my machine.  I can tell you I had the exact same issue, and I got passed it, but might not remember the exact steps on how.
From what I'm reading, you're going after Android yes?
Firstly, make sure you're pointing at master in package.json with this:
"react-native-maps": "git@github.com:lelandrichardson/react-native-maps.git",
I don't believe they've released since @skellock 's additions.
Next,  be sure to adb logcat when you run your project (react-native log-ios if you're doing iOS).  This will give you the info you're missing when your app crashes.
Lastly, close packager, any IDE's and stop debugging and close simulators, then run these commands in this order to destroy any cache.   https://raw.githubusercontent.com/GantMan/mobile-commander/master/bin/newclear.sh
Hopefully, that will clear any ghosts in the machine, if that's the issue.
The above steps will give you some info either fix the issue, or give us some info to chew on.  We'll get this puppy working 👍

Thank you @GantMan, after following your steps it didn't work, but I had no idea add logcat existed. After taking a look at the logs, Googling around and testing several different things adding these three lines to the gradle got it working:
compile "com.google.android.gms:play-services-base:8.4.0"
 compile 'com.google.android.gms:play-services-maps:8.4.0'
 compile 'com.google.android.gms:play-services-gam:8.4.0'


Ctrl+Tab not working when integrated terminal has focus

VSCode Version: Code - Insiders 1.8.0-insider (fb8939b09460ff9fbd40d39056b54c88d5aad9c8, 2016-11-11T13:12:38.741Z)
OS Version: Darwin x64 15.6.0
Extensions:

Extension
Author
Version

EditorConfig
EditorConfig
0.3.4

vscode-docker
PeterJausovec
0.0.7

regex
chrmarti
0.0.6

vscode-eslint
dbaeumer
1.1.0

ghlink
dt
0.0.4

gitlens
eamodio
0.5.5

tslint
eg2
0.5.40

PowerShell
ms-vscode
0.7.2

debugger-for-chrome
msjsdiag
2.2.2

diff
rafaelmaiolla
0.0.1

kustovscode
seanmcbreen
0.0.1

vscode-open-in-github
sysoev
1.2.1

Steps to Reproduce:

Open 2 editors
Focus integrated terminal
Try to use Ctrl+Tab to cycle through the editors
-> bash will interprets it as 'Tab' it seems

As designed, but I've been wanting to include it in commandsToSkipShell by default for a while now, along with ctrl+shift+tab.


Can't open damage rolls.

When rolling damage, you can no longer open the drop down to see what the dice rolls are. Doing so will either do nothing, or may crash foundry. Tested on a new world and issue still persisted.

I am assuming Foundry V10?
Yeah, when I click to expand the damage, my chat goes from this:

to this:

You will notice the chat log (and the players list and hotbar and modifierbucket...) have all moved up.    At least the dice did display (you have to scroll the chat log to see them).
Now if I can just play on 1/2 the screen.  :-(
I've been searching for a bit, and I can't find the code that is expanding the dice area... I assume we have clobbered some of Foundry's newly changed CSS.

I've put something in for the next release... but I honestly can't tell if it is fixing it.   But I can't seem to recreate it with the fix in, so I am going to assume.   Please test with the new version when you get a chance.
NOTE:   A work around "seems" to be deleting the chat log and restarting (F5).

Closed as fixed


ocamlPackages.nbd: init at 1.20.2

Enable compilation of ocaml bindings in the main libnbd derivation, and expose them in ocamlPackages.
Needed for virt-v2v.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

The OCaml bindings require a “recent” version of the compiler. Wrong configurations can be detected at evaluation time, e.g. by adding the following assertion:
--- a/pkgs/by-name/li/libnbd/package.nix
+++ b/pkgs/by-name/li/libnbd/package.nix
@@ -16,6 +16,9 @@
   autoreconfHook,
 }:

+lib.throwIf (buildOcamlBindings && !lib.versionAtLeast ocamlPackages.ocaml.version "4.05")
+  "OCaml binding are not available for OCaml < 4.05"
+
 stdenv.mkDerivation rec {
   pname = "libnbd";
   version = "1.20.2";

My apologies, I assumed you wanted to fail evaluation here. Just a non-failing trace seems odd, and would just lead to a build failure if it triggered.

The documentation for throw highlights the difference with assert.
However, in practice, I cannot spot any run-time difference between before and after the change you propose. So my question stay: why do you suggest this change?

Consistency with other packages, mostly. I haven't seen a library function just called before the actual derivation function like that; usually it's an assert that precedes derivation calls for handling... assertions.
Also, wouldn't the && operator fail if we aren't building OCaml? The logical implication seems to make more sense here IMO.

There are a few instances of this pattern in the repo, e.g.: https://github.com/NixOS/nixpkgs/blob/5190ddc27dc6a083df998f50abb38557932d80b0/pkgs/games/dwarf-fortress/wrapper/default.nix#L144-L148
The condition you wrote is exactly the negation of the other one.