开云体育

I'm trying to get my build environment setup on windows, but there seems to be an error at build0 stage: ```shell (lf) C:\dev\src\github\lfortran\lfortran>build0 (lf) C:\dev\src\github\lfortran\lfortran>xonsh ./build0_win.xsh xonsh: To log full traceback to a file set: $XONSH_TRACEBACK_LOGFILE = <filename> Traceback (most recent call last): File "C:\Users\gauth\.conda\envs\lf\Lib\site-packages\xonsh\procs\proxies.py", line 523, in run r = self.f(self.args, sp_stdin, sp_stdout, sp_stderr, spec, spec.stack) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\gauth\.conda\envs\lf\Lib\site-packages\xonsh\cli_utils.py", line 649, in __call__ result = dispatch( ^^^^^^^^^ File "C:\Users\gauth\.conda\envs\lf\Lib\site-packages\xonsh\cli_utils.py", line 409, in dispatch parsed = parser.parse_args(args) ^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\gauth\.conda\envs\lf\Lib\argparse.py", line 1904, in parse_args args, argv = self.parse_known_args(args, namespace) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\gauth\.conda\envs\lf\Lib\argparse.py", line 1914, in parse_known_args return self._parse_known_args2(args, namespace, intermixed=False) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\gauth\.conda\envs\lf\Lib\argparse.py", line 1943, in _parse_known_args2 namespace, args = self._parse_known_args(args, namespace, intermixed) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ArgParser._parse_known_args() takes 3 positional arguments but 4 were given ``` any idea how I can troubleshoot? Thanks!

Hi, I'm adding lfortran to Debian. Its been accepted, should be in unstable next week and hopefully the next release. Lfortran builds using zlib statically (also zstd). Why ? Is this a performance thing or would shared zlib crash lfortran? This matters because for security and maintenance we use dynamic libs. In particular zlib has a bad history (better in recent times); when a security bug happens in a library, if its static then all copies embedded in all apps need to be discoverd and fixed and tested overnight, which is terrible compared to fixing in one place (the dynamic library). Ditto zstd. Thanks Alastair McKinstry

