Re: [4diac-dev] Retiring the old FORTE C++ Exporter

[Alois Zoitl <alois.zoitl@xxxxxx>]

Hi,

I just pushed the commit which is removing the old FORTE exporter also from our repo [1]. The old exporter served as long and rather good but it is time for it
to go for good.

Fixing issues in the new Xtend based exporter in the last weeks showed me that this is definitely the way to go. Therefore please continue to test the new
exporter and report issues.

Cheers,
Alois


[1] https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/166815


On Tue, 2020-06-02 at 16:10 +0200, Alois Zoitl wrote:
> Yes there was an issue [1]. This is fixed now and should be available in the nightly build from tomorrow on.
>
> With that I will now also deactivate the old exporter. If you notice any issues please use the forte ng bug [2] for reporting.
>
> Cheers,
> Alois
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=563716
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=560721
>
>
> On Fri, 2020-05-29 at 14:03 +0200, Alois Zoitl wrote:
> > On Thu, 2020-05-28 at 23:19 +0200, Jörg Walter wrote:
> > > On 28.05.20 21:57, Alois Zoitl wrote:
> > > > > -- but I did encounter issues with the new workflow
> > > > > using the merge tool, which is why I continue using the old exporter. My
> > > > > build environment does a 3-way-merge on top of that, which means that mos.
> > > >
> > > > I'm not sure if I understand that, because the new and old exporter use the same infrastructure and should use the same merge tool
> > >
> > > Strange... It automatically popped up the diff tool when using the new
> > > exporter, but not when using the old exporter. I thought it had
> > > something to do with the exporter, maybe it was a user error?
> >
> > There is a checkbox if files should be silently overwritten or merged. I sofar always wanted to see the merges as I was doing bug fixes on the exporter to see
> > the differences. However now that you mention it I think hitting yes for overwriting also showed me the merge tool. I'll file a bug and look into it. Also yes
> > should be renamed into overwrite.
> > > > > I do appreciate the effort, however, and I think this is exactly the
> > > > > right direction, it just needs to be a 3-way-merge (old unedited file
> > > > > vs. new unedited file vs. old file with user-edits). Does the merging
> > > > > plugin support that?
> > > >
> > > > Would be hard if you don't have the old unedited file. Where should 4diac IDE get that from?
> > > > Furthermore the Eclipse merge tool which we are using currently only supports a two way merge. I don't know how to change this.
> > >
> > > Well then this discussion is hypothetical for the time being, but this
> > > is how I imagine it: during 4days of 4diac I proposed to automatically
> > > export all modified FB types into a well-defined path inside the project
> > > tree, behind the scenes, each time a type was modified. If such a path
> > > were available, export could easily manage all three versions: the
> > > current plain export, the previous plain export, and the user-modified
> > > file.
> > >
> > > That would also allow auto-merges, popping up the merge tool only when
> > > there are conflicts. Right now I emulate such behaviour using some CMake
> > > scripting and the diff/patch tools, which also works pretty well but is
> > > not part of the IDE experience.
> >
> > Ah I still have to re-read all the ideas you had on the 4days of 4diac. with the new project layout we are stabilzing now this should be much better
> > implementable.
> >
> > > Regards,
> >
> > _______________________________________________
> > 4diac-dev mailing list
> > 4diac-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
>
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev