Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Thu, Oct 27, 2016 at 12:58:14AM +0100, Dominik Vogt wrote:
> Ah.  Technically, the branch is probably as good as it will get.
> Any changed to the "stdint.h" branch can easily be backported, but
> that may not be necessary.
> 
> However, if we agree on this becoming the "long time stable"
> version we'll need something on the web page that explains:
> 
>  * What this release is and what future work it will receive
>(maintenance but no new features).
>  * Where information about version 2 and version 3 is found.
>  * What the plans for version 3 are.
> 
> We'll also need similar information for the mailing lists.  When
> we publish the release it must be clear that "that's it" and
> development of version 2 is finally over (unless steps up to take
> over the project).

Yes.

> Also, a first "very unstable" development release should already
> be in place so that people who are interested in the new work can
> download and try it and don't have to use git.

You can always point people here:

https://github.com/fvwmorg/fvwm/archive/master.zip

(Or any repo name) -- which will download HEAD of master.  No git needed.
Interestingly though, I just don't think that's as big a problem as you think
it is.

> Just thinking of it, once the version split is done, it must be
> possible to install version 2 and version 3 in parallel.  It is
> really possible at the moment?  A couple of days ago I've noticed
> that each "make install" just overwrites the files in
> $prefix/share.  Does the --program-suffix configure option work?
> Maybe we should make "--program-suffix=-3" the default for now?
> And we need to tell people how to install both versions in
> parallel.

It's not possible, no.  Plus, have you seen configure.ac lately?  It's a
bloody mess.  I don't think you'll have to worry about paralell
installs---if/when/maybe fvwm3 starts, we'll fix it there in a different way.

Kindly,
Thomas

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Thu, Oct 27, 2016 at 12:41:03AM +0100, Dominik Vogt wrote:
> On Thu, Oct 27, 2016 at 12:15:36AM +0100, Thomas Adam wrote:
> > On Wed, Oct 26, 2016 at 11:45:53PM +0100, Dominik Vogt wrote:
> > > Maybe, maybe not.  This work only changes the inner structure of
> > > the parser yet and has few user visible changes (some rarely
> > > triggered quoting issues).
> > 
> > Any chance we could at least get that done though?  It seems daft not to.
> 
> I'm not exactly sure what you're refering to with "that".

I'm referring to relesing fvwm2-stable and fvwm-2.6.7 -- that's still
outstanding, and from what I understand fvwm2-stable can be declared.
fvwm-2.6.7 is ready when the default-config is merged.

-- Thomas Adam

Separate or common project infrastructure fvwm v2/v3.

[Dominik Vogt]

This is important enough to warrant a separate discussion thread.

On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote:
> Oh, and the point of a separate repo still stands, in my eyes.  You might
> think it moot, or even an unnecessary point, but I feel it's a very important
> one.  It reinforces (psychologically) that it's separate from fvwm2.  It
> reinforces that fvwm3 is discrete, and it reinforces the idea that it will
> become divergent from fvwm2 quite quickly.

First of all, for me personally there is no psychological issue.
I can think of the continued work to be all new regardless of
which mailing list its discussed on and where the repository is
located.  It may be different for others.

>From the point of view of the users and the people reading
fvwm-workers I am very sceptical.  We have already abandoned cvs
in favour of git, and as you can see, this has even further
reduced the number of old timers who have set up a development
environment.  I'd be very careful about sending yet another "we
don't want to have anything to do with the old stuff" message to
the world.

Switching to new infrastructure, we'll automatically lose some of
the people that are interested in fvwm development, be it that
they miss that the mailing lists have moved or that they won't
understand why there are two projects with the same name and which
to look at.  On the other hand:

 * Staying on the same mailing list:  Readers will notice over time
   that we're working on something new, that version 3 will be a
   more modern and radically different thing than version 2.  They
   may become interested in it or not, only time will tell.  There
   is no information hurdle they have to take to find out that
   something new is being done.

   Bugs reported for fvwm-2.x will still be relevant to fvwm-3.x
   for a long time (depends on the bugs).  We don't want to keep
   people from reporting bugs on the list because they might think
   the project is dead when it has just moved.

 * Switching git repository:  Given that the current amount of
   work going into version 2.x is very low, having both versions
   in the same repository is certainly manageable.  It's just more
   work for anybody who is interested in both repos (and getting
   access to github *is* very cumbersome compared to cvs access in
   the past).

 * Switching to a new web space:  This would make us the target of
   ridicule for years and cause musch confusion.  How would we
   explain that there are two distict web pages for the same project
   that differ only in version number?  It would just be
   inconvenient for everybody.  All right, we would have to place
   a big announcement on the web page with a link that points to the
   version 2 related sub pages, but I think with two different web
   pages we'd have to do it on both anyway.

 * With new infrastructure we'd run the risk that fvwm is kicked
   out of even more distributions.

