Trying to install GEDIT

[jacobnavia]

Hi folks

I tried to install the open source package "GEDIT".

It needed a Tex package, and a Tex installation, what I did download.
But then it needs "style sheets" (whatever that may be)

It crashed during ./autogen.sh with missing xslt-stylesheets.

So, I cloned
git clone https://github.com/docbook/xslt10-stylesheets.git

OK

Bu then it says it needs perl package xml-xpath. I figured out that issuing
sudo apt-get install libxml-xpath-perl

would fix that.

Then it needed to read a file called .xmlc. After an houro so searching
I came to see an invisible fdirectory in the download of xstyle-sheets
called ".trevis" and ythere I found a xmlc file. I copied that to my
home directory and the script went a little bit further.

A package called "xerces" was needed. I found that and wen further.
I installed then a package that is called "saxon", that asked for money.
Happily there is a free version, but apparently it will not work.

1 Exception in thread "main" java.lang.NoClassDefFoundError:
com.icl.saxon.StyleSheet
2 at gnu.java.lang.MainThread.run(libgcj.so.17)
3 Caused by: java.lang.ClassNotFoundException:
com.icl.saxon.StyleSheet not found in gnu.gcj.runtime.System
ClassLoader{urls=[file:/usr/share/java/saxon.jar,file:/usr/share/java/xercesImpl.jar,file:/usr/share/java
/xml-resolver.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
4 at java.net.URLClassLoader.findClass(libgcj.so.17)
5 at java.lang.ClassLoader.loadClass(libgcj.so.17)
6 at java.lang.ClassLoader.loadClass(libgcj.so.17)
7 at gnu.java.lang.MainThread.run(libgcj.so.17)
8 make[2]: *** [af.xml] Error 1
9 Exception in thread "main" java.lang.NoClassDefFoundError:
com.icl.saxon.StyleSheet
10 at gnu.java.lang.MainThread.run(libgcj.so.17)
11 Caused by: java.lang.ClassNotFoundException:
com.icl.saxon.StyleSheet not found in gnu.gcj.runtime.System
ClassLoader{urls=[file:/usr/share/java/saxon.jar,file:/usr/share/java/xercesImpl.jar,file:/usr/share/java
/xml-resolver.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

I wanted to study Gedit because I want to write an editor and I thought
that I could learn it by studying the "gedit" source code, that is
advertised as an editor written in C.

Why a C program will need java/perl/xml/ etc is beyond me.

Why the documentation is mandatory? Why do I need all those megabytes of
different languages to compile a C-GTK based editor?

Mystery.

If anyone can tell me how to proceed I would be thankful.

Thanks in advance

Jacob

[Jens Stuckelberger]

On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:

> Why do I need all those megabytes of different languages to compile a C-
> GTK based editor?
>
> Mystery.

Not at all - it's a text editor for the GNOME environment.
Throwing all sorts of stuff into the mix is par for the course for this
desktop environment, which is succeeding beyond all expectation at making
sure that Linux remains a nonentity in the desktop.

[Scott Lurndal]

jacobnavia <ja...@jacob.remcomp.fr> writes:
>Hi folks
>
>I tried to install the open source package "GEDIT".

Using what linux distribution? All of them should have
the binary package available, and most of them have the
corresponding source code package available for download
which contains any configuration differences from the
upstream package required to build for your distribution.

E.g. Redhat has .srpms for each .rpm package. Install
the source package and use rpmbuild to initiate a rebuild
of the package. I'm sure the other distros have a method
to build from source any package they ship as a binary package.

>
>I wanted to study Gedit because I want to write an editor and I thought
>that I could learn it by studying the "gedit" source code, that is
>advertised as an editor written in C.

Try vim instead. Although it also has many dependencies, many of which
can be configured out with options to the ./configure command you
use to build it. It will use GTK2 if present to provide a GUI version.

https://www.vim.org/

gedit is heavily tied to the gnome desktop.

>
>Why a C program will need java/perl/xml/ etc is beyond me.

Modern editors generally do far more than just allow one to edit text.

The description of gedit itself (see its wiki page) should help
you to understand why a C program needs xml support (and perl to support
PCRE):

"gedit is the default text editor of the GNOME desktop
environment and part of the GNOME Core Applications. ...
It includes tools for editing source code and structured
text such as markup languages."

>
>Why the documentation is mandatory? Why do I need all those megabytes of
>different languages to compile a C-GTK based editor?
>
>Mystery.
>
>If anyone can tell me how to proceed I would be thankful.
>

See above. Use the source package distributed by your distribution.

If you're trying to build on windows, use the Ubuntu WSL, don't
bother with mingw or cygwin.

[Jasen Betts]

On 2018-10-05, Scott Lurndal <sc...@slp53.sl.home> wrote:
> jacobnavia <ja...@jacob.remcomp.fr> writes:
>>Hi folks
>>
>>I tried to install the open source package "GEDIT".
>

>>

>>Why a C program will need java/perl/xml/ etc is beyond me.
>
> Modern editors generally do far more than just allow one to edit text.
>
> The description of gedit itself (see its wiki page) should help
> you to understand why a C program needs xml support (and perl to support
> PCRE):

perl is not requiored for PCRE, PCRE is a separate C library - an
off-shoot of the Exim MTA project, not a descendant of perl.

> "gedit is the default text editor of the GNOME desktop
> environment and part of the GNOME Core Applications. ...
> It includes tools for editing source code and structured
> text such as markup languages."

>>Why the documentation is mandatory? Why do I need all those megabytes of
>>different languages to compile a C-GTK based editor?

It's because the devs decided to put the docs in the same repo as as the
software.

> See above. Use the source package distributed by your distribution.

> If you're trying to build on windows, use the Ubuntu WSL, don't
> bother with mingw or cygwin.

Yeah, mingw can be tricky. but most Gnome/GTK libraries are available if
you look hard enough.

--
Notsodium is mined on the banks of denial.

[Spiros Bousbouras]

On Fri, 5 Oct 2018 22:00:15 +0200
jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Hi folks
>
> I tried to install the open source package "GEDIT".
>
> It needed a Tex package, and a Tex installation, what I did download.
> But then it needs "style sheets" (whatever that may be)
>
> It crashed during ./autogen.sh with missing xslt-stylesheets.

Crashed or exited with an error message ? If it crashed then perhaps you
need to submit a bug report somehwere.

[...]

> I wanted to study Gedit because I want to write an editor and I thought
> that I could learn it by studying the "gedit" source code, that is
> advertised as an editor written in C.

Just what the world needs , another text editor. vim , emacs , nano and
many other text editors are written in C. Is there anything in particular
you want to learn ? Is your editor meant to run on console or a graphical
environment ?

[jacobnavia]

Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
> Just what the world needs , another text editor

I started writing the debugger for my linux version of lcc-win. It uses
the ptrace interface.

If I have my own debugger, I could use the same debugging info format as
I use under windows or use the "stabs" format, that I generate correctly
now.

If I would use the gnu "gdb" I would have to generate DWARF debug info,
what is an horrible MESS!

And I do want to show the CONTEXT where the program is executing, and
for that I need a text editor!

Besides I want a modern debugger, with automatic variable dispmlay (no
longer needed to write "print foo print bar" at each line like in gdb.

Besides an IDE would be handy to make it easier to use the compiler. I
have already one under windows, so I wanted to rewrite a better one
under linux.

[Ian Collins]

Why don't you just integrate your debugger with an existing IDE (or
three)? Most id not all IDEs on Linux work with gdb, so you should be
able to use what has already be written.

--
Ian.

[David Brown]

On 06/10/18 09:45, jacobnavia wrote:
> Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>> Just what the world needs , another text editor
>
> I started writing the debugger for my linux version of lcc-win. It uses
> the ptrace interface.
>
> If I have my own debugger, I could use the same debugging info format as
> I use under windows or use the "stabs" format, that I generate correctly
> now.
>
> If I would use the gnu "gdb" I would have to generate DWARF debug info,
> what is an horrible MESS!

gdb should be fine with stabs, I think.

Dwarf is the modern format for debugging information because it can
support far more detail than stabs - things like macro definitions,
tracking variables as they move between registers, showing structs that
are partly in registers, variables that have been eliminated or
transformed by optimisation, etc. I can well believe that it is a much
more complex format as it supports those features.

But AFAIUI gdb supports other formats, including stabs.

>
> And I do want to show the CONTEXT where the program is executing, and
> for that I need a text editor!
>
> Besides I want a modern debugger, with automatic variable dispmlay (no
> longer needed to write "print foo print bar" at each line like in gdb.
>
> Besides an IDE would be handy to make it easier to use the compiler. I
> have already one under windows, so I wanted to rewrite a better one
> under linux.
>
>

I fully agree that using an IDE is useful. Perhaps you could use
something like Eclipse or Netbeans as the IDE, and talk to the debugger
in the same way as they talk to gdb? If your debugger supports the same
MI interface as gdb, then you could use the existing debugger support in
those IDEs. If your debugger has its own methods for communicating with
the gui, then you might need to make your own plugins - that would, I
think, mean Java programming, but it would be a smaller project than
writing everything from scratch.

If you can use gdb, it would be easier - then you can use an existing
debugger and a range of existing IDEs on many platforms.

[Scott Lurndal]

jacobnavia <ja...@jacob.remcomp.fr> writes:
>Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>> Just what the world needs , another text editor
>

>If I would use the gnu "gdb" I would have to generate DWARF debug info,
>what is an horrible MESS!

Why do you say that?

[jacobnavia]

Le 06/10/2018 à 16:53, Scott Lurndal a écrit :
> jacobnavia <ja...@jacob.remcomp.fr> writes:

>> Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :

>>> Just what the world needs , another text editor
>>
>
>> If I would use the gnu "gdb" I would have to generate DWARF debug info,
>> what is an horrible MESS!
>
> Why do you say that?
>

Line numbers.

Under windows (and stabs) I just have to emit a record with line, PC
address. Very easy. Under DWARF I have to make a virtual table to be
decoded with a virtual machine that has its own "instruction set". That
means I have to recreate that virtual machine when emiytting the debug
info, and when reading it. No longer possible to make an easy line+PC
address record any more.

Then, there are the abbreviations for commands, etc etc. It is
incredibly complicated. I already generated info for #defines under
windows (no other compilers did, and MSVC doesn't even today as far as I
know) gcc doesn't either because when I type any #define MACRO under gdb
it never recognizes it.

Then there is the frame information (that I already generate for my C++
interface). The problem is that the DWARF specs aren't followed neither
by gcc nor by gdb, since they "optimized" them in undocumented ways, so
that if you follow the specs it will never work. I arrived to the
conclusion that the only way to do that is to generate EXACTLY what gcc
generates, even if it is incomprehensible if you refer to the published
DWARF specs.

One of the problems also was that the assembler has some "optimizations"
that are nowhere documented concerning how it assembles the stack frame
descriptions, since it will react to some bit patterns and emit
something else to "optimize" the stack frame info.

Figuring out all this is incredibly time consuming and messy: you are at
the mercy of the whims of gcc developers that can change everything from
version X.01 to X.02 without you being able to complain or to understand
why the new gcc / gdb version doesn't work anymore.

Yes, gdb understand sometimes the stabs that I generate, but it has a
bug with 64 bit arguments using stabs, that get mangled. I sent them a
patch for that 4-5 years ago but the bug is there today. Since they do
not use stabs any more, they will never fix it.

Using my own debugger I know what is going on. I wrote one under
windows. Of course in the first time I generated debug info that the
MSVC compiler would understand (CV09 standard). But then MSVC changed in
a whim to another (undocumented) debug info format and I was left in the
cold of course. So, I kept the CV09 standard and wrote my own debugger.

For linux I would prefer avoiding gdb/gcc as much as possible (as I
avoided MSVC/CodeView under windows)

[C W Rose]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Hi folks
>
> I tried to install the open source package "GEDIT".
>
> It needed a Tex package, and a Tex installation, what I did download.
> But then it needs "style sheets" (whatever that may be)
>
> It crashed during ./autogen.sh with missing xslt-stylesheets.
>
> So, I cloned
> git clone https://github.com/docbook/xslt10-stylesheets.git
>
> OK
>
> Bu then it says it needs perl package xml-xpath. I figured out that issuing
> sudo apt-get install libxml-xpath-perl
>
> would fix that.
>
> Then it needed to read a file called .xmlc. After an houro so searching
> I came to see an invisible fdirectory in the download of xstyle-sheets
> called ".trevis" and ythere I found a xmlc file. I copied that to my
> home directory and the script went a little bit further.
>
> A package called "xerces" was needed. I found that and wen further.
> I installed then a package that is called "saxon", that asked for money.
> Happily there is a free version, but apparently it will not work.
>

...

>
> If anyone can tell me how to proceed I would be thankful.
>

On an obsolete Linux system, gedit 2.30.4 builds correctly with
./configure && make. However, 3.8.3 fails with:

configure: error: Package requirements (
libxml-2.0 >= 2.5.0
glib-2.0 >= 2.28.0
gio-2.0 >= 2.35.4
gtk+-3.0 >= 3.7.10
gtksourceview-3.0 >= 3.2.0
libpeas-1.0 >= 1.7.0
libpeas-gtk-1.0 >= 1.7.0
gsettings-desktop-schemas
) were not met:

Requested 'gio-2.0 >= 2.35.4' but version of GIO is 2.34.3
Requested 'gtk+-3.0 >= 3.7.10' but version of GTK+ is 3.4.4
No package 'gtksourceview-3.0' found
No package 'libpeas-1.0' found
No package 'libpeas-gtk-1.0' found

Gnome is notorious for breaking APIs, so unless you want a full Gnome
system, I'd avoid Gedit - or find a 2.x version, which may be easier
to install. Or check the Elvis source code, if that's your interest.
No modern software documents its structure particularly well; the
documentation is now intended for users, not programmers.

Will

--
Unprovided with original learning, unformed in the habits of thinking,
unskilled in the arts of composition, I resolved to write a book.
-- Edward Gibbon

[Melzzzzz]

On 2018-10-05, jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Hi folks
>
> I tried to install the open source package "GEDIT".

Gedit is part of Gnome, so you will need Gnome of particular version.
Try editor that is standalone.

--
press any key to continue or any other to quit...

[jacobnavia]

Excuse me my ignorance but I thought that GTK+ was the equivalent of the
windows API for linux.

Is that wrong?

What other window APIs are there to use?

Thanks

[Lew Pitcher]

Long story short, Linux doesn't have /a/ windowing API; it has /many/
windowing APIs. Pick one. You can start here
https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries



--
Lew Pitcher
"In Skills, We Trust"

[Melzzzzz]

Qt. Plain X, plain Wayland and others...

>
> Thanks

[Jasen Betts]

On 2018-10-07, jacobnavia <ja...@jacob.remcomp.fr> wrote:

GTK+ is an application framework. the windowing API is Xlib

other frameowrks include

Lesstiff, Xforms (X11 not W3C), SDL, Qt, Tk, Xaw

some of those are also available on MS-windows,