From: Drew Adams <drew.adams@oracle.com>
To: tomas@tuxteam.de, help-gnu-emacs@gnu.org
Subject: RE: Fatal error 11: Segmentation Fault
Date: Wed, 3 Apr 2019 10:06:41 -0700 (PDT) [thread overview]
Message-ID: <76a8206d-702c-484d-867c-912aa860d34a@default> (raw)
In-Reply-To: <20190403162903.GA22109@tuxteam.de>
> > > And here you see the price you pay for your
> > > above decision [...]
>
> > ... what approaches are there, again?
>
> I was talking about every piece of code (conditionally) pulling
> in its dependencies (with require, e.g.). This makes it much
> easier to skip parts without the whole construction breaking
> down. But hey -- it's just an offer. You are not forced to do
> it this way :-D
I tried suggesting the same thing. Imagine...
You're going on vacation. You make a list
of what you need to bring. For each thing
you think of you decide to list not only that
thing but also each of its parts.
For your car you list not only "car" but also
tires, engine, transmission, radio...
Why? Because you think it's easier somehow.
Because you can loop over your checklist...
Your car already requires its tires (at least
it should!). Leaving your car home should
automatically leave your tires home.
But if you list each bit separately then sure,
if you try to bring your car _without_ the
tires there'll be a problem because it thinks
it needs them (and it does).
This is why we have things like `require' -
they keep track of dependencies for us.
List only the things _you_ need to bring.
Make sure that things that require other
things know that they require them, so
_they_ take care of bringing whatever
_they_ need, saving you the bother.
Then if you leave something home none of
the things you bring with you will holler.
next prev parent reply other threads:[~2019-04-03 17:06 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 1:33 Fatal error 11: Segmentation Fault Emanuel Berg
2019-04-02 2:39 ` Emanuel Berg
2019-04-02 2:48 ` Drew Adams
2019-04-02 15:50 ` Emanuel Berg
2019-04-02 16:27 ` Drew Adams
2019-04-02 23:54 ` Emanuel Berg
2019-04-03 1:37 ` Drew Adams
2019-04-03 5:30 ` Emanuel Berg
2019-04-03 6:47 ` Emanuel Berg
2019-04-03 7:08 ` Eli Zaretskii
2019-04-03 7:49 ` Emanuel Berg
2019-04-03 8:18 ` tomas
2019-04-03 10:51 ` Using 'git bisect' to pinpoint errors in .emacs. Was: " Vegard Vesterheim
2019-04-03 11:14 ` Eli Zaretskii
2019-04-03 12:47 ` Vegard Vesterheim
2019-04-03 14:48 ` Emanuel Berg
2019-04-03 12:14 ` Skip Montanaro
2019-04-03 12:30 ` Eli Zaretskii
2019-04-03 14:52 ` Emanuel Berg
2019-04-03 15:41 ` Eli Zaretskii
2019-04-03 15:47 ` Emanuel Berg
2019-04-03 14:35 ` Emanuel Berg
2019-04-04 7:40 ` Vegard Vesterheim
2019-04-03 14:34 ` Emanuel Berg
2019-04-03 16:29 ` tomas
2019-04-03 17:06 ` Drew Adams [this message]
2019-04-03 19:19 ` tomas
2019-04-03 17:41 ` Robert Thorpe
2019-04-03 21:03 ` Emanuel Berg
2019-04-03 21:07 ` Robert Thorpe
2019-04-03 21:16 ` Emanuel Berg
2019-04-03 20:56 ` Emanuel Berg
2019-04-02 17:14 ` Óscar Fuentes
2019-04-02 23:56 ` Emanuel Berg
2019-04-03 0:05 ` Emanuel Berg
2019-04-03 0:13 ` Emanuel Berg
2019-04-03 1:20 ` Óscar Fuentes
2019-04-03 1:28 ` Óscar Fuentes
2019-04-03 2:33 ` Emanuel Berg
2019-04-03 2:39 ` Emanuel Berg
2019-04-03 4:47 ` Emanuel Berg
2019-04-03 5:23 ` Eli Zaretskii
2019-04-03 5:31 ` Emanuel Berg
2019-04-03 5:56 ` Eli Zaretskii
2019-04-03 6:48 ` Emanuel Berg
2019-04-03 6:59 ` Eli Zaretskii
2019-04-03 7:51 ` Emanuel Berg
2019-04-03 8:12 ` Eli Zaretskii
2019-04-03 14:21 ` Emanuel Berg
2019-04-03 14:36 ` Eli Zaretskii
2019-04-03 14:57 ` Emanuel Berg
2019-04-03 15:48 ` Eli Zaretskii
2019-04-03 21:05 ` Emanuel Berg
2019-04-04 12:51 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76a8206d-702c-484d-867c-912aa860d34a@default \
--to=drew.adams@oracle.com \
--cc=help-gnu-emacs@gnu.org \
--cc=tomas@tuxteam.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).