Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, testexceptions_refactor branch | GSoC students, please read trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 6 May 2010.
bacek totally confused when this regression was introduced... 00:01
Bah... 00:02
Coke it's been a problem in branch for some time.
bacek I'm on codestring branch, not trunk...
Coke yes.
trunk was failing tests for a while though, so we're borked either way! =-)
00:03 khisanth_ joined
nopaste "bacek" at 192.168.1.3 pasted "Another patch for codestring" (52 lines) at nopaste.snit.ch/20507 00:04
Coke got past Action.pm which I haven't in some time. it also was taking 8G, though.
bacek Coke: can you try tis one? It should show some stats during build. 00:05
Coke is that in addition to or in place of?
00:06 Khisanth joined
bacek in place of 00:06
00:09 Mokurai1 joined
Coke bacek a LOT of debug output. 00:23
Total blocks: 3 122414472
and counting.
purl counting is ok
bacek yes...
But it's 120 megs of strings. Not 8 gigs 00:24
Coke counting.
purl it has been said that counting is ok
Coke Total blocks: 3 230477968 00:26
(new file. guess I should cancel this and capture the output.)
bacek Just replace #ifdef 1 with #ifdef RESOURCE_DEBUG in pad_pool_size 00:27
I've got info I need...
Coke ... that wasn't the last number output. it was just some random line. 00:28
good enough?
bacek "enough"
But not good...
Basically - we've lost optimization for not-compacting pools 00:29
00:36 hercynium joined
Coke Total blocks: 3 499437648 00:39
(still going. I'm just bored) 00:40
ok, killed it. 00:43
bacek Coke: sorry, I have to go. 00:48
But you can try next things: 1) Don't use string allocations for SB.buffer. Use gc_allocate_memory/reallocate manually; 2) Replace str_copy with str_clone (actually just put return str_clone into str_copy) 00:50
00:56 joeri joined 00:58 particle joined 01:01 Mokurai2 joined
dalek rrot: r46423 | plobsing++ | trunk/compilers/imcc (5 files):
kill graph colouring register allocator
 01:32
rrot: r46424 | plobsing++ | trunk/t/compilers/imcc/imcpasm (2 files):
remove TT1281 todoed tests
TT #1281 closed by plobsing++: Remove graph coloring register allocator from IMCC 01:42
TT #1281: trac.parrot.org/parrot/ticket/1281
kudo: c52c61a | (Solomon Foster)++ | src/core/ (4 files):
Add Numeric versions of the infix:<cmp> family of operators. Move the old infix:<cmp>(Num, Num) operator code to infix:�<=>�(Num, Num) and delete infix:<cmp>(Num, Num). Remove the Rat versions of infix:<cmp>.
 01:59
kudo: 9427875 | (Solomon Foster)++ | tools/test_summary.pl:
Change // to || to keep Perl 5.8 happy.
purl dalek: that doesn't look right
kudo: 85a7aa4 | (Solomon Foster)++ | src/core/Numeric.pm:
Eliminate Numeric versions of eq, ne, lt, gt, le, and ge -- these should always be string comparisons.
02:00 Psyche^ joined
sorear hmm 02:13
in a Parrot stack trace, the line numbers and byte code offsets always point to the beginning of the functions
do we know why?
experiment failed 02:34
subclass of RPA is failing to behave as a RPA with no evidence of why
it just returns empty iterators
02:36 janus joined
plobsing sorear: which vtables have you overloaded? 02:42
sorear plobsing: none
oh, get_bool 02:43
purl i think get_bool is 5.66% of execution time.
plobsing all RPA's get_iter vtable does is "return new 'ArrayIterator'(self);" 02:44
try doing that manually to see if it fails
sorear I had already reverted... 02:48
I wasn't trying to debug anything, just run a "quick experiment"
02:52 JimmyZ joined 02:55 Andy joined
sorear yikes. *** glibc detected heap corruption *** during a post-realclean build of the codestring branch 03:18
sorear checks if it's repeatable after turning off randomize_va_space
(in miniparrot) 03:19
yes. 03:27
absolutely repeatable.
imcc_run -> ??? -> yyparse -> yylex -> mem_sys_free -> *** glibc detected *** ./miniparrot: free(): invalid next size (fast): 0x080f1358 *** 03:28
start with latest 'codestring' on linux/i386 gcc 4.4.4 03:29
svn status --no-ignore #empty
perl Configure.pl
make
1.6MB core dump
according to strace, no files from my existing parrot install are being read and possibly poisoning 03:35
plobsing hmmm... works fine for me 03:47
04:01 khairul joined
sorear grr. watchpoints appear to be broken in debian gdb 7 04:14
sorear minimizes the test case
oh I see 04:20
it can't place hardware watchpoints in not-yet-allocated memory
so after 'run', the existing watchpoints all revert to software
dalek rrot: r46425 | petdance++ | trunk/compilers/imcc (2 files):
re-headerized
 04:31
