Re: [perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
On Tuesday 03 June 2008 18:19:57 James Keenan via RT wrote: > In r28055, I removed those references which either appeared in comments > or were found in the .json files. That leaves lib/Parrot/Manifest.pm > and t/distro/file_metadata.t -- which I will take a look at (though > perhaps others should glance at as well). I think it's a safe > assumption that if there are no references to 'svk' in our code base, > svk can't pose any problems for us. (Correct?) Yes. Those two references are the likely culprits for the svk initialization hang. -- c
Re: [perl #54562] [TODO] DEVELOPING should stop lagging reality
From: Geoffrey Broadwell <[EMAIL PROTECTED]> Date: Tue, 03 Jun 2008 14:21:28 -0700 OK, how about this . . . -'f Perfect. -- Bob
[perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
On Tue Jun 03 12:56:44 2008, coke wrote:
>
> (That said, didn't we already solve the svk issue elsewhere? If so, no
> harm in piggy-backing on that.)
>
After my first post this morning, I got to thinking the same thing. So
when I got home I grepped the repository for /svk/i, and came up with this:
[li11-226:parrot] 505 $ fns . | xargs grep -in svk
./tools/util/templates.json:11:Parrot, or help develop Parrot itself, we
recommend using Subversion or SVK on
./tools/util/templates.json:34:href=\"@[EMAIL PROTECTED]">Subversion
or SVK on
./tools/util/release.json:24:"svk.root" :
"http://svk.bestpractical.com/";
./tools/dev/mk_manifest_and_skip.pl:34:Recreates MANIFEST and
MANIFEST.SKIP from the svn/svk directories.
./tools/dev/mk_manifest_and_skip.pl:35:So far tested with svn 1.2.0, svn
1.4.2, and svk 1.08.
./lib/Parrot/Manifest.pm:18:cmd=> -d '.svn' ? 'svn' : 'svk',
./t/distro/file_metadata.t:35:my $cmd = -d '.svn' ? 'svn' : 'svk';
./t/distro/file_metadata.t:276:elsif ( !( (-d '.svn' && `svn info
.`) or `svk info .` ) ) {
./t/distro/file_metadata.t:284:# at a time. (do this to speed up
execution for the svn/svk commands)
./t/codingstd/gmt_utc.t:46:# trim out svn and svk Id lines
In r28055, I removed those references which either appeared in comments
or were found in the .json files. That leaves lib/Parrot/Manifest.pm
and t/distro/file_metadata.t -- which I will take a look at (though
perhaps others should glance at as well). I think it's a safe
assumption that if there are no references to 'svk' in our code base,
svk can't pose any problems for us. (Correct?)
kid51
Re: [perl #54562] [TODO] DEVELOPING should stop lagging reality
On Tue, Jun 03, 2008 at 02:21:28PM -0700, Geoffrey Broadwell wrote: > OK, how about this: > > 1. As with Bob's suggestion, DEVELOPING is reduced to just the > unchanging middle paragraph. It is then merely a flag -- removing that > function as well is better left to another RT. > > 2. The information about the next release moves to NEWS, where I think > it belongs. As soon as a release is cut and functionality starts to be > committed, we should start updating NEWS. A simple change to the format > of the header line makes it serve the duty previously done by the first > paragraph in DEVELOPING. > > See the attached patch. +1 Pm
Re: [perl #54562] [TODO] DEVELOPING should stop lagging reality
On Tue, Jun 3, 2008 at 5:21 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote: > On Mon, 2008-06-02 at 20:28 -0700, chromatic via RT wrote: >> On Monday 02 June 2008 20:05:22 Bob Rogers wrote: >> >> > Agreed, but doesn't this info really belong in README? Then DEVELOPING >> > really only needs the middle paragraph, which is unchanging, and there >> > would be one less file to have to update when cutting a new release. >> > >> >Or is there some purpose in keeping this information out of the hands >> > of mere tarball-downloaders? >> >> DEVELOPING mostly exists so that people who check out interim releases run >> extra tests by default and people who download only official releases don't. >> >> There may be a better way to accomplish this. > > OK, how about this: > > 1. As with Bob's suggestion, DEVELOPING is reduced to just the > unchanging middle paragraph. It is then merely a flag -- removing that > function as well is better left to another RT. > > 2. The information about the next release moves to NEWS, where I think > it belongs. As soon as a release is cut and functionality starts to be > committed, we should start updating NEWS. A simple change to the format > of the header line makes it serve the duty previously done by the first > paragraph in DEVELOPING. > > See the attached patch. > > > -'f > > +1 -- Will "Coke" Coleda
Re: [perl #54562] [TODO] DEVELOPING should stop lagging reality
On Tuesday 03 June 2008 14:21:28 Geoffrey Broadwell wrote: > OK, how about this: > > 1. As with Bob's suggestion, DEVELOPING is reduced to just the > unchanging middle paragraph. It is then merely a flag -- removing that > function as well is better left to another RT. > > 2. The information about the next release moves to NEWS, where I think > it belongs. As soon as a release is cut and functionality starts to be > committed, we should start updating NEWS. A simple change to the format > of the header line makes it serve the duty previously done by the first > paragraph in DEVELOPING. > > See the attached patch. +1 -- c
Re: [perl #54562] [TODO] DEVELOPING should stop lagging reality
On Mon, 2008-06-02 at 20:28 -0700, chromatic via RT wrote: > On Monday 02 June 2008 20:05:22 Bob Rogers wrote: > > > Agreed, but doesn't this info really belong in README? Then DEVELOPING > > really only needs the middle paragraph, which is unchanging, and there > > would be one less file to have to update when cutting a new release. > > > >Or is there some purpose in keeping this information out of the hands > > of mere tarball-downloaders? > > DEVELOPING mostly exists so that people who check out interim releases run > extra tests by default and people who download only official releases don't. > > There may be a better way to accomplish this. OK, how about this: 1. As with Bob's suggestion, DEVELOPING is reduced to just the unchanging middle paragraph. It is then merely a flag -- removing that function as well is better left to another RT. 2. The information about the next release moves to NEWS, where I think it belongs. As soon as a release is cut and functionality starts to be committed, we should start updating NEWS. A simple change to the format of the header line makes it serve the duty previously done by the first paragraph in DEVELOPING. See the attached patch. -'f diff --git a/DEVELOPING b/DEVELOPING index 66d50d4..b1d5aee 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -1,11 +1,5 @@ # $Id$ -THIS RELEASE: Parrot 0.6.2 2008.05.20 -PREVIOUS RELEASE: Parrot 0.6.1 2008.04.15 - -This file should only exist in development distributions. Delete it +This file should only exist in development distributions. Delete it (and its entry in the MANIFEST) before packaging Parrot up for a CPAN or other release distribution. - -'THIS RELEASE' is the goal of the current development. -'PREVIOUS RELEASE' is the release that has been last let out into the wild. diff --git a/NEWS b/NEWS index d740ad8..bb6ba56 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,12 @@ # $Id$ +New for next release (2008-06-17, version undecided) +- Configuration + + expanded step gen::opengl +- Miscellaneous + + ported OpenGL/GLU/GLUT bindings to Win32 and more Mac OS X variants + + generate OpenGL/GLU/GLUT bindings by parsing system headers + New in 0.6.2 - Specification + updated and launched pdd28_strings.pod
Re: [perl #54602] [PATCH] Several changes to allow C++ compiling
Looking more carefully at this issue, it seems that those variables
and the code that uses them has no real effect. Without it, make test
pass, make testj pass, make hello and make perl6 builds and runs.
This patch cleans all. It needs to be tested with make testj in win
32, and for completeness in other jitable platforms, but the variables
are only used in the i386 jit files. I already tested in linux i386.
--
Salu2
Index: src/exec.c
===
--- src/exec.c (revisión: 28051)
+++ src/exec.c (copia de trabajo)
@@ -62,9 +62,6 @@
int Parrot_exec_run = 0;
-extern char **Parrot_exec_rel_addr;
-extern int Parrot_exec_rel_count;
-
/*
=item C
@@ -90,7 +87,6 @@
Parrot_exec_objfile_t * const obj =
mem_allocate_zeroed_typed(Parrot_exec_objfile_t);
exec_init(obj);
-Parrot_exec_rel_addr = mem_allocate_n_zeroed_typed(4, char *);
obj->bytecode_header_size =
(interp->code->base.file_offset + 4) * sizeof (opcode_t);
jit_info = parrot_build_asm(interp, code_start, code_end,
@@ -341,10 +337,7 @@
break;
}
-if (Parrot_exec_rel_count)
-addr = Parrot_exec_rel_addr[--Parrot_exec_rel_count];
-else
-addr = nptr + disp;
+addr = nptr + disp;
new_relloc->offset= (int)(addr - obj->text.code);
new_relloc->symbol_number = symbol_number;
new_relloc->type = type;
Index: src/jit/i386/jit_emit.h
===
--- src/jit/i386/jit_emit.h (revisión: 28051)
+++ src/jit/i386/jit_emit.h (copia de trabajo)
@@ -94,19 +94,6 @@
#define ISR1 emit_EAX
#define FSR1 0
-extern char **Parrot_exec_rel_addr;
-extern int Parrot_exec_rel_count;
-
-/* Register the address of a rellocation. */
-#if EXEC_CAPABLE
-# define EXEC_RA(addr) \
- if (Parrot_exec_rel_addr) \
- Parrot_exec_rel_addr[Parrot_exec_rel_count++] = addr;
-# define EXEC_RD \
- if (Parrot_exec_rel_addr && Parrot_exec_rel_count) \
- Parrot_exec_rel_count--;
-#endif /* EXEC_CAPABLE */
-
#define emit_b00 0
#define emit_b01 1
#define emit_b10 2
@@ -170,9 +157,6 @@
}
else {
*(long *)pc = disp;
-#if EXEC_CAPABLE
-EXEC_RA(pc);
-#endif /* EXEC_CAPABLE */
return pc + 4;
}
}
@@ -240,9 +224,6 @@
if (!base && !(i && scale)) {
*(pc++) = (char)(emit_Mod_b00 | reg_opcode | emit_rm_b101);
*(long *)pc = disp;
-#if EXEC_CAPABLE
-EXEC_RA(pc);
-#endif /* EXEC_CAPABLE */
return pc + 4;
}
@@ -371,7 +352,6 @@
*(pc++) = (char) 0xff; \
*(pc++) = (char) 0x35; \
*(long *)pc = (long)mem; \
- EXEC_RA(pc); \
(pc) += 4; }
#else /* EXEC_CAPABLE */
# define emitm_pushl_m(pc, mem) { \
@@ -1353,7 +1333,7 @@
# define emitm_callm(pc, b, i, s, d) { \
*((pc)++) = (char) 0xff; \
(pc) = emit_r_X(interp, pc, emit_reg(emit_b010), b, i, s, d);\
- EXEC_RD }
+ }
#else /* EXEC_CAPABLE */
# define emitm_callm(pc, b, i, s, d) { \
*((pc)++) = (char) 0xff; \
@@ -1376,7 +1356,7 @@
# define emitm_jumpm(pc, b, i, s, d) { \
*((pc)++) = (char) 0xff; \
(pc) = emit_r_X(interp, pc, emit_reg(emit_b100), b, i, s, d); \
- EXEC_RD }
+ }
#else /* EXEC_CAPABLE */
# define emitm_jumpm(pc, b, i, s, d) { \
*((pc)++) = (char) 0xff; \
Index: src/jit/i386/exec_dep.c
===
--- src/jit/i386/exec_dep.c (revisión: 28051)
+++ src/jit/i386/exec_dep.c (copia de trabajo)
@@ -32,8 +32,6 @@
jit_info->optimizer->cur_section;
int i, j, last_is_branch = 0;
void ** offset;
-extern char **Parrot_exec_rel_addr;
-extern int Parrot_exec_rel_count;
assert(op_jit[*jit_info->cur_op].extcall == 1);
if (cur_section->done == 1)
Index: src/jit.c
===
--- src/jit.c (revisión: 28051)
+++ src/jit.c (copia de trabajo)
@@ -48,9 +48,6 @@
void Parrot_jit_debug(PARROT_INTERP);
#endif
-char **Parrot_exec_rel_addr;
-int Parrot_exec_rel_count;
-
/*
=item Coptimizer->map_branch[jit_info->op_i + (i)]
#endif
-extern char **Parrot_exec_rel_addr;
-extern int Parrot_exec_rel_count;
-
#define ROFFS_INT(x) REG_OFFS_INT(jit_info->cur_op[x])
#define ROFFS_NUM(x) REG_OFFS_NUM(jit_info->cur_op[x])
#define ROFFS_STR(x) REG_OFFS_STR(jit_info->cur_op[x])
Re: Release Managers needed
On Thu, May 22, 2008 at 11:07 PM, Will Coleda <[EMAIL PROTECTED]> wrote: > We are down to one more scheduled release next month by Smash, and > need to refresh our list of pending volunteers. > > Anyone with a commit bit and a PAUSE id can do it (easy enough to get > if you don't have one), and of course repeat volunteers are welcome. > > I'd like to get managers scheduled at least out through the end of > this year, possibly beyond if we get more than six volunteers. > > Respond privately, along with a list of good and or bad months for you > if you're interested. Third tuesday of each month, the work required > is listed in docs/project/release_manager_guide.pod > > Thanks! > > -- > Will "Coke" Coleda > Thank you to everyone that volunteered; here's the list through the end of 2008. - June 17th, 2008 - Nuno Carvalho - July 15th, 2008 - Bernhard Schmalhofer - August 19th, 2008- Bob Rogers - September 16th, 2008 - Patrick R. Michaud - October 21st, 2008 - Jerry Gay - November 18th, 2008 - chromatic - December 16th, 2008 - Andrew Whitworth Many repeat customers, and one newbie; Presuming I haven't slotted him in during finals week, hopefully Andrew will be ready to cut a release in December. (If I have, we can always rotate him.) I believe I've accommodated everyone's schedules. If not, we can juggle things around, no problem. Regards. -- Will "Coke" Coleda
Re: [perl #55244] [BUG] Configure.pl TEMP_exec_dep warning
On Tuesday 03 June 2008 13:09:39 Will Coleda wrote: > Remove the comma before the last fat arrow, and it works, yes. > > (Otherwise you introduce a different warning.) Wow. Nice typo. Applied in r28052. -- c
Re: [perl #55244] [BUG] Configure.pl TEMP_exec_dep warning
On Tue, Jun 3, 2008 at 3:55 PM, chromatic via RT <[EMAIL PROTECTED]> wrote: > On Tuesday 03 June 2008 12:40:08 Will Coleda wrote: > >> on OS X 10.4, intel, r28051, with a realclean and no options to >> Configure.pl: >> >> >> >> Generating makefiles and other build files...value for 'TEMP_exec_dep' >> in config/gen/makefiles/root.in is undef at >> lib/Parrot/Configure/Compiler.pm line 400, <$in> line 1228. >> .done. >> Moving platform files into place..done. >> Recording configuration data for later retrieval..done. >> Okay, we're done! >> >> You can now use `make' to build your Parrot. >> After that, you can use `make test' to run the test suite. > > Does this patch fix it? Note that you have to run Configure.pl again. > > -- c Remove the comma before the last fat arrow, and it works, yes. (Otherwise you introduce a different warning.) Regards. -- Will "Coke" Coleda
Re: [perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
On Tuesday 03 June 2008 12:49:38 James Keenan via RT wrote:
> > If I understand Arcady's and Will's posts earlier in this thread, we
> > need to prevent Configure.pl from hanging up when it encounters SVK on a
> > particular box where that SVK has never been run before.
> >
> > So I suspect we'll have to simulate the restoration of SVK virginity and
> > then guarantee that Configure.pl does not get so flustered by that that
> > it hangs up.
I wonder if setting the SVKROOT environment variable to something unlikely
would help simulate this.
$ENV{SVKROOT} = 'you must be kidding me';
-- c
Re: [perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
On Tue, Jun 3, 2008 at 3:49 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > For got to cc the list >> > >> >> If I understand Arcady's and Will's posts earlier in this thread, we >> need to prevent Configure.pl from hanging up when it encounters SVK on a >> particular box where that SVK has never been run before. >> >> So I suspect we'll have to simulate the restoration of SVK virginity and >> then guarantee that Configure.pl does not get so flustered by that that >> it hangs up. >> >> kid51 We could also drop support for doing a check with any version control systems other than subversion. (Another note that probably belongs on another ticket: just because we have an svn repository doesn't mean we have an svn binary: see tortoiseSVN on windows.). I would prefer to keep our infrastructure geared towards the one version control system we *have* to support; There's no problem with folks using other front ends to the system, of course, but it's all subversion in the end. (That said, didn't we already solve the svk issue elsewhere? If so, no harm in piggy-backing on that.) -- Will "Coke" Coleda
Re: [perl #55244] [BUG] Configure.pl TEMP_exec_dep warning
On Tuesday 03 June 2008 12:40:08 Will Coleda wrote:
> on OS X 10.4, intel, r28051, with a realclean and no options to
> Configure.pl:
>
>
>
> Generating makefiles and other build files...value for 'TEMP_exec_dep'
> in config/gen/makefiles/root.in is undef at
> lib/Parrot/Configure/Compiler.pm line 400, <$in> line 1228.
> .done.
> Moving platform files into place..done.
> Recording configuration data for later retrieval..done.
> Okay, we're done!
>
> You can now use `make' to build your Parrot.
> After that, you can use `make test' to run the test suite.
Does this patch fix it? Note that you have to run Configure.pl again.
-- c
=== config/auto/jit.pm
==
--- config/auto/jit.pm (revision 28058)
+++ config/auto/jit.pm (local)
@@ -1,4 +1,4 @@
-# Copyright (C) 2001-2007, The Perl Foundation.
+# Copyright (C) 2001-2008, The Perl Foundation.
# $Id$
=head1 NAME
@@ -167,16 +167,17 @@
}
else {
$conf->data->set(
-jitarchname => 'nojit',
-jitcpuarch => $cpuarch,
-jitcpu => $cpuarch,
-jitosname => $osname,
-jitcapable => 0,
-execcapable => 0,
-cc_hasjit => '',
-TEMP_jit_o => '',
-TEMP_exec_h => '',
-TEMP_exec_o => ''
+jitarchname=> 'nojit',
+jitcpuarch => $cpuarch,
+jitcpu => $cpuarch,
+jitosname => $osname,
+jitcapable => 0,
+execcapable=> 0,
+cc_hasjit => '',
+TEMP_jit_o => '',
+TEMP_exec_h=> '',
+TEMP_exec_o=> '',
+TEMP_exec_dep, => '',
);
}
[perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
For got to cc the list > > > > If I understand Arcady's and Will's posts earlier in this thread, we > need to prevent Configure.pl from hanging up when it encounters SVK on a > particular box where that SVK has never been run before. > > So I suspect we'll have to simulate the restoration of SVK virginity and > then guarantee that Configure.pl does not get so flustered by that that > it hangs up. > > kid51
Re: [perl #55238] [BUG] OpenGL breaks the build
On Tue, Jun 3, 2008 at 2:54 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote: > On Tue, 2008-06-03 at 08:33 -0700, Will Coleda wrote: >> # New Ticket Created by Will Coleda >> # Please include the string: [perl #55238] >> # in the subject line of all future correspondence about this issue. >> # http://rt.perl.org/rt3/Ticket/Display.html?id=55238 > >> >> >> ./parrot -o runtime/parrot/library/OpenGL.pbc >> runtime/parrot/library/OpenGL.pir >> error:imcc:No such file or directory >> in file 'runtime/parrot/library/OpenGL.pir' line 79 >> make: *** [runtime/parrot/library/OpenGL.pbc] Error 2 >> >> The offending line is shown below: >> >> 76 >> 77 .namespace ['OpenGL'] >> 78 >> 79 .include 'library/OpenGL_funcs.pir' >> 80 >> 81 >> 82 =item _opengl_init() >> >> "OpenGL_funcs.pir'" doesn't appear to be in the repository, so when we >> try to build it, it dies. >> >> svn blame says. >> >> 27975 japhb .include 'library/OpenGL_funcs.pir' >> >> Regards. > > That file is generated during Configure.pl (by config/gen/opengl.pm). I > have a pending question out asking what the right place is to add > makefile dependencies for libraries in runtime/parrot/library/ (because > most of them contain at least dependencies on generated files in > runtime/parrot/include that as far as I can tell we don't enforce). > Unfortunately, each time I've asked, I've been Warnocked. Build dependencies _must_ be listed in the makefile; we need more deps here, not fewer. Are you asking where in root.in they should go? doesn't matter, carve out a section. ^_^ (Please take the rest of this as a documentation of a rant which is not specifically directed at you. Some enterprising person could probably break this up into an RT or two =-) We have a few kinds of generated files at the moment: 1) generated by normal config 2) generated by config with special maintainer options 3) generated by some funky command line that isn't part of the build and you have to remember when to run it. (like when adding/deleting opcodes) 4) generated during the build process. Step 3 should go away, and either become part of step 2, or step 4, depending on if a non-standard tool is required. Step 2 can go away and be replaced by a clever config option that detects whether or not you have the tools installed. If not, then you get "touch" and a warning. Everything still depends on each other, but if you don't have the tool, you can't rebuild the file. (In fact, we might want to replace this by a failure, not a touch: if you change a file that generated files depend on and you can't update the generated (checked in) files, you shouldn't be editing that file in the first place, now should you?) Additionally, there are some files (e.g. Parrot::Config) which are smart enough to at least complain if they need configure to be run and it hasn't. Sadly, none of this addresses the issue you present here, which is: how could I have avoided a realclean after this update. Unifying the build process is is going to involve a revamp of config, however, which is a whole can of worms I'm trying to avoid just this second. In the mean time, we can at least reduce the kinds of generated files we have by half by cutting out types 2 & 3 above. A good intermediate step would be to create a dependency for config-generated files that stopped the build with the message "You must re-Configure parrot to generate this file."; If we ever have the ability to generate that file as the type 4 files above, we can just change the build step there to actually gen the file instead of complaining. > There is, however, another problem here. I'm not sure how you ended up > *not* having an OpenGL_funcs.pir when you went to make. Because I did an update and then a make. I typically fallback and do a realclean and rebuild, but apparently did not in this case. So, your patch here was just fine, as far as we do things today, but I hope we can find a way to do better. =-) Feel free to resolve the ticket. > According to > config/gen/makefiles/root.in , OpenGL_funcs.pir is conditioned on > has_opengl and included in GEN_PASM_INCLUDES, which is part of > CONFIGURE_GENERATED_FILES, which should *not* be removed on 'make > clean', only on 'make realclean'. And the latter requires a 'perl > Configure.pl' afterwards, which regenerates that file! > > In the mean time, a 'make realclean; perl Configure.pl; make' ought to > fix it for you. But I still want to know how you ended up ready to make > without having that file. > > > -'f -- Will "Coke" Coleda
[perl #55244] [BUG] Configure.pl TEMP_exec_dep warning
# New Ticket Created by Will Coleda # Please include the string: [perl #55244] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55244 > on OS X 10.4, intel, r28051, with a realclean and no options to Configure.pl: Generating makefiles and other build files...value for 'TEMP_exec_dep' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Compiler.pm line 400, <$in> line 1228. .done. Moving platform files into place..done. Recording configuration data for later retrieval..done. Okay, we're done! You can now use `make' to build your Parrot. After that, you can use `make test' to run the test suite. Happy Hacking, The Parrot Team -- Will "Coke" Coleda
Re: [perl #55238] [BUG] OpenGL breaks the build
On Tue, 2008-06-03 at 08:33 -0700, Will Coleda wrote: > # New Ticket Created by Will Coleda > # Please include the string: [perl #55238] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=55238 > > > > ./parrot -o runtime/parrot/library/OpenGL.pbc > runtime/parrot/library/OpenGL.pir > error:imcc:No such file or directory > in file 'runtime/parrot/library/OpenGL.pir' line 79 > make: *** [runtime/parrot/library/OpenGL.pbc] Error 2 > > The offending line is shown below: > > 76 > 77 .namespace ['OpenGL'] > 78 > 79 .include 'library/OpenGL_funcs.pir' > 80 > 81 > 82 =item _opengl_init() > > "OpenGL_funcs.pir'" doesn't appear to be in the repository, so when we > try to build it, it dies. > > svn blame says. > > 27975 japhb .include 'library/OpenGL_funcs.pir' > > Regards. That file is generated during Configure.pl (by config/gen/opengl.pm). I have a pending question out asking what the right place is to add makefile dependencies for libraries in runtime/parrot/library/ (because most of them contain at least dependencies on generated files in runtime/parrot/include that as far as I can tell we don't enforce). Unfortunately, each time I've asked, I've been Warnocked. There is, however, another problem here. I'm not sure how you ended up *not* having an OpenGL_funcs.pir when you went to make. According to config/gen/makefiles/root.in , OpenGL_funcs.pir is conditioned on has_opengl and included in GEN_PASM_INCLUDES, which is part of CONFIGURE_GENERATED_FILES, which should *not* be removed on 'make clean', only on 'make realclean'. And the latter requires a 'perl Configure.pl' afterwards, which regenerates that file! In the mean time, a 'make realclean; perl Configure.pl; make' ought to fix it for you. But I still want to know how you ended up ready to make without having that file. -'f
Re: [perl #55000] [PATCH] Threads Failures on Optimized Build
On Tuesday 03 June 2008 10:50:27 NotFound via RT wrote:
> On Sun, Jun 1, 2008 at 1:31 PM, Vasily Chekalkin <[EMAIL PROTECTED]> wrote:
> > interp->exceptions initialized lazily. But really_destroy_exception have
> > signature with __attribute_notnull__. So we should either check this
> > value before function call or change function signature to accepts NULL.
>
> I tried this variant:
>
> --- src/exceptions.c(revisión: 28050)
> +++ src/exceptions.c(copia de trabajo)
> @@ -772,8 +772,10 @@
> void
> destroy_exception_list(PARROT_INTERP)
> {
> -really_destroy_exception_list(interp->exceptions);
> -really_destroy_exception_list(interp->exc_free_list);
> +if (interp->exceptions)
> +really_destroy_exception_list(interp->exceptions);
> +if (interp->exc_free_list)
> +really_destroy_exception_list(interp->exc_free_list);
> }
>
> /*
>
> In my platform, Ubuntu 8.04 i386, solves both this problem and #55170
>
> The diagnostic is the same, the root of the problem is to pass null to
> a parameter attributed as non null.
>
> (Optionally add several rants about premature optimization here).
Agreed, and applied as r28051. Thanks, everyone!
-- c
Re: [perl #55170] [BUG] "make perl6" fails with an optimized parrot
On Sunday 01 June 2008 16:24:37 Andrew Whitworth wrote: > I'm not sure if this issue has been brought up before, and I'm also > not sure if it's related to "#55000 Threads Failures on Optimized > Build". > > I run this script on Debian with GCC 4.2.3: > > make realclean > perl Configure.pl --optimize && make && make perl6 > > I built again without --optimize and it works perfectly. I'm doing > another optimized build now to get the log entries (i didn't copy them > the first time like i should have). Parrot builds optimized, although > it fails some threading tests as chromatic points out in #55000. The > perl6 executable does not. I'll post more information in a follow-up. Definitely related to RT #55000, and fixed in r28051. -- c
Re: [svn:parrot] r28038 - in branches/gsoc_pdd09: include/parrot src/gc
On Monday 02 June 2008 13:10:32 [EMAIL PROTECTED] wrote: > +/* > + * 2) Mark root items as grey > + * I don't currently know how to determine which items are root. However, > + * When we find them, we can mark them > + */ The existing GC systems all start with interp->iglobals. Note that this doesn't scan the C stack or CPU registers for live entities. > +#define GC_IT_NEED_TA_DO_DA_BREAK(x) ((x)->break) Every time you mark one entity as black, you could do this break. You don't want to break any more frequently (though you might want to break less frequently). -- c
[perl #55000] [PATCH] Threads Failures on Optimized Build
On Sun, Jun 1, 2008 at 1:31 PM, Vasily Chekalkin <[EMAIL PROTECTED]> wrote:
> interp->exceptions initialized lazily. But really_destroy_exception have
> signature with __attribute_notnull__. So we should either check this value
> before function call or change function signature to accepts NULL.
I tried this variant:
--- src/exceptions.c(revisión: 28050)
+++ src/exceptions.c(copia de trabajo)
@@ -772,8 +772,10 @@
void
destroy_exception_list(PARROT_INTERP)
{
-really_destroy_exception_list(interp->exceptions);
-really_destroy_exception_list(interp->exc_free_list);
+if (interp->exceptions)
+really_destroy_exception_list(interp->exceptions);
+if (interp->exc_free_list)
+really_destroy_exception_list(interp->exc_free_list);
}
/*
In my platform, Ubuntu 8.04 i386, solves both this problem and #55170
The diagnostic is the same, the root of the problem is to pass null to
a parameter attributed as non null.
(Optionally add several rants about premature optimization here).
--
Salu2
Index: src/exceptions.c
===
--- src/exceptions.c (revisión: 28050)
+++ src/exceptions.c (copia de trabajo)
@@ -772,8 +772,10 @@
void
destroy_exception_list(PARROT_INTERP)
{
-really_destroy_exception_list(interp->exceptions);
-really_destroy_exception_list(interp->exc_free_list);
+if (interp->exceptions)
+really_destroy_exception_list(interp->exceptions);
+if (interp->exc_free_list)
+really_destroy_exception_list(interp->exc_free_list);
}
/*
Re: [perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
Using parrot 0.6.2 on 10.5.3, make now builds and I can run the tests. So for the newest versions of parrot and the OS, the problem is fixed. Jim Simon Cozens wrote: Sure, what do you need me to do? S Sent from my iPod On 3 Jun 2008, at 23:46, "James Keenan via RT" <[EMAIL PROTECTED]> wrote: Resolution of this ticket appears to depend on having Mac OS X 10.5 (whether on ppc or on intel). Is there anyone who can volunteer to work on this? Thank you very much. kid51 -- Jim Brandt Administrative Computing Services University at Buffalo
[perl #55238] [BUG] OpenGL breaks the build
# New Ticket Created by Will Coleda # Please include the string: [perl #55238] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55238 > ./parrot -o runtime/parrot/library/OpenGL.pbc runtime/parrot/library/OpenGL.pir error:imcc:No such file or directory in file 'runtime/parrot/library/OpenGL.pir' line 79 make: *** [runtime/parrot/library/OpenGL.pbc] Error 2 The offending line is shown below: 76 77 .namespace ['OpenGL'] 78 79 .include 'library/OpenGL_funcs.pir' 80 81 82 =item _opengl_init() "OpenGL_funcs.pir'" doesn't appear to be in the repository, so when we try to build it, it dies. svn blame says. 27975 japhb .include 'library/OpenGL_funcs.pir' Regards. -- Will "Coke" Coleda
Re: [perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
Sure, what do you need me to do? S Sent from my iPod On 3 Jun 2008, at 23:46, "James Keenan via RT" <[EMAIL PROTECTED] > wrote: Resolution of this ticket appears to depend on having Mac OS X 10.5 (whether on ppc or on intel). Is there anyone who can volunteer to work on this? Thank you very much. kid51
Re: [perl #49226] [BUG] 'make pbc_to_c' fails on Intel Mac
On Tue, Jun 3, 2008 at 11:03 AM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > Ovid, > > If I understand correctly the issues you raised in the OP, you were > attempting to build a Perl 6 binary on an Intel Mac (10.4? 10.5?). > Either the instructions weren't clear or it was a genuine problem on > that OS. > > I suspect that over the past months any such problem has cleared up in > the course of other fixes -- but since I don't have an Intel Mac, I > can't confirm it myself. > > Could you give it another try and report if you are still unable to get > that binary? > > Thank you very much. > kid51 > FYI, I have no problems with this on a 10.4 OS X/intel box. -- Will "Coke" Coleda
[perl #49226] [BUG] 'make pbc_to_c' fails on Intel Mac
Ovid, If I understand correctly the issues you raised in the OP, you were attempting to build a Perl 6 binary on an Intel Mac (10.4? 10.5?). Either the instructions weren't clear or it was a genuine problem on that OS. I suspect that over the past months any such problem has cleared up in the course of other fixes -- but since I don't have an Intel Mac, I can't confirm it myself. Could you give it another try and report if you are still unable to get that binary? Thank you very much. kid51
[perl #49762] parrot 0.5.2 make fails on mac ppc with leopard 10.5.1
Resolution of this ticket appears to depend on having Mac OS X 10.5 (whether on ppc or on intel). Is there anyone who can volunteer to work on this? Thank you very much. kid51
[perl #52898] build on an macosx 10.5.2
Stéphane, Have we resolved all the issues in this ticket? (If so, I'll mark it resolved.) Thank you very much.
Re: building pugs under Fedora 9 doesn't work
Ryan Richter wrote: > On Tue, Jun 03, 2008 at 12:03:00PM +0200, Moritz Lenz wrote: >> My last successful build was r18093 with GHC 6.6.1. >> Maybe we should just die in Makefile.PL until somebody finds a fix. > > Maybe we should just revert the pugs source to that rev. Haven't the > modifications since then basically just broken the build for most > people? They were an attempt to get it working under ghc 6.8.1. As long as pugs isn't actively developed, the question is mostly irrelevant. Yet feel free to revert the changes to pugs, unless somebody vetoes. (But please don't blindly revert any commit in the meantime, there were other non-pugs changes to the repo that many hackers would hate you for reverting ;-) Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: building pugs under Fedora 9 doesn't work
On Tue, Jun 03, 2008 at 12:03:00PM +0200, Moritz Lenz wrote: > My last successful build was r18093 with GHC 6.6.1. > Maybe we should just die in Makefile.PL until somebody finds a fix. Maybe we should just revert the pugs source to that rev. Haven't the modifications since then basically just broken the build for most people? -ryan
[perl #55228] [BUG] Configuration problem with GLUT on macintel leopard
# New Ticket Created by Stephane Payrard # Please include the string: [perl #55228] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55228 > This bug appeared very recently (less than 3 days ago). I did "make realclean". Below the relevant part of Configure.PL logs : Determining if your platform supports OpenGLyes, MacOSX_GLUT 5. ... Generating OpenGL bindings... step gen::opengl died during execution: 'GLEW_VERSION_1_1' is defined as 'GLEW_GET_VAR(__GLEW_VERSION_1_1)', but no 'GLEW_GET_VAR(__GLEW_VERSION_1_1)' has been defined at config/gen/opengl.pm line 420. at Configure.pl line 66 -- cognominal stef
Re: Fatal/autodie exception hierarchies for Perl 5
G'day Larry / p6l / p5p,
Larry Wall wrote:
One little problem at the outset here is that Perl 6 has almost no
concept of "built-in" or "CORE", except insofar as the Prelude happens
to choose to import certain subs into the user's scope by default.
Once you actually start parsing and calling functions, there is
no distinction at all between different versions of "open", say.
I think that chromatic's suggestion of roles is an excellent one. In P5 we
certainly do have a concept of built-in (core) functions, and if nothing
else autodie uses this internally to work its dark magicks.
In P6, I imagine we can just drop the the core and user roles, leaving the
other roles intact.
Originally, my plan was for the vanilla autodie:
use autodie;
to enable autodie for all core functions in scope. However I think that
having a 'default' role makes quite a lot of sense. User-defined
subroutines can register themselves with the default role, so a vanilla
autodie can enable Klingon semantics[1] for whatever system is being used at
the time.
Currently, when testing exceptions from autodie, we can use:
given ($@) {
when (undef) { say "No errors here" }
when ('open') { say "Open died" }
when (':file') { say "Some sort of file error" }
>> ...
}
That may be what we have to do for Perl 5, but from the Perl 6
viewpoint it's duplicating information that should derive directly from
the type and introspection systems.
For the following discussion, I fear I'm bumping my head on the low ceiling
of my P6 knowledge, so I apologise in advance for my ignorance.
The autodie exceptions are real objects, which do contain an awful lot of
information about what went wrong, including the failed subroutine, where it
was called from, what arguments were involved, and so on. They just happen
to smart-match against our roles, since those are things that are likely to
be commonly checked.
However I suspect this is a very different system to what's intended for P6
given the next paragraph:
> For instance, functions are real objects in P6,
> and can have other methods than just the "invoke" method. If you want
> to tell a function how to behave, you might just talk to it directly...
So could I theoretically say (in pidgin P6):
open.on_fail(try_the_other_drive);
print.on_fail(panic);
system.on_fail(wake_sysadmin_from_slumber);
That certainly has a lot of value when thinking about parallel processing,
since errors can be handled in-situ, ignored, or handled later when the data
is collated or used.
However there's still a number of quite concrete current-day examples where
the traditional try/catch paradigm provides excellent value. The classic is
a single-threaded sysadmin task:
try {
mount_tapes;
check_tape_labels;
backup_files;
delete_old_files;
}
catch {
wake_sysadmin_from_slumber;
}
finally {
unmount_tapes;
}
Here if any part of our try fails, then we immediately want to stop what
we're doing, rather than overwriting the wrong tape, or deleting files we
didn't successfully back-up. I trust these sorts of exceptions will still
be around in P6?
That's because it would be S33, which hasn't been written yet... :)
Oh good, my searching skills aren't completely dead then.
[snips]
As chromatic suggested, it would be good to use some kind of role-ish
mixin idea (with or without Moose) instead of hierarchies of strings.
Given my ignorance of Moose, and my desire for autodie to be a candidate for
inclusion in the P5 core, I was intending autodie to be orthogonal to Moose.
Of course I'm happy for there to be hooks which Moose may find useful.
I do very much like the idea of roles, they're going to be quite useful.
Mixins I haven't even considered. I'll make sure there's a sane way to use
them, but the ones provided with standard autodie will probably be quite
lightweight.
I dunno--you're dragging us back down from the stratosphere of theory
to the troposphere of practice.
I don't expect we can keep things entirely lined up, but it would
be nice to avoid gratuitous divergence if we can.
I'm not sure actually sure if we've avoided divergence yet, but unless
there's any barotrauma due to the sudden change in pressure, I'll continue
to throw autodie exception-related plans to p6l as they happen. ;)
All the best,
Paul
[1] Klingon semantics: It is better to die() in the attempt than to return()
in failure. I'll buy a beverage for whomever can help me translate that
back into Klingon in time for OSCON. ;)
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681
Re: The Inf type
HaloO,
John M. Dlugosz wrote:
I don't know why he's calling it an "Int with non-uniform spacing"
unless he is complaining about what happens when you store ints in
floats: it rounds off to the mantissa size.
With uniform spacing you have
constant $step = 1;
and
$x++; # means $x = $x + $step
whereas non-uniform is
$x++; # means $x = $x + $x.step;
You can make the second to subsume the first with
multi method *step (Int) { 1 }
and optimize whenever you can prove that $x always
does Int. If you can't, you leave that to the runtime.
Going further with that you could define $a == $b to
actually mean abs($a-$b) < min($a.step, $b.step).
E.g. with the usual 64bit floats you have 0.5.step==2**-53
and (2**52).step==1. Then per definition
multi method *step (Real) { 0 }
essentially means a real object can't step away from itself
or some such.
Given the above, the optimizer can e.g. take a sub that claims to
achieve its business with two Reals in such a way that ++ is
considered a noop and taken out of the code. If the code is not
up to that it can hardly be a function that properly handles two
Reals. If your test suite manages to detect that failure is another
question. But a good enough optimizer makes bad enough programs
reveal their realness or lack thereof ;)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: building pugs under Fedora 9 doesn't work
Hi, Gerd Pokorra wrote: > building pugs under Fedora 9 doesn't work. With every revision I get the > following error by executing the command "make": ... > Generating precompiled Prelude, Math::Basic... pugs: Internal error: > Invalid grammatical category: "Bool" > Please file a bug report This is a known issue, and nobody really knows what to do about it. Pugs isn't actively developed at the moment. My last successful build was r18093 with GHC 6.6.1. Maybe we should just die in Makefile.PL until somebody finds a fix. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP digital signature
Re: The Inf type
On 2008 Jun 3, at 4:19, John M. Dlugosz wrote: Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: e . Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. Yes. If you look at my specdoc, the ideas I've identified thus far are basically driven by which functions are sensible on which types. The basic math functions basically define the "which functions are sensible on which types" is exactly where Haskell is messed up; basically, what makes sense varies according to whose notion of what a given numeric type is. Are you thinking in terms of what current machines do natively? In terms of set theory (a popular alternative among Haskell-folk)? In terms of what most people consider sensible (if you can in fact nail that particular bit of jelly down; OTOH, it may be the most "Perlish" way of doing it)? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: The Inf type
HaloO,
Mark J. Reed wrote:
In what the heck mathematical world is the square root of two an
infinite value? Irrationality and infinitude are not the same thing;
in particular, there are an (uncountably) infinite number of
irrational numbers...
I don't know what you accept as an infinity but there is e.g.
an infinite set of complex numbers
subset InfSqrt2 of Complex where { $_ ** sqrt(2) == 1 }
whereas
subset Inf141 of Complex where { $_ ** 1409/997 == 1 }
# 1409/997 approx 1.41
only has 1404773 entries. That is one way to transform the infinity
of an irrational number into an infinite set. Rationals only render
infinities of the kind a circle has, where you can run in one direction
without reaching an end.
Or take the tan function that can be used to wrap the real number line
around a circle at Zero. Then you get a point Inf on "the other side" of
Zero that just behaves like Zero, i.e. on one side you have all the
positive reals and on the other all the negative ones. So you can make
the transition from +Inf to -Inf just as easily as from +0 to -0. IOW,
there are properties that are usually ascribed to Zero that Inf can
claim as well. For that very reason I gave here, IEEE-754 distinguishes
-0 and +0 just like it distinguishes -Inf and +Inf. And there are
contexts where -Inf === +Inf makes sense just as -0 === +0 makes sense
and some where it doesn't. Now, how are these contexts distinguished?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
building pugs under Fedora 9 doesn't work
Hello, building pugs under Fedora 9 doesn't work. With every revision I get the following error by executing the command "make": Gerd Pokorra [EMAIL PROTECTED] pugs]$ make . . . [1 of 1] Compiling Main ( src/Main.hs, src/Main.o ) Linking pugs.new ... /usr/bin/perl util/gen_prelude.pl -v -i src/perl6/Prelude.pm -i ext/Math-Basic/lib/Math/Basic.pm -p ./pugs --output blib6/lib/Prelude.pm.yml # ./pugs -Iext/Math-Basic/lib -C Parse-YAML Prelude.pm > # blib6/lib/Prelude.pm.yml Generating precompiled Prelude, Math::Basic... pugs: Internal error: Invalid grammatical category: "Bool" Please file a bug report. Output is empty at util/gen_prelude.pl line 189. system: [/usr/bin/perl util/gen_prelude.pl -v -i src/perl6/Prelude.pm -i ext/Math-Basic/lib/Math/Basic.pm -p ./pugs --output blib6/lib/Prelude.pm.yml]: at util/build_pugs.pl line 600. make: *** [pugs] Fehler 1 [EMAIL PROTECTED] pugs]$ [EMAIL PROTECTED] pugs]$ ./pugs __ /\ __ \ \ \ \/\ \ __ __ __ __ (P)erl 6 \ \ __//\ \/\ \/\ __ \/\ ___\(U)ser's \ \ \/ \ \ \_\ \ \ \/\ \ \___ \ (G)olfing \ \__\ \ \/\ \ \/\_\ (S)ystem \/__/ \/___/ \/___/\ \// /\/ Version: 6.2.13 (r20630) \/___/Copyright 2005-2007, The Pugs Contributors Web: http://pugscode.org/ Email: [EMAIL PROTECTED] Welcome to Pugs -- Perl6 User's Golfing System Type :h for help. pugs: Internal error: Invalid grammatical category: "Bool" Please file a bug report. [EMAIL PROTECTED] pugs]$
[perl #55220] [PATCH] expands the file "parrot.spec" to build languages
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #55220] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55220 > Hello, this patch for the file "parrot.spec" add the two commands: make languages make perl6 to the build part and put this files to the package "parrot-languages". So the package "parrot-languages" will also hold the executable "/usr/bin/perl6". Perhaps someone will add a better description for the "languages" package. Gerd Pokorra patch.tar Description: Unix tar archive
[perl #54148] [NEW] Add tools/util/dump-pbc.pl (weave PIR source and PBC disassembly)
> > The previous version of the patch didn't work on Windows, because pipe > open doesn't work there, grrr. Please try the attached version of the > patch. > It looks like the current version of the patch has been applied. In r28039 I added a sanity test in the new file t/tools/dump_pbc.pl. If that works across platforms, I propose to close this ticket. -- /* [EMAIL PROTECTED] */
RE: assignable mutators (S06/Lvalue subroutines)
> If a routine is rw, you may optionally define a single "slurpy scalar" > (e.g., '*$value') in its signature. A good start, but why limit the Lvalue to a scalar? A list l-value seems like a pretty useful thing to me. -Martin --- Have you seen our website? http://www.vodafone.co.nz Manage Your Account, check your Vodafone Mail and send web2TXT online: http://www.vodafone.co.nz/myvodafone CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030 Telephone + 64 9 355 2000 Facsimile + 64 9 355 2001
Re: [perl #55196] 'print' and 'say' format a number register differently
On Mon, 2008-06-02 at 12:27 -0700, Bernhard Schmalhofer wrote: > [EMAIL PROTECTED]:~/devel/Parrot/trunk$ ./parrot t.pir > 3.14159 > 3.141590 > > Why should 'print' print trailing a '0' and 'say' not? default rounding length? sub main $N0 = 3.141596 ... ./parrot ../pi.pir 3.1416 3.141596 and for $N1 = 3.1415968 3.1416 3.141597 a -- Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] Voice: (608) 261-5738 Fax: 264-5932 Sent from Evolution (CentOS)!!!
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: e . Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. Yes. If you look at my specdoc, the ideas I've identified thus far are basically driven by which functions are sensible on which types. The basic math functions basically define the most primitive roles, as those are what you will be calling (and counting on being sensibly defined) when you write more complicated functions that take generic types, and gives a natural handle on how to specify which types your own function is sensible for. --John
Re: The Inf type
Brandon S. Allbery wrote: > John M. Dlugosz wrote: >> Jon Lang wrote: >>> type (i.e., 'num'). Somehow, I had got it into my head that Num was a >>> role that is done by all types that represent values on the real >>> number line, be they integers, floating-point, rationals, or >>> irrationals. And really, I'd like Num to mean that. I'd rather see >> >> Would you care to muse over that with me: what Roles should we decompose >> the various numeric classes into? Get a good list for organizing the >> standard library functions and writing good generics, and =then= argue over >> huffman encoding for the names. Call them greek things for now so we don't >> confuse anyone . > > Learn from the Haskell folks, who are still trying to untangle the mess they > made of their numeric hierarchy (see > http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. -- Jonathan "Dataweaver" Lang
Re: Fatal/autodie exception hierarchies for Perl 5
G'day chromatic / p5p / p6l, Make a list of all possible types of exceptions, define them as roles, and group them that way. Any given exception can implement multiple roles (:CORE and :io, for example, or a specialization of that role that also does :USER). Excellent point. I've been largely ignoring the user exceptions, and that they may wish to declare themselves as having an :io, :math, or similar role. So, roles are in, I'll need to provide an appropriate interface for user code to make use of them. Larry's post I'll be digesting on my trip home tonight. ;) Cheerio, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681
Re: The Inf type
On 2008 Jun 3, at 3:15, John M. Dlugosz wrote: Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: type (i.e., 'num'). Somehow, I had got it into my head that Num was a role that is done by all types that represent values on the real number line, be they integers, floating-point, rationals, or irrationals. And really, I'd like Num to mean that. I'd rather see Would you care to muse over that with me: what Roles should we decompose the various numeric classes into? Get a good list for organizing the standard library functions and writing good generics, and =then= argue over huffman encoding for the names. Call them greek things for now so we don't confuse anyone . Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion) . -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: ; I see. We just had a role-vs-class cognitive disconnect. Officially, Num is the autoboxed version of the native floating point type (i.e., 'num'). Somehow, I had got it into my head that Num was a role that is done by all types that represent values on the real number line, be they integers, floating-point, rationals, or irrationals. And really, I'd like Num to mean that. I'd rather see what is currently called 'num' and 'Num' renamed to something like 'float' and 'Float', and leave 'Num' free to mean 'any real number, regardless of how it is represented internally'. Either that, or continue to use Num as specified, but also allow it to be used as a role so that one can create alternate representations of real numbers (or various subsets thereof) that can be used anywhere that Num can be used without being locked into its specific approach to storing values. Would you care to muse over that with me: what Roles should we decompose the various numeric classes into? Get a good list for organizing the standard library functions and writing good generics, and =then= argue over huffman encoding for the names. Call them greek things for now so we don't confuse anyone . --John
Re: [perl #54930] [BUG] PGE build fails in pdd25cx branch
On Monday 02 June 2008 19:42:58 Will Coleda via RT wrote: > Error earlier in the build process now, with PGE: > > /home/coke/bin/perl -e "" >PGE/builtins_gen.pir > ../../parrot -o PGE.pbc --output-pbc PGE.pir > ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir -- > output=PGE/builtins_gen.pir PGE/builtins.pg > make: *** [PGE.pbc] Segmentation fault > > Running this last parrot invocation with -G avoids the segfault. I can't reproduce this with 32-bit x86 GNU/Linux, but I do see some segfaults in the PGE tests. -- c
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: TSa wrote: John M. Dlugosz wrote: The sqrt(2) should be a Num of 1.414213562373 with the precision of the native floating-point that runs at full speed on the platform. That makes the Num type an Int with non-uniform spacing. E.g. there are Nums where $x++ == $x. And the -Inf and +Inf were better called Min and Max respectively. IOW, the whole type based aproach to Inf is reduced to mere notational convenience. Please give an example value for a Num where $x++ == $x. Other than Inf, of course. Num is floating point. If you exceed the mantissa precision, then ++ will not change it. I don't know why he's calling it an "Int with non-uniform spacing" unless he is complaining about what happens when you store ints in floats: it rounds off to the mantissa size. --John
