Re: Variable registers
Leopold Toetsch wrote: On Oct 1, 2005, at 18:11, Klaas-Jan Stol wrote: ah I thought so. just making sure. Then another question WRT this; will there be a register allocator? In other words, an attempt to minimize the number of needed registers? (in my simple code generator implementations, any time I need a new register, I just increment a counter, and use that, so in that case there is No register allocation scheme) Sure, the register allocator will remain. The increment the counter strategy is fine. The only difference will be that all lexicals and persistent variables, which are used around a function call, will be assigned to distinct Parrot registers. This strategy will solve the still lurking continuation bug that was discussed excessively here. Temps, not used around a function call, will have their registers reused as now. maybe I misunderstand, but does the above mean that lexicals are stored in registers, instead of storing them in scratchpads? (with lexicals being local variables in a function, with the addition of being also accessible from nested functions) klaas-jan
deprecated opcodes and PIR directives
I've updated the file DEPRECATED (r9306) with two more entries: is_digit, find_digit, ... # use *_cclass opcodes and APIs pack # wtf See DEPRECATED for more detailed information about planned changes. I'll start resolving DEPRECATED soon. If you have some good arguments that something from the listed things should be kept, please say so soon. leo
Lexicals (was: Variable registers)
Klaas-Jan Stol wrote: maybe I misunderstand, but does the above mean that lexicals are stored in registers, instead of storing them in scratchpads? (with lexicals being local variables in a function, with the addition of being also accessible from nested functions) The storage of lexicals will be in Parrot registers, yes. The plan is to assign all static (compile-time known) lexicals to distinct Parrot registers. Dynamic lexicals (tcl upvars or such) will still be handled with a hash, and name lookup remains the same. Basically: the current runtime-only lexical handling will be extended to provide a static scheme too. Chip is currently preparing a PDD covering all the details. klaas-jan leo
Re: [perl #29936] JIT debugging on Cygwin not working
--- Joshua Hoblitt via RT [EMAIL PROTECTED] wrote: Can you still recreate this issue? I haven't been involved in Parrot development for some time now. When I was involved I was pretty much the only Cygwin user actively participating so it was frustrating not to be able to validate what I was seeing. Parrot has changed considerably since then as has Cygwin and gcc. I would suggest asking the list if there is anyone interested in carrying on the Cygwin torch by asking them to reproduce the problem. I no longer have an environment to do so. Thanks, -J Cheers, Joshua Gatcomb a.k.a. Limbic~Region __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Exception handlers and calling conventions
On 11 July, Leopold Toetsch wrote: In the old calling scheme the exception object arrived as P5 in the handler. This doesn't really fit into the new scheme. Leo, did you change the handling of P5? I have some PIR code that works differently under 0.2.3 and 0.3.0: .sub main @MAIN push_eh MAIN_HANDLER foo() clear_eh end MAIN_HANDLER: print in main handler\n rethrow P5 .end .sub foo push_eh FOO_HANDLER new $P1, .Exception $P1[_message] = my_error_message throw $P1 clear_eh .return() FOO_HANDLER: print in foo handler\n rethrow P5 .end Under 0.2.3 it prints in foo handler in main handler before failing, which in my opinion is the expected behaviour. Under 0.3.0 it prints this before failing: in foo handler in main handler in main handler If you agree that the 0.3.0 behaviour is wrong, I'll file a bug report. Regards, Roger Browne
Re: [perl #30528] [PATCH] String PMC with iterator
On Oct 3, 2005, at 1:09 PM, Joshua Hoblitt via RT wrote: [EMAIL PROTECTED] - Tue Jun 29 05:14:34 2004]: This is the latest version of the String PMC, complete with iterators. In my understanding, the default implementation of morph() would check if the new class number is the same as the old one, and if it isn't then it would destroy the pmc and create a new one. For some reason this default method is sometimes not found (resulting in morph() not implemented errors). Am I wrong or is this a bug? alexm It doesn't look like this patch was ever applied and I don't think from looking at it that it can even been applied now. Do you still feel that there are issues with the string PMC? -J I believe the patch is hopelessly outdated. If you find no use for it, please delete it. Thanks. --alex
Re: Exception handlers and calling conventions
Roger Browne wrote: Leo, did you change the handling of P5? I have some PIR code that works differently under 0.2.3 and 0.3.0: The exception object iss still P5 in the handler, no changes here yet. If you agree that the 0.3.0 behaviour is wrong, I'll file a bug report. But the MAIN_HANDLER is catching twice, which looks like a bug to me. Regards, Roger Browne leo
Re: Look-ahead arguments in for loops
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
To pick some nits, reduce and fold are different concepts. By
definition, reduce doesn't take the initial value, while fold does.
So reduce using fold is something like
@items || die horribly;
foldl fn, @items[0], @items[1..]
... while fold using reduce is:
reduce fn, ($initial, @items)
I think both are useful, depending on the circumstances.
Miro
Re: Exception handlers and calling conventions
Roger Browne wrote: in foo handler in main handler in main handler Fixed. Now the main handler catches just once. Regards, Roger Browne Thanks for testing, leo
[perl #31285] [PATCH] first step in implementing a SCons base build
[EMAIL PROTECTED] - Sun Aug 22 17:19:34 2004]: All~ This patch is an early step in getting a scons based build system for parrot. Currently, it leaves the make system in place, the goal being to add a SCons system alongside the make system until the scons one is entirely ready. This patch allows scons to build foo.c and foo.dump files from foo.pmc. It will automatically detect dependencies between various PMC's and rebuild them as appropriate. Obviously this requires SCons to be installed on the system (and SCons requires Python). But since parrot can be built without it, I figured that this was a non-issue. If any one has a burning itch to implement other parts of this system, feel free to email me so we can collaborate. Have fun, Matt Matt, There has been alot of discussion about build systems on #parrot recently so I'm CCing p6i. Is SCons really an option for Parrot? I don't really know much about it but since it's implimented in Python, and Python hasn't been ported to all the platforms we hope to run on, wouldn't it introduce a serious portability issue? -J --
Re: Parrot 0.3.0 TODO
Well, Parrot builds on my new install of Cygwin. So I was sort of looking for stuff to do. The roadmap says that about a third of the opcodes don't have associated tests. Would that be a nice, easy start for chipping in? More significantly, the roadmap talks about rearchitecting the string internals. This sounds pretty fun, but not trivial. Also potentially fun -- and perhaps nontrivial -- is implementing the parrot equivalent of $0. I also see a lot of whining about the miniparrot build being broken. That might be Deep Voodoo, or not. Finally, it may be that all of these items are defunct, and I should be looking at RT instead. Any suggestions and preferences? Robert
Re: Parrot 0.3.0 TODO
On Oct 3, 2005, at 1:35 PM, Eaglestone, Robert J wrote: Also potentially fun -- and perhaps nontrivial -- is implementing the parrot equivalent of $0. This particular item would enable functionality in partcl.
[perl #37334] [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #37334]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37334
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch helps:
--- io/io_unix.c.dist 2005-10-03 20:54:25.0 +0300
+++ io/io_unix.c2005-10-03 20:56:51.0 +0300
@@ -832,7 +832,7 @@
newio = PIO_new(interpreter, PIO_F_SOCKET, 0, PIO_F_READ|PIO_F_WRITE);
if ((newsock = accept(io-fd, (struct sockaddr *)newio-remote,
- (socklen_t *)newsize)) == -1)
+ newsize)) == -1)
{
fprintf(stderr, accept: errno=%d, errno);
/* Didn't get far enough, free the io */
[perl #37335] [BUG] Parrot 0.3.0 tru64 compiler serious warning
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #37335] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37335 imcc/pcc.c^M cc: Info: imcc/pcc.c, line 379: In this statement, an array is being accessed o\ utside the bounds specified for the array type. (subscrbounds)^ regs[2] = arg;^ - And sure enough, regs has been declared as two-element array: SymReg *arg, *sub, *reg, *regs[2]; Assiging to the third elements is bound to be deadly.
[perl #37336] [BUG] Parrot 0.3.0 t/pmc/io.t assert core dump
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #37336] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37336 $ ./parrot t/pmc/io_1.pir Undef ok 1 Undef ok 2 Assertion failed: (unsigned long)l != 0xdeadbeefUL, file io/io.c, line 1013 dbx shows: (dbx) where 0 __nxm_thread_kill(0x6, 0x3ffc01b6000, 0x3ff805c0eb8, 0x3ffc01b6000, 0x3ffc01b6000) [0x3ff805c3048] 1 pthread_kill(0x0, 0x11fffb238, 0x0, 0x11fffc010, 0x3ff0001) [0x3ff805c0ed0] 2 (unknown)() [0x3ff805c7908] 3 (unknown)() [0x3ff80633994] 4 exc_raise_signal_exception(0x60ffe0003, 0x86, 0x0, 0x3ff805c3048, 0x1) [0x3ff80633d80] 5 __nxm_thread_kill(0x0, 0x3ffc01b6000, 0x3ff805c0eb8, 0x3ffc01b6000, 0x3ffc01b6000) [0x3ff805c3048] 6 pthread_kill(0x11fffbdf0, 0x11fffbdfd, 0x10378, 0x1, 0x3ff0001) [0x3ff805c0ed0] 7 __tis_raise(0x10378, 0x1, 0x3ff0001, 0x0, 0x3ff801d274c) [0x3ff80140554] 8 abort(0x3ff801d21b4, 0x0, 0x3ff805c2400, 0x0, 0x6) [0x3ff801d2748] 9 __assert(0x3ff800c2a90, 0x3ff800c2a80, 0x3, 0x1, 0x3) [0x3ff801d21b0] 10 PIO_putps(interpreter = 0x140138000, pmc = 0x140139ba0, s = 0x1404de570) [io/io.c:1013, 0x1200b95f4] 11 Parrot_print_p_sc(cur_opcode = 0x1401376b8, interpreter = 0x140138000) [ops/io.ops:308, 0x1200f2ff0] 12 runops_slow_core(interpreter = 0x140138000, pc = 0x1401376b8) [src/runops_cores.c:153, 0x120169748] 13 runops_int( = 0x140138000, = 0x140138000, interpreter = 0x140138000, offset = 0) [src/interpreter.c:750, 0x12010f1e0] 14 runops(interpreter = 0x140138000, offs = 0) [src/inter_run.c:81, 0x1200b70c0] 15 Parrot_runcode(interpreter = 0x140138000, argc = 1, argv = 0x11fffc020) [src/embed.c:869, 0x120095ac8] 16 Parrot_runcode(interpreter = 0x140138000, argc = 1, argv = 0x11fffc020) [src/embed.c:808, 0x1200958b8] 17 main(argc = 1, argv = 0x11fffc020) [imcc/main.c:647, 0x120094520](dbx)
[perl #37337] [BUG] Parrot 0.3.0 tru64 t/op/comp.t #7
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #37337] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37337 t/op/compok 6/80 # Failed test (t/op/comp.t at line 156) # got: '1 # 0 # -242 # 1 # ' # expected: '1 # 0 # -1 # 1 # ' t/op/compok 80/80# Looks like you failed 1 test of 80. t/op/compdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 7 Failed 1/80 tests, 98.75% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/comp.t1 256801 1.25% 7 Failed 1/1 test scripts, 0.00% okay. 1/80 subtests failed, 98.75% okay.
[perl #37338] [BUG] Parrot 0.3.0 tru64 t/pmc/string.t #13
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #37338] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37338 t/pmc/stringok 12/35 # Failed test (t/pmc/string.t at line 556) # got: '0 # 1 # -1 # 128 # -64 # 0 # ' # expected: '0 # 1 # -1 # 1 # -1 # 0 # ' t/pmc/stringok 34/35# Looks like you failed 1 test of 35. t/pmc/stringdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 13 Failed 1/35 tests, 97.14% okay (less 1 skipped test: 33 okay, 94.29%) Failed TestStat Wstat Total Fail Failed List of Failed --- t/pmc/string.t1 256351 2.86% 13 1 subtest skipped. Failed 1/1 test scripts, 0.00% okay. 1/35 subtests failed, 97.14% okay.
[perl #37339] [BUG] Parrot 0.3.0 tru64 t/pmc/perlstring.t #44
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #37339] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37339 t/pmc/perlstringok 43/68 # Failed test (t/pmc/perlstring.t at line 1244) t/pmc/perlstringNOK 44# got: '0 # 1 # -1 # 128 # -64 # 0 # ' # expected: '0 # 1 # -1 # 1 # -1 # 0 # ' t/pmc/perlstringok 67/68# Looks like you failed 1 test of 68. t/pmc/perlstringdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 44 Failed 1/68 tests, 98.53% okay (less 1 skipped test: 66 okay, 97.06%) Failed TestStat Wstat Total Fail Failed List of Failed --- t/pmc/perlstring.t1 256681 1.47% 44 1 subtest skipped. Failed 1/1 test scripts, 0.00% okay. 1/68 subtests failed, 98.53% okay.
Re: [perl #31285] [PATCH] first step in implementing a SCons base build
Joshua~ On 10/3/05, Joshua Hoblitt via RT [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] - Sun Aug 22 17:19:34 2004]: All~ This patch is an early step in getting a scons based build system for parrot. Currently, it leaves the make system in place, the goal being to add a SCons system alongside the make system until the scons one is entirely ready. This patch allows scons to build foo.c and foo.dump files from foo.pmc. It will automatically detect dependencies between various PMC's and rebuild them as appropriate. Obviously this requires SCons to be installed on the system (and SCons requires Python). But since parrot can be built without it, I figured that this was a non-issue. If any one has a burning itch to implement other parts of this system, feel free to email me so we can collaborate. Have fun, Matt Matt, There has been alot of discussion about build systems on #parrot recently so I'm CCing p6i. Is SCons really an option for Parrot? I don't really know much about it but since it's implimented in Python, and Python hasn't been ported to all the platforms we hope to run on, wouldn't it introduce a serious portability issue? -J I brought it up on the list first, and Dan was OK with it because scons can output a series of commands (like a bat file or batch script) to build from scratch (no smart dependency checks). This also provides a way to break the make dependency. All that having been said, I probably won't get around to finishing this anytime soon, and I don't think most of the others are interested in it. Although it also would solve the problem of our make system being broken WRT dependency checking. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
another deprecated one: newsub?
1) newsub with 4 arguments op newsub(in INT, in INT, labelconst INT, labelconst INT) Creates a 'Sub' in P0 and a 'Continuation' in P1. It was invented as a speed hack before Sub PMCs and return continuations did exist. The implicit register usage needs extra code inside IMC. Other arguments against it are common with the 3-arg newsub. It should for sure go away. 2) newsub with 3 arguments op newsub(out PMC, in INT, labelconst INT) Creates a new 'Sub-like PMC of given type and label. The opcode is too general: Sub objects created with this opcode don't have a name and are missing other meta-information like the end of the subroutine. This would disable bounds-checking during execution of such an object. Other meta-information missing from such subs include the namespace, HLL information, and MMD type information. The given label doesn't have to be a real .sub label either. The opcode is not needed IMHO: .sub foo or the PASM equivalent .pcc_sub foo both create a Sub PMC, which can be looked up or resolved at compile time, when the sub is in the same comilation unit. If there is really a need to create a new Sub object, an existing one can be cloned. .sub gen ... .yield(res) ... creates a Coroutine PMC due to the presence of the .yield. Closures are only reasonably useful, if the closure objects are distinct. Therefore: .local pmc clos clos = find_name foo clos = clone clos can be used instead of the newsub opcode. I'm going to deprecate both soon, if there arent' really strong arguments against it. leo
Re: Tcl - compiling
Committed: partcl is now now a compiler. Though some tests still fail
(leo fixed one of the unicode issues)
t/cmd_global.t 3 768 63 50.00% 2-4
t/cmd_proc.t 4 1024114 36.36% 3-4 8-9
t/cmd_return.t 1 256 21 50.00% 1
t/cmd_string.t 2 512572 3.51% 45-46
t/tcl_backslash.t4 1024354 11.43% 31-34
Jerry Gay was getting bored with all tests passing, so this is for
him. =-)
Thanks to a conversation on #parrot with leo, I have a lead on fixing
the problems with global, proc, and return: but I think the easiest
solution will involve completing one of the upcoming items below, so
committing as is for now. The unicode issues in the last two test
files above could use some time to track down. Ping me if you'd like
work on this.
Next few compiler related things to do:
1) provide inline-able versions of builtins. (on the short list:
anything in examples/bench.tcl)
2) Change the compiler to call those if they're available. (For
anything that has an inlinable version, we can replace the
interpreted version with a call to the compiled version.)... this
will temporarily brake some rename tests, but:
3) Keep a global counter that is incremented whenever a procedure is
created or rename'd. When generating the compiled code, key against
this counter - if it's changed, we must fall back to the interpreted
version. (which, although it starts out with a a call to the compiled
builtin, might have been replaced at that point.).
4) Provide a way to dump the total generated PIR code instead of
compiling executing it.
Regards.
On Oct 2, 2005, at 1:40 AM, Will Coleda wrote:
The simple version of the compiler is now mostly done in my sandbox:
Failed Test Stat Wstat Total Fail Failed List of Failed
--
-
t/cmd_global.t 3 768 63 50.00% 2-4
t/cmd_proc.t 4 1024114 36.36% 3-4 8-9
t/cmd_return.t 1 256 21 50.00% 1
t/cmd_string.t 3 768573 5.26% 21 45-46
t/tcl_backslash.t4 1024354 11.43% 31-34
These break down into two classes of errors:
1) ``Pad index out of range'' {global, proc, return}
2) Data::Escape::String can't escape unicode {string, backslash}
I've opened a TODO ticket for #2: [perl #37321] Any takers on this
appreciated.
If I can get #1 working, I'll just TODO everything that depends on
#2 and get this checked in.
I've attached the generated PIR output for the sample program,
which outputs 10
set a 0
while {$a 10} {
incr a
}
puts $a
It's functional but ugly. (Patches welcome once I checkin)
output.txt
On Sep 30, 2005, at 1:39 PM, Amos Robinson wrote:
Eeek. Yes, I forgot just how crazy a language it was. :-D
Yes, that's the plan, but the initial implementation isn't going to
be a compiler like most people would expect:
For example, something like:
while {$a 10} { incr a }
while isn't language syntax. it's a command. So, this code would
result in creating two PMCs for the args (first arg is {$a 10},
second is {incr a}), and then lookup the while PIR .sub, and invoke
it with the two PMC args.
Future versions of the compiler will be able to cheat (presuming the
while builtin hasn't been overriden) and generate inline-able PIR,
which should improve performance.)
Regards.
Re: Tcl - compiling
On Oct 3, 2005, at 22:57, Will Coleda wrote: 3) Keep a global counter that is incremented whenever a procedure is created or rename'd. When generating the compiled code, key against this counter - if it's changed, we must fall back to the interpreted version. (which, although it starts out with a a call to the compiled builtin, might have been replaced at that point.). I don't see the point. Your compiler can emit, e.g.: while(test, body) You provide an appropriate implementation of a default while function, in your default namespace. Whenever user code overrides the while word (set while $foo - or some such - I dunno Tcl syntax details), you store_global the new implementation as a compiled function into the same namespace (or as a lexical). Done. Regards. leo
Re: Tcl - compiling
On 10/3/05, Will Coleda [EMAIL PROTECTED] wrote: Committed: partcl is now now a compiler. Though some tests still fail (leo fixed one of the unicode issues) t/cmd_global.t 3 768 63 50.00% 2-4 t/cmd_proc.t 4 1024114 36.36% 3-4 8-9 t/cmd_return.t 1 256 21 50.00% 1 t/cmd_string.t 2 512572 3.51% 45-46 t/tcl_backslash.t4 1024354 11.43% 31-34 Jerry Gay was getting bored with all tests passing, so this is for him. =-) i can't tell you how happy this makes me :) even more tests failing on windows (r9318)... Failed Test Stat Wstat Total Fail Failed List of Failed --- t\cmd_global.t 3 768 63 50.00% 2-4 t\cmd_inline.t 1 256 31 33.33% 2 t\cmd_proc.t 4 1024114 36.36% 3-4 8-9 t\cmd_return.t 1 256 21 50.00% 1 t\cmd_string.t 2 512572 3.51% 45-46 t\tcl_backslash.t4 1024354 11.43% 31-34 Failed 6/47 test scripts, 87.23% okay. 15/450 subtests failed, 96.67% okay. t/cmd_inline.t:2 is the mysterious can't spawn bug that only seems to infest windows: t\cmd_inline...NOK 2# Can't spawn .\parrot.exe --gc-debug languages/tcl/tcl.pbc C:\DOCUME~1\particle\LOCALS~1\Temp\cmd_inline_2.tcl: Bad file descriptor at ../../lib/Parrot/Test.pm line 238. # ' # expected: 'ok # ' # '.\parrot.exe --gc-debug languages/tcl/tcl.pbc C:\DOCUME~1\particle\LOCALS~1 \Temp\cmd_inline_2.tcl' failed with exit code 255 ~jerry
Re: [perl #30997] pdb labels broken in tru64/alpha
1989 /* (dbx) The line-label is an impossible pointer, so deferencing causes promptly a bus error. Jarkko, Can you restest and confirm that this is still an issue with pdb? These seems to have been fixed. Thanks, -J
Re: [perl #37334] AutoReply: [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch helps:
--- io/io_unix.c.dist 2005-10-03 20:54:25.0 +0300
+++ io/io_unix.c2005-10-03 20:56:51.0 +0300
@@ -832,7 +832,7 @@
newio = PIO_new(interpreter, PIO_F_SOCKET, 0, PIO_F_READ|PIO_F_WRITE);
if ((newsock = accept(io-fd, (struct sockaddr *)newio-remote,
- (socklen_t *)newsize)) == -1)
+ newsize)) == -1)
{
fprintf(stderr, accept: errno=%d, errno);
/* Didn't get far enough, free the io */
Please ignore that patch, it doesn't work since socklen_t is a long,
not an int, and in Tru64 one shall not mix those.
Re: [perl #30671] tru64 problems with nci.t and object-meths.t
Jarkko, Does this issue still occur on tru64? Works in Parrot 0.3.0. -J
[perl #37340] Calling vtable functions from PIR fails in 0.3.0
# New Ticket Created by Roger Browne # Please include the string: [perl #37340] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37340 --- osname= linux osvers= 2.4.21-27.0.2.elsmp arch= i386-linux-thread-multi cc= gcc 4.0.0 20050516 (Red Hat 4.0.0-6) --- Flags: category=core severity=medium ack=no --- Under Parrot 0.2.3 the following PIR program prints 4 as expected: .sub main @MAIN .local pmc a, b a = new Integer a = 2 b = a.__add(a) print b print \n end .end Under Parrot 0.3.0 the same code fails like this: parrot: src/nci.c:72: get_nci_P: Assertion `n st-src.n' failed. Aborted Regards, Roger Browne --- Summary of my parrot 0.3.0 (r9313) configuration: configdate='Mon Oct 3 20:04:05 2005' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' 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 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
Re: [perl #31285] [PATCH] first step in implementing a SCons base build
On Mon, Oct 03, 2005 at 03:49:25PM -0400, Matt Fowles wrote: Joshua~ On 10/3/05, Joshua Hoblitt via RT [EMAIL PROTECTED] wrote: Matt, There has been alot of discussion about build systems on #parrot recently so I'm CCing p6i. Is SCons really an option for Parrot? I don't really know much about it but since it's implimented in Python, and Python hasn't been ported to all the platforms we hope to run on, wouldn't it introduce a serious portability issue? -J I brought it up on the list first, and Dan was OK with it because scons can output a series of commands (like a bat file or batch script) to build from scratch (no smart dependency checks). This also provides a way to break the make dependency. That sounds like a step backwards from autoconf/automake can provide. Granted, everybody agrees that make sucks but I don't see the point SCons. We'd be swapping a dependency on make for one on Python - with what advantage? -J -- pgp3sJT5OUfYi.pgp Description: PGP signature
[perl #37333] [BUG] Config missing response for shared libs
# New Ticket Created by Will Coleda # Please include the string: [perl #37333] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37333 Determining if your C compiler is actually gcc.yes. Enabling optimization.done. Determining flags for building shared libraries.. . Determining what charset files should be compiled in..done. Determining what encoding files should be compiled in.done. This is on OS X 10.4.2, using gcc 4.0.0 Builds and tests fine, though.
[perl #37332] 'rethrow' opcode regression under Parrot 0.3.0
# New Ticket Created by Roger Browne # Please include the string: [perl #37332] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37332 --- osname= linux osvers= 2.4.21-27.0.2.elsmp arch= i386-linux-thread-multi cc= gcc 4.0.0 20050516 (Red Hat 4.0.0-6) --- Flags: category=core severity=medium ack=no --- The following PIR code that works differently under 0.2.3 and 0.3.0: .sub main @MAIN push_eh MAIN_HANDLER foo() clear_eh end MAIN_HANDLER: print in main handler\n rethrow P5 .end .sub foo push_eh FOO_HANDLER new $P1, .Exception $P1[_message] = my_error_message throw $P1 clear_eh .return() FOO_HANDLER: print in foo handler\n rethrow P5 .end Under 0.2.3 it prints in foo handler in main handler before dying, which in my opinion is the expected behaviour. Under 0.3.0 it prints this before dying: in foo handler in main handler in main handler In other words, the 'rethrow' within MAIN_HANDLER is causing MAIN_HANDLER to be entered a second time. Roger Browne. --- Summary of my parrot 0.3.0 (r0) configuration: configdate='Sun Oct 2 22:30:54 2005' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' 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 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
Re: [perl #37334] AutoReply: [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
Jarkko Hietaniemi wrote:
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch helps:
--- io/io_unix.c.dist 2005-10-03 20:54:25.0 +0300
+++ io/io_unix.c2005-10-03 20:56:51.0 +0300
@@ -832,7 +832,7 @@
newio = PIO_new(interpreter, PIO_F_SOCKET, 0, PIO_F_READ|PIO_F_WRITE);
if ((newsock = accept(io-fd, (struct sockaddr *)newio-remote,
- (socklen_t *)newsize)) == -1)
+ newsize)) == -1)
{
fprintf(stderr, accept: errno=%d, errno);
/* Didn't get far enough, free the io */
Please ignore that patch, it doesn't work since socklen_t is a long,
not an int, and in Tru64 one shall not mix those.
Please ignore the ignore :-) It seems that it depends how long the
socklen_t is in Tru64, and with cxx (the C++ compiler) and the flags
Parrot compilation uses, int is fine. So the above patch is fine for
now. In the long run the newsize really should be socklen_t. Getting
that to be defined seems to be little tricky with cxx, so please don't
change that right now... in the meanwhile, I found another bug in the
IO code, bug report coming soon.
Re: [perl #30908] [PATCH] find_or_create_global
I think that was taken care of by adding the addition of a 'don't throw exception on undefined global access' runtime flag. Though find_or_create_global might still be useful, I don't think it's worth digging up that old patch. --- Joshua Hoblitt via RT [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] - Sun Aug 01 09:14:41 2004]: This adds the find_or_Create_global ops, which act just like find_global, except that if the global does not yet exist, it is created as undef. They will never throw an exception just because the global does not yet exist. This also adds a test to t/op/globals.t It doesn't appear that this patch was applied. Is there still an issue that needs to be considered? -J __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [perl #31285] [PATCH] first step in implementing a SCons base build
On Mon, 2005-10-03 at 12:29 -1000, Joshua Hoblitt wrote: That sounds like a step backwards from autoconf/automake can provide. Granted, everybody agrees that make sucks but I don't see the point SCons. We'd be swapping a dependency on make for one on Python - with what advantage? Python has fewer platform-specific differences, though it may work on far fewer platforms overall. In my mind, that's not necessarily an argument for Python as it is against make in practice. -- c
Re: Look-ahead arguments in for loops
Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
To pick some nits, reduce and fold are different concepts. By
definition, reduce doesn't take the initial value, while fold does.
So reduce using fold is something like
@items || die horribly;
foldl fn, @items[0], @items[1..]
... while fold using reduce is:
reduce fn, ($initial, @items)
I think both are useful, depending on the circumstances.
Miro
Something like:
sub *reduce(func, +$initial = undef, [EMAIL PROTECTED])
{
$value = $initial;
map { $value = func($value, $_); } == @list;
return $value;
}
?
Or would this be an array method? I can see wanting to reduce list
literals, in some wierd mostly-tutorial cases, but I can also see
wanting this to be a data structure method to prevent reducing a parse
tree using an array operation...
=Austin
[PATCH] Add BROKEN.pod
Hi there, Here's (finally) a collection and summary of all of the known broken items in Parrot right now as a patch to create BROKEN.pod in the top level directory. If this isn't the right name or place to put the file, that's fine. I'll check this in in two days with regard to feedback from anyone whose opinion matters and what to call it and where to put it, if my initial choice isn't perfect. -- c --- /dev/null 1969-12-31 16:00:00.0 -0800 +++ BROKEN.pod 2005-10-03 18:13:25.0 -0700 @@ -0,0 +1,183 @@ +=head1 What's Broken in Parrot Right Now + +This is a list of items we think are broken in Parrot at the current revision. +Committers, please add to the list as you find things and remove from the list +as you resolve things. + +=head2 Missing Features + +Ways to emulate these would be nice too. + +=over 4 + +=item * Lexical Classes + +=item * Anonymous Classes + +=item * Submethods + +=back + +=head2 Broken Features + +=over 4 + +=item * Existing Code Marked As Broken + +Lots of comments in the code read CXXX, C???, or CFIXME. Fix them. + +=item * Lexical Pads + +Autrijus Tang has details. + +=item * Nested *Struct PMCs Share State + +chromatic has a test case almost ready to show this. + +=item * Csetattribute Sometimes Misses + +https://rt.perl.org/rt3//Ticket/Display.html?id=36411 + +=back + +=head2 Unfinished Opcodes + +=over 4 + +=item * split + +https://rt.perl.org/rt3//Ticket/Display.html?id=32544 + +Will Coleda suggested Cs/regexp/perl 6 rule/ and using PGE. Patrick Michaud +suggests making Csplit work only on constant strings and using PGE for +everything else. + +=back + +=head2 Missing Vtables + +=over 4 + +=item * ResizablePMCArray + +https://rt.perl.org/rt3//Ticket/Display.html?id=31867 + +=item * ResizableIntegerArray + +https://rt.perl.org/rt3//Ticket/Display.html?id=32374 + +=item * splice + +https://rt.perl.org/rt3//Ticket/Display.html?id=34394 + +=back + +=head2 Missing PDDs + +=over + +=item * Embedding (PDD 10) + +https://rt.perl.org/rt3//Ticket/Display.html?id=33918 + +=item * Assembly (PDD 12) + +https://rt.perl.org/rt3//Ticket/Display.html?id=33919 + +=item * Bytecode (PDD 13) + +https://rt.perl.org/rt3//Ticket/Display.html?id=33920 + +=back + +=head2 Language-Specific Items + +=over 4 + +=item * Make Perl a F/language + +=over 4 + +=item * Don't have Perl deps in static classes + +https://rt.perl.org/rt3//Ticket/Display.html?id=32642 + +=item * Make Perl PMCs dynamic + +https://rt.perl.org/rt3//Ticket/Display.html?id=32646 + +=back + +=item * Let languages be self contained + +https://rt.perl.org/rt3//Ticket/Display.html?id=31633 + +Right now many languages are in the FMANIFEST, using the global config, etc. +As far as Perl goes, this could let us move Perl PMCs into +Flanguages/perl[6]). + +=back + +=head2 Obsolete Features + +=over 4 + +=item * Everything in FDEPRECATED + +=item * Fops/rx.ops + +Superseded by PGE. + +=back + +=head2 Miscellaneous + +=over 4 + +=item * Generate accurate file/line number information in stack traces. + +=item * Get name of Cparrot executable + +https://rt.perl.org/rt3//Ticket/Display.html?id=33923 + +=item * Namespaces + +Matt Diephouse has prepared an email on this. + +=item * Give invokable PMCs a canonical way to store their associated HLL +source and argument information. + +Will Coleda is thinking about this. + +=item * Add rules engines for perl5-ish RE's in PGE. + +Will Coleda specifically wants +http://www.tcl.tk/man/tcl8.5/TclCmd/re_syntax.htm, but having a P5-ish one to +subclass would be just dandy. Patrick Michaud thinks this is doable. + +=item * Allow Building with a Different Compiler + +Parrot relies on values pulled from the Perl 5 configuration, even with +C--ask. Andy Dougherty says that: + + $ perl Configure.pl cc=XX cxx=XX link=XX ld=XX + +should, but doesn't, work. + +=item * Allow Runtime Compiler Registration + +Leo suggests an eventual startup sequence of: + +=over 4 + +=item * start main in Fsrc/parrot.c + +=item * determine source file type to compile/run + +=item * handle execution over to xxx-compiler or to pbc-run. + +=back + +Currently Fsrc/parrot.c does nothing and startup occurs in Fimcc/main.c. + +=back
Re: [PROPOSED PATCH lib/Parrot/Vtable.pm] Generate src/extends.c
On Mon, 2005-09-26 at 22:04 +0200, Leopold Toetsch wrote: vtable_extend.patch Well, besides a nitpick regarding: +=item Cvtbl_extend($vtable) + + [ snipped ] + +sub vtbl_embed ... I'm fine with that patch. Okay, I checked it in. But the ultimate word should speak actual users of Parrot extend/embed, and of course, if it should be included in the upcoming release. Nothing uses it yet; it's just there to test against in whatever generates the file for embedders. Someone'll have to enable it manually with some Makefile magic. -- c
Re: Tcl - compiling
On Oct 3, 2005, at 6:34 PM, Leopold Toetsch wrote: On Oct 3, 2005, at 22:57, Will Coleda wrote: 3) Keep a global counter that is incremented whenever a procedure is created or rename'd. When generating the compiled code, key against this counter - if it's changed, we must fall back to the interpreted version. (which, although it starts out with a a call to the compiled builtin, might have been replaced at that point.). I don't see the point. Your compiler can emit, e.g.: while(test, body) You provide an appropriate implementation of a default while function, in your default namespace. Whenever user code overrides the while word (set while $foo - or some such - I dunno Tcl syntax details), you store_global the new implementation as a compiled function into the same namespace (or as a lexical). That's actually how things work right now (very similar to the interpreter from previous versions). I'm suggesting switching to inlining the code when possible... and then watching out for cases where the inlined version is stale (using a fairly simple method, but one that'll still give us a boost.). The degenerate case using this caching/inlining will be the current implementation (plus an integer compare before each invocation) Is the argument that inlining will not (even theoretically) provide a speed boost? I imagine on single pass code it'd be a wash, but for something like while, we're potentially avoiding one find_global per statement per iteration of the body, as well as the associated call/ return for each element in the body. Even for something like examples/ bench.tcl, that'd be tens of thousands of parrot sub calls/returns that we could potentially eliminate. as low as that overhead is, I imagine it's got to add up. The nice thing about doing the inlining _as it's available_ means that (presuming this *is* a good thing), we can inline the builtins that give us the best boost first, and I don't have to reimplement everything all at once. Regards.
my $key is sensitive;
For the last couple days, I've been implementing a cryptographic cipher framework for Perl 6. (It's in the Pugs repository if you want to see it.) Dealing with this sort of algorithm has brought forward a feature that I think Perl 6 and Parrot ought to support. Basically, I'd like to be able to mark a variable as sensitive or secret. This implies that the language should overwrite the memory it uses before deallocating it, and that if possible it should tell the virtual memory system to avoid swapping it out. Moreover, it should probably do so recursively, and to any value that has ever been stored in the variable. (In essence, the *variable* marks all *values* it ever contains as sensitive.) This feature could make Perl 6 a better language for security work than any other I've seen. C and C++ could do this, but only with the programmer's assistance (by calling a wipe function or making sure a destructor is correctly called), and optimizers have been known to helpfully remove such code. Many higher-level languages, including Perl 5, make it hard to know when a piece of data is being overwritten, rather than a pointer being changed. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
