Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Sören Gebbert]

Hi,

[snip]
> IIUC, a higher-level C API would be between the current API and modules.
> What functionality is needed at this intermediate level ?
>
> Concerning the C++ API, I'm just a bit afraid that this will lead to more
> and more modules in C++ with the possible issues Markus mentions above.

Agreed.

>
> Also, what exactly is meant by:
>
> "Bridging of C++ RAII and try-catch with GRASS GIS C API exit and optional
> memory cleaning must be addressed."
>
> This sounds like another attempt to create persistent state in GRASS (I
> guess its this discussion [1] coming back ?). Again, I have no problem with
> discussing the issue once again, but I don't think this should be done
> within a GSoC project without prior discussion and consensus on the
> dev-list.

Agreed.

IMHO, there is no need for a higher level C or C++ API. Addressing the
memory and exit behavior of GRASS
can be managed in Python using an RPC interface to PyGRASS or
C-wrapper functionality [1].

It would be meaningful to improve the high level GRASS Python
interface that makes implementing
GRASS modules much easier than coding modules in C or C++.
Making the current GRASS RPC interface ground solid, providing more features,
so that it can be used in stable, long-running GUI applications may be
a better GSoC goal.

[1] https://grass.osgeo.org/grass73/manuals/libpython/_modules/pygrass/rpc.html

Just my 2cent
MfG
Sören
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

On 02/02/17 09:22, Markus Metz wrote:



On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras > wrote:



On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert

> wrote:


I don't really agree with the idea that

"Unfortunately, its [GRASS'] development is stagnating because of

small interest

from fresh and young developers. This is partially caused by the fact

that its design and

concepts are overcome by modern practices in a software development."

I do not see GRASS stagnating. And even though GRASS uses an "old"

language,



I think C is fine and that might be more clear now than in 2008, but

C++ is popular too.

C++ is more problematic in terms of portability and robustness over
time, have a look at the revision log of e.g. r.terraflow and the
iostream library.


However, the motivation for GSoC is make writing of modules in C and

C++ easier. We may discuss if "development is stagnating because of
small interest" is true or not, but for sure we can have better
interface which would attract more people.

Then the project should determine what is "better". This could be a
project where a concept is going to be developed without writing a
single line of code. The main objective would then be to first identify
what is bad or too complicated and how to improve on it.


More pressing problem however are the modules which use variants of

all-in-memory and tiling-on-disk raster reading modes. I'm not sure what
is the state now, because MarkusM fixed a lot of those, but some addons
were not included into core because of custom segment libraries (and
even now they have custom all-in-memory implementations).

There are only a few modules requiring random access and external memory
(e.g. but not only tiling on disk). IMHO, random access and usage of
external memory are special cases, and I don't see how a higher-level
API would help with these special cases.

All-in-memory processing is so simple that any API would IMHO make
things more complicated.

The interface to the segment library is pretty simple: you need only
Segment_open(), Segment_put(), Segment_get(), Segment_close().

Maybe it would help if there would a better description about the
differences in the tiling-on-disk methods available in GRASS, i.e. the
segment library, the read-only cache used by r.proj, and the rowio library.




I imagine that it's unpleasant if all you believe in is OO, but that

doesn't necessarily make OO the naturally best way to go... :-)



Similarly to Python API, OOP is not the only thing we should focus on.

C++ is a multiparadigm language and OOP is just part of it (e.g.
templates are kind of big), plus there are different levels of doing OOP
("C with classes" versus more complicated OOP). So yes, the student
should be familiar with more than just OOP.

Note that the vast majority of portability and compatibility issues
arises from Python and C++.

Maybe this proposal addresses two different things that could be kept
separated:
1) some higher-level C and C++ API


IIUC, a higher-level C API would be between the current API and modules. 
What functionality is needed at this intermediate level ?


Concerning the C++ API, I'm just a bit afraid that this will lead to 
more and more modules in C++ with the possible issues Markus mentions above.


Also, what exactly is meant by:

"Bridging of C++ RAII and try-catch with GRASS GIS C API exit and 
optional memory cleaning must be addressed."


This sounds like another attempt to create persistent state in GRASS (I 
guess its this discussion [1] coming back ?). Again, I have no problem 
with discussing the issue once again, but I don't think this should be 
done within a GSoC project without prior discussion and consensus on the 
dev-list.


Moritz


[1] https://lists.osgeo.org/pipermail/grass-dev/2014-April/068345.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Markus Metz]

On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras  wrote:
>
>
> On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>> I don't really agree with the idea that
>>
>> "Unfortunately, its [GRASS'] development is stagnating because of small
interest
>> from fresh and young developers. This is partially caused by the fact
that its design and
>> concepts are overcome by modern practices in a software development."
>>
>> I do not see GRASS stagnating. And even though GRASS uses an "old"
language,
>
>
> I think C is fine and that might be more clear now than in 2008, but C++
is popular too.