So, is there maybe *another* way to foster enthusiasm about a new,
incompatible version?  Maybe we just need to do some "public
relations" work here.  A while ago you started a discussion about
a new logo contest.  Great idea, why not make it an event around
the official "fork" date.  I'd be happy to donate another prize.
We'd have something "new" practically from day one.  Maybe an Irc
"fvwm version 3" kickoff party where we explain our plans for the
future?

> It's not as if we're backporting features or fixes between the two.

Of course I'll continue backporting fixes like the recent ones in
event handling in the window management core.  This code is
changes at a very low pace, and backports are easily done.

> Copy---if it makes you feel any easier--- the entirety of the
> files from fvwm's master branch to new fvwm3 repository.  Do your
> work there, the set up is

Not at all, that would just greatly complicate things and confuse
people.  What use would two copies of the same code in deifferent
repositories be?

> Do your work there, the set up is
> easy.  Having a separate fvwm3 repository also allows to integrate anything we
> wish to the main fvwm website as well (when that becomes appropriate).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Wed, Oct 26, 2016 at 11:45:53PM +0100, Dominik Vogt wrote:
> Maybe, maybe not.  This work only changes the inner structure of
> the parser yet and has few user visible changes (some rarely
> triggered quoting issues).

Any chance we could at least get that done though?  It seems daft not to.

[...]

-- Thomas Adam

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Dominik Vogt]

On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote:
> On Wed, Oct 26, 2016 at 02:21:57PM +0200, Dominik Vogt wrote:
> > First of all I hope I'll be able to find the crash caused by a free of a 
> > string that is still
> > used, then experiment with it to see whether a step by step replacement of 
> > the old
> > parser is feasible while keeping the old parser around for a while.  
> > Disentangling the
> > builtin functions from the parser without changing their syntax is an
> > important step towards a new parser with a new syntax.  As long as all the
> > functions do their own parsing, replacing the syntax is a huge amount of
> > work.
> 
> But what you're describing is the biggest piece of work which would almost
> define fvwm3.  Thus far, there's still an on-going discussion about how we're
> going to do that.  Heck, we haven't even declared fvwm2-stable or fvwm-2.6.7
> yet.  Aren't you jumping the gun a little?

Maybe, maybe not.  This work only changes the inner structure of
the parser yet and has few user visible changes (some rarely
triggered quoting issues).

> I'd argue---quite strongly---that any work towards a new parser should be done
> with breaking everything completely.  Sure, you can still keep some of the
> surrounding things, but trying to maintain backwards-compatibility isn't
> necessary given the measures we're putting in place for fvwm2's future.

It's not about staying compatible but about changing the parser in
steps with a useable intermediary result that can be tested.
Donig the parser from zero would mean to have nothing that works
even remotely for months.

> But at the moment, we haven't even discussed what that will look like, or what
> requirements we might have.  I started to do that recently when I put out a
> proposal for a new syntax to see how that fared.

Yeah, I've seen that.  The current work should be independent of
the syntax we're aiming at though.  I would imagine changing the
parser in several distinct steps:

  1. Restructuring the code so that different parsers can be plugged
 in at run time on a per builtin basis.
 [This is what the current  work is about.]

  2. Replace the current builtins parsing code with an abstract
 syntax description and provide a parsing core that can parse
 the input and provide the output the builtins need.
 [This is the really big chunk of work.]

  3. Replace the internal parser language (quoting, argument
 passing, variable expansion, conditional syntax etc.).

  4. Rewrite the builtins' syntax descriptions to a new style that
 will hopefully be easier to read, write and parse.

Note that once step 1 is complete, the following steps can be
written and tested in a separate parser plugin, so the code stays
useable even while the new parser is still under construction.
You just switch to the unfinished parser for certain commands.
Once the result is stable, the duplicate code can be eliminated
(or kept around for a while to give people more time to adapt).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...

