[Preview 2] - Removing project from solution, something keeping access lock

Preview 2 tooling.
I open the solution in VS, and add a new project to it. Realising I had giving it a crappy folder name, I remove it from the solution. I then attempt to rename the folder in windows explorer but can't because something is still keeping a lock:

I wouldn't expect things to still be accessed after removing the project from the solution. Having to restart VS just to be able to rename a folder is not a nice experience!

This issue is being closed because it has not been updated in 3 months.
We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.


vscode go to definition doesn't work

clone this very small mwe
open the repo with vscode

In A.sol, I can't ctrl+click on B.sol in the import. If I remove the fallback function, it works !
Can you reproduce this ? Same behaviour on Linux, Windows. I've reinstalled extension, and deleted .vscode .code repo plenty of times, with no results.

Thanks for the great example ♥, I'll investigate.

@Fabien-Morrow it should be fixed on the latest.


Use fallback in setSelection to fix chrome bug

In some cases with Chrome the selection is empty after calling collapse, even when it should be valid. This appears to be a bug, but it is difficult to isolate. If this happens fallback to the old path without using extend.
See discussion

Thanks @marijnh


guide: start sagemaker page

First draft of a page about sagemaker integration. Related: #4724.

I think a lot of people use Sagemaker for the Sagemaker Model registry and Sagemaker Endpoints. It would be good to connect this guide to something like the MLEM blog article for now and then perhaps connect the dots by having a demo for the entire workflow (starting with what you have here @dberenbaum and then DVC Model registry + deployment to Sagemaker Endpoints). I guess that demo is something I could take a look at (although I'd have to see when)

@daavoo and @tapadipti are both already working on deploying with Sagemaker Endpoints, and the next follow-up here should be to add that (see https://github.com/iterative/dvc.org/issues/4724#issuecomment-1679483943). I think we have enough support here already @tibor-mach, but thanks for the offer!


Update gogs upgrade information

It seems that migrating from Gogs 0.12.x and above may require more work as time goes on and the projects continue to diverge.
This PR updates the docs to make it more clear.

It's better to put some more feasible methods there, and suggest users do not do the "difficult" migrations (eg: adopt the git repositories directly). Otherwise it might cause strange problems for Gitea in the future, and make Gitea developers frustrated to help with the strange problems.

It's better to put some more feasible methods there, and suggest users do not do the "difficult" migrations (eg: adopt the git repositories directly).

I considered that, however there isn't a good page to direct to for adopting repositories, so I wasn't entirely sure if it was worth saying "adopt the repos instead" without also explaining how that works, etc.


Build the database

Setup the database using PostgreSQL

Put here the link to the DB schema for reference to obtain a detailed non-technical POV.


chore(FX-3610): Pass correct owner type to analytics for saved search alerts screen

The type of this PR is: Chore

This PR resolves FX-3610
Description
For the screen view on the SavedSearchList screen on an app (the list of all Saved Alerts under settings on the app), we fire a pageview with context_screen_owner_type = SavedSearches where it should be savedSearch

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Pass correct owner type to analytics for saved search alerts screen - dimatretyak

This PR contains the following changes:

Dev changes (Pass correct owner type to analytics for saved search alerts screen - dimatretyak)

  Generated by :no_entry_sign: dangerJS against a82ad0477a0fb30d4cb234727a6a4f3bf8c0c4bf


UINavigationBar.appearance().titleTextAttributes is not working on 4.2.0

Hi all!!
Im using the next code on 4.2.0 and its no working.
On the 4.1.7 works
UINavigationBar.appearance().titleTextAttributes = [             NSAttributedString.Key.font: Fonts.robotoMedium.withSize(18),             NSAttributedString.Key.foregroundColor: Color.mainRed         ]
Im getting the title on other font and white color for >iOS 13 and black color for <iOS 13

Fixed! Thanks!!!

This will be fixed on the next Cocoa release ?

Yes, shipped today(or tomorrow) with 4.2.0

Thank you!


Added user stats functionality with API route

Progress towards fixing #14. Still needs to connect with the racing portion which will make function calls to update user stats.
Added UserStats database schema that tracks user wins and total user races. Whenever a new user signs up, they will be entered into this database with default values of 0 for both wins and races. The updateStats function will update these stats properly depending on if the given user won the race or not.
Also added an API route /stats/:username that returns the user's wins and total races.

Just a thought for something that could be added later: Keep track of Races using a RaceSchema. The RaceSchema would track the problem name (and maybe)problem difficulty, winning user, and all participating users. Then additional detail about a user's race history could be displayed on their profile.


I can help in extension UI ...

U think i can help in the design of the extension
but can you please guide me on how to test it in my PC so that i can see changes

To test the extension:

Clone / Download+Extract this repo.
Go to the Chrome extensions page (chrome://extensions/) and enable "Developer mode".
Click "Load Unpacked" and select the cloned/downloaded extension folder.
Click in the "W" logo in the extension bar to see the "popup.html" file.

I don't think login will work until the extension as been published to the store (will require a custom Client ID and Redirect URL).

I'll move the extension testing information to the readme file. If you encounter any problems, fell free to open another issue.


Allow to use a whole local directory as IaC source

Q
A

🐛 Bug fix?
no

🚀 New feature?
yes

⚠ Deprecations?
no

❌ BC Break
no

🔗 Related issues
#253

❓ Documentation
yes

Description
Allow to use a whole local directory as IaC source.
⚠ Does not follow symlinks within root folder

Need to change all multiples to multiple.

Sure nice catch 🙏🏻

I tested it like you did which works perfectly. But we're gonna have problems with people who would like to use it with a folder like this one below which seems pretty normal in terragrunt environment if I remember well:

This is a real question, it can totally be done in this PR but I don't know exactly what we want to do.
The .tfstate extension is not enforced by terraform at all, so I don't think we can hardcode a check on this extension.
Maybe it's the responsibility to the user to specify the pattern in the --from argument with a glob pattern for example.
I had in mind something like THAT

This is a real question, it can totally be done in this PR but I don't know exactly what we want to do.
The .tfstate extension is not enforced by terraform at all, so I don't think we can hardcode a check on this extension.
Maybe it's the responsibility to the user to specify the pattern in the --from argument with a glob pattern for example.

Agree we must not hardcode a check on any extension. Either it's gonna be the user who would specify a pattern like you did or if it's possible we could check if a file is a terraform state but I can't find a method in their repo that does that yet ...
I'd say we could first ship this PR with the changes I requested, then ask @sjourdan about his view and finally decide which way to go.

This is a real question, it can totally be done in this PR but I don't know exactly what we want to do.
The .tfstate extension is not enforced by terraform at all, so I don't think we can hardcode a check on this extension.
Maybe it's the responsibility to the user to specify the pattern in the --from argument with a glob pattern for example.

Agree we must not hardcode a check on any extension. Either it's gonna be the user who would specify a pattern like you did or if it's possible we could check if a file is a terraform state but I can't find a method in their repo that does that yet ...
I'd say we could first ship this PR with the changes I requested, then ask @sjourdan about his view and finally decide which way to go.

Can't we use magic number to check ? I'm not sure there is an identification for tf state tho.

The scope of ticket in this release was just to be able to use a batch of tfstate inside a repository. We talked about blob filtering but this was more intended as a first step from what I remember.


Possibility of making TROCR recognize numbers alone

Hey, As others have mentioned before, your model works nicely with single-line text. Kudos for that! :tada:
I have been testing the pretrained handwritten model to recognize numbers, but it gets confused with words sometimes like 0 turns out to be 'o', So just wondering if there is any possibility of configuring the pre-trained model to recognize numbers alone?

Hi wolfshow,
Is it possible to read non-latin languages? Or is there anyway to train a model that can read non-latin languages?
Thank you

@wolfshow
s it possible to read non-latin languages? Or is there anyway to train a model that can read non-latin languages?
Thank you

@TheMightyRaider Thanks for the interest!
If you would like to recognize numbers only, you may conduct the constrained decoding from beam search, which you may allow digit BPEs only.

How to perform this? -> constrained decoding from beam search
Some changes in the code?


Is this the reason why my GPU is always high when using Franz?

https://github.com/meetfranz/franz/blob/024fb395d6a01db714b5d2eda2314fc635f0e8c9/src/models/User.js#L57

WHAT? Is Franz mining in the background?


Warn users about Qt.py-only functionality

As a user and developer I would like to be notified when using backward or forward compatibility  methods when using them.

Worth using python warning system , https://docs.python.org/2/library/warnings.html
so we can filter them through the logging system as well.

Thanks @hdd.
I agree this would be good and I've got in mind one way of achieving this, but it comes at a cost. The cost is likely too high, so I'm interested in alternative ways of achieving this result.
The idea
The inherent problem of triggering anything when accessing a member variable, such as QtWidgets.QWidget versus QtGui.QWidget is that there isn't any code inbetween asking for this member and getting it.
The idea is to convert QtWidgets from being a module into being an object and override __getattr__ such that asking for a member would allow us to trigger these warnings.
class QtWidgets(object):
  def __getattr__(self, attr):
    warnings.warn("Not backwards compatible!")
    return getattr(PyQt5.QtWidgets, attr)

Qt.QtWidgets = QtWidgets()

I'm a bit weary however of doing this, as we would move away from wrapping a module - e.g. PySide.QtGui - with another module to wrapping it with a class, possibly and most likely breaking all sorts of things.
Alternative
So, what's another way of achieving this?

agree that would be the ideal way of doing it , but I found issues on wrapping the classes and replace them in place as you are describing. Especially when you retrieve the class from another instance and not from the top module (Qt).  Using unbounded methods (function patching) seems to be working fine so far.
I would suggest to keep going with unbound methods for the time being, while looking into a proper way to have the full widget/object class patched with bound methods, so users can use and test the module and implementation in the meanwhile.

Using unbounded methods (function patching) seems to be working fine so far.

Could you show an example of this?

You can see this in use on #98 where I patch the translate function as well as in #96 for the headers.
This allow you to retrieve the header from the instanced object and access the patched method.
These patched methods results to be unbounded.

Sure, that shouldn't be a problem.
Did you not also want warnings when users try and use, e.g. QtGui.QWidget when they should have used QtWidgets.QWidget? Or was it strictly related to direct function calls?

If we assume all the bindings will be mirroring the PySide2/Qt5 implementation , guess is not needed...
but I'm up for chatting about it. (just trying to avoid to bloat the shell with too many info, which are distracting)
I think is more important to notify the users when they try to use/access something is not supposed to be there in the implementation they are using.

I think is more important to notify the users when they try to use/access something is not supposed to be there in the implementation they are using.

Yeah, I think that could be helpful too. I'm just not sure how to technically achieve this..
Perhaps some form of external linting process?
$ python -m Qt.py --check my_module.py
my_module.py:L54: QtGui.QWidget should be QtWidgets.QWidget
my_module.py:L107: QtCore.pyqtSignal should be QtCore.Signal
...

If it aligns with how other linters output their warnings, maybe something along those lines could later be integrated with native linters, like Sublime-Linter and such.

I'm more thinking of providing warnings from within the patched methods:
import warnings

def myPatchedMethod(*args, **kwargs):
         warnings.warn(
        "shouldn't use this function anymore! Now use XYZ.",
        DeprecationWarning
    )
      return something(*args, **kwargs)

Ah, ok. Which functions should we add this warning too? Do you mean when we choose to upgrade and deprecate our own functionality?
I think we might be talking of different things. Maybe if you could show a few examples or produce a PR with your idea we'd be able to progress faster.

I think this should be in each function we patch, wither forward or backward.
Is not about deprecating functionalities (that's why I was suggesting of coming up with custom warning), but more about letting the user know, he's not using the original API , but a wrapped function, which we have added to leverage the differences.
I agree, from what I understand you are looking on providing something py2to3, which analise the code, and report how things should be changed.
What I'm thinking about is just a way to notify the users when they access a method which is really not part of the original implementation (think of the setResizeMode vs setSectionResizeMode in QHeaders).
So for example if someone is using pyside , but on a legacy code which still use pyside2 (eg in Maya), this should be notifying that the function he's using is a patched one.

he's not using the original API , but a wrapped function

Ahaaaa, ok, so this was what I didn't understand.
You want a warning when using any function that isn't in the original binding? Ok. I'm not sure I agree with this. In that case, I'd rather see a namespace for it.
import Qt
Qt.my_custom_functionality.load_ui()

At the moment, custom functionality is mixed with native so you don't know what you're using. Maybe that's the problem?
Personally, I'm not sure it matters. But I can see what you mean and it's worth having a conversation about.

At the moment, custom functionality is mixed with native so you don't know what you're using. Maybe that's the problem?

Yup, that's exactly the issue I'm trying to solve with this.
If not solving, at least, having the users aware of what they are actually using.
I would set the logging to warning to a lever which doesn't print anything by default.
In case , this can be set to print out all these info, which could help porting code, and understand differences.

Solved via documentation.

https://github.com/mottosso/Qt.py#documentation


New Button

Added new button
Closes #issue_number

Changes proposed
Neon effect button is added
Note to reviewers

Fix the Merge Conflicts

Mention which issue this closes and tag me again

Please check #1346


Commit 286d8d1 breaks http loading

1. What version of Caddy are you running (caddy -version)?
https://github.com/mholt/caddy/commit/286d8d1e898c19d0b678892e908156fb45d2f369 on OSX 10.11
2. What are you trying to do?
curl -i http://<IP_ADDRESS>:2017/
3.   What did you expect to see?
An HTML page and integration tests are passing
6. What did you see instead (give full error messages and/or log)?
~10-20s loading and then downloading nothing or some tiny weird bytes.
$ hexdump -C page_grpc.html
00000000  15 03 01 00 02 02 0a                              |.......|
00000007

Content of page_grpc.html located here: https://github.com/SchumacherFM/caddyesi/blob/master/www_root/page_grpc.html
Same results when compiling with master branch latest commit.
The MITM feature works perfect.

Will investigate :)

Can you check @SchumacherFM this fix: https://github.com/mholt/caddy/pull/1456 ?

Don't worry about build failing (forgot to run gofmt 😭 )

Works! Please merge


Updating the version to 1.3

minor version is bumped to 3 for the next upcoming release version 1.3

/azp run

/azp run


Patches to fix build under arm/powerpc

These were added by a fellow FreeBSD-er to resolve the build under arm/powerpc:
https://cgit.freebsd.org/ports/tree/www/varnish-libvmod-fileserver/files

Hi @zi0r, thanks for pointing me at those, I believe this is fixed in version 0.0.2, after @pkubaj pointed it out here: https://github.com/gquintard/varnish-rs/issues/14
Would you be able to confirm this?

Ah, this does indeed look like the same stuff.  Sorry for the noise!


Next.js build failing due to internal error

Describe the bug
Attempts to build a nextjs projects in netlify are failing due to the error bellow.
Plugin "@netlify/plugin-nextjs" internal error

Error: Source and destination must not be the same.

In "onBuild" event in "@netlify/plugin-nextjs" from Netlify app
at Object.checkPathsSync (/opt/build/repo/.netlify/plugins/node_modules/fs-extra/lib/util/stat.js:51:11)
at copySync (/opt/build/repo/.netlify/plugins/node_modules/fs-extra/lib/copy-sync/copy-sync.js:24:38)
at copyPublicFiles (/opt/build/repo/.netlify/plugins/node_modules/@netlify/plugin-nextjs/src/lib/steps/copyPublicFiles.js:14:5)
at build (/opt/build/repo/.netlify/plugins/node_modules/@netlify/plugin-nextjs/src/index.js:30:3)
at nextOnNetlify (/opt/build/repo/.netlify/plugins/node_modules/@netlify/plugin-nextjs/src/index.js:90:11)
at onBuild (/opt/build/repo/.netlify/plugins/node_modules/@netlify/plugin-nextjs/index.js:123:11)
at async Object.run (/opt/buildhome/.netlify-build-nvm/versions/node/v12.16.3/lib/node_modules/@netlify/build/src/plugins/child/run.js:20:3)
at async handleEvent (/opt/buildhome/.netlify-build-nvm/versions/node/v12.16.3/lib/node_modules/@netlify/build/src/plugins/child/main.js:36:38)
at async process. (/opt/buildhome/.netlify-build-nvm/versions/node/v12.16.3/lib/node_modules/@netlify/build/src/plugins/ipc.js:103:16)

To Reproduce
Steps to reproduce the behavior:

Go to netlify dashboard
Select site
Go to deploys tab
Click Trigger deploy
Build fails at the stage 3. onBuild command from @netlify/plugin-nextjs

Expected behavior
Build works without issues
Versions

Next.js: 11.1.2

Okay, Sorry. turns out my Publish directory got configured to a wrong destination by default. This issue is fixed


Issue with bidirectional bindings in NSTextField

I was trying to set a bidirectional binding on a NSTextField and I think I have spotted a bug (I am using Xcode 6.3. / Swift 1.2)
This is what I have:
@IBOutlet weak var textField: NSTextField!
let backedValue = Dynamic<String>("Moose")

func applicationDidFinishLaunching(aNotification: NSNotification) {
   backedValue <->> textField.dynText
}

When the textfield is changed, Bond attempts to trigger -[Bond.TextFieldDynamicHelper textChanged:] but it fails with "unrecognized selector sent to instance". After looking at Bond+NSTextField.swift I noticed that textChanged is declared as private:

Declarations marked private are not exposed to the Objective-C runtime if not otherwise annotated. IB outlets, IB actions, and Core Data managed properties remain exposed to Objective-C whatever their access level. If you need a private method or property to be callable from Objective-C (such as for an older API that uses a selector-based callback), add the @objc attribute to the declaration explicitly.

Perhaps adding @objc would be a good idea?

HI,
I reported this issue a while ago... I think adding @objc attribute makes the most sense since it allows us to keep it private
Regards,
Juan Dent

Ok guys, should be fixed in v3.7.3. AppKit support is kind of still unofficial. Feel free to contribute if you need additional extensions.

@srdanrasic Unfortunately the changes in v3.7.3 did not fix this issue.
I noticed you added the @objc to the class rather than the private function, hence the situation has not changed (selector is still not recognised.)
    @objc private func textChanged(sender: AnyObject?) {
        self.listener?(control?.stringValue ?? "")
    }

This, however works as intended :+1:

Oh. Well, v3.7.4 is out :)

@srdanrasic Great, thank you! :+1:


notify_html5 issue when re-registering a device

Home Assistant release with the issue:

0.91.3
Last working Home Assistant release (if known):
N/A
Operating environment (Hass.io/Docker/Windows/etc.):

Docker on Ubuntu system
Component/platform:

https://www.home-assistant.io/components/html5
Description of problem:
If you "reset your browser" and need to turn on push notifications in homeassistant again on the same device, another entry is created in the html5_push_registrations.conf
This new entry causes home assistant to throw an error each time notify.html5 service is called.
Manually deleting the old entry and restarting corrects the issue.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
notify:
  - name: html5
    platform: html5
    vapid_pub_key: XXXXXXXX
    vapid_prv_key: !secret vap_prv_key
    vapid_email<EMAIL_ADDRESS>
Traceback (if applicable):

Additional information:

Can you paste the error mentioned?

Sorry, it's a bit annoying to manually edit but here it is. Also, if you "turn off" push and turn back on it works fine (it deletes the entry) . This only happens if your browser dies or if you "clear site data" while registered for push and then re-enable again.
Push failed: <Response [404]>:

Error 404 (Not Found)!!1

404. That’s an error.
 That’s all we know.
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/websocket_api/commands.py", line 122, in handle_call_service
    connection.context(msg))
  File "/usr/local/lib/python3.7/site-packages/homeassistant/core.py", line 1138, in async_call
    self._execute_service(handler, service_call))
  File "/usr/local/lib/python3.7/site-packages/homeassistant/core.py", line 1160, in _execute_service
    await handler.func(service_call)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/notify/__init__.py", line 117, in async_notify_message
    await notify_service.async_send_message(**kwargs)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/html5/notify.py", line 467, in send_message
    self._push_message(payload, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/html5/notify.py", line 504, in _push_message
    vapid_claims=self._vapid_claims
  File "/usr/local/lib/python3.7/site-packages/pywebpush/__init__.py", line 384, in webpush
    result, result.text))
