consultingwerk / proparse

Proparse, forked from http://www.oehive.org/proparse/
Other
18 stars 9 forks source link

Remove redundancy in proparse #8

Closed mikefechner closed 7 years ago

mikefechner commented 7 years ago

The java project has a lot of redendancy. This includes the grammar files and parser logic.

We are using the ParseUnit:treeParser01 API to parse the syntax.

All other API's should be removed.

We should first try this in a branch - and when we still successfully build a .NET assembly merge this into the master.

akera-io commented 7 years ago

Any preference on the package name if we're to do some sort of refactoring?

or something new (de.consultingwerk.proparse)???

mikefechner commented 7 years ago

or something new (de.consultingwerk.proparse)???

It's still a "community" proparse. So I'd prefer to stick with one of the original proparse's. There's a small hope, that this makes it easier in the future to merge changes from other proparse variants out there (except for Gilles' version).

These are my current USING statements when dealing with Proparse:

USING com.joanju.proparse.NodeTypes              FROM ASSEMBLY .
USING org.prorefactor.core.JPNode                FROM ASSEMBLY .
USING org.prorefactor.nodetypes.*                FROM ASSEMBLY .
USING org.prorefactor.treeparser.*               FROM ASSEMBLY .

And this is how I do the parsing typically:

        DEFINE VARIABLE javafile       AS java.io.File                         NO-UNDO .
        DEFINE VARIABLE pu             AS org.prorefactor.treeparser.ParseUnit NO-UNDO .

        javafile = NEW java.io.File (pcFilename).

        pu = NEW ParseUnit(javafile).
        pu:treeParser01().

An for initialization:

          proparseEnv:configSet (pcFlag, pcValue).

(that is of type com.joanju.proparse.Environment)

and

        org.prorefactor.refactor.RefactorSession:invalidateCurrentSettings () .

        prsession = org.prorefactor.refactor.RefactorSession:getInstance().
        prsession:setContextDirName (SESSION:TEMP-DIRECTORY) .

        oBackward:clear().

Here's the ABL helper class we typically use. ProparseHelper.cls.txt

I would prefer if we don't have to change this - as there is other code, that also uses proparse directly.

marianedu commented 7 years ago

ok then, no changes in naming/packages just see what is redundant and is safe to be removed (hopefully)…

guess ParseUnit should be able to deal directly with a file name so you don’t have to create a java.io http://java.io/.File from .net :)

On 26 May 2017, at 09:30, Mike Fechner notifications@github.com wrote:

or something new (de.consultingwerk.proparse)???

It's still a "community" proparse. So I'd prefer to stick with one of the original proparse's. There's a small hope, that this makes it easier in the future to merge changes from other proparse variants out there (except for Gilles' version).

These are my current USING statements when dealing with Proparse:

USING com.joanju.proparse.NodeTypes FROM ASSEMBLY . USING org.prorefactor.core.JPNode FROM ASSEMBLY . USING org.prorefactor.nodetypes. FROM ASSEMBLY . USING org.prorefactor.treeparser. FROM ASSEMBLY . And this is how I do the parsing typically:

    DEFINE VARIABLE javafile       AS java.io.File                         NO-UNDO .
    DEFINE VARIABLE pu             AS org.prorefactor.treeparser.ParseUnit NO-UNDO .

    javafile = NEW java.io.File (pcFilename).

    pu = NEW ParseUnit(javafile).
    pu:treeParser01().

An for initialization:

      proparseEnv:configSet (pcFlag, pcValue).

(that is of type com.joanju.proparse.Environment)

and

    org.prorefactor.refactor.RefactorSession:invalidateCurrentSettings () .

    prsession = org.prorefactor.refactor.RefactorSession:getInstance().
    prsession:setContextDirName (SESSION:TEMP-DIRECTORY) .

    oBackward:clear().

Here's the ABL helper class we typically use. ProparseHelper.cls.txt https://github.com/consultingwerk/proparse/files/1031014/ProparseHelper.cls.txt I would prefer if we don't have to change this - as there is other code, that also uses proparse directly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/consultingwerk/proparse/issues/8#issuecomment-304203341, or mute the thread https://github.com/notifications/unsubscribe-auth/AChpBww8Z9QJCqgkgCXVTgSAZ6npvA1aks5r9nFrgaJpZM4NlSyk.

mikefechner commented 7 years ago

guess ParseUnit should be able to deal directly with a file name so you don’t have to create a java.io http://java.io/.File from .net :)

As an alternative signature - very welcome. But we should leave the method based on the Java.io.file there as well.

And when we're talking about that, a variant, that takes a string to be parsed (ABL source in a Character or Longchar and not in a file(name) ) that would be helpful as well.

I guess that there's a stringstream in Java?

akera-io commented 7 years ago

On 26 May 2017, at 09:40, Mike Fechner notifications@github.com<mailto:notifications@github.com> wrote:

guess ParseUnit should be able to deal directly with a file name so you don’t have to create a java.iohttp://java.io http://java.io/.File from .net :)

As an alternative signature - very welcome. But we should leave the method based on the Java.io.file there as well.

And when we're talking about that, a variant, that takes a string to be parsed (ABL source in a Character or Longchar and not in a file(name) ) that would be helpful as well.

I guess that there's a stringstream in Java?

most probably, will see what can be done there… not sure how would be able to convince the ABL to see the string as a longchar though, you’re the .net expert ;)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/consultingwerk/proparse/issues/8#issuecomment-304204882, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOgnoHPBWesStgJIuDc80iv5DObdgkuqks5r9nPYgaJpZM4NlSyk.

mikefechner commented 7 years ago

most probably, will see what can be done there… not sure how would be able to convince the ABL to see the string as a longchar though, you’re the .net expert ;)

Much simpler in this case. This INPUT is an ABL CHARACTER or LONGCHAR. If that get's BOX(ed) it will be a .NET System.String. ABL does not need to get convinced.

marianedu commented 7 years ago

did pushed some changes in a new branch (redundancy), check that out please and see if it works with .net

one of the three grammars/parsers was completely removed JPTreeParser, the base grammar in com.joanju.proparse seems to be used for core parsing while the TreeParser01 (the one used from .net) is a bit more advanced by using references with context qualifiers… so, at this point it does look like we have to keep them both.

did added some extra methods in ParseUnit so you can try something like this…

DEFINE VARIABLE pu AS org.prorefactor.treeparser.ParseUnit NO-UNDO .

// parse a file pu = NEW ParseUnit(pcFilename). pu:treeParser01().

// parse in-memory content pu = NEW ParseUnit(). // or give it a file name, anything works, defaults to ‘dummy.p’ :) pu:treeParser01(pcStreamContent).

when you have time to give it a try let me know how it goes and if ok will merge that back into the main branch

On 26 May 2017, at 09:49, Mike Fechner notifications@github.com wrote:

most probably, will see what can be done there… not sure how would be able to convince the ABL to see the string as a longchar though, you’re the .net expert ;)

Much simpler in this case. This INPUT is an ABL CHARACTER or LONGCHAR. If that get's BOX(ed) it will be a .NET System.String. ABL does not need to get convinced.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/consultingwerk/proparse/issues/8#issuecomment-304206183, or mute the thread https://github.com/notifications/unsubscribe-auth/AChpB5KIPmgy3noajgnoB-93JoXxYm9Yks5r9nYDgaJpZM4NlSyk.

mikefechner commented 7 years ago

I have tried the old API - based on the java.io.file parameter:

org.prorefactor.refactor.RefactorException: java.lang.RuntimeException: java.lang.NullPointerException

java.lang.RuntimeException: java.lang.NullPointerException

java.lang.NullPointerException:

Call Stack: ParseFile Consultingwerk.Studio.Proparse.ProparseHelper at line 1564 (.\Consultingwerk\Studio\Proparse\ProparseHelper.r) OpenFileForParsing Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1215 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) ultraToolbarsManager1_ToolClick Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1289 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) Consultingwerk/Studio/Proparse/start.p at line 482 (.\Consultingwerk\Studio\Proparse\start.r)

.NET Stack Trace: bei org.prorefactor.treeparser.ParseUnit.parse(String fileName, String fileContent)

bei org.prorefactor.treeparser.ParseUnit.parse(String fileName)

bei org.prorefactor.treeparser.ParseUnit.parse()

bei org.prorefactor.treeparser.ParseUnit.treeParser01()

Shown by: ShowErrorMessage Consultingwerk.Util.ErrorHelper at line 2081 (.\Consultingwerk\Util\ErrorHelper.r) OpenFileForParsing Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1222 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) ultraToolbarsManager1_ToolClick Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1289 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) Consultingwerk/Studio/Proparse/start.p at line 482 (.\Consultingwerk\Studio\Proparse\start.r)

akera-io commented 7 years ago

Might have been caused by a use of getPath instead of getAbsolutePath, the DoParse object only works with file name as input… can you share the exact code that gives that error? Maybe something I’m missing in Java unittests, normally from Java things works fine with absolute/relative path but it might just be something in ikvm.

Did pushed a change fixing the absolute path issue, let me know if that helps or there is something else.

Marian Edu

Acorn IT www.acorn-it.comhttp://www.acorn-it.com www.akera.iohttp://www.akera.io +40 740 036 212

On 29 May 2017, at 00:32, Mike Fechner notifications@github.com<mailto:notifications@github.com> wrote:

I have tried the old API - based on the java.io.file parameter:

org.prorefactor.refactor.RefactorException: java.lang.RuntimeException: java.lang.NullPointerException

java.lang.RuntimeException: java.lang.NullPointerException

java.lang.NullPointerException:

Call Stack: ParseFile Consultingwerk.Studio.Proparse.ProparseHelper at line 1564 (.\Consultingwerk\Studio\Proparse\ProparseHelper.r) OpenFileForParsing Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1215 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) ultraToolbarsManager1_ToolClick Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1289 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) Consultingwerk/Studio/Proparse/start.p at line 482 (.\Consultingwerk\Studio\Proparse\start.r)

.NET Stack Trace: bei org.prorefactor.treeparser.ParseUnit.parse(String fileName, String fileContent)

bei org.prorefactor.treeparser.ParseUnit.parse(String fileName)

bei org.prorefactor.treeparser.ParseUnit.parse()

bei org.prorefactor.treeparser.ParseUnit.treeParser01()

Shown by: ShowErrorMessage Consultingwerk.Util.ErrorHelper at line 2081 (.\Consultingwerk\Util\ErrorHelper.r) OpenFileForParsing Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1222 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) ultraToolbarsManager1_ToolClick Consultingwerk.Studio.Proparse.ProparseTreeViewForm at line 1289 (.\Consultingwerk\Studio\Proparse\ProparseTreeViewForm.r) Consultingwerk/Studio/Proparse/start.p at line 482 (.\Consultingwerk\Studio\Proparse\start.r)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/consultingwerk/proparse/issues/8#issuecomment-304541753, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOgnoP7lubehFudZ_h_i2zWPDmYk-ANsks5r-eflgaJpZM4NlSyk.

mikefechner commented 7 years ago

This seems to work now.