[Dominik Vogt]

On Wed, Oct 26, 2016 at 08:40:02AM +0200, Florian Schmidt wrote:
> On 10/25/2016 06:38 PM, Dominik Vogt wrote:
> >Right.  A solution must disable the warnings on any compilers and
> >versions the developers use, and not break compilation anywhere.
> 
> The way I generally do it is check for the compiler, and then define
> a macro for gcc and for clang using those attributes. Admittedly,
> that works, because for the stuff I work on, those two are all that
> is expected to be ever used; something that probably cannot be said
> about fvwm.
> 
> In the end, this mail (and the one from yesterday) are outdated
> anyway

No, I'm still thinking about a possible solution that works
without using potentially unportable headers.  A colleague has
come up with this:

 x = (x >= 0) ? (((unsigned) x) & 0x7fff)
  : - ((- (unsigned) x) & 0x7fff);

Well, there's CARD16/INT16 defined in Xmd.h, maybe we should use
them instead of the the C standard headers.

> because I see you already found another solution via the
> SUPPRESSED_UNUSED_VAR_WARNING macro, so disregard my comments.

> But, since I'm curious: that macro doesn't have the problem of
> potentially masking warnings about using uninitialized variables?

I hope so, but that may depend on how clever the compiler is.

> I guess the important difference is that you only use , not x
> itself any more?

Yes.  Apparently when the pointer is used, Gcc thinks any value
set may be used, but does not consider it a potentially
uninitialised use. 

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...

[Florian Schmidt]

On 10/25/2016 06:38 PM, Dominik Vogt wrote:

Right.  A solution must disable the warnings on any compilers and
versions the developers use, and not break compilation anywhere.


The way I generally do it is check for the compiler, and then define a 
macro for gcc and for clang using those attributes. Admittedly, that 
works, because for the stuff I work on, those two are all that is 
expected to be ever used; something that probably cannot be said about fvwm.


In the end, this mail (and the one from yesterday) are outdated anyway 
because I see you already found another solution via the 
SUPPRESSED_UNUSED_VAR_WARNING macro, so disregard my comments.


But, since I'm curious: that macro doesn't have the problem of 
potentially masking warnings about using uninitialized variables? I 
guess the important difference is that you only use , not x itself any 
more? Still, that's interesting.



Florian

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Wed, Oct 26, 2016 at 02:21:57PM +0200, Dominik Vogt wrote:
> First of all I hope I'll be able to find the crash caused by a free of a 
> string that is still
> used, then experiment with it to see whether a step by step replacement of 
> the old
> parser is feasible while keeping the old parser around for a while.  
> Disentangling the
> builtin functions from the parser without changing their syntax is an
> important step towards a new parser with a new syntax.  As long as all the
> functions do their own parsing, replacing the syntax is a huge amount of
> work.

Yes, I remember that bug when we first started this, but it was a pain to
track down.  Hopefully you'll have more luck.  :)

But what you're describing is the biggest piece of work which would almost
define fvwm3.  Thus far, there's still an on-going discussion about how we're
going to do that.  Heck, we haven't even declared fvwm2-stable or fvwm-2.6.7
yet.  Aren't you jumping the gun a little?

I'd argue---quite strongly---that any work towards a new parser should be done
with breaking everything completely.  Sure, you can still keep some of the
surrounding things, but trying to maintain backwards-compatibility isn't
necessary given the measures we're putting in place for fvwm2's future.

But at the moment, we haven't even discussed what that will look like, or what
requirements we might have.  I started to do that recently when I put out a
proposal for a new syntax to see how that fared.

Oh, and the point of a separate repo still stands, in my eyes.  You might
think it moot, or even an unnecessary point, but I feel it's a very important
one.  It reinforces (psychologically) that it's separate from fvwm2.  It
reinforces that fvwm3 is discrete, and it reinforces the idea that it will
become divergent from fvwm2 quite quickly.  It's not as if we're backporting
features or fixes between the two.

Copy---if it makes you feel any easier---the entirety of the files from fvwm's
master branch to new fvwm3 repository.  Do your work there, the set up is
easy.  Having a separate fvwm3 repository also allows to integrate anything we
wish to the main fvwm website as well (when that becomes appropriate).

Kindly,
Thomas

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Dominik Vogt]

> Gesendet: Mittwoch, 26. Oktober 2016 um 12:06 Uhr
> Von: "Thomas Adam" 
> An: "Dominik Vogt" 
> Cc: fvwm-workers@fvwm.org
> Betreff: Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing 
> in __execu...
>
> On Wed, Oct 26, 2016 at 12:04:46PM +0200, Dominik Vogt wrote:
> > > On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote:
> > > >   Branch: refs/heads/dv/new-parser-2
> > ...
> > > 
> > > I ported all of this over before here:
> > > 
> > > https://github.com/fvwmorg/fvwm/tree/new-parser
> > > 
> > > You should just rebase that against master, and use that if it's any use?
> > 
> > This new branch is the result of rebasing the new-parser branch against 
> > master.  There
> > were some conflicts with the USE_DECOR removal patch, and rebase had some 
> > trouble
> > with the mvwm subdirectory, so I've rewritten the history to eliminate this 
> > directory
> > (and merged some commits for simplicity).
> 
> Cool -- but what do you intend to do with this work?

First of all I hope I'll be able to find the crash caused by a free of a string 
that is still
used, then experiment with it to see whether a step by step replacement of the 
old
parser is feasible while keeping the old parser around for a while.  
Disentangling the
builtin functions from the parser without changing their syntax is an important 
step
towards a new parser with a new syntax.  As long as all the functions do their 
own
parsing, replacing the syntax is a huge amount of work.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Wed, Oct 26, 2016 at 12:04:46PM +0200, Dominik Vogt wrote:
> > On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote:
> > >   Branch: refs/heads/dv/new-parser-2
> ...
> > 
> > I ported all of this over before here:
> > 
> > https://github.com/fvwmorg/fvwm/tree/new-parser
> > 
> > You should just rebase that against master, and use that if it's any use?
> 
> This new branch is the result of rebasing the new-parser branch against 
> master.  There
> were some conflicts with the USE_DECOR removal patch, and rebase had some 
> trouble
> with the mvwm subdirectory, so I've rewritten the history to eliminate this 
> directory
> (and merged some commits for simplicity).

Cool -- but what do you intend to do with this work?

Thomas

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Dominik Vogt]

> On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote:
> >   Branch: refs/heads/dv/new-parser-2
...
> 
> I ported all of this over before here:
> 
> https://github.com/fvwmorg/fvwm/tree/new-parser
> 
> You should just rebase that against master, and use that if it's any use?

This new branch is the result of rebasing the new-parser branch against master. 
 There
were some conflicts with the USE_DECOR removal patch, and rebase had some 
trouble
with the mvwm subdirectory, so I've rewritten the history to eliminate this 
directory
(and merged some commits for simplicity).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...

[Thomas Adam]

On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote:
>   Branch: refs/heads/dv/new-parser-2
>   Home:   https://github.com/fvwmorg/fvwm
>   Commit: 1d38f7a2727f28f1817e1c951bc07267002d2006
>   
> https://github.com/fvwmorg/fvwm/commit/1d38f7a2727f28f1817e1c951bc07267002d2006
>   Author: Dominik Vogt 
>   Date:   2016-10-25 (Tue, 25 Oct 2016)
> 
>   Changed paths:
> M fvwm/Makefile.am
> M fvwm/add_window.c
> M fvwm/builtins.c
> A fvwm/cmdparser.h
> A fvwm/cmdparser_old.c
> A fvwm/cmdparser_old.h
> M fvwm/colorset.c
> M fvwm/conditional.c
> M fvwm/events.c
> M fvwm/ewmh.c
> M fvwm/ewmh_events.c
> M fvwm/expand.c
> M fvwm/expand.h
> M fvwm/functions.c
> M fvwm/functions.h
> M fvwm/fvwm.c
> M fvwm/fvwm.h
> M fvwm/menucmd.c
> M fvwm/menus.c
> M fvwm/module_interface.c
> M fvwm/move_resize.c
> M fvwm/read.c
> M fvwm/repeat.c
> M fvwm/schedule.c
> M fvwm/update.c
> M fvwm/virtual.c
> M fvwm/windowlist.c
> 
>   Log Message:
>   ---
>   !!! Start work on replacing the parsing in __execute_command_line ...

I ported all of this over before here:

https://github.com/fvwmorg/fvwm/tree/new-parser

You should just rebase that against master, and use that if it's any use?

-- Thomas Adam