C++ is more problematic in terms of portability and robustness over time,
have a look at the revision log of e.g. r.terraflow and the iostream
library.

> However, the motivation for GSoC is make writing of modules in C and C++
easier. We may discuss if "development is stagnating because of small
interest" is true or not, but for sure we can have better interface which
would attract more people.

Then the project should determine what is "better". This could be a project
where a concept is going to be developed without writing a single line of
code. The main objective would then be to first identify what is bad or too
complicated and how to improve on it.

> More pressing problem however are the modules which use variants of
all-in-memory and tiling-on-disk raster reading modes. I'm not sure what is
the state now, because MarkusM fixed a lot of those, but some addons were
not included into core because of custom segment libraries (and even now
they have custom all-in-memory implementations).

There are only a few modules requiring random access and external memory
(e.g. but not only tiling on disk). IMHO, random access and usage of
external memory are special cases, and I don't see how a higher-level API
would help with these special cases.

All-in-memory processing is so simple that any API would IMHO make things
more complicated.

The interface to the segment library is pretty simple: you need only
Segment_open(), Segment_put(), Segment_get(), Segment_close().

Maybe it would help if there would a better description about the
differences in the tiling-on-disk methods available in GRASS, i.e. the
segment library, the read-only cache used by r.proj, and the rowio library.

>
>> I imagine that it's unpleasant if all you believe in is OO, but that
doesn't necessarily make OO the naturally best way to go... :-)
>
>
> Similarly to Python API, OOP is not the only thing we should focus on.
C++ is a multiparadigm language and OOP is just part of it (e.g. templates
are kind of big), plus there are different levels of doing OOP ("C with
classes" versus more complicated OOP). So yes, the student should be
familiar with more than just OOP.

Note that the vast majority of portability and compatibility issues arises
from Python and C++.

Maybe this proposal addresses two different things that could be kept
separated:
1) some higher-level C and C++ API
2) random read (and write) access to raster cells.

For both cases, a more detailed description of the objective would be
helpful.

my2c

Markus M
>
>>
>>
>> b) I'm afraid it's too big of a project for GSoC and that we would put
the student in an uncomfortable position.
>
>
> It should be much smaller than GAL project and it should be mostly
additions to API, not rewriting the libraries.
>
> That's at least my idea. I hope this clarifies it a bit.
>
> Vaclav
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert  wrote:

> >please take a look at GAL project from 2008 [1]. Ma
>
>
I didn't really work out the differences to GAL project but this GSoC
project should be less ambitious, much more limited, cover smaller part of
the functionality, and perhaps be less high level. Another difference would
be that the GSoC proposal aims to cover both C and C++ APIs and is limited
only to module development (no GUI-aware/friendly API).


>
> I don't really agree with the idea that
>
> "Unfortunately, its [GRASS'] development is stagnating because of small
> interest
> from fresh and young developers. This is partially caused by the fact that
> its design and
> concepts are overcome by modern practices in a software development."
>
> I do not see GRASS stagnating. And even though GRASS uses an "old"
> language,


I think C is fine and that might be more clear now than in 2008, but C++ is
popular too. However, the motivation for GSoC is make writing of modules in
C and C++ easier. We may discuss if "development is stagnating because of
small interest" is true or not, but for sure we can have better interface
which would attract more people. There are people writing custom C or C++
code for basic geospatial things which GRASS libraries do in a way which is
better than what they have or aim for.

More pressing problem however are the modules which use variants of
all-in-memory and tiling-on-disk raster reading modes. I'm not sure what is
the state now, because MarkusM fixed a lot of those, but some addons were
not included into core because of custom segment libraries (and even now
they have custom all-in-memory implementations).

I imagine that it's unpleasant if all you believe in is OO, but that
> doesn't necessarily make OO the naturally best way to go... :-)
>

Similarly to Python API, OOP is not the only thing we should focus on. C++
is a multiparadigm language and OOP is just part of it (e.g. templates are
kind of big), plus there are different levels of doing OOP ("C with
classes" versus more complicated OOP). So yes, the student should be
familiar with more than just OOP.


>
> b) I'm afraid it's too big of a project for GSoC and that we would put the
> student in an uncomfortable position.


It should be much smaller than GAL project and it should be mostly
additions to API, not rewriting the libraries.

That's at least my idea. I hope this clarifies it a bit.

Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

I did not include many details in the idea so here they are.

On Wed, Feb 1, 2017 at 11:59 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> I just the GSoC proposal for a "Higher level API for C and C++".
>

It it should not remove the existing API but build on to of it.


> I _think_ I understand where this comes from,
>

Good example is the random access to raster cells which runs in
all-in-memory and tiling-on-disk modes. Several modules need it, several
modules implement it in different ways. Segement library helps but solves
just part of the issue.


> but it does raise some very fundamental issues about how GRASS is written
> and should be written,
>

The implementation should stay the the intact, especially when talking
about GSoC. The point is to create a better API. Something link PyGRASS but
in C and C++. PyGRASS also uses existing C functions but wraps them in the
way they are easy to use (this would be case for C API) or more appropriate
to the language (C++).


> notably, but not only, the inclusion of a C++ API.
>

Add C++ API can be adding just few header files. Limiting the C++ API to
what "fits" into a header file has two advantages: same functionality needs
to be accessible in C API and it avoids (some/all?) issues of C++ linking.


>
> I just want to ensure that there is sufficient discussion on the list
> about such a project which could have far-reaching consequences. And if we
> ever decide to for such a project, then I think it has to be made
> absolutely clear that the student working on this needs to be extremely
> proficient in C/C++.
>

Agreed.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

Le 1 février 2017 21:02:25 GMT+01:00, Martin Landa  a 
écrit :
>Hi,
>
>2017-02-01 17:59 GMT+01:00 Moritz Lennert
>:
>> I just the GSoC proposal for a "Higher level API for C and C++". I
>_think_ I
>> understand where this comes from, but it does raise some very
>fundamental
>> issues about how GRASS is written and should be written, notably, but
>not
>> only, the inclusion of a C++ API.
>>
>> I just want to ensure that there is sufficient discussion on the list
>about
>> such a project which could have far-reaching consequences. And if we
>ever
>> decide to for such a project, then I think it has to be made
>absolutely
>> clear that the student working on this needs to be extremely
>proficient in
>> C/C++. Otherwise, I'm afraid that we risk creating a great mess that
>might
>> need lots of cleanup work afterwards.
>
>please take a look at GAL project from 2008 [1]. Ma


Interesting. But was this ever discussed on the lists ?

I don't really agree with the idea that

"Unfortunately, its [GRASS'] development is stagnating because of small interest
from fresh and young developers. This is partially caused by the fact that its 
design and
concepts are overcome by modern practices in a software development."

I do not see GRASS stagnating. And even though GRASS uses an "old" language, 
and it's core was developed long ago, its code base, IMHO, still represents 
very good practice in terms of programming.

I also have to smile when reading that one of the obstacles to "modernization" 
of GRASS is the "unpleasant attitude of GRASS developers to the 
object­-oriented programming." 

I imagine that it's unpleasant if all you believe in is OO, but that doesn't 
necessarily make OO the naturally best way to go... :-)

All this said : I'm not against a reflection about a fundamental rewrite of 
GRASS, but a) it should be extensively discussed on this list before even 
starting to code anything and b) I'm afraid it's too big of a project for GSoC 
and that we would put the student in an uncomfortable position.

Moritz

>
>[1]
>https://dspace.vutbr.cz/xmlui/bitstream/handle/11012/53128/5989.pdf?sequence=1=y
>[2] https://ojs.cvut.cz/ojs/index.php/gi/article/viewFile/gi.3.1/2561
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Martin Landa]

Hi,

2017-02-01 17:59 GMT+01:00 Moritz Lennert :
> I just the GSoC proposal for a "Higher level API for C and C++". I _think_ I
> understand where this comes from, but it does raise some very fundamental
> issues about how GRASS is written and should be written, notably, but not
> only, the inclusion of a C++ API.
>
> I just want to ensure that there is sufficient discussion on the list about
> such a project which could have far-reaching consequences. And if we ever
> decide to for such a project, then I think it has to be made absolutely
> clear that the student working on this needs to be extremely proficient in
> C/C++. Otherwise, I'm afraid that we risk creating a great mess that might
> need lots of cleanup work afterwards.

please take a look at GAL project from 2008 [1]. Ma

[1] 
https://dspace.vutbr.cz/xmlui/bitstream/handle/11012/53128/5989.pdf?sequence=1=y
[2] https://ojs.cvut.cz/ojs/index.php/gi/article/viewFile/gi.3.1/2561

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

Hi,

I just the GSoC proposal for a "Higher level API for C and C++". I 
_think_ I understand where this comes from, but it does raise some very 
fundamental issues about how GRASS is written and should be written, 
notably, but not only, the inclusion of a C++ API.


I just want to ensure that there is sufficient discussion on the list 
about such a project which could have far-reaching consequences. And if 
we ever decide to for such a project, then I think it has to be made 
absolutely clear that the student working on this needs to be extremely 
proficient in C/C++. Otherwise, I'm afraid that we risk creating a great 
mess that might need lots of cleanup work afterwards.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev