Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 23 December 2008.
00:09 AndyA joined
Coke I'm seeing a rise in smolder reports. the smokers must have switched. 00:11
or, rather, survived the switch.
I am confused to see allison still working in the remove_pic branch.
ah well. it will result in less code thatn we have now. 00:12
01:29 tetragon joined 01:49 kid51 joined 02:07 Limbic_Region joined 02:09 Ademan joined 02:46 Whiteknight joined 03:58 apeiron joined 04:02 elmex_ joined 04:30 Andy joined 04:32 ChrisDavaz joined
dalek r34402 | allison++ | branches/pdd22io_part3/src (3 files): 05:06
: [pdd22io] Invert 'close', 'is_closed', and 'putps', so public interface just
: calls a method on the FileHandle PMC, to allow clean polymorphism.
review: www.parrotvm.org/svn/parrot/revision?rev=34402
05:08 gmansi joined
dalek r34403 | allison++ | branches/pdd22io_part3/include/parrot: 05:09
: [pdd22io] Run the headerizer on I/O files for new functions and filename
: changes.
review: www.parrotvm.org/svn/parrot/revision?rev=34403
r34404 | petdance++ | trunk/src: 05:32
: SHIMmed an argument
review: www.parrotvm.org/svn/parrot/revision?rev=34404
r34405 | petdance++ | trunk/tools/build:
: no need to have an import on ::Utils
review: www.parrotvm.org/svn/parrot/revision?rev=34405
05:40 gmansi joined
Andy anyone around? 05:43
purl wait a minute and see
chromatic Something in mind? 05:46
dalek r34406 | petdance++ | trunk/lib/Parrot (2 files): 05:50
: consting
review: www.parrotvm.org/svn/parrot/revision?rev=34406
Andy it's just hard to tell what's failing and why 05:51
smolder.plusthree.com/app/public_pr..._reports/8
shorten Andy's url is at xrl.us/beaqvk
Andy some things fail, some don't, none of them what's failing for m.e
dalek r34407 | allison++ | branches/pdd22io_part3 (4 files): 05:52
: [pdd22io] Invert 'flush', so public interface calls method on filehandle
: object, for clean polymorphic substitution.
review: www.parrotvm.org/svn/parrot/revision?rev=34407
chromatic Andy, the OpenBSD ones are probably very specific to OpenBSD's transcendental number handling. 05:53
Andy it's also tragic that the headerizer can't run. 05:56
chromatic I had it working a while ago. 05:57
Andy can't find HEADERIZER HFILE directive in 'src/jit_defs.c' at tools/build/headerizer.pl line 452. 06:15
Adding it in. 06:16
nobody's run headerizer in a while. 06:23
dalek r34408 | petdance++ | trunk (16 files): 06:26
: reran headerizer
review: www.parrotvm.org/svn/parrot/revision?rev=34408
r34409 | petdance++ | trunk/src (3 files): 06:36
: removing unused vars
review: www.parrotvm.org/svn/parrot/revision?rev=34409
chromatic What's the point of a register machine if our calling conventions are so heavyweight that we have to construct a CallSignature PMC for every subroutine invocation? 06:39
TiMBuS sounded like a cool idea at the time? 06:47
Andy didn't we ave a page of who's running what compiler somewhere? 07:02
I bet I'm the only one even thinking of the intel COmpiler 07:03
compiler
purl rumour has it compiler is a controversial feature of Perl5.005 which will probably be used for evil ends or a way for the unenlightened to make themselves think their programs will run faster
TiMBuS would it be a good suggestion to ask for generated labels in inline past nodes? so you dont have a clash if its used twice in the same scope 07:09
and on that subject, what will happen with inline past nodes if it switches to compiling straight to bytecode as (i think) patrick has said might happen? 07:10
dalek r34410 | petdance++ | trunk/src/io:
: removed unused var, and consted a bunch
review: www.parrotvm.org/svn/parrot/revision?rev=34410
r34411 | petdance++ | trunk/src/jit (10 files): 07:23
: added headerizer directives
review: www.parrotvm.org/svn/parrot/revision?rev=34411
Andy sometimes I feel like the only one runing with max compile switches 07:30
07:35 tuxdna joined
tuxdna hi all 07:36
is docs/book/ included in the HTML when we generate html documentation using "make html"
I could'nt locate it there. Please tell me to find it out. 07:37
dalek r34412 | petdance++ | trunk/lib/Parrot/Pmc2c/PMC: 07:40
: no imports for classes
review: www.parrotvm.org/svn/parrot/revision?rev=34412
r34413 | petdance++ | trunk (2 files):
: die_from_exception cannot return
review: www.parrotvm.org/svn/parrot/revision?rev=34413 07:41
r34414 | petdance++ | trunk/src/pmc: 07:50
: localizing a pointer
review: www.parrotvm.org/svn/parrot/revision?rev=34414
cotto tuxdna, iirc the book stuff is written in a PseudoPOD, which the normal POD code can't deal with. 07:53
I'd look at search.cpan.org/~arandal/Pod-PseudoPod-0.13/ to get html out of it 07:54
dalek r34415 | petdance++ | trunk/lib/Parrot/Pmc2c:
: removed unused var
review: www.parrotvm.org/svn/parrot/revision?rev=34415
tuxdna cotto, Thanks. I will figure it out. 07:56
dalek r34416 | petdance++ | trunk/lib/Parrot/Pmc2c (2 files): 08:05
: Working on SHIMming out unused args in PMCs that throw exceptions
review: www.parrotvm.org/svn/parrot/revision?rev=34416
08:50 barney joined 08:58 Theory joined 09:57 Zaba joined 10:11 jimmy joined 10:14 jimmy_ joined 10:26 masak joined 10:58 iblechbot joined
dalek r34417 | ask++ | trunk: 11:09
: Add subversion usernames and email addresses for everyone who made a commit
: Include a small script to make an "svn authors" file
: Signed-off-by: Ask Bj�rn Hansen <ask@develooper.com>
review: www.parrotvm.org/svn/parrot/revision?rev=34417
r34418 | kjs++ | trunk/docs:
: [docs] update entry for pirc. + remove an unnecessary space.
review: www.parrotvm.org/svn/parrot/revision?rev=34418
r34419 | kjs++ | trunk/compilers/pirc/new (3 files): 11:15
: [pirc] prepare to refactor sub struct.
: + remove __ in some union names. They're ugly.
: + remove some false comment.
review: www.parrotvm.org/svn/parrot/revision?rev=34419
11:16 alvar joined 11:18 kj joined
dalek r34420 | kjs++ | trunk/compilers/pirc/new (2 files): 11:37
: [pirc] rewrite some complex code into switch format.
review: www.parrotvm.org/svn/parrot/revision?rev=34420
11:57 jimmy joined 12:21 ffwonko joined
dalek r34421 | kjs++ | trunk/config/gen/makefiles: 13:14
: [config] fix pirc.in for make test.
review: www.parrotvm.org/svn/parrot/revision?rev=34421
13:15 register joined
dalek r34422 | kjs++ | trunk/compilers/pirc/new (3 files): 13:15
: [pirc] add a parse_string function, which takes a PIR string.
: + parse_file+parse_string() need to be refactored, but for now this works.
: + add a PARROT_ASSERT on filename in bcgen.c:new_bytecode(); this cannot be NULL.
review: www.parrotvm.org/svn/parrot/revision?rev=34422
13:41 kid51 joined 14:04 jan joined 14:08 Theory joined 14:13 mberends joined
dalek r34423 | infinoid++ | trunk/compilers/imcc: 14:33
: [cage] Re-add some #ifdef guards that were removed by 'make headerizer'.
: This kills a gcc warning.
review: www.parrotvm.org/svn/parrot/revision?rev=34423
14:48 riffraff joined 14:53 tetragon_ joined, jimmy joined
riffraff I'd like to build a kind of label/goto thing into a language, but Im not sure how to emit that with PAST nodes. Probably it could be done building a continuation where the label is and calling it where I have the goto statement, but I'm not sure how to do that, is there something I could look for in the parrot code? 15:03
barney riffraff: I'm not aware of any HLL with 'goto' 15:10
15:20 riffraff joined
riffraff sorry got disconnected 15:21
I was saying I think perl6 has a kind of goto statement, and php IIRC
thougb probably the semantic is not the same as C's one 15:22
masak riffraff: Perl 6 has a goto, but Rakudo doesn't yet, IIRC. 15:24
Infinoid there is a t/spec/S04-statements/goto.t but it doesn't seem to parse correctly yet 15:25
riffraff ok, thanks 15:29
barney Same with Pipp. There is a goto in PHP, but it is not yet supported in Pipp. 15:30
riffraff it seems I found the trick: interpinfo .INTERPINFO_CURRENT_CONT shall return a callable comntinuation, so hopefully I can then invoke it to get a kind of goto behaviour 15:31
masak riffraff: does that mean you can only goto backwards? 15:32
riffraff masak, ah very true
masak riffraff: actually, worse than that. you can only goto to places you've executed. 15:33
riffraff yep 15:35
15:36 pedr joined
dalek r34424 | bernhard++ | trunk/languages/pipp (2 files): 15:36
: [Pipp] Get rid of $?BLOCK and use @?BLOCK[0] instead.
: Rename $past to $block where appropriate.
: Enter parameters in the symtable of the function or method.
: Reenable the recently todoed OO tests.
review: www.parrotvm.org/svn/parrot/revision?rev=34424
riffraff maybe i can build a block for each label at parse time and .tailcall it from the goto, but that would require explicitly .tailcall every block from the previous one, which seems painful (scope is not an issue in my case, I just have globals) 15:37
15:37 pedr left
masak riffraff: specifically, it might not work if you have a label inside a loop block, say. 15:40
dalek r34425 | bernhard++ | trunk/languages/pipp/src/pct:
: [Pipp] Replace some hard tabs.
review: www.parrotvm.org/svn/parrot/revision?rev=34425
masak riffraff: er, disregard that last part. 15:42
dalek r34426 | bernhard++ | trunk/languages/pipp/t/php: 15:48
: [Pipp] Saner function name in testcode.
review: www.parrotvm.org/svn/parrot/revision?rev=34426
riffraff masak, well yes I guess it can get pretty hairy anyway, but I'm implementing the shakespeare programming language so my problem space us pretty limited :) 15:49
masak googles
oh yes, that one. :) 15:50
riffraff: sounds like a fun project. good luck! I should do something like that too, to get to know PCT better.
15:52 Zaba_ joined
riffraff yes, as of now it 's fun, the only problem is that PCT errors are not extremely useful (i.e. no return value if there is no action for a rule is evil) 15:55
masak aye. 15:56
16:00 jhorwitz joined 16:04 tetragon joined 16:24 kj joined
dalek r34427 | bernhard++ | trunk/languages/pipp (2 files): 16:32
: [Pipp] Support for methods with parameters.
review: www.parrotvm.org/svn/parrot/revision?rev=34427
r34428 | pmichaud++ | trunk/languages/perl6/docs: 16:36
: [rakudo]: spectest-progress.csv update: 264 files, 5905 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=34428
r34429 | pmichaud++ | branches: 16:39
: New branch to refactor parameter, signature, and variable handling.
review: www.parrotvm.org/svn/parrot/revision?rev=34429
16:56 contingencyplan joined 16:59 tetragon joined
dalek r34430 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 17:04
: [Pipp] Add rule <statement_list> in order to simplify actions.
review: www.parrotvm.org/svn/parrot/revision?rev=34430
17:07 nopaste joined 17:18 jq joined
dalek r34431 | fperrad++ | trunk (61 files): 17:23
: [Lua]
: - add a CREDITS file
: - remove POD section AUTHORS
review: www.parrotvm.org/svn/parrot/revision?rev=34431
17:31 peters joined
peters Hello 17:31
masak peters: hello. 17:32
peters How is your game coming along? 17:34
masak peters: github.com/masak/druid/ 17:35
peters: quite well, thank you. :)
dalek r34432 | bernhard++ | trunk/languages/pipp/src/pct (2 files):
: [Pipp] Eliminate rule block in favour of statement_list.
review: www.parrotvm.org/svn/parrot/revision?rev=34432
masak pmichaud: the last thing I wrote was code to check if someone won.
peters masak: cool, looking forward to play with it =) 17:36
jonathan hi all
masak jonathan: OH HAI
peters Hi Jon
jonathan Will be heading home from Christmas break tomorrow, and then back online more often again. :-)
masak \\o/ 17:37
jonathan Looks like pmichaud++ hasn't stopped turning in lots of stuff. :-)
pmichaud jonathan: I'm refactoring variables, signatures, declarations today 17:38
jonathan pmichaud: OK. Status of rakudoreg branch? 17:40
pmichaud jonathan: I decided to do the parameter refactor first. 17:41
jonathan pmichaud: OK
pmichaud I think it'll make more logical sense that way.
jonathan Well, I dodn't see them as hugely related.
pmichaud right. 17:42
jonathan Other than for type captures.
pmichaud also, parameter refactor is huge, and I have a couple of days where I can focus on them now.
jonathan OK, sure.
pmichaud so if I don't do that now, I don't know when I might get another chance
jonathan I'll be traveling tomorrow anyway.
So won't get to look at it again for a bit.
(As in, day or two) 17:43
So works for me.
pmichaud sounds good.
jonathan Having that sorted out will stand me in a good position for dispatch work. 17:44
January should be fun - finishing of type reg stuff, bunch of dispatch stuff, the start of parametric roles. :-) 17:45
And a workshop to round it all off. 17:46
17:49 Andy joined
dalek r34433 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 17:52
: [Pipp] Rename array_arguments to array_argument.
: Simplify instantiate_array.
review: www.parrotvm.org/svn/parrot/revision?rev=34433
masak rakudobug? 17:56
purl rakudobug is mailto:rakudobug@perl.org
dalek r34434 | bernhard++ | trunk/languages/pipp: 17:59
: [Pipp] add fperrad and cotto to CREDITS
review: www.parrotvm.org/svn/parrot/revision?rev=34434
18:20 gryphon joined 18:28 Whiteknight joined 18:33 kj joined 18:38 kj joined
dalek r34435 | kjs++ | trunk/compilers/pirc/new (5 files): 19:02
: [pirc] refactoring of sub structure.
review: www.parrotvm.org/svn/parrot/revision?rev=34435
r34436 | kjs++ | trunk/compilers/pirc/new (4 files): 19:06
: [pirc] refactoring of add_sub_pmc function using new sub_info structure.
: + move a line in yyerror; this makes more sense, to keep print stuff together.
review: www.parrotvm.org/svn/parrot/revision?rev=34436
19:07 chromatic joined
dalek r34437 | kjs++ | trunk/compilers/pirc/new (4 files): 19:13
: [pirc] re-organize bytecode generation stuff a bit.
: + the bytecode struct is now created at the start, so we can add constants before generating bytecode.
: + creating a code segment is now done in a separate step, and should be done right before emiting bytecodes.
review: www.parrotvm.org/svn/parrot/revision?rev=34437
r34438 | kjs++ | trunk/compilers/pirc/new (3 files): 19:16
: [pirc] consting + small update in documentation.
review: www.parrotvm.org/svn/parrot/revision?rev=34438
r34439 | kjs++ | trunk/compilers/pirc/new (4 files): 19:29
: [pirc] add the sub PMC after the sub has been parsed, in the finalization routine for subroutines. This will allow us to store the constant table index by which this sub was stored in the constant table, in the global_label node, which is created for each subroutine. Then, when a subroutine invokes another subroutine, it can find this constant table index.
: + rename const_nr as constant_table_index, which is a bit clearer.
review: www.parrotvm.org/svn/parrot/revision?rev=34439
r34440 | kjs++ | trunk/compilers/pirc/new (3 files): 19:40
: [pirc] store the constant table index for the sub in the global_label node for that sub.
review: www.parrotvm.org/svn/parrot/revision?rev=34440
r34441 | kjs++ | trunk/compilers/pirc/new: 19:47
: [pirc] convert 4 similar statements into a loop.
review: www.parrotvm.org/svn/parrot/revision?rev=34441
Infinoid I've hacked headerizer to give me per-function assert() macros, to verify that some kinds of arguments (ARGIN, ARGMOD, ARGOUT, NOTNULL) really are non-null. they look like: 20:07
#define _PARROT_DOD_CLEAR_LIVE_BITS_ASSERT assert(interp);
#define _PARROT_DOD_FREE_BUFFER_ASSERT assert(pool); assert(b);
#define _PARROT_DOD_FREE_BUFFER_MALLOC_ASSERT assert(b);
#define _PARROT_DOD_FREE_PMC_ASSERT assert(interp); assert(p);
#define _PARROT_DOD_FREE_SYSMEM_ASSERT assert(b);
there are 1709 of them. any complaints about the naming scheme, before I spend a day or so dropping them into all the functions they correspond to? 20:08
kj I believe the acronym 'DOD' is deprecated 20:10
chromatic It is. 20:11
kj there's an rt ticket on that I think
or maybe trac tricket
Infinoid its just an uppercasing of the name of the function
rename the function and the macros will get renamed too
chromatic Fine by me then.
20:12 rhr joined
dalek r34442 | allison++ | branches/pdd22io_part3 (3 files): 20:20
: [pdd22io] Invert 'read' so public interface calls the method, allowing cleaner
: polymorphism.
review: www.parrotvm.org/svn/parrot/revision?rev=34442
tewk Any little c tasks I could do? 20:25
I've started looking at the class registry is there a design plan ther yet?
chromatic I don't think there is. 20:26
The calling conventions refactoring branch could use some attention.
I don't know if Whiteknight's around to comment though. 20:27
tewk is calling_conventions/ the restart based on allison's diff or is it the old mess? 20:29
chromatic I think Whiteknight deleted the old branch and restarted based on a new diff.
tewk good
chromatic He had a commit or two there in the past couple of weeks, so if you see a branch without that, it's the old one.
I think the new branch compiles.
I keep trying to speed up MMD but the overhead is 95% calling conventions, and I don't want to rework those until we get rid of some of the mess. 20:30
20:32 pedr joined 20:33 pedr left
tewk chromatic++ I agree with your NCI comments by the way. 20:33
chromatic Thanks.
More and more I think we should steal wholesale how a mature Lisp FFI or Python's ctypes does things. 20:34
dalek r34443 | pmichaud++ | trunk/compilers/pge/PGE: 20:35
: [pge]: Allow spaces before adverbs in regexes (RT #47996).
review: www.parrotvm.org/svn/parrot/revision?rev=34443
tewk I'll have to look at ctypes. I like NCI generally. 20:36
chromatic It's a great idea, but we do only handle a fraction (if significant) of the available signatures. 20:37
Tene tewk: allison tells me that at PDS it was established that we do need to include the HLL name in the type registry
tewk: so that's a mostly straightforward design
tewk pmichaud: have you had a chance to look at the nsentry branch? its going to bit rot.
Tene, that makes sense, I was thinking the same. 20:38
Tene There are a few remaining issues about whether we just use the currentl HLL when looking up types and if so how we get a type from another HLL, and if not do we then require everyone to always specify the HLL, and is that an issue?
etc.
Mostly minor things, though. I think that PM was in favor of just always requiring the HLL name. 20:39
tewk Where do type lookups occur? new?
Tene there's also an opcode to get the class 20:40
the simple PIr case you want to try is something like .HLL 'foo'; then make a new String class or some such
20:43 apeiron joined
pmichaud when looking up types, I think we should distinguish 'XYZ' from ['Foo';'XYZ'] somehow. 20:48
sorry
rephrase
when looking up types, I think we should distinguish 'XYZ' from ['XYZ'] somehow.
I'm definitely _not_ in favor of always requiring the hll name in the PIR code -- much too much will break. 20:49
i.e., ['parrot';'XYZ'] is just asking for trouble. 20:50
dalek r34444 | kjs++ | trunk/compilers/pirc/new (12 files): 20:51
: [pirc] implement emission of .const items.
: I'm not entirely happy with the lexer having to distinguish between .const identifiers and all other identifiers: now .const identifiers hide ops and all other identifiers, such as .locals. For now, this works.
review: www.parrotvm.org/svn/parrot/revision?rev=34444
20:55 Theory_ joined
pmichaud Here's my (not completely thought out) proposal: 20:55
(1) Keep the type registry as it is now, but attempting to
create a class with an existing name doesn't carp (and doesn't change
the registry).
(2) $P0 = get_class 'Foo' and $P0 = get_class $S0 always looks up a
class in the global registry.
(3) $P0 = get_class ['Foo'] always looks up a class corresponding to the ['Foo'] namespace in the current HLL.
(4) To obtain a class from another HLL, it's necessary to first get the foreign HLL namespace and then obtain the class from that.
Similar rules apply for newclass and subclass ops.
chromatic Seems sane to me. I especially like #1. 20:56
pmichaud This seems to give the most flexibility with the least amount of breakage. In particular, it means that HLLs can continue to get to Parrot's 'Integer', 'String', 'ResizablePMCArray' etc. types without having to go through lots of hoops to do so. 20:57
Then, if I need Parrot's Integer type, I do $P0 = get_class 'Integer'
if I need my own local Integer type, I do $P0 = get_class ['Integer']
If I need someone else's Integer type, I do $P0 = get_root_namespace ['otherhll';'Integer'] $P1 = get_class $P0 20:58
Tene Different behavior for strings, keys, and namespaces feels awkward to me and possibly a source of bugs or confusion for new parroters in the future. I don't think that those concerns make it a bad idea, though.
I tentatively like this design.
pmichaud we already have different behavior for strings/keys/namespaces in the get_*_namespace opcodes, though. 20:59
at least, potentially different behaviors.
chromatic This is consistent, too; none of Parrot's built in classes/PMCs have compound names.
pmichaud I do think it important for HLL's to still have a convenient way to get to Parrot's builtin classes. 21:00
I haven't thought much about what this might imply for the 'isa' opcode, however.
(which needs fixing anyway, imo)
Tene And how does it affect things if an HLL dev wants to use the builtin Parrot Integer, but his custom String subclass? Does he need to arrange for the compiler to generate different get_class ops for the two different types of classes? 21:01
pmichaud best option for such a developer would be to subclass or import parrot's Integer into the local namespace 21:02
Tene Okay.
kj store the built-in class in the HLLs namespace
Tene That's reasonable.
pmichaud of course, rakudo and PCT never really run into this issue because they use protoobjects as handles to all of the classes anyway. 21:03
Tene Yeah, I approve this design too.
pmichaud (except for some of Parrot's builtins.)
in PGE/PCT/rakudo the only things that really ever use get_class, subclass, or newclass are those things that are dealing with metaclasses in the first place. 21:04
s/metaclasses/metaobject programming/
dalek r34445 | kjs++ | trunk/compilers/pirc/new (3 files): 21:05
: [pirc] no need to store the constant table index in the constant node; it was already handled automatically by existing code.
review: www.parrotvm.org/svn/parrot/revision?rev=34445
Tene tewk: haven't seen you comment... you getting this?
21:08 PacoLinux joined
tewk back 21:08
kj woohoo! pirc emits code for sub calls :-) 21:17
dalek r34446 | kjs++ | trunk/compilers/pirc/new: 21:18
: [pirc] first hacky attempt to do sub invocations.
review: www.parrotvm.org/svn/parrot/revision?rev=34446
pmichaud tewk: (nsentry) I'll definitely get to looking at it in the next 24 hrs. 21:25
tewk: I'm not too worried about bitrot -- most things in rakudo are actually moving closer to nsentry compatibility, not farther away from. :-)
dalek r34447 | kjs++ | trunk/compilers/pirc/new: 21:30
: [pirc] refactor a bit and generate a signature PMC for auto-leave-instructions in a sub. Now the :main flag is no longer needed to run PIRC with -b option (and not segfault).
review: www.parrotvm.org/svn/parrot/revision?rev=34447
r34448 | pmichaud++ | trunk (4 files): 21:36
: [pge]: Initial implementation of goal matching '(' ~ ')' <expr>
review: www.parrotvm.org/svn/parrot/revision?rev=34448
Whiteknight Im here now 21:37
dalek r34449 | kjs++ | trunk (2 files): 21:42
: [pirc] generate a fixedintegerarray, not a ~pmcarray. THe problem was that you can't resized a FIA to 0 elements, so only do the resize if size > 0. Also add a NEWS entry for PIRC with this progress.
review: www.parrotvm.org/svn/parrot/revision?rev=34449
21:53 Zaba joined
dalek r34450 | kjs++ | trunk/compilers/pirc/new: 22:01
: [pirc] rename some stuff and remove some old comments.
review: www.parrotvm.org/svn/parrot/revision?rev=34450
22:13 Andy joined 22:17 kid51 joined
kid51 New test failure in t/compilers/pge/perl6regex/01-regex.t 22:17
Unable to open filehandle 22:18
not ok 755 - [rx_syntax:41] bare : after |+sp
Developed somewhere between r34444 and r34449.
22:18 geof joined
kid51 smolder.plusthree.com/app/public_pr...m/9874/342 22:20
shorten kid51's url is at xrl.us/beasdh
kid51 Must be something Patrick is up to: ------------------------------------------------------------------------ 22:24
r34448 | pmichaud | 2008-12-27 16:36:20 -0500 (Sat, 27 Dec 2008) | 2 lines
[pge]: Initial implementation of goal matching '(' ~ ')' <expr>
pmichaud oh, I forgot to add a file. 22:26
dalek r34451 | pmichaud++ | trunk (2 files): 22:29
: [pge]: Add test file omitted from r34448 (kid51++)
review: www.parrotvm.org/svn/parrot/revision?rev=34451
r34452 | pmichaud++ | trunk/compilers/pct/src/PCT:
: [pct]: Add smarter version of FAILGOAL rule for grammars.
review: www.parrotvm.org/svn/parrot/revision?rev=34452
r34453 | pmichaud++ | trunk/languages/perl6/src/parser:
: [rakudo]: Update grammar to use goal matching syntax.
review: www.parrotvm.org/svn/parrot/revision?rev=34453
kid51 magnachef ping 22:34
dalek r34454 | pmichaud++ | branches: 22:37
: Drop branch to start anew with new trunk (PGE) changes.
review: www.parrotvm.org/svn/parrot/revision?rev=34454
22:46 nopaste joined 23:08 brunoV joined
kid51 Smolder reports now reporting no failures on FreeBSD. 23:21
23:22 gryphon joined
tewk So my plan for class registry is to add one to the hll info struct. 23:23
The global one will exist mainly for top level parrot pmcs 23:24
Do we have syntax to specify the HLL of dynpmcs?
If not we should add it. 23:25
23:29 TiMBuS joined
pmichaud tewk: when would the hll class registry get used? 23:30
and did you see my proposal earlier? 23:31
tewk pmichaud: yes I saw it, when you use keyed access [] 23:34
I guess I could just use the global one and serialize the FQN of the class as the key to the class registry
pmichaud ....no 23:35
keyed access doesn't use the hll class registry, it uses the namespace
since every class has an associated namespace
there's no need for a "hll class registry"
basically, $P0 = get_class ['Foo'] is the same as 23:36
$P1 = get_namespace ['Foo']; $P0 = get_class $P1
(or perhaps get_hll_namespace there, depending on whether we want to search from the root or from the current namespace.)
tewk ok 23:37
pmichaud at least, that's the way I was thinking of it.
tewk so what goes in the registry then, just core pmcs.
dalek r34455 | petdance++ | trunk/compilers/imcc (2 files): 23:44
: making internal functions static
review: www.parrotvm.org/svn/parrot/revision?rev=34455
pmichaud well, everything goes in the registry 23:45
it just doesn't carp about duplicates
(and hll implementors would be wise to avoid the registry except for the core types) 23:46
that was my point #1 -- leave the registry as is, just make it so it's less annoying
or, phrased another way
if I do
$P0 = newclass 'Foo'
then 'Foo' goes into the registry, and later get_class 'Foo' will grab it from the registry 23:47
if I do
$P0 = newclass ['Foo']
then I (pmichaud) don't really care if it goes in the registry or not. Probably better if it doesn't.
if I do
$P0 = get_namespace ['Foo']; $P1 = newclass $P0
then it doesn't go into the registry. (This is current Parrot behavior)
so, the only time things go into the registry: 23:48
when creating a class using a string or string constant with newclass or subclass ops
when explicitly giving a class a name via the .name method
in either case, the registry doesn't complain about the duplicate name, or it's a catchable exception that we can ignore 23:49
tewk I think I got it, going to take a look at code 23:51
dalek r34456 | jkeenan++ | trunk/compilers/pct/src/PCT: 23:53
: Eliminate trailing whitespace.
review: www.parrotvm.org/svn/parrot/revision?rev=34456
23:57 apeiron_ joined
dalek r34457 | petdance++ | trunk/compilers/imcc (2 files): 23:59
: staticing and localizing
review: www.parrotvm.org/svn/parrot/revision?rev=34457

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!