Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initializing defined types #37

Open
freevryheid opened this issue May 4, 2023 · 3 comments
Open

Initializing defined types #37

freevryheid opened this issue May 4, 2023 · 3 comments

Comments

@freevryheid
Copy link
Owner

This library makes heavy use of defined types from db, con, chunks, vectors, etc.

I've always been confused about the need to initialize defined types before using them. I noted that this was required for the duckdb_result type to pass some early tests, but many of the later tests are passing without initializing the types. This may be compiler related too - we've only tested on gfortran. Anyways, something to consider moving forward.

@ludnic
Copy link
Collaborator

ludnic commented May 4, 2023

This comment reminded me that I was looking at setting up a CI action to run the tests, so I went ahead and added it. The test is failing because of the strange behaviour in retrieving the values in the chunks test.

I don't know the answer regarding initialisation. btw, just to clarify do you mean derived types or is defined types something else I don't know about? if so I see the internal c_ptr is always initialised to c_null_ptr so I was assuming that would be enough.

 type, bind(c) :: duckdb_data_chunk
    type(c_ptr) :: dtck = c_null_ptr
  end type

I saw some of the tests rely on passing a null pointer rather than one of the derived types (or C structures), which we can't do in the fortran API. So I was thinking that an uninitialised type would already have that null pointer and be equivalent. For example:

status = duckdb_appender_flush(nullptr);
REQUIRE(status == DuckDBError);

I have implemented as:

type(duckdb_appender) :: a 
status = duckdb_appender_close(a)
call check(error, status == duckdberror)
if (allocated(error)) return 

assuming that the uninitalised appender is equivalent to a nullptr because a%appdr = c_null_ptr. not sure if it makes fully sense tho.

@freevryheid
Copy link
Owner Author

My bad - I meant derived type. Yes, it appears that the initialization of the derived type is applied when first defined so that an explicit call as in : chunk = duckdb_data_chunk(), doesn't appear to be necessary. This would only serve to reinitialize an already initialized derived type.

I've never setup CI actions - have you seen this: https://github.com/awvwgk/setup-fortran

@ludnic
Copy link
Collaborator

ludnic commented May 8, 2023

I've never setup CI actions - have you seen this: https://github.com/awvwgk/setup-fortran

yes I have seen it and it's great. Indeed was part to experiment with it that I have done #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants