[ANNOUNCE] Devel::TypeCheck 1.2
The latest release of Devel::TypeCheck adds typing of functions (without polymorphism) as well as numerous bug fixes: The uploaded file Devel-TypeCheck-1.2.tar.gz has entered CPAN as file: $CPAN/authors/id/B/BA/BARGLE/Devel-TypeCheck-1.2.tar.gz size: 37304 bytes md5: 04369069c2a307c85bbe54ee5a267c9b -- Gary
Changing argv to be a ResizableStringArray complications
With the attached patch, which changes argv to be a ResizableStringArray instead of an SArray, when argv reaches the pir execution, four null strings are prepended to argv. Running parrot with -D8 prints the argv without those four null strings. The comment above the change indicates eventually changing it to be a ResizableStringArray, but these four null strings are an issue against that. I can't understand why it's doing that, maybe someone else can understand it. embed.patch Description: Binary data
Re: [perl #38217] r11124: Cygwin build fails
"Greg Bacon (via RT)" <[EMAIL PROTECTED]> wrote: [...] /usr/bin/perl tools/build/parrot_config_c.pl --mini > \ src/null_config.c src/null_config.c gcc -o miniparrot.exe -s -L/usr/local/lib compilers/imcc/main.o \ -L/home/gbacon/src/parrot/blib/lib -lparrot -lcrypt src/null_config.o compilers/imcc/main.o: In function `imcc_version': /home/gbacon/src/parrot/compilers/imcc/main.c:124: undefined reference to `_Parrot_revision' /home/gbacon/src/parrot/compilers/imcc/main.c:128: undefined reference to `_Parrot_config_revision' ... collect2: ld returned 1 exit status make: *** [miniparrot.exe] Error 1 Ugh. I'm currently doing a lot of stuff to get rid of .def files and replace them with decorations in the code instead. You may have got caught up in this (or maybe the changes have hurt cygwin in a way I didn't anticipate). Anyway, please grab the latest source, make realclean and have another go at building it. I've put in a whole load more changes tonight. Thanks, Jonathan
[perl #38219] [BUG] (r11026) pdb.exe build broken
# New Ticket Created by jerry gay # Please include the string: [perl #38219] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38219 > while running 'make world' for i386-win32-cl: link -out:.\pdb.exe src\pdb.obj -nologo -nodefaultlib -debug -mach ine:x86 -debug blib\lib\libparrot.lib oldnames.lib kernel32.lib user32.lib gd i32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbc cp32.lib msvcrt.lib pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_destroy refere nced in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_debug referenc ed in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_loadbc referen ced in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_readbc referen ced in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_exit reference d in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_init reference d in function _main pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_new referenced in function _main .\pdb.exe : fatal error LNK1120: 7 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. ~jerry
[perl #38221] Build fails on FreeBSD 5.4
# New Ticket Created by Joshua Isom
# Please include the string: [perl #38221]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38221 >
On FreeBSD 5.4, building parrot fails for the experimental.ops part of
core_ops_cgp.c. The gcc version is 3.4.2. Here's the output from the
compile. The last time I got a successful compile for FreeBSD was on
the 8th, but there was the shared library problem then.
src/ops/core_ops_cgp.c
src/ops/experimental.ops: In function `cgp_core':
src/ops/experimental.ops:226: error: unable to find a register to spill
in class `DIREG'
src/ops/experimental.ops:226: error: this is the insn:
(insn 27898 30731 27899 2388 src/ops/string.ops:397 (parallel [
(set (reg:SI 2 cx [8556])
(unspec:SI [
(mem:BLK (reg/f:SI 8558 [ tmp ]) [0 A8])
(reg:QI 1 dx [8560])
(const_int 1 [0x1])
(reg:SI 2 cx [8559])
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg/f:SI 8558 [ tmp ]))
(clobber (reg:CC 17 flags))
]) 453 {*strlenqi_1} (insn_list 27894 (insn_list 27895
(insn_list 27896 (insn_list 27897 (nil)
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_DEAD (reg:SI 2 cx [8559])
(expr_list:REG_DEAD (reg:QI 1 dx [8560])
(expr_list:REG_DEAD (reg/f:SI 8558 [ tmp ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg/f:SI 8558 [ tmp ])
(nil
src/ops/experimental.ops:226: confused by earlier errors, bailing out
gmake: *** [src/ops/core_ops_cgp.o] Error 1
Re: [perl #38216] [PATCH] fix parrot.pc.in
On Thu, Jan 12, 2006 at 11:11:13AM -1000, Joshua Hoblitt wrote: > On Thu, Jan 12, 2006 at 07:51:58PM +, Nick Glencross wrote: > > > It looks like only prefix is actually set, and the other paths are set > > using pkgconfig variables (which look the same as the style that we've > > just moved away from). > > > > I hope that you don't mind, but I've not used your patch per se, but > > have fixed the problem in r11128 similarly. Before closing the call, it > > might be worth checking with everyone that libdir/includedir will always > > be correct, otherwise we'll expand their paths. > > DOH! I noticed that yesterday when I was editing parrot.pc.in and > decided that I should fix it as a separate changeset. Then promptly > forgot to fix it... nice catch. OK - this issue should be fixed in r11137. Thanks for reporting. Cheers, -J -- pgpauc5c0Gb6g.pgp Description: PGP signature
Re: declaration of 'clone'
On Thu, Jan 12, 2006 at 04:53:26PM +0100, Leopold Toetsch wrote: > Klaas-Jan Stol wrote: > >Hi, > > > >I'm trying to implement some functions into the Lua PMCs, but I'm having > >trouble to compile them. > > > >I want to add a clone method to the LuaNil PMC (which should extend > >Null.pmc, not None.pmc, as it does currently; changed that already) > > > >However, I get the following error: > > > >luanil.c:343: error: conflicting types for `clone' > >/usr/include/bits/sched.h:72: error: previous declaration of `clone' > >compile luanil.c failed (256) > > clone is a standardized vtable function. But it's name is never a bare > 'clone', it's always prefixed by 'Parrot__. This is also true > for > > METHOD PMC* clone() # dunno if that works, if vtable exists > > You must have some bug in your PMC code. On Linux clone() is a syscall with a wraper function in the the standard library that is defined in sched.h. On my laptop types.h includes pthreadtypes.h which includes sched.h. You should *probably* use a different function name. ;) -J -- pgp4nRk8BaRkx.pgp Description: PGP signature
Re: [perl #38146] [TODO] OS.pmc - file copy
I'd vote for that being the default method that can be overridden on a
per platform basis with a more functional/efficient version.
-J
--
On Thu, Jan 12, 2006 at 12:07:33PM +, Alberto Manuel Brand?o Sim?es wrote:
> I'm not implementing copy at the moment as I lack knowledge. I might
> just write the default open/while(){write}/close method for cases when
> everything else fails.
>
> BTW, it will go for File.pmc accordingly with Leo.
>
> Joshua Juran wrote:
> >On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:
> >
> >>On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:
> >>
> >>>Since before System 7 (approaching two decades ago), Mac OS has had a
> >>>system call that exchanges the contents of two files. The purpose of
> >>>this call is to implement a 'safe save' strategy ...
> >>
> >>
> >>Is this still a system call in Mac OS X?
> >
> >
> >Yes, the original FSpExchangeFiles() call persists along with most of
> >the calls pertaining to FSSpecs. New code written only for Mac OS 9 and
> >above could also use the newer FSRef-based FSExchangeObjects() call
> >which subsumes it.
> >
> >Josh
> >
>
> --
> Alberto Sim?es - Departamento de Inform?tica - Universidade do Minho
> Campus de Gualtar - 4710-057 Braga - Portugal
pgpNhiAJKcDYi.pgp
Description: PGP signature
Re: Table of Perl 6 "Types"
Larry Wall skribis 2006-01-12 12:40 (-0800): > Well, it could be a lazy list that you only ever pop, I suppose. > In any event, it doesn't work syntactically because ... is where a > term is expected, so it's a yada-yada-yada with an unexpected term > following it. Why avoid having both ... and ...$foo? MMD, longest-match, ugly hacks, there's a bag full of tricks that could be used, so I gathered there must be a philosophical reason not to have this. I just can't think of any that would weigh more than having ...$foo around. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Table of Perl 6 "Types"
Larry Wall wrote: > On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote: > : The only remaining problem is that we have no syntax for ...3, which > : doesn't make sense as a list, but does make sense as a range. > > Well, it could be a lazy list that you only ever pop, I suppose. > In any event, it doesn't work syntactically because ... is where a > term is expected, so it's a yada-yada-yada with an unexpected term > following it. To bad; because that's exactly the syntax that I'd expect to use. -- Jonathan "Dataweaver" Lang
Re: [perl #38146] [TODO] OS.pmc - file copy
On Thu, Jan 12, 2006 at 06:27:11AM -0800, jerry gay wrote:
> On 1/12/06, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote:
> > I'm not implementing copy at the moment as I lack knowledge. I might
> > just write the default open/while(){write}/close method for cases when
> > everything else fails.
>
> since there seem to be non-File-specific methods destined for the File
> PMC, perhaps it could be renamed to something more appropriate, like
> FileSystem. thoughts?
I think getting away from "File" is good. By analogy with "OS", for
convenience, and in keeping with common usage, I like "FS". Today,
anyway.
PS: If some class is named "Filesystem" someday, the "S" shouldn't be
capitalized: "filesystem" is an established single term in CS.
"Filesys" maybe as a short form?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Table of Perl 6 "Types"
On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote: : The only remaining problem is that we have no syntax for ...3, which : doesn't make sense as a list, but does make sense as a range. Well, it could be a lazy list that you only ever pop, I suppose. In any event, it doesn't work syntactically because ... is where a term is expected, so it's a yada-yada-yada with an unexpected term following it. Larry
Table of Perl 6 "Types"
Luke Palmer wrote:
> That's good, because that's what it does. A "range object" in list
> context expands into a list, but in scalar context it is there for
> smart-matching purposes:
>
> 3.5 ~~ 3..4 # true
> 4 ~~ 3..^4 # false
>
> etc.
>
> The only remaining problem is that we have no syntax for ...3, which
> doesn't make sense as a list, but does make sense as a range.
So just include a ... prefix operator that's useful for pattern
matching in scalar context, but fails if you try to use it in list
context.
More precisely, cause any range with an indeterminant lower bound to
fail if you try to use it in list context; so not only would "loop
...5 {...}" fail, but so would "loop (not 3..4) {...}" or "loop (not
5...) {...}"; but "loop (not ...5) {...}" would work, generating a
list of 6, 7, 8, 9, and so on.
BTW: where is the behavior in scalar context documented? I don't
remember seeing it. (I also seem to recall seeing something about "$a
..^ $b" being equivalent to "$a .. ($b - 1)"; but I could be mistaken.
I hope that's not the case, as the only time that it would make sense
would be when the both bounds are whole numbers and the range is being
used in list context.)
--
Jonathan "Dataweaver" Lang
Re: Table of Perl 6 "Types"
Rob Kinyon wrote: I wouldn't see a problem with defining a "Real" role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily "does Enumerable" if it wants to declare that it supports them. What about the scripty-doo side of Perl6? One of the overriding design considerations that Larry put forward at the very beginning was that the "easy things are easy" part of the philosophy would still remain. I want to still be able to do something like perl -pia -e '@F[2]++' somefile.xsv And it just DWIM for numbers like 1.2 ( -> 2.2). If Real is what 1.2 is implicitly coerced into, what do I do now? Scripty-code (without explicit types) uses Num, not Real.
Re: [perl #38216] [PATCH] fix parrot.pc.in
On Thu, Jan 12, 2006 at 07:51:58PM +, Nick Glencross wrote: > It looks like only prefix is actually set, and the other paths are set > using pkgconfig variables (which look the same as the style that we've > just moved away from). > > I hope that you don't mind, but I've not used your patch per se, but > have fixed the problem in r11128 similarly. Before closing the call, it > might be worth checking with everyone that libdir/includedir will always > be correct, otherwise we'll expand their paths. DOH! I noticed that yesterday when I was editing parrot.pc.in and decided that I should fix it as a separate changeset. Then promptly forgot to fix it... nice catch. -J -- pgpVgocMXf4lB.pgp Description: PGP signature
Re: Table of Perl 6 "Types"
On 1/12/06, Jonathan Lang <[EMAIL PROTECTED]> wrote: > I think that Dave has a point about a Range[Real] being an infinite > set: According to DWIM, if I see "4.5..5.7", I don't think of "4.5, > 5.5"; I think of "numbers greater than or equal to 4.5 but less than > or equal to 5.7". Likewise, "4.5^..^5.3" contains "numbers greater > than 4.5 but less than 5.3", not "an empty list". That's good, because that's what it does. A "range object" in list context expands into a list, but in scalar context it is there for smart-matching purposes: 3.5 ~~ 3..4 # true 4 ~~ 3..^4 # false etc. The only remaining problem is that we have no syntax for ...3, which doesn't make sense as a list, but does make sense as a range. Luke
Re: Table of Perl 6 "Types"
Dave Whipp wrote:
>An Int is Enumerable: each value that is an Int has well defined succ
>and pred values. Conversely, a Real does not -- and so arguably should
>not support the ++ and -- operators. Amonst other differences, a
>Range[Real] is an infinite set, whereas a Range[Int] has a finite
>cardinality.
I think that Dave has a point about a Range[Real] being an infinite
set: According to DWIM, if I see "4.5..5.7", I don't think of "4.5,
5.5"; I think of "numbers greater than or equal to 4.5 but less than
or equal to 5.7". Likewise, "4.5^..^5.3" contains "numbers greater
than 4.5 but less than 5.3", not "an empty list".
Mind you, I generally wouldn't be using such a range for iterative
purposes; rather, I'd be using it as a matching alternative to
comparison operators:
C === C<< if 4.5 <= $_ <= 5.7 {...; break} >>
C === C<< if 4.5 < $_ < 5.3 {...; break} >>
C === C<< if 1.2 <= $_ {...; break} >>
C === C<< if $_ < 7.6 {...; break} >>
C === C<< if $_ < 4.5 || 5.7 < $_
{...; break} >> === C
That said: if I _did_ use it for iterative purposes, I'd rather get
the current approach of turning it into a step-by-one incremental list
than have perl 6 complain about trying to iterate over an infinite
set. Well, unless I said something like "loop ...4.3 {...}"; in that
case, I'd expect Perl to complain about not knowing where to start.
--
Jonathan "Dataweaver" Lang
Re: [perl #38216] [PATCH] fix parrot.pc.in
Greg Bacon (via RT) wrote:
# New Ticket Created by Greg Bacon
# Please include the string: [perl #38216]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38216 >
There appears to have been some slop in the ${foo} -> @foo@ change,
and the attached patch fixes it.
Also, did libdir and includedir change to include underscores?
Hi Greg,
The parrot.pc.in has suffered a bit, hasn't it.
What I originally did with the parrot.pc.in was retain the general style
of other pkg-config configuration files, such as:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: GTK+
Description: GIMP Tool Kit
Version: 1.2.10
Requires: gdk
Libs: -L${libdir} -lgtk
Cflags:
It looks like only prefix is actually set, and the other paths are set
using pkgconfig variables (which look the same as the style that we've
just moved away from).
I hope that you don't mind, but I've not used your patch per se, but
have fixed the problem in r11128 similarly. Before closing the call, it
might be worth checking with everyone that libdir/includedir will always
be correct, otherwise we'll expand their paths.
Thanks for spotting,
Nick
Re: [perl #38219] AutoReply: [BUG] (r11126) pdb.exe build broken
On 1/12/06, Parrot Assembler via RT <[EMAIL PROTECTED]> wrote: > This message has been automatically generated in response to the > creation of a parrotbug regarding: > "[BUG] (r11026) pdb.exe build broken" > of course that should be r11126. ~jerry > while running 'make world' for i386-win32-cl: > > link -out:.\pdb.exe src\pdb.obj -nologo -nodefaultlib -debug > -mach > ine:x86 -debug blib\lib\libparrot.lib oldnames.lib kernel32.lib user32.lib > gd > i32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib > oleaut32.li > b netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib > odbc > cp32.lib msvcrt.lib > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_destroy > refere > nced in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_debug > referenc > ed in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_loadbc > referen > ced in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_readbc > referen > ced in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_exit > reference > d in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_init > reference > d in function _main > pdb.obj : error LNK2019: unresolved external symbol __imp__Parrot_new > referenced > in function _main > .\pdb.exe : fatal error LNK1120: 7 unresolved externals > NMAKE : fatal error U1077: 'link' : return code '0x460' > Stop.
[perl #38216] [PATCH] fix parrot.pc.in
# New Ticket Created by Greg Bacon
# Please include the string: [perl #38216]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38216 >
There appears to have been some slop in the ${foo} -> @foo@ change,
and the attached patch fixes it.
Also, did libdir and includedir change to include underscores?
Greg
Index: config/gen/makefiles/parrot.pc.in
===
--- config/gen/makefiles/parrot.pc.in (revision 11124)
+++ config/gen/makefiles/parrot.pc.in (working copy)
@@ -6,5 +6,5 @@
Name: parrot
Description: virtual machine to execute bytecode for interpreted languages
Version: @VERSION@
-Libs: [EMAIL PROTECTED]@} -lparrot @icu_shared@ @libs@
-Cflags: [EMAIL PROTECTED]@
+Libs: [EMAIL PROTECTED]@ -lparrot @icu_shared@ @libs@
+Cflags: [EMAIL PROTECTED]@
Re: Table of Perl 6 "Types"
On 1/12/06, Ævar Arnfjörð Bjarmason <[EMAIL PROTECTED]> wrote:
> The "next/prev" semantics are, and should be more general than ±1, I
> just think that ±1 should remain the default for reals & ints.
So, Num (and all types that derive from Num) should have a next of {
@_[0] + 1 } and a prev of { @_[0] - 1 } (boundschecking against the
limits of the type, of course) ... ?
That sounds reasonable and dwimmish to me.
Rob
Re: Table of Perl 6 "Types"
> I wouldn't see a problem with defining a "Real" role that has a fairly > sparse set of operations. Afterall, a type that does support ++ and -- > (e.g. Int, Num) could easily "does Enumerable" if it wants to declare > that it supports them. What about the scripty-doo side of Perl6? One of the overriding design considerations that Larry put forward at the very beginning was that the "easy things are easy" part of the philosophy would still remain. I want to still be able to do something like perl -pia -e '@F[2]++' somefile.xsv And it just DWIM for numbers like 1.2 ( -> 2.2). If Real is what 1.2 is implicitly coerced into, what do I do now? Remeber a few truisms: * The most common usage of Perl after bad CGIs is systems administration. * The most powerful feature of Perl for sysadmins is the scalar Rob
Re: Table of Perl 6 "Types"
On 1/12/06, Dave Whipp <[EMAIL PROTECTED]> wrote: > >>(perhaps this discussion belongs on p6l) > > It sure does;) > > (this reply moved to p6l) > > [EMAIL PROTECTED] wrote: > > Dave Whipp wrote: > > > >>An Int is Enumerable: each value that is an Int has well defined succ > >>and pred values. Conversely, a Real does not -- and so arguably should > >>not support the ++ and -- operators. Amonst other differences, a > >>Range[Real] is an infinite set, whereas a Range[Int] has a finite > >>cardinality. > > > > > > ++ and -- aren't meant to increment or decrement to the next/last value > > in the set, they're increment or decrement by one (see perlop). I can > > see your point about them not making sense for Real since it's not an > > enumerable set like integers but I don't think it would be in the > > spirit of DWIM ... > > Imagine I have a concrete type FixedPoint8_1000 that stores numbers from > 0 to 1000 in an 8-bit value, and "does Real". Incrementing a value > stored in this type by one isn't a meaningful operation. > > wrt the perlop reference, we manipulate strings with ++ and --; and > we're going to have enumerated types (albeit backed by intergers). I'm > sort-of hoping that we'll be able to use the operators on iterators, > too. I think what I'm saying is that "succ/pred" semantics are more > general than just "+/- 1"; and perl6 does not need to be bound by > perl5's perlop. I can't find a formal defn of autoincrement in the perl6 > docs. > > I wouldn't see a problem with defining a "Real" role that has a fairly > sparse set of operations. Afterall, a type that does support ++ and -- > (e.g. Int, Num) could easily "does Enumerable" if it wants to declare > that it supports them. I just meant that my Real $x = 5; # Or Num or ... say ++$x; should print "6" by default as opposed to "Error: no 'next' for real value". The "next/prev" semantics are, and should be more general than ±1, I just think that ±1 should remain the default for reals & ints.
[perl #38217] r11124: Cygwin build fails
# New Ticket Created by Greg Bacon # Please include the string: [perl #38217] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38217 > [...] /usr/bin/perl tools/build/parrot_config_c.pl --mini > \ src/null_config.c src/null_config.c gcc -o miniparrot.exe -s -L/usr/local/lib compilers/imcc/main.o \ -L/home/gbacon/src/parrot/blib/lib -lparrot -lcrypt src/null_config.o compilers/imcc/main.o: In function `imcc_version': /home/gbacon/src/parrot/compilers/imcc/main.c:124: undefined reference to `_Parrot_revision' /home/gbacon/src/parrot/compilers/imcc/main.c:128: undefined reference to `_Parrot_config_revision' compilers/imcc/main.o: In function `parseflags': /home/gbacon/src/parrot/compilers/imcc/main.c:294: undefined reference to `_yydebug' /home/gbacon/src/parrot/compilers/imcc/main.c:366: undefined reference to `_IMCC_fatal' compilers/imcc/main.o: In function `do_pre_process': /home/gbacon/src/parrot/compilers/imcc/main.c:387: undefined reference to `_IMCC_push_parser_state' /home/gbacon/src/parrot/compilers/imcc/main.c:388: undefined reference to `_yylex' /home/gbacon/src/parrot/compilers/imcc/main.c:402: undefined reference to `_yylex' compilers/imcc/main.o: In function `main': /home/gbacon/src/parrot/compilers/imcc/main.c:475: undefined reference to `_imcc_init' /home/gbacon/src/parrot/compilers/imcc/main.c:476: undefined reference to `_IMCC_ast_init' /home/gbacon/src/parrot/compilers/imcc/main.c:497: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:500: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:510: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:511: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:545: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:549: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:556: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:557: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:557: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:565: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:572: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:577: undefined reference to `_IMCC_push_parser_state' /home/gbacon/src/parrot/compilers/imcc/main.c:580: undefined reference to `_emit_open' /home/gbacon/src/parrot/compilers/imcc/main.c:582: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:585: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:585: undefined reference to `_IMCC_ast_compile' /home/gbacon/src/parrot/compilers/imcc/main.c:586: undefined reference to `_imc_compile_all_units_for_ast' /home/gbacon/src/parrot/compilers/imcc/main.c:590: undefined reference to `_yyparse' /home/gbacon/src/parrot/compilers/imcc/main.c:592: undefined reference to `_imc_compile_all_units' /home/gbacon/src/parrot/compilers/imcc/main.c:594: undefined reference to `_imc_cleanup' /home/gbacon/src/parrot/compilers/imcc/main.c:596: undefined reference to `_yyin' /home/gbacon/src/parrot/compilers/imcc/main.c:598: undefined reference to `_line' /home/gbacon/src/parrot/compilers/imcc/main.c:598: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:606: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:610: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:616: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:620: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:623: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:632: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:635: undefined reference to `_IMCC_fatal' /home/gbacon/src/parrot/compilers/imcc/main.c:653: undefined reference to `_IMCC_info' /home/gbacon/src/parrot/compilers/imcc/main.c:655: undefined reference to `_IMCC_info' collect2: ld returned 1 exit status make: *** [miniparrot.exe] Error 1
Re: [perl #38146] [TODO] OS.pmc - file copy
At 18:03 03/01/2006 -0800, you wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #38146] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38146 > OS.pmc should provide both a: and rename(oldname, newname) François. copy(source_file,target) And a copy(array_of_source_files,targetDir)
Re: Table of Perl 6 "Types"
>>(perhaps this discussion belongs on p6l) > It sure does;) (this reply moved to p6l) [EMAIL PROTECTED] wrote: Dave Whipp wrote: An Int is Enumerable: each value that is an Int has well defined succ and pred values. Conversely, a Real does not -- and so arguably should not support the ++ and -- operators. Amonst other differences, a Range[Real] is an infinite set, whereas a Range[Int] has a finite cardinality. ++ and -- aren't meant to increment or decrement to the next/last value in the set, they're increment or decrement by one (see perlop). I can see your point about them not making sense for Real since it's not an enumerable set like integers but I don't think it would be in the spirit of DWIM ... Imagine I have a concrete type FixedPoint8_1000 that stores numbers from 0 to 1000 in an 8-bit value, and "does Real". Incrementing a value stored in this type by one isn't a meaningful operation. wrt the perlop reference, we manipulate strings with ++ and --; and we're going to have enumerated types (albeit backed by intergers). I'm sort-of hoping that we'll be able to use the operators on iterators, too. I think what I'm saying is that "succ/pred" semantics are more general than just "+/- 1"; and perl6 does not need to be bound by perl5's perlop. I can't find a formal defn of autoincrement in the perl6 docs. I wouldn't see a problem with defining a "Real" role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily "does Enumerable" if it wants to declare that it supports them. Dave.
Re: Table of Perl 6 "Types"
Dave Whipp wrote: > An Int is Enumerable: each value that is an Int has well defined succ > and pred values. Conversely, a Real does not -- and so arguably should > not support the ++ and -- operators. Amonst other differences, a > Range[Real] is an infinite set, whereas a Range[Int] has a finite > cardinality. ++ and -- aren't meant to increment or decrement to the next/last value in the set, they're increment or decrement by one (see perlop). I can see your point about them not making sense for Real since it's not an enumerable set like integers but I don't think it would be in the spirit of DWIM to have to do: my Int $i = 5; say ++$i; and my Real $i = 5; # Or Num, Float or whatever say $i += 1; as that would be both inconsistent with Perl 5, C and every language that has ++/-- as well as being internally inconsistent in Perl 6 to have to use different constructs to increment by one for different number types. There's of course the argument that ++/-- aren't needed at all since they're really just relics from C where you needed them for pretty much every loop, although they're definitely usable almost everywhere where loop(;;) is appropriate in Perl 6 you don't need them as much as C, some other languages such as Python and Ruby don't have them at all, but that's a bit offtopic;) > (perhaps this discussion belongs on p6l) It sure does;)
Re: declaration of 'clone'
Klaas-Jan Stol wrote: Hi, I'm trying to implement some functions into the Lua PMCs, but I'm having trouble to compile them. I want to add a clone method to the LuaNil PMC (which should extend Null.pmc, not None.pmc, as it does currently; changed that already) However, I get the following error: luanil.c:343: error: conflicting types for `clone' /usr/include/bits/sched.h:72: error: previous declaration of `clone' compile luanil.c failed (256) clone is a standardized vtable function. But it's name is never a bare 'clone', it's always prefixed by 'Parrot__. This is also true for METHOD PMC* clone() # dunno if that works, if vtable exists You must have some bug in your PMC code. leo
declaration of 'clone'
Hi, I'm trying to implement some functions into the Lua PMCs, but I'm having trouble to compile them. I want to add a clone method to the LuaNil PMC (which should extend Null.pmc, not None.pmc, as it does currently; changed that already) However, I get the following error: luanil.c:343: error: conflicting types for `clone' /usr/include/bits/sched.h:72: error: previous declaration of `clone' compile luanil.c failed (256) make: *** [pmcs] Error 2 It seems the compiler finds another function called "clone", which has nothing to do with Parrot: /* Definitions of constants and data structure for POSIX 1003.1b-1993 scheduling interface. Copyright (C) 1996-1999,2001,2002,2003 Free Software Foundation, Inc. This file is part of the GNU C Library. regards, klaas-jan
Re: [perl #38146] [TODO] OS.pmc - file copy
On 1/12/06, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote:
> I'm not implementing copy at the moment as I lack knowledge. I might
> just write the default open/while(){write}/close method for cases when
> everything else fails.
>
> BTW, it will go for File.pmc accordingly with Leo.
>
since there seem to be non-File-specific methods destined for the File
PMC, perhaps it could be renamed to something more appropriate, like
FileSystem. thoughts?
~jerry
[perl #38123] [TODO] build - change genfile() interpolation syntax
The ${foo} interoplation/substitution syntax is no more. It has been
replaced with the autoconf like @foo@ syntax and all of the *.in files
have been updated. The special quoting syntax has also been removed
from parrot.pc.in
Support implimented in r11082 & r7.
Cheers,
-J
--
Re: [perl #38146] [TODO] OS.pmc - file copy
I'm not implementing copy at the moment as I lack knowledge. I might
just write the default open/while(){write}/close method for cases when
everything else fails.
BTW, it will go for File.pmc accordingly with Leo.
Joshua Juran wrote:
On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:
On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:
Since before System 7 (approaching two decades ago), Mac OS has had a
system call that exchanges the contents of two files. The purpose of
this call is to implement a 'safe save' strategy ...
Is this still a system call in Mac OS X?
Yes, the original FSpExchangeFiles() call persists along with most of
the calls pertaining to FSSpecs. New code written only for Mac OS 9 and
above could also use the newer FSRef-based FSExchangeObjects() call
which subsumes it.
Josh
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
Deprecated PMCs
The following PMCs wil be removed soon:
- FloatvalArray - use {Fixed,Resizable}FloatArray instead
- StringArray - use {Fixed,Resizable}StringArray instead
The latter is a dummy wrapper around ResizablePMCArray BTW.
leo
Re: how to detect that we're running under CPAN::Testers?
Tyler MacDonald wrote: Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote: For CPAN smokers based on CPAN::YACSmoke, the answer is: test the presence of the AUTOMATED_TESTING environment variable. See also the following page for more details: http://search.cpan.org/dist/CPAN-YACSmoke/lib/CPAN/YACSmoke/FAQ.pod Awesome, that's what I was after. :) Are there any other automated testing environments that post their results to testers.cpan.org I should worry about? Thanks, Tyler PITA will be doing so as well once it gets completed enough to start doing CPAN testing. I'll make sure to set AUTOMATED_TESTING as well. Adam K