pywebpush.WebPushException: Push failed: :

Error 404 (Not Found)!!1

404. That’s an error.
 That’s all we know.

I have the same error
Push failed: <Response [404]>:
<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>

404. That’s an error.

  That’s all we know.
Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/websocket_api/commands.py", line 122, in handle_call_service
    connection.context(msg))
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1138, in async_call
    self._execute_service(handler, service_call))
  File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
    future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step
    result = coro.throw(exc)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1160, in _execute_service
    await handler.func(service_call)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/notify/__init__.py", line 117, in async_notify_message
    await notify_service.async_send_message(**kwargs)
  File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
    future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
    raise self._exception
  File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/html5/notify.py", line 467, in send_message
    self._push_message(payload, **kwargs)
  File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/html5/notify.py", line 504, in _push_message
    vapid_claims=self._vapid_claims
  File "/srv/homeassistant/lib/python3.5/site-packages/pywebpush/__init__.py", line 384, in webpush
    result, result.text))
pywebpush.WebPushException: Push failed: <Response [404]>:
<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>

404. That’s an error.

  That’s all we know.

I believe this is probably related to the vapid error issue #23613


Redundant steps are retrieved and processed for handleLoop

atmloopval.txt
for example "enableCardReader" label appears several times in attached log
Maybe it is just diamond flow shape? Investigate please

not an issue (diamond)


Add denom metadata

This is fine for testing but how will we guard this in production? Let's hold on merging until we have a production story ironed out. I think the alternative of depending on this registry is fine: https://github.com/cosmos/chain-registry

Closing bc we're favoring the github token registry approach


Space beneath the form attachment list

There seems to be some blank space beneath the form attachment list where the background of the page is visible:

The space disappears when the viewport is narrow enough:

I know that the modal classes used for the popup have different effects based on the viewport width, which makes me think that the additional space could be related to those classes.
@clint-tseng, what are your thoughts about this space? Do you think it's fine to remain, or should we try to remove it?

Kasia and Marzena note that this space is pretty large, so I think we should try to remove it.

oh it’s on this page. huh yeah i dunno then. we can fix it.
On Tue, Nov 13, 2018 at 14:28 Matthew White<EMAIL_ADDRESS>wrote:

Interestingly, I see this space in Chrome, but I don't see it in Firefox.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/central-frontend/issues/144#issuecomment-438462649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHMArP2DLIcoNHVZgybctD0Ra19rIDmks5uu0d8gaJpZM4Wd4K0
.

@kkrawczyk123 notes:

Confirmed that it is not visible on Firefox and Safari. It is visible on Chrome and Egde.


[K8s] Resource Server Helm chart rework to use single deployment for all verticles

Modified values.yaml to remove all the verticles except apiServer
Modified aws and azure resource-values files to have only resources and limits of single verticle
updated the helm chart

Can one of the admins verify this patch?

As per the suggestion I have updated the resources in the resource values yaml file
added the "rs-s3-env" in the values.yaml
updated metadata name and label to resource-server


Receiving different sets of advertisement data on iOS and Android

To help us fix your issue, please provide the information in the below template. If something causes a crash, provide as much information as you can gather.
Just imagine: we do not know what you are doing!

Note: There is often little we can do without a minimal reproducible sample of the issue, so please provide that in a standalone git repository and link it here.

The Bluetooth device we are using is proprietary so it may not be easy to reproduce this issue
The Bluetooth module has 2 sets of advertisement data by default which is a battery level and a "Device name", the 3rd one was added manually in the firmware. We are attempting to identify the devices by MAC address, but we cannot access the MAC of the remote device with CrossBluetoothLE.Current.Adapter, so the MAC address was added in the advertisement data, but does not appear on iOS.
Steps to reproduce

On an Android device and iOS device, search nearby devices

When a device is found, check the AdvertisementRecords, for this particular device, on Android we are receiving 3 advertisement records (this is correct) on iOS we only receive 2

Expected behavior
I expect to see the same advertisement data on iOS and Android
Actual behavior
1 of our advertisement data sets is missing on iOS (MAC address)
Crashlog
If something causes an exception paste full stack trace + Exception here
Configuration
Version of the Plugin: e.g. 1.0.0 / 1.0.1-alpha3
1.3.0-alpha1
Platform: e.g. iOS 10.1 / Android 4.4 / ... (including version!!! e.g. Android 5.1 / i0S 10)
iOS: 10.3.1
Android: 7.0
Device: e.g. HTC Sensation /i Phone 7 ...
Samsung Galaxy S7 Edge
iPhone 5C

Hi @Yelnik,
I'm the friendly issue checker.
Thanks for using the issue template :star2:
I appreciate it very much. I'm sure, the maintainers of this repository will answer, soon.

What type of AdvertisementRecordType does Android use for the MAC?
(see AdvertisementRecordType.cs). I suspect it's not implemented on the iOS side

On Android the type for the MAC address is showing as Plugin.BLE.Abstractions.AdvertisementRecordType.DeviceAddress

Based on my knowledge, iOS supports only the following keys for advertisement data:
advertisement_data_retrieval_keys
Maybe you can check your application output for the following message:
https://github.com/xabre/xamarin-bluetooth-le/blob/master/Source/Plugin.BLE.iOS/Adapter.cs#L348
Maybe we are lucky and can see which key iOS is using if at all one.
Maybe this post can also help:
https://forums.developer.apple.com/thread/8442
Let me know what you find.

@Yelnik any news on this one?

Not yet no, we'll be looking into this in a few weeks maybe. Some other stuff came up and we're fine testing with the Android version for now. I'll post our solution/what happens here when we make the changes.


Plans for ES2.0?

Are you planning support for ES2.0? I've tried updating myself but it is to complicated for me, because there are many changes ...

I have bundled my plugins into one zip, and updated to 2.0.0-Beta1
Can you try https://github.com/jprante/elasticsearch-plugin-bundle ?

Thanks! I'll try this out.

Version <IP_ADDRESS> is released for ES 2.0.0


(maint) Bump Chocolatey Version

Description
This updates the Chocolatey version used when building pull requests,
when pushing and running normal updates and removes an unsupported
version of Chocolatey CLI.
Motivation and Context
We always want to use the latest stable version of Chocolatey CLI when updating and pushing packages, the latest supported version when building pull request and to not list any versions of Chocolatey CLI that is too old for us to support.
How Has this Been Tested?
N/A
Screenshot (if appropriate, usually isn't needed):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the chocolatey test environment.
[ ] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review

Thanks for updating this @AdmiringWorm


Create new LIS-metforcing reader for GDAS netcdf files

A new met forcing reader in LIS is required for new netcdf-formatted GDAS files being generated.
@karsenau is working on first draft of the reader in LIS.

New GDAS-NetCDF reader is generating identical results, when accounting for the entire GDAS domain read in and interpolated in LIS.  This new reader is running somewhat faster than the Grib-1 format reader (without reading subsetted GDAS netcdf fields relative to the local parallel subdomains).
Next phase to the new GDAS-NetCDF reader will include updates to the reading and subsetting of the actual GDAS Gaussian grid, so the reader will be able to read the fields in parallel and achieve significant increases in runtime over the current Grib-1 reader. The Gaussian code within LIS' map_utils.F90 appears to be outdated and may require updates to support this feature.

New GDAS-NetCDF reader is generating identical results, when accounting for the entire GDAS domain read in and interpolated in LIS.  This new reader is running somewhat faster than the Grib-1 format reader (without reading subsetted GDAS netcdf fields relative to the local parallel subdomains).
Next phase to the new GDAS-NetCDF reader will include updates to the reading and subsetting of the actual GDAS Gaussian grid, so the reader will be able to read the fields in parallel and achieve significant increases in runtime over the current Grib-1 reader. The Gaussian code within LIS' map_utils.F90 appears to be outdated and may require updates to support this feature.

First version of the new GDAS-NetCDF4 reader can be found here:
https://github.com/NASA-LIS/LISF/commit/9c0c5e9002b347e87e31dd24cd40df106f668ffe

First version of the new GDAS-NetCDF4 reader can be found here:
https://github.com/NASA-LIS/LISF/commit/9c0c5e9002b347e87e31dd24cd40df106f668ffe

Would like to return to this work to finalize this GDAS netcdf4 reader in LIS


[RFC] New parallel compilation infrastructure

TL;DR This is why you want it:

I have been using this branch almost exclusively for the last few weeks, and it
should be pretty stable now.
There is one nasty memory leak though (that is also in master): open
init/core.lean and standard.lean. Then change something in init/core.lean.
Every change uses an additional few hundred megabytes for me. I would really
appreciate any ideas on how to debug this. So far I've tried valgrind (too slow
on the whole library, small examples don't show any leaks) and heaptrack
(doesn't give any clues either), without success.
New parallel compilation infrastructure
While the current parallel compilation and server mode works pretty well, there
a few issues:

Defining tasks in C++ is cumbersome.
Message reporting, cancellation, task queues are terribly tightly coupled.
The code for mt_task_queue is horribly complex at the moment because it has
lots of responsibilities, and there are probably lots of bugs.
The approach requires a hand-rolled task queue, and does not easily transfer
to other programming languages, or even just multiple Lean instances inside
the same process (which might reasonably happen when Lean is used as a
library).
We cannot work on a file without compiling its dependencies.  The
dependencies (in particular proof elaborations) are always executed.
Similarly, we eagerly compile all reverse dependencies.  This is a huge
problem if you edit init/core.lean and have data/list/comb.lean open at
the same time.
When handling info command we indicate that the server is busy (with the
"hourglass" icon in Emacs), just because the command spawns a task.

This PR solves all of these issues.  I think a good way to view the problem is
to consider 4 very similar, but subtly different graphs:

Task dependency graph.  (Contains an edge if a task needs to be run after
another one.  For example, type-checking must run after elaboration.)
Module dependency graph.  (Reflects the import statements.)
Message tree.  (How messages can be reused.  When reparsing a file, we
keep the messages form the old proof elaborations around, and only replace
them once they are re-elaborated as well.)
Cancellation graph.  (Which tasks need to be cancelled when we reload a
file?)

These are now separate and mostly explicitly represented.  Currently tasks have
metadata which we use for 3. and 4., this metadata is replaced by explicit data
structures.
Additionally, this PR adds the following new features:

By default, we only check the visible lines.  You can also choose to check
nothing, or the complete visible files.
Greatly reduced number of sorry warnings.
The command-line exit status is 1 if and only if an error was reported.  This
matches the error reporting in Emacs. Concretely, we missed two error in the
run tests due to the current mismatch: quote1.lean and exact_perf.lean.
@leodemoura quote1 was an easy fix, but exact_perf.lean reports an error
because try { exact h2 } fails, and h2 has an elaboration error. You
added this error message at
https://github.com/leanprover/lean/commit/add5266df75bf04c721670ea5ac0e3c59209c15b
Any ideas?

I have removed all incremental message/tasks updates from the server.  The
server resends all running tasks / all messages every time (about every 100ms).
(See #1364 for how we arrived at this approach.)
However these are only sent for the region that is checked: for example if
you choose "check visible lines", then you only see errors for the visible lines.
There are two backwards-compatible changes in the server protocol:

The additional_message command got removed.
There is now a roi (region of interest) command:

{
  "seq_num": 45,
  "command": "roi",
  "files": [
    {
      "file_name": "/home/gebner/lean/library/init/core.lean",
      "begin_line": 1,
      "end_line": 69
    }
  ]
}

Task dependency graph (and tasks in general)
As before, the task dependency graph is specified by the dependencies of each
task.  Every task has a method that computes a list of its dependencies:
virtual void get_dependencies(buffer<gtask> &) {}

The reason this is a method is because the dependencies can change dynamically.
Consider for example a dependency on task<task<expr>>, here the
get_dependencies method would first return the outer task, and then both the
outer and inner task once the outer one is finished.
Since tasks no longer require so much metadata, it is feasible to construct
them with lambdas, including nice combinators for mapping, etc.:
add_library_task(map<unit>(error_already_reported(), [_d] (bool already_reported) {
    if (!already_reported && has_sorry(_d)) {
        report_message(...);
    }
    return unit();
}).depends_on(_d.is_theorem() ? _d.get_value_task() : nullptr));

(The snippet above causes sorry to be only reported at most once per
declaration, and only if no other error was reported.  It is also completely
deterministic.)
Tasks now have the the type task<T> (much easier to type).  Tasks are
typically constructed using the task_builder<T> helper.  A common operation is to
wrap the execution function, e.g. to set thread-local variables.  This is
accomplished using the .wrap() function; implementation-wise, each wrapper
adds a new heap-allocated gtask_imp object that delegates the execution and
dependency methods to the previous gtask_imp.  (We could avoid the
heap-allocation with some template trickery, but I'd rather wait for C++14 for
that--it has the equivalent of Rust's impl Trait feature.)
Dependencies are usually constructed with combinators as well, and are tasks as
well (with the generic gtask type).
In general, tasks are now no longer submitted immediately.  They are stored in
the log_tree for lazy evaluation--see the corresponding section for details.
Module dependency graph
This part remains essentially unchanged.  In the module_mgr every module has
a list of dependencies.  We might want to use the cancellation graph to
invalidate modules as well, but this has the (positive?) side-effect that
invalidated modules are immediately cancelled.
I'm waiting with this refactoring until we have the parser monad.
Message tree (log_tree)
The log_tree is a mutable, concurrent data structure.  It stores produced
messages, the info managers, as well as the tasks that need to be executed to
produce these messages.  More concretely, a node of the log_tree has the
following fields:
name_map<node> m_children;

std::vector<log_entry> m_entries;  // e.g. messages

location m_location;
std::string m_description;

gtask m_producer;

Every node has an associated location (file name + position range). The tree is
structured in a way such that the children's location is always a subset of the
parent's location.  We could enforce this invariant, as well as that messages
need to be contained in the node's location.  This would solve the problem where
we run a command, and report error messages in a different part of the file.
The tree is designed for lazy evaluation: we first insert nodes that contain
unsubmitted tasks. The tasks are then submitted by a separate listener, and only
when the editor/command-line requests the error messages for that location. When
a task is finished, it resets the producer field in its node to null. We only
modify nodes where an ancester has a non-null producer. Nodes that have a
non-null producer are shown as in-progress in the editor.
When sending information to the editor, we simply traverse this tree.  (Recall
that we only send messages for the currently visible region, so this is pretty
efficient. We don't even look at subtrees whose location is disjoint.)
std::vector<message> msgs;
m_lt->for_each([&] (log_tree::node const & n) {
    if (roi.intersects(n)) {
        for (auto & e : n.get_entries()) {
            if (auto msg = dynamic_cast<message const *>(e.get())) {
                if (roi.intersects(*msg))
                    msgs.push_back(*msg);
            }
        }
        return true;
    } else {
        return false;
    }
});

The progress messages at the command line and in the server mode are obtained by
traversing the log_tree as well, instead of looking at the state of the task
queue.
Tasks are typically inserted by using the add_library_task<T> function.
Cancellation graph
At the moment, we cancel tasks based on their position in the file, by storing
the file name and position in every task, and sending a predicate to the task
queue when we want to cancel something.  This PR takes an approach inspired by
vscode, where every command gets an explicit CancellationToken object, where
you can attach listeners. We have a thread-local variable for a
cancellation_token, which can be cancelled and where we can add children.
It is notable to describe the ownership convention: parents hold weak references to
the children, children hold (strong) references to the parents. This ensures,
that as long as you have a cancellation_token, you will receive cancellation
events from every parent, without creating memory leaks (by never freeing
children).
To do

Different priorities for the tasks. Currently we prioritize parsing over
elaboration. This has been lost in the refactoring. It does not seem to be a
major issue for now.

Do not elaborate proofs in dependent modules. With this PR, this would happen
for a "stupid" reason: we check for every import whether it contains sorry.
This causes the proofs to be elaborated. We just need to find a clean way to
skip this sorry check, probably only when "checking visible lines".

Once we refactor the parser to process one command at a time, I'd like to
schedule one parsing task per command. This brings a few immediate advantages:

Better visual feedback about the parsing status.
We can stop parsing right below the edge of the screen. Parsing is
automatically resumed when scrolling down.
We can reuse snapshots even when we did not finish parsing the file. Right
now we only get the snapshots after we finish parsing the whole file.

Performance
There is no (significant) performance change in either direction when compiling
the standard library. The editor interface seems to be more responsive now.

Every change uses an additional few hundred megabytes for me. I would really
appreciate any ideas on how to debug this.

Still reading through the RFC, but https://clang.llvm.org/docs/LeakSanitizer.html might be worth a try.

There is one nasty memory leak though (that is also in master): open
init/core.lean and standard.lean. Then change something in init/core.lean.
Every change uses an additional few hundred megabytes for me.

I tried a few experiments.

Disabled memory pools and the small object allocators (they could be fragmenting memory, and/or preventing memory from being reclaimed). No change: memory consumption keeps increasing.

Printed amount of memory released by memory pools and small object allocators (in the end of execution). The amount of reclaimed memory increases as memory consumption increases. My point here is that I don't think the issue is due to a memory leak. I think a module may be preventing memory from being reclaimed because it contains references to many live objects. Today, I will add a compilation flag that when enabled will display the total amount of memory reclaimed by all these subsystems.

I disabled g_expr_cache_enabled, and other caches. No change: memory consumption keeps increasing.

The memory keeps increasing even if I instruct emacs to use -j0 -T0 -M0.

I tried valgrind, but it detected only minor leaks (the ones I posted before).

@leodemoura quote1 was an easy fix, but exact_perf.lean reports an error
because try { exact h2 } fails, and h2 has an elaboration error. You
added this error message at
add5266
Any ideas?

I will take a look.

I tried a few experiments.

I tried adding this in module_mgr on file invalidation:
m_modules.clear();

When I check in the debugger, the task queue is empty, there is just a single loaded module (init.core), log_tree is also cleared, yet we're using a gigabyte of memory.  I really can't see where we still keep references to all that memory.

I have added the following compilation flags
1)
-D TRACK_CUSTOM_ALLOCATORS=ON

Tracks the amount of memory deallocated by memory_pool and small_object_allocator.

-D TRACK_LIVE_EXPRS=ON

Enable counter for the number of live expr
BTW, Lean displays the amount of deallocated memory and live expressions before/after finalization.

-D CUSTOM_ALLOCATORS=OFF

Disable memory_pool and small_object_allocator.
Here is some data for an example that consumes 1Gb by making simple modifications to tactic.lean while vector.lean is open:
a) with -D TRACK_CUSTOM_ALLOCATORS=ON and -D TRACK_LIVE_EXPRS=ON
memory deallocated by memory_pool and small_object_allocator (before finalization): 117205272
number of live expressions (before finalization): 105
memory deallocated by memory_pool and small_object_allocator (after finalization): 608798768
number of live expressions (after finalization): 0

So, the custom allocators have released 608Mb in the end of the execution. Note that this amount is not including the overhead introduced by malloc. I believe this is evidence that the high memory consumption is not due to a memory leak. 608Mb is a lot of memory. Moreover, when I edited the file manually, the memory consumption was around 250Mb after the first modification.
b) With -D CUSTOM_ALLOCATORS=OFF (memory consumption goes down to 828Mb). However this is expected since we may have unused space in pools for different threads. 828Mb is still a lot of memory.

The compilation flags are nice.  I just had to move them around and make them write to stderr, so that I can see them from emacs.  I also added an extra output right before thread finalization:
memory deallocated by memory_pool and small_object_allocator (before finalization): 96532824
number of live expressions (before finalization): 4309228
memory deallocated by memory_pool and small_object_allocator (after finalization): 96532824
number of live expressions (after finalization): 4309140
memory deallocated by memory_pool and small_object_allocator (after thread finalization): 173477928
number of live expressions (after thread finalization): 4309140

(This is from while the server is running.)  So it is really the thread local data that uses up memory.  However all worker threads are stopped as soon as they are idle.  The lthread objects are destroyed as well (there was a reference cycle there), but that doesn't help either.

I have just added -D SAVE_INFO=OFF and -D SAVE_SNAPSHOT=OFF.
Then, I tried the following experiment with the setting
-D SAVE_INFO=OFF -D SAVE_SNAPSHOT=OFF -D CUSTOM_ALLOCATORS=OFF

and lean server running with -j2.
Then, I tried the usual example two files (tactic.lean and bitvec.lean), and kept adding/fixing an error in tactic.lean.
Initially memory consumption stabilized at 1.05Gb. Then, I started adding different kinds of errors, and it started to increase again. However, it stabilized many times. I managed to get it to 1.8Gb but it took hundreds of modifications. With the info_manager and snapshots enabled, I get to 2Gb very quickly.

Hmm, apparently all the thread-local data is on the main thread: if I comment out the following line, then delete_thread_finalizer_manager does not change the value of get_memory_deallocated:
    ~thread_finalizers_manager() {
//        finalize_thread(get_pair()); // finalize main thread
        pthread_key_delete(g_key);
    }

That is, I get:
memory deallocated by memory_pool and small_object_allocator (before finalization): 104291536
number of live expressions (before finalization): 125
memory deallocated by memory_pool and small_object_allocator (after finalization): 104291536
number of live expressions (after finalization): 0
memory deallocated by memory_pool and small_object_allocator (after thread finalization): 104291536
number of live expressions (after thread finalization): 0

@Kha LeakSan is awesomely fast, thanks for pointing me to it.  However it doesn't detect the leak above.

@gebner I tried to reproduce your last experiment. Here is the data I get (I'm using the master branch)
Before:
% memusg ../../bin/lean -j 2 --server=../../tmp/trace2.txt > /dev/null
memory deallocated by memory_pool and small_object_allocator (before finalization): 375631624
number of live expressions (before finalization): 105
memory deallocated by memory_pool and small_object_allocator (after finalization): 375631624
number of live expressions (after finalization): 105
memory deallocated by memory_pool and small_object_allocator (after thread finalization): 636353912
number of live expressions (after thread finalization): 0
memusg: peak=974244

After I commented the line you have referenced in your message
memusg ../../bin/lean -j 2 --server=../../tmp/trace2.txt > /dev/null
memory deallocated by memory_pool and small_object_allocator (before finalization): 325759920
number of live expressions (before finalization): 105
memory deallocated by memory_pool and small_object_allocator (after finalization): 325759920
number of live expressions (after finalization): 105
memory deallocated by memory_pool and small_object_allocator (after thread finalization): 325759920
number of live expressions (after thread finalization): 105
~/projects/lean/build/track$ memusg: peak=889312

@gebner Here is a conjecture:
1- worker threads allocate many exprs and other kinds of object using the memory_pool.
2- the memory pool for the worker thread is often empty, and it requests more memory using malloc
3- some/most of these object are deallocated by the main thread. These objects are stored in the main thread memory_pool.
4- The main thread memory_pool keeps growing since the main thread doesn't do much. This is why we have a 300Mb in the memory_pool of the main thread in the last experiment.
What do you think?
I will test this conjecture by putting a limit on the memory_pool size.

@gebner Here is the same experiment, but memory_pools can have at most 1024 objects.
memusg ../../bin/lean -j 2 --server=../../tmp/trace2.txt > /dev/null
memory deallocated by memory_pool and small_object_allocator (before finalization): 10004080
number of live expressions (before finalization): 105
memory deallocated by memory_pool and small_object_allocator (after finalization): 10004080
number of live expressions (after finalization): 105
memory deallocated by memory_pool and small_object_allocator (after thread finalization): 13335936
number of live expressions (after thread finalization): 0
memusg: peak=1048732

We are still consuming a lot of memory 1Gb, but the main thread is holding only 3Mb instead of 300Mb during finalization.
When using the editor, the memory seems to stabilize around 1.5Gb. It keeps growing but in a much slower pace, and I hit several plateaus where the memory doesn't increase.
Another thing to keep in mind that there is overhead and fragmentation going on in the malloc provided by the runtime. I will keep running more experiments.

3- some/most of these object are deallocated by the main thread. These objects are stored in the main thread memory_pool.

This is very true.  We deallocate all the environments on the main thread, as well as the info managers, etc.
I tried the memory_pool change, but it doesn't change the memory consumption for me.  I found a different memory leak though that sometimes happens at the end of a server process, I'm looking into it right now.

Does it still keep growing for you? For me, it stops around 2Gb.

It still keeps growing for me.  I need to test master again to see the difference.

Do you still observe this behavior after the memory_pool commit?

No, the main thread finalizer does not change the deallocation number anymore, so that seems to be fixed.

Does it still keep growing for you? For me, it stops around 2Gb.

Okay, there were quite a few leaks all over the place.  Now it stops at 1.5G for me as well.

I've added the region-of-interest support to the vscode extension as well: https://github.com/leanprover/vscode-lean/compare/master...gebner:parallel2
Unfortunately, it's not possible to determine which lines are visible with the current vscode API: https://github.com/Microsoft/vscode/issues/14756

@leodemoura quote1 was an easy fix, but exact_perf.lean reports an error
because try { exact h2 } fails, and h2 has an elaboration error. You
added this error message at
add5266
Any ideas?
I will take a look.

I investigated this one. However, I didn't find a good solution yet (only hacks).
Here is the problem:
When we parse tactic notation, we statically know whether we should report errors or not.
Example:
begin
     tac_1, tac_2
           --^ if tac_2 fails, we want the red squiggly line here
end

On the other hand,
begin
     tac_1, try {tac_2}
                --^ we don't want a red squiggly line here if tac_2 fails
end

So, we use the tactic.rstep and tactic.istep combinators for controlling this.
The tactic.rstep line col tac will report the error at the given line and column if tac fails.
The tactic notation module decides which one should be used.
This works for everything, but to_expr.
The elaboration errors are reported by the elaborator depending on the flag report_errors.
Right now, tactic.interactive.exact is defined as
/- doesn't allows metavars and report errors -/
meta def i_to_expr_strict (q : pexpr) : tactic expr :=
to_expr q ff tt -- << the `tt` means report errors

meta def exact (q : parse texpr) : tactic unit :=
do tgt : expr ← target,
   i_to_expr_strict ``(%%q : %%tgt) >>= tactic.exact

Here is one ugly hack to fix the problem above.
We add a combinator tactic.ignore_elab_errors tac which will execute tac without reporting elaboration errors even if tac uses to_expr e ff tt -- << tt here means "report_errors".

I think that in the long run all error messages during tactic execution should be kept in the tactic_state.  Then <|> behaves as expected and suppresses error messages when backtracking.  Even if we add ignore_elab_errors for try, we'd still have the problem with <|>.
If I recall correctly, the main motivation for rstep to ignore the exception position, and then for to_expr to directly report an error is because of the issue in quote_error_pos.lean: if we call to_expr on a pre-expression from another definition, the we might get elaboration errors at that definition, and not at the tactic use site.
This issue was the reason we now keep track of position ranges (begin and end of the current command) in the log_tree data structure; we could take the position if it lies inside the range (when the pre-expression comes from the current tactic block), or assign it another useful position if it lies outside (when it comes from another definition).
For now, the ignore_elab_erors hack is probably the easiest and would fix the test and the try problem.  I'm on vacation for a week, I can solve this afterwards in a nicer way.

I think that in the long run all error messages during tactic execution should be kept in the tactic_state.

This would be bad. The error messages are thunks, because we want to discard them at <|>. This is important for performance. We originally did not use thunks and it was a performance bottleneck.
It is also problematic to store the thunk since we would have to use the thread safe vm_obj.

Then <|> behaves as expected and suppresses error messages when backtracking. Even if we add ignore_elab_errors for try, we'd still have the problem with <|>.

This is a bug in the current support for <|> in interactive mode. I can fix this, and it will work with ignore_elab_errors.

This would be bad. The error messages are thunks, [...]

I did not suggest to switch from thunks to error messages.  I was referring to the fact that some operations like add_declaration and to_expr directly report errors that remain after backtracking.  And that those error messages should go into the tactic state instead (as thunks).

And that those error messages should go into the tactic state instead (as thunks).

This problematic since to put them into the tactic_state we need to convert the thunks into thread safe vm_objs (which deep copy vm_objs closures and constructors).

I'm not sure I'm following yet - why would we ever need to report errors immediately or store them in the tactic state, instead of returning them in result.exception?

I'm not sure I'm following yet - why would we ever need to report errors immediately or store them in the tactic state, instead of returning them in result.exception?

In very rare cases we produce warnings instead of errors, for example when adding declarations with the wrong noncomputability annotation.  The elaborator can also produce more than one error (when error recovery is enabled).  Maybe we want to produce more warnings in the future.

@leodemoura Did you already start with ignore_elab_errors?
I think there are two options here:

Modify to_expr so that it doesn't report errors directly, but makes sure that they are inside the current declaration.  Then we can remove rstep.
Add an ignore_elab_errors combinator that sets a thread-local flag that causes to_expr to not report errors directly.  (Or a flag in the tactic state instead?)  This flag is always set on the left branch of <|> (also in the non-interactive version).  Maybe rename ignore_elab_errors to possible_backtracking; we could enable error recovery if we're not backtracking.

Any opinions?  Should we do 1, 2, or 1+2?

So, I found another possible explanation for the high memory usage, this is the output of malloc_stats:
Total (incl. mmap):
system bytes     =<PHONE_NUMBER>
in use bytes     =  533526976
max mmap regions =          2
max mmap bytes   =    8396800

That is, the Lean process uses 1095M of memory but we have only malloc'd 533M.  The rest seems to be due to fragmentation and/or glibc's reluctancy to free memory.  No idea yet on how to improve that.

One possibility: we switch to jemalloc.  It has a nice API to query how much memory we use, and it also doesn't seem to fragment that much.
With jemalloc, when switching between init/core.lean and standard.lean, we allocate 700M, and use 1200M (after a few iterations).

In very rare cases we produce warnings instead of errors, for example when adding declarations with the wrong noncomputability annotation. The elaborator can also produce more than one error (when error recovery is enabled). Maybe we want to produce more warnings in the future.

I see, thanks. I do wonder if we can't come up with simpler implementations, however. For example, for warnings we could traverse and check all new declarations only after the top-level command (eg run_cmd) has finished.

Modify to_expr so that it doesn't report errors directly, but makes sure that they are inside the current declaration. Then we can remove rstep.

Sounds perfect. Are there any downsides?

Btw, gperf (and jemalloc in particular) seem to have some nice heap profilers: https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Leak-Checking

I see, thanks. I do wonder if we can't come up with simpler implementations, however. For example, for warnings we could traverse and check all new declarations only after the top-level command (eg run_cmd) has finished.

The noncomputability/sorry/type-checking errors are a bit of a hack at the moment, the otherwise pure module::add functions directly reports them--even if we never use the resulting environment.  I'm open for better suggestions.  The problem with checking the new declarations after the top-level command is mainly that we don't really know which declarations are new.  But looking at the code, these checks seem to be better at home in the definition command, then you couldn't circumvent them using environment::add either.

Modify to_expr so that it doesn't report errors directly, but makes sure that they are inside the current declaration. Then we can remove rstep.
Sounds perfect. Are there any downsides?

The issue with the easy one-line implementation is that the error would appear at the begin of the declaration, not at the tactic.

Ok, I just looked a bit through the tactic notation code.  I'm surprised to see that we apparently directly report errors in rstep, completely bypassing the built-in exception handling of the tactic monad.
I don't really remember the rationale for this behavior.  Why can't we just replace rstep with istep?  Concretely, my proposal would be the following:

Change istep to have begin_line begin_col end_line end_col : nat arguments, with the intention that error positions in the exception case should be adjusted to lie in the given range.
Remove rstep, report_error, as well as silent_fail.
Use step instead of istep in auto-quote blocks.

Still sounds good to me - do we actually need to clamp downwards (end_*)
too though?
On Wed, Mar 15, 2017 at 3:58 PM Gabriel Ebner<EMAIL_ADDRESS>wrote:

Ok, I just looked a bit through the tactic notation code. I'm surprised to
see that we apparently directly report errors in rstep, completely
bypassing the built-in exception handling of the tactic monad.
I don't really remember the rationale for this behavior. Why can't we just
replace rstep with istep? Concretely, my proposal would be the following:

Change istep to have begin_line begin_col end_line end_col : nat
arguments, with the intention that error positions in the exception case
should be adjusted to lie in the given range.
Remove rstep, report_error, as well as silent_fail.
Use step instead of istep in auto-quote blocks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/leanprover/lean/pull/1405#issuecomment-286768191, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGqRlY6rjIYLbfanBX7DwhMVr7Cqk1Wks5rl_yMgaJpZM4MOdka
.

Still sounds good to me - do we actually need to clamp downwards (end_*)

I have now implemented this approach.  I left out the downward clamping for simplicity: in the worst case, report_message will do some clamping anyhow (to the current declaration, basically).  The code is quite a bit simpler now.

(edit: we do in recursive tactics I guess ￼ )

I'm not sure I follow.  We don't use istep in auto-quote blocks (`[begin ... end]), so this shouldn't happen.

I will play with this branch soon.
In the meantime, I will just write a few use cases and mark them as OK or BUG based on the master branch. Some of the them used to work in the master branch, but don't work anymore (e.g., repeat).
example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  exact (or.inl _)
       --^ type mismatch here (OK)
end

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  exact (and.intro _ h2)
                 --^ don't know how to synthesize placeholder here (OK)
end

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  abstract {exact (and.intro _ h2)}
                           --^ don't know how to synthesize placeholder here (OK)
end

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  {exact (and.intro _ h2) } <|> apply and.intro
                  --^ should not show error here (BUG)
end

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  try {exact (and.intro _ h2) }
                      --^ should not show error here (BUG)
end

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  repeat {exact (and.intro _ h2) }
                         --^ should not show error here (BUG)
end

open tactic
meta def mytac : tactic unit :=
`[apply (or.inl _)]

example (p q : Prop) (h1 : p) (h2 : q) : p ∧ q :=
begin
  mytac
--^ failed to unify error here, it shoult *not* be at mytac or.inl (OK)
end

The import foo uses sorry warnings are now disabled in the editor by default, since they would require elaboration of all proofs in the dependent modules.  Nothing has changed with lean --make, they are still there.  It is easy enough to re-enable it in some cases (for example if "check all files" is selected), but I'd like to hear how people use them first.

I just found another problem with show-goal: apparently the goal is rendered in the empty environment (or maybe with pp.all set, but I don't know where that would come from).

I just found another problem with show-goal: apparently the goal is rendered in the empty environment (or maybe with pp.all set, but I don't know where that would come from).

It's using get_closest_snapshot. Should we fall back to m_loaded_module (when available) when there are no snapshots?

It's using get_closest_snapshot. Should we fall back to m_loaded_module (when available) when there are no snapshots?

The environment and/or snapshots should not make a difference, since the environment at the time of the goal is stored in vm_obj_format_info.

I just found another problem with show-goal: apparently the goal is rendered in the empty environment (or maybe with pp.all set, but I don't know where that would come from).

The environment and/or snapshots should not make a difference, since the environment at the time of the goal is stored in vm_obj_format_info.

@gebner It is not clear to me what the problem is. The environment is stored in the goal, and your second comment makes it clear you are aware of this fact.

The import foo uses sorry warnings are now disabled in the editor by default, since they would require elaboration of all proofs in the dependent modules.

Good for me.

@leodemoura This is the problem (as seen from emacs), I'm still trying to figure out what's going on:
α : Type.{u},
_inst_1 : discrete_linear_ordered_field.{u} α,
a b : α,
ha :
  gt.{u} α (strong_order_pair.to_has_lt.{u} α (linear_strong_order_pair.to_strong_order_pair.{u} α (linear_ordered_ring.to_linear_strong_order_pair.{u} α (linear_ordered_field.to_linear_ordered_ring.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1))))) a (zero.{u} α (no_zero_divisors.to_has_zero.{u} α (integral_domain.to_no_zero_divisors.{u} α (discrete_field.to_integral_domain.{u} α (discrete_linear_ordered_field.to_discrete_field.{u} α _inst_1) (discrete_linear_ordered_field.to_discrete_field.{u} α _inst_1))))),
h :
  le.{u} α (weak_order.to_has_le.{u} α (strong_order_pair.to_weak_order.{u} α (linear_strong_order_pair.to_strong_order_pair.{u} α (linear_ordered_ring.to_linear_strong_order_pair.{u} α (linear_ordered_field.to_linear_ordered_ring.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))))) (div.{u} α (division_ring_has_div.{u} α (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1))) (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))) (one.{u} α (zero_ne_one_class.to_has_one.{u} α (division_ring.to_zero_ne_one_class.{u} α (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))))) a) b
⊢ le.{u} α (weak_order.to_has_le.{u} α (strong_order_pair.to_weak_order.{u} α (linear_strong_order_pair.to_strong_order_pair.{u} α (linear_ordered_ring.to_linear_strong_order_pair.{u} α (linear_ordered_field.to_linear_ordered_ring.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))))) (div.{u} α (division_ring_has_div.{u} α (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1))) (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))) (one.{u} α (zero_ne_one_class.to_has_one.{u} α (division_ring.to_zero_ne_one_class.{u} α (field.to_division_ring.{u} α (linear_ordered_field.to_field.{u} α (discrete_linear_ordered_field.to_linear_ordered_field.{u} α _inst_1)))))) b) a

