Spelling exceptions changes

[Martin Dorey]

Your check-in comments for these changes, Elliott, say what you're doing but don't explain why.  If it's about startup performance, then surely the elephant in the room is the list of source files, but why not generate the Ruby list as part of the build rather than dooming it to be increasingly stale with:

https://github.com/software-jessies-org/jessies/commit/e18a16185a0e0a005dc38b2797e9308b4979e948

Here you don't address the removal of numerous names, like rdbuf, that look like they will now cause unhelpful squiggly red underlines:

https://github.com/software-jessies-org/jessies/commit/1d91f9e79015605c0a000b209fca8a6af1aa3850

[Elliott Hughes]

On Sun, Sep 16, 2018 at 12:47 PM Martin Dorey <marti...@gmail.com> wrote:

Your check-in comments for these changes, Elliott, say what you're doing but don't explain why.  If it's about startup performance, then surely the elephant in the room is the list of source files,

you fixed that for low-end machines, remember, by postponing it :-)

on the low-end machine i've been dicking about on, this actually made a noticeable difference. (i'm also probably seeing what phil was complaining about a while back --- editing PosixJNI.cpp is pretty laggy, i think because all of the "spelling mistakes" [POSIX stuff that isn't in our list].)

 

but why not generate the Ruby list as part of the build rather than dooming it to be increasingly stale with:

https://github.com/software-jessies-org/jessies/commit/e18a16185a0e0a005dc38b2797e9308b4979e948

Here you don't address the removal of numerous names, like rdbuf, that look like they will now cause unhelpful squiggly red underlines:

https://github.com/software-jessies-org/jessies/commit/1d91f9e79015605c0a000b209fca8a6af1aa3850

i had two aims: startup performance (as you guessed) and, ironically, being less out of date. my plan was to move Ruby, C++, and Java over to scripts that we can run. the idea being that these things only change roughly once per year.

the ruby -- modulo the question of whether we'll remember to regenerate, but we could always put that in the top-level makefile? -- seemed fine.

the C++ was an improvement for my motivating cases, but, yeah, i didn't notice that the cppreference.com index is only of names directly in std:: causing regression on stuff like rdbuf. and regenerating from the web in a build file (for something that changes once every ~3 years) seemed unreasonable.

i ran out of time to do anything with java (because i was distracted trying to find a download like there used to be --- i wanted to test my script against a local copy, even if my plan was to just point it at the canonical copy on the web and run it once per year).

anyway, sorry, i added so many words (and the previous file wasn't sorted), so i didn't realize that some had gone missing. if it's too annoying (given that you noticed so quickly), just concatenate the old file for now? if i need to read far more pages, maybe i should work from a downloaded archive, but the links for that also lead to https://github.com/jeaye/stdman which might be a much simpler solution: they've already automated the work, so i can just pull the identifiers we need from their filenames.

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.
Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

--

Elliott Hughes - http://www.jessies.org/~enh/

[Martin Dorey]

On Sun, Sep 16, 2018 at 9:56 PM Elliott Hughes <elliott....@gmail.com> wrote:

On Sun, Sep 16, 2018 at 12:47 PM Martin Dorey <marti...@gmail.com> wrote:

Your check-in comments for these changes, Elliott, say what you're doing but don't explain why.  If it's about startup performance, then surely the elephant in the room is the list of source files,

you fixed that for low-end machines, remember, by postponing it :-)

I didn't remember that.  I had a look for what you might mean and found:

https://github.com/software-jessies-org/jessies/commit/c45c1c0ca8a95b8431a335b2518fddd7d905fbb5

That cites an email thread in which I wrote: "I've had to run with that thread pool hacked to be single-threaded ever since I left Debian Etch and 2.6.18.  Every new kernel, I try again and every one, it gets slammed with io when I have a cold cache.  And when I have a hot cache, it makes ~no difference how many threads I use - it's done before I start throwing a tantrum."

I lost that hack somewhere along the way, but, after realizing that ~/.evergreen isn't in use, I see I do have the preference set in ~/.e.edit.Edit/app-preferences.  I wouldn't say it was "fixed".  Well, the machine remains usable while Evergreen starts up, hurrah, but Evergreen isn't, in that it doesn't have a file list, which is quite crippling when you want to start working on something.  I thought it was supposed to do something like prioritizing the focused workspace, but, empirically, it just keeps chugging through them in alphabetical order.  Restarting with a hot cache took about 2.5 minutes with the preference set and, contra my "no difference" claim from before, 30 seconds with the default.  So there's no one good setting, even on this one machine.

i had two aims: startup performance (as you guessed) and, ironically, being less out of date.

Thanks for clarifying.

 

if it's too annoying (given that you noticed so quickly)

It hasn't been.  My nightly build, the one that uploads the installers to Google Drive, includes the output of git pull near the start of its mail to me.  That's usually enough to send me looking at the commits.  I thought it'd be better to comment while it was fresh than wait until it was just a nagging memory.

[Phil Norman]

Note that if we change evergreen to delegate the file scan to a script, you could have a script that caches the last seen result in a text file somewhere.

Just saying 

--

[Elliott Hughes]

On Tue, Sep 18, 2018 at 10:58 AM Martin Dorey <marti...@gmail.com> wrote:

On Sun, Sep 16, 2018 at 9:56 PM Elliott Hughes <elliott....@gmail.com> wrote:

On Sun, Sep 16, 2018 at 12:47 PM Martin Dorey <marti...@gmail.com> wrote:

Your check-in comments for these changes, Elliott, say what you're doing but don't explain why.  If it's about startup performance, then surely the elephant in the room is the list of source files,

you fixed that for low-end machines, remember, by postponing it :-)

I didn't remember that.  I had a look for what you might mean and found:

https://github.com/software-jessies-org/jessies/commit/c45c1c0ca8a95b8431a335b2518fddd7d905fbb5

That cites an email thread in which I wrote: "I've had to run with that thread pool hacked to be single-threaded ever since I left Debian Etch and 2.6.18.  Every new kernel, I try again and every one, it gets slammed with io when I have a cold cache.  And when I have a hot cache, it makes ~no difference how many threads I use - it's done before I start throwing a tantrum."

oh, looks like i was confusing that with something different that i'd done years earlier (search for "Workers free to start after").

 

I lost that hack somewhere along the way, but, after realizing that ~/.evergreen isn't in use, I see I do have the preference set in ~/.e.edit.Edit/app-preferences.  I wouldn't say it was "fixed".  Well, the machine remains usable while Evergreen starts up, hurrah, but Evergreen isn't, in that it doesn't have a file list, which is quite crippling when you want to start working on something.  I thought it was supposed to do something like prioritizing the focused workspace, but, empirically, it just keeps chugging through them in alphabetical order.  Restarting with a hot cache took about 2.5 minutes with the preference set and, contra my "no difference" claim from before, 30 seconds with the default.  So there's no one good setting, even on this one machine.

my weak machine (spinning rust, ~10yrs old) only deals with personal projects, so no more than 1k files.

my work machine deals with the Android source tree, but it's quite a big machine (SSD, multi-socket Xeon, ridiculous amounts of everything) and even so i don't try to have one workspace for the whole tree. i have a workspace for bionic/ and another for system/core/ and another for the linux kernel, and so on, so they're all fairly small too.

maybe i should try to scale to a whole AOSP tree. might be an interesting exercise. i'm not sure it's practical though. no IDE i know of scales anything like that far.

 

i had two aims: startup performance (as you guessed) and, ironically, being less out of date.

Thanks for clarifying.

 

if it's too annoying (given that you noticed so quickly)

It hasn't been.  My nightly build, the one that uploads the installers to Google Drive, includes the output of git pull near the start of its mail to me.  That's usually enough to send me looking at the commits.  I thought it'd be better to comment while it was fresh than wait until it was just a nagging memory.

i just pushed my suggested fix of using that guy's man pages too.

i'm tempted to follow up by doing similar with man7.org to include all the POSIX identifiers too. (but to be really useful we need to understand man pages a bit better --- posix_spawn.3, for example, contains a whole lot of different identifiers. as does something like errno.3.)

i'm more concerned about what to do about Java. if anyone has a better idea than parsing the HTML index off the web, let me know.

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.
Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

[Elliott Hughes]

then i need extra logic to deal with allowing it to call me back later with an updated answer. if we're going to cache, we may as well just do it automatically in /tmp rather than force everyone to do it manually for each workspace.

mad: would a cached file list + your existing "minimize i/o" setting work for you?

should we replace the "minimize i/o" setting with a "only index a workspace when it's touched" policy? we already don't open files from workspaces until they're switched to.

[Martin Dorey]

I'm confident that a cached file list and a single threaded refresh of that list, focused workspace first, on startup would be great.

[Martin Dorey]

> i just pushed my suggested fix of using that guy's man pages too.

That didn't fix the ones I'd started to notice, so I had another go at it, in a not particularly constructive way, but one that I warrant does address all the lost entries.

[Elliott Hughes]

sorry about that. i've fixed all of those (plus some more, by virtue of it being basically automated at this point), and pushed.

as i say in my final checkin comment in the group, we still have a POSIX-shaped problem to deal with at some point. but i think the latest list is definitely better than where we started at least.

[Elliott Hughes]

i have this change, but it's in my usual "works for me in one case on my small laptop with small projects, and i've been using it for about 5mins" state... want me to commit it anyway? send you a patch? wait until i've at least used it for a while?

(attached patch anyway, in case it's a while until we're next online at the same time...)

[Martin Dorey]

Thanks.  I applied it to my copy at work, where it will get something of a pounding.  I had a look after and it looked plausible enough to commit to me.

[Martin Dorey]

Cracking, thanks!

[Elliott Hughes]

pushed. (though now we have another merge commit to upset you because i didn't pull until after i committed...)

if there's something wrong with it that isn't easily fixed, feel free to just revert until we get time to fix it properly.

[Martin Dorey]

(Splicing and changing the subject to make replies to the wrong fork less likely.)

I've been resisting replying, knowing that as soon as I say how great it is, I'll find a problem, but I've just had a go at breaking it and failed, so I'll say it: that's so good that I've quit and restarted Evergreen several times over the last few days just because it's now painless.  Thanks!

On Sun, Oct 7, 2018 at 9:43 PM Elliott Hughes <elliott....@gmail.com> wrote:

pushed. (though now we have another merge commit to upset you because i didn't pull until after i committed...)

if there's something wrong with it that isn't easily fixed, feel free to just revert until we get time to fix it properly.

[Elliott Hughes]

Like so many other things, we could have done this years ago if we'd only thought of it...

I haven't noticed any problems with this, though I have seen with my clang-format changes that sometimes the tags panel gets upset until the next save. I haven't had chance to have a look yet, but since I'm the only user I'm assuming no one cares. Let me know otherwise. (That said, you really should try it!)

I see Phil working on Open Quickly... Good to know someone is using it. Given that the languages I use the most don't tend to have a one-to-one correspondence between filenames and their contents, I don't think I've used that once in the last decade. It was on my "should we remove this?" list. 

[Martin Dorey]

Weird, I use Open Quickly all the time, though I'll admit to occasionally being frustrated when it turns out that the bit of the filename I'd thought was unique enough needed an extra hint most easily supplied from content and, dammit, I'm in the wrong dialog for that.

[Elliott Hughes]

ah, sorry, i was confusing "Open Quickly" and "Open Import". i think of "Open Quickly" as just "Open"!

(and i'd forgotten that ctrl-O does something special if there's a selection.)

anyway, it was "Open Import" that i've been itching to remove :-)

[Phil Norman]

I never use 'open import'.

And yes, I worked a tiny bit of 'open quickly', but only to add a sanity check to the part of the feature that just tries to open a file directly if it looks like the selection is a filename (eg "// your comment here."). It'll still do the same thing, but if the file doesn't exist, it falls back to opening the 'open quickly' dialog rather than popping up an error saying "Couldn't open file '// your comment here.'".

From my side, removing 'open import' is fine. The feature can be implemented using a tool, anyway.

Cheers,

Phil

[Martin Dorey]

I don't think I've ever successfully used Open Import.