Re: Use of num instead of float
Joshua Isom wrote: > ... proposing to change all floats to nums ... I have no objection to the proposed change - but it would be interesting to know the motivation behind this proposal. In some languages, 'num'/'number'/'numeric'/'bignum' implies decimal arithmetic and 'float'/'real'/'double' implies binary arithmetic. Regards, Roger Browne
Re: Use of num instead of float
On Dec 19, 2005, at 20:31 , Joshua Isom wrote: I was talking to Leo in the IRC room and he told me post onto the list about proposing to change all floats to nums. Code such as `.local float i` would instead be written as `.local num i`, but as I gather it, current behavior would remain the same, or at least general behavior. I don't endorse this change in it's entirety as you suggest, it will wreak havoc with globals down the road. I see no reason to not modify any routines using decimal arithmetics however changing binary arithmetics to be referenced as floats is just poor programming and promotes unstable structure. -- Dale
Re: Shootout Updates Posted
On Dec 20, 2005, at 4:01, Joshua Hoblitt wrote: I'm surprised that Parrot's memory usage is so high relative to other platforms. It looks like a hog even relative to Java. Has anyone taken a serious look at where all that memory is going? Memory usage as well as startup time aren't optimized at all. One thing comes to my mind immediately: the MMD_table takes more than 1 MB and setup time is in prominent position in profile logs. -J leo
Re: Shootout Updates Posted
On Dec 20, 2005, at 1:35, Brent Fulgham wrote: FYI, the revised shootout updates are on the site: http://shootout.alioth.debian.org/sandbox/benchmark.php? test=all&lang=parrot Yeah, I've seen it. Thanks a lot for updating all. Performance seems much better with the interpreter flags suggested. Please let me know if you notice any problems. Yup. Fasta and random seem to be unable to load random_lib.pir, as that file wasn't in the debian package, when that was built. Loading the file should work, if it is copied to runtime/library (that location where e.g. PGE.pbc is). Thanks again, leo
ChangeLog serves no purpose
In it's current form ChangeLog is little more than a pointer to NEWS. This is really defeating the purpose of what ChangeLog is supposed to contain; detailed information about changes. It is also more or less redundant with the function of NEWS. However, I am not proposing that people start adding detailed information to ChangeLog. I think it is entirely reasonable to machine generate this file with svn2cl[1] before each release. Comments? Cheers, -J [1] http://ch.tudelft.nl/~arthur/svn2cl/ -- pgpyUhaVxBmpX.pgp Description: PGP signature
Re: ChangeLog serves no purpose
On Tue, Dec 20, 2005 at 02:03:44AM -1000, Joshua Hoblitt wrote: > people start adding detailed information to ChangeLog. I think it is > entirely reasonable to machine generate this file with svn2cl[1] before > each release. Comments? Generating it from the subversion commit messages seems a good way to go. Doing it per release is equivalent to the perl 5 situation, where the Changes file is updated before each official snapshot or release from the perforce commit messages. Nicholas Clark
Re: Test::Harness spitting an error
On 12/15/05, Troy Denkinger <[EMAIL PROTECTED]> wrote: > > > I wrote a test harness - you'll find the code below my signature, if > you're interested. When I run it, I get the following: > > You said to run 0 tests! You've got to run something. > # Looks like your test died before it could output anything. > > Then the tests run and the success/failure report for each module > returns success. Anyone have any idea where this error is coming from? That's an error from Test::Builder (ie. the thing behind Test::More and others) and not Test::Harness. Its coming from the test program your harness is running, not from the harness itself. My guess would be is that the recursive search for test files (using File::Find and looking for .t files it not the same as t/*.t) has picked up a .t file you forgot about somewhere inside your t/ directory hierarchy and is trying to run it. Additionally, File::Find will chdir() into each directory as it works, thus you're running your tests from a different place than prove. Most tests assume they're being run from the top of the package source directory, not from their own directory. If your plan is based on reading some list of files in the source directory it probably can't and thus is coming up with 0. You can use the 'no_chdir' flag to get around this. Simplest thing to do is to throw in a print $File::Find::name before your analyze_file() call so you can know what messages are associated with what test files, that should allow you to easily identify the failing test. And you really should have that sort of information in your harness anyway. Also throw in a cwd() check to verify that File::Find has put you in an odd directory.
Re: Test::Harness spitting an error
On 12/19/05, Troy Denkinger <[EMAIL PROTECTED]> wrote: > The error is related to my pod.t which is, just as in the docs: > > use Test::More; > eval "use Test::Pod 1.14"; > plan skip_all => "Test::Pod 1.14 required for testing POD" if $@; > all_pod_files_ok(); > > Running this under my test harness, I get the error. Running this with > prove directly, I get no errors. I probably won't dig further into this > as it's not really worth the time. I'm guessing the problem is > Test::Harness::* related. It is not Test::Harness related. Your custom harness is using File::Find which chdirs as it recurses. This means your test is running from within t/. It normally runs one level up. This means all_pod_files_ok() cannot see blib/ so it can't find any POD to check. The solution is to use the no_chdir flag to File::Find::find() so that your tests are run from the top level of your source directory, not inside t/.
Re: Use of num instead of float
As a parrot user, I have two feelings about this proposal 1) A very small part of me thinks that this would improve a small consistency nit which I've already lived with for... 4 years? 2) A much larger part would find it another inconvenience in a long line of (each one justifiable in its own light) inconveniences. That said, hope for the best, but... While I'm sure it's implied, I suggest postponing it for a .0 release (0.5.0?), but start documenting the change and offering the new syntax as a (preferred) option well in advance. Similar to what was done with recent items in DEPRECATED, but with a much longer time frame. And, assuming the goal here is consistency across the board, don't forget about .sym. Or the Float PMC, or VTABLE methods like "unshift_float", or methods like Parrot_floatval_time, or the FLOATVAL macro. And collateral changes like the docs, the website and the examples. And the book. My 2ยข. On Dec 19, 2005, at 8:31 PM, Joshua Isom wrote: I was talking to Leo in the IRC room and he told me post onto the list about proposing to change all floats to nums. Code such as `.local float i` would instead be written as `.local num i`, but as I gather it, current behavior would remain the same, or at least general behavior.
Re: ChangeLog serves no purpose
Anything that makes it easier for developers to develop is a good thing. On Dec 20, 2005, at 7:40 AM, Nicholas Clark wrote: On Tue, Dec 20, 2005 at 02:03:44AM -1000, Joshua Hoblitt wrote: people start adding detailed information to ChangeLog. I think it is entirely reasonable to machine generate this file with svn2cl[1] before each release. Comments? Generating it from the subversion commit messages seems a good way to go. Doing it per release is equivalent to the perl 5 situation, where the Changes file is updated before each official snapshot or release from the perforce commit messages. Nicholas Clark
Re: ChangeLog serves no purpose
On 12/20/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > In it's current form ChangeLog is little more than a pointer to NEWS. > This is really defeating the purpose of what ChangeLog is supposed to > contain; detailed information about changes. It is also more or less > redundant with the function of NEWS. However, I am not proposing that > people start adding detailed information to ChangeLog. I think it is > entirely reasonable to machine generate this file with svn2cl[1] before > each release. Comments? > i've recently started updating changelog during my directory reorg, as i was told it would make it easier to generate the debian package (so it is useful.) automatic generation sounds great, but it's no good without clear commit messages. one or two word commit messages should be shunned in favor of brief yet clear descriptions of the change, including which parrot components are affected. here are some guidelines for good commit messages, from my observations: ~ languages should prefix the message with the language name/nickname (eg. 'tcl: added compiled [frobnitz]') ~ if the work is against a ticket, the ticket number and title should be included in the message (eg. '[#3141592] [PATCH] add moonphase op) ~ if the work is being committed for someone without ci rights, a courtesy message should be included (eg. 'Courtesy of Alex the Parrot <[EMAIL PROTECTED]>') ~ if the commit is platform dependent, or has been tested on one or more platforms, say it (eg. 'tested successfully on i386-linux-gcc-4.0 and win32-msvc-7.1') ~ details (if appropriate) should be provided in a bullet-list format for easy reading (eg. '* added handle jiggling to flush all buffers') i hope this (incomplete) list is helpful. if these guidelines are followed, a generated changelog will be valuable without getting in the way. ~jerry
Re: Use of num instead of float
On Dec 19, 2005, at 8:31 PM, Joshua Isom wrote: >I was talking to Leo in the IRC room and he told me post onto the >list about proposing to change all floats to nums. Code such as >`.local float i` would instead be written as `.local num i`, but as >I gather it, current behavior would remain the same, or at least >general behavior. How does the Pugs number hierarchy work? Specifically, I'm uncomfortable with this idea because floating point is just one way of representing numbers. Integers being another way. And it feels wrong to call one particular representation "num(ber)". It's going to cause confusion - there will be numbers and nums. [I guess we just need to get the ISO C people to s/float/single/g and then "float" won't be overloaded to mean a particular representation size.] Nicholas Clark
Re: Test::Harness spitting an error
Michael G Schwern wrote: That's an error from Test::Builder (ie. the thing behind Test::More and others) and not Test::Harness. Its coming from the test program your harness is running, not from the harness itself. [snip] Thanks, Michael. I'll try that. Regards, Troy
Re: [perl #37992] [PATCH] Conditional jump or move depends on uninitialised value
*sigh* Please don't apply this patch ... It causes the most recent svn tree to segfault when trying to build PGE: gmake[1]: Leaving directory `/home/steveg/parrot/src/dynclasses' gmake -C compilers/pge gmake[1]: Entering directory `/home/steveg/parrot/compilers/pge' ../../parrot mklib.pir >PGE/Library.pir /bin/sh: line 1: 8863 Segmentation fault ../../parrot mklib.pir >PGE/Library.pir gmake[1]: *** [PGE.pbc] Error 139 gmake[1]: Leaving directory `/home/steveg/parrot/compilers/pge' make: *** [compilers.dummy] Error 2
Announcing "Amber for Parrot 0.4.0 (Induction)"
I have released "Amber for Parrot" version 0.4.0 (Induction): Downloads: http://xamber.org/download.html Release history: http://xamber.org/history.html Project home page: http://xamber.org/index.html "Amber for Parrot" is an Eiffel-like scripting language for the Parrot Virtual Machine. Changes since version 0.3.1: - The "old" keyword is implemented - Unary plus & minus now have higher precedence than dot-calls in a Call_chain - New test to check operator precedence - Minor change to code generation for manifest integer constants - Square-bracket indexing of Hash and Array implemented for single dimensions - New test for copying/reference semantics and aliasing - Implemented outer lexicals for AGENTs (read-only) - New test for outer variables - Added Ackermann benchmark to examples/shootout - Inspect_instruction now accepts multiple Expressions in When_part - New test for the Inspect_instruction - Various bug fixes and tweaks - Estimated progress towards release 1.0: language constructs 46%, libraries 6%, documentation 4%, robustness 5% Roger Browne
Re: [perl #37992] [PATCH] Conditional jump or move depends on uninitialised value
The errors reported by valgrind have also gone in the latest SVN release. This now seems to be a non-issue. 8-)
Re: ChangeLog serves no purpose
On Dec 20, 2005, at 16:45, jerry gay wrote: ... automatic generation sounds great, but it's no good without clear commit messages. one or two word commit messages should be shunned in favor of brief yet clear descriptions of the change, including which parrot components are affected. here are some guidelines for good commit messages, from my observations: [ ... ] Exactly. I've tried that mentioned svn2cl util for the 50 last revs. Due to file moves or other global changes a lot of the created ChangeLog entries are a meaningless mess of a list of filenames + an "oneliner". If I need this I can still run 'svn log -v ...' I still prefer a single line ChangeLog entry that is concise (due to mentioned guidelines), generated automatically, and includes the revision number for further digging. This still will need the help of all committers to create a precise heading line. ~jerry
Re: ChangeLog serves no purpose
On Tue, Dec 20, 2005 at 07:45:30AM -0800, jerry gay wrote: > On 12/20/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote: > > In it's current form ChangeLog is little more than a pointer to NEWS. > > This is really defeating the purpose of what ChangeLog is supposed to > > contain; detailed information about changes. It is also more or less > > redundant with the function of NEWS. However, I am not proposing that > > people start adding detailed information to ChangeLog. I think it is > > entirely reasonable to machine generate this file with svn2cl[1] before > > each release. Comments? > > > i've recently started updating changelog during my directory reorg, as > i was told it would make it easier to generate the debian package (so > it is useful.) automatic generation sounds great, but it's no good > without clear commit messages. one or two word commit messages should > be shunned in favor of brief yet clear descriptions of the change, > including which parrot components are affected. Admittedly, your updating of ChangeLog is what motivated this thread. I keep a list of modifications in a file named Changes as part of all of my CPAN distributions but doing such a thing is really a burden for a project as large as Parrot. I think that your working too hard. ;) This is something that can be automated. I also agree that some discipline with respect to the format of changeset metadata is good but I don't agree with all of your points. > here are some guidelines for good commit messages, from my observations: > ~ languages should prefix the message with the language name/nickname > (eg. 'tcl: added compiled [frobnitz]') I don't agree with this point because the commit message should be taken in the context of the file(s) being modified. An example GNU format ChangeLog entry (actually generated from the Parrot tree) for a language changeset would look: 2005-12-16 05:22 allison * trunk, trunk/MANIFEST, trunk/MANIFEST.SKIP, trunk/config/gen/makefiles/punie.in, trunk/languages/punie/demo.p1, trunk/languages/punie/lib, trunk/languages/punie/lib/PunieGrammar.pir, trunk/languages/punie/lib/punie.g, trunk/languages/punie/pge_compile.pir, trunk/languages/punie/punie.pir: Refactor Punie so it uses a pre-compiled PGE grammar. Another example of a lengthy commit message not being required when put in context: 2005-12-17 19:35 jhoblitt * trunk/MANIFEST: sorted > ~ if the commit is platform dependent, or has been tested on one or > more platforms, say it > (eg. 'tested successfully on i386-linux-gcc-4.0 and win32-msvc-7.1') I think that sort of metadata is more appropriate for an RT ticket. A commit messages should describe primarily * what* is being changed instead of *why* the change is being made. Of course, including the *why* doesn't hurt but I don't believe it should be part of our guidelines. > ~ details (if appropriate) should be provided in a bullet-list format > for easy reading > (eg. '* added handle jiggling to flush all buffers') I don't really like that either but that's really just a matter of style. > i hope this (incomplete) list is helpful. if these guidelines are > followed, a generated changelog will be valuable without getting in > the way. I agree with all of your other points. Somebody should write this up and add it to the tree. Perhaps under docs/dev? Cheers, -J -- pgpTEvFDz82aD.pgp Description: PGP signature
Re: ChangeLog serves no purpose
On Tue, Dec 20, 2005 at 11:56:17PM +0100, Leopold Toetsch wrote: > I've tried that mentioned svn2cl util for the 50 last revs. Due to file > moves or other global changes a lot of the created ChangeLog entries > are a meaningless mess of a list of filenames + an "oneliner". If I > need this I can still run 'svn log -v ...' The size of the entries can be limited. The thing to keep in mind is who the audience of ChangeLog is. It's really intended for end users that are looking to see when some behavior changed (I do this all the time in glibc). Developers can and should just use `svn log...`. > I still prefer a single line ChangeLog entry that is concise (due to > mentioned guidelines), generated automatically, and includes the > revision number for further digging. > > This still will need the help of all committers to create a precise > heading line. Agreed. Who's going to get beaten with sticks first? :) -J -- pgph7X4S02PVS.pgp Description: PGP signature
[perl #37992] [PATCH] Conditional jump or move depends on uninitialised value
# New Ticket Created by Steve Gunnell
# Please include the string: [perl #37992]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37992 >
It hasn't fixed my Segfaulting but along the way valgrind was reporting
a lot of errors like:
==7675== Conditional jump or move depends on uninitialised value(s)
==7675==at 0x80CC77A: trace_mem_block (dod.c:1023)
==7675==by 0x80CEC3C: trace_system_stack (cpu_dep.c:117)
==7675==by 0x80CEBFC: trace_system_areas (cpu_dep.c:98)
==7675==by 0x80CBF56: Parrot_dod_trace_root (dod.c:375)
==7675==by 0x80CBFAF: trace_active_PMCs (dod.c:387)
==7675==by 0x80CCAAC: Parrot_dod_ms_run (dod.c:1232)
==7675==by 0x80CCB75: Parrot_do_dod_run (dod.c:1271)
==7675==by 0x812B579: mem_allocate (resources.c:142)
==7675==by 0x812BF37: Parrot_allocate_string (resources.c:613)
==7675==by 0x808DA6D: Parrot_unmake_COW (string.c:79)
==7675==by 0x81B69D4: upcase (ascii.c:168)
==7675==by 0x8090CA1: string_upcase_inplace (string.c:2590)
==7675==
The cause seems to be a reversed test in dod.c
--- src/dod.c 2005-12-20 21:36:58.0 +0800
+++ src/dod.new 2005-12-20 21:36:45.0 +0800
@@ -1004,7 +1004,7 @@
if (!lo_var_ptr || !hi_var_ptr)
return;
-if (lo_var_ptr < hi_var_ptr) {
+if (lo_var_ptr > hi_var_ptr) {
tmp_ptr = hi_var_ptr;
hi_var_ptr = lo_var_ptr;
lo_var_ptr = tmp_ptr;
[perl #37993] [BUG] optimized parrot behaves differently than non-optimized (win32-msvc)
# New Ticket Created by jerry gay # Please include the string: [perl #37993] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37993 > compiling either with msvc 6.0 or 7.1 on win32, parrot behaves differently wrt 0 vs -0 depending on whether optmizations are enabled. nmake realclean && svn up && configure.pl && nmake smoke ## passes tests, which expect 0 and not -0 nmake realclean && svn up && configure.pl --optimize && nmake smoke ## fails tests for example, - t/op/arithmetics.t # Failed test (t/op/arithmetics.t at line 213) # got: '-0.00 # -0.00 # -123.456789 # 123.456789 # -0.00 # -0.00 # -123.456789 # 123.456789 # ' # expected: '-0.00 # 0.00 # -123.456789 # 123.456789 # -0.00 # 0.00 # -123.456789 # 123.456789 # ' # Looks like you failed 1 test of 26. can't debug now as i'm off on holiday, but i'll be back in a week to have a look if nobody's beaten me to it. please somebody, beat me to it ;) also, i thought -0 was correct, and 0 was broken as per the standard. why are the tests expecting 0 and not -0? why is optimization changing the results? this smells like a combination of bad tests and bad code to me. ~jerry
Re: ChangeLog serves no purpose
> I think that sort of metadata is more appropriate for an RT ticket. A > commit messages should describe primarily * what* is being changed > instead of *why* the change is being made. Of course, including the > *why* doesn't hurt but I don't believe it should be part of our > guidelines. (This isn't at all my call, I know, but this is one of those things I have very strong opinions about.) I disagree very strongly. _What_ you're changing is something that's really easy to reverse-engineer from the diffs. _Why_ you you changed a dot to a colon or sorted a MANIFEST isn't something that anyone's going to be able to guess without a hint later on. "Why" is the one thing I really care about in Commit messages. Jesse
[perl #37997] r10604 build failure on Cygwin
# New Ticket Created by Justin Koser # Please include the string: [perl #37997] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37997 > Hello Parrot hackers, I'm trying to build Subversion revision 10604 of Parrot on Cygwin, and everything seems fine until I end up with a bunch of linker errors. Below, please find the contents of `myconfig' and some of the build output. Naturally, I'm willing to help solve this in any way that I can. Thanks, Justin Summary of my parrot 0.4.0 (r10604) configuration: configdate='Tue Dec 20 19:56:39 2005' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=0 perl=/usr/bin/perl Compiler: cc='gcc', ccflags=' -pipe -I/usr/local/include', Linker and Libraries: ld='gcc', ldflags=' -s -L/usr/local/lib', cc_ldflags='', libs='-lcrypt -lgmp' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 gcc -pipe -I/usr/local/include -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -Wno-shadow -falign-functions=16 -I./include -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c make -C docs make[1]: Entering directory `/usr/local/src/parrot/docs' /usr/bin/perl -e '-d or mkdir $_,0777 or die foreach @ARGV' ops make[1]: Leaving directory `/usr/local/src/parrot/docs' make -C src/dynclasses make[1]: Entering directory `/usr/local/src/parrot/src/dynclasses' gcc -s -L/usr/local/lib -shared -o match_group.dll lib-match_group.o match.o matchrange.o /usr/local/src/parrot/src/extend.o lib-match_group.o: In function `Parrot_lib_match_group_load': /usr/local/src/parrot/src/dynclasses/match_group.c:35: undefined reference to `_pmc_new' /usr/local/src/parrot/src/dynclasses/match_group.c:43: undefined reference to `_const_string' /usr/local/src/parrot/src/dynclasses/match_group.c:44: undefined reference to `_pmc_register' /usr/local/src/parrot/src/dynclasses/match_group.c:45: undefined reference to `_const_string' /usr/local/src/parrot/src/dynclasses/match_group.c:46: undefined reference to `_pmc_register' match.o: In function `make_hash_key': /usr/local/src/parrot/src/dynclasses/match.pmc:33: undefined reference to `_internal_exception' /usr/local/src/parrot/src/dynclasses/match.pmc:37: undefined reference to `_key_string' match.o: In function `match_range': /usr/local/src/parrot/src/dynclasses/match.pmc:42: undefined reference to `_const_string' /usr/local/src/parrot/src/dynclasses/match.pmc:48: undefined reference to `_hash_get_bucket' /usr/local/src/parrot/src/dynclasses/match.pmc:50: undefined reference to `_internal_exception' /usr/local/src/parrot/src/dynclasses/match.pmc:64: undefined reference to `_string_substr' match.o: In function `fetch_integer': /usr/local/src/parrot/src/dynclasses/match.pmc:80: undefined reference to `_string_to_int' [ ... more undefined references ... ] /usr/local/src/parrot/src/extend.o: In function `Parrot_new_string': /usr/local/src/parrot/src/extend.c:976: undefined reference to `_string_make' /usr/local/src/parrot/src/extend.o: In function `Parrot_register_pmc': /usr/local/src/parrot/src/extend.c:1028: undefined reference to `_dod_register_pmc' /usr/local/src/parrot/src/extend.o: In function `Parrot_unregister_pmc': /usr/local/src/parrot/src/extend.c:1054: undefined reference to `_dod_unregister_pmc' /usr/local/src/parrot/src/extend.o: In function `Parrot_get_dod_registry': /usr/local/src/parrot/src/extend.c:1064: undefined reference to `_pmc_new' /usr/local/src/parrot/src/extend.o: In function `Parrot_get_vtable': /usr/local/src/parrot/src/extend.c:1104: undefined reference to `_Parrot_base_vtables' collect2: ld returned 1 exit status partial link match_group.dll failed (256) make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/parrot/src/dynclasses' make: *** [dynclasses.dummy] Error 2
Re: the $! too global
Following the discussions from 2 weeks ago, are there any plans to update the synopsis soon regarding the $! variable? Synopsis 2 still says that it is conjectural to whether $! is always environmental. Thanks. -- Darren Duncan
