Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; merge branches; review Git conversion plan
Set by moderator on 7 September 2010.
00:00 Patterner left, kid51_at_dinner is now known as kid51
ttbot Parrot trunk/ r48838 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386243.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 00:01
chromatic Now that Parrot_fixed_8_encoding_ptr is gone, what should src/library.c +385 do? 00:03
ttbot Parrot trunk/ r48839 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386249.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 00:05
NotFound chromatic: IMO all that convoluted windows specific functions should be replaced, using parrot string functions instead of playing with the raw string buffer 00:06
chromatic Agreed. 00:07
For now, hackety hack.
00:08 Andy left
dalek rrot: r48839 | chromatic++ | trunk/src/nci/extra_thunks.c:
[NCI] Removed spurious debugging output of r48831.
 00:10
rrot: r48840 | whiteknight++ | branches/ns_func_cleanup:
branch merged to trunk back on r47678. tcurtis++ for the reminder
rrot: r48841 | chromatic++ | trunk/src/library.c:
[src] Fixed cnv_to_win32_filesep().

didn't catch this one reference in the source. We should address the issue, but PARROT_ASSERT() isn't the right way to verify that this na�ve approach is correct.
NotFound r48839 still doesn't build in amd64 with --optimize 00:11
00:11 Psyche^ joined, Psyche^ is now known as Patterner
NotFound src/extra_nci_thunks.c:2857 contains spurious characters 00:12
chromatic Not here.
NotFound typedef void *(* func_t)(*^A^@º^A+char *, int, voi0); 00:13
chromatic Sounds like what pmichaud saw with my GC patch. 00:14
00:15 ash_ left
chromatic groups.google.com/group/parrot-dev/...42d1dbe5a4 00:16
00:20 Patterner left
luben I see the same bugs @ r@48805 00:21
example: ./parrot t/library/mime_base64.t 00:22
cotto_work looks fine here 00:25
luben here, there are some test that fail 00:27
dalek rrot: r48842 | nwellnhof++ | trunk (16 files):
[str] Remove unused stringrep enum
luben they passed successfully before portint string_join to StringBuilder 00:28
(verified just now)
cotto_work, it happens on optimized builds on amd64 00:29
chromatic Not my GC patch then. 00:31
nwellnhof luben: r48823 is probably the problem. i switched stringbuilder back to use str_clone 00:32
luben no, I do not think so 00:33
nwellnhof i just thought, because the str_clone thing caused issues on amd64 00:34
cotto_work nwellnhof++ for nuking that enum.
kid51 r 48841: build failure on Darwin/PPC: 00:35
luben My understanding is that there is a bug in StringBuilder, when we ported parrot_str_join to use StringBuilder, some bugs surfaced
we worked arround some of them but the bug is still there
nopaste "kid51" at 192.168.1.3 pasted "Darwin/PPC: 'make' fails; r48841" (474 lines) at nopaste.snit.ch/23256
kid51 src/string/encoding/ucs4.c: In function 'ucs4_hash': nested functions are not on MacOSX syntax error before '*' token 'pos' undeclared (first use in this function) 00:38
nwellnhof luben: i hoped that r48808 would cure the StringBuilder issues
kid51: do you have a line number? 00:39
kid51 See the nopaste
luben I hoped also - parrot builds but fails some tests 00:40
kid51 lines 436+
ttbot Parrot trunk/ r48842 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386313.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
kid51 taptinder reporting same error 00:41
cotto_work I see some similar-looking corruption with an optimized build.
NotFound Looks like a missing #if PARROT_HAS_ICU 00:42
nwellnhof the ucs4.c issue is ICU related. i have a fix coming up...
00:43 ascent left
kid51 nwellnhof: Datum: The Darwin/PPC on which I saw failure is ICU-less. 00:45
nwellnhof yes, ICU-less builds are the problem 00:46
00:47 contingencyplan left 00:48 contingencyplan joined, ascent joined
NotFound chromatic: completely unrelated with the current problems: can you take a quick look at github.com/jnthn/blizkost/pull/14 ? 00:49
chromatic Looking. 00:52
Seems sane. 00:53
00:53 dngor_ is now known as dngor
NotFound I've not do XS code for long time. Is that arg passing order corerct? 00:54
chromatic Yes. 00:56
ST(0) is thus the first argument on the stack
and therefore the first argument passed to the XSUB, ST(1) is the
second argument, and so on.
00:56 Psyche^ joined, Psyche^ is now known as Patterner
dukeleto covers the eyes of children, lest they learn about the horrors of XS 00:57
NotFound I was wondering why some of my blizkost tests gave strange results... %-)
chromatic I fixed that bug in Pugs, years ago. 00:58
kid51 used the line, "The horror, the horror", in his talk about ExtUtils::ParseXS at YAPC this year. 00:59
NotFound Good to know. With that fixed, using perl5 Gtk2 from parrot looks very doable. 01:00
dukeleto NotFound: that sounds nice
kid51 Woot
NotFound From winxed, of course.
ttbot Parrot trunk/ r48843 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386387.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 01:01
dalek rrot: r48843 | nwellnhof++ | trunk/src/string/encoding/ucs4.c:
[str] Fix to ucs4_hash to build without ICU
rrot: r48844 | luben++ | branches/hash_inlined_func:
Inline hash functions in hash.c - removes runtime indirection
01:02 dngor_ joined 01:03 dngor left
nwellnhof ucs2 and ucs4 rely on ICU only because of a typedef. i'm gonna fix that tomorrow. 01:03
can anyone confirm that r48843 fixes non-ICU build problems? 01:04
NotFound nwellnhof: if ttbot doesn't cry in a while, is fixed 01:06
kid51 rebuilds on Darwin/PPC 01:08
01:09 kid51 left, kid51 joined 01:10 dngor_ is now known as dngor 01:11 Patterner left
kid51 discovers the joys of the plain-text version of irclog.perlgeek.de; moritz++ 01:12
dukeleto purl, msg cotto_work i think porting tools/dev/mk_manifest_and_skip.pl is the most difficult thing left to do for the migration 01:15
purl Message for cotto_work stored.
01:16 Psyche^ joined, Psyche^ is now known as Patterner
dalek rrot: r48845 | dukeleto++ | trunk/tools/build/parrot_config_c.pl:
[tools] Refactor tools/build/parrot_config_c.pl . No functional changes
 01:18
rrot: r48846 | luben++ | branches/hash_inlined_func (9 files):
Merge branch 'fixes2-inlined' into hash_inlined_func
kid51 At r48843, Parrot now builds successfully on Darwin/PPC. nwellnhof++
will now run make test, but that will take a while
01:20 particle left
ttbot Parrot trunk/ r48845 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386445.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 01:21
luben I have created a svn branch with my work from last 3-4 days (hash_inlined_func). it is up-todate with trunc 01:22
kid51 taptinder now reporting different error on win32
01:22 particle joined
chromatic Wow. 01:22
Let me guess: missing header?
kid51 src/nci/extra_thunks.c 01:23
lots of 'undefined reference to ...'
plobsing_ what's with the _imp_ prefixes?
chromatic VS symbol mangling, probably.
dalek tracwiki: v20 | dukeleto++ | GitMigration 01:24
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
plobsing_ I know the problem: PARROT_IN_EXTENSION is defined! 01:25
which means it expects to link against an already compiled libparrot
luben the branch compiles and passes make_test (Configue --optimize, gcc-4.5, linux-amd64). It's open for test, review and comment 01:26
chromatic Oh, right. 01:29
01:31 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
plobsing_ to make nci thunks for core, parrot_nci_thunk_gen takes a --core option. or you could just run tools/dev/mk_nci_thunks.pl 01:32
kid51 luben: Is this branch being tracked by a Trac ticket?
luben no
how I do that?
kid51 Assuming you have an account at trac.parrot.org, you click on the New Ticket button and take it from there. 01:33
luben ok, I'll try
kid51 Value of ticket: Enables you to describe purpose of branch. Enables you to post a diff of branch from trunk. Enables people to post test result summaries. 01:34
Once you create a TT, you can also post to parrot-dev requesting that people provide feedback in that TT. 01:35
dalek rrot: r48847 | plobsing++ | trunk/src/nci (2 files):
run tools/dev/mk_nci_thunks.pl
 01:36
rrot: r48848 | jkeenan++ | trunk/lib/Parrot/Manifest.pm:
Correct semantic error in POD.
kid51 r 48843: make test PASS on Darwin/PPC
nwellnhof kid51: good to hear, thanks for testing 01:39
01:39 particle left
dalek TT #1775 created by luben++: Inline hash key_hash and compare functions 01:40
TT #1775: trac.parrot.org/parrot/ticket/1775
01:47 whiteknight left
nopaste "kid51" at 192.168.1.3 pasted "hash_inclined_func branch failures in t/pmc/hash.t" (182 lines) at nopaste.snit.ch/23258 01:50
kid51 paste 23258 is on Linux/i386 at r48846 01:51
01:52 PacoLinux left 01:57 nwellnhof left 01:58 Patterner left
chromatic luben, the key_hash_STRING() changes on the branch look counterproductive. 02:01
I backed it out and have better performance. 02:03
luben you are right
chromatic Want me to commit? 02:04
luben you have to change also in hash_get_bucket and hash_put
02:04 PacoLinux joined
luben it is manually inlined there 02:05
02:05 kid51 left
chromatic hash_get_bucket looks fine to me. 02:05
Same as parrot_hash_put 02:06
luben oh, I see. I was thinking we are talking about key_hash_STRING 02:07
for key_hash_STRING, you are absolutely right, its leftover from the try to use custom hash function in place of Parrot_str_to_hashval 02:08
02:13 patspam left 02:15 contingencyplan left
cotto ~~ 02:18
02:21 Psyche^ joined, Psyche^ is now known as Patterner
ttbot Parrot trunk/ r48848 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386527.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 02:23
dalek rrot: r48849 | chromatic++ | branches/hash_inlined_func/src/hash.c:
[hash] Simplified key_hash_STRING().
 02:26
luben chromatic, you could commit it. 02:28
chromatic Done!
02:29 ash_ joined
cotto where do nwellnhof and luben live? 02:32
plobsing_ when you phrase it like that, one might think twice about giving you that info ;-) 02:33
02:33 Psyche^ joined 02:34 Patterner left, Psyche^ is now known as Patterner
luben I am in Bulgaria, Sofia 02:34
cotto I associate them with chromatic's recruiting and am curious if they're also in pdx
guess not then
chromatic I recruit people for whom I am tired of applying their patches myself.
02:35 janus left 02:36 dafrito left
pmichaud I'm seeing test errors in t/compilers/pct in trunk... is anyone else seeing them? 02:37
02:37 ash_ left
dalek rrot: r48850 | chromatic++ | branches/hash_inlined_func/src/hash.c:
[hash] Sprinkled around some nice consts.
 02:43
02:47 Patterner left 02:48 janus joined 02:50 mariano__ joined
pmichaud looks like the failures come when --optimize is given 02:51
should I bisect, or ... ?
02:51 mariano__ is now known as bluescreen10
nopaste "bluescreen10" at 192.168.1.3 pasted "Getting get_string() not implemented in class 'XXXX' when using "get_class self"" (17 lines) at nopaste.snit.ch/23260 02:51
02:52 Psyche^ joined, Psyche^ is now known as Patterner
luben pmichaud, it's known failure on amd64 - most probably bug in stringbuilder somewhere 02:58
bluescreen10 seems like I'm dong something wrong at nopaste.snit.ch/23260 but I can't figure out what
BTW, I'm using parrot 2.4.0 03:01
03:02 ash_ joined
pmichaud bluescreen10: your :load subroutine gets executed twice. 03:03
luben: is the bug likely to be fixed anytime soon? 03:04
bluescreen10 well I even removing the load doesn't solve it
getting the same thing
luben everybody is looking for it. it appeared after porting string_join to use internaly stringBuilder 03:05
cotto Why not use the clone pir op? 03:06
though it does seem odd that the method would fail
03:07 Patterner left
bluescreen10 originally wanted to clone the class so i used get_class to get the class and then clone it 03:07
cotto: should that work or I'm missing the boat ?
chromatic The Object PMC probably needs a default get_string. 03:08
bluescreen10 mmm.. even outside the subroutine fails. 03:09
chromatic: why in the first place get_class calls get_string()? shouldn't that return a ref to class's PMC? 03:10
chromatic It's metacircular.
A Class PMC is an instance of Object.
Though that doesn't answer your question, I now realize. 03:11
bluescreen10 is it because get_class can be overloaded ?
i mean you can do get_class $S0, but in this case is a $P 03:12
cotto Would it make sense for Parrot_oo_get_class to use VTABLE_name instead of VTABLE_get_string?
03:13 Psyche^ joined
chromatic Seems like we're missing a case in the switch for enum_class_Object. 03:13
03:13 Psyche^ is now known as Patterner
pmichaud get_class isn't supposed to work on instance 03:13
if you want the class, use typeof 03:14
cotto ...
pmichaud $P0 = typeof self
get_class locates a class based on an RSA, Key, or String.
(or namespace)
bluescreen10 that makes sense pmichaud, thanks! 03:15
cotto Sounds like it needs to fail in other cases then. 03:16
pmichaud well, it assumes that if it's not one of those, then it's a string of some sort.
or something that stringifies
which is why it does get_string 03:17
chromatic That smells fragile.
bluescreen10 ..hmmm..
pmichaud (I'm not saying that's correct behavior.. it's just traditional, unfortunately.)
for the longest time classes were known by their string names more than their class object identity. We still have a lot of code like that in Parrot, I fear.
(and code that depends on that interpretation, I suspect) 03:18
cotto adds a failing default case and sits back for some fireworks
bluescreen10 hehe 03:19
plobsing_ bluescreen10: are you sure you don't want to use typeof_p_p in stead?
pmichaud cotto: be careful with that -- especially subclasses of String or NameSpace
chromatic +1 to deprecate the old behavior.
pmichaud (Rakudo definitely has subclasses of String for its strings) 03:20
bluescreen10 plobsing, I'm sure I now want to use that
cotto Yeah. We definitely rely on that behavior. PGE doesn't build without it.
doesn't work, even with a check for the "string" role 03:22
chromatic Crazy. 03:24
cotto there's no role for namespace-like thingies, is there?
It seems to build if I explicitly check for enum_class_NameSpace 03:25
pmichaud PGE and PCT and the like tend to use namespaces to identify classes 03:26
(if only because that's been declared "the official way to do it")
nopaste "cotto" at 192.168.1.3 pasted "tighten up Parrot_oo_get_class" (18 lines) at nopaste.snit.ch/23261
cotto let's see how the test suite feels about that 03:27
pmichaud oh yes
iirc, the namespace check there is handling the case of something like $P0 = get_namespace ['Integer']; $P1 = get_class $P0 03:28
i.e., the namespaces for the built-in PMC types
cotto bluescreen10, thanks for reporting that oddity 03:29
bluescreen10 i wish i had more insights into parrot's guts to come up with something more useful
cotto make test passes
suggestions for a better exception message? 03:34
bluescreen10 I rather make documentation a little bit clear 03:39
cotto ok. In addition to a docs update, is "can't use get_class on a class or instance" a reasonable message? 03:41
pmichaud that doesn't sound right 03:42
03:42 ash_ left, ash_ joined
pmichaud I think the previous message you had (where it identifies the type) is better 03:42
can't use get_class on a '%Ss' 03:43
you could do "on an instance of '%Ss'"
cotto I'm tempted to make it say "can't use get_class on an instance; you probably want typeof" 03:51
pmichaud yes, except that Strings, RSAs, and NameSpaces *are* instances. :-) 03:52
cotto but you're not using them to get the String class 03:53
unless it's a String with the value "String"
pmichaud okay. The only other thing is that Parrot_oo_get_class gets called from a lot of places other than just the opcode. 03:55
cotto Yeah. It's messy.
What if it returned NULL in those cases and let the op throw a nicer message? 03:56
pmichaud I think returning NULL is in-bound. 03:57
i.e., get_class 'NoSuchClass' should return NULL
I think we even use that a few places -- for example, to avoid creating a class that already exists. 03:58
(for libraries that are somehow loaded more than once)
luben I am chasing amd64 optimized builds bug 03:59
pmichaud luben: good. Rakudo fails some of its spectests with current Parrot trunk.
luben it seems related with GC and StringBuilder 04:00
at which point the GC mark is run?
04:02 Patterner left
luben pmichaud, parrot also fails test with otimized builds on amd64 04:03
pmichaud luben: yes.
luben does GC run is triggered somehow on vtable dispatch? 04:05
it seems strange
pmichaud GC runs tend to be triggered on allocation requests, iiuc
so if a vtable does something that needs to allocate memory, then it can cause gc to be triggered. 04:06
but GC is definitely not my area of expertise.
04:07 bluescreen10 left 04:08 Psyche^ joined, Psyche^ is now known as Patterner
luben if I block GC arround invocation of Parrot_pmc_new_init(interp, enum_class_StringBuilder,ar) everything is fine, but if I block GC inside the init, it does not help... this is strange 04:09
chromatic The array should be getting marked. 04:10
Hm, should SB have a custom mark? 04:11
04:12 plobsing_ left 04:13 bluescreen left
bacek_at_work chromatic, no. It uses system memory. 04:20
04:21 Patterner left 04:24 jsut joined
dukeleto 'ello 04:25
04:27 Psyche^ joined, Psyche^ is now known as Patterner 04:29 jsut_ left
luben bacek, does the PMCs on on the stack get marked? 04:33
bacek_at_work luben, yes.
04:34 Patterner left
cotto as long as they're not after the end of a struct, e.g. when a larger struct gets cast to a smaller one 04:34
bacek_at_work PMCs are fixed size. 04:36
PMC attributes are not, but it's irrelevant.
cotto Sorry. I meant "as long as the pointer to the pmc"..., and that's not a concern for most code 04:41
04:43 Psyche^ joined, Psyche^ is now known as Patterner
nopaste "chromatic" at 192.168.1.3 pasted "Let's try this for AMD64 and StringBuilder" (17 lines) at nopaste.snit.ch/23262 04:44
04:45 tcurtis joined
luben it seems that StringBuilder.get_string is somehow broken 04:46
chromatic, I have tried this and does not work
chromatic You think get_string() is the culprit?
luben look here: luben.spnet.net/gitweb/?p=parrot/.g...heads/temp 04:47
ugly code to find where the things break
it works like that, but if I remove block/unblock arround get_string it breaks 04:48
04:50 M_o_C joined
chromatic Is the buffer moving out from under the StringBuffer? 04:51
Shouldn't be, with the external flag set.
04:56 Patterner left 04:57 Psyche^ joined, Psyche^ is now known as Patterner 05:04 particle joined 05:05 ash_ left 05:06 Patterner left
nopaste "chromatic" at 192.168.1.3 pasted "Avoid Parrot_str_clone() in SB" (17 lines) at nopaste.snit.ch/23263 05:12
chromatic Any better?
05:21 dafrito joined
luben I'll try 05:21
no, the same 05:23
dukeleto I've added #phasers to the Parrot Calendar on parrot.org, so people (like me) can set reminders. Hope that doesn't ruffle any feathers 05:25
chromatic Hm. How about deleting the PObj_is_string_FLAG on line 73 of stringbuilder.pmc?
05:26 luben_work_ joined, luben_work left
luben chromatic, it does not change anything. Wierd - even with blocked GC runs, some other test fail. This test never call string_join 05:29
nopaste "luben" at 192.168.1.3 pasted "amd64 fail" (4 lines) at nopaste.snit.ch/23264 05:30
chromatic I'm out of ideas for the night.
05:30 Psyche^ joined 05:31 Psyche^ is now known as Patterner
luben may be it is not a bug in string builder or string_join... me also 05:31
chromatic Not sure what else it might be. 05:33
05:33 dafrito left
nopaste "chromatic" at 192.168.1.3 pasted "luben: avoid GC for fixed size pool exhaustion" (53 lines) at nopaste.snit.ch/23265 05:34
chromatic Does that fail for you too?
bacek_at_work SB.get_string is horribly wrong...
05:35 particle left
bacek_at_work It should use Parrot_str_new_init 05:35
Something Parrot_str_new_init(INTERP, buffer->_bufstart, buffer->_buflen, buffer->encoding, 0); 05:36
chromatic We tried that a bit ago.
05:38 Patterner left
luben chromatic, GC-patch fixes it 05:39
but t/compilers/pct/complete_workflow.t still fails
chromatic Hm, I wonder why that didn't work for Patrick. 05:40
luben I'l try to bisect when that happened
bacek_at_work Do we have ticket for it? I can look at it tonight @home on amd64 05:47
luben bacek_at_work, no ticket as I know, It hapens on optimized amd64 builds. Sometimes only with -O3, sometimes with -O2 (depending on the gcc version 4.4/4.5 here) 05:53
bacek_at_work luben, ok. Thanks for info.
nopaste "bacek" at 192.168.1.3 pasted "luben, can you try this patch?" (13 lines) at nopaste.snit.ch/23266 05:56
"bacek" at 192.168.1.3 pasted "luben, can you try this patch (full version)?" (13 lines) at nopaste.snit.ch/23267 05:57
bacek_at_work second one
luben bacek_at_work, we have tried this without effect. 05:58
05:58 Psyche^ joined, Psyche^ is now known as Patterner
bacek_at_work hmm... Strange. 05:59
purl But true.
bacek_at_work purl, annoying girl
purl bacek_at_work: what?
luben bacek_at_work, one of the test that exhibit this strange behaviout is t/library/mime_base64.t 06:00
another failing test is t/compilers/pct/complete_workflow.t, but I thing it's not related 06:01
06:09 uniejo joined 06:23 Psyche^ joined, Patterner left, Psyche^ is now known as Patterner 06:30 Patterner left 06:34 Psyche^ joined, Psyche^ is now known as Patterner, chromatic left, theory left 06:43 Patterner left 06:51 fperrad joined
sorear seen Whiteknight 07:00
purl Whiteknight was last seen on #parrot 7 hours, 2 minutes and 15 seconds ago, saying: you guys are on fire today
aloha Whiteknight was last seen in #parrot 7 hours 2 mins ago saying "you guys are on fire today".
07:04 M_o_C left
dalek rrot: r48851 | cotto++ | trunk/src (2 files):
make Parrot_oo_get_class fail less surprisingly and improve docs
 07:14
ttbot Parrot trunk/ r48851 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386810.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 07:32
dalek a: fe73b9c | fperrad++ | dynext/pmc/luastring.pmc:
fix build after trac.parrot.org/parrot/changeset/48842
 07:35
07:37 tadzik joined 07:38 jsut_ joined 07:43 jsut left 07:47 tadzik left 08:11 tadzik joined 08:19 tadzik left
dalek rrot: r48852 | luben++ | branches/hash_inlined_func/src/hash.c:
use some functions and macros defined in the new encoding refactor
 08:39
rrot: r48853 | luben++ | trunk/src/string/encoding/shared.c:
Speed up equality check of same encoding multibyte strings

can memcmp between strings of same enconding
sorear that patch assumes that two strings in the same encoding are equal iff they have the same bytes 08:47
this appears to be currently true; do we plan to keep it that way?
ttbot Parrot trunk/ r48853 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386870.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
moritz seems to collide with darbelo's NFG work, no? 08:48
sorear darbelo has vanished 08:49
08:56 tcurtis left
bacek aloha, humans 09:01
cotto perl6: <0 1>.pick(1).say 09:04
p6eval pugs, rakudo 19a8b7: OUTPUT«0␤»
cotto perl6: <0 1>.pick(1).say 09:05
p6eval pugs, rakudo 19a8b7: OUTPUT«0␤»
cotto perl6: <0 1>.pick(1).say
p6eval pugs, rakudo 19a8b7: OUTPUT«0␤»
cotto perl6: <0 1>.pick(1).say
p6eval pugs: OUTPUT«1␤»
..rakudo 19a8b7: OUTPUT«0␤»
cotto perl6: <0 1>.pick(1).say
p6eval pugs: OUTPUT«1␤»
..rakudo 19a8b7: OUTPUT«0␤»
cotto perl6: <0 1>.pick(1).say
p6eval pugs, rakudo 19a8b7: OUTPUT«1␤»
cotto I guess that's random. 09:06
hio bacek
bacek aloha, cotto
cotto who owns ttbot? 09:09
ttbot?
purl hmmm... ttbot is TapTinder build bot owned by mj41 and reporting tt.taptinder.org/buildstatus/pr-Parrot/rp-trunk build errors. See also TapTinder.
cotto mj41, ping 09:10
I guess it's not critical to have ttbot updated exactly when we move to git, but it'd be a shame to lose it for long. 09:11
seen mj41 09:12
purl mj41 was last seen on #parrot 42 days, 15 hours, 42 minutes and 9 seconds ago, saying: Lost connection to server irc.perl.org. [Jul 27 17:30:16 2010]
aloha mj41 was last seen in #parrot 1 days 18 hours ago joining the channel.
cotto aloha, seen mj41
aloha cotto: mj41 was last seen in #parrot 1 days 18 hours ago joining the channel.
cotto purl, seen mj41
purl mj41 was last seen on #parrot 42 days, 15 hours, 42 minutes and 36 seconds ago, saying: Lost connection to server irc.perl.org. [Jul 27 17:30:16 2010]
cotto purl, msg mj41 We're planning on moving Parrot to git. What would it take to update ttbot to use a github repo instead of svn? 09:13
purl Message for mj41 stored.
smash mornin' everyone 09:14
cotto morning, smash 09:15
bacek, have you seen the recent changes to the GitMigration wiki page? 09:17
bacek cotto, nope
cotto please take a look and add anything you think should be there 09:18
dukeleto and I have been fleshing it out recently
bacek tools/dev/mk_native_pbc? I don't think it has svn dependency 09:39
cotto It automatically commits generated pbc, so it's a trivial dependency 09:45
bacek ah 09:50
I wasn't aware about this "functionality" :)
And we generate native PBCs during build now
Hang on.
purl Hang on. is this actually "session is still there but user has been deleted" ?
bacek It's just echoing commands for commit new pbc. But don't commit them 09:51
ok. 09:56
recent regressions in t/compilers has nothing to do with StringBuilder.
It's some horrible GC/PCC failure. 09:57
-PCC
Just GC.
dalek kudo: b736c88 | patrickas++ | src/ (2 files):
add ...^ operator
 10:17
kudo: 0a93184 | patrickas++ | src/core/operators.pm:
Cleanup as per pmichaud++'s comment
kudo: 4615073 | moritz++ | src/core/operators.pm:
Refactored series operator

Conflicts:
  \tsrc/core/operators.pm
kudo: f763b7e | patrickas++ | src/core/operators.pm:
Minor refactor for series
kudo: c2a00c0 | patrickas++ | src/core/operators.pm:
Made infinite-series lazier
kudo: 11e8510 | patrickas++ | src/core/operators.pm:
More refactor of the series op with help from colomon++
kudo: 938cb3e | patrickas++ | src/core/operators.pm:
is-on-the-wrong-side only returns true when the rhs is on the wrong side of ALL the lhs
kudo: 049af59 | patrickas++ | src/core/operators.pm:
Support for infix ops as last item of lhs in series
kudo: e102240 | patrickas++ | src/core/operators.pm:
Fix regression from previous commit
kudo: da97ee9 | patrickas++ | src/core/operators.pm:
All the series tests pass again
kudo: ea77ccd | moritz++ | src/ (2 files):
Merge remote branch 'origin/series-refactor'

See github.com/rakudo/rakudo/pull/3 for a discussion of what features that brings us.
Note that this implements still the "old" series specs, but works much more robust than before, and hopefully makes it also easier to adopt to the new spec (since it supports closures on the RHS).
Infinoid Hmm. Was that botspam expected? 10:33
moritz spam? all valuable commits :-)
Infinoid Oh, good
Infinoid feared another false history bug
moritz it was a branch merge - one can argue whether that should show all commits from that branch 10:34
'git log' does, and so does dalek
Infinoid My counterargument would be that it's hard for dalek to tell the difference
It just looks for hashes it hasn't seen before...
moritz well, I've said "one can argue", not taken a position
the current behavior works well for me 10:35
Infinoid Ok :)
10:59 ruoso left 11:38 hudnix left
dalek tracwiki: v21 | cotto++ | GitMigration 11:39
tracwiki: get cracking on git-aware tools
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
Coke luben - you're in Sofia? I used to work with a remote dev team there. They owe me beer if I ever show up. ;) 11:56
msg dukeleto: when you added it, did you do it from the UTC timezone so it tracks DST with no worries? 12:05
purl Message for dukeleto stored.
aloha OK. I'll deliver the message.
Coke mk_native_pbc shouldn't automatically commit anything. 12:06
msg luben - you're in Sofia? I used to work with a remote dev team there. They owe me beer if I ever show up. ;) 12:07
purl Message for luben stored.
aloha OK. I'll deliver the message.
pmichaud Perhaps luben could collect the beer for you? ;-)
luben_work_ coke, glad to hear 12:08
Coke pmichaud: NO MY BEER! 12:09
cotto 85/.45 12:10
purl 188.888888888889
aloha 188.888888888889
Coke Добро утро
Coke ponders digging up his bulgarian book again to practice on luben. 12:11
luben_work_ Добро и на теб
pmichaud parrot trunk no longer builds on my system :( 12:12
afk for 20
luben_work_ Coke, and if you show in sofia, I'll buy you another beer :) 12:13
cotto Coke, it doesn't. It just spits out the command in case the user wants to copy-paste it.
dalek tracwiki: v22 | cotto++ | GitMigration
tracwiki: note which scripts have been converted so far
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
Coke cotto: so have it not spit out the command, done. 12:14
luben_work_: oooh, благодаря.
cotto I don't have enough brainpower to evaluate that statement. I'm going to bed.
Infinoid, i'd be nice if dalek tracked the not-from-svn branches in the parrot github repo, i.e. the ones like leto/git_docs and cotto/git_aware_tools 12:16
Coke finds a nice oatmeal comic that really speaks to him about the presence of the utilikilt folks at yapc. 12:17
Infinoid: but if that doesn't happen until post-switch, that'd probably be ok.
dalek rrot: r48854 | NotFound++ | trunk/t/pmc/hashiterator.t:
add a few tests to hashiterator.t and fix its description and comments
 12:18
12:18 Themeruta joined 12:19 Themeruta is now known as NotFound_b 12:25 JimmyZ joined
ttbot Parrot trunk/ r48854 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386967.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 12:32
Coke I'm able to build trunk. 12:38
pbc_merge.obj : error LNK2001: unresolved external symbol _Parrot_default_encoding_ptr
(from TT)
12:39 ruoso joined
pmichaud Coke: I think that amd64 systems have difficulty. 12:40
But the trunk build has deteriorated. Last night I could build but not pass tests. This morning I cannot build. :( 12:41
Coke pmichaud: what's the error? 12:42
purl the error is KABOOM!
pmichaud just a sec, rebuilding again 12:43
Coke (if it looks like the taptinder error that just hit, presumably someone will be working on it.)
pmichaud huh, it built this time on my other machine. 12:47
Let me try the original again.
moritz pmichaud: I had no trouble building today 12:48
and rakudo passes most tests
(all except two spectest files)
12:50 NotFound_b left
pmichaud gist.github.com/570088 # error I get when trying to build Parrot using "--gen-parrot" from Rakudo. 12:52
basically, I set build/PARROT_REVISION to 48854 and then did the standard "perl Configure.pl --gen-parrot" 12:53
NotFound pmichaud: is the same kind of error we are having since yesterday. Funny characters in generated code. 12:54
pmichaud NotFound: right, okay. I'm just reporting broken builds.
moritz tries again after git clean -xdf
Coke and that's in dynoplibs, which is gen'd each time. 12:55
I bet it's nwell* recent stringbuilder changes.
pmichaud: you have ICU?
pmichaud Coke: yes.
Coke (enabled)
hurm. my line 536 is empty. 12:56
can you nopaste that bit of bit_ops.c ?
moritz pmichaud: is 'svn status' clean? 12:57
pmichaud moritz: fresh checkout.
moritz huh
pmichaud gist.github.com/570097 # lines 527-539 of bit_ops.c 12:58
Coke looks like extraneous garbage from the end of a C string.
NotFound Coke: or maybe wrong encoding 12:59
Coke (not that that looks like anything in particular.)
pmichaud I'll do one more fresh checkout, just in case.
luben_work_ the problem on amd64 is bad interaction between StringBuilder (that got excercised after porting string_join on ot) and our GC - there are ways to workarround it, but it's not a fix. 13:01
bacek, promised to take a look on it today
NotFound pmichaud: Can you try this: replace line 3112 of string/api.c with CONST_STRING(interp, "") 13:05
pmichaud my line 3112 says 13:07
j_length = Parrot_str_byte_length(interp, j);
...that's the one you want me to replace?
NotFound No... i'll better nopaste a patch
13:07 particle joined
pmichaud gist.github.com/570109 # (fwiw) steps used to obtain build failure on my system 13:09
nopaste "NotFound" at 192.168.1.3 pasted "patch for str_join" (13 lines) at nopaste.snit.ch/23268
NotFound My fault, I had some debug comments added 13:10
Coke thinks that 48853 looks odd.
ah, looks better in context. 13:11
NotFound pmichaud: nopasted the fix 13:12
pmichaud NotFound: applied, rebuilding
NotFound With that change amd64 --optimize builds here
pmichaud gist.github.com/570114 # new build failure after patch 13:14
NotFound For me build, but fails several tests 13:15
Coke that loosk like the same error.
pmichaud it's an error in the same place, but the strings are different this time 13:16
particle everybody sing happy birthday to chromatic when he shows up today! 13:20
luben_work_ NotFound, stringBuilder's buffer get sweeped under it. there are 2 workarounds: 1. block GC for string_join, 2. do not run GC compact fixed pool on pool exhaustion. 13:24
NotFound Why StringBuilder doesn't have a custom mark?
13:24 TiMBuS left, shockwave left, TiMBuS joined
luben_work_ NotFound, buffer is attribute and is set to be marked automatically 13:25
pmichaud Huh, this is weird. If I try to build Parrot from a git checkout, it builds okay. If I try to do it from an svn checkout, I get the build error.
NotFound luben_work_: automatically? By whom?
moritz pmichaud: I also use a git checkout. Which might explain why it builds for me. Let's switch to git :-) 13:26
NotFound Oh, I see. That shit isn't a string at all. No wonder it fails in bizarre ways. 13:27
luben_work_ because it is in the pool for pmc attributes
NotFound Proposal: kill Parrot_str_clone. Is a source of bugging misuses 13:29
pmichaud reconfirmed on my system. An svn checkout fails to build. A git checkout succeeds. 13:32
(I agree that makes almost no sense.)
moritz the only difference should be (1) expansion of modelines and (2) revison information 13:33
13:35 whiteknight joined, JimmyZ left, nwellnhof joined
NotFound Another attempt of fix: in line 73 of stringbuilder.pmc add: | PObj_constant_FLAG to the buffer->flags setting 13:38
No, doesn't solve almost nothing 13:40
pmichaud Now re-reconfirmed on my other system. svn checkout fails to build. git checkout succeeds. 13:41
NotFound Great
pmichaud so, I'll diff the sources and see what's.... different. :-) 13:42
Coke msg chromatic let me know if you want me to bludgeon particle for you.
purl Message for chromatic stored.
aloha OK. I'll deliver the message.
pmichaud msg Coke please bludgeon particle anyway 13:43
purl Message for coke stored.
aloha OK. I'll deliver the message.
nwellnhof I think we should try to mark the StringBuilder buffer. It shouldn't be necessary, but I suspect that buffer seomhow gets collected.
Coke what could be different between the two... line endings?
ok. if we're not ready to switch to aloha, he needs to shut up. 13:44
NotFound Coke: line endings is multiline macros can do funny things. Ususally they give warnings, but...
pmichaud a configuration might be looking for a file that exists in an svn checkout but not in git (or vice versa) 13:47
(I agree this is stretching... but I'm totally surprised that I can consistently build git checkouts but not svn ones) 13:48
Coke pmichaud: does rakudo have a plan for dealing with parrot's cutover to git for --gen-parrot? 13:49
pmichaud Coke: I'll likely re-do gen-parrot. 13:50
Coke Let's throw it out to #perl6 and see if anyone steps up. ;)
pmichaud well, it has to be done for nqp-rx also. :)
NotFound pmichaud: <conspiration>Maybe someone is doing it on purpose to speedup the switch to git?</conspiration> 13:51
nopaste "nwellnhof" at 192.168.1.3 pasted "stringbuilder-mark.diff" (19 lines) at nopaste.snit.ch/23269
pmichaud NotFound: maybe. Wish I had thought of it sooner? ;-)
moritz dukeleto++ submitted a patch for --gen-parrot and git (in the fork queue)
it doesn't do the version comparison yet
nwellnhof can anyone with the stringbuilder problems try the patch above?
pmichaud how does Parrot get its 'revision' configuration entry, ooc? 13:52
luben_work_ nwellnhof, compiling 13:54
pmichaud what is tools/dev/nm.pl, oocu? 13:55
*ooc?
13:55 hudnix joined
NotFound nwellnhof: fails for me 13:55
luben_work_ and for my
nwellnhof ok, it was just a guess 13:56
luben: you said the problems go away if you block the GC inside StringBuilder's get_string?
luben_work_ no, if I block GC in parrot_string_join, arround usage of StringBuilder 13:57
nwellnhof ah, ok 13:58
moritz didn't bacek do that in r48767 already?
14:02 uniejo left 14:06 contingencyplan joined
NotFound tapir2.ro.vutbr.cz/cover/cover-resu...r-pmc.html --> A critical part of StringBuilder is not covered by tests 14:08
moritz you mean lines 197-201? 14:09
NotFound Yeah 14:10
Coke NotFound: is it me, or is that case already handled at 216? 14:12
also, why is 197 doing a free before doing anything with the old buffer?
14:12 patspam joined
pmichaud is buffer->strstart still valid after doing the mem_gc_free ? 14:13
Coke (ah, no, it's stored at #192.)
pmichaud (lines 199 and 197)
14:13 particle left
pmichaud oh, nm 14:13
it's a double assign
Coke seems like that whole section can be ripped out anyway due to #216-222 14:14
pmichaud oh, but we then do a memcopy?
okay, I get it.
whiteknight good morning, #parrot 14:15
14:16 shockwave joined
shockwave Howdy. 14:16
pmichaud when we do mem_gc_alloc_n_typed (line 200) or mem_gc_realloc_n_typed (line 220), is it possible we're losing the string allocated by the encoding conversion earlier (line 186)? 14:17
i.e., perhaps those allocs are causing a gc run?
shockwave I just ran some tests to see if a property assigned to a PMC is transferred to the other upon doing $P0 = $P1. And it appears to be the case. Is there anything anyone knows that I should keep in mind when doing this?
nwellnhof i think the ->to_encoding is the problem
luben_work_ moritz, it was patch arround old string_join implementation. bacek said that using stringbuilder not require GC blocking 14:18
pmichaud shockwave: your question is wrong.
moritz ah
nwellnhof i made some changes to the to_encoding functions that aren't compatible with the way StringBuilder uses them.
shockwave pmichaud: Can you qualify your statement? 14:19
pmichaud $P0 = $P1 doesn't transfer anything.
luben_work_ nwellnhof, this bug dates before your branch merge
pmichaud it just causes register $P0 to point to the PMC at $P1.
nwellnhof luben: but back then we had the bug in str_clone 14:20
14:20 Andy joined
pmichaud (and so yes, both $P0 and $P1 will appear to have the same properties, because they are in fact the same PMC) 14:20
shockwave pmichaud: oh, I see. I don't know why I always think of = as assignment.
moritz because that's what non-assembler languages use :-) 14:23
shockwave @moritz: hehe, as soon as I wrote that last statement I told myself that same thing.
14:32 Andy left
dalek rrot: r48855 | nwellnhof++ | trunk/src/string/encoding (5 files):
[str] Switch back to str_clone in to_encoding functions
 14:32
pmichaud nwellnhof: I have a different patch for StringBuffer I'm about to work on 14:33
(testing r48855 though) 14:34
nwellnhof r48855 probably doesn't help, but it's safer that way 14:35
pmichaud yes, I'm curious to see if 48855 helps
okay, I still get build failure for svn checkout of 48855 14:36
ttbot Parrot trunk/ r48855 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/387058.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 14:39
luben_work_ it does not help for me neither 14:40
14:41 Andy joined
nwellnhof luben: i'm still curious if the call to to_encoding is the problem. can you maybe try to block the GC during the whole encoding stuff in push_string? 14:42
pmichaud I'm trying that now. 14:43
My first attempt didn't seem to help.
...and neither did my second attempt. I'm guessing it's not gc in push_string that is the issue. 14:44
14:45 particle joined
pmichaud gist.github.com/570226 # fwiw, the patch I tried 14:45
I think the patch w/o the gc block/unblock might be worthwhile, anyway.
avoids the extra memcopy code. 14:46
although I don't know if any other code relies on the buffer attribute being invariant.
nwellnhof the extra memcopy is needed because the stringbuilder buffer is external. 14:48
pmichaud okay, makes sense.
this is my first time to look at the stringbuilder pmc
and just to confirm, adding block_GC_mark and unblock_GC_mark to push_string (with no other changes) doesn't resolve the problem for me either. 14:51
14:52 ash_ joined, contingencyplan left 14:53 silug left
luben_work_ pmichaud, if you add block_GC_mark & unblock_GC_mark in src/string/api.c, arround Parrot_str_join it will help you 14:53
pmichaud luben_work_: I'm looking for a permanent (commitable) fix, not just something to get me by. 14:54
NotFound What the hell is latin1 encoding?
pmichaud luben_work_: for what I'm doing (Rakudo) -- uncommitted changes to trunk aren't at all useful. 14:55
luben_work_ pmichaud, yes, I understand.
pmichaud or, phrased another way -- currently we can't update PARROT_REVISION in Rakudo until this bug is resolved. 14:56
NotFound Parrot_str_join uses vtable calls that can throw. If you block the gc and something throws, you get the gc blocked 14:57
moritz "what could possible go wrong"
NotFound moritz: just the build 14:58
whiteknight What's the problem in Parrot_str_join that requires the GC to be blocked? 15:09
nwellnhof whiteknight: build failures on amd64 with --optimize 15:14
r48857 might help with the StringBuilder issue 15:15
pmichaud I'm still quite amazed at the git vs. svn difference
checkouts with 'svn export' fail also. 15:16
so it's not the presence/absence of .svn directories
15:17 theory joined
pmichaud nwellnhof: testing r48857 now 15:17
nwellnhof: still fails (at the same place) 15:19
I wish there was some way to get an svn export without keyword expansion :-| 15:20
moritz for making a diff?
iirc the keyword expansion is client side, so you'd "just" have to patch your localy svn installation 15:21
pmichaud to see if keyword expansion is part of why the build fails
moritz as a stopgap measure you can just re-substitute them with a regex
pmichaud yeah, I'm thinking of doing that
moritz perl -i -pe ftw 15:22
dalek rrot: r48856 | nwellnhof++ | trunk/src/string/api.c:
[str] Don't allocate empty string storage
 15:23
rrot: r48857 | nwellnhof++ | trunk/src/pmc/stringbuilder.pmc:
[pmc] Never allocate empty strings in StringBuilder
ttbot Parrot trunk/ r48856 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/387124.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 15:24
whiteknight nwellnhof: what compiler on amd64? GCC I assume? 15:25
nwellnhof nwellnhof: i don't know. i'm on 32bit and can't reproduce it. 15:26
whiteknight ah, gotcha
I can't reproduce it then until I get home tonight
ash_ i have 64-bit OS X, and access to a 64-bit linux machine if you need me to test something
pmichaud I can probably make an account on this box, too. 15:27
just a sec
ash_ oh, that reminds me, last time i tried it, doing --m=32 on OS X has no effect, and it might be nice/useful if we could specify to build a universal binary on OS X 15:28
ttbot Parrot trunk/ r48857 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/387150.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 15:37
pmichaud oh, another data point: I seem to get the build failure only when passing a --prefix= option to Configure.pl .
ash_ on OS X 64 bit, the latest trunk with --optimize built fine, running tests 15:39
pmichaud ash_: what kind of checkout did you do?
ash_ svn co svn.parrot.org/parrot/trunk/
15:40 silug joined
ash_ built with apple gcc 4.2 15:40
pmichaud did you try building with --prefix= passed to Configure.pl ?
ash_ no, but i can
i got 3 errors in pge, and 1 error in a library mime_base64 15:41
15:41 chromatic joined
luben_work_ nwellnhof, still the same @ r48857 15:41
ash_ i am adding a --prefix and --optimize to see if that changes anything 15:42
luben_work_ whiteknight, bugs manifest on linux amd64 with gcc-4.4 -O2 and gcc-4.5 -O3
nwellnhof ash_: can you post the output of the mime_base64 test
luben_work_ ash, t/library/mime_base64.t
ash_ nwellnhof: ummm sure... i just started re-compiling though, ill let this finish first 15:43
whiteknight how does the build fail? crash? segfault? Is there a backtrace somewhere I can take a peek at?
nwellnhof mime_base64 seems to be unicode related
ash_ doing: parrot t/library/mime_base64.t instantly segfaults 15:44
NotFound whiteknight: garbage inserted in generated files
ash_ well, not instantly, it prints 1..550
then segfaults
luben_work_ pmichaud, the only obvious reason for git/svn difference is in SVN ID that is inserted in svn checkout
whiteknight great
pmichaud luben_work_: yes, I know.
whiteknight: I'm generating a fresh build failure now 15:45
ash_ it dies in: Parrot_str_rep_compatible
i can give you a gdb stacktrace if you want
whiteknight pmichaud: awesome. Let me know when you have it and I'll take a looksie
nopaste "luben" at 192.168.1.3 pasted "amd64 fail, gcc-4.5 -O3" (6 lines) at nopaste.snit.ch/23271
nwellnhof ash: a backtrace would be nice
pmichaud whiteknight: it's very bizarre here. It only fails the build if I grab parrot from an svn checkout, and use both the --prefix= and --optimize flags on Configure (more) 15:46
if I use a git checkout, no failure.
whiteknight urg. This just sounds wonderful
pmichaud However, it's extremely repeatable, and I've confirmed it on two separate machines.
ash_ nwellnhof: gist.github.com/570315
nwellnhof hmm, no line numbers 15:47
ash_ nwellnhof: i did --optimize, i can leave that out if you want to give you some
or is there another option that adds line numbers with --optimize?
luben_work_ ash_, but then you will not get the crash
nwellnhof i think it's -g but that should be enabled with optimized builds, too 15:48
15:48 rblackwe left
pmichaud gist.github.com/570319 # latest build failure, for whiteknight++ 15:49
nwellnhof but it can only be a NULL string or a NULL encoding in string_rep_compatible
whiteknight urg. that's horrible 15:50
Coke nwellnhof: why force initial_string_capacity there instead of just checking for 0?
--optimize --ccflags="-g"
whiteknight pmichaud: you say it happens when you use --prefix=? Does it ever happen without that?
pmichaud whiteknight: I haven't tried it w/o --prefix very often. I almost always configure with --prefix, because Rakudo and NQP need installed parrots. 15:51
I don't know if it's failed w/o prefix present. In all likelihood it's just the present of prefix is tickling the GC in some way that makes the problem manifest during the build. 15:52
*presence
whiteknight pmichaud: if it requires --prefix, I think we can narrow it down to a problem in the library path search logic. like a string not being properly anchored there
nwellnhof Coke: the size given to init_int is only a guess. we might need more than that. so i think it's ok to allocate at least initial_string_capacity.
whiteknight if we don't need --prefix, then we need to look elsewhere
pmichaud whiteknight: well, that's what causes the build failure. Other people get past the build, but then see test failures.
whiteknight ah, I see. 15:53
Coke nwellnhof: if it was only a guess, why bother even supporting it?
pmichaud (that have the same underlying cause -- i.e., generated files that are corrupt)
Coke why not just use our builtin guess?
NotFound It fails for me with --optimize without --prefix
pmichaud NotFound: the build fails, or tests fail?
ash_ nwellnhof: i still get the error without --optimize 15:54
nwellnhof Coke: what builtin guess?
NotFound pmichaud: the build
purl the build is called $self->BUILD($param)
moritz fwiw, rakudo on latest parrot has lots of spectest failures (aborted tests)
pmichaud NotFound: interesting.
ash_ nwellnhof: gist.github.com/570324
pmichaud nwellnhof: would it help to have access to a 64-bit machine? I can give you a guest account here.
moritz ./perl6 t/spec/S32-list/reduce.rakudo aborts with
can't get class from an instance of class 'P6role' in 'Test::isa_ok' at line 142:Test.pm in main program body at line 61:t/spec/S32-list/reduce.rakudo
ash_ is a stack trace with numbers (basically i just did perl Configure.pl && make && parrot t/library/mime_base64.t 15:55
moritz (with a previous parrot version and no rakudo change, this test was fine)
nwellnhof ash: it might be something unrelated, but it's still interesting 15:56
Coke nwellnhof: the initial_capacity constant that you just used. 15:57
nwellnhof pmichaud: maybe later
pmichaud nwellnhof: okay, let me know. I have one set up now if you need it.
I have to take a break for a bit -- bbl
nwellnhof Coke: yes we could do that. but we would only save some bytes that might be allocated later anyway. 15:59
NotFound make corevm ; make coretest pass except for the integer and bigint known problem. Conclusion, as always: we don't have enough test for core features
Maybe we should add corelibs and corelibstest targets 16:01
chromatic src/pmc/stringbuilder.pmc lines 195 through 197 look wrong. 16:05
16:06 ash_ left
chromatic I know it's misleading, but even so it looks wrong. 16:06
nwellnhof it looks a bit strange, but if we do it this way we don't have to reallocate the buffer twice. 16:10
Coke nwellnhof: /might/ being the operative word there. why bother taking the user's guess if we're ignoring it. ;) 16:12
nwellnhof Coke: if you care about the memory, it would be better to decrease INITIAL_STRING_CAPACITY. 16:13
Coke nwellnhof: nevermind. 16:14
16:14 patspam1 joined
Coke I'll just fix it myself. 16:14
chromatic buffer->strlen = Parrot_str_length(interp, new_buffer);
Seems like that might help.
16:15 patspam left 16:21 theory left
dukeleto msg Coke yes, i added #phasers in UTC 16:22
purl Message for coke stored.
aloha OK. I'll deliver the message.
NotFound r48830 build and pass test with --optimize and --prefix 16:32
nopaste "chromatic" at 192.168.1.3 pasted "AMD64: update StringBuffer's strlen" (23 lines) at nopaste.snit.ch/23272 16:33
dukeleto 'ello
whiteknight hello duke 16:40
16:51 mikehh_ joined
dukeleto whiteknight: how goes it in your neck of the woods? 16:53
whiteknight dukeleto: quite well. Have a small window now where the kid isn't sick and isn't teething, so I'm trying to write as much software as I possibly can 16:54
16:54 mikehh left
whiteknight dukeleto: you? 16:54
purl i guess you is a test factoid
luben_work_ chromatic, no difference with the pasted patch here
Coke . 16:57
any reason we can't switch over to aloha fully now?
\\/win 11
17:00 tcurtis joined
cotto_work ~~ 17:02
17:07 luben_work_ left 17:13 rblackwe joined
dukeleto whiteknight: trying to figure out what to spend time on. I am interested by too many things. 17:17
shockwave @dukeleto: Threads.
purl rumour has it threads is ithreads, Thread is 5.005 threads (older)
shockwave Does anyone know how far Chandon has gotten with that? 17:19
And, is any of it on trunk? 17:20
cotto_work It's not in trunk. My understanding is that green threads work but that we need to make some design decisions before real threads can work. 17:21
Coke that is a faq, I think.
NotFound if (fmt->encoding != Parrot_utf8_encoding_ptr && fmt->encoding != Parrot_asc 17:22
fmt = Parrot_utf8_encoding_ptr->to_encoding(INTERP, fmt);
Adding this in codestring fixes the build for me.
Uh... no... sometimes build, sometimes no. 17:23
17:23 ruoso left
shockwave cotto_work: Do you happen to know if the green threads are in trunk? 17:24
cotto_work Chandon's aren't.
shockwave cotto_work: ok, thanks. 17:25
dukeleto cotto_work: what are you working on today? 17:27
cotto_work I'll probably look at what it'll take to update mk_manifest_and_skip, work permitting (which is likely) 17:28
I hope you say my branch on github 17:29
dukeleto cotto_work: i saw it, but haven't looked at it closely, yet 17:30
cotto_work: gonna take a look now 17:32
cotto_work mk_manifest_and_skip isn't going to be quite as easy as I'd hoped 17:33
chromatic NotFound, that encoding switch does look suspicious. 17:40
17:41 theory joined
NotFound chromatic: I suspect that the problem is that the encoding of concatenations or joins has changed 17:43
Can't someone get rid of remaining CodeString usages? 17:44
dukeleto NotFound: it isn't used widely, but PGE and nqp-rx use it 18:04
NotFound And data_json
purl data_json is the newer stuff, i think JSON is being deprecated
NotFound Jey components are using a deprecated thing.
s/Jey/Key 18:05
dukeleto cotto_work: in your git_aware_tools branch, mk_native_pbc will need something like "git add" before a commit 18:07
cotto_work So it will. Can you fix that? 18:09
dukeleto cotto_work: do we know exactly what the filenames will be, or are they dynamic? 18:10
cotto_work: i am pretty sure they are dynamic
cotto_work There's a fixed number of files that'll be changed.
dukeleto cotto_work: yes, but the filenames change depending on what platform you run mk_native_pbc on, right? 18:11
dalek rrot: r48858 | nwellnhof++ | trunk/src/string/api.c:
[str] Don't convert to UTF-16 in str_replace
dukeleto cotto_work: we could just always add all possible files, and only the files that have actually changed will be effected
cotto_work sure
dukeleto cotto_work: t/native_pbc/*_*.pbc 18:12
cotto_work: will fix. you want me to commit to your branch?
cotto_work please do
I only put my name there because it seems to be a convention. 18:13
dukeleto cotto_work: yep, i just always ask before commiting to other peeps branches :) Common courtesy, in the age of DVCS's
cotto_work *.pbc might be a better idea. There are some files without underscores in their names. 18:14
e.g. number.pbc
dukeleto cotto_work: the comments in mk_native_pbc specify *_*.pbc. hmmm 18:15
18:15 darbelo joined
dukeleto cotto_work: also, mk_native_pbc does a svn commit, which actually pushes the changes to the server 18:15
cotto_work git ls-tree looks like a good starting point for mk_manifest...
dukeleto cotto_work: i think the new mk_native_pbc should only do a git commit, and then the person running should have to do the git push manually. Seems safer 18:16
cotto_work +1
purl 1
dukeleto cotto_work: we will probably need to update the release guide about that
darbelo dukeleto: Really? I thought it just suggested the user do so.
dukeleto darbelo: you are correct. it echo's the commands
darbelo Having scripts ato commit strikes me as a dangerous thing to do, specially with svn. 18:17
*auto
cotto_work We like to live on the wild side. 18:18
Sometimes I put a forkbomb into the test suite, just because.
dukeleto keeps life interesting. 18:19
dalek p-rx: c83336f | pmichaud++ | src/cheats/hll-grammar.pir:
Add :sub<...> precedence for operator precedence parser (<EXPR>).
 18:20
dukeleto cotto_work: i fixed mk_native_pbc and pushed. enjoy.
cotto_work I'd plan subversion roulette, but that's basically the same as trying to merge a branch.
dukeleto cotto_work: jhelwig may be of some help porting mk_manifest_* to git 18:21
cotto_work: he was the one trying to get it to work with git-svn
cotto_work: i will attempt to recruit him, since I will probably see him at PDX.pm tonight 18:22
jhelwig dukeleto: I won't be at PDX.pm tonight, but I'll be at the hackathon tomorrow.
dukeleto jhelwig: ok. you can still help us, though :)
jhelwig Yeah.
dukeleto jhelwig: cotto_work and I are porting various parrot tools to git from svn
jhelwig Excellent. 18:23
dukeleto jhelwig: your old friend mk_manifest_and_skip.pl could use some work ...
jhelwig: github.com/parrot/parrot <-- feel free to fork 18:24
jhelwig: i am also hacking on git docs at github.com/parrot/parrot/tree/leto/git_docs 18:25
purl okay, dukeleto.
jhelwig You going to be at the hackathon tomorrow?
dukeleto jhelwig: probably
pmichaud I can likely get nqp to stop using CodeString.
jhelwig Remind me then.
pmichaud I'll work on that now.
dukeleto pmichaud++ # we are trying to put CodeString out to pasture 18:28
jhelwig: ok, i will remind myself to remind you ;)
18:31 whiteknight left
dukeleto is so delighted that all the perl6 repos are on github now. Makes me really want to work hard to get parrot moved to github 18:31
cotto_work Ideally, I'd like us to make the switch yesterday. 18:32
18:34 ruoso joined
ttbot Parrot trunk/ r48858 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/387244.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 18:37
18:44 hercynium joined 18:52 theory left 18:58 davidfetter joined
chromatic Wow, a 1.8% performance improvement. 19:01
dalek rrot: r48859 | chromatic++ | trunk/compilers/imcc (2 files):
[IMCC] Removed vestigial JIT flag from IMCC.
rrot: r48860 | chromatic++ | trunk/src/parrot_debugger.c:
[src] Fixed typos and tidied documentation.
rrot: r48861 | chromatic++ | trunk/src/namespace.c:
[ns] Optimized NameSpace type check.
rrot: r48862 | NotFound++ | trunk/ChangeLog:
change in ChangeLog the comment about Id getting mangled when it's commited that gets mangled when it's commited
purl dalek: that doesn't look right
NotFound my ($svnid) = 19:03
'$Id: gen_charset_tables.pl 48833 2010-09-07 22:58:38Z nwellnhof $' =~
This is intentional?
tools/dev/gen_charset_tables.pl
19:05 theory joined
cotto_work probably not 19:05
19:07 Patterner joined 19:08 contingencyplan joined 19:10 fperrad left
dalek TT #1252 closed by darbelo++: src/dynpmc/gdbmhash.pmc: Handle case where libgdbm.so cannot be loaded on ... 19:12
TT #1252: trac.parrot.org/parrot/ticket/1252
rrot: r48863 | chromatic++ | trunk/src/hash.c:
[hash] Optimized parrot_hash_mark().

effects for any GC-heavy code.		 19:19
kudo: 780732f | moritz++ | src/core/IO.pm:
make dir() default to the current directory
 19:22
dukeleto NotFound: do you want me to apply your pull request to blizkost? I was going to test it, but I am seeing nt/exit.t fail in master 19:29
NotFound dukeleto: ofcoz!
chromatic said is good, so it is ;) 19:30
sorear dukeleto: well run the other tests 19:31
nt/exit.t would be a TODO if I knew how to TODO segfaults
one failing test isn't an excuse to skip the entire testsuite 19:32
dukeleto sorear: i ran the tests that run with "make tesT" 19:33
"make test" rather
NotFound: applied 19:34
sorear: so nt/exit.t is supposed to be TODOed ? 19:35
sorear: i see a segfault in parrot-nqp from the test, but my build is optimized so I don't have a useful backtrace
dalek rrot: r48864 | pmichaud++ | trunk (2 files):
[pct]: Migrate 'lineof' method (from deprecated CodeString PMC) into PCT::HLLCompiler.
rrot: r48865 | pmichaud++ | trunk/compilers/pct/src (2 files):
[pct]: Switch PAST::Compiler and POST::Compiler to use lineof method from PCT::HLLCompiler.
rrot: r48866 | pmichaud++ | trunk (3 files):
[pct]: Refactor cache parameter of .lineof method to be named param.
dukeleto looks like CodeString is hanging on by a .... string.
cotto_work It's on the ropes. 19:37
Why's it being deprecated? The ticket isn't especially clear on that point. 19:38
dalek izkost: 7f0ac55 | Julian++ | src/pmc/bkmarshal.c:
fix order of args in trampoline
cotto_work Coke: ping 19:39
pmichaud its capabilities have been subsumed by other PMCs 19:40
cotto_work Coke: unping 19:41
dukeleto rm's leto/parrot.git on github, 'cause people seem to be getting confused
NotFound dukeleto: installed from plumage, also fails the nt/exit.t test here
pmichaud the stringbuilding/formatting is now handled by StringBuilder 19:43
sorear dukeleto: I understand nt/exit.t; it's simply a matter of global destruction being broken
pmichaud and the line-counting capability is moving to PCT/HLLCompiler
sorear dukeleto: fixing it, correctly, it not trivial
pmichaud this is being done because CodeString doesn't play well with immutable strings 19:44
dukeleto NotFound: ok, you want to open an issue? do you have a useful backtrace?
sorear of course it fails nt/exit.t. When I added that test, it fails everywhere with the same backtrace 19:45
pmichaud okay, I'm stuck.
dukeleto cotto_work: this looks really useful to generate various reports about our git repo: github.com/visionmedia/git-extras
pmichaud I can't update nqp-rx to use the new 'lineof' method because it depends on r48866. 19:46
dalek TT #1776 created by moritz++: r48847 breaks Rakudo
TT #1776: trac.parrot.org/parrot/ticket/1776
dukeleto sorear: you say "of course" but these things you talk about, very few other people understand. if you would explain the situation a bit more, that would really be helpful
NotFound dukeleto: nt/exit.t .................. Can't undef active subroutine during global destruction.
pmichaud and I can't use r48866 because it won't build and run on 64-bit machines.
(when checked out via svn, which nqp-rx does)
sorear dukeleto: Parrot has no concept of ordering in global destruction 19:48
dukeleto: blizkost SV proxies need to drop Perl-side references when destroyed
dukeleto: that means 1. blizkost needs to still be loaded 2. the Perl interpreter needs to still exist
NotFound dukeleto: I suppose the problem is that it tries to destroy the sub that is calling exit.
dukeleto sorear: how do we get ordered global destruction in parrot? 19:51
sorear we can't. 19:52
cotto_work Note that it's currently on the roadmap for 3.6
sorear somebody with political clout needs to invent a way and force it in
cotto_work My impression was that it's a technical issue. 19:53
pmichaud I suspect it involves more technical clout than political clout.
cotto_work Barring side-effects, it'll be a welcome feature.
chromatic It's 100% technical. 19:56
dukeleto is there any TT currently to track ordered global destruction in parrot? sounds like we need one. 19:57
cotto_work trac.parrot.org/parrot/ticket/607 19:58
not much there atm
luben good evening
purl Ah, evening. The tumultuous mind tarries and contemplates, reveling in the silence afforded by the diurnal proletariat. Good evening, indeed.
cotto_work Hi luben. 19:59
TimToady phone
cotto_work Have you ever had the urge to implement ordered destruction? 20:00
dukeleto cotto_work: i have various urges that involve destruction. order is usually not involved. 20:03
dukeleto ponders that it would be nice to have a test that fails without global destruction, but can imagine that it is hard to test. But not impossible. 20:06
dalek rrot: r48867 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp] Update bootstrap to eliminate use of CodeString PMC.
 20:10
dukeleto updates TT607 with more info
dukeleto ponders that nt/exit.t already shows that global destruction doesn't work, calls it good enough 20:11
20:11 theory left
dalek p-rx: ce60da8 | pmichaud++ | src/cheats/hll-compiler.pir:
Temporarily backport PCT::HLLCompiler's 'lineof' method

continue to build from an older Parrot until parrot's trunk is working again. When we're able to bump PARROT_REVISION, this code can go away to fall back to Parrot's version of
  'lineof' (DRY).		 20:11
p-rx: bb5d370 | pmichaud++ | src/ (3 files):
Switch 'lineof' method calls to use the version of HLL::Compiler instead of CodeString.
20:11 patspam1 left
dalek p-rx: d2d100f | pmichaud++ | src/Regex/Cursor.pir:
Eliminate CodeString coercion.
 20:11
p-rx: 5c1686c | pmichaud++ | src/stage0/ (4 files):
Update bootstrap to include lineof changes.
20:12 patspam joined
sorear seen darbelo 20:12
purl darbelo was last seen on #parrot 1 hours, 55 minutes and 9 seconds ago, saying: Having scripts ato commit strikes me as a dangerous thing to do, specially with svn.
aloha darbelo was last seen in #parrot 1 hours 54 mins ago saying "*auto".
cotto_work What's hard about ordered destruction? 20:13
chromatic Who sets the order? 20:15
Where do you set it?
What if there's a conflit?
How do you start?
sorear darbelo: ping
dukeleto chromatic: seems like a datastructure needs to keep track of things from the beginning 20:18
cotto_work Is this something another language has solved? 20:19
dukeleto notes in passing that if someone wants a CS paper that is behing a paywall, I can help them out.
cotto_work: yes, other languages with garbage collectors have to solve this problem. Who solves it in the best way? No clue. 20:21
chromatic: what do you mean "conflict" ? Do you mean circular refs? 20:22
20:24 patspam left
chromatic Certain types of PMCs depend on other types. 20:27
For example, any NCI/Sub/Pointer PMC which refers to a symbol loaded from a shared library must be destroyed before the ParrotLibrary which represents that shared library can be destroyed.
That's a static dependency we know. 20:28
There *may* be dynamic dependencies between specific PMCs which imply an order, and we don't know that right now.
20:28 hercynium left
dukeleto chromatic: we might be able to leverage the parrot-instrument runcore to figure out what those dynamic deps are 20:28
chromatic I'm not sure that will help; those dependencies might be specific to a program. 20:29
dukeleto chromatic: i see, they change depending on which codepaths are chosen. 20:30
chromatic Right. 20:31
GeJ Bonjour everyone.
dukeleto chromatic: is there a language that you know of that we should learn from, regarding ordered global destruction ?
chromatic There may be a Smalltalk/Strongtalk paper about it somewhere. 20:32
I'm sure the JVM has considered it.
You get it for free with reference counting, until you have to break cycles.
dukeleto chromatic: it seems like each parrot interp needs to build it's own table of dynamic deps iteratively, as execution happens 20:33
chromatic Only if any such deps exist.
However, we also need a mechanism to track PMCs (or types of PMCs) which *always* need destruction/finalization even if Parrot doesn't perform global destruction on an interp. 20:40
dukeleto Git summary of parrot.git : gist.github.com/570791 # leo++
20:40 davidfetter left
dukeleto Coke: you are catching up to leo++, only about 800 commits to go ;) 20:41
Coke dukeleto: does that count dead branches?
dukeleto Coke: not sure, what do you mean "dead" branch ? 20:42
Coke a branch that was rm'd at HEAD at some point. 20:43
cotto_work or more than I've made since I've been around
Coke (and therefore not in svn ls ^/branches just this second.)
dukeleto Coke: that summary only counts what it is parrot.git 20:44
Coke so, no. hokay.
I suspect that would skew those #'s quite a bit.
still, nifty!
20:45 ash_ joined 20:46 whiteknight joined
darbelo sorear: pong 20:47
dukeleto Coke: the output is from "git summary" from git-extras. it has lots of other cool toys
atrodo dukeleto> Wow, not the break down I was expecting 20:50
20:50 hercynium joined
cotto_work There's a lot of history there. It'd look less surprising if you took it over the last 24 months (or less). 20:52
chromatic Three years. 20:53
purl hmmm... three years is a long time to fail.
Coke 3 years? that includes cvs.
more like 9.
(unless parrot.git doesn't include r1) 20:54
Andy are we all using ack 1.93_01? 20:56
darbelo I have a 1.92 here.
dukeleto parrot.git's first commit is from 2001 20:57
sorear darbelo: you were working on eliminating strstart/bufstart, yes? 20:58
darbelo In a way, yes.
sorear darbelo: and you had it faster for everything except nqp-rx?
dukeleto parrot.git includes CVS and svn commits
cotto_work Andy: is your site down? 20:59
betterthangrep.com
Andy not that I know
darbelo sorear: Yes. NQP uses substr to skip over strings, which mandates shared buffers in order to not become pathologically expensive.
sorear darbelo: ah, you do know 21:00
Andy bah
rebooting
purl i think rebooting is always the first solution
sorear darbelo: I was going to recommend removing src/PAST/Compiler-Regex.pir 137-153 and dealing with ripple effects and rebenchmarking 21:01
darbelo The streq_at branch was an attempt to move nqp away from substr abuse.
But I got sidetracked with school stuff before I could dig in.
21:02 mikehh_ is now known as mikehh
darbelo I'm not sure I'll be able to do too much soon either since it looks like I'll be getting a job soon. 21:02
mikehh opbots, names
darbelo ETOOMANYSOONS.
cotto_work Yay for employed Parrot hackers!
What job?
purl job is that which one does in order to live or something to make you batshit insane
cotto_work forget job' 21:03
purl cotto_work, I didn't have anything matching job'
cotto_work forget job
purl cotto_work: I forgot job
darbelo iPhone stuff, of all things.
Well, and iPad stuff as well I guess.
dukeleto darbelo: developing with cocoa or something else? 21:04
cotto_work So you get to wait in anticipation while Apple decides to approve your fate?
darbelo cotto_work: Yep.
dukeleto: iOS development is done with whatever Apple decide you develop with.
Upside is, I'll be getting a mac to test parrot on :) 21:05
cotto_work joeberkovitz.com/blog/2010/04/08/ap...ciousness/
21:05 davidfetter joined
dalek TT #1777 created by doughera++: Optimized builds on gcc/amd64 broken since r48308 21:11
TT #1777: trac.parrot.org/parrot/ticket/1777
darbelo dukeleto: Oh, if you are looking for ordered detruction testcases TT #956 contains one.
Andy What would it take to get the purl source and make a new one? 21:13
darbelo We kind of have a 'new one'.
aloha: say hi!
aloha: aloha? 21:14
purl aloha is, like, nothing but a humid enema-bucketful of malodorous dog balls
aloha darbelo: I have no idea.
chromatic r48308 was a complex commit. 21:15
dukeleto darbelo: you are familiar with Cydia, right?
Coke ETOOMANYSOONGS
chromatic Wordsize problem?
dukeleto darbelo: you should take a look at PhoneGap too, if you haven't heard of it. It allows writing cross-platform apps in JS 21:16
dalek rrot: r48868 | nwellnhof++ | trunk/src (2 files):
[src] Unbreak Windows build
 21:17
darbelo dukeleto: Yeah, I'm vaguely familiar with that. Still not a solution :) 21:21
21:27 Coke left
dalek TT #306 closed by nwellnhof++: embedding parrot fails, many symbols not exported properly [win32] 21:28
TT #306: trac.parrot.org/parrot/ticket/306
cotto_work insult botsnack 21:32
purl thanks cotto_work :)
aloha botsnack is nothing but an antique gob of milk-livered cat bladders.
purl :)
darbelo insult purl 21:34
aloha purl is nothing but a toad-spotted thimbleful of horn-beat pond scum.
darbelo aloha++ 21:35
aloha darbelo: Thanks!
dukeleto parrot.git summary since RELEASE_1_0_0 : gist.github.com/570881
dukeleto gives NotFound++ a cookie
NotFound dukeleto: Thanks! 21:37
21:39 Coke joined
NotFound But I think that if you count the size of the commits the order may change a lot. 21:39
21:40 tcurtis left, theory joined
NotFound whiteknight: you can test HLL maps quickly with winxed, it has a feature for it since a a few weeks ago. 21:41
sorear I wonder if he reads his blog comments. 21:42
NotFound One time I signaled a typo in a comment and he answered quickly. 21:43
darbelo dukeleto: Looks like you need to make that summary case-insensitive. see Whiteknight vs whiteknight and infinoid vs Infinoid in your gist. 21:46
21:46 chromatic left
jnthn ooc, does Parrot have any abstraction layer in place for operations like atomic compare and swap? 21:47
I guess it's not so important until there's real threads. 21:48
whiteknight Whiteknight vs whiteknight? I would pay to see that fight
jnthn Though I expect once there is, they'll be what Rakudo's meta-model-y guts will want.
NotFound whiteknight: if you want to give a try: namespace Foo [HLL] { .... 21:51
21:52 ruoso left
whiteknight I think I may actually hate Parrot's Test::More implementation 21:55
cotto_work If you understand it, you're ahead of the curve. 21:56
whiteknight I don't really understand it, and every time I try I'm surprised by new things that make me angry
and today I think I finally passed the threshold of abject hatred
21:58 ash_ left
whiteknight I use the setstdout opcode to change the default output handle to a StringHandle. Test::Builder::Output helpfully ignores this and outputs to STDOUT anyway 21:59
probably exposes a bug that the ParrotInterpreter.stdhandle() method doesn't play nicely with that dynop library 22:00
ttbot Parrot trunk/ r48867 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/387514.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 22:03
dukeleto darbelo: you are write. it is basically just the output of git-shortlog. it needs to be munged, still 22:04
dukeleto ponders using levenshtein distances to detect similar commit names
whiteknight: i can try to help fix parrot's Test::More, if that helps at all
darbelo: also, I do know the difference between write and right. Just that my fingers don't. 22:05
whiteknight dukeleto: the biggest frustration is taking almost an hour out of my day to figure out what the problem was
now that we're past that, the damage is done 22:06
dukeleto whiteknight: i feel your pain. sometimes i feel like some yak holes go all the way to China
whiteknight: maybe we should fix Test::Builder::Output 22:07
cotto_work If you squint, this entire migration to git is one giant exercise in yak shaving.
dukeleto whiteknight: that sounds like a bug
cotto_work: I don't have to squint :)
whiteknight dukeleto: I don't think it's Test::Builder::Output so much. I need to boil down a failing test case first
dukeleto cotto_work: i've migrated svn to git a few times, and parrot's is definitely the most involved, because we were so tightly coupled to svn
cotto_work: not that we won't be tightly coupled to git. we just have a lot of dev scripts and docs 22:08
cotto_work btw, what's the purpose of MANIFEST, apart from passing the manifest tests?
dukeleto cotto_work: to make our lives hell
dalek rrot-linear-algebra: 9286277 | Whiteknight++ | t/pir-subclass/nummatrix2d.t:
add a stub test for verifying subclass behavior. Test fails because of weirdness elsewhere in the dependency tree.
dukeleto cotto_work: i have had lengthly conversations with jhelwig about why MANIFEST exists 22:09
cotto_work Is there a reason?
dalek tracwiki: v4 | nwellnhof++ | Platforms/Windows
tracwiki: trac.parrot.org/parrot/wiki/Platfor...ction=diff
dukeleto MANIFEST has a reason. But building it manually is *insanity* 22:10
whiteknight cotto_work: just to make me angry, I assume
jhelwig cotto_work: From my fuzzy memories, it's to help people who forget to $vcs rm/add things when they remove old files, or add new files.
dukeleto all CPAN modules have a MANIFEST and parrot used to be distributed on CPAN, as well 22:11
22:12 Limbic_Region joined
cotto_work If that's all, let's drop it. Adding/removing files doesn't happen that often and we have enough testers to complain when someone forgets. 22:12
dukeleto cotto_work: I am not sure if some of the ports/* stuff needs it. I don't think so, but I am not sure. 22:13
jhelwig IMO, if you're not distributing via CPAN, it's probably got a _very_ high cost/benefit ratio.
dukeleto cotto_work: you want to email parrot-dev about it? see if anyone has a "OMG you will feel pain if you do that" comment 22:14
cotto_work doing so now 22:15
22:17 ash_ joined
Coke MANIFEST is theoretically used to insure you got a good tarball. 22:18
cotto_work checksums are nice for that too 22:19
dalek TT #1778 created by nwellnhof++: Charset opcodes are deprecated
TT #1778: trac.parrot.org/parrot/ticket/1778
Coke yes, but how do you check that from inside the tarball?
(that is, with "perl Configure.pl && make test")
cotto_work you assume that the release manager followed procedure and tested the tarball before taking its checksum 22:20
Coke I don't follow. you assume the tarball made it to you unharmed? 22:21
cotto_work You can verify that by taking its sha1sum
Coke yes, but what do you COMPARE it against?
cotto_work the checksum mentioned in the release announcement 22:22
Coke the sha1sum the maintainer took. which isn't IN the tarball.
right. you then have to have 2 bits. Which is fine, and dandy, but something else.
jhelwig Coke: Just because you have all of the files mentioned in the MANIFEST, how do you know they aren't corrupted?
Coke jhelwig: you don't. =-)
jhelwig Which is why the SHA1 of the tarball is much more useful. 22:23
Coke I'm not saying it's good, I'm merely trying to construct an argument for why we might still need it.
*why one might argue... (not me.)
dalek rrot: r48869 | luben++ | branches/hash_inlined_func/src/hash.c:
fix ambigous code in hash key comparison
 22:24
22:25 ash_ left
Coke so if you can kill MANIFEST, then you don't need MANIFEST.SKIP, but only MANIFEST.GENERATED 22:25
rrot: r48870 | luben++ | branches/hash_inlined_func (30 files):
Bring up to date with master
rrot: r48871 | luben++ | branches/hash_inlined_func/src/hash.c:
resolve confilict in parrot_mark_hash functions
rrot: r48872 | nwellnhof++ | trunk/DEPRECATED.pod:
Add deprecation notice for charset opcodes
cotto_work seen kid51 22:29
purl kid51 was last seen on #parrot 20 hours, 37 minutes and 46 seconds ago, saying: paste 23258 is on Linux/i386 at r48846
aloha kid51 was last seen in #parrot 20 hours 37 mins ago saying "paste 23258 is on Linux/i386 at r48846".
cotto_work sent 22:31
dukeleto aloha, msg tcurtis can your gsoc_past_optimization branch be deleted? did your code leave the nest, or are you still working on that branch? 22:39
aloha dukeleto: OK. I'll deliver the message.
cotto_work His code definitely left the nest. 22:40
It's on github now.
sorear Is Parrot still being pushed to CPAN?
because if so, we need MANIFEST
cotto_work istr something about him wanting to get it back into core though
sorear the (non-Parrot-specific) CPAN toolchain expects to find that file with its current contents
cotto_work sorear: nope 22:41
dukeleto sorear: no, it isn't being pushed to CPAN
cotto_work: yes, i thought it left the nest
moritz cpan has parrot-0.0.8.1 22:42
cotto_work It shouldn't. We made an effort a while ago to get all releases off cpan.
dukeleto moritz: that must be why people think we never release code ;)
moritz: yes, allison tried to delete a bunch of old Parrot stuff on CPAN, methinks
aloha, msg darbelo it would be nice to get a final blog post out of you about gsoc 22:43
aloha dukeleto: OK. I'll deliver the message.
cotto_work We release code? Who knew.
dalek tracwiki: v10 | nwellnhof++ | ParrotDeprecationsFor2.9 22:44
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v13 | nwellnhof++ | ParrotDeprecations
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
dukeleto aloha, msg darbelo what is the status of gsoc_nfg ? does it require deprecations to get merged? 22:45
aloha dukeleto: OK. I'll deliver the message.
dukeleto: Okay.
dukeleto alohabug 22:46
bacek: ^^^
darbelo rematerializes 22:48
dukeleto: gsoc_nfg is basically done, functionality-wise. But the implementation path I took adds a (very rarely used) pointer to the string header, which is questionable at best. 22:51
dukeleto darbelo: so you are saying that we need to benchmark that change? 22:52
darbelo Not really, I already know it's one pointer more expensive *per string header* even if you don't use NFG. 22:53
dukeleto darbelo: so memory use is the issue
darbelo That and possibly unnnecessary allocations. Also, NFG strings are effectively COW-less. 22:54
I wanted to do away with the overhead by doing some refactoring on strings, mainly disabling shared buffers. That's the unshared_buffers branch. 22:55
sorear NQP needs some changes to make that work though
darbelo Yeah. That degenerated into gc-tuning and compact_pool tweaking, until I noticed that NQP-generated parsers were going pathological. 22:56
I managed to make a sizable dent on rakudo's build memory usage, but runtime went out the window when I tried it. 22:57
Both, pmichaud and chromatic had ideas about what we could do to improve that, and that went into the streq_at branch. But I ran out of tuits before I could jump in. 22:58
sorear darbelo: what if I were to give you a NQP branch that doesn't go O(N^2) with unshared buffers?
darbelo I think that was pmichaud's side of the streq_at stuff. Though I am not sure if it payed off. 22:59
sorear streq_at is something completely different 23:00
it didn't pay off because you missed 2/3 of the problem
streq_at is only a constant factor improvement 23:01
darbelo Definitely possible. I am not familiar enough with NQP to say for sure.
I know streq_at is part of the solution, since it avoids a string header (and a buffer, and a copy, without shared buffers). 23:03
23:04 Andy left
darbelo But it could be dwarfed by other unfavorably placed substr calls. 23:04
dukeleto did ash's gsoc work get merged? i don't see a branch for it.
darbelo I think ash worked on a git clone, not an svn branch. 23:05
dukeleto aloha, msg plobsing did ash's gsoc work get merged? i am working on a gsoc blog post, just want to summarize what was accomplished
aloha dukeleto: OK. I'll deliver the message.
dukeleto darbelo: happen to know if that was on github or gitorious or somewhere else? 23:06
darbelo github, I think. 23:07
github.com/ashgti/parrot seems to be it. 23:08
dukeleto darbelo: thanks!
it is hard to tell what was accomplished in ashgt's parrot repo. does anybody know anything about it? 23:10
darbelo I'd guess his mentor would :) 23:13
But I think his gsoc ended up being a two-parter. Part one was a framebuilder and part two was some sort of llvm-uber-experiment. 23:14
dukeleto darbelo: it would be nice if the frame-builder could be committed 23:19
dukeleto can't believe that livejournal does a flash add popup over page content. Livejournal no longer can be used as blog for GSoC 23:20
cotto_work orly? I never saw such a monstrosity on jwz's blog, which is the only lj blog I read. 23:22
maybe it's one of the times when noscript silently saves me a bit of annoyance 23:24
23:26 Paul_the_Greek joined
Paul_the_Greek G'day folks. 23:27
cotto_work hio Paul_the_Greek
Paul_the_Greek Just about to commit the exciting sprintf exponent digit change.
Is there a way to run the coding standards tests on one file? 23:28
cotto_work You can run one test, but not on one file 23:30
afaik
Paul_the_Greek I just ran codetest. It still complains if there is no documentation for static functions.
cotto_work I usually run codingstds while I do a final pre-commit review of the patch. 23:31
Paul_the_Greek I wonder if there is a ticket for that?
We did agree that static functions don't want pod documentation, I think.
23:32 ash_ joined 23:33 chromatic joined 23:39 Limbic_Region left, ascent left
dukeleto cotto_work: i have noscript, but i still see the failed flash thingie, and it dimms the whole page. jwz probably has a paid account, or knows somebody :) 23:40
23:40 ascent joined
dukeleto works on a gsoc blog post. Very proud of all my parrot students! 23:40
mikehh Paul_the_Greek: yeah we did, but someone needs to change the tests and until we do I think we need to include the documentation, so that at least we are sure it is there
Paul_the_Greek Okay, I'll add some for my new function. 23:41
mikehh Paul_the_Greek: and I still think most users of the docs are developers, not users so it does no harm
Paul_the_Greek: we could even include a local pod header 23:44
Paul_the_Greek Local pod header?
cotto_work It's a thing you copy/paste from a file that has one so that perldoc your/file.c looks nicer 23:45
mikehh well a pods header around the static function =items, just for the static functions
like =head2 Static Functions followed by =over 4, =cut then the -items - something like that if you want 23:48
Paul_the_Greek Right. 23:49
dalek rrot: r48873 | Paul C. Anagnostopoulos++ | trunk (2 files):
sprintf() trims exponents to 2 digits if possible
23:49 theory left
shockwave I'm getting an op-not-found error, on a line like so: if_null $P50000000 goto LABEL_2 23:51
:The opcode 'if_null_p' (if_null<1>) was not found.
This is the first time I've used this opcode, so I'm not sure of its syntax. 23:52
I'm assuming is just like the other if opcode.
Any ideas?
Paul_the_Greek No 'goto'. 23:53
It's if_null reg, label
cotto_work I think the goto is desugared away.
Paul_the_Greek Though why would that give you op-not-found?
cotto_work I guess not then. 23:54
shockwave It was the goto. Thanks.
Paul_the_Greek Well, then that's inconsistent.
'goto' should be allowed. 23:55
cotto_work: When I merge my sleeker_boolean branch, will it just silently ignore the fact that a bunch of files are out of date? 23:56
dukeleto Paul_the_Greek: are you asking about svn? 23:57
Paul_the_Greek Yes.
dukeleto Paul_the_Greek: when you try to merge, it will tell you that you are out of date and tell you do svn up
Paul_the_Greek: or maybe it does it without asking. /me tries to forget about svn
Paul_the_Greek I tried that just to see what happens. It just says "At revision xxx," since I match my files in that branch. 23:58
23:58 chromatic left, theory joined
Paul_the_Greek I'll see what happens when I actually try to merge. Never done that. Frightening. 23:58
dukeleto Paul_the_Greek: :) Don't worry, if you set fire to the svn repo, we can just make the conversion to git sooner ;) 23:59
cotto_work not for long
Paul_the_Greek Happy to help!

Powered by Cro and the Raku® Programming Language.

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

Thank you!