Thread: Re: [q-lang-users] Pure (Page 2)
Brought to you by:
agraef
From: Ryan S. <rya...@us...> - 2008-04-29 19:50:31
|
On Apr 29, 2008, at 7:58 AM, Albert Graef wrote: > Ok, a minimal website is now online at http://pure-lang.sf.net/, and > both the SVN repository and the 0.1 release are now available. 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. I installed llvm using MacPorts, so it's not in /usr/local. Replacing all occurrences of /usr/local with the MacPorts prefix in the Makefile got me to this: 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 'expr* interpreter::mkwhen_expr (expr*, rulel*)': interpreter.cc:1325: error: no match for 'operator!=' in 'it != std::list<_Tp, _Alloc>::rend() [with _Tp = rule, _Alloc = std::allocator<rule>]()' interpreter.cc: In member function 'llvm::Function* interpreter::declare_extern(std::string, std::string, const std::list<std::string, std::allocator<std::string> >&, bool, void*, std::string)': interpreter.cc:2243: warning: passing negative value 'INT' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2255: warning: passing negative value 'INT' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2267: warning: passing negative value 'INT' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2279: warning: passing negative value 'INT' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2291: warning: passing negative value 'DBL' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2303: warning: passing negative value 'STR' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2313: warning: passing negative value 'PTR' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2325: warning: passing negative value 'PTR' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2349: warning: passing negative value 'PTR' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2350: warning: passing negative value 'STR' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' interpreter.cc:2351: warning: passing negative value 'BIGINT' for argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get(const llvm::Type*, uint64_t, bool)' 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 make: *** [interpreter.o] Error 1 Now I don't know how to proceed. |
From: Albert G. <Dr....@t-...> - 2008-04-30 00:16:09
|
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. For the time being, just run 'make depend' before doing 'make', that should fix it. > 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. > 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. What version of gcc did you use? > 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. 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-04-30 18:20:22
|
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? >> 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. Thanks for reporting, 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: Tim H. <q...@st...> - 2008-03-31 19:53:20
|
Just had a thought, since we're talking fairly fundamental bits of Q... I'm in the middle of hacking up a script to work on potentially large bitmaps. In a normal run, my script is well-behaved, albeit slow, using about 23M RAM for a couple of minutes. That's OK. However, during a hacking phase when I'm introducing screwups by the minute, it feels the urge to spew huge strings as it represents lists of variously 65536 elements or even that many triples - and most noticeably hogs up to a gig RAM in the process. Am I right in thinking that the generation of error strings including object-dumps is non-lazy? It's a bit of a PITA trying to find the one or two list-elements on which it can't do some function or other in the middle of such a large list. Normal development process here is emacs and a mrxvt session or two in whcih I either run the script or occasionally q -d theblighter.q or rarely hack around in the interpreter. Is there any way to speed the process up a bit? Maybe set a few exceptions or something? ~Tim -- <http://spodzone.org.uk/> |
From: Albert G. <Dr....@t-...> - 2008-03-31 23:19:04
|
Tim Haynes wrote: > Am I right in thinking that the generation of error strings including > object-dumps is non-lazy? Well, if you use a non-lazy data structure (lists rather than streams) then that's what you get... > It's a bit of a PITA trying to find the one or two list-elements on which > it can't do some function or other in the middle of such a large list. I guess that you should really take a look at the new bytestring operations in clib which allow you to treat a bytestring as a mutable integer vector with fast random access. That should probably work much better for the application at hand. Or maybe tuples of references would be helpful (reftypes.q). In Pure you'll hopefully be able to do serious number crunching like this, although it still won't be quite as fast as Fortran. ;-) > Is there any way to speed the process up a bit? Maybe set a few exceptions > or something? Yup, that's what they're for. Just add a few default rules throwing exceptions to the suspicious functions. HTH, 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: Tim H. <q...@st...> - 2008-03-31 23:35:32
|
Albert Graef <Dr....@t-...> writes: > Tim Haynes wrote: >> Am I right in thinking that the generation of error strings including >> object-dumps is non-lazy? > > Well, if you use a non-lazy data structure (lists rather than streams) > then that's what you get... Ah :) Yes, that's something else I've considered, but I'll start with a smaller script to understand exactly how to convert them all across :) >> It's a bit of a PITA trying to find the one or two list-elements on >> which it can't do some function or other in the middle of such a large >> list. > > I guess that you should really take a look at the new bytestring > operations in clib which allow you to treat a bytestring as a mutable > integer vector with fast random access. That should probably work much > better for the application at hand. Or maybe tuples of references would > be helpful (reftypes.q). Oh? That's interesting. I discovered uint16_list and relatives the other day, which has made life an awful lot nicer. Now one of the big slow-downs is the conversion of the bitmap to triples and back - actually, I could use a hand improving on this: //take flat list, return list of triples triplify [] = []; triplify Ds = [tuple $ sub Ds 0 2] ++ (triplify (sub Ds 3 ((#Ds)-1))); //take list of triples, return flat list detriplify = (foldr1 (++)) . (map list) ; I was wondering if there was something smart I could be doing with zip3, but memory is a serious concern at this point. I don't necessarily need random-access on the thing at the moment - a simple map across the whole lot will suffice, so this is also a candidate for streaming to reduce memory footprint later. Any advances welcome :) > In Pure you'll hopefully be able to do serious number crunching like > this, although it still won't be quite as fast as Fortran. ;-) Sounds good to me :) >> Is there any way to speed the process up a bit? Maybe set a few >> exceptions or something? > > Yup, that's what they're for. Just add a few default rules throwing > exceptions to the suspicious functions. Right, I'll see what I can do. It's the occasional simple things like ... where C=hdict (R ++ [(G,G)]) except I first forgot about the [] there and wound up with a 600M pid for the interpreter, a list of 64K elements plus a pair on the end in an error message. Ooops :) ~Tim -- <http://spodzone.org.uk/> |
From: Eddie R. <er...@bm...> - 2008-04-28 13:14:21
|
On Mon, 2008-04-28 at 11:45 +0100, Libor Spacek wrote: > I have installed Ubuntu 4.08, which was, unexpectedly, a pain in the neck. This is off topic but, why such an old version? I'm using 8.04 (I'm dyslexic so I didn't catch that at first) and it was fairly painless to install. You can get LLVM 2.3 through the Synaptic Package Manager by adding more software sources but I don't know what they are. Sometimes I prefer the manual install ;) I installed Ubuntu, then Ubuntu 64bit, then back to Ubunto. Although not Linux, I think I liked FreeBSD of all the OSs I've used and that is quite a list. > > Hi friends, > > BTW, the present version is some 30-40 times faster than Q on naive fib, > > IIRC. I was hoping for more, but it's already 7 times faster than Python > > 2.4 on the recursive benchmark from the shootout, and it certainly makes I wonder if Python 2.5 is faster than 2.4? MzScheme seemed to be faster than Python 2.5 on most of the bench marks on the shootout. Lua seems pretty fast too. The OCaml interpreter absolutely smokes. If I were aiming for speed, the OCaml interpreter is the one to chase. However, IIRC, BigIntegers are not built into OCaml and that and type information can have a major impact on speed. Eddie |
From: Libor S. <li...@gm...> - 2008-04-28 13:43:58
|
Eddie, Sorry, I must be dyslexic too, I meant 8.04., 64bit. It took a dislike to my ATA disks, though previous Ubuntus were OK with them. However, I found some "magic incantation" boot options and it works now. You were lucky to get an easy ride, I think. I will look for the LLVM software sources, I like them for their automatic updates. Libor On Mon, 28 Apr 2008 14:14:04 +0100, Eddie Rucker <er...@bm...> wrote: > On Mon, 2008-04-28 at 11:45 +0100, Libor Spacek wrote: > >> I have installed Ubuntu 4.08, which was, unexpectedly, a pain in the neck. > > This is off topic but, why such an old version? I'm using 8.04 (I'm > dyslexic so I didn't catch that at first) and it was fairly painless to > install. You can get LLVM 2.3 through the Synaptic Package Manager by > adding more software sources but I don't know what they are. Sometimes I > prefer the manual install ;) I installed Ubuntu, then Ubuntu 64bit, then > back to Ubunto. Although not Linux, I think I liked FreeBSD of all the > OSs I've used and that is quite a list. |
From: Eddie R. <er...@bm...> - 2008-04-28 17:27:46
|
Ok, I cannot find a Debian package so it looks like a manual install from the source code is the easy way to go. Eddie On Mon, 2008-04-28 at 15:43 +0100, Libor Spacek wrote: > Eddie, > > Sorry, I must be dyslexic too, I meant 8.04., 64bit. > It took a dislike to my ATA disks, though previous Ubuntus were OK with them. > However, I found some "magic incantation" boot options and it works now. > You were lucky to get an easy ride, I think. > I will look for the LLVM software sources, > I like them for their automatic updates. > > Libor > > On Mon, 28 Apr 2008 14:14:04 +0100, Eddie Rucker <er...@bm...> wrote: > > > On Mon, 2008-04-28 at 11:45 +0100, Libor Spacek wrote: > > > >> I have installed Ubuntu 4.08, which was, unexpectedly, a pain in the neck. > > > > This is off topic but, why such an old version? I'm using 8.04 (I'm > > dyslexic so I didn't catch that at first) and it was fairly painless to > > install. You can get LLVM 2.3 through the Synaptic Package Manager by > > adding more software sources but I don't know what they are. Sometimes I > > prefer the manual install ;) I installed Ubuntu, then Ubuntu 64bit, then > > back to Ubunto. Although not Linux, I think I liked FreeBSD of all the > > OSs I've used and that is quite a list. > > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > q-lang-users mailing list > q-l...@li... > https://lists.sourceforge.net/lists/listinfo/q-lang-users |