[Django] #21356: Instant auto-reloading on BSD / OS X
Django
------------------------------------------------+------------------------
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
In the wake of #9722, I'd like to implement the same feature on OS X,
preferably without external dependencies.
Pull request: https://github.com/django/django/pull/1830
However, I'm often seeing two or three reloads in a row when a single file
in changed. I'm not sure where that behavior comes from. Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/21356>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:1>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
I would limit the `fflags` to:
{{{
fflags = (
select.KQ_NOTE_DELETE |
select.KQ_NOTE_WRITE |
select.KQ_NOTE_EXTEND |
select.KQ_NOTE_RENAME
)
}}}
I suspect the reason for the multiple reloads is that modern text editors
do all sorts of fancy things to files, which could trigger extra events.
With the previous set of `fflags`, I haven't managed to trigger more than
one event by using the `touch` command, while my text editor (PyCharm)
would reload almost at every key stroke.
With the restricted set of `fflags`, I only get a reload when the changes
are committed, which is the expected outcome.
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:2>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Aymeric Augustin <aymeric.augustin@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"a023a84c060eaaa4cf520c33d9c73adab7af3d30"]:
{{{
#!CommitTicketReference repository=""
revision="a023a84c060eaaa4cf520c33d9c73adab7af3d30"
Merge pull request #1830 from aaugustin/instant-reload-os-x
Add instant autoreload on platforms supporting kqueue.
Fix #21356.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:3>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
I'm getting a `ValueError: current limit exceeds maximum limit`.
This happens in the PyCharm console, but not in the terminal.
`resource.getrlimit` returns `(10240, 9223372036854775807)` in PyCharm and
`(256, 9223372036854775807)` in the terminal.
The issue is `10240` is actually the kernel limit for my system as
demonstrated by `sysctl kern.maxfilesperproc`; so when we do `NOFILES_SOFT
+ len(filenames)` we try to go over the kernel hard limit which causes the
`ValueError`.
It's not clear to me why the second return value of `resource.getrlimit`
is not equal to the actual kernel hard limit...
I'm not sure how to proceed at this point.
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:4>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by loic84):
PR https://github.com/django/django/pull/1836.
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:5>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
Here's an alternative solution that gets the actual limit from the kernel.
https://github.com/django/django/pull/1838
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:6>
Django
Reporter: aaugustin | Owner: nobody
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Aymeric Augustin <aymeric.augustin@…>):
In [changeset:"2bba0d275bdf392deb144a6e83392a80d57c8c03"]:
{{{
#!CommitTicketReference repository=""
revision="2bba0d275bdf392deb144a6e83392a80d57c8c03"
Improved resource limits handling in the kqueue autoreloader.
Refs #21356. Thanks Loïc.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21356#comment:7>