pure-lang-users Mailing List for Pure (Page 53)
Status: Beta
Brought to you by:
agraef
Menu
▾
▴
pure-lang-users — Discussion of the Pure programming language.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Libor S. <li...@gm...> - 2008-05-01 10:26:39
|
I won't have time to test it on my machine until late this afternoon, as I am at work at the moment. Will do as soon as I get home. Libor > Well, the results have become more consistent, but not in a good way! :( > > Taking the simple fact example same as last night: > > | zsh, sauce 11:04AM trunk/ % cat test1.pure > > | fact 0 = 1; > | fact n = n * fact (n-1); > | fact 4; > | > > | zsh, sauce 11:04AM trunk/ % ./pure < test1.pure > | zsh: segmentation fault (core dumped) ./pure < test1.pure > > > _______________________________________________ > pure-lang-users mailing list > pur...@li... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users > |
|
From: Tim H. <q...@st...> - 2008-05-01 10:15:32
|
Albert Graef <Dr....@t-...> writes: [snip] >>>> You're right about that. Don't understand why. :/ > > Ok, that should be fixed now. Could you please give it a go? I tested it > as good as I can simulate it on a 32 bit system, but of course there may > still be some other alignment issues waiting to be discovered. ;-) > > Please note that the latest regression, #7, will still fail if you run > 'make check', that's the next one on my TODO list. :) Well, the results have become more consistent, but not in a good way! :( Taking the simple fact example same as last night: | zsh, sauce 11:04AM trunk/ % cat test1.pure | fact 0 = 1; | fact n = n * fact (n-1); | fact 4; | | zsh, sauce 11:04AM trunk/ % ./pure < test1.pure | zsh: segmentation fault (core dumped) ./pure < test1.pure That's worse - segfault was previously on test2.pure (my flip-around) only. gdb: | #0 0x000000000055d597 in add_char (x=0x0, c=0) at runtime.cc:901 | #1 0x00002ab533bb0f22 in ?? () | #2 0x0000000000000000 in ?? () Moving on to `check': | zsh, sauce 11:09AM trunk/ % make check | PURELIB=./lib ./pure -n -v7 lib/prelude.pure > test/prelude.log | PURELIB=./lib ./pure -v7 test/test1.pure > test/test1.log | /bin/sh: line 1: 28936 Segmentation fault (core dumped) PURELIB=./lib | ./pure -v7 test/test1.pure >test/test1.log | make: *** [test/test1.log] Error 139 | zsh: exit 2 make check gdb => same place: | #0 0x000000000055d597 in add_char (x=0x2b097500aad8, c=19142847192) | at runtime.cc:901 At this point I rm -rf * and svn upd; problem persists after very clean rebuild too. Am now on revision 17. A second `check': | zsh, sauce 11:05AM trunk/ % make check | PURELIB=./lib ./pure -v7 test/test2.pure > test/test2.log | PURELIB=./lib ./pure -v7 test/test3.pure > test/test3.log | PURELIB=./lib ./pure -v7 test/test4.pure > test/test4.log | /bin/sh: line 1: 28450 Illegal instruction (core dumped) PURELIB=./lib | ./pure -v7 test/test4.pure >test/test4.log | make: *** [test/test4.log] Error 132 | zsh: exit 2 make check Oh I see. Your check target is incremental and treats the log-file as proof it's been done. :) ~Tim -- <http://spodzone.org.uk/> |
|
From: Ryan S. <rya...@us...> - 2008-05-01 10:15:32
|
On May 1, 2008, at 4:09 AM, Albert Graef wrote: >> g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc >> runtime.cc: In function 'void pure_sys_vars()': >> runtime.cc:1401: error: 'GLOB_PERIOD' was not declared in this scope >> runtime.cc:1405: error: 'GLOB_ONLYDIR' was not declared in this scope >> make: *** [runtime.o] Error 1 > > The glob on OSX doesn't have these, apparently. Should be fixed in > revision 13. >> Except that your Makefile >> calls g++ by name, but that's not what MacPorts calls it. For example >> MacPorts installs g++ from gcc 4.3 as "g++-mp-4.3". It also sets the >> CC, CXX and CPP environment variables to match, so maybe the Makefile >> should use the CXX variable if set. > > You're right. Fixed in revision 15. Ok, with revision 17 now I get this: g++ -g -Wall `llvm-config --cppflags` -c -o util.o util.cc util.cc: In function 'char* toutf8(const char*, const char*)': util.cc:458: error: invalid conversion from 'char**' to 'const char**' util.cc:458: error: initializing argument 2 of 'size_t libiconv (void*, const char**, size_t*, char**, size_t*)' util.cc: In function 'char* fromutf8(const char*, char*)': util.cc:511: error: invalid conversion from 'char**' to 'const char**' util.cc:511: error: initializing argument 2 of 'size_t libiconv (void*, const char**, size_t*, char**, size_t*)' util.cc: In function 'wchar_t* ictowcs(wchar_t*, char*)': util.cc:583: error: invalid conversion from 'char**' to 'const char**' util.cc:583: error: initializing argument 2 of 'size_t libiconv (void*, const char**, size_t*, char**, size_t*)' make: *** [util.o] Error 1 |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 09:55:06
|
Tim Haynes wrote: > Albert Graef <Dr....@t-...> writes: > >> Tim Haynes wrote: >>>>> fact 0 = 1; >>>>> fact n = n * fact (n-1); >>>>> fact 4; >>>> 1 >>> You're right about that. Don't understand why. :/ Ok, that should be fixed now. Could you please give it a go? I tested it as good as I can simulate it on a 32 bit system, but of course there may still be some other alignment issues waiting to be discovered. ;-) Please note that the latest regression, #7, will still fail if you run 'make check', that's the next one on my TODO list. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 08:54:42
|
Ryan Schmidt wrote: > I tried compiling trunk at revision 10. With Mac OS X 10.4's flex > 2.5.4 and bison 1.28, if I do "make all" I get: Yes, those versions are ancient. But with the release tarball that's not a problem because parser.cc and lexer.cc are included there and so bison and flex aren't normally needed on the build system. > And if I do "make depend all" I get: You shouldn't have to do that any more, I've fixed the dependencies in the distributed Makefile. > Should I be running "make depend all" or "make all"? Just "make" or "make all". That will create a debug-enabled build which is comparatively slow, so for the release build I recommend "make build=release". > g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc > runtime.cc: In function 'void pure_sys_vars()': > runtime.cc:1401: error: 'GLOB_PERIOD' was not declared in this scope > runtime.cc:1405: error: 'GLOB_ONLYDIR' was not declared in this scope > make: *** [runtime.o] Error 1 The glob on OSX doesn't have these, apparently. Should be fixed in revision 13. > We have newer versions of gcc in MacPorts that I can make the pure > portfile use if that becomes necessary. No, that shouldn't be necessary. Once I fixed all the OSX incompatibilities, it should compile at least with gcc 4.0.1. Not sure about gcc 3.x, though. > Except that your Makefile > calls g++ by name, but that's not what MacPorts calls it. For example > MacPorts installs g++ from gcc 4.3 as "g++-mp-4.3". It also sets the > CC, CXX and CPP environment variables to match, so maybe the Makefile > should use the CXX variable if set. You're right. Fixed in revision 15. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 08:27:02
|
Yes, Tim and Eddie already reported this, I'm working on it. Libor Spacek wrote: > I think there is something wrong with my (64bit) integers. I get this: -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 08:19:42
|
Libor Spacek wrote: > g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o util.o util.cc > util.cc: In function 'wchar_t* ictowcs(wchar_t*, char*)': > util.cc:583: warning: dereferencing type-punned pointer will break > strict-aliasing rules Yes, that one. It's only generated with -O3, and it should be harmless. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-05-01 08:11:42
|
I think there is something wrong with my (64bit) integers. I get this: > fact 1 = 1; > fact n::int = n*fact (n-1) if n>1; > fact 4; fact 4 > fact 1.0 = 1.0; > fact n::double = n*fact (n-1) if n>1; > fact 4.0; 24.0 Also test6.pure fails. |
|
From: Ryan S. <rya...@us...> - 2008-05-01 08:02:25
|
On Apr 30, 2008, at 1:35 PM, Albert Graef wrote: > Albert Graef wrote: >> Ryan Schmidt wrote: >>> I tried building on Mac OS X 10.4.11 PPC and got this: >>> >>> Command output: make: *** No rule to make target `/usr/local/ >>> include/ >>> llvm/DerivedTypes.h', needed by `expr.o'. Stop. >> >> Hmm yes, the distributed Makefile shouldn't have all those LLVM >> dependencies, I'll fix that. > > Fixed. > >>> interpreter.cc:1325: error: no match for 'operator!=' in 'it != >>> std::list<_Tp, _Alloc>::rend() [with _Tp = rule, _Alloc = >>> std::allocator<rule>]()' >> >> I'll look at that tomorrow. I don't get that error here, maybe >> it's an >> incompatibility in the STL. > > That's a bug in older GNU STL versions: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11729 > > I changed the reverse_const_iterator there to an ordinary > reverse_iterator, that should fix it. Ryan, can you please check that > the trunk from SVN compiles now? I tried compiling trunk at revision 10. With Mac OS X 10.4's flex 2.5.4 and bison 1.28, if I do "make all" I get: bison -v -o parser.cc parser.yy parser.yy:7: unrecognized: %skeleton parser.yy:7: Skipping to next % parser.yy:8: unrecognized: %require parser.yy:8: Skipping to next % parser.yy:9: unrecognized: %defines parser.yy:9: Skipping to next % parser.yy:34: unrecognized: %parse_param parser.yy:34: Skipping to next % parser.yy:35: unrecognized: %lex_param parser.yy:35: Skipping to next % parser.yy:38: unrecognized: %locations parser.yy:38: Skipping to next % parser.yy:39: unrecognized: %initial_action parser.yy:39: Skipping to next % parser.yy:50: unrecognized: %debug parser.yy:50: Skipping to next % parser.yy:51: unrecognized: %error_verbose parser.yy:51: Skipping to next % parser.yy:234: unrecognized: %destructor parser.yy:234: Skipping to next % parser.yy:238: unrecognized: %destructor parser.yy:238: Skipping to next % parser.yy:239: unrecognized: %printer parser.yy:239: Skipping to next % parser.yy:242: unrecognized: %printer parser.yy:242: Skipping to next % parser.yy:243: unrecognized: %printer parser.yy:243: Skipping to next % parser.yy:244: unrecognized: %printer parser.yy:244: Skipping to next % parser.yy:251: invalid input: %start parser.yy:251: ill-formed rule: initial symbol not followed by colon make: *** [parser.cc] Error 1 And if I do "make depend all" I get: flex -o lexer.cc lexer.ll flex: can't open lexer.cc make: *** [lexer.cc] Error 1 Should I be running "make depend all" or "make all"? If I install flex 2.5.35 with MacPorts then flex can run in "make depend all" but bison fails again as above. I see you wrote in another thread on this list that bison 2.1a is now needed. Ok. Once I install bison 2.3 with MacPorts then that works too, but now it ends at: flex -o lexer.cc lexer.ll bison -v -o parser.cc parser.yy makedepend -Y expr.cc expr.hh funcall.h interpreter.cc interpreter.hh lexer.ll matcher.cc matcher.hh parser.yy printer.cc printer.hh pure.cc runtime.cc runtime.h symtable.cc symtable.hh util.cc util.hh lexer.cc parser.cc parser.hh location.hh position.hh stack.hh 2> /dev/ null g++ -g -Wall `llvm-config --cppflags` -c -o expr.o expr.cc g++ -g -Wall `llvm-config --cppflags` -c -o interpreter.o interpreter.cc interpreter.cc: In member function 'llvm::Value* interpreter::fbox (Env&, bool)': interpreter.cc:3269: warning: control reaches end of non-void function interpreter.cc: In member function 'llvm::Value* interpreter::fref (int32_t, uint8_t, bool)': interpreter.cc:3494: warning: control reaches end of non-void function g++ -g -Wall `llvm-config --cppflags` -c -o matcher.o matcher.cc g++ -g -Wall `llvm-config --cppflags` -c -o printer.o printer.cc g++ -g -Wall `llvm-config --cppflags` -DVERSION='"0.1"' -DPURELIB='"/ macports/lib/pure"' -c -o pure.o pure.cc g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc runtime.cc: In function 'void pure_sys_vars()': runtime.cc:1401: error: 'GLOB_PERIOD' was not declared in this scope runtime.cc:1405: error: 'GLOB_ONLYDIR' was not declared in this scope make: *** [runtime.o] Error 1 >>> interpreter.cc:2243: warning: passing negative value 'INT' for >>> argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get >>> (const >>> llvm::Type*, uint64_t, bool)' >> >> Those are annoying but harmless. I don't get them. > > I added the appropriate cast to uint64_t, so that should be fixed > now, too. > >>> interpreter.cc: In member function 'llvm::Value* interpreter::fbox >>> (Env&, bool)': >>> interpreter.cc:3269: warning: control reaches end of non-void >>> function >>> interpreter.cc: In member function 'llvm::Value* interpreter::fref >>> (int32_t, uint8_t, bool)': >>> interpreter.cc:3494: warning: control reaches end of non-void >>> function >> >> I don't get these either, probably a bogus warning, but I'll have >> a look >> at that, too. > > These warnings are certainly bogus, probably related to: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16558 > You can just ignore these, and they should go away when you upgrade > to a > newer gcc version. I don't think Apple will upgrade the version of gcc in Xcode for Tiger (Mac OS X 10.4) to anything newer than 4.0.1; I don't expect they'll release a new version of Xcode for Tiger beyond version 2.5. Xcode 3.0 for Leopard (Mac OS X 10.5) currently also uses gcc 4.0.1 by default, though 4.2 is either available from Apple or will be available (not sure which since I don't have Leopard on this machine; I just see a preview of gcc 4.2 for Leopard on Apple Developer Connection released in August 2007 and then Xcode 3.0 released in October 2007). Xcode 1.5 for Panther (Mac OS X 10.3) only provides gcc 3.3. We have newer versions of gcc in MacPorts that I can make the pure portfile use if that becomes necessary. Except that your Makefile calls g++ by name, but that's not what MacPorts calls it. For example MacPorts installs g++ from gcc 4.3 as "g++-mp-4.3". It also sets the CC, CXX and CPP environment variables to match, so maybe the Makefile should use the CXX variable if set. |
|
From: Libor S. <li...@gm...> - 2008-05-01 07:42:12
|
Yes, the latest SVN as of a few minutes ago produced this, fairly clean, compilation with one warning: l@ubuntu:~/pure-lang/pure/trunk$ make build=release bison -v -o parser.cc parser.yy g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o expr.o expr.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o interpreter.o interpreter.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o matcher.o matcher.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o printer.o printer.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -DVERSION='"0.1"' -DPURELIB='"/usr/local/lib/pure"' -c -o pure.o pure.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o symtable.o symtable.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o util.o util.cc util.cc: In function 'wchar_t* ictowcs(wchar_t*, char*)': util.cc:583: warning: dereferencing type-punned pointer will break strict-aliasing rules flex -o lexer.cc lexer.ll g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o lexer.o lexer.cc g++ -O3 -DNDEBUG -Wall `llvm-config --cppflags` -c -o parser.o parser.cc g++ -o pure -rdynamic expr.o interpreter.o matcher.o printer.o pure.o runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags --libs core jit native` -lreadline -lgmp l@ubuntu:~/pure-lang/pure/trunk$ Regards, Libor 2008/5/1 Albert Graef <Dr....@t-...>: > Libor Spacek wrote: > > In the end I only had one compilation warning about an unsafe cast of a > pointer. > > Albert, if you are interested, I can reproduce it after I had some > sleep. > > Yes, please do. Are you running the latest Pure from SVN? > > Albert > > |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 07:03:22
|
Libor Spacek wrote: > In the end I only had one compilation warning about an unsafe cast of a pointer. > Albert, if you are interested, I can reproduce it after I had some sleep. Yes, please do. Are you running the latest Pure from SVN? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 07:01:43
|
Tim Haynes wrote: >> fact 0 = 1; >> fact n = n * fact (n-1); >> fact 4; >> >> in a file test.pure, say, and send me the output of 'pure -v15 test.pure'. > > OK - attached. Thanks. The generated code for the first example looks ok, that's good. Looks like at least the first regression is just a silly alignment issue in my LLVM-side definition of the expression struct, I will fix that now and then we can see whether the stack overflow with the second example goes away, too. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 06:37:39
|
Chris Double wrote: > I get a segfault using current SVN (r10) with the following: > >> let y=(\a b -> a+b);y 1 5; > > Am I misunderstanding how let works? No, it's a bug. Apparently the closure gets garbage-collected while it's still bound by the variable. I think I already know where that happens. Thanks folks for all the great bug reports, keep them rolling. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Chris D. <chr...@do...> - 2008-05-01 03:34:20
|
I get a segfault using current SVN (r10) with the following: > let y=(\a b -> a+b);y 1 5; This works: > (\a b -> a+b) 1 5 ; Am I misunderstanding how let works? Chris. -- http://www.bluishcoder.co.nz |
|
From: Eddie R. <er...@bm...> - 2008-05-01 01:32:31
|
Glad you mentioned that. Maybe that's the problem with my install. E.R. On Wed 30/04/08 8:10 PM , "Libor Spacek" li...@gm... sent: > Sorry everyone about my rather unnecessary last message, I thought it was > going just to Eddie. > I did find and install the various missing libraries now, including some > that Eddie did not mention, like"ltdl-dev". I now have Pure up and running on my Ubuntu AMD-64! So the fun > begins later today with some testing. > In the end I only had one compilation warning about an unsafe cast of a > pointer.Albert, if you are interested, I can reproduce it after I had some > sleep.It may have something to do with the 64bit architecture. > > Libor > > > > -------------------------------------------------------------------------This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java. > sun.com/javaone_______________________________________________ > pure-lang-users mailing list > pur...@li...://lists.sourceforge.net/lists/listinfo/pure-lang-users > > |
|
From: Libor S. <li...@gm...> - 2008-05-01 01:11:22
|
Sorry everyone about my rather unnecessary last message, I thought it was going just to Eddie. I did find and install the various missing libraries now, including some that Eddie did not mention, like "ltdl-dev". I now have Pure up and running on my Ubuntu AMD-64! So the fun begins later today with some testing. In the end I only had one compilation warning about an unsafe cast of a pointer. Albert, if you are interested, I can reproduce it after I had some sleep. It may have something to do with the 64bit architecture. Libor |
|
From: Albert G. <Dr....@t-...> - 2008-05-01 00:05:53
|
Eddie Rucker wrote: >> That was last night's bug on amd64 here and I can confirm fixed to point >> ofbeing able to compile it in the svn trunk (revision 10); however... > > I know I copied the files from svn into the pure-1.0 directory before I did a make. Please double-check. I'm sure that I committed that change. Search for a cast like (uint32_t)(uint64_t), if you can't find that in runtime.cc then you have an old revision. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-04-30 23:58:04
|
Tim Haynes wrote: >>> fact 0 = 1; >>> fact n = n * fact (n-1); >>> fact 4; >> 1 > > You're right about that. Don't understand why. :/ Ok, looks like I finally have to install a 64 bit SUSE on my laptop. In the meantime, could you please send me your output of running that script with 'pure -v15'? That is, put those three lines, fact 0 = 1; fact n = n * fact (n-1); fact 4; in a file test.pure, say, and send me the output of 'pure -v15 test.pure'. > Worse, and *maybe* related: trying a quick flip-around of that definition: > > | > fact n=1 if n==0; =n * fact (n-1) otherwise; > | > fact 4; > | zsh: segmentation fault pure That looks like it's a stack overflow. If it's really a 64 bit related bug in the code generator, I should be able to see this in the trace from above. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-04-30 23:39:42
|
On Wed 30/04/08 5:56 PM , Tim Haynes q...@st... sent: > Eddie Rucker erucker@bmc.e > du> writes: > > I almost have it. I have the following make > errors:> > That was last night's bug on amd64 here and I can confirm fixed to point > ofbeing able to compile it in the svn trunk (revision 10); however... I know I copied the files from svn into the pure-1.0 directory before I did a make. > >> fact 0 = 1; > >> fact n = n * fact (n-1); > >> fact 4; > > 1 > > You're right about that. Don't understand why. :/ > > Worse, and *maybe* related: trying a quick flip-around of that > definition: > | > fact n=1 if n==0; =n * fact (n-1) otherwise; > | > fact 4; > | zsh: segmentation fault pure > > gdb says: > > | Program received signal SIGSEGV, Segmentation fault. > | [Switching to Thread 0x2b22de70fe60 (LWP 25677)] > | 0x000000000055d48f in add_char (x=0x2b22df8caa88, c=20930407048) > | at runtime.cc:901 > | 901 interpreter& interp = *interpreter::g_interp; > | (gdb) where > | #0 0x000000000055d48f in add_char (x=0x2b22df8caa88, c=20930407048) > | at runtime.cc:901 > | #1 0x00002b22de791fb0 in ?? () > > Oops :) > > ~Tim I second the Oops! E.R. |
|
From: Libor S. <li...@gm...> - 2008-04-30 23:01:10
|
Me too! Trying to add the deb depository as a new Ubuntu software source (the recommended method) complained about the indexes being out of date and failed. I then downloaded the .deb files manually and got the LLVM working from the .deb files in a couple of clicks. Much easier than compiling it all! Now onto the Pure! Libor 2008/4/30 Eddie Rucker <er...@bm...>: > I almost have it. I have the following make errors: > > g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc > runtime.cc: In function 'pure_expr* pure_intval(pure_expr*)': > runtime.cc:678: error: cast from 'void*' to 'uint32_t' loses precision > runtime.cc: In function 'pure_expr* pointer_to_bigint(void*)': > runtime.cc:728: error: cast from 'void*' to 'uint32_t' loses precision > runtime.cc:733: error: cast from 'void*' to 'uint32_t' loses precision > make: *** [runtime.o] Error 1 > > I change uint32_t to uint64_t in each case and make compiled everything. > However, when you run pure you get funny things: > > > fact 0 = 1; > > fact n = n * fact (n-1); > > fact 4; > 1 > > > > E.R. > |
|
From: Tim H. <q...@st...> - 2008-04-30 22:56:14
|
Eddie Rucker <er...@bm...> writes: > I almost have it. I have the following make errors: > > g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc > runtime.cc: In function âpure_expr* pure_intval(pure_expr*)â: > runtime.cc:678: error: cast from âvoid*â to âuint32_tâ loses precision > runtime.cc: In function âpure_expr* pointer_to_bigint(void*)â: > runtime.cc:728: error: cast from âvoid*â to âuint32_tâ loses precision > runtime.cc:733: error: cast from âvoid*â to âuint32_tâ loses precision > make: *** [runtime.o] Error 1 > > I change uint32_t to uint64_t in each case and make compiled everything. > However, when you run pure you get funny things: That was last night's bug on amd64 here and I can confirm fixed to point of being able to compile it in the svn trunk (revision 10); however... >> fact 0 = 1; >> fact n = n * fact (n-1); >> fact 4; > 1 You're right about that. Don't understand why. :/ Worse, and *maybe* related: trying a quick flip-around of that definition: | > fact n=1 if n==0; =n * fact (n-1) otherwise; | > fact 4; | zsh: segmentation fault pure gdb says: | Program received signal SIGSEGV, Segmentation fault. | [Switching to Thread 0x2b22de70fe60 (LWP 25677)] | 0x000000000055d48f in add_char (x=0x2b22df8caa88, c=20930407048) | at runtime.cc:901 | 901 interpreter& interp = *interpreter::g_interp; | (gdb) where | #0 0x000000000055d48f in add_char (x=0x2b22df8caa88, c=20930407048) | at runtime.cc:901 | #1 0x00002b22de791fb0 in ?? () Oops :) ~Tim -- <http://spodzone.org.uk/> |
|
From: Eddie R. <er...@bm...> - 2008-04-30 22:36:05
|
I almost have it. I have the following make errors: g++ -g -Wall `llvm-config --cppflags` -c -o runtime.o runtime.cc runtime.cc: In function ‘pure_expr* pure_intval(pure_expr*)’: runtime.cc:678: error: cast from ‘void*’ to ‘uint32_t’ loses precision runtime.cc: In function ‘pure_expr* pointer_to_bigint(void*)’: runtime.cc:728: error: cast from ‘void*’ to ‘uint32_t’ loses precision runtime.cc:733: error: cast from ‘void*’ to ‘uint32_t’ loses precision make: *** [runtime.o] Error 1 I change uint32_t to uint64_t in each case and make compiled everything. However, when you run pure you get funny things: > fact 0 = 1; > fact n = n * fact (n-1); > fact 4; 1 > E.R. On Wed, 2008-04-30 at 21:47 +0200, Albert Graef wrote: > Libor Spacek wrote: > > Looking at the early posts here, it seems that the LLVM compilation might > > become a stumbling block to a wider adoption. > > Yes, if you take a look at the q-lang-users archive, you'll see that we > actually discussed the problem of having such a huge dependency quite a > while ago, when the idea to target LLVM first came up. But give it some > time, and LLVM should be readily available as a binary package on most > Linux distros. > > > In my case, the SVN LLVM actually compiled on my AMD64 Ubuntu 8.04 but it > > was the front end that failed and there are no binaries available for it :( > > I'm not sure whether the frontend is actually needed, Pure only links > against the LLVM libraries AFAICT. > > > I will get some more time on Thursday to pick up courage and look at it again. > > Great, maybe you can give it a try with the little guide I just posted. > If that doesn't work then Eddie Rucker should be able to help, he > already has it up and running on Ubuntu IIRC. > > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-04-30 20:57:05
|
Dear Michael, (I hope you don't mind that I'm cc'ing this to the mailing list since the reply should be interesting for others, too.) > An interesting possibility opens itself up if equations in Pure are > first class, which I believe they weren't in Q. No, in Q they aren't, at least not without emulating Q in Q. ;-) > I'm not sure if they are in Pure Well, yes and no. If you restrict your programming to "Pure Pure", i.e., the purely functional part of Pure, then no, because adding a new equation to the running program is a side effect. "Pure Pure" is pretty much the entire language, except the exception handling primitives (throw/catch), the "*p = x" kind of operations (put_int et al) in primitives.pure, and eval in strings.pure. The latter is what's currently available to add new rewriting rules at runtime, it's not really documented yet, but I'll have to say more about that below. > It seems that once could > build a powerful equational reasoning system on Pure, which would enable > one to reason about it's functions as defined by rewrite equations, or > at least the side-effect free ones. Yes, certainly. What's currently missing is a function in the runtime which returns the current list of equations, but that information is readily available (e.g., the "list" command of the interpreter already uses it) and will be made available to user programs as soon as I get around implementing a decent interface for the reflection stuff. There's however a practical issue there, due to the way term pattern matching is implemented in the Pure compiler (which essentially is the "left-to-right term acceptor" technique I invented for my master thesis, see my article in the RTA 91 proceedings, Springer). This technique yields very fast matching code (an essential prerequisite for a TRS programming language), because it's deterministic (non-backtracking). *But* there are pathological cases of term sets where the automata are exponential in size (that's also discussed in my paper). Now if you start adding lots of overlapping equations to the running program, as any form of Knuth-Bendix completion typically does, it might hit that wall and the dynamic compilation as well as the program itself will become very slow and unusable. :( > This would also be incredibly useful to prove things about types in Pure > programs, i.e. it would be a way for the compiler of Pure, a dynamically > typed language, to produce code which is closer to the performance of > that produced by compilers for statically typed languages such as Haskell. I seriously doubt that this will be practical, at least on this scale and for this application (i.e., type inference in Pure). It's not only that the completion may fail (even with "unfailing" KB completion you still have to find a term order or valuation under which the rules are reducing), but all forms of KB are also fairly slow. I still think that a KB completion module for Pure would be very useful, for less ambitious applications in mathematical logic. E.g., if you have a little equational theory (a free group, say), and you want to do some computations in that group, you really want a complete set of equations which decides the word problem in that theory. Group theorists would probably be happy with that (although there surely are software packages for group theory which already do this kind of stuff). > Would you be interested in incorporating such an equational reasoning > engine into Pure? Yes, I that that a KB completion procedure would be a useful addition. It could be just provided as a separate Pure module which programmers can load if they need it. But as explained above, I don't see that it would be feasible to incorporate it into the compiler itself. > On another point, you say that Pure is designed to be more reflective > than Q. Does/Will Pure include the ability to incorporate the Pure > compiler/interpeter runtime in a deployed application, so that new code > can be compiled at runtime? This is one of the hallmarks of Lisp (and > Smalltalk) and a very desirable feature for dynamic languages. Yes, that already works, you can use the eval function to execute arbitrary Pure code at runtime. E.g.: > using system; > foo x y = eval $ sprintf "%s %s = %s+1;" (str x,str y,str y); > foo bar 42; foo bar 23; eval "bar 42 = 42+1;" eval "bar 23 = 23+1;" > list bar bar 42 = 42+1; bar 23 = 23+1; > bar 42; bar 23; 43 24 As you can see, the interface is a bit icky right now because eval takes the source code as a string, but it's workable. I'll add more of those reflection capabilities I promised when I have the time. The interpreter already has an API to process equations represented in a symbolic form, I just need to add a routine to the runtime which gives access to that functionality. > I ask because the GPL then requires the resulting application to be GPLed > since it includes Pure itself. A more permissive license, such as LGPL > or BSD, is in order if Pure is to be used in this way in commercial > applications. You're right, I haven't thought about that yet. But since I'm the author and only copyright holder of the Pure software, I can do that without any ado when the issue comes up. I'll probably switch to LGPL then. Maybe I should do that right away, I will think about it. Best, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-04-30 19:44:51
|
The previous reply didn't go to the listserv. Yes, I *think* this should be a snap. E.R. On Wed, 2008-04-30 at 20:03 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > Check this out! > > > > Critical values of the student t-distribution from GSL: > > Great, congrats. So when can we expect the Pure GSL module? ;-) > > >> using "lib:libgsl"; > >> extern double gsl_cdf_tdist_Pinv(double, double); > >> extern double gsl_cdf_tdist_Qinv(double, double); > >> let left, right = gsl_cdf_tdist_Pinv 0.05 12.0, gsl_cdf_tdist_Qinv > > 0.05 12.0; > >> left, right; > > -1.78228755564932,1.78228755564932 > > > > Beautiful!!! I just dig it!!! > > Nice. It's *much* fun to do system programming with Pure. I really > enjoyed doing the regex and printf/scanf stuff in system.pure. You can > go as low as C, but it's just ... much nicer. ;-) > > Albert > |
|
From: Libor S. <li...@gm...> - 2008-04-30 19:41:17
|
Eddie and Albert, Thanks to you both. Ubuntus are bad, refusing to update their very old version of LLVM, despite having had a request for it for the last six months or more. I have just found a .deb package of LLVM2.2-7 at: http://ubuntu.cica.es/debian/pool/main/l/llvm/ which might turn out to be the easiest way to go. I am just going to try it and report here. Libor On Wed, 30 Apr 2008 20:34:44 +0100, Albert Graef <Dr....@t-...> wrote: > Eddie Rucker wrote: >> Tonight, I'm going to install the 64 bit Ubuntu again (I already have a CD) and see if I can get LLVM to work. I should probably go ahead and switch to FreeBSD, as I will later, but I'm too busy to install it. IIRC, FreeBSD wasn't as easy to install. If it works I'll give the step-by-step. > > That would be great! I'll add your notes to the README and will also > make them available on The Pure website. > > In fact, I now seem to recall that the install wasn't all that > difficult, it's just the documentation on the LLVM website which is > confusing. I actually followed the "Building the LLVM GCC Front-End" > page (http://llvm.org/docs/GCCFEBuildInstrs.html) rather than the > "Getting Started" guide, which is much shorter (you'll have to fiddle > with some of the options, though, because that page actually talks about > building the Ada frontend). > > So IIRC this is the procedure I followed (please, someone should verify > these steps, as it's been a while since I've done this): > > *Step#1:* Unpack the sources from both llvm-2.2.tar.gz and > llvm-gcc4.2-2.2.source.tar.gz to some directory SRCDIR and go there (cd > SRCDIR). You can find the downloads here: > http://llvm.org/releases/download.html#2.2 > (Just ignore all the binary packages and get only those two source > tarballs.) > > *Step#2:* Rename the source directories: > > mv llvm-2.2 llvm > mv llvm-gcc4.2-2.2.source llvm-gcc-4.2 > > *Step#3:* Make a build directory llvm-objects for llvm and go there: > > mkdir llvm-objects > cd llvm-objects > > *Step#4:* Configure, build and install LLVM (set prefix to wherever you > want it to, and use ENABLE_OPTIMIZED=0 instead of ENABLE_OPTIMIZED=1 to > build LLVM with checking enabled): > > ../llvm/configure --prefix=/usr/local > make ENABLE_OPTIMIZED=1 > sudo make install > > *Step#5:* Make a build directory llvm-gcc-4.2-objects for llvm-gcc and > go there: > > cd .. > mkdir llvm-gcc-4.2-objects > cd llvm-gcc-4.2-objects > > *Step#6:* Configure, build and install llvm-gcc (you might wish to add > other languages like ada and fortran to the --enable-languages option): > > ../llvm-gcc-4.2/configure --prefix=/usr/local --enable-languages=c,c++ \ > --enable-checking --enable-llvm=$PWD/../llvm-objects --disable-shared \ > --disable-bootstrap --disable-multilib > make > sudo make install > > > That should be all, IIRC. I'm not sure whether you actually have to > install llvm-gcc (steps 5 and 6) if you only want to compile another > LLVM application, but those are the steps I followed on both my > development box (SUSE 10.1) and my laptop (SUSE 10.3), and it allows me > to build Pure just fine. > > HTH, > Albert > |
6 messages has been excluded from this view by a project administrator.
