public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: "Patrick Monnerat" <Patrick.Monnerat@datasphere.ch>
To: "Keith Seitz" <keiths@redhat.com>, <insight@sourceware.org>
Subject: RE: Is the project still alive ?
Date: Thu, 26 Jun 2014 10:15:00 -0000	[thread overview]
Message-ID: <AB5E58B87EB73C46A38073D8F459F113D9FEA7@dataspheresrv01> (raw)
In-Reply-To: <53AB5285.3020909@redhat.com>

 
Keith Seitz wrote:
> Hi, Patrick,

Hi Keith,
Thanks for your reply.

> I've been struggling with this very question for about a year now. It
isn't really clear to me that EOLing Insight would affect more than a
handful of people, and there are alternatives out there (Nemevier,
Eclipse-based standalone, QtCreator, Code::Blocks, ...).

I do not have statistics about use and installation count in Fedora, but
I received some crash reports and I can imagine some people are still
interested in insight in the Fedora community.

> A GIT repository exists, but I have not yet pushed it to sourceware.

Well, I saw sourceware git repo was empty and yesterday I started to try
to build a local git repo, using submodules. I hope we don't do the same
thing...

> When I last played with this, I wasn't very pleased by the direction
it was going. It was essentially a clone of the gdb repo with the
insight/libgui bits thrown in. Yuck. [If anyone has any better ideas,
I'm all eyes/ears.]

Submodules may help, but not completely: we cannot create the exact dir
structure as the CVS config did with git. In addition, gdbtk was part of
the "real" gdb directory and dropped out for the "gdb" checkout. With
the binutils-gdb git repo, we are in the opposite case.
I think migration to git can be done 2 ways:
1) Use submodules, then a rootdir script to "compose" the current dir
structure in a subdirectory.
2) Reorganize the Makefiles to have the gdbtk directory outside of gdb.
IMHO, 2) is more elegant, but harder to perform.
I tried yesterday solution 1), but I'm not happy either.

> At one time, my immediate for goal for the project was a slight/small
"reboot":
> 1) create GIT repo [created, not published, not happy with it]
> 2) NO in-tree Tcl, Tk, Itcl, Itk, iwidgets, etc. All must be provided
by the platform [or maybe on an auxiliary branch?]
> 3) Remove dependency on/prune libgui [TkTable is particularly
troubling]
> 4) Linux-only first "release"; cygwin using X and mingw to follow
> 5) Remove all the Foundry/Code Fusion junk from the tree and
simplify/audit the codebase.
> 6) Formalize and make "regular" snapshots/updates/releases

In my tentative, tcl/tk/itcl/itk are submodules from
github.com/tcklk/... And iwidgets (that is no longer within the itk
tree) is a snapshot since it is not kept in a git repo (using fossil). I
wanted to keep these bundles for the official insight repo, since
sourceware projects mostly seems "self-contained". But dropping the
bundles is OK for my one use. What about other users?
 
> I've toyed with jumping straight to a rewrite based on Tom Tromey's
python-based efforts, but it is still unclear whether that would work
well (enough?) on all the platforms I care about (Linux, MinGW, Cygwin).

That notwithstanding, I had convinced myself that I would need a
stop-gap solution until a rewrite was sufficiently advanced to be
useful.

You mean you want to drop (i)tcl/tk and use python? This would be a
great job, but would probably spend a long time before we have a running
version. This will also be the death of the present version, since no
update effort to the tcl/tk version will be done in the meantime. In
this case, I'd better EOL the Fedora package and re-emerge it when
Python version will be available.

> In the end, a part of me still believes that there is an audience for
Insight or something insight-like, i.e., a lightweight, *fast*, non-MI
GUI for gdb.

We're 100% OK on that :-)

Tell me if I can help.

Cheers,
Patrick

  reply	other threads:[~2014-06-26 10:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 11:28 Patrick Monnerat
2014-06-24 17:25 ` Bruce Dawson
2014-06-25 22:52 ` Keith Seitz
2014-06-26 10:15   ` Patrick Monnerat [this message]
2014-07-22 17:18   ` Tom Tromey
2014-07-22 17:42     ` Patrick Monnerat
2014-07-22 17:46       ` Keith Seitz
2014-07-23 10:14         ` Patrick Monnerat
2014-09-04  5:54 ` Pavel Fedin
2014-09-04  8:01   ` Richard Tierney
2014-09-04 12:39   ` Fernando Nasser
2014-06-25  5:44 Roland Schwingel
2014-06-25 10:43 ` Patrick Monnerat

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AB5E58B87EB73C46A38073D8F459F113D9FEA7@dataspheresrv01 \
    --to=patrick.monnerat@datasphere.ch \
    --cc=insight@sourceware.org \
    --cc=keiths@redhat.com \
    /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).