04:33 JimmyZ joined 04:42 JimmyZ joined
dalek TT #1622 created by plobsing++: [DEPRECATED] :unique_reg flag 04:42
TT #1622: trac.parrot.org/parrot/ticket/1622
sorear after spending an hour or two chasing malloc memory corruption in the debugger, it just occurred to me to use valgrind 04:47
dalek rrot: r46426 | jimmy++ | trunk/src/call (2 files):
random consting
sorear bacek: Are you still here? 04:50
Or any other committer. 04:51
bacek got the arguments to memset backward at gc_ms.c :1365
our new memory allocator, in debug mode, fills the first 15 bytes of any allocation with the allocation's size as a byte
including allocations smaller than 15 bytes 04:52
plobsing: Are you on a non-optimized post-46422? 04:54
plobsing I checked out and ran 'perl Configure.pl; make -j3' 04:57
maybe it's not recent
04:57 patspam joined
sorear the bogus patch was 6 hours ago 04:58
anyways, reversing the arguments to memset makes it work. 04:59
dalek rrot: r46427 | plobsing++ | trunk (9 files):
deprecate :unique_reg and make it a nop
 05:04
rrot: r46428 | jimmy++ | trunk/src (2 files):
removed unused value and consting
plobsing sorear: we're talking about the codestring branch right?
sorear plobsing: yes 05:08
Coke: I know why 'codestring' is using so much memory
plobsing make test passes for me at r46428 05:09
sorear plobsing: with or without --optimize?
plobsing without
sorear bacek committed 46422 to 'codestring' 05:10
not trunk
are you doing anything which might cause NDEBUG to be set? 05:11
plobsing nope. maybe it is pulling it from the system perl
sorear likely. 05:12
anyway, the line is obviously wrong
just look at memset(3) and compare argument orders...
plobsing hmmm... true enough 05:13
hmmm... maybe the object being memset gets packed into fewer than 15 bytes on your machine but not mine (x64) 05:15
sorear under glibc, no allocated object can be smaller than 2*sizeof(size_t) 05:16
so yeah. 05:17
purl hmmm... so yeah is there anyone that has any advice on how to get a resultset that contains two joined tables ?\\
sorear Coke: Do you want me to explain the codestring memory problem? 05:19
purl: forget so yeah
purl sorear: I forgot so yeah
plobsing sorear: fixed 05:24
05:32 rbuels joined
dalek rrot: r46429 | plobsing++ | branches/codestring/src/gc/gc_ms.c:
correct order of arguments to memset (sorear++)
 05:36
sorear plobsing: excellent 05:39
dalek rrot: r46430 | plobsing++ | trunk/compilers/imcc (8 files):
remove some life analysis code dead after graph colouring allocator removal
 05:53
05:54 JimmyZ joined
dalek TT #1152 closed by plobsing++: :named should default to the name of the parameter 06:21
TT #1152: trac.parrot.org/parrot/ticket/1152
rrot: r46431 | plobsing++ | trunk (4 files):
allow named params to default to their variable name.
 06:25
06:34 kjeldahl joined
dalek rrot: r46432 | jimmy++ | trunk/src/call/args.c:
cleaned up unused struct
 06:41
kudo: 118f4aa | (Solomon Foster)++ | src/core/ (5 files):
Overhaul sqrt for Numeric / Real.
 06:51
07:08 ShaneC joined
ShaneC Hello 07:08
purl privet, ShaneC.
dalek TT #1030 closed by plobsing++: long sub invocation with named parameters 07:10
TT #1030: trac.parrot.org/parrot/ticket/1030
ShaneC Is there a web site somewhere that lists parrot's supported platforms?
browsed the main site a bit but i didn't see anything 07:11
plobsing ShaneC: svn.parrot.org/parrot/trunk/PLATFORMS
ShaneC thanks 07:12
07:12 dolmen joined
dalek rrot: r46433 | plobsing++ | trunk (3 files):
allow named arguments in long-form pcc_sub calls (TT1030)
 07:14
ShaneC anyone know how well parrot is currently suited to embedding? I know I've seen some progress on getting it into Postgres 07:15
asking because I've been trying to think of a good way to contribute for a while, my day job is a game dev and I'm working on LUA in our engine atm -- curious if getting parrot onto the ps3/360 would be a huge challenge 07:17
(powerpc)
sorear parrot will run on ppc fine 07:19
however
ShaneC yea i saw linux ppc listed 07:20
sorear our current build system is allergic to cross compilers
does ps3-linux have a native gcc port?
if so, you shouldn't have difficulties
ShaneC i wouldn't be running linux on the ps3
but gcc is available
sorear no, but the architecture would be the same
I think
purl, khairul? 07:21
purl i haven't a clue, sorear
ShaneC we don't use gcc for our ps3 builds, but sony's other compiler is very gcc compatible
sorear purl, ash_?
purl i guess ash_ is John Harrison or John Harrison <mailto:john@greaterthaninfinity.com>
sorear ShaneC: that's not the point
JimmyZ plobsing: using TT #1030 will be more useful, then Trac can add a link to the ticket.
ShaneC (along with very msvc compatible, interestingly)
sorear ShaneC: your compiler needs to spit out executables that can be run *locally*
ie it needs to either generate fat binaries or run on the ps3
ShaneC well, it would be embedded into the game engine (if that matters) 07:22
sorear I don't know what that means
Are you saying you're going to scrap the entire build system?
ShaneC there would not be a standalone parrot executable
sorear That doesn't matter at all 07:23
ShaneC sorear: i'd hope i wouldn't have to, but i don't really know what would be required
i've done some work with parrot but never modified the parrot code/build at all
sorear If you plan to, under any situation, compile any part of Parrot for a different computer than the development machine, for *any* such circumstance
you can either 1. give up now 2. coordinate with the SoC student (khairul?) who is adding cross compiler support 07:24
ShaneC ah, interesting, i'll have to contact him
sorear the synopsis of the SoC is to port Parrot to RTEMS (a midrange embedded OS that tends to show up in spacecraft and the like) 07:25
but 98% of it is "make Parrot cross-compilable and POSIX-agnostic"
plobsing JimmyZ: thanks for the tip 07:26
ShaneC sorear: i'm assuming scrapping the build system is not feasible?
lua is pretty simple to embed, you can just shove the lua source into your project, set a define, and compile
07:27 fperrad joined
sorear Erm, was that an insult? 07:27
I can never tell
ShaneC lol, no
im a long time perl/parrot fan ;-)
but i'm asking whether something like that is possible with parrot 07:28
sorear Not now, as I just tried to explain 07:29
ShaneC my apologies, i do a lot of coding, but i don't normally touch the build process much
sorear Rather little of Parrot is actually C
plobsing ShaneC: (AFAICT) part of the difference between lua and parrot that increases the challenge of embedding is Parrot provides more builtin functionality (which it needs to get from somewhere) 07:30
ShaneC do you think just starting with the c pieces would be viable? for instance, if i just wanted to get pasm up and running 07:31
sorear No, because the interpreter is written in a custom macro language and generated at build time by a large pile of system-querying Perl 5
ShaneC and leave the (insert language) -> pasm compilers part of the offline build
sorear collectively "ops2c" 07:32
the datatype engine is set up with a different but related custom macro engine
plobsing ShaneC: IMCC (the subsystem that handles PASM and PIR) is one of the hairiest, most tightly coupled systems in Parrot. Good luck extracting it.
sorear once you have both of those - and the configuration data, most of which is extracted from "perl -V" - you can build "miniparrot"
"miniparrot" is then used to run a second bank of macro processors written in PIR 07:33
ShaneC so essentially the problem with cross compiling is that the build process needs the target machine to have perl?
sorear yes, perl and parrot
ShaneC or at least to know bout its perl
about*
sorear no, it needs to have perl 07:34
because you need to run the Perl 5 part of the build system on a machine with the same characteristics
then, you can transfer the generated C to your development machine and build a miniparrot 07:35
then transfer *that* *back* to the PS3
Man. You do not scare eaily.
ShaneC lol 07:36
i <3 challenging programming ;-) 07:37
sorear Know what you are getting yourself into.
ShaneC yea, it definitely sounds very non trivial
sorear Think very carefully about whether you actually want to spend three man months helping us and humanity
ShaneC are there any long term plans (the cross compiling gsoc project aside) to remove perl from the build process?
sorear Instead of the expedient approach of simply embedding a mature script engine like Perl5 or Lua 07:38
Yes.
In that it is a goal.
No plans have been made.
ShaneC oh, i'm not suggesting that we would use parrot for our production scripting
lua is definitely the choice, but i have access and experience with console dev, and getting parrot onto those platforms would be pretty cool 07:39
sorear Incidentally, the only mature language that runs on Parrot is Lua.
purl: coke? 07:40
purl coke is Will Coleda <mailto:will@coleda.com> or perpetually annoyed. or magical ticket robot or (if Diet), something that turns into formaldehyde in my blood. or getting those data_json issues in Coke's build. or tempted to remove "ticket_append" for authenticated. or on OSX 10.6.3
ShaneC well, i really appreciate the input, i'll dig into some of the things you mentioned and mull it over 07:41
thanks!
07:41 fperrad_ joined
khairul hi sorear, i think the one doing the RTEMS port is bubaflub? 08:02
sorear ah thanks. 08:03
ShaneC:
ShaneC i'll scan through the mailing list and try to find it
dalek rrot: r46434 | jimmy++ | trunk/include/parrot/context.h:
cleaned up macros
 08:36
08:40 jan_ joined 08:48 jan_ joined
dalek rrot: r46435 | jimmy++ | trunk/src/call (2 files):
use macro instead of inline fuction, C89 doesn't like it
 08:53
JimmyZ parrot-dev blocked my mail? :( 09:27
msg chromatic since there is a macro in the context.h, so I just changed it to use that macro.
purl Message for chromatic stored.
JimmyZ msg chromatic when I saied ' C89 doesn't like it', I meant 'by the way, C89 doesn't like it'. 09:28
purl Message for chromatic stored.
moritz bacek: with r46435 I still get 4 non-zero exit stati in a rakudo spectest run 09:40
oh wow, just read that the plural of "status" is also "status", but the 'u' in there is pronounced slightly different 09:42
09:42 kjeldahl joined 10:06 lucian joined 10:18 iblechbot joined 10:54 JimmyZ joined 11:18 JimmyZ joined
JimmyZ Hello, any objection to Make fast core the default core? 11:20
arnsholt moritz: In Latin, it's a fourth declension noun, so yeah. Not sure if the pronounciations differed much though 11:21
11:27 Whiteknight joined
dalek tracwiki: v8 | jimmy++ | PerformanceImprovements 11:35
tracwiki: trac.parrot.org/parrot/wiki/Perform...ction=diff
rrot: r46436 | jimmy++ | trunk/src/main.c:
make fast core the default core, see PerformanceImprovements
 11:36
11:46 joeri joined 11:52 kid51 joined
kid51 make test failures in trunk at r46436 11:55
smolder.plusthree.com/app/projects/...ails/33720 11:56
nopaste "kid51" at 192.168.1.3 pasted "make test failures observed in trunk at r46436" (83 lines) at nopaste.snit.ch/20508 11:58
kid51 Bisecting; everything was okay at r46425 11:59
dalek kudo: c18ef37 | (Solomon Foster)++ | src/core/Range.pm:
Switch prefix:<^> to use +$max internally.
 12:00
kid51 Bisecting: the failing tests were passing at r46430 12:04
mikehh kid51: I got the tests passing at r46435, failing at r46436 12:10
12:11 JimmyZ joined
mikehh JimmyZ: it looks like r46436 generates some test failures 12:11
JimmyZ (fast core)-- :( 12:12
kid51 JimmyZ: So there's the answer to your question: the *tests* object to making fast core the default core 12:13
mikehh: Confirmed. The failing tests passed at both r46433 and r46435. 12:15
Fortunately, reverting 46436 involves changing only 4 keystrokes :-)
JimmyZ reverted 12:18
kid51 Thanks 12:22
dalek rrot: r46437 | jimmy++ | trunk/src/main.c:
revert r46436, some tests failed
 12:24
tracwiki: v9 | jimmy++ | PerformanceImprovements 12:25
tracwiki: trac.parrot.org/parrot/wiki/Perform...ction=diff
mikehh interesting - make testf passes - i need to look maybe some TODO's 12:26
kid51 codestring branch PASS make test at r46437
JimmyZ annotations have problems with fast core 12:28
nopaste "kid51" at 192.168.1.3 pasted "r46437: one codingstd failure" (14 lines) at nopaste.snit.ch/20509 12:35
mikehh kid51: I think this is a work-in-progress by plobsing - I got different failures earlier 12:36
although I think this sort of change needs to be done in a branch 12:37
that's with assert-args 12:38
kid51 mikehh: Yes, almost by definition, "work-in-progress" implies "should be done in branch" 12:39
mikehh I was going to try and fix them - but then an ack showed that new stuff had been added but not yet implemented and am not happy with make headerizer 12:44
dalek kudo: ee6ec74 | (Solomon Foster)++ | src/core/Pair.pm:
Add infix:<cmp> for pairs.
 13:21
13:34 Andy joined 13:42 rurban joined 14:00 rurban_ joined
dalek kudo: e113d85 | (Solomon Foster)++ | src/core/Array.pm:
Add proto for unshift so we can use named args.
 14:19
14:38 Andy joined
dalek kudo: 73a3d3e | moritz++ | t/spectest.data:
[t/spec] run another test file
 14:42
Coke msg jimmyZ: This is probably a translation issue, but I don't see the difference between your two C89 statements. 15:06
purl Message for jimmyz stored.
JimmyZ Hi 15:07
Coke msg plobsing ah, looks like you're saying it doesn't do anything these days. that makes sense, then. Thanks. =-) 15:08
purl Message for plobsing stored.
Coke plobsing++ #imcc
JimmyZ that's just code cleaning up
there is already a macro 15:09
LTA? 15:11
purl LTA is less than adequate, see also acronyms.thefreedictionary.com/LTA or "Less Than Awesome" in Rakudo world :)
dalek kudo: ad46ef8 | moritz++ | t/spectest.data:
run two more test files
Coke so, in this brave new string world, what's the right way to do a substring that doesn't keep a copy of the full original string? 15:14
msg sorear got your message. Trying to find where I can untangle it. 15:22
purl Message for sorear stored.
15:29 davidfetter joined 15:38 s1n left 15:43 tetragon joined
dalek kudo: 27e05a8 | (Solomon Foster)++ | (3 files):
Add dead simple preliminary implementation of Sop, and turn on the only test we were able to find for it.
 16:08
16:10 davidfetter joined 16:30 lucian joined
sorear Coke: I think it would be better to start by factoring 'lineof' out of CodeString 17:01
Coke: then NQP-rx wouldn't need to play stupid tricks with input
because, even if you fix substring, you still have a huge amount of cpu time spent making short-lived clones... 17:02
17:28 Mokurai joined 17:51 plobsing joined 18:29 snarkyboojum joined 18:42 Mokurai1 joined 18:50 kjeldahl joined 19:09 jan joined 19:18 rbuels joined
sorear Why does CodeString do so many things? 19:24
moritz maybe the line number tracking can be moved to a utility PMC that is not a string itself 19:25
now that strings are immutable
19:48 Andy joined
dalek rrot: r46438 | plobsing++ | trunk/compilers/imcc (4 files):
remove vestigial tokens INC, DEC, and NEW
 19:49
19:51 Psyche^ joined
sorear moritz: Good idea... how would that look? 20:00
20:04 theory joined
sorear What files do I need to change to add a new core PMC? 20:14
plobsing sorear: just dump it into src/pmc. It will be auto-detected. You'll have to bump PBC_COMPAT and regen the native pbcs (requires x86) as well 20:20
sorear ...why?
plobsing because core pmcs are numbered alphabetically and PMC numbering is part of PBC 20:21
sorear oh. maybe I don't want to add a core pmc then.
moritz sorear: a StringMarker PMC; constructor takes a string; it has get_line_by_position method or so
sorear also, MANIFEST.generated contains mention of /codestring/ and other core pmcs 20:22
plobsing oh yeah, theres a test that will complain at you about that =-D
sorear how about adding standard dynpmcs, then? 20:23
plobsing not sure. they likely get auto-detected from the src/dynpmc directory. there is no special numbering on dynpmcs, so you're in the clear wrt PBC_COMPAT 20:26
20:28 Andy joined
dalek rrot: r46439 | petdance++ | trunk/compilers/imcc (3 files):
re-headerized
 20:39
rrot: r46440 | plobsing++ | trunk/compilers/imcc (5 files):
eliminate special parsing of 'new' opcode for old-style class numbering
 20:55
21:07 Andy joined
dalek rrot: r46441 | petdance++ | trunk (4 files):
include/parrot/embed.h is now headerized, although there are some imperfections with two redundant headers cut-and-pasted in there
 21:11
rrot: r46442 | plobsing++ | trunk/compilers/imcc (5 files):
eliminate old code handling special NCI calling convention
rrot: r46443 | plobsing++ | trunk/DEPRECATED.pod:
deprecate .nci_call syntax
21:24 dolmen joined
dalek TT #1623 created by plobsing++: [DEPRECATED] .nci_call 21:25
TT #1623: trac.parrot.org/parrot/ticket/1623
rrot: r46444 | plobsing++ | trunk/compilers/imcc (6 files):
eliminate pcc_sub_t.calls_a_sub, leaving pcc_sub_t.yield
 21:28
rrot: r46445 | plobsing++ | trunk/compilers/imcc/pbc.c:
narrow variable scope
plobsing are bit-fields C89? I see plenty of single bit flags in 'int' containers. I could significantly decrease the size of several objects. 21:31
dalek rrot: r46446 | petdance++ | trunk/lib/Parrot/Headerizer.pm:
Fixed a potential bug found by Perl::Critic
 21:44
sorear bit-fields are C89, but their behavior is very loosely standardized 21:47
you can't portably use them for anything other than compressing structures 21:48
the most pessimistic intepretation of C89 bitfields is that they are allocated to an intmax_t 21:49
so you should start bit field groups at pointer-aligned areas if you don't want padding 21:50
also, compilers are allowed to not support splitting bit fields between bytes
so groups of bit fields should ideally add up to 8 bits each
the legal basic types of a bitfield are "signed int" and "unsigned it" 21:52
int
do not use "int", as signedness in this case is undefined
dalek rrot: r46447 | petdance++ | trunk/lib/Parrot/Test.pm:
hiding the namespace mucking in a function
 22:00
22:03 lucian joined 22:13 jjore joined 22:21 jjore joined 22:30 triddle joined 22:44 hercynium joined 22:59 plobsing joined 23:11 jjore joined 23:18 mariano joined 23:23 jjore joined
plobsing why is '~' xor in PIR, not '^' ? 23:38
23:54 mariano joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!