pure-lang-users Mailing List for Pure (Page 50)
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: Ryan S. <rya...@us...> - 2008-05-03 00:39:39
|
On May 2, 2008, at 5:02 PM, Albert Graef wrote: > Hi Jeremy, > > (I'm cc'ing the list, so that we can discuss any remaining issues > there.) > > Jeremy Voorhis wrote: >> I have a mostly working build of r19. My only modification was adding >> -liconv to the Makefile. I have LLVM 2.2.0 installed from macports, >> and built using the release profile. Make check passes fully. When I >> run it from the svn working tree, everything is fine. > > It's weird that you get a pass on all checks when Ryan's doesn't. But > let's postpone that until the symbol resolution issue has been > resolved. Jeremy, what version of Mac OS X and Xcode do you have and on what processor? |
|
From: Libor S. <li...@gm...> - 2008-05-02 23:38:52
|
Tim, I don't think so, test6.pure looks OK to me. However, there may well be similar bugs elswhere. Libor On Sat, 03 May 2008 00:00:46 +0100, Tim Haynes <q...@st...> wrote: > "Libor Spacek" <li...@gm...> writes: > >> ALbert, >> >> I have solved that problem with test1.pure There is actually a bug in >> fact3. It should be corrected to the following: >> >> fact3 n = case n of >> 0 = 1; >> n = n*fact3 (n-1) if n>0; >> end; >> >> The previous guard n>1 was wrong because fact3 1 then failed to match any >> case. In other words it was not a 64bit issue. > > Could something like that be behind my ppc problem with test6.pure, d'you > think? > > ~Tim |
|
From: Tim H. <q...@st...> - 2008-05-02 23:09:46
|
"Libor Spacek" <li...@gm...> writes: > ALbert, > > I have solved that problem with test1.pure There is actually a bug in > fact3. It should be corrected to the following: > > fact3 n = case n of > 0 = 1; > n = n*fact3 (n-1) if n>0; > end; > > The previous guard n>1 was wrong because fact3 1 then failed to match any > case. In other words it was not a 64bit issue. Could something like that be behind my ppc problem with test6.pure, d'you think? ~Tim -- <http://spodzone.org.uk/> |
|
From: Libor S. <li...@gm...> - 2008-05-02 22:39:31
|
ALbert,
I have solved that problem with test1.pure
There is actually a bug in fact3. It should be corrected to the following:
fact3 n = case n of
0 = 1;
n = n*fact3 (n-1) if n>0;
end;
The previous guard n>1 was wrong because fact3 1 then failed to match any case.
In other words it was not a 64bit issue.
Cheers,
Libor
|
|
From: Albert G. <Dr....@t-...> - 2008-05-02 21:47:11
|
Hi Jeremy, (I'm cc'ing the list, so that we can discuss any remaining issues there.) Jeremy Voorhis wrote: > I have a mostly working build of r19. My only modification was adding > -liconv to the Makefile. I have LLVM 2.2.0 installed from macports, > and built using the release profile. Make check passes fully. When I > run it from the svn working tree, everything is fine. It's weird that you get a pass on all checks when Ryan's doesn't. But let's postpone that until the symbol resolution issue has been resolved. > I just noticed that running pure from /usr/local/bin generates a lot > of warnings/errors, although it appears to function. I've attached > (really!) a transcript demonstrating this. Yes, you're getting the same messages as Ryan, and these are obviously due to -rdynamic not working with Apple's gcc, as Ryan already reported. If all else fails, I can try to work around that, but maybe someone here knows how to do this with the Apple linker? Cheers, 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-02 20:35:05
|
Albert Graef wrote: > Right. But I can remove the dependencies of the log on the test files, > and add an explicit goal to regenerate the logs from changed test files. > Problem solved. Done. The "golden girls" errm I meant "logs" are in svn now. -- 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-05-02 20:25:47
|
Albert Graef <Dr....@t-...> writes: > Tim Haynes wrote: >> No loop for just doing that. List output attached. > > The output code is ok, so compilation works as it should. There's one > more thing you could try before whipping out the almighty gdb: > > PURE_STACK=512 PURELIB=./lib ./pure < test/test6.pure > > If that bails out with a stack_fault exception then indeed it doesn't > match the first rule and the problem is in the generated machine code > (maybe another alignment problem). | <stdin>:3.0-5: unhandled exception 'stack_fault' while evaluating 'fact 4' Oops? Speaking of alignment problems - the ppc differs from x86 and x86_64 by being the opposite endianness. Don't know if that helps anything... :) ~Tim -- <http://spodzone.org.uk/> |
|
From: Albert G. <Dr....@t-...> - 2008-05-02 20:14:57
|
Ryan Schmidt wrote: > Subversion does not store file modification times. Right. But I can remove the dependencies of the log on the test files, and add an explicit goal to regenerate the logs from changed test files. Problem solved. 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: Libor S. <li...@gm...> - 2008-05-02 20:14:20
|
OK, I sent to you direct. Cheers, Libor 2008/5/2 Albert Graef <Dr....@t-...>: > Libor Spacek wrote: > > test/test1.pure: FAILED > > Ok, it seems that there still are some issues on 64 bit, even with the > release build. Could you please send me the output of the following > command? > > pure -v15 < test/test1.pure > > 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 > > ------------------------------------------------------------------------- > 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... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users > |
|
From: Albert G. <Dr....@t-...> - 2008-05-02 20:10:52
|
Tim Haynes wrote: > No loop for just doing that. List output attached. The output code is ok, so compilation works as it should. There's one more thing you could try before whipping out the almighty gdb: PURE_STACK=512 PURELIB=./lib ./pure < test/test6.pure If that bails out with a stack_fault exception then indeed it doesn't match the first rule and the problem is in the generated machine code (maybe another alignment problem). 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: Ryan S. <rya...@us...> - 2008-05-02 20:00:53
|
On May 2, 2008, at 2:50 PM, Albert Graef wrote: > John Cowan wrote: >> In short, they are "golden log files", ones that are distributed as >> samples known to be accurate. It is appropriate to change-control >> this >> kind of files, even though they were originally automatically >> generated. > > Ok, I'm convinced already. ;-) I'll add them to svn. I just hope that > svn recreates the proper timestamps so that you don't end up > regenerating them anyway. IIRC, that's a problem with cvs. Subversion does not store file modification times. By default, when users check out a directory from a Subversion repository, the files will have a modification time equal to the time when the files were checked out. Users can change this by setting "use-commit-times = yes" in their Subversion client's configuration file; then checked out files will have a modification time equal to the time when the files were committed. |
|
From: Albert G. <Dr....@t-...> - 2008-05-02 19:58:50
|
Hi Ryan, >> On May 2, 2008, at 5:13 AM, Ryan Schmidt wrote: >> >>> And also the test suite doesn't pass: >>> >>> PURELIB=./lib ./pure -n -v7 lib/prelude.pure > test/prelude.log >>> PURELIB=./lib ./pure -v7 test/test1.pure > test/test1.log >>> 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 >>> make: *** [test/test4.log] Error 139 Yes, I did notice this after hitting "Send", and I did follow up on this message, but apparently that post went into Nirvana. ;-) Anyway, could you please send me the log files that you have, especially test4.log? Also, I have a report from someone who apparently has Pure up and running on OSX already, but I still need to confirm that. 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-02 19:35:32
|
John Cowan wrote: > In short, they are "golden log files", ones that are distributed as > samples known to be accurate. It is appropriate to change-control this > kind of files, even though they were originally automatically generated. Ok, I'm convinced already. ;-) I'll add them to svn. I just hope that svn recreates the proper timestamps so that you don't end up regenerating them anyway. IIRC, that's a problem with cvs. 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: Ryan S. <rya...@us...> - 2008-05-02 19:34:17
|
On May 2, 2008, at 12:12 PM, Albert Graef wrote: > Ryan Schmidt wrote: >> I'm at the point where r30 of the source builds on Mac OS X, so I'm >> making my portfile available. If you want to try it, make sure you >> have MacPorts and Subversion installed and check it out: > > That's great. :) Just to be sure: Does 'make check' work? Not exactly: > On May 2, 2008, at 5:13 AM, Ryan Schmidt wrote: > >> And also the test suite doesn't pass: >> >> PURELIB=./lib ./pure -n -v7 lib/prelude.pure > test/prelude.log >> PURELIB=./lib ./pure -v7 test/test1.pure > test/test1.log >> 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 >> make: *** [test/test4.log] Error 139 |
|
From: Albert G. <Dr....@t-...> - 2008-05-02 19:28:19
|
Ryan Schmidt wrote: > And also the test suite doesn't pass: Oops, scratch my previous post, I only noticed this now. Could you please send me your test/*.log files? Then I'll look into it. > And when I run the pure binary I get this: > > $ pure > primitives.pure:29.7-33: external symbol 'same' cannot be found That looks like the external resolution in LLVM doesn't work, probably a bug in LLVM. I'll try to find a way to work around that. Maybe that also made the regression tests fail. 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-02 19:06:04
|
Libor Spacek wrote: > test/test1.pure: FAILED Ok, it seems that there still are some issues on 64 bit, even with the release build. Could you please send me the output of the following command? pure -v15 < test/test1.pure 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-02 18:53:26
|
Eddie Rucker wrote: >> (1,2):(2,3):[]; > (1,2):(2,3):[] > > not ok. Why not? That's just the normal way a list of tuples is printed. If you don't see why, check what [(1,2),(2,3)] gives you and read about "flat tuples" and the role of parentheses in the manpage. Well, maybe I ought to put a note about this into the CAVEATS AND NOTES section of the manpage. Or start a FAQ! :) > Actually, I found this when trying to do a list comprehension: > >> [x,y; x=1..5; y=1..5; x<y]; > (1,2):(1,3):(1,4):(1,5):(2,3):(2,4):(2,5):(3,4):(3,5):(4,5):[] Again, that's just what it's supposed to be. (Sorry, I don't have the time to go into further detail right now, gotta run because we have a rehearsal with our choir. Will maybe follow up later.) 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-02 18:48:08
|
Ryan Schmidt wrote: > I'm at the point where r30 of the source builds on Mac OS X, so I'm > making my portfile available. If you want to try it, make sure you > have MacPorts and Subversion installed and check it out: That's great. :) Just to be sure: Does 'make check' work? 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: John C. <co...@cc...> - 2008-05-02 18:40:48
|
Albert Graef scripsit: > But normally the output of those regression tests is *only* to be > regenerated when the tests themselves change (this is done > automatically), otherwise the whole idea of the check is to *compare* > your output against the *existing* logs, which presumably were generated > for you on a system where it's already known that the interpreter works > correctly. In short, they are "golden log files", ones that are distributed as samples known to be accurate. It is appropriate to change-control this kind of files, even though they were originally automatically generated. -- John Cowan http://ccil.org/~cowan co...@cc... 'My young friend, if you do not now, immediately and instantly, pull as hard as ever you can, it is my opinion that your acquaintance in the large-pattern leather ulster' (and by this he meant the Crocodile) 'will jerk you into yonder limpid stream before you can say Jack Robinson.' --the Bi-Coloured-Python-Rock-Snake |
|
From: Albert G. <Dr....@t-...> - 2008-05-02 18:38:58
|
Tim Haynes wrote: > I'm also attaching a trivial patch to Makefile that should remove logs > before `make check', thereby starting afresh at test 1 every time the way I > like it. No, that's not the way those tests are supposed to work. I know that this confusion arises because the test logs aren't included in svn right now. Maybe I should do that, but I made it a strong habit to never put generated stuff in a repository. But normally the output of those regression tests is *only* to be regenerated when the tests themselves change (this is done automatically), otherwise the whole idea of the check is to *compare* your output against the *existing* logs, which presumably were generated for you on a system where it's already known that the interpreter works correctly. The only circumstances under which I regenerate the logs from scratch is when there's some change in the compiler affecting the output of -v7. In such a case I just run 'make cleanlogs check', *after* carefully checking the diffs against the existing logs and making sure that everything still works. Also note that the output of -v7 is truly platform-independent, it's only abstract code (essentially rewriting rules annotated with de Bruijn indices and descriptions of the corresponding pattern matching automata) which isn't supposed to change. It doesn't even include the generated LLVM assembler code, because that code is subject to change (e.g., if there's a bug in the code generator, or some new semantics-preserving optimizations are applied). Whereas the output of -v7 is just the abstract "meaning" of your program. Ok, I hope that this clears things up a bit. :) I'll probably have to put some notes about this into the README file. 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-02 18:35:42
|
Tim Haynes wrote: > I've built the release and default builds of pure on ubuntu gutsy/ppc: > | zsh, trough 1:36PM trunk/ % uname -a > | Linux trough 2.6.22-14-powerpc #1 Tue Dec 18 08:48:38 UTC 2007 ppc GNU/Linux Forgive my ignorance, but is that a 32 bit or 64 bit cpu? If the latter, does a 32 bit build exhibit the same problems? > Using either build option-set, pure goes ballistic and hogs lotsaRAM(TM) - > up to 600M and growing fast, on this line: > > | PURELIB=./lib ./pure -v7 test/test6.pure > test/test6.log Hmm, no idea. What happens if you enter the following definition and list command manually? fact n = 1 if n==0; = n * fact (n-1) otherwise; list -cde fact Does that loop as well? If so, then I'm afraid it's gdb time. Otherwise please send me the output of the list command, so that I can check the generated code. I still have a few other minor things to fix, then I'm ready to give it a go on 64 bit Linux myself... 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-05-02 15:30:26
|
Pestering Ed again ;) > 1:2:[]; [1,2] ok. > (1,2):(2,3):[]; (1,2):(2,3):[] not ok. Actually, I found this when trying to do a list comprehension: > [x,y; x=1..5; y=1..5; x<y]; (1,2):(1,3):(1,4):(1,5):(2,3):(2,4):(2,5):(3,4):(3,5):(4,5):[] > e.r. |
|
From: Libor S. <li...@gm...> - 2008-05-02 12:06:21
|
The culprit is:
fact3 n = case n of
0 = 1;
n = n*fact3 (n-1) if n>1;
end;
I believe it is failing to match the zero case.
Forgive me if you already know about this and are "on the case".
2008/5/2 Libor Spacek <li...@gm...>:
> Revision 30, still on my Ubuntu 64-bit system gives:
>
> l@ubuntu:~/pure-lang/pure/trunk$ make check
> PURELIB=./lib ./pure -n -v7 lib/prelude.pure > test/prelude.log
> PURELIB=./lib ./pure -v7 test/test7.pure > test/test7.log
> Running tests.
> prelude.pure: passed
> test/test1.pure: FAILED
> test/test2.pure: passed
> test/test3.pure: passed
> test/test4.pure: passed
> test/test5.pure: passed
> test/test6.pure: passed
> test/test7.pure: passed
>
>
|
|
From: Libor S. <li...@gm...> - 2008-05-02 11:41:43
|
Revision 30, still on my Ubuntu 64-bit system gives: l@ubuntu:~/pure-lang/pure/trunk$ make check PURELIB=./lib ./pure -n -v7 lib/prelude.pure > test/prelude.log PURELIB=./lib ./pure -v7 test/test7.pure > test/test7.log Running tests. prelude.pure: passed test/test1.pure: FAILED test/test2.pure: passed test/test3.pure: passed test/test4.pure: passed test/test5.pure: passed test/test6.pure: passed test/test7.pure: passed |
|
From: Eddie R. <er...@bm...> - 2008-05-02 10:40:20
|
> Libor Spacek wrote: > > However, it is a bit slower than your reported time, > even though my> processor is a bit better. > > Well, raw performance depends on many factors: type of cpu, instruction > set, cache size, compiler version etc. etc. So you can only do more or > less meaningful benchmarks by running two programs against each other > onthe same machine. ... and how many processes are running in the background. My previous Debian system only had maybe 12 or 14 backgound process running after startup, I never had X running at startup. Ubuntu seems like it has a zillion running after startup :( e.r. |
6 messages has been excluded from this view by a project administrator.
