2012/6/1 ridiculous_fish <[email protected]>
> Hello Axel! I am honored to hear from you.
>
> I must thank you for fish. It was (and still is) an inspiration for me,
> both in
> its technical design, and also its user-facing simplicity and elegance
> relative
> to its peers.
Aw man... Thanks! :-)
BTW, I'm guessing you are the person (Craniata?) behind the blog also fount
at ridiculusfish.com? If so, may I return the favor by saying you are a
good writer? I learned stuff while being amused when reading the "I Didn't
Order That, So Why Is It On My Bill" articles among others.
> After several iterations of learning and forgetting bash, I gave
> fish a try. I will never forget how its syntax highlighting and
> completions just
> worked. It felt like my first lungful of air after breathing water all my
> life.
>
If you are indeed a fish, it's not obvious that is a good thing.
> I'm glad you agree with the design decisions for autosuggestions. There is
> indeed a $fish_color_autosuggestion, which is by default #555 (a subdued
> gray).
>
> If you're not seeing it, it's probably because I neglected to bump the
> version
> __fish_init_1_23_0 in fish_config_interactive, so it won't apply the
> first-launch defaults for current fish users (oops). Or it may be because
> your
> term doesn't support term256 - I'll work on a solution for non-term256
> users.
>
Like I think I said in another mail, I think "black --bold" should work, at
least on a majority of shells. It's quite possible that it will do
something ridiculous, like render invisible on a others, though. :-/
> > I would have either moved it to a separate process and communicated over
> a
> > socket or used cooperative threading, but I guess there is a chance that
> > simply means I'm very, very old.
>
> Or maybe wise. Combining threads with forks is very...delicate, and had I
> appreciated just how delicate it was, I might not have attempted it. It
> can be
> done safely and portably, and I claim to have done so, but it does require
> some
> contortions.
>
Would you say it is delicate as in the code is still fragile, or only that
it was a long journey to get it to a robust state? Can you give some
pointers to parts of the code that are less obvious?
> I'm not a big C++ fan, but I can see that basic_string and vector are much
> > nicer than what's possible to implement in straight C. I wouldn't
> > (and didn't) choose to use C++, but not really my choice to make anymore.
> > Use the language you like.
>
> I am neither a a C++ fan or a hater. The story is, I thought halloc was
> liable
> to cause problems in a multithreaded environment, and so I went looking
> for a
> new memory model. C++ seemed like a simple and readily available solution.
>
> I view C++ like drinking from a beer bong: a little is nice, but if you
> don't
> control yourself it's easy to swallow too much and wake up the following
> day
> with a protected abstract virtual base pure virtual private destructor in
> your
> bed. And nobody wants that. So my hope is to use C++ in a limited scope,
> and
> resist the urge for increased abstraction, templates, boost, etc.
>
I am dealing with a somewhat large and C++ code base at work right now,
written by extremely clever people who wanted to try out some extremely
clever ideas. Exceedingly fed up with C++ right now; a conversation about
the merits of C++ would not be constructive, so lets not have one.
By the way, initially I viewed halloc with some fear and revulsion, not
> really
> understanding it. Later I learned to appreciate its cleverness. Was this
> your
> own idea, or did you learn the technique from somewhere else?
>
Maybe I should have documented the code better, then. I really think it's a
pretty wonderful idea, and pretty much the nicest memory management model
you can find in languages without garbage collecting, IMO. Not my idea at
all, though. I got it from a very similar setup used by the samba project,
but the idea's been around for a lot longer than that. I rolled my own
version because I wanted to be able to call methods when deallocating, sort
of like a destructor in C++, which wasn't possible in the samba version.
> All source files have been renamed .c => .cpp, but the .h files are still
> > named .h.
>
> I'm glad to know this. Sadly, it looks like there is no extension that will
> satisfy emacs by default. Please correct me if I'm wrong.
>
.hh seems to work for me.
> > The repo at https://gitorious.org/~ridiculousfish/fish-shell/fishfishto be
> > significantly older than the tarball on the website. Is there an actual
> public
> > repo with the latest code available anywhere? If yes, sorry for the
> noise, if
> > no, I urge you to move to a more open development model. Making awesome
> > surprise release announcements is nice and seems to actually work pretty
> well
> > for Apple, but doesn't really gel with the open source model.
>
> fish development and maintenance seems to have been centralized at
> https://gitorious.org/fish-shell/, which reports all my changes. I did not
> announce anything (except to those who inquired directly) because I have a
> bad
> habit of getting excited, promising the moon, and then disappearing. I
> agree
> completely with using an open development model.
>
Good to hear about openness. I'm probably doing something wrong on my end,
though, because I can't seem to find your changes on gitorious. A quick
glance at the source listing implies that all branches there all use the .c
extension on all files. Am I doing something stupid?
> Why do bug tracking on github and repo tracking on gitorious?
>
> fish trunk is hosted on gitorious, and I wanted to stay close to that. But
> gitorious doesn't have an issue tracker (I sure wish it did). So the
> current
> dorky plan is to use gitorious for all development, and use github only
> for bug
> tracking. This, of course, sucks.
>
I think that is a bad plan.
How have issues been tracked in the past with gitorious? How do people feel
> about moving everything to github?
>
I'd like to hear answers to these questions, too.
> Point of interest. I never ever wrote fish to be fast - there are metric
> tons
> > of really obvious low hanging fruit, but I never saw the need because I
> never
> > had any performance problems with fish, even when using NFS on my 300 MHz
> > Pentium II with 256 MB of RAM. What parts of fish were running slowly
> and needed
> > optimization?
>
> Other than the aforementioned syntax-highlighting-on-slow-NFS-shares issue,
> startup was where I noticed the largest performance issues, especially
> when my
> system was under load. After some tests, I concluded this was due to the
> sheer
> number of files touched: every command requires a check for an autoloading
> function, in multiple directories. My Core i5 may smoke your Pentium II,
> but my
> 5400 RPM hard disk sure won't!
>
If I remember correctly, fish will stat all individual loadable files at
startup and after that will only check the modification date on the
directory the files live in, so the stat count during use should be fairly
manageable. Your interning of share/{functions,completions} should help
reduce the number of stat calls during startup, but the way it's done right
now has side effects, like we've noticed. Like I said yesterday, I believe
it's possible to implement this feature as a fallback after searching
$fish_function_path/$fish_completion_path, and that way you can get the
memory savings without any of the weird side effects. The only downside
would be the loss of discoverability - I think that checking out the
completion files in the shared-directory is an excellent way to get started
at writing your own completions, which I in the past found to be the most
common way to lure people into becoming fish contributors.
One idea I plan to try is to read the /functions/ directory entries
> up-front.
>
> I also suspect (but have not yet proven) that OS X has slower fork calls
> compared to Linux, and that this is especially bad in low-memory
> situations,
> which I encounter a lot. I plan to use posix_spawn() instead of fork() when
> possible, because posix_spawn requires less memory on some systems, and
> has some
> other nice benefits.
>
I believe that this is very much true. Now that you mention it, I seem to
remember that Mac users had exec-related performance problems back in the
day, but I never had them myself on Linux. Scratch your own itches, I
guess...
Axel, thank you again for your shell, and for your willingness to "pass the
> torch" as it were. It is a mystery to me why no other shell seems to place
> any
> importance on its UI, but I am sure glad you do.
>
>
:-)
Axel
> _fish
>
> (Incidentally, ridiculous_fish has been my online persona for about 15
> years;
> it's a happy/confusing accident that I got involved with the fish shell.)
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