@gebner Can you reproduce the problem in batch mode? If you can, one option is to put a breakpoint at format tactic_state:pp() const at tactic_state.cpp. Then, we can see whether the options are correct there or not. We can also put a breakpoint at
vm_obj tactic_save_info_thunk(vm_obj const & pos, vm_obj const & thunk, vm_obj const & s) {

at info_manater.cpp. This is invoked when we save the goal information. We can compare the options object at saving and pp times.

@gebner Can you reproduce the problem in batch mode?

It does not happen with -j0.  I'll debug further when I get home.

The issue was that the global ios was not set, and we would hence fall back to the dummy ios without the fancy formatter.  It's fixed now.

@gebner I just pushed a small Emacs 24 fix (always wanted to try out this Github feature :) )

@kha Thanks!  I didn't realize you could push to other people's repositories.  This only works for PRs, right?

This only works for PRs, right?

Yes, I would hope so :)

The import foo uses sorry warnings are now disabled in the editor by default, since they would require elaboration of all proofs in the dependent modules.

I'm a bit anxious about this change. A colleague just asked me whether Lean has a sorry command just like Isabelle - he had proved something in Isabelle, which turned out to still depend on a sorry, but he didn't notice because there is no warning at all in Isabelle (compiling on the command line, however, would give an error by default). How about an opt-out setting that elaborates such proofs at lowest priority?
If we have fully checked a dependent module that does not depend on any opened modules, it may also make sense to write out an olean file even in server mode. I have accidentally processed the whole standard library when working in another project on more occasions than I can count, only to redo all those computations when changing to the next project (e.g. another tests/ folder).

