Hello Erick, Thanks for a quick reply.
> use the subversion one. Ok. Will do. > > path/to/build/mk doc Ah..cool. >> PS - I have this habit of calling my files >> 1hello.x 2hello.x....when I try examples with > > Oh thats interesting! I have no idea what will happen if you do that :) > I'll have to check that out. I also don't know what felix thinks of I am sorry..I actually saved that as 1hello.flx, 2hello.flx...etc. (not *.x but *.flx). But the error part is still the same - I think Here is the terminal output : [EMAIL PROTECTED]> cp hello.flx 1hello.flx [EMAIL PROTECTED]> flx 1hello.flx In file included from 1hello.cpp:5: 1hello.hpp:30:30: error: invalid suffix "hello" on integer constant 1hello.hpp:86:25: error: invalid suffix "hello" on integer constant 1hello.cpp:14:30: error: invalid suffix "hello" on integer constant In file included from 1hello.cpp:25: 1hello.rtti:16:35: error: invalid suffix "hello_head_shape" on integer constant 1hello.rtti:17:13: error: invalid suffix "hello_head_shape" on integer constant 1hello.cpp:41:34: error: invalid suffix "hello" on integer constant 1hello.cpp:41:34: error: invalid suffix "hello" on integer constant 1hello.cpp:41:34: error: invalid suffix "hello" on integer constant 1hello.cpp:41:34: error: invalid suffix "hello" on integer constant 1hello.cpp:42:42: error: invalid suffix "hello" on integer constant 1hello.cpp:42:42: error: invalid suffix "hello" on integer constant 1hello.hpp:30: error: expected identifier before numeric constant compilation terminated due to -Wfatal-errors. [EMAIL PROTECTED]> [EMAIL PROTECTED]> cat 1hello.flx #include <std.flx> print "Hello World!\n"; [EMAIL PROTECTED]> > Glad to hear it. Felix changes *a lot*, and so the next release could > change dramatically from the last. So, if you have any complaints, > please let us know! Now that you ask....: I was reading the old archive messages and looks like a lot of work is done to get felix to the c++ folks. On the other hand, felix looks/feels like python in most of the respects. So I wonder why not take that a few more steps and make it as close to python as possible ? (atleast a subset of python). [I understand if the whitespace and colon-newline-delimiters and other stuff are not carried forward - but a lot of other syntactical parts] This would be a big win for any python programmer who wants to get "C" speed. Ocaml has this very nice camlp4 [preprocessor pretty printer]. I was initially planning on using this to translate a subset of python to ocaml. How hard would it be to make felix do that kind of language/syntax modification easy ??? Also, when/if you can, please point me to docs that say about : 1. how to create runnable binaries (so I can do ./hello) 2. What do all those files ? (when I do a flx hello.flx) 3. Any design info/notes as to why there is a val and var and why there is a proc and fun. I also just found a ton of example programs in bagley directory, they are very useful as well. Will check that out. Thanks & Regards, Krishna. Erick Tryzelaar wrote: > Krishna Srinivasan wrote: >> Very cool idea (I have always personally wanted >> to do many of what felix does, compile python >> to c, python to ocaml, adding type inference >> to dynamic languages...etc) and when I saw this >> project on LtU, thought I will give it a try. > > Great! We love new folks. Always tends to find bugs and add new features :) > >> 0. Why are there two sites ? >> One the sf.net site and the other >> the felix-lang.org site ? >> I think the sf site pointed me to 1.1.1. >> But the second one said, 1.1.3 is now ready. >> (the former said 1.1.3 is beta or something, I think). > > So the sourceforge site is pretty old and not well maintained. I wrote > the felix-lang.org site so it's a much nicer front end to draw in > people. However, it's not *yet* the main felix website. In order to get > everything well integrated between the website and mailing lists, we > have to migrate the mailing lists to use google's mailing lists. I'm > still waiting for skaller to give me approval for that :) > > I'd recommend that if you're going to use a version of felix that you > use the subversion one. If you're using a unix-based system, here's how > I'd recommend you do things: > > > mkdir felix && cd felix > > svn co https://felix.svn.sourceforge.net/svnroot/felix/felix/trunk > felix.svn > > mkdir build && cd build > > ../felix.svn/autogen.sh > > This separates the felix.svn directory from the build directory so > everything is nice and clean. You can then run felix like this: > > > path/to/build/bin/flx --test=path/to/build ... > > I typically create a file in the build directory called flx that wraps > this like this: > > path/to/build/flx: > #!/bin/sh > `dirname $0`/bin/flx --test=`dirname $0` $* > > Whic you can then just build felix programs like this: > > > flx foo.flx > > (i really need to add this to the wiki...) > >> 1. Installation >> >> 1.1.1 - make was ok, but 'make install' FAILED. >> So I was not able to run ./bin/flx as well. > > 1.1.1 is really old, which makes sense why you'd have trouble installing > it :) > >> 1.1.3_rc4 - installed perfectly fine (on ppc mac osx 10.4.10). >> [I already had ocaml, python latest versions] >> >> ./configure took about 2 minutes and >> make took about 45 minutes. >> >> 1a. Why is there a separate 'make doc' and why >> is it not part of 'make' ? [anyways, I promptly >> forgot to do that and now don't want to mess up >> anything before I get more comfortable - so >> am living without docs]. > > Our makefile is really just a wrapper for the real felix build system, > which is called "mk". So as a consequence it doesn't have everything > exposed due to it not getting as much attention. To build it, just run > this: > > > path/to/build/mk doc > > However, it can take a bit of time, so it's not done by default. We also > have the docs online, found here: > > http://felix.sourceforge.net/doc/en_flx_doc_0001.html > > Which are updated to 1.1.3. > >> 2. Hello World >> Hello World example worked just fine. >> Although I got confused by >> include <flx.flxh> in one place and >> include <std.flx> in another doc. >> [Again mainly due to two different web sites >> and document/example pointers] > > Yeah, I'm sorry about that. It's a little confusing the whole > import/include and flx.flxh/std.flx. However, we're working to fix up > those problems to make things a little more understandable. Generally, > you want to ignore all those other options and just stick with: > > #import <flx.flxh> > > It gets you the standard interface with macros and everything. "include" > disables macros, and that can have odd consequences. > >> PS - I have this habit of calling my files >> 1hello.x 2hello.x....when I try examples with >> incremental compelxity (so I can type the number >> and hit tab). But this failed with a weird cpp >> error ....guess, I cannot name files that does >> not begin with a 'letter'. :) > > Oh thats interesting! I have no idea what will happen if you do that :) > I'll have to check that out. I also don't know what felix thinks of > files named ".x". We use ".flx" in all our tests, but I'm not sure if > thats mandatory. In the meantime, I'd suggest using hello1.flx, > hello2.flx and etc. > >> >> 3. Right now, I am looking at the docs : >> http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html >> >> >> >> And I cannot find how to open, read, write files. >> Can someone please point me to that ? > > Sure. Thats in Text_file::fopen_input / Text_file::fopen_output. Check > out lib/std.flx, you can find a bunch of semi-documented routines that > are hopefully descriptive enough to get you around. > > (skaller, any reason why we don't just support the fopen protocol? Like > how do we expose file appending and etc? Or, we could always go with > wrapping stl's io routines?) > > >> 4. The unit tests examples are awesome - they give >> me more clear view of how to do various things >> with the lang. :) >> >> Anyways, I have a long way to go with the felix, >> but I am liking what I am seeing. > > Glad to hear it. Felix changes *a lot*, and so the next release could > change dramatically from the last. So, if you have any complaints, > please let us know!> Glad to hear it. Felix changes *a lot*, and so the next > release could > change dramatically from the last. So, if you have any complaints, > please let us know!> Glad to hear it. Felix changes *a lot*, and so the next > release could > change dramatically from the last. So, if you have any complaints, > please let us know! > > -e > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