Hi, I'm interested in running LFortran on Windows and currently trying to find out what the problems are and how to solve them. One particular compatibility issue between the world of *NIX systems and Windows are filesystem paths, e.g. in src/libasr/string_utils.cpp there are functions (e.g. parent_path()) which assume '/' as the delimiter. These don't work on Windows. The obvious solution would be using the <filesystem> header here, but the following commit suggests it has been deliberately avoided: Revision: 1626bda3b150fd18f3457b1047027d468168a48a Author: Ond?ej ?ertík <ondrej@...> Date: 05.10.2022 23:46:49 Message: Implement path utilities We do not want to use std::filesystem yet, as it is not always available. On the other hand, <filesystem> is used in /src/libasr/utils.h as per the following commit: Revision: b58397bacfa097e93844457beedf6720c74bab65 Author: meow464 <meow464@...> Date: 22.10.2022 01:08:14 Message: Implement -I and -J (#930) So I wonder: What is the current policy regarding this header? Are PR's acceptable that make use of it to make LFortran run on Windows? Thanks Boris

My name is Neha . I'm a PHD student at University of Newcastle Australia and am willing to contribute to google season of docs. I have technical writing experience for NGO's and tech firms and have been working for open source for a while. I know Python and R and done few of the projects in them. I have experience in writing in Latex and other platforms

[AMD Official Use Only - General] Hello, I built and installed the following versions of Lfortran (from downloadable sources and the git versions): ----- lfortran --version LFortran version: 0.17.0 Platform: Linux Default target: x86_64-pc-linux-gnu lfortran --version LFortran version: 0.18.0-782-gcbcbdcc37 Platform: Linux Default target: x86_64-pc-linux-gnu ----- I was able to build simple executables (Hello World programs etc). However I see that For the programs in the tests directory the executables are not built after running The following scripts (as suggested in the online documentation): ctest and ./run_tests.py I tried to manually build the executable for one of the tests but it would not build. Get the following error: lfortran -o x derived_types_04.f90 Internal Compiler Error: Unhandled exception Traceback (most recent call last): LCompilersException: visit_GenericAssignment() not implemented I wanted to find out the exact status on the availability of Lfortran. Can we expect lfortran to build real world applications other than trivial hello world Programs? Thanks and Regards, -Sesha Kalyur

Hi! I'm interested on this project for applying in Google Summer of Code this year. I'm a venezuelan university student and developer, I would like some help to get into the community as well as getting guidance to contribute and submit my application. Any help would be appreciated!

Hi all, I'm trying to build LFortran from source, Using conda is not an option, since this is supposed to be part of package building for Slackware 15.0 and Slackware-Current, so I have to use system's "native" tools. I am using llvm 13.0.0 for that, with gcc 11.2.0 and cmake 3.21.14. Compilation seems ok (with a few warnings which look harmless,) but linking fails. This is what I get: cmake -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=`pwd`/inst . ... make -j ... /usr/bin/ld: ../../libasr/libasr.a(evaluator.cpp.o): undefined reference to symbol '_ZN4llvm20SectionMemoryManagerC1EPNS0_12MemoryMapperE' /usr/bin/ld: /usr/lib64/../lib64/libLLVMExecutionEngine.so.13: error adding symbols: DSO missing from command line /usr/bin/ld: ../libasr/libasr.a(evaluator.cpp.o): undefined reference to symbol '_ZN4llvm20SectionMemoryManagerC1EPNS0_12MemoryMapperE' /usr/bin/ld: /usr/lib64/../lib64/libLLVMExecutionEngine.so.13: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [src/lfortran/tests/CMakeFiles/test_lfortran.dir/build.make:225: src/lfortran/tests/test_lfortran] Error 1 make[1]: *** [CMakeFiles/Makefile2:379: src/lfortran/tests/CMakeFiles/test_lfortran.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... collect2: error: ld returned 1 exit status make[2]: *** [src/bin/CMakeFiles/lfortran.dir/build.make:112: src/bin/lfortran] Error 1 make[1]: *** [CMakeFiles/Makefile2:463: src/bin/CMakeFiles/lfortran.dir/all] Error 2 make: *** [Makefile:166: all] Error 2 The missing DSO errors suggest missing of -lpthread in LDFLAGS, but I'm not sure what's going on here. Any ideas?

Hi all, I wanted to see how far lfortran is from being able to compile scipy, by analyzing the failures. I used FreeBSD 13.1-Test, not FreeBSD-Clean used to compile LFortran from scratch. As a result, the build used Python 3.8 not 3.9 and there may be other packages not accounted for. To summarize the initial findings, 236 failed builds 106 are due to attributes not yet supported SAVE: 30 integer: 30 COMMON/common: 18 49 are due to a mismatch of calling types internal to lfortran 47 are type mismatches in scipy code 36 appear to be tokenizer errors with scipy code related to #ifdef 9 are LHS assignment issues 8 are due to Return type not supported 7 are due to internal compiler errors 2 are ICE issues also related to #ifdef There appear to be some duplications, as the total instances of the above is 243. There will be further errors, as the build process was unable to proceed to completion (about 96% completed). tim Discussion: I ran ninja -k 0 > k_build.txt [1549/1615] ... ninja: build stopped: cannot make progress due to previous errors. ~/tools/scipy/build % grep -nr FAILED k_build.txt | wc -l 236 The biggest thing that stands out is ~/tools/scipy/build % grep -nr 'Call parameter type does not match function signature!' k_build.txt | wc -l 279 One very large cause of this is Call parameter type does not match function signature! %104 = getelementptr inbounds float, float* %103, i32 %98 %array* call void @dcosqf1(i32* %n, %array* %x, %array* %wsave, float* %104) When this fails, ninja emits a significant amount of pseudo-assembly code: [292/1615] Compiling Fortran object scipy/linalg/_interpolative.cpython-38.so.p/src_id_dist_src_dfft.f.o FAILED: scipy/linalg/_interpolative.cpython-38.so.p/src_id_dist_src_dfft.f.o lfortran -Iscipy/linalg/_interpolative.cpython-38.so.p -Iscipy/linalg -I../scipy/linalg -I/usr/home/tkelly/tools/numpy/numpy/core/include -I/usr/home/tkelly/tools/numpy/numpy/f2py/src -Iscipy/lib_fortranobject.a.p -I/usr/local/include/openblas -I/usr/local/include/python3.8 --fixed-form --implicit-typing --allow-implicit-interface --generate-object-code -g -o scipy/linalg/_interpolative.cpython-38.so.p/src_id_dist_src_dfft.f.o -c ../scipy/linalg/src/id_dist/src/dfft.f ; ModuleID = 'LFortran' source_filename = "LFortran" %array = type { float*, i32, %dimension_descriptor*, i1, i32 } %dimension_descriptor = type { i32, i32, i32 } %array.0 = type { i32*, i32, %dimension_descriptor*, i1, i32 } %array.1 = type { i1*, i32, %dimension_descriptor*, i1, i32 } %c_ptr = type { i32 } ... It creates a large space in the analysis file: ~/tools/scipy/build % grep -nr 'getelementptr' k_build.txt | wc -l 10241 but this is not from inside the scipy build environment ~/tools/scipy/build % grep -nr 'getelementptr' ../scipy | wc -l 0 Examining the actual build command lfortran -Iscipy/linalg/_interpolative.cpython-38.so.p -Iscipy/linalg -I../scipy/linalg -I/usr/home/tkelly/tools/numpy/numpy/core/include -I/usr/home/tkelly/tools/numpy/numpy/f2py/src -Iscipy/lib_fortranobject.a.p -I/usr/local/include/openblas -I/usr/local/include/python3.8 --fixed-form --implicit-typing --allow-implicit-interface --generate-object-code -g -o scipy/linalg/_interpolative.cpython-38.so.p/src_id_dist_src_dfft.f.o -c ../scipy/linalg/src/id_dist/src/dfft.f getelementptr does not exist in dfft.f. I conclude this is an issue internal to lfortran and possibly easily fixed. There are duplications, so I am not able to get a handle on how many FAILED builds this would resolve. However, this does appear to cause at least 49 failures: ~/tools/scipy/build % grep -nr asr_to_llvm k_build.txt | wc -l 49 (i.e., k_build.txt:2118:code generation error: asr_to_llvm: module failed verification. Error:) k_build.txt:114291:code generation error: asr_to_llvm: module failed verification. Error: k_build.txt-114292-Call parameter type does not match function signature! k_build.txt-114293- %271 = getelementptr inbounds double, double* %a, i32 %269 k_build.txt-114294- %array* call void @h12(i32* %call_arg_value37, i32* %j, i32* %call_arg_value38, i32* %m, double* %271, i32* %cal

Hello All, I believe the following are the minimal necessary steps to compile lfortran on FreeBSD 13.1: installer downloaded from https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-amd64-dvd1.iso.xz default install FreeBSD -- ntp enabled -- UFS (default is ZFS) -- no ports -- no IPv6 (as root:) pkg install llvm15 (BSD-licensed tool) (will install python3.9, PFSL-licensed tool) (required:) # ln -s /usr/local/bin/python3.9 /usr/local/bin/python (optional:) # ln -s /usr/local/bin/python3.9 /usr/local/bin/python3 pkg install re2c (Public Domain) pkg install cmake (BSD-licensed tool) pkg install git (GPL-licensed tool) pkg install bash (GPL-licensed tool) pkg install bison (GPL-licensed tool) (There are additional dependencies that may be installed by the above that will install additional GPL-licensed tools. The above installations added a total of 57 packages.) The .yy files in lfortran have directives that are not supported in yacc. Other shells might work, but as far as I can tell, python's virtual environments often (always?) expect bash. ~/tools/ % git clone https://github.com/lfortran/lfortran/ ~/tools/ % cd lfortran ~/tools/lfortran % ./build0.sh ~/tools/lfortran % cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=/usr/local . ~/tools/lfortran % make (not make -j8, unless you have a lot of memory, 4G+2G swap fails with -j4, -j2 succeeds) ~/tools/lfortran % src/bin/lfortran --version LFortran version: 0.18.0-311-gcd2332228 Platform: FreeBSD Default target: x86_64-portbld-freebsd13.1 ~/tools/lfortran % uname -a FreeBSD fbsd_clean 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 make will build src/runtime .o files but make clean will not remove them. These files appear to be compiled via src/bin/CMakeLists.txt. ~/tools/lfortran % ls src/runtime/*.o src/runtime/lfortran_intrinsic_bit.o src/runtime/lfortran_intrinsic_math2.o src/runtime/lfortran_intrinsic_builtin.o src/runtime/lfortran_intrinsic_math3.o src/runtime/lfortran_intrinsic_ieee_arithmetic.o src/runtime/lfortran_intrinsic_optimization.o src/runtime/lfortran_intrinsic_iso_c_binding.o src/runtime/lfortran_intrinsic_sin.o src/runtime/lfortran_intrinsic_iso_fortran_env.o src/runtime/lfortran_intrinsic_string.o src/runtime/lfortran_intrinsic_kind.o src/runtime/lfortran_intrinsic_trig.o src/runtime/lfortran_intrinsic_math.o ~/tools/lfortran % make clean ~/tools/lfortran % ls src/runtime/*.o src/runtime/lfortran_intrinsic_bit.o src/runtime/lfortran_intrinsic_math2.o src/runtime/lfortran_intrinsic_builtin.o src/runtime/lfortran_intrinsic_math3.o src/runtime/lfortran_intrinsic_ieee_arithmetic.o src/runtime/lfortran_intrinsic_optimization.o src/runtime/lfortran_intrinsic_iso_c_binding.o src/runtime/lfortran_intrinsic_sin.o src/runtime/lfortran_intrinsic_iso_fortran_env.o src/runtime/lfortran_intrinsic_string.o src/runtime/lfortran_intrinsic_kind.o src/runtime/lfortran_intrinsic_trig.o src/runtime/lfortran_intrinsic_math.o There are some warnings that might warrant review: /home/tkelly/tools/lfortran/src/lfortran/semantics/ast_common_visitor.h:3453:21: warning: variable 'result' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: { ^~~~~~~ /home/tkelly/tools/lfortran/src/lfortran/semantics/ast_common_visitor.h:3459:42: note: uninitialized use occurs here al, x.base.base.loc, result, dest_type)); ^~~~~~ /home/tkelly/tools/lfortran/src/lfortran/semantics/ast_common_visitor.h:3435:31: note: initialize the variable 'result' to silence this warning int64_t result; ^ = 0 In the above example, the full code says // Reconsider default: { LFORTRAN_ASSERT(false); op = ASR::binopType::Pow; } so while there is likely an assertion that will fail, someone noted that perhaps this is not always true. I am not posting a patch because I do not know what the preferred default value of result should be; it might not be 0. To run the tests (as root) pkg install py39-pip ~/tools/lfortran % pip install --upgrade toml ~/tools/lfortran % python run_tests.py START TEST: subroutine1

Hello, In trying to compile scipy, I find ~/tools/scipy/build % lfortran -Iscipy/special/libmach.a.p -Iscipy/special -I../scipy/special --fixed-form --implicit-typing --allow-implicit-interface --generate-object-code -g -o scipy/special/libmach.a.p/mach_d1mach.f.o -c ../scipy/special/mach/d1mach.f semantic error: Attribute declaration not supported --> ../scipy/special/mach/d1mach.f:17:7 | 17 | COMMON /D9MACH/ CRAY1 | ^^^^^^^^^^^^^^^^^^^^^ In reviewing the scipy code, ~/tools/scipy/build % grep -nr COMMON ../scipy/ | grep '\.f' | grep -v 'C ' | grep -v 'C\.' | wc -l 44 Two of the 44 are inside FORMAT statements, but that still leaves 42 instances: % grep -nr COMMON ../scipy/ | grep '\.f' | grep -v 'C ' | grep -v 'C\.' ../scipy/integrate/dop/dop853.f:546: COMMON /CONDO8/XOLD,HOUT ../scipy/integrate/dop/dop853.f:862: COMMON /CONDO8/XOLD,H ../scipy/integrate/dop/dopri5.f:372: COMMON /CONDO5/XOLD,HOUT ../scipy/integrate/dop/dopri5.f:629: COMMON /CONDO5/XOLD,H ../scipy/integrate/mach/d1mach.f:17: COMMON /D9MACH/ CRAY1 ../scipy/integrate/odepack/vode.f:1168: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:1176: COMMON /DVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/vode.f:1882: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:1890: COMMON /DVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/vode.f:2042: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:2050: COMMON /DVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/vode.f:2449: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:2621: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:2832: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:2840: COMMON /DVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/vode.f:3061: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:3069: COMMON /DVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/vode.f:3329: COMMON /DVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ../scipy/integrate/odepack/vode.f:3403: COMMON /DVOD01/ RVOD1(48), IVOD1(33) ../scipy/integrate/odepack/vode.f:3404: COMMON /DVOD02/ RVOD2(1), IVOD2(8) ../scipy/integrate/odepack/zvode.f:1182: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:1190: COMMON /ZVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/zvode.f:1902: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:1910: COMMON /ZVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/zvode.f:2063: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:2071: COMMON /ZVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/zvode.f:2470: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:2642: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:2854: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:2862: COMMON /ZVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/zvode.f:3080: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:3088: COMMON /ZVOD02/ HU, NCFN, NETF, NFE, NJE, NLU, NNI, NQU, NST ../scipy/integrate/odepack/zvode.f:3342: COMMON /ZVOD01/ ACNRM, CCMXJ, CONP, CRATE, DRC, EL(13), ETA, ../scipy/integrate/odepack/zvode.f:3415: COMMON /ZVOD01/ RVOD1(50), IVOD1(33) ../scipy/integrate/odepack/zvode.f:3416: COMMON /ZVOD02/ RVOD2(1), IVOD2(8) ../scipy/odr/odrpack/d_odr.f:8285: + ' HAVE AT LEAST 2 DIGITS IN COMMON.') ../scipy/odr/odrpack/d_odr.f:8289: + ' HAVE FEWER THAN 2 DIGITS IN COMMON. DERIVATIVE',

Hello, I would like to bootstrap LFortran without a Fortran compiler. This seems like a chicken and egg problem. Preferably LFortran could be compiled with the simple presence of clang. I see there are some .f90 files in src/runtime/(im)pure/. Are these intrinsics? Could these be ported to C to solve any dependency on a Fortran compiler? If calling convention is an issue, could libffi be used to mitigate the issue? Or, more simply, is there a switch I can set to avoid looking for a Fortran compiler? I see src/runtime/CMakeLists.txt contains project(lfortran_unif_runtime C Fortran) on line 3. This suggests the answer to the second line of inquiry is no, but I wanted to make sure I am not missing the obvious. Thank you, tim -- "The waging of war will become a regularly occurring municipal function, like trash collection or street cleaning — all the while draining money out of our schools and hospitals, food out of our children’s mouths, and peace and beauty out of the rest of our lives." -- David Potorti

Hello, I am trying to compile scipy on FreeBSD 13.1 from source and with lfortran. I have managed to add lfortran to meson's build system (instructions available upon request, to be published when finalized). I am running into an issue with lfortran compiling scipy code: % lfortran -Iscipy/special/libamos.a.p -Iscipy/special -I../scipy/special -g -o scipy/special/libamos.a.p/amos_zabs.f.o -c ../scipy/special/amos/zabs.f syntax error: Token '*' is unexpected here --> ../scipy/special/amos/zabs.f:2:4 | 2 | C***BEGIN PROLOGUE AZABS | ^ I am not familiar with Fortran, but even a cursory understanding suggests this is a comment line. Why is the line being compiled? Am I missing a flag? As a test run, I removed the commented lines and compiled again: % lfortran -Iscipy/special/libamos.a.p -Iscipy/special -I../scipy/special -g -o scipy/special/libamos.a.p/amos_zabs.f.o -c ../scipy/special/amos/n_zabs.f style suggestion: Use '==' instead of '.eq.' --> ../scipy/special/amos/n_zabs.f:7:12 | 7 | IF (S.EQ.0.0D+0) GO TO 20 | ^^^^ help: write this as '==' style suggestion: Use '>' instead of '.gt.' --> ../scipy/special/amos/n_zabs.f:8:12 | 8 | IF (U.GT.V) GO TO 10 | ^^^^ help: write this as '>' Note: if any of the above error or warning messages are not clear or are lacking context please report it to us (we consider that a bug that needs to be fixed). runtime_error: raw_fd_ostream failed These seem to be two different issues. Is the style issue due to a difference between f77 and f90 (or some later Fortran)? The "raw_fd_ostream failed" error is coming from the path to scipy/special/libamos.a.p/amos_zabs.f.o not existing. That may be a build environment issue. Otherwise is does actually compile. Does anyone have suggestions about what flags I might need to set by default for scipy? Thank you, tim -- Let me see you smile until your eyes disappear -- Kim Mitchell

Hi, everyone! I have a largish, multiple file, Fortran program and am looking for tools to help me understand it. 2 examples: 1) get the calling patterns among the different routines 2) identify all file input and output Ideally 2) would be in sequence, would skip test or unused functions, and would have the calling context, i.e., kind of 1+2 together. It seemed a parser would be helpful, which led me to lfortran. But I'm confused on a couple of points, and am hoping for some clarification. AST and ASR are described as separate libraries in some documentation, but I see only one big repository with everything on github, and the only instructions are for building the whole thing. Is it possible to just build and use just the AST parser? The entire system has a lot of dependencies, which it would be nice to avoid. I will probably be using the program on MS-Windows. Second there apparently was a parser written in Python as an initial cut, and plans for a Python wrapper for the C++ code. What is the current state of the python code? I ask partly because it might have even lower build requirements than the AST parser, and it's an easier language to work in than C++. Even if, say, the old Python parser is still present, is it a suitable substitute for what I take to be the current main implementation in C++, or was it just a proof of concept? I don't think the code I want to analyze does anything particularly exotic in its use of Fortran; it was mostly written many years ago, and so almost certainly isn't using any of the more recent language features. It's being compiled with Intel's Fortran compiler. Thanks. Ross Boylan

Hi, We have moved our main development repository to GitHub: https://github.com/lfortran/lfortran From now on, please send pull requests against it. Thank you, Ondrej

Hello! I've just recently discovered the LFortran Jupyter Kernel and I'm loving it! Right now I'm working in a refactoring project of some legacy code that's really hard to read (classic single file with thousands of lines and just a couple of subroutines that do more than they should). From that old code I'm making some user-friendly modules to make the usage of our programs as simple as posible. And that's where I see the Jupyter integration as one of the best ways of doing that but, at least for the bit I've tried, right not it's imposible to `use` pre-compiled modules that aren't included in another cell. Is there a way of making this possible?

Hello I am a coder from Nigeria. I am a python programmer and a Machine Learning/Deep learning enthusiast. I have never contributed to any open source project and I do not know how to go about doing that. If I can receive any assistance on how to do that I will be most grateful. Looking forward to contributing to this great organization. Thank you in anticipation of your response. Sent from Mail ( https://go.microsoft.com/fwlink/?LinkId=550986 ) for Windows

I am trying to build lfortran from source code. I am following the steps mentioned in the "Build From Git" section of https://docs.lfortran.org/installation/ On executing ./run_tests.py, I am getting a differing reference results error. The outputs of each step (according to the "Build From Git" section of https://docs.lfortran.org/installation/) are as follows: ubaid@ubaid-Lenovo-ideapad-330-15ARR:~/Desktop/GSoC/lfortran$ activate lf ubaid@ubaid-Lenovo-ideapad-330-15ARR:~/Desktop/GSoC/lfortran$ ./build0.sh + ci/version.sh ++ git describe --tags --dirty + version=v0.14.0-1345-g74d6438a + version=0.14.0-1345-g74d6438a + echo 0.14.0-1345-g74d6438a + python grammar/asdl_cpp.py Assuming default values of AST.asdl and ast.h + python grammar/asdl_cpp.py grammar/ASR.asdl src/libasr/asr.h + cd src/lfortran/parser + re2c -W -b tokenizer.re -o tokenizer.cpp + cd src/lfortran/parser + re2c -W -b preprocessor.re -o preprocessor.cpp + cd src/lfortran/parser + bison -Wall -d -r all parser.yy + grep -n \' src/lfortran/parser/parser.yy + echo OK OK ubaid@ubaid-Lenovo-ideapad-330-15ARR:~/Desktop/GSoC/lfortran$ cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=`pwd`/inst . -- Found LLVM 10.0.0 -- Using LLVMConfig.cmake in: /usr/lib/llvm-10/cmake Configuration results --------------------- LFORTRAN_VERSION: 0.14.0-1345-g74d6438a CPACK_PACKAGE_FILE_NAME: lfortran-0.14.0-1345-g74d6438a-Linux C compiler : /usr/bin/cc C++ compiler : /usr/bin/c++ Build type: Debug C compiler flags : -g C++ compiler flags : -Wall -Wextra -g -ggdb Installation prefix: /home/ubaid/Desktop/GSoC/lfortran/inst WITH_LFORTRAN_ASSERT: yes LFORTRAN_STATIC_BIN: no WITH_STACKTRACE: no WITH_UNWIND: no WITH_BFD: no WITH_DWARFDUMP: no WITH_LINKH: no WITH_MACHO: no HAVE_LFORTRAN_DEMANGLE: yes WITH_LLVM: yes WITH_XEUS: no WITH_JSON: no WITH_FMT: no WITH_LFORTRAN_BINARY_MODFILES: YES WITH_RUNTIME_LIBRARY: YES WITH_TARGET_AARCH64: no WITH_TARGET_X86: yes -- Configuring done -- Generating done -- Build files have been written to: /home/ubaid/Desktop/GSoC/lfortran ubaid@ubaid-Lenovo-ideapad-330-15ARR:~/Desktop/GSoC/lfortran$ make -j8 [ 4%] Built target lfortran_runtime_static [ 4%] Built target doctest [ 6%] Built target lfortran_runtime Scanning dependencies of target asr [ 8%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/do_loops.cpp.o [ 8%] Building CXX object src/libasr/CMakeFiles/asr.dir/codegen/asr_to_x86.cpp.o [ 9%] Building CXX object src/libasr/CMakeFiles/asr.dir/codegen/asr_to_cpp.cpp.o [ 11%] Building CXX object src/libasr/CMakeFiles/asr.dir/codegen/asr_to_py.cpp.o [ 11%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/param_to_const.cpp.o [ 13%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/global_stmts.cpp.o [ 14%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/for_all.cpp.o [ 15%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/select_case.cpp.o [ 16%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/implied_do_loops.cpp.o [ 17%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/array_op.cpp.o [ 18%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/class_constructor.cpp.o [ 19%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/arr_slice.cpp.o [ 20%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/print_arr.cpp.o [ 21%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/pass_utils.cpp.o [ 22%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/unused_functions.cpp.o [ 23%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/flip_sign.cpp.o [ 25%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/div_to_mul.cpp.o [ 26%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/fma.cpp.o [ 27%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/sign_from_value.cpp.o [ 28%] Building CXX object src/libasr/CMakeFiles/asr.dir/pass/inline_function_calls.cpp.o [ 29%] Building CXX object src/libasr/CMakeFiles/asr.dir/asr_verify.cpp.o [ 30%] Building CXX object src/libasr/CMakeFiles/asr.dir/asr_utils.cpp.o [ 31%] Building CXX object src/libasr/CMakeFiles/asr.dir/asr_scopes

Hi, I am a Python and a Machine learning enthusiast. I have been learning python for one year two months now. I am very interested in contributing to open source project but i have no experience in open sourcing. I will be greatful if i am guided through making just one successful pull request. From here, i will be able to continue the process. Thanks!

Folks, I was wondering how much you have thought about adding support for the OpenMP API to lfortran? I'm asking because I'm the maintainer of a smallish OpenMP runtime system that can be used for educational purposes [1]. It's a drop-in for LLVM's OpenMP runtime (for the part that LOMP supports) and having lfortran use these LLVM OpenMP interfaces would be a good thing to have. Kind regards, -michael [1] https://github.com/parallel-runtimes/lomp

Hello. I am a web developer with an interest in compilers and programming languages. Struck upon lfortran and found it intriguing with its applications in scientific computing. Familiar with C and C++ and would like to learn and contribute more. Found a few issues and resources which looks nice to start with: https://gitlab.com/lfortran/lfortran/-/issues/603 https://gitlab.com/lfortran/lfortran/-/issues/642 https://j3-fortran.org/doc/year/18/18-007r1.pdf https://docs.lfortran.org/developer_tutorial Do suggest if there are any resources or issues with which I can get up to speed with the codebase, architecture etc Thank you