@Kha I absolutely agree. I also find the behavior of Isabelle to not show sorry (neither as a dot in a scroll bar nor as warning at the import statement) very annoying.
Would it be possible to set a /tainted/ flag or something in the olean file after it was produced? Would it be possible to add a special /end-of-file/ block describing the used axioms?

he had proved something in Isabelle, which turned out to still depend on a sorry, but he didn't notice because there is no warning at all in Isabelle

Ok, maybe I should reiterate some of the changes in this PR.  By default, we only show errors for the currently visible lines.  We do this for a few reasons.

Flycheck.  Updating many errors makes emacs unresponsive.  The easiest way to improve flycheck performance is to show fewer errors.
Long files.  If we always check the whole file, then working on the beginning of a long file is very uncomfortable.  Only checking the first part improves responsiveness.  This will get even better when we stop parsing as soon as we leave the visible part.
Consistency.  We could show all produced errors for the current file, even if they are outside of the part that we actively check.  But I feel that this would be even more confusing, since whether or not these errors are produced depends on where you have scrolled before.  (E.g. you would not normally see an error in a proof at the end of a file, but you would see it if you had previously scrolled to the end and back.)

Now, this behavior is configurable.  You can switch to "check visible file" mode, which checks (and shows errors for) the whole file.  I think including sorry checks would fit well in this extended mode.
My intention was that "check visible lines" would be used when you're working on a proof and just want to see errors in the current proof and have the editor be as responsive as possible.  You'd then switch to "check visible files" to get a more global overview.

I have accidentally processed the whole standard library when working in another project on more occasions than I can count,

The change with regards to sorry reporting addresses precisely this issue, but in a slightly different way: we no longer process the whole standard library.  Essentially all proofs get skipped.
This may be a bit overkill for the standard library where we have mostly definitions, but I think it will greatly improve responsiveness in formalizations with many proofs.

Would it be possible to set a /tainted/ flag or something in the olean file after it was produced?

Yes, we have such a flag.  But in general, the files containing sorry will not be loaded from olean anyhow.

Would it be possible to add a special /end-of-file/ block describing the used axioms?

Do you want to see import statements annotated with "uses propext"?  Or would you like to see warnings for theorems that depend on axioms?  I think this would result in a huge number of warnings.  We always have #print axioms, which will also tell you if a proof uses sorry.
Or maybe I'm misunderstanding you: would you like the editor modes to insert an uneditable block of text at the end of each module summarizing the used axioms?

How about an opt-out setting that elaborates such proofs at lowest priority?

Just to make a concrete proposal:

"check visible lines" would skip the sorry check.
"check visible files" would perform them, but at lowest priority.

@kha If I understand you correctly, you'd like "check visible files" to be the default.  This would also show all errors for the visible files, not restricting them to the currently visible lines.

@kha If I understand you correctly, you'd like "check visible files" to be the default

I'm fine with "visible lines", I just think we shouldn't hide errors by default in any non-obvious way. So perhaps we should just be a bit more verbose, where applicable:

add an info message "dependencies not checked/still checking: ..." at the beginning of the file
add an info message "checked up to here" at the end of the ROI (Isabelle uses its annotated scroll bar for that)

Yes, we have such a flag. But in general, the files containing sorry will not be loaded from olean anyhow.

Ah, then it is mostly a misunderstanding on my side. Now I understand @Kha's comment on elaborating the dependent modules on low priority. But maybe add a forth option, to have:

No Check
Check visible lines
Check visible file
Check visible file and dependencies

My suggestion with the list of used axioms was more a generalization of the flag. So Lean would check at the import if sorry was in the list of axioms. And something like #print axioms would work without full elaboration. And you are right it would be only useful for propext. sorry is reported anyway, and choice is marked with noncomputable.
When the dependent modules are not fully elaborated, what is the current behavior of #print axioms? Does it show a warning that not all theorems are fully elaborated?
Btw, I didn't test this PR yet, but I love its idea :-)

When the dependent modules are not fully elaborated, what is the current behavior of #print axioms? Does it show a warning that not all theorems are fully elaborated?

The output of #print axioms is completely deterministic (and will also include user-defined axioms, in case it wasn't clear).  Right now it will block parsing until all the referenced proofs have been elaborated, but it is not difficult to change it so that this becomes async.

We could show all produced errors for the current file, even if they are outside of the part that we actively check.

By the way, that is Isabelle's behavior and I find it very acceptable (especially with an indicator of what parts of the file have been processed). Conversely, I just got very confused by an error in Lean not showing up because it was above the ROI.

@leodemoura How do we proceed with this branch?  BTW, I added your examples as a test case and everything works as expected.

@gebner, I just tried out this branch with my code. I can get the Lean server to consistently crash, by opening VS Code with just monoidal_categories/monoidal_category.lean open. It parses for a few seconds and then crashes. It's fine on the master branch.
git clone https://github.com/semorrison/lean-category-theory
cd lean-category-theory
git reset --hard 7cf08593e2b1749105d68fc9b88c32a6c6c403a4

@semorrison Thanks for testing!  This branch requires an updated version of the vscode extension from https://github.com/gebner/vscode-lean/tree/parallel2
But I just noticed that the updated extension no longer works with the current state of the branch, I'll fix it and notify you when it should work again.

@gebner I can merge it today. Is it ready?

@leodemoura Great.  I'm still tracking down the bug reported by Scott.  Aside from that the branch is ready.

@leodemoura The bug is fixed, feel free to merge.
@semorrison vscode now works again.

Just so that I don't lose track of it: I think this is the upstream vscode issue that would allow us to implement the "visible lines" mode. https://github.com/Microsoft/vscode/issues/588


New version 0.9.8 Redis URL Error

Hello,
I just upgraded to the new version 0.9.8 from version 0.9.7, and now I am facing this error
AttributeError: 'NoneType' object has no attribute 'startswith'
defender\utils.py", line 23, in
REDIS_SERVER = get_redis_connection()
defender\connection.py", line 35, in get_redis_connection
return redis.StrictRedis.from_url(config.DEFENDER_REDIS_URL)
redis\client.py", line 144, in from_url
connection_pool = ConnectionPool.from_url(url, **kwargs)
redis\connection.py", line 989, in from_url
url_options = parse_url(url)
redis\connection.py", line 879, in parse_url
url.startswith("redis://")
AttributeError: 'NoneType' object has no attribute 'startswith'

@omarfateh0, what do you have set for your DEFENDER_REDIS_URL config?
Also, which Redis library and version are you using?

@kencochrane it works fine with version 0.9.7 with the same configurations , I didn't change anything
here are the libraries I am using:
django-redis==5.4.0
redis==5.0.3
and this defender config url:
DEFENDER_REDIS_URL = f"redis://{REDIS_IP}:6379/0"

In the last release we removed a bunch of custom code to parse redis URLs and replaced it with the one built into the redis library. Probably related, but I'm not sure what is causing the issue.

Use redis parse_url method instead of a custom one (#234) [@dkr-sahar]

I tried to re-produce without Defender and it parses fine. And I'm able to re-produce your error by passing in a None value to redis.StrictRedis.from_url()
>>> REDIS_IP="<IP_ADDRESS>"
>>> DEFENDER_REDIS_URL = f"redis://{REDIS_IP}:6379/0"
>>> redis.StrictRedis.from_url(DEFENDER_REDIS_URL)
Redis<ConnectionPool<Connection<host=<IP_ADDRESS>,port=6379,db=0>>>

>>> redis.StrictRedis.from_url(None)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
    redis.StrictRedis.from_url(None)
  File "/usr/local/lib/python3.11/site-packages/redis/client.py", line 144, in from_url
    connection_pool = ConnectionPool.from_url(url, **kwargs)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 989, in from_url
    url_options = parse_url(url)
                  ^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/redis/connection.py", line 879, in parse_url
    url.startswith("redis://")
    ^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'startswith'

The code is very simple:
https://github.com/jazzband/django-defender/blob/master/defender/connection.py#L16C1-L35C69
def get_redis_connection():
    """ Get the redis connection if not using mock """
    if config.MOCK_REDIS:  # pragma: no cover
        import mockredis

        return mockredis.mock_strict_redis_client()  # pragma: no cover
    elif config.DEFENDER_REDIS_NAME:  # pragma: no cover
        try:
            cache = caches[config.DEFENDER_REDIS_NAME]
        except InvalidCacheBackendError:
            raise KeyError(INVALID_CACHE_ERROR_MSG.format(config.DEFENDER_REDIS_NAME))
        # every redis backend implement it own way to get the low level client
        try:
            # redis_cache.RedisCache case (django-redis-cache package)
            return cache.get_master_client()
        except AttributeError:
            # django_redis.cache.RedisCache case (django-redis package)
            return cache.client.get_client(True)
    else:  # pragma: no cover)
        return redis.StrictRedis.from_url(config.DEFENDER_REDIS_URL)

we care about these lines here:
    else:  # pragma: no cover)
        return redis.StrictRedis.from_url(config.DEFENDER_REDIS_URL)

It takes the value from config.DEFENDER_REDIS_URL which is basically the DEFENDER_REDIS_URL settings variable and if your setting isn't None, I'm not sure what is going on.
What am I missing?


Say dialog doesn't appear correctly in full screen

Reported on the forum

I tested this under Unity 5.0 and the Say Dialogs appear correctly on lower resolution fullscreen.
This appears to be a regression in the Unity UI system, rather than something in Fungus.
http://issuetracker.unity3d.com/issues/build-canvas-elements-are-placed-incorrectly-when-setting-non-native-resolution-in-standalone-build
Closing this bug while we await a fix in a future Unity release.


Internal packages in Dapr

Today, all our packages are packed in the pkg directory, which means anyone who depends on github.com/dapr/dapr, has access to all the exported functionality from pkg. However, a lot of code in pkg is internal to Dapr, i.e., it should not be a part of our public API. For example, https://github.com/dapr/dapr/tree/master/pkg/testing provides mocks for our internal unit testing.
 However, all packages can be imported.
...
An import of a path containing the element “internal” is disallowed if the importing code is outside the tree rooted at the parent of the “internal” directory.

Should we also invest in moving our code to the internal directory, instead of pkg?

In fact, we do not have a real "public API", I do not see harmful problems about being called by others, maybe I miss something important?

Yes, I was coming from more of a best practices point-of-view than a bad actor one.


Release Metal3 0.9.0

This is a major update containing the following changes:

Ironic dependencies are rebased to the latest 2024.2 stable OpenStack branch
The ironic container has been rebased to more closely align with the upstream metal3-io ironic-image which includes several fixes and security improvements, removal of the deprecated idrac-wsman driver, removal of the ironic-inspector, and enablement of sqlite as an alternative to mariadb
The metal3 baremetal-operator has been updated to the 0.8.0 upstream release, and the deployment reconfigured to remove the dependency on ironic-inspector (inspection is now handled via the ironic API)
Mariadb is now optional and disabled by default, on upgrade the mariadb deployment will be replaced by sqlite unless the new enable_mariadb variable is specified.
Persistent storage for the Ironic shared volume is now optional and disabled by default - on upgrade it will be necessary to ensure the size and storageClass persistence values are specified if you wish to retain a PVC in the deployment
The IPA ramdisk now supports a hosts.append parameter which can be passed via the ironicKernelParams chart value, e.g hosts.append=<IP_ADDRESS>_imagecache.local - this is comma-delimited and the _ will be translated into spaces, with each entry then appended to /etc/hosts - this is related to this Sylva issue

Marking this as draft pending further validation - @fdegir FYI there is a preview published at https://hardys.github.io/charts/

I will ask for validation in Sylva CI before we merge this but removed the draft status based on feedback above

The metal3 baremetal-operator has been updated to the 0.8.0 upstream release, and the deployment reconfigured to remove the dependency on ironic-inspector (inspection is now handled via the ironic API)

I understand that Ironic port tcp/5050 is no more used and inspection flow now uses port tcp/6385. Am I right ?

Hi @greenmaid yes that's correct - following the upstream Ironic community decision to deprecate the standalone ironic-inspector API the Metal3 upstream community agreed to make changes to align and use the inventory API that is part of the main Ironic API instead

Sylva validation of this was successful so I'll go ahead and merge this https://gitlab.com/sylva-projects/sylva-core/-/merge_requests/3297


This.

"You will no longer be able to boot without the SD card in, that is normal."
This is no longer the case. Finally.
Still requires Luma nightly though, so this will probably be added once a new official Luma3DS release comes out...

Why does this need an issue opened? The luma that works for it is still a nightly.... I'm sure once it comes out the guide will be updated for it even though it is pointless.

This will be added when it's included in a release.


Enhance tweening with different tween modes (LinearOut, LinearIn, EaseInAndOut)

See https://motioncanvas.io/docs/tweening/ for inspiration

more inspiration https://github.com/jeffreylanters/unity-tweens

TweenXPositionComponent(from, to)
TweenComponent returns progress and progressvalue / progressvalue is then mapped on from/to form=0%, to=100%

Use option 2. individual tweens not necessary when every component has a from, to option

implemented in main


Adding three subdirectories to a rollout document

What would you like to be added:
Add the AB-Test, Blue-Green Deploy and Canary Deploy subdirectories to the rollout document.
Why is this needed:
As more and more ingresses are supported by the Kurator Rollout feature, the corresponding documents will be confusing if they are all written under the existing release documents, and the subdirectories should be added and then classified according to the ingresses.

/assign


add a nice 503 page while alfresco loads

currently apache proxy times out with 503 if alfresco isn't ready; make a nice looking 503, preferably with an implicit reload

"We'll bee with you in a moment" :-D

Err no issue for the home page so attaching it here, where is the home page?

yep, its still looking for a load of javascript and css, needs stripping out

Once share has come up properly the elements load ok. But I thought the point of a home page was to add useful links and content, not just to copy the login form

have created a 503.html needs to be placed somewhere to overwrite, can see on fresh install using /503.html which redirects to /index.html


Added adaptor for SwiftModules.com

Tested locally, compiles without errors and returns results. An example query that returns results from both IBM and SM /v1/packages?q=coryalder.

Awesome, thanks so much! I added just nit picks, so once you fix those, I'll merge and deploy! 💯

Awesome, thanks!


Changes in Add Contributor File

Changes in Add Contributor File
Deleted unwanted spacing in the file
Removed the anchor link for adding Contributors from the parent project
Added a toggle button to show/hide list of contributors from the Parent project
Re-positioned the button and changed the appearance of the layout
[#OSF-4763]

Please resolve the merge conflicts.


Javaparser websocket

Coverage increased (+0.03%) to 77.093% when pulling 741355afa409e4a59211a4d151face8c4ac443b9 on Heliozoa:javaparser-websocket into 806ccff93d4c0a915cce1e16290ea2aad68bf682 on tdd-pingis:master.

Coverage increased (+0.03%) to 77.093% when pulling 75350137f5b3826b0b127f6628fcf31aa9e622d7 on Heliozoa:javaparser-websocket into 1660beb81966d716a69dbe6f3a535e642f405fd5 on tdd-pingis:master.


Cache host auth proto

Fixes #12

Coverage decreased (-1.8%) to 88.803% when pulling 991fa0bb0f3df0c89627d4e42644fc80e39336d5 on cache-host-auth-proto into 94a048de1f45519414208794ddaa80dad0c093f8 on master.


[Sql] Avoid using Operation as model suffix

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.Sql


Trying to create a context across probe executions for a plugin

Resolves #31
This create an environment where one probe could use a previously executed probe result to condition its execution.

I'm trying to push tests to your PR but getting a "permission denied" error. Can you check the box in the PR which says “Allow edits from maintainers.”?

Can you check the box in the PR which says “Allow edits from maintainers.”?

it's already activated.


As a user I can see XML search results inside the diagram view

...so that I can use the XML search as an "advanced diagram search".
Tasks

User searches in XML (i.e. for executionListener)
We allow him to highlight search results inside the diagram (if applicable, i.e. results are parts of elements, displayed on diagram)
Search results / highlighting is done using the existing diagram search facilities (try CTRL+F in BPMN diagram view).

This could be an alternative to https://github.com/camunda/camunda-modeler/issues/493.

Related to SUPPORT-2940.

Related: Highlight selected diagram elements in XML (https://github.com/camunda/camunda-modeler/issues/499).


FLUME-3409: httpclient security issue

https://issues.apache.org/jira/browse/FLUME-3409

please run the github actions tests again. You can do this by pushing an empty commit or if you have write access to the repository using the github ui

Thanks @busbey - I tried the rerun but it still failed.
I'm not really a Flume user - just a random ASF member concerned about projects not using secure dependencies.


Control if redis uses async-std or tokio via feature flags

I saw that this project was pulling in async-std in as a dependency. My project didn't otherwise use async-std, instead using tokio, and would prefer to avoid async-std if possible.
So to preserve the current behavior, I pulled out async-std-comp into its own feature flag and made it the default. I then tested this against my project that was already using rslock, setting default-features = false and features = ["tokio-comp"] and found that it was functionally the same, and saved me from compiling ~15 dependencies I evidently didn't need.
Since you directly depend on tokio anyways, I'm curious if the default shouldn't be tokio-comp instead of async-std-comp to avoid pulling in both, since downstream projects likely only include one or the other. Thoughts?

I have noticed a regression when dropping the lock guard, where when dropping it, it locks up tokio when doing the futures::executor::block_on call to unlock.
I believe that this discussion captures what I'm seeing https://github.com/tokio-rs/tokio/discussions/2653.
I will attempt to conditionally compile either futures::executor::block_on or tokio::task::spawn_blocking in the Drop impl depending on which is enabled.

I added an acquire_no_guard function to allow looping until a lock is acquired so downstream crates don't have to re-implement that themselves if they use the tokio-comp feature.
I would prefer acquire_guard to be the name of the function that returns a guard and acquire to be the name of the function that returns the plain lock, but for the sake of backwards compatibility, I have left acquire the same here.
Now, acquire() cannot be called if the tokio-comp feature is enabled, preventing the deadlock of Tokio's runtime.

Hello, thanks for working with me to integrate this change.
I've done my best to make the changes you requested. I differed by putting #[cfg(any(feature = "async-std-comp", feature = "tokio-comp"))] on the lock module instead of the LockManager struct because other structs rely on that struct anyways, making the module practically unusable without them. Applying the cfg condition to the module seems like a cleaner approach.

See the issue, the test suite runs with --all-features, causing the `not(tokio-cfg) dependent cfg to compile out the Drop impl. I will add cfgs to the test, and duplicate the test and alter the expected outcome if running with only async-std.

This is imperfect, because the test suite doesn't cover the currently failing test now.
I figure I should extend the workflow to test with different feature flags, but I'm unsure exactly how you want that to be done.
I figure having a single stable-toolchain job without the --all-features  flag to get the default crate behavior would be acceptable?

I figure having a single stable-toolchain job without the --all-features flag to get the default crate behavior would be acceptable?

good point, i am happy to accept this proposed stable-toolchain job to ensure tests run with default features