Skip to content

Conversation

@swamishiju
Copy link
Collaborator

Removed check for struct type and used same procedure for all empty arrays

@swamishiju swamishiju changed the title #2841 Fix for #2841 Apr 9, 2025
@swamishiju
Copy link
Collaborator Author

#2841

@swamishiju
Copy link
Collaborator Author

We still need to fix print for arrays they dont seem to be working properly

#2841 (comment)

@ubaidsk
Copy link
Collaborator

ubaidsk commented Apr 9, 2025

Does this PR also fix the print issue mentioned in #2841 (comment)?

@swamishiju
Copy link
Collaborator Author

swamishiju commented Apr 10, 2025

Doesn't fix the print issue i need to look into that i'm not sure rn where runtime printing is handled but it shouldn't take too long

@ubaidsk
Copy link
Collaborator

ubaidsk commented Apr 10, 2025

Ok. I think this is still good. It seems to fix some our integration tests without breaking other tests.

@ubaidsk ubaidsk merged commit afffb06 into lcompilers:main Apr 10, 2025
18 checks passed
@swamishiju
Copy link
Collaborator Author

swamishiju commented Apr 10, 2025

Does this PR also fix the print issue mentioned in #2841 (comment)?

@Shaikh-Ubaid The print issues can't be fixed until we have separated libasr because it is intended fortran behavior but not for python

Same problem with string tests also, why don't we have libasr as part of this repo now?

@ubaidsk
Copy link
Collaborator

ubaidsk commented Apr 12, 2025

Same problem with string tests also, why don't we have libasr as part of this repo now?

Going forward, the contribution workflow that we intend to use is that any changes to libasr needs to be sent to LFortran first, approved and merged there and then we just update the libasr commit in LPython. This ensures that any changes we do to LibASR in LPython are always compatible with that of LFortran. This also helps when we do LibASR sync, as now we just need to update the LibASR commit and get the lpython integration tests to pass.

@ubaidsk
Copy link
Collaborator

ubaidsk commented Apr 12, 2025

The print issues can't be fixed until we have separated libasr because it is intended fortran behavior but not for python

Could you elaborate on the intended behaviour for fortran and python, maybe sharing some small examples?

@swamishiju
Copy link
Collaborator Author

The print issues can't be fixed until we have separated libasr because it is intended fortran behavior but not for python

Could you elaborate on the intended behaviour for fortran and python, maybe sharing some small examples?

I discussed this today with Ondrej over Zulip

He said it was supposed to be handle by string_format_kind I think its probably not working

The examples I have in mind were

In fortran

Program Hello
integer, dimension(3,2) :: x
Print *, x
End Program Hello

prints

   0       0           0       0           0           0

Like in a straight line without any like formatting

This is what i think equivalent code for python would be

x:i32[3,2] = empty([3,2], dtype=int32)
print(x)

which pre-sync prints formatted

0 0 0
0 0 0 

I will look into this

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

Successfully merging this pull request may close these issues.

2 participants