Parrot 1.1.0 Released | parrot.org/ | 332 RTs left
Set by moderator on 21 April 2009.
00:03 bacek_ joined 00:09 AndyA joined 00:19 darbelo left
Coke anyone have thoughts on what we should do with milestone tickets for milestones that have passed? I hesitate to auto-bump them to the next release. 00:35
Infinoid I suppose there should be some kind of review process to find a time slot (and possibly someone with more tuits) 00:36
maybe group them with a "late" tag if there are a lot of them? 00:37
Coke they already have a milestone, no need to add more meta info. 00:40
rg since they have proved to not be essential enough for anyone to care, i'd just remove them. 00:43
Infinoid not having time != not caring 00:45
all these milestones set a pretty brisk development pace, to be honest. 00:46
rg wrong choice of words maybe. i didn't want to offend anyone.
cotto I guess we forgot to review them during #ps today. 00:47
Infinoid and unfortunately, all the milestones I've signed up for so far (website migration, packfile stuff) have proved to be quite remarkably boring. :)
cotto After all the PMC hackery I was doing, I though it'd be nice to have some documentation to work on. 00:48
not the case
Infinoid heh
cotto especially when it's not inline documentation
I start documenting, and suddenly vacuuming my apt looks attractive. 00:49
Infinoid oh, don't get me wrong, I've gotten quite a lot of useful things done as a result that I wouldn't have otherwise. But I haven't made much progress on the actual tasks
Coke cotto: I was going to review them, but it's not like we were going to do any of them in 5m. 01:10
cotto I have to wonder how much of tewk's work will be reusable if we're eventually going to switch over to writing PMCs and ops in L1.
Coke the time to review them was last week. We'll do better next release.
cotto Coke, this is true.
Coke if tewk finishes before the L1 stuff hits, he wins. =-)
cotto s/L1/L1 ops/ 01:11
which he will, since L1 is only a sparkle in chromatic's eye
more familiarity with LLVM will help us in any case 01:12
rg if more than just tewk become familiar with llvm ;) 01:13
Infinoid a tewk familiar with llvm is better than no tewk familiar with llvm 01:19
01:32 eternaleye joined
dalek rrot: r38263 | whiteknight++ | trunk/docs/book/ch09_pasm.pod:
a number of major improvements and rewrites to the second quarter of chapter 9. This chapter is far too huge to all the necessary improvements in one commit
 01:34
bacek_ hi there 01:45
"L1"?
what is it?
purl it's it!
01:49 AndyA joined
rg some discussion (including jit) that went around here: irclog.perlgeek.de/parrot/2009-04-21#i_1083550 01:52
ah no even before that
the whole thing started about here: irclog.perlgeek.de/parrot/2009-04-21#i_1083259 01:53
02:07 kid51 joined, rdice joined
bacek_ wow. Sounds good. 02:10
02:24 amoc joined 02:29 darbelo joined 02:39 fperrad left, dukeleto joined 02:41 janus joined 02:44 Fayland_logger joined
kid51 From the channel message, I take it that the release is complete. Okay to resume commits? 02:46
02:51 wayland_ joined
rg kid51: yes, there have been quite a couple already. 02:57
kid51 thx 02:59
03:19 gryphon joined
dalek rrot: r38264 | jkeenan++ | trunk/src/packfile.c:
Applying patch submitted by Andy Dougherty in

coding standard test..		 03:24
03:32 cspencer joined
cspencer parrot has the "compose" opcode which normalizes a unicode string, and reading through some of the unicode docs, i note that there're four normalization forms (NFD, NFC, NFKD and NFKC) - is there a way of specifying which one you'd like? 03:39
03:53 dukeleto joined
Infinoid he: I've split your netbsd-alpha patch into two issue-focused patches, and created two tickets: #573 and #574. I didn't have time tonight to do any actual fixing, but I think I've got the current state of things documented. 04:29
04:37 tetragon joined
Infinoid Hearing no objection to the TT #571 patch, here it comes. 04:39
dalek rrot: r38265 | Infinoid++ | trunk/config/gen/makefiles/CFLAGS.in:
[config] Apply patch from doughera++ in TT #571:
 04:40
eternaleye Hm, NEWS contains 'Add another dumper format to assist syntax highlighters 04:51
How do I invoke that?
It sounds interesting
Infinoid trac.parrot.org/parrot/changeset/38208 04:55
04:55 Fayland_logger joined
Infinoid Apparently you invoke a pct compiler object with the --dumper option, or something like that. I'm not really sure. 04:56
Tene --dumper=padre
doesn't look like rakudo supports it... 04:57
Infinoid invoking as ./perl6 --dumper=padre <somefile> takes the option but doesn't do anything visible with it 05:01
baest try perl6 --target=parse --dumper=padre <file> 05:10
05:12 Andy joined 05:33 allison joined
cotto allison, do you know off the top of your head what kind of PMCs should have need_ext? It doesn't seem to be especially well-documented. 05:45
allison it used to be PMCs that used the 'data' member, but we moved that into the core struct. Any PMC that does a custom mark will need it. 05:46
let's see...
cotto It contains _synchronize, _metadata and _next_for_gc
allison properties, that's the other big one 05:47
_synchronize is used for some forms of thread sharing
it was used for the old STM, but we've ripped that out
cotto There are still some places where _synchronize is used. Should I try ripping them out and seeing what happens? 05:48
allison looks like it's only used in the PMC_sync macro 05:49
checking where the macro is used...
cotto right, but that's used in a half-dozen places
allison in the gc and in HLLs 05:50
it's probably safe to remove 05:51
not certain, but likely
cotto Sounds worthwhile.
If all PMCs are GC'd, why do only some need the PMC_EXT, with its _next_for_gc? 05:52
allison cotto: it's only used for PMCs with children that need marking 05:53
it's a bit of a hack, and will likely be removed eventually
which would leave us with only properties 05:54
cotto ok, so all aggregate PMCs should have need_ext?
allison which could be handled as an attribute in 'data', if we really wanted it 05:55
cotto: aggregates of strings or PMCs, yes
you could have an aggregate of, say, integers that manages a chunk of memory directly instead of GC allocating its children
cotto ok 05:56
What uses _metadata? 05:57
allison that's properties
set_prop and get_prop 05:58
setprop and getprop vtable function
cotto Ok. So it's implementation-dependent how properties are used, but if you want them you need need_ext. 05:59
allison well, sneakily, Parrot will add pmc_ext if you call setprop and don't have it 06:00
so, even if you don't set need_ext, you'll get it 06:01
cotto I saw a function that looked like it could dynamically add PMC_EXT to a PMC. It's nice that Parrot dtrt there.
So it's not strictly necessary for properties, although a generally good idea. 06:02
allison it could be argued that the _metadata pointer should live in the core struct, but properties aren't common enough yet
aye
it's a short cut if you know you're going to need pmc_ext anyway 06:03
I don't see the usual "go ahead and start committing again" message on the mailing list 06:13
cotto fperrad said it was fine earlier 06:14
allison but, I do see fperrad tagged the release
okay, I'll go ahead then
dalek rrot: r38266 | allison++ | trunk/tools/util/release.json:
[cage] 1.1 lives in the 'devel' directory. (And so will the next few
 06:15
06:21 iblechbot joined
cotto allison, I've got a patch that removes _synchronize. The build works and I'm running make test. 06:23
If make test passes, do you have time to give the patch a once-over? 06:24
allison sure
06:24 uniejo joined
Tene allison: I have some questions about load_language... 06:27
allison aye?
purl I!
Tene allison: it looks like the standard is to have languages with uppercase names and pbc files with lowercase names, yes?
perl6.pbc
compreg 'Perl6' 06:28
allison seems to be
Tene Right?
allison yes
Tene So should the hll downcase the arg to load_language, or should load_language downcase its arg?
allison load_language doesn't do compreg 06:29
Tene Right.
I know.
nopaste "cotto" at 96.26.202.243 pasted "patch to remove _synchronize from PMC_EXT" (223 lines) at nopaste.snit.ch/16371
cotto allison, incoming
allison but you're suggesting the name passed to load_language should look the same as the one passed to compreg?
Tene allison: I'm asking whether it should or not. 06:30
allison (or at least should be able to look the same)
Tene Right.
allison (thinking...)
I'm okay with adding downcasing
Tene Or, perhaps, compreg should be case-insensitive? 06:31
regardless, I think we need some standards here.
allison maybe case-insensitive, or maybe we should just standardize on one case everywhere
Tene Right. 06:32
allison so, it's 'Perl6' everywhere, or 'perl6' everywhere
Tene I'd also be okay with Perl6.pbc, for example
allison but not swapping between the two all the time
and 'Perl6' as the name of the namespace
(the HLL namespace)
Tene iirc, hll namespaces are already specced as case-insensitive
allison blech :( 06:33
allison has been bitten by case-insensitive file-systems
Tene also
allison on the whole, I'm happier with asking HLLs to pick a case and stick with it 06:34
than messing with downcasing (and maybe also upcasing) in various locations
but, it's a question to put to the general pool of HLL developers
Tene nods 06:35
perhaps someone should post to the list.
allison a summary of this irc conversation would do 06:36
Tene allison: if I can get a partial port of rakudo to its own HLL namespace, up to the part where it breaks due to PMC HLL issues, will you have tuits to work on it sometime soon, or are you pretty booked?
allison yes, I can take a look
dalek kudo: fd0a4d5 | (Stephen Weeks)++ | src/builtins/control.pir:
Use load_lang opcode for eval with :lang
 06:37
shorten dalek's url is at xrl.us/bepvhp
allison cotto: the patch looks good 06:38
cotto: I'm not sure how good our threading tests are, so might want to run a few thread test examples aside from our official test suite 06:39
cotto as in write some new ones? 06:40
allison just to be sure shared variables still work (that is, to make sure it was only STM that was using _synchronize)
cotto: yeah, or just take a quick skim of the existing ones and see if they cover the common cases (specifically, if they cover shared variables) 06:41
Tene okay, sent. LEt's see if my mail to the list actually goes through this time.
(often doesn't) 06:42
oh, went straight through, no problem
huh
06:43 chromatic joined 06:44 dukeleto joined
allison Tene: your address might have been on the "needs approval" list, and I might have set it to "always accept" (I don't remember doing it with your address specifically, but I've certainly done it with a number of other addresses) 06:44
Tene ah
:)
cotto allison, what would a proper test for shared variable synchronization look like? modify a shared aggregate rapid-fire and make sure it doesn't end up corrupted? 06:58
s/aggregate/aggregate PMC/
allison I'm not even sure we're testing basic synchronization, create a variable, modify it from two different threads 06:59
but, yes, stress testing would be a good addition
cotto The thread tests seem a little sparse. I'll add some more before committing the patch. 07:00
It's funny how many tangents updating docs/pmc.pod has involved. 07:03
allison :) 07:15
07:36 rblasch joined 08:00 fperrad joined 09:06 mikehh joined
dalek tracwiki: v91 | fperrad++ | Languages 09:23
tracwiki: Update with Parrot 1.1.0
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
shorten dalek's url is at xrl.us/bepvvu
cotto allison, are you still up? 09:48
or anyone who knows how to use threads in pir
09:49 he left
dalek tracwiki: v92 | fperrad++ | Languages 09:49
tracwiki: More update with Parrot 1.1.0
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff 09:50
shorten dalek's url is at xrl.us/bepwre
nopaste "cotto" at 96.26.202.243 pasted "attempt to get two threads reading/writing a shared PMC" (51 lines) at nopaste.snit.ch/16374 09:51
bacek cotto: threads in parrot are pretty useless because of disabling GC... 10:17
cotto goodie 10:21
so can stuff be shared between threads at all more than from parent to child? 10:27
Hmmm. Threads don't seem to be on either roadmap. 10:39
bacek cotto: try it with PARROT_CLONE_DEFAULT ( or just use "run_clone" which is equivalent) 10:43
cotto bacek, no dice 10:45
I get the feeling that this isn't something Parrot wants me to do. 10:48
bacek really want to create "pmc_pct" branch to rewrite pmc2c in PCT. 11:05
cotto you'd be loved and your name would be held in high esteem 11:06
bacek Even for just creating branch? :) 11:07
cotto we have low standards around here 11:08
bacek my own standards are little bit higher... 11:09
dalek rrot: r38267 | bacek++ | branches/packfile_revamp:
Removed packfile_revamp branch. It was merged into trunk
 11:12
kudo: d0a5de5 | (Moritz Lenz)++ | src/setting/Match.pm:
Match.perl: work around RT #64952
 11:15
shorten dalek's url is at xrl.us/bepwu6
dalek rrot: r38268 | fperrad++ | trunk/config/gen/makefiles/root.in:
[build] fix warning on Windows (introduced by r38256)

makefile:636: warning: ignoring old commands for target `.s.o'		 11:16
11:30 cognominal joined 11:35 ruoso joined
mikehh Method 'log10' not found for invocant of class 'Complex' after ok 27 - got the log10 of -i (complex unit) 11:50
moritz mikehh: I just fixed the test 11:51
mikehh sorry wrong channel
moritz happens to me all the time 11:52
mikehh moritz: jolly good show and all that sort of stuff :-} 11:54
12:05 Gerd joined
dalek rrot: r38269 | fperrad++ | trunk (2 files):
[chm] add pdd15_object_metamodel image
 12:07
Gerd Hello Allison!
Allison: Do you already read my last email? 12:09
coke_afk (case) yes, pick a case and stick with it. 12:31
12:37 rg1 joined 12:59 rdice joined 13:03 gryphon joined 13:12 wayland_ joined
dalek rrot: r38270 | pmichaud++ | trunk/compilers/pct/src (2 files):
[pct]: loadinit handling in PAST/POST compilation now works for 'compiler' nodes
 13:13
13:27 iblechbot joined 13:28 particle1 joined
Coke pmichaud: you about? 13:46
pmichaud Here.
13:46 gryphon joined
Coke messages eraseblahblahboo 13:48
(thanks, purl. =-)
pmichaud: was wondering on the status of some very old PGE tickets. let me findz them.
pmichaud in all probably they are still significant. 13:49
*probability
13:49 PacoLinux joined
Coke turns out there's more than I thought. 8 RTS with PGE in the subject. 13:51
Yah, I figured you'd have rejected them by now if they weren't relevant. 13:52
pmichaud I can see about moving them to Trac, though.
and comment on them that "yes, this is still relevant."
Coke eh.
pmichaud Although I think a couple of them got closed this past weekend :-)
Coke We don't have to move to trac. I've done that for a few tickets where there's no history and we can just cut and paste the original post. 13:53
have to move to tracy *immediately*, anyway.
rt.perl.org/rt3/Ticket/Display.html?id=53464 would be a fine candidate to move, e.g., esp if it's not getting closed anytime soon.
pmichaud oh, I might be able to resolve that one soon. 13:54
13:54 Andy joined
pmichaud I might even be able to delegate it to someone who did some PGE hacking at NPW 13:54
Coke that would be awesome. (delegation)
right now our PGE bus number is somewhere between 1 and 2.
13:59 he joined
nopaste "he" at 158.38.152.119 pasted "...and another architecture tested, ref. smolder 20336, diff to PLATFORMS" (12 lines) at nopaste.snit.ch/16376 14:03
Coke he? 14:06
purl well, he is Havard Eidnes <mailto:he@NetBSD.org>
dalek kudo: 04ee8d0 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 374 files, 10467 passing, 0 failing
shorten dalek's url is at xrl.us/bepxas
Coke he: committed. 14:07
dalek rrot: r38271 | coke++ | trunk/PLATFORMS:
[docs] another platform passing

  [t] revert r38202 (release done)		 14:10
14:10 dalek joined
he Coke: thanks. 14:12
Infinoid he: I've split your netbsd-alpha patch into two issue-focused patches, and created two tickets: #573 and #574. I didn't have time tonight to do any actual fixing, but I think I've got the current state of things documented. 14:21
oh... I see you already found #574. nevermind :) 14:22
he :) 14:25
14:37 he left
Coke now gets to write some RE stuff in cf. gah. 14:37
14:43 masak joined
Coke ... I can't seem to find a substring variant in CFMX that /replaces/, only extracts. 14:50
(I do find a very long thread where someone asks this question and is told they'd be fired if they worked for the repsonder.) 14:51
rg1 the things we've come to expect from our favourite language ;) 14:57
Infinoid fired for asking about search and replace, or fired for using CF in the first place? 15:05
Coke: When will parrot get CF? :) 15:07
Coke Infinoid: for asking the question without checking the docs. 15:09
and while the OP was vague in what it wanted, the obvious (to cfmx people) answer was pretty obvious.
Infinoid: Never?
purl Well, hardly ever!
Coke Infinoid: If there were no licensing concerns, it'd be doable. 15:10
except for the part where CFMX has tight integration with flash & pdf because it's adobe, and that it's written in Java currently.
Infinoid wants lolfusion 15:12
15:15 slavorgn joined
Infinoid allison: As we discussed yesterday, src/pmc/class.pmc:338 calls Parrot_pcc_build_sig_object_from_varargs with a NULL va_list argument, which fails to build on platforms where va_list is a struct type and not a pointer. It then calls Parrot_pcc_invoke_from_sig_object() with the result, but it doesn't look like I can pass PMCNULL there. 15:22
Unfortunately, I don't know PCC at all. How much of what we discussed yesterday is already there and ready for use, and how much infrastructure do we still need to add for the PMCNULL_SIGNATURE stuff you suggested? 15:23
15:24 he joined
Infinoid There's a ticket for this, #573, but I'm hoping for a little guidance to find a better fix (the current patch changes a bunch of APIs) 15:24
15:30 cspencer joined 15:33 Theory joined
allison Infinoid: the solution is to not call Parrot_pcc_build_sig_object 15:46
Infinoid: at the moment, the system isn't set up to handle a PMCNULL in place of a sig object, but a sig object with no arguments or returns will work just fine 15:48
that is, just "pmc_new(interp, enum_class_CallSignature)" 15:49
no build or extensions
Infinoid ah, cool. I'll try that in place of the Parrot_pcc_build_sig_object_from_varargs, thanks!
Coke allison: you'd probably know the answer to this question: are there any legal ramifications to implementing a coldfusion-alike on top of parrot? 15:52
Not, mind you, that I'd advocate that insanity. 15:53
allison as long as we aren't using their code, no legal problems at all 15:54
copyright doesn't protect them from someone implementing the same interface
(I could see someone wanting it) 15:55
particle you're both sick. 15:56
Coke allison: I do wonder if their online docs have any kind of eula. 15:57
"if you read these, you agree not to harsh our buzz." 15:58
16:01 davidfetter joined
nopaste "tene" at 166.70.38.237 pasted "full bt for Match issue" (15 lines) at nopaste.snit.ch/16377 16:08
Khisanth docs with eula? O_o 16:09
16:12 rblackwe joined 16:15 HG` joined
davidfetter Khisanth, it's not the wackiest thing i've seen :P 16:16
nopaste "Infinoid" at 75.140.33.106 pasted "Patch implementing allison++'s suggestion for TT #573, unfortunately it doesn't quite work (error message included)" (29 lines) at nopaste.snit.ch/16378 16:18
allison Infinoid: set the string value of the sig_object to a CONST_STRING "->", that should take care of it 16:22
Coke: very possible, though those sorts of limitations are usually put on "using" the software 16:23
Infinoid with "->" I get "too few arguments passed (0) - 1 params expected" 16:26
allison is it a method or a sub? 16:27
davidfetter hi allison. how'd the talk go last night?
<-- couldn't make it :P
allison Infinoid: if it's a method, then it needs the invocant added as an argument
davidfetter: it went well, good crowd, good questions 16:28
davidfetter cool :)
allison (I have two more talks at Bay Area user groups in the next couple of months)
Infinoid I think it's trying to call init() on a base class, so it must be a method
davidfetter where? 16:29
allison Infinoid: okay, I have to go catch a plane, but will be back online in about 3 hours and can look at it then
davidfetter bon voyage :)
Infinoid I'll rtfm and see if I can figure it out
thanks! 16:30
allison davidfetter: PenLUG and SVLUG
adios
Infinoid he: I'm concerned that there may be other build failures caused by the va_list type issue. But I've got a patch to fix this particular NULL case, are you able to test? 16:38
nopaste "infinoid" at 75.140.33.106 pasted "TT #573: This patch builds and tests successfully on Linux/x86-64." (25 lines) at nopaste.snit.ch/16379
16:45 braceta joined 16:58 fperrad joined 17:01 flh joined 17:05 jan joined 17:21 darbelo joined 17:22 japhb joined 17:25 helozjisky joined 17:36 LylePerl joined
LylePerl I'm having an issue with parrot Configure.pl and ActiveState 5.8 17:39
particle 5.8.what?
LylePerl ActivePerl 5.8.8 is compiled with MSCV++
So parrot is assuming MSVC++ and failing (most people with ActivePerl wont have MSVC++) 17:40
ActivePerl 5.10 is compiled with gcc so it's not an issue
I was wondering if it's worth my writing a patch so that it'll check for MSVC++ and if not available default to MinGW instead... 17:41
particle no
17:41 jhorwitz joined
particle you need to specify the compiler on the command line 17:41
perl Configure.pl --cc=... etc 17:42
see --help
LylePerl yes, but I thought it's be easier for people if it just worked straight away?
cspencer is anyone here familiar with the parrot "compose" unicode normalization opcode?
particle what if msvc and mingw are available?
LylePerl Then default to msvc like it is already 17:43
particle LylePerl: maybe compiler detection is broken... hrmm.
LylePerl As far as I could see it picks up the compiler from Perl 17:44
Is there a detection module that overrides it?
rg i believe there isn't really such a thing as compiler detection. short of specifying the compiler, it's "use whatever was used to compile perl"
LylePerl config/init/defaults.pm get's it from Perl's Config 17:45
particle does perl built with msvc work with xs modules built with mingw gcc? 17:46
LylePerl Yes, for the most part
I read a post about it on the ActiveState list, there are only some specific windows XS modules that have issues 17:47
But they may well have been fixed now, with 5.10 using mingw
particle well, if you want to monkey with compiler detection, feel free, but i can't imagine too many users with AS perl 5.8 and mingw gcc compiling parrot 17:48
i just don't want to be the guy supporting it, is what i'm trying to say. it's not that i don't think it's not valuable, as i like it when things Just Work.
rg well i could build a similar scenario on solaris, but i'm contempt with just specifying the compiler on the command line 17:49
LylePerl I'm just thinking that most the Win32 hosting companies that I've come across who support Perl are using AP 5.8.x 17:50
17:51 barney joined
LylePerl If they gave parrot a try, it would be good if it just worked 17:52
particle they're more likely to try rakudo than parrot 17:53
but, yeah.
rg i'd also expect most windows users to look for a binary or even installer package
particle yes, which we have, too 17:54
Tene entertained by s/content/contempt/
rg happy to be of service ;)
LylePerl Yes, and rakudo just trys to run Configure.pl with defaults to install parrot (that's why I was trying to do)
Infinoid Contempt-type: application/x-foadiafoa+xml
17:55 HG` joined
moritz LylePerl: rakudo's Configure.pl can pass arguments to parrot's Configure.pl 17:58
17:59 szabgab joined
NotFound What will be a good compiler detection stratregy: try all .exe in the system? ;-) 18:01
Infinoid Did the new parrot tarball ever get uploaded to the ftp site?
NotFound: In sha1 order
Tene pmichaud: I'd love to get comments from you on the HLL name case issue on the list 18:02
NotFound If we implement a compiler detection we must provide a way to overrida if it fails... hey, we already have that
So the detection will only be useful for people stupid enough to install C compiler without even knowing. 18:04
rg lyleperl: seems like a lot of people here seem to think your time could be better spent elsewhere ;)
notfound: no the detection will be useful for people who get a perl binary from someone using a compiler they don't have.
LylePerl I'm trying to think Windows mentallity 18:05
NotFound rg: 99% of that people will not have any C compiler. At least 50% of them even doesn't know what is a compiler
Infinoid and 85% of those 50% don't know or care about parrot, they just want rakudo 18:06
LylePerl Most of them will probably struggle to open a command prompt. People usually give up if there isn't an install.exe or setup.exe
NotFound Then point them to a binary
particle ...which we have.
fperrad see parrotwin32.sourceforge.net/ 18:07
Coke yah. packing FTW. 18:22
... sigh.
"packaging"
davidfetter wonders whether Coke's packing 18:32
Tene It's interesting having a boss who open-carries. 18:33
davidfetter wonders if every finite open carry has a finite sub-carry 18:34
er, if every open carry*
18:37 iblechbot joined
Coke given my line of work, open carry would be very wierd. 18:43
davidfetter what line is that? 18:46
purl line that is, like, dying is actually IN the bash script. SilverStr is wondering if I should be forking there instead
davidfetter open the pod bay doors, purl
purl I'm sorry, davidfetter, I'm afraid I can't do that. I still have the utmost confidence in the mission.
18:47 whoppix joined
davidfetter finds open carry pretty weird in light of its universal and explicit threat of death 18:47
wayland_ Modern people have a historically unusually high fear of death 18:49
PerlJam davidfetter: it's the same policy the USA and Russia have been following. "I know you can hurt me and you know I can hurt you, so let's not hurt each other even though we can"
wayland_ (I suspect, anyway)
For a while, this was referred to a "Mutually Assured Destruction" 18:50
However, I think "Mutually Assured Non-destruction" is probably a better term now :)
And I'll have to remember the acronym for future reference :) 18:51
18:59 rblasch joined
pmichaud phone, today? 19:00
I guess that wouldn't be for another 60 mins, though.
19:07 HG` joined
dalek rrot: r38273 | coke++ | trunk/t/compilers/imcc/syn/regressions.t:
[t] add a test for TT #575
 19:17
Coke pmichaud: trying out the obvious fix. Will let you know.
changing LEXICAL STRINGC to LEXICAL any_string still fails the same way. 19:21
pmichaud I could understand it failing; failing "the same way" is a bit surprising, though. 19:23
Coke it still says it's expecting a STRINGC. 19:24
doesn't look like .y needs any special protection for sub rules. (so that any_string should be self contained when I use it in the LEXICAL rule)
trying 2 explicit rules, just to see... 19:25
nope. 19:26
something odd, since if I just replace STRINGC with USTRINGC there I get the same error. 19:30
AH! multiple lexical rules. wtf. I wonder how this other one ever gets called. =-) 19:31
# Lexical '$Ī²ĪæĪæ' not found 19:32
pmichaud ah, that's getting closer, then.
19:33 rblasch1 joined
Coke I suspect IMCC's set_lexical needs to be smarter about strings. 19:34
hurm. this might be fixable... 19:35
19:41 szabgab joined 19:47 allison joined
Coke pmichaud: passing that TODO, running a 'test' now. 19:51
pmichaud yay!
Coke allison;functions used only internaly by IMCC are changeable with no notice, neh?
or anyone. =-) 19:52
pmichaud: I was changing the /pasm/ rule originally which I why I got nowhere. =-)
pmichaud a-ha 19:53
interesting (and amusing)
me, I would've been lost for most of it. :-)
Coke eh. not like I know what I'm doing, really. 19:54
Infinoid Coke: if it's something that isn't tagged with PARROT_EXPORT, I wouldn't hesitate to change it
Coke bah. I only changed C code. now running perlcritic.t ... 19:55
jhorwitz pmichaud: having a mod_perl6 regression failure. i create a class in PIR and register it w/ P6metaclass. but then in rakudo Foo.new() tries to invoke Foo() before calling the 'new' method, which fails miserably. ideas? 19:57
i can paste if necessary 19:58
dalek rrot: r38274 | coke++ | trunk (4 files):
[imcc] - allow unicode lexical identifiers. (Fix TT #575)
pmichaud Sounds like Rakudo is reading Foo as a listop instead of a typename.
jonathan jhorwitz: The registration of the class is being done *before* Rakudo gets to parse Foo.new(), right?
jhorwitz: If not, that would need fixing.
jhorwitz jonathan: hi there! correct.
jonathan OK.
Is it in a different HLL's namespace? 19:59
jhorwitz wait...
actually...
pmichaud my guess is that it doesn't have the Abstraction role.
jhorwitz i'm precompiling that particular module, so it would be parsed BEFORE the registration
pmichaud oh.
jonathan pmichaud: At the moment, I'm pretty sure we check if it's a proto explicitly.
pmichaud (do all protoobjects automatically get the Abstraction role?)
jonathan: okay. Good.
jonathan (Since I figured we can't rely on external types automatically getting Abstraction.) 20:00
pmichaud jonathan++
jonathan jhorwitz: OK, that's...tricky. :-(
jhorwitz: Basically because Rakudo at parse-time needs to know what is a type and what is not.
If it can't find a type in the namespace under that name, then it presumes it's a post-declared list-op. 20:01
(This isn't just Rakudo, it's what STD.pm does as well.)
jhorwitz precompiling has exposed all sorts of interesting bugs.
and features. :)
jonathan I guess that you are not having a "use" directive that registers these?
(I figure you probably can't because we don't have importing from non-Rakudo modules worked out yet...) 20:02
jhorwitz that too. :)
jonathan (Well, just use'ing...)
jhorwitz mod_parrot does the registering. mod_perl6 just assumes that "Foo" is a registered class.
no "use"ing or anything else.
particle phone 20:03
jonathan I wonder if the Best Thing would be for me to get class stubs in.
So you can 'use' something in the script that pulls in the stubs or means they are at least identified as type names... 20:04
jhorwitz if that makes my problem go away, then +1 ;-)
shall i open a ticket?
jonathan Yeah, that'll serve as a reminder for me. :-)
jhorwitz excellent. ITMT i'm going to try it w/o precompiling
jonathan Provided you compile after the symbols are registered, you should be fine. 20:05
jhorwitz it's part of the mod_perl6 build process, so that's not gonna happen. :)
dalek rrot: r38275 | chromatic++ | trunk (20 files):
Merged the headercleanup branch to trunk as of r38254.
 20:07
Coke is there a test/spectest for rt.perl.org/rt3/Ticket/Display.html?id=64878 20:08
(I can't easily type in greek.)
Infinoid there's probably a spectest, let me look 20:10
S02-lexical-conventions/unicode.t has unicode variable names 20:12
also function names.
moritz I should fudge that 20:13
Infinoid is greek treated any differently than any of the other stuff in that file?
(I don't think it should be.)
jonathan Probably not.
Coke moritz: if you can check out [perl #64878] in re: testing, that'd be good. =-) 20:14
moritz Infinoid: not different than other non-latin1-stuff
jonathan If other non-ASCII and non-Latin-1 stuff works, greek probably should.
I guess all of us who know some of a language with non-Latin-1 chars could contribute some tests though. ;-)
Infinoid I know monty python, but the test already covered that. 20:16
moritz not even Latin-1 non-ascii work 20:17
Coke moritz: should work with latest parrot. 20:18
Tene I just tested it
allison Coke: yes, it's the public API that's subject to deprecation cycles
moritz Coke: I'll svn up and try 20:19
Coke allison: good, since I already committed that. ^_^
nopaste "tene" at 97.117.72.236 pasted "fail for Coke++" (18 lines) at nopaste.snit.ch/16383
allison Coke: (I just wandered over to the laptop running IRC, catching up)
Coke Tene: can you reduce that to a parrot failure? =-)
20:22 samlh joined
Tene hmm 20:23
... but maybe it does work? 20:24
it doesn't work with -e, but does work in a file??
20:25 bsdz joined
nopaste "tene" at 97.117.72.236 pasted "Weird failure..." (23 lines) at nopaste.snit.ch/16384 20:25
Tene that's creepy 20:26
bsdz hi, any easy way to disable #line directives being created during *.pmc -> *.c creation ?
he Infinoid: tested with nopaste.snit.ch/16379 and my alternative workarounds de-applied, and it builds and tests OK still.
jonathan Tene: How is Parrot handling unicode passed in ARGC? 20:27
Tene jonathan: enoclue
NotFound Last time I checked parrot does nothing, but rakudo assume they are latin1 20:28
Tene This doesn't work in rakudo, even in a file:
sub ā˜‚ { ... }
Coke I just fixed lexicals. =-)
"fixed"
Tene malformed routine definition 20:29
NotFound Tene: have you tried quoting it?
moritz Tene: is ā˜‚ an identifier character?
Tene Apparently not
moritz perl 5 conforms that
Tene NotFound: you can't quote sub names. 20:30
in rakudo
moritz in Perl 6 in general
NotFound Make rakudo quoting the,m then
moritz that still doesn't make ā˜‚ a valid Perl 6 sub name ;-)
NotFound Thanks god ;) 20:31
Tene moritz: but it could be an operator...
moritz Tene: sure
NotFound Urgh. You're giving a new sense to the saying: "The language that looks like line noide" 20:32
noise
Tene jonathan: this is what you were asking, I think...
$P1 = $P0.'command_line'(args_str, 'encoding'=>'utf8', 'transcode'=>'ascii')
20:33 gryphon joined
fperrad allison: have you some news from ftp-osl.osuosl.org ? 20:33
Infinoid he: great, thanks, I'll apply it then 20:40
So that just leaves the SIGFPE stuff 20:44
dalek rrot: r38276 | Infinoid++ | trunk/src/pmc/class.pmc:
[netbsd] netbsd-alpha fails to compile due to passing NULL in place of a va_list argument.

This patch implements allison++'s suggestion to more cleanly build a null CallSignature object.		 20:45
Infinoid Forgot to mention, that last commit fixes TT #573. 20:54
bsdz fyi: ops2c.pl --no-lines disables #line directives 20:55
21:01 rblasch joined
Coke moritz: any more passing tests in that spectest now? 21:18
particle fperrad: they've asked us to provide ssh keys. looks like each of the release managers will need to do so. 21:19
moritz Coke: yes. Works with greek now 21:22
but other parts of the file still fail, and it's hard to make out which part it is 21:27
21:29 Ademan joined
Coke moritz: whee. 21:30
moritz Coke: I'm working on it, but the tests use outdated stuff in many places 21:35
Coke moritz: approximately how many tests do you think you'll end up with? 21:43
(passing)
21:43 gerd joined
pmichaud By the time Rakudo sees the command line arguments, Parrot will have already placed them in strings and given them an encoding. 21:43
moritz Coke: 28 in that test file
pmichaud So Rakudo doesn't really control the encoding of the command line arguments -- that comes from Parrot.
(in response to: 20:28 <NotFound> Last time I checked parrot does nothing, but rakudo assume they are latin1 21:44
jonathan pmichaud: I was guessing it would be something like that.
May need a Rakudo fix.
erm 21:45
pmichaud I'm thinking it should be a Parrot fix.
jonathan a Parrot fix.
Yeah
I thought one and typed the other.
NotFound Last time was some time ago ;)
janus hm, 1.1.0 hasn't hit the ftp yet?
moritz pmichaud: t/spec/S02-lexical-conventions/unicode.t now mostly passes, but there are some details that don't work with Unicode, it seems 21:46
21:47 Whiteknight joined
pmichaud moritz: example? 21:47
moritz pmichaud: a named param :$Ć¤Ć¶Ć¼ 21:48
in a lexical sub, that is
pmichaud I wonder if Parrot accepts unicode named parameters.
moritz pmichaud: and the hindi identifiers don't get parsed 21:49
perl 5 confirms that they match ^\\w+$
but PGE does not 21:50
pmichaud ...checking.
moritz actually I have a test file that runs in both Rakudo and perl-5.10 without modifications 21:51
nopaste "moritz_" at 91.10.248.48 pasted "Hindi test" (8 lines) at nopaste.snit.ch/16385 21:52
21:53 jdv79 left
pmichaud try with /^<isL>+$/ in rakudo? 21:54
moritz also false
pmichaud That's odd. 21:55
Maybe <isLo>+ ?
moritz also false.
pmichaud &#2370 is given as a "non spacing mark" 21:57
moritz that thing is made of \\N{DEVANAGARI LETTER DA} and \\N{DEVANAGARI VOWEL SIGN UU}
and Perl 5 thinks that all marks match \\w 21:58
because that way most regexes DWIM
Perl 6 won't need that, once it works on graphemes
it just has to respond with with "yes" to \\w if the base char is a letter
Coke someone should open a trac to get the 1.1.0 docs out on docs.parrot.org and I'll get to it tomorrow if no one else has. 21:59
particle we need a way to submit trac tickets from irc 22:08
ingy hi 22:09
rg particle: if we can get submitting tickets by mail fixed, maybe we can write (or extend) a bot ;)
particle sigh.
heya ingy
rg moritz: can you close #63922 (perl6 ticket)
ingy hi particle. how's seattle?
moritz rg: done, thanks 22:10
particle wet, again.
where are you these days?
ingy I heard you had some sun
I was just in oslo with pmichaud et al
particle yeah, it was awesome, while it lasted. got a nice sunburn on a long bike ride
ingy now I'm back in Chamonix 22:11
to UK on May 5th, then Seattle on May 27th
then Pittsburgh 22:12
planning to drive from seattle to PA
particle i'm sure i'll see you there.
ride or drive?
ingy drive I think
I don't have the bike for that kind of riding
particle ought to be a nice ride, until chicago/indy 22:13
ingy drive
;)
particle then it's a bit trafficky
er, drive :)
ingy I've driven coast to coast many times 22:14
particle twice for me. 10k miles in 5 weeks.
of which, 3k miles was in 4 days.
ingy anyway thinking about just driving for the summer
that's a lot
Infinoid that's an accelerated particle 22:15
particle indeed i was
ingy I drove 1200 on a motorcyle in one go
particle my longest day was billings->seattle
ingy got off 4 times for gas
this was boulder->chicago
particle wait, maybe that's not my longest day... 22:16
ingy I drove portland to boulder in 27 on motorcycle
but pull over to sleep 3 hours in a field 22:17
particle too much for me.
ingy my typical car driving day is 750 miles
that's usually like 18 hours 22:18
er 16
jonathan That's...a lot of driving.
jonathan can't drive, but can't quite imagine being able to concentrate enough for that long either.
ingy then I recline the seat, sleep 8 hours, get up, pee, and repeat
hi jonathan! 22:19
jonathan hi ingy!
pmichaud I did St. Louis to Pittsburgh once in a single stretch.
Not quite 750 miles, but it's up in the high 600s I think
eh, Google says 601. Oh well. 22:20
ingy I've done chicago to stl (5 hours), and chicago to pitts (10 hours) a lot
jonathan has done 1000km+ in a day on train, but that's rather less effort on my part. ;-)
ingy chi->pitts is like 450 iirc
pmichaud my longish drives were typically Lafayette to Corpus Christi (7.5 hours) every two weeks.
22:21 rblasch1 joined
ingy I'm just glad gas is back to normalish 22:21
pmichaud indeed. :-)
Infinoid I've tried and failed to do Lake Tahoe to Phoenix in one stretch... twice
Infinoid burns out too easily from driving.
jonathan I barely travel in a car these days. When Jeremiah++ drove us from Gothenburg up to Oslo for NPW, I realized it was my longest car journey so far this year. And it was just 3 hours. 22:22
I actually don't dislike it, particularly if there are decent views to be had.
TBH, I think folks from the US tend to have a different concept of "a long drive" to many Europeans. 22:25
22:26 rob joined
rob hey just been reading www.pmichaud.com/2009/pres/npw-pct/...de41c.html 22:26
shorten rob's url is at xrl.us/bepzkf
rob does the $<something>.ast'method mean that $($<something>) is now depreciated? 22:27
Whiteknight pmichaud and jonathan, I was wondering if you two saw my response to TT #218? 22:28
jonathan rob: Yes.
rob ah ok, it reads better I guess. will have to update porcupine 22:29
particle ingy: i did my nyc->chi in 11 hours (880mi) 22:30
ingy leadfoot
particle yep :D
ingy :)
jonathan Whiteknight: Just read it. 22:31
Whiteknight: get_pointer is _meant_ to return some kind of address that represents the PMC. 22:32
cotto If you had a delorean, you'd only have to go 88 MPH for the last few seconds.
Whiteknight jonathan: but get_pointer has different semantics for all PMCs
for some PMCs it returns the SELF pointer, for other PMCs it returns a pointer to the underlying data
I'm saying for encapsulation, FixedPMCArray should use the later semantics, not the former 22:33
jonathan Yeah, but even within that the tests that pmichaud added should hold. 22:34
That is, the underlying data should be different.
Whiteknight Not necessarily, if the two PMCs are pointing to a NULL array, or are shallow copies of each other 22:35
pmichaud Two empty arrays should not have the same address if they are different PMCs.
cotto I don't think we have cow arrays either. 22:36
jonathan I fear that patch also makes assumptions about what subclasses of get_pointer will do also. 22:38
Whiteknight pmichaud, not necessarily. There are two different semantics at play here
jonathan erm, subclasses will do with get_pointer
Whiteknight one is the location of the PMC structure itself, and one is the location of the underlying data.
The second can be the same between for two new PMCs if the data is NULL in both
the former obviously can't be 22:39
I want to separate the two semantics and give a separate opcode to each that can both be used consistently
pmichaud That requires a deprecation cycle.
jonathan Additionally, it's wrong. 22:40
"Please give me your guts." Yeah, bye encapsulation, hi future segfaults...
Whiteknight jonathan: I don't agree. It's wrong to shoehorn to different semantics into the same get_addr op
lots of other PMCs already use get_pointer and set_pointer for various other uses
jonathan Yeah. At least one of them last time I saw it has "KLUDGE ON THE CHOPPING BLOCK" written above it too...# 22:41
Whiteknight okay, back up and look at the current situation: Several PMCs define all sorts of custom behaviors for get_pointer, and that's directly exposed by the get_addr opcode 22:42
jonathan I always saw get_pointer as useful if, for example, you were proxying for another PMC and wanted to hand back the address or something else you were proxying.
Whiteknight we can't expect get_addr to be used to return the unique memory address of the PMC if it doesn't do that for all types
jonathan In general, I also am rather fearful of get_pointer as a vtable generally. 22:43
Whiteknight I don't always like it either, I definitely don't like that it's so easily exposed to PIR through the get_addr op
It has plenty of legitimate uses internally
jonathan Imagine I override it in a PIR subclass (if possible). I return 0. Something else grabs it and dereferences...boom. 22:44
pmichaud at any rate, we need some way of uniquely identifying a PMC
jonathan From what I can see, your legitimate use was "breaking a PMC's encapsulation".
Whiteknight well the easy solution to that is not to allow get_pointer (or set_pointer) to be overridden from PIR
pmichaud: yes. I am proposing a second single-purpose opcode for that
pmichaud but not "get_addr"? 22:45
Whiteknight PMCs like Sub and Continuation use get_addr to point to the underlying opcode_t offsets
so you would have those PMCs not returning unique values from it either
jonathan Grr.
Whiteknight as it is, we absolutely can't guarantee that get_addr will return anything unique, so I say we add a new op that does make that guarantee 22:46
pmichaud fair enough. Just let me know what it becomes so we can fix Rakudo to match. 22:47
Whiteknight do you have a preference for what to call it?
jonathan Aye. Looking around, I concede that get_pointer is used for all kinds. :-| 22:48
pmichaud "get_addr" seems most appropriate . :-)
but if that isn't available, then "get_pmc_addr"
cotto get_self_addr?
pmichaud theres no "self" here.
jonathan If get_pointer is going to stay, I'd really like it to be as hidden from PIR as possible...
Whiteknight pmichaud, that's fair, We'll just have to rename all other uses of get_addr (like for Continuation PMCs) to something else, which beggs the question about what to call that
pmichaud well, I suspect any renaming is likely to be problematic. 22:49
Whiteknight jonathan: I agree with that
jonathan Do we *need* the current semantics of get_addr from PIR?
Whiteknight jonathan: that I am aware of, only for the Sub and Continuation PMCs
and the ExceptionHandler, I think
pmichaud I suspect the bigger question is whether or not anything uses set_addr
jonathan I just saw that...
pmichaud currently it's used for exception handler setting. 22:50
We don't have a way to set the return address of an exception handler except via set_addr
jonathan erm.
Ouch.
Whiteknight if we kill set_addr, we could make a method on the ExceptionHandler/Continuation PMCs to set the addres offset
pmichaud I don't think address offsets can be passed to method calls.
or subroutine calls.
purl subroutine calls are pretty slow in Parrot right now, comparatively speaking.
pmichaud I could be wrong about that, though. 22:51
jonathan VTABLE_set_pointer(INTERP, context->lex_pad, context);
(In sub.pmc)
pmichaud set_addr seems to have been used extensively for getting offsets into pmc registers. 22:52
I have to head off to my soccer game. 22:53
I'll be back later tonight.
Whiteknight okay, later
nopaste "jonathan" at 85.216.157.73 pasted "segfault as a result of set_addr and set_pointer usage" (9 lines) at nopaste.snit.ch/16386 22:54
jonathan That's exactly where set_pointer/get_pointer and their exposure to PIR is going to get us.
22:54 contingencyplan_ joined
jonathan (That is, I can look at a usage of it quite randomly picked and craft a program to make Parrot segv in about a minute...) 22:55
Whiteknight jonathan: I agree with you 100%. If it weren't for the Sub PMC problems I would have removed the PIR-facing uses of them
22:55 Limbic_Region joined
jonathan We'd need a deprecation cycle, but I suspect it's something we should push for. 22:55
Whiteknight I'm willing to do all the pushing, I just wanted to talk to you guys to make sure my ideas were sane
jonathan I do still worry about get_pointer's encapsulation breaking behaviour, mind...
cotto particle, ping 22:56
Whiteknight jonathan: I worry too, but get_pointer isn't always used to "get my guts". Instead it's often used for "get my data that isn't something nice like a INTVAL or PMC*" 22:57
so it *generally* preserves encapsulation well enough, in most cases 22:59
<insert disclaimer about potential abuse>
jonathan It's not my call really, I just worry that the potential for abuse is a little high... 23:01
Whiteknight right, but we're going to fix it in baby steps 23:08
LylePerl Infinoid: I just tested for the realclean issue on XP/Strawberry Perl and I had the same problem with files being left... I thought you tested on XP/Strawberry and found it to be ok? 23:12
23:21 tetragon joined 23:31 bacek_ joined 23:44 kid51 joined
Infinoid msg lyleperl I did. I think I need a list of exact steps to reproducd it 23:52
purl Message for lyleperl stored.
Infinoid msg lyleperl To be specific, I tried all kinds of combinations, with and without rakudo and realcleaning in random orders, and in each case, the parrot checkout no longer had a blib/lib and no longer had a src/ops/*.c. 23:55
purl Message for lyleperl stored.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!