Re: evergreen: would like opening of files to follow a pattern in evergreen

[Martin Dorey]

I think it puts each one in the largest space remaining. I don't think anyone likes it much, not least as it doesn't scale and wastes quite a lot of today's wide screen real estate. Go for it.
 

From: Alan Carwile
Sent: Friday, November 07, 2014 10:26 AM
To: Martin Dorey
Subject: evergreen: would like opening of files to follow a pattern in evergreen
 

Martin,

 

After a search, as I click files to open them, evergreen follows some policy for where to place each file in the window.  It would be handy (sometimes, maybe even always) for evergreen to put the files in the same order as I open them, or maybe even the same order as the search results.  If I've got 5 files open already for one task, and then I want to open 5 more files for a very different task, I'd like to have the files end up as shown below, for example, assuming the tasks are named a and b.  Does evergreen have a way for making newly opened files go at the bottom of the list?

 

a1

a2

a3

a4

a5

b1

b2

b3

b4

b5

 

Even better would be the ability to hide currently open files, and then just show the newly open files.  Taken further, perhaps I could also stash tasks a and b and now work on c (with 3 files say), and then switch among tasks.  I bet you'd use this too, for when someone walks up to you with questions on a completely different topic than what you're working on.

Thanks,

Alan

[Elliott Hughes]

yeah, definitely when opening a batch of files it would be great to have them in order.

--
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 http://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

[Alan Carwile]

On the second part of the idea, essentially grouping sets of open files, I tried using workspaces.  I created two workspaces (docs1 and docs2) with the same base directory (~/work/docs).  My hope was to be able to open a couple files in one workspace and then a couple different files in another workspace.  However, even if I selected docs2 workspace before opening a file, it appeared in the docs1 workspace, probably based on the path. I also tried making a symbolic link (~/work/docs3 -> ~/work/docs) and then a workspace on ~/work/docs3) but that did not help.

 

Making opened files appear in the selected workspace area would help task switching and screen real estate.

 

Unfortunately I'm not getting (or making) time for implementation, but perhaps someone will get inspired…

Alan

 

From: Elliott Hughes [mailto:elliott....@gmail.com]
Sent: Friday, November 07, 2014 10:52 AM
To: evergre...@googlegroups.com; Alan Carwile
Subject: Re: evergreen: would like opening of files to follow a pattern in evergreen

 

yeah, definitely when opening a batch of files it would be great to have them in order.

On Fri Nov 07 2014 at 10:44:15 AM Martin Dorey <Martin...@hds.com> wrote:

[Martin Dorey]

I sometimes have workspaces on subdirectories of the same build tree.  That works m'kay.

[Elliott Hughes]

yeah, the Android tree's so large i live like that all the time.
that's what workspace meant: directory tree.

paths are canonicalized so that you don't accidentally end up editing
the same file twice courtesy of symbolic links. (i think this was a
particular problem at BlueArc because of trees of symlinks to header
files?)

i think the only workaround for what you're trying to do would be to
run multiple instances with different configuration directories.

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

[Martin Dorey]

(Dropping my work account, just so I don't get two copies of everything.)

> i think the only workaround for what you're trying to do would be to
run multiple instances with different configuration directories.

This might do the trick:

EVERGREEN_DOT_DIRECTORY=~/.evergreen-instance2 evergreen

If you want to throw files into both Evergreens from the command line, you might want to have that variable set for longer than the execution of that one command.

As Elliott hints, there's then no vim-style .swp protection against editing the same file twice. I know I'd get confused, but it has been occasionally useful, though more in the days when the startup time was a problem. It would be OT here, but here I go anyway: 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. In further derailment of the thread, in ~Real Work this week, I've got a threaded Ruby script that reimplements find(1), with no arguments, that I've finally got to run faster than find when the cache is hot, by direct use of getdents (I probably could and should have used readdir), specifically the d_type field.

[Elliott Hughes]

On Wed, Nov 26, 2014 at 2:25 PM, Martin Dorey <marti...@gmail.com> wrote:
> (Dropping my work account, just so I don't get two copies of everything.)
>
>> i think the only workaround for what you're trying to do would be to
> run multiple instances with different configuration directories.
>
> This might do the trick:
>
> EVERGREEN_DOT_DIRECTORY=~/.evergreen-instance2 evergreen
>
> If you want to throw files into both Evergreens from the command line, you might want to have that variable set for longer than the execution of that one command.
>
> As Elliott hints, there's then no vim-style .swp protection against editing the same file twice. I know I'd get confused, but it has been occasionally useful, though more in the days when the startup time was a problem. It would be OT here, but here I go anyway: 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.

interesting. i remember what you mean, but with the ridiculous spec
machine i have and the fact that i no longer use spinning disks, it
went away somewhere along the line. (i'm also using Ubuntu kernels
which might be another variable?)

> 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.

this is the indexing rather than the find in files?

> In further derailment of the thread, in ~Real Work this week, I've got a threaded Ruby script that reimplements find(1), with no arguments, that I've finally got to run faster than find when the cache is hot, by direct use of getdents (I probably could and should have used readdir), specifically the d_type field.

yeah, glibc has that available via readdir. bionic too, should you
start porting to Android :-)

[Martin Dorey]

> this is the indexing rather than the find in files?

Yes.

>> I've got a threaded Ruby script that reimplements find(1), with no arguments, that I've finally got to run faster than find when the cache is hot, by direct use of getdents

I don't suppose anyone's particularly interested but for future-me's reference I'd like to set the record straight.  I was up a blind alley.  The parallelism wasn't really working, due to the Global VM Lock that's still in Ruby 1.9 not being released round syscall.  Performance on this test case seems sensitive to the buffer size I was passing to getdents, so I guess I just happened to pass a different size than glibc.  I rewrote it in C++ and got some benefit even in the cold cache against a single rotating platter of doom.  I don't have such a repeatable and quantified test case for my real motivation, which involves a file server with tens of spinning disks, but it's completing a cache warming run in a couple of minutes where a do-nothing rsync from and to the same file server was taking up to seven hours in the cold cache condition.  That maybe halved the time taken by the following rsync - a handy improvement but not the game changer I was after.  I resorted to using a special-purpose mount with a raised actimeo, so the warmth wouldn't ebb away before rsync was done.  Between them, that seems to have done the trick.