Camelia, the Perl 6 bug

IRC log for #parrot, 2010-09-09

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 dukeleto Paul_the_Greek: awesome, will keep that in mind
00:00 Paul_the_Greek Burn, baby, burn.
00:00 Psyche^ joined #parrot
00:00 dalek TT #1200 closed by Paul_the_Greek++: sprintf formatting for exponents needs to be standardized
00:00 dalek TT #1200: http://trac.parrot.org/parrot/ticket/1200
00:01 Patterner left #parrot
00:01 Psyche^ is now known as Patterner
00:06 Paul_the_Greek If I add a benchmark, do I need to register it in any file?
00:07 theory left #parrot
00:11 Paul_the_Greek left #parrot
00:18 Coke
00:18 Coke cd sandbox
00:18 Coke ww
00:18 cotto_work error: sandbox not found
00:19 cotto_work I was sure you'd left it somewhere around here.
00:25 plobsing joined #parrot
00:26 dukeleto aloha, msg Paul_the_Greek when you add a file, you need to run perl tools/dev/mk_manifest_and_skip.pl, which will update the MANIFEST with your new file
00:26 aloha dukeleto: OK. I'll deliver the message.
00:26 dukeleto for now, anyway.
00:26 cotto_work I'm starting a branch to rip it out when I get home.  If it ends up being useful, I can always not merge.
00:28 davidfetter left #parrot
00:28 dukeleto cotto_work: best of luck. let me know how it goes
00:30 cognominal left #parrot
00:35 darbelo Hm, I think MANIFEST is used by our install scripts to determine what they should install.
00:35 ascent left #parrot
00:35 ascent joined #parrot
00:35 darbelo Although it might be less relevant now that we don't care about install vs install-dev.
00:37 kid51 joined #parrot
00:42 dukeleto kid51: how goes it?
00:45 cognominal joined #parrot
00:48 dukeleto Finaly Summary of GSoC 2010: http://leto.net/dukeleto.pl/2010/09/googl​e-summer-of-code-2010-final-summary.html
00:52 kid51 dukeleto hello
00:53 dukeleto kid51: howdy
00:56 dalek parrot: r48874 | coke++ | trunk/t/op/calling.t:
00:56 dalek parrot: avoid use of deprecated method to test this feature
00:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48874/
00:58 Coke I'm getting failures in 'make test'
00:58 Coke (and I'm not on amd64!)
00:59 Coke MANIFEST.generated is used for the installs.
00:59 cotto ~~
00:59 Coke (no?)
01:00 dalek parrot-linear-algebra: 297a02f | Whiteknight++ | t/pir-subclass/nummatrix2d.t:
01:00 dalek parrot-linear-algebra: add a stub test file for testing subclasses in NumMatrix2D. Can't use Test::More here for some reason, so brewing my own
01:00 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/297a02fc0348952c83ded394fb53982ad4c6b9df
01:00 dalek parrot-linear-algebra: 2c8ae58 | Whiteknight++ | t/pir-subclass/nummatrix2d.t:
01:00 dalek parrot-linear-algebra: flesh out the nummatrix2d subclass tests. This appears to cover all VTABLEs that use mapped types
01:00 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/2c8ae5835a480b291dbec59a250763dcf74faad4
01:00 Coke I forgot about the use of MANIFEST for /making/ the tarball.
01:00 dalek parrot-linear-algebra: ac8772b | Whiteknight++ | /:
01:00 dalek parrot-linear-algebra: teh mergz
01:00 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/ac8772b3f8e1d76ed54fb22d44142a143aac2ed6
01:01 tcurtis joined #parrot
01:03 cotto Looks like allison saved me from an unnecessary branch, for now at least.
01:04 whiteknight how?
01:05 cotto gave a good reason why we keep MANIFEST around
01:05 cotto (et al)
01:06 kid51 is now known as kid51_at_dinner
01:07 dukeleto cotto_work: we need MANIFEST, it is just how we go about generating it and maintaining it
01:12 Coke so much for hacking on parrot tonight. (TT #1779)
01:25 dalek TT #1779 created by coke++: test failures on OSX
01:25 dalek TT #1779: http://trac.parrot.org/parrot/ticket/1779
01:27 nwellnhof left #parrot
01:36 nopaste "Whiteknight" at 192.168.1.3 pasted "Why I hate GDB sometimes" (7 lines) at http://nopaste.snit.ch/23274
01:38 whiteknight seriously. There's a segfault happening, and GDB doesn't stop at all for it
01:59 whiteknight blargle. I'll deal with all of this crap tomorrow. Goodnight
02:00 kid51_at_dinner is now known as kid51
02:01 dalek parrot-linear-algebra: 73ed80c | Whiteknight++ | / (3 files):
02:01 dalek parrot-linear-algebra: Add in a test class for subclassing behavior in ComplexMatrix2D. Also, I made a change to the init_from_pmc_array function, which I thought was necessary but turns out to not be (though I do prefer a solution of this form, for future reference). This is causing some test failures, so I need to debug that later
02:01 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/73ed80cc81b20a21ba6f3b673b3f97a4e70f05d9
02:05 kid51 Oh, how we need our smolder server back!
02:05 dalek rakudo: 859f2d9 | colomon++ | src/core/Iterable.pm:
02:05 dalek rakudo: Add Iterable.Numeric so that Arrays (and other Iterable types) numify to Int rather than to Num.
02:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​59f2d9afe0b60a9f1616803c2c1b8651ba6296e
02:05 kid51 That's the only way we can keep track of which configuration variants result in which build/test failures.
02:09 whiteknight left #parrot
02:14 darbelo left #parrot
02:15 darbelo joined #parrot
02:17 dukeleto hola
02:26 darbelo aloha: msg whiteknight (Re: http://nopaste.snit.ch/23274) Are you sure you are attaching gdb to the same process that is segfaulting? It seems to me you probably are spawning something that dies but attaching gdb to the 'spawner' who exits normally.
02:26 purl Message for whiteknight stored.
02:26 aloha darbelo: OK. I'll deliver the message.
02:28 kid51 msg mikehh src/spf_render.c is failing c_function_docs.t, even after my fix (commit coming up).  I believe you know the magic invocation.  Thanks.
02:28 purl Message for mikehh stored.
02:28 aloha OK. I'll deliver the message.
02:29 kid51 dukeleto++ for GSOC blog post:  http://leto.net/dukeleto.pl/2010/09/googl​e-summer-of-code-2010-final-summary.html
02:29 * dukeleto is listening to chromatic++ talk about modern perl philosophy at PDX.pm
02:29 dukeleto kid51: thanks
02:30 darbelo dukeleto: Audio or it didn't happen :)
02:30 theory joined #parrot
02:32 kid51 FWIW: at r48874 I got PASS for 'make test' on both Linux/i386 (--optimize) and Darwin/PPC.
02:32 kid51 Are these test failures all in the 64-world?
02:33 kid51 (And on Linux/i386 'make fulltest' PASS except for 3 codingstd fails, 2 of which I've fixed)
02:34 dukeleto there is a podcast being made and someone is livestreaming it, i think
02:34 dukeleto live stream: http://ustre.am/p0
02:34 darbelo Nice.
02:35 janus left #parrot
02:35 kid51 merlyn is the streamer
02:36 dalek parrot: r48875 | jkeenan++ | trunk/ext/nqp-rx/src/stage0/HLL-s0.pir:
02:36 dalek parrot: Correct 2 pod formatting errors.
02:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48875/
02:36 dalek parrot: r48876 | jkeenan++ | trunk/src/spf_render.c:
02:36 dalek parrot: [codingstd] Correct c_parens error -- but c_function_docs error remains.
02:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48876/
02:42 Andy joined #parrot
02:47 janus joined #parrot
02:53 dalek parrot: r48877 | mikehh++ | trunk/src/spf_render.c:
02:53 dalek parrot: sort out documentation to pass c_function_docs.t
02:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48877/
02:53 nopaste "kid51" at 192.168.1.3 pasted "hash_inlined_func branch: t/pmc/hash.t continued failures" (182 lines) at http://nopaste.snit.ch/23275
03:01 kid51 left #parrot
03:45 arnsholt left #parrot
03:46 hercynium left #parrot
03:52 arnsholt joined #parrot
04:13 arnsholt left #parrot
04:14 plobsing left #parrot
04:33 arnsholt joined #parrot
04:51 jsut joined #parrot
04:55 jsut_ left #parrot
05:26 Andy left #parrot
06:07 darbelo left #parrot
06:23 uniejo joined #parrot
06:27 esskar left #parrot
06:47 dalek parrot: r48878 | chromatic++ | branches/hash_inlined_func/src/hash.c:
06:47 dalek parrot: [hash] Optimized parrot_hash_mark().
06:47 dalek parrot: This improves Rakudo performance by some 1.4%, and should have similar nice
06:47 dalek parrot: effects for any GC-heavy code.
06:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48878/
06:47 dalek parrot: r48879 | chromatic++ | branches/hash_inlined_func/src/hash.c:
06:47 dalek parrot: [hash] Fixed key annotation for key_hash().
06:47 dalek parrot: Int keys can be NULL, so the specific hashing functions for other key types
06:47 dalek parrot: have to catch undesired NULLness.
06:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48879/
06:50 fperrad joined #parrot
07:10 theory left #parrot
07:10 theory joined #parrot
07:10 theory left #parrot
07:20 dalek parrot: r48880 | chromatic++ | trunk/src/gc/mark_sweep.c:
07:20 dalek parrot: [GC] Sprinkled consts in Parrot_gc_sweep_pool().
07:20 dalek parrot: This lets a good optimizing compiler avoid unnecessary memory fetches in a very
07:20 dalek parrot: hot path.
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48880/
08:23 cotto_work left #parrot
08:24 cotto_work joined #parrot
09:12 ttbot left #parrot
09:22 ttbot joined #parrot
09:44 tcurtis left #parrot
10:14 PerlJam left #parrot
10:14 PerlJam joined #parrot
10:14 Util left #parrot
10:14 Util joined #parrot
10:14 dukeleto left #parrot
10:14 dukeleto joined #parrot
10:23 dukeleto left #parrot
10:23 pmichaud left #parrot
10:23 Util left #parrot
10:24 PerlJam left #parrot
10:24 PerlJam joined #parrot
10:24 dalek left #parrot
10:29 dukeleto joined #parrot
10:29 dalek joined #parrot
10:34 Util joined #parrot
10:39 pmichaud joined #parrot
11:23 luben_work joined #parrot
11:34 GodFather joined #parrot
11:55 contingencyplan left #parrot
11:59 contingencyplan joined #parrot
11:59 smash hello everyone
12:12 whiteknight joined #parrot
12:14 plobsing joined #parrot
12:29 whiteknight good morning, #parrot
12:29 smash whiteknight: mornin'
12:31 whiteknight hello smash, how are you today?
12:33 smash whiteknight: fine thank you, and you ?
12:34 whiteknight fine as well. Could always use more sleep, but can't complain otherwise
12:35 bluescreen joined #parrot
12:38 smash nice, could use some mre sleep as well
12:50 ash_ left #parrot
13:10 ash_ joined #parrot
13:14 fperrad left #parrot
13:17 uniejo left #parrot
13:17 Patterner left #parrot
13:23 uniejo joined #parrot
13:33 dalek parrot: r48881 | mikehh++ | trunk/src/namespace.c:
13:33 dalek parrot: fix g++ build - namespace is a reserved word in C++
13:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48881/
13:33 dalek parrot: r48882 | whiteknight++ | trunk/src/pmc/complex.pmc:
13:33 dalek parrot: Complex pmc now provides 'complex' role, to help ease working with it and various subclasses
13:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48882/
13:43 Psyche^ joined #parrot
13:43 Psyche^ is now known as Patterner
13:50 dalek parrot: r48883 | whiteknight++ | trunk (2 files):
13:50 dalek parrot: add a does scalar to Complex as well, which is needed for some reason. Add tests for the new 'complex' role I added
13:50 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48883/
13:50 uniejo left #parrot
13:58 ash_ so... macruby has a new feature, that's rather nifty IMO, you can now pass a ruby closure to a C library, it under the hood converts the ruby closure into a C block (the C blocks apple added to gcc and clang)
14:00 ash_ macruby is almost to the point where it could be an alternative syntax for obj-c
14:09 ash_ left #parrot
14:09 atrodo Hmmm.  Looks like Apple has relaxed a few restrictions on iOS, and at first glance, it looks like apps can now be written in parrot
14:11 fperrad joined #parrot
14:22 ash_ joined #parrot
14:24 ash_ just have to figure out how to cross compile parrot using XCode...
14:24 ash_ i tried once already, but i was not very familiar with the parrot configuration system, but i am more familiar with it now, it should be possible
14:45 particle left #parrot
14:45 particle joined #parrot
14:50 theory joined #parrot
14:59 shockwave left #parrot
15:07 patspam joined #parrot
15:09 pmichaud good morning, #parrot
15:10 pmichaud (streq_at)  chromatic and I worked up several patches to switch nqp-rx to use streq_at instead of substr, and there was no appreciable improvement in performance
15:10 GodFather left #parrot
15:12 pmichaud thinking about it now, I'm not too surprised.  Doing the substrs does increase the number of string headers created, but they're very quickly collected.
15:12 pmichaud (and reused)
15:17 particle cotto_work, pmichaud, others interested in git migration: see the bottom of  `perldoc Config` for how p5 handles git info
15:17 moritz .oO( in retrospect you're never surprised :-)
15:18 pmichaud moritz: yeah.  I was thinking that avoiding the substrs would relieve pressure on the GC, but the GC seems to suffer more from long-lived items than from short-lived ones.
15:19 pmichaud it still may be worth adding streq_at to our permanent set
15:20 moritz once we have a generational GC, the long lived objects shouldn't matter that much
15:20 pmichaud right
15:20 moritz then avoiding GCables makes sense again
15:20 pmichaud I keep wondering when "once" will be.  :-)
15:20 moritz christmas!
15:20 purl hmmm... christmas is all jolly goofy shit. weee! or o/~ we wish you a spendy christmas o/~ x3; o/~ and a 'spensive new year o/~ or not yet or next year or when Perl6 is released.
15:20 mikegrb left #parrot
15:22 mikegrb joined #parrot
15:22 pmichaud 21:01 <sorear> darbelo: I was going to recommend removing src/PAST/Compiler-Regex.pir 137-153 and dealing with ripple effects and rebenchmarking
15:23 pmichaud I think that only becomes helpful when we can have a fixed-width encoding for unicode strings.  Otherwise the cost of indexing into variable width strings overloads everything else.
15:23 NotFound pmichaud: On the positive side, that means we can stop using shared buffers for substr if we need/want, without penalizing nqp.
15:24 pmichaud NotFound: as long as NQP also gets rid of its other needs for substr, yes.
15:24 pmichaud based on past experience, the cost of indexing into variable width encodings is a significant cost.
15:24 pmichaud especially as source code gets longer.
15:24 fperrad_ joined #parrot
15:25 pmichaud we ran into this problem a couple of years ago with PGE, where Perl 6 source files containing unicode characters ended up taking forever to parse because every comparison operation required an index (that always had to be counted from the beginning of the string)
15:27 pmichaud I fully plan to take out the substring operation from NQP when we have efficient unicode strings.  :)
15:28 pmichaud however, parrot's opcode set is going to require that we still do the equivalent of   $S0 = $P0.  I don't know if that will still be able to share a buffer.
15:28 fperrad left #parrot
15:28 fperrad_ is now known as fperrad
15:28 NotFound I think we have efficient unicode strings... as long as they are utf32
15:28 pmichaud I think utf32 doesn't work on systems that don't have ICU present.
15:29 NotFound You were not requiring icu for rakudo?
15:29 pmichaud ICU is required if you want to do unicode-specific operations, but not for basic running of Rakudo.
15:29 NotFound Oh, nqp, sorry.
15:29 pmichaud or nqp, for that matter.
15:33 NotFound It will be relatively easy to add uff decoding and encondig operations without external libs. If that is useful enough for nqp and others, we can give it a try.
15:33 NotFound s/uff/utf
15:34 pmichaud I think that anytime we can avoid variable width encoding internally that's likely to be a nice win.
15:34 pmichaud oh, there's another possibility
15:34 pmichaud (not a great one, but it exists)
15:35 NotFound In fact, we already have utf operations, for iterator advance et al.
15:35 pmichaud nqp-rx could switch to using a ResizableIntegerArray (or other packed equivalent) and reformulate its operations in terms of those.
15:36 pmichaud We'd still end up switching things back into strings to be able to do case conversions and property checks, though.
15:36 pmichaud (or we'd have to develop opcodes that know how to do those kinds of things for RIA instead of strings)
15:37 pmichaud I'm guessing that would also have its own set of inefficiencies, but it could be done.
15:37 NotFound Do you think a method or something to create a integer array from the codepoints of a string, and viceversa, will be helpful?
15:38 pmichaud maybe, but that's probably the easiest part of that switch
15:38 NotFound Is the easier to test, at least.
15:38 pmichaud doing a literal comparison between two integer arrays doesn't strike me as being nearly as efficient as saying   iseq $S0, $S1
15:40 NotFound Thinking about it, is at less the same as work as recoding to utf32 and less useful.
15:40 pmichaud anyway, (fixed-width unicode representation)++
15:42 NotFound Technically utf32 is not fixed widh, but there are no plans to add several hundres of thousands of characters in the near future.
15:42 NotFound So we can take it as fixed width safely,
15:42 pmichaud as long as I can get directly to offset $n without having to scan from the start of the string :-)
15:43 pmichaud s/I/Parrot/
15:50 NotFound Reamining CodeString usages, checked with ack, are in compilers/tge compilers/pge and compilers/data_json
15:51 NotFound If someone get rid of that, I bet that debugging the amd64 problems will be easier.
16:00 pmichaud does anything use those?
16:00 pmichaud I mean, does anything use tge/pge/data_json
16:00 pmichaud rakudo doesn't use them.
16:01 pmichaud put another way, I don't think that tge/pge/data_json are at all involved in the amd64 problems.
16:02 NotFound data_json is heavily used
16:02 pmichaud it's used by... ?
16:03 NotFound mime_base64, for example, wich is mentioned in several reports about the mad64 problems.
16:04 NotFound tools/dev/nci_thunk_gen.pir also uses it
16:04 NotFound And is also related with the problems of gargbage in generated code.
16:04 pmichaud generated code from... ?
16:04 NotFound from nci_thin_gen
16:05 NotFound nci_thunk_gen
16:05 pmichaud ah
16:05 pmichaud well, I don't have any plans to try to rewrite pge to avoid codestring, as it's being deprecated.
16:05 pmichaud better would be to rewrite data_json to not use tge/pge
16:05 NotFound I've tried, but don't know how to get 'unique' from, for example.
16:06 NotFound Tried to avoid CodeString, that is.
16:06 pmichaud oh, PCT::HLLCompiler provides a replacement 'unique'
16:07 NotFound pmichaud: yeah, but I don't know what object I can use in the data_json usages of CodeString I've looked
16:07 NotFound I'm tempted to write a json parser in C.
16:07 pmichaud $P0 = get_hll_global ['PCT'], 'HLLCompiler'
16:07 pmichaud something = $P0.'unique'()
16:08 pmichaud json_data returns a Sub?
16:08 pmichaud interesting.
16:08 NotFound pmichaud: yes, that is part of I'd like to get rid of.
16:09 pmichaud you want it to return the data structure directly?
16:09 NotFound Yes
16:09 pmichaud jeepers, I bet I could write this in NQP very quickly.
16:09 pmichaud it's just a compiler.
16:09 NotFound Generating code for such thing is a waste and serves no useful purpose.
16:10 pmichaud oh, I disagree.  Currently the only good way we have to serialize data structures for libraries is as Parrot subs.
16:10 patspam left #parrot
16:11 NotFound Generating pir from the data when requeired will be easier than the other way, and faster when you don't need the sub.
16:12 pmichaud anyway, I can write a replacement for data_json, if that will help the amd64 efforts.
16:13 pmichaud I can have it generate either a sub or a data structure.
16:13 pmichaud making other components work with the new data_json.... not something I'm likely to do :)
16:14 NotFound Mmm... you mean using a compreg object that has keeps the compile method for generating a sub, and other method called compile_to_data or something like that?
16:16 nwellnhof joined #parrot
16:16 luben_work I maight have an idea about amd64 optimized build
16:16 pmichaud a compreg object that has different targets
16:16 luben_work why they are broken
16:16 whiteknight ah crap. I forgot to test the optimized build last night when I was home
16:16 pmichaud basically, the other target would switch out the action methods to return the data structure directly instead of PAST nodes
16:17 NotFound pmichaud: 'target' the named argument of the compile method, you mean?
16:17 pmichaud NotFound: currently one can do  target=pir, target=past, target=parse, etc.
16:17 pmichaud I can just add a target=data
16:18 NotFound Works for me.
16:18 pmichaud and have it do the steps needed to return the data structure directly rather than go through the code/compile/generation phase
16:18 NotFound luben_work: please explain
16:19 ruoso joined #parrot
16:19 luben_work does our GC check for pointers in "args passing registers" -  and "saved register" on AMD64
16:19 luben_work on AMD64 some of the function args (first 6 integer args) are not passed on the stack
16:20 luben_work additionally, some register are saved between function calls
16:20 whiteknight luben_work: Good question. All that code is in src/gc/system.c, I think
16:21 luben_work so, I clever compiler could avoid allocation of vars on the stack and work only with registers
16:21 NotFound luben_work: the assumption someone told me some time ago is that all relevant info is saved in the stack, becuse the gc is always invoked via function calls.
16:21 nwellnhof the code is here: http://trac.parrot.org/parrot/br​owser/trunk/src/gc/system.c#L122
16:21 luben_work and so if the only pointer to GC-able object is in register, we get a boom....
16:21 dalek TT #1780 created by whiteknight++: Using StringHandle for STDERR can cause segfaults
16:21 dalek TT #1780: http://trac.parrot.org/parrot/ticket/1780
16:22 nwellnhof it seems that we use a setjmp to get the register contents on the stack.
16:22 whiteknight right, I don't know what all that copies
16:24 NotFound luben_work: if the only pointer is in a register and should survive a function call, the C compiler should take care to stack it or save it.
16:24 NotFound (Unless we lie to the compiler, as we sometimes do)
16:24 luben_work NotFound, but if it does not have to survive...
16:25 NotFound luben_work: if it does not have to survive, it can be collected
16:25 whiteknight Do we know which PMC is getting recycled? If we find that exact PMC we can take care to ensure it is anchored somewhere
16:25 NotFound whiteknight: we don't know if the problem is something being recycled
16:27 luben_work imagine: in function a: return b(reg o); in function b(void *i): trigger GC run; (here where i point may be reallocated to another object))
16:28 NotFound luben_work: i should be allocated somewhere. It can't be left in a register used for passing arguments to functions while calling other functions.
16:29 whiteknight NotFound: if an item isn't getting prematurely collected/recycled, what is the problem?
16:29 NotFound whiteknight: the visible problems I have seen is wrongly generated code.
16:30 NotFound That may means a pmc being premturely collected, ot misused strings, or who knows.
16:31 nopaste "nwellnhof" at 192.168.1.3 pasted "bits/setjmp.h" (5 lines) at http://nopaste.snit.ch/23277
16:32 nwellnhof it seems that the jump buffer contains only 8 words on amd64. so we might really be missing some registers.
16:32 baest left #parrot
16:32 ash_ is it not using the defined jmp_buf type? From setjmp.h?
16:34 NotFound ash_: I suppose that bits/setjmp.h is the system header internally used by setjmp.h
16:35 NotFound The file /usr/include/bits/setjmp.h in linux systems
16:35 Coke ~~
16:35 luben_work here is a scenario I have in mind: http://pastebin.com/hs62XbkP
16:37 ash_ on OS X, the 64 bit jmp_buff is int jmp_buf[37];  and the i386 is int jmp_buf[18]
16:37 ash_ but that is architecture dependent
16:37 NotFound luben_work: x can't be in a temporary register overwritable by function calls if it is used later.
16:38 luben_work NotFound, its not used in the function more
16:38 NotFound No sane C compiler can do that.
16:38 NotFound luben_work: I see it in the return line
16:38 luben_work it is returned, may be in different register or memory
16:39 NotFound Sorry?
16:39 purl It's okay, NotFound.
16:40 luben_work I don't know, this is just a suggestion...
16:40 NotFound To be able to return it later, it must be in a safe place while calling other functions. It can't be in an unsafe temporary.
16:41 NotFound And the gc is triggered only via function calls.
16:41 nwellnhof if there are callee-saved registers that are not put on the stack in trace_system_areas on AMD64, we definitely have a problem.
16:42 NotFound We definitely have problems, but usually are cause by ourselves, not by the C compiler.
16:42 tcurtis joined #parrot
16:52 nwellnhof left #parrot
16:55 dalek parrot: r48884 | NotFound++ | trunk/src/string/api.c:
16:55 dalek parrot: avoid segfaulting in string_rep_compatible is a string has null encoding for some reason, TT #1779
16:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48884/
17:00 luben_work on amd64 if we compile with -fno-inline everithing goes OK
17:01 Coke so add that to the config defaults for that platform?
17:02 NotFound Given that the problem is in optimized builds, no wonder that avoiding some optimizations it goes well.
17:03 luben_work yes
17:03 Coke (i imagine ideally we need more compiler annotations on some subs.)
17:04 cotto_work ~~
17:04 NotFound IMO we should not have subs that require annotations, except maybe in some very low level access functions.
17:05 NotFound And surely packfile reading level is not that low,
17:06 NotFound However, if the problem is a bug in the compiler we can make an exception only for that compiler and version.
17:08 NotFound Disabling an important optimizations for all gcc or all amd64 looks excesive to me.
17:09 NotFound I'll give a try to the patch in TT #1777
17:09 Coke yes, limit it only specific combo.
17:09 luben_work NotFound, I agree
17:10 NotFound Looks like gcc 4.3.2 is the culprit. Someone is having problems with other version?
17:11 luben_work What versions of GCC you use?
17:11 NotFound In amd64? 4.3.2
17:11 luben_work here I have problems with gcc-4.4 -O2 also
17:11 NotFound 4.3.2 (Debian 4.3.2-1.1)
17:11 luben_work gcc-4.5 -O2 is fine, but gcc-4.5 -O3 is broken in the same way
17:12 NotFound Not so easy, then.
17:15 davidfetter joined #parrot
17:17 NotFound The __attribute__ ((__noinline__)) makes no difference to me.
17:24 PerlPilot joined #parrot
17:24 PerlPilot left #parrot
17:26 PerlJam left #parrot
17:27 PerlJam joined #parrot
17:27 nwellnhof joined #parrot
17:37 dukeleto hola
17:37 cotto_work holla
17:38 davidfetter hollla
17:45 dalek parrot: r48885 | NotFound++ | trunk/src/exceptions.c:
17:45 dalek parrot: avoid redying from unhandled exceptions while dying from unhandled exception, TT #1780
17:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48885/
17:48 estrabd left #parrot
17:49 estrabd joined #parrot
17:52 dukeleto davidfetter: i would like to make a .deb for the next release of PL/Parrot. It opens a lot of options and I think will make it much more likely for people to try it
17:52 davidfetter agreed
17:59 luben_work left #parrot
18:05 patspam joined #parrot
18:19 patspam1 joined #parrot
18:19 patspam left #parrot
18:20 dalek TT #857 closed by Paul_the_Greek++: Parrot_floatval_time() and Parrot_intval_time() do not match up on Win32
18:20 dalek TT #857: http://trac.parrot.org/parrot/ticket/857
18:27 Paul_the_Greek joined #parrot
18:28 Paul_the_Greek Okay, I need a little enlightening.
18:28 PerlJam Paul_the_Greek: 42
18:28 Paul_the_Greek Thank you, sir.
18:28 NotFound 666
18:29 Paul_the_Greek Also good.
18:29 * PerlJam shines a light on Paul_the_Greek
18:29 Paul_the_Greek So here's what I get when I make headerizer ...
18:29 cotto_work There is no spoon?
18:29 purl But there is a spork.
18:29 Paul_the_Greek can't find HEADERIZER HFILE directive in "src/ops/core_ops.c" at tools/dev/headerizer.pl line 355
18:29 Paul_the_Greek Indeed, no headerizer directive in that generated file.
18:29 NotFound Paul_the_Greek: windows?
18:29 purl windows is one hell of an event! or crashing on someone
18:30 Paul_the_Greek But it's listed in makefile as a file to be headerized.
18:30 Paul_the_Greek Yes, Windows XP.
18:30 Paul_the_Greek Why doesn't everyone get this error?
18:30 cotto_work trying to reproduce now
18:30 NotFound Paul_the_Greek: maybe no one has ever used make headerizer in windows
18:30 Paul_the_Greek But it's listed as a file to be headerized, in makefile, unconditionally.
18:31 Paul_the_Greek I should be getting that error.
18:31 patspam1 left #parrot
18:31 Paul_the_Greek Oh wait, is that part of makefile created by the configurer?
18:31 cotto_work yes
18:32 Paul_the_Greek Ah.
18:32 cotto_work wfm on linux
18:32 Paul_the_Greek Must investigate Configure.pl, then.
18:33 NotFound Paul_the_Greek: Is a svn build?
18:33 Paul_the_Greek cotto_work: Check your makefile and search for INTERP_O_FILES. core_ops is not listed there, right?
18:33 Paul_the_Greek Yes, svn.
18:34 cotto_work yup
18:34 cotto_work it is listed there
18:34 Paul_the_Greek Second file in the list?
18:35 Paul_the_Greek Then please search for O_FILES and tell me if INTERP_O_FILES is in its list.
18:35 cotto_work it is
18:36 Paul_the_Greek Then please search for HEADERIZER_O_FILES and tell me if O_FILES is in its list.
18:36 cotto_work It looks like we should be trying to headerize it.
18:36 cotto_work Paul_the_Greek: config/gen/makefiles/root.in is what much of Makefile is generated from
18:36 NotFound Where do you see it listed?
18:36 contingencyplan left #parrot
18:37 Paul_the_Greek NotFound: What do you mean by "it"?
18:37 NotFound core_ops.c in the Makefile
18:37 cotto_work For some reason, .o files are passed to headerizer, not .c
18:38 cotto_work afk for a bit
18:38 Paul_the_Greek It's included in INTERP_O_FILES, which are some of the files that are headerized.
18:38 Paul_the_Greek It's right there in root.in, so no surprise it's in makefile.
18:39 Paul_the_Greek Why the heck isn't it headerized on non-Windows systems?
18:41 Paul_the_Greek NotFound: Can you check your copy of core_ops.c to see if it has a headerizer tag?
18:43 * NotFound adding a few print STDERR to headerizer.pl
18:45 NotFound This line seems to be related: next if $ofile =~ m/^\Qsrc$PConfig{slash}ops\E/;
18:46 NotFound Maybe $PConfig[slahs} is not as expected?
18:46 Paul_the_Greek A highly perspicuous Perl line, as always.
18:47 NotFound This will be better? next if $ofile =~ m/^\Qsrc[/$PConfig{slash}]ops\E/;
18:47 Paul_the_Greek Can you translate for me?
18:47 Paul_the_Greek Oh ...
18:47 NotFound Do nothing if the file is in /src/ops
18:47 Paul_the_Greek Right, a question of slash vs. backslash.
18:48 Paul_the_Greek Where are the PConfig values?
18:48 contingencyplan joined #parrot
18:49 NotFound From perl, I think.
18:49 Paul_the_Greek There is a slash entry in config_lib.pir
18:50 NotFound That code seems to assume that paths always have the usual slash of the platform, and that assumption is invalid.
18:50 Paul_the_Greek Mine is set to "\\".
18:50 Paul_the_Greek Yes, it is.
18:50 Paul_the_Greek Let me try your fix ...
18:50 NotFound I'm not fluent with perl regexes, not sure if that fix is valid.
18:51 Paul_the_Greek No, it's not. Hang on ...
18:52 NotFound Uh.... the / probably need to be escaped.
18:53 Paul_the_Greek Yes, it does. What is \Q and \E ?
18:54 atrodo They say "don't listen to any other escapes until you see a \E"
18:54 NotFound Q          quote (disable) pattern metacharacters till \E
18:54 NotFound Oh, nice...
18:54 Paul_the_Greek Oh, well then that explains why it doesn't work.
18:54 Andy joined #parrot
18:54 NotFound Going the easy way: duplicate the line.
18:54 Paul_the_Greek All fixed.
18:55 Paul_the_Greek No let me do it the right way.
18:55 NotFound Sure
18:56 NotFound Please add a comment explaining the purpose of that skip
18:56 Paul_the_Greek Will do.
18:57 Paul_the_Greek What does $PConfig(slash) mean? Is that interpolated when the pattern is scanned?
18:58 NotFound I told you I'm not fluent with perl regexes ;)
18:58 Paul_the_Greek Yeah, you and me both, baby.
19:00 plobsing Paul_the_Greek: (did you mean $PConfig{slash} ?) yes, it is interpolated. It is just a hash lookup.
19:00 Paul_the_Greek Yeah, you and me both, baby.
19:02 Paul_the_Greek All righty, this is working much better. I'll add a big fat comment and commit it.
19:02 Paul_the_Greek Any test I should run other than make headerizer?
19:03 nopaste "nwellnhof" at 192.168.1.3 pasted "This patch might fix the amd64/optimized problems" (14 lines) at http://nopaste.snit.ch/23278
19:03 luben nwellnhof, trying now
19:03 nwellnhof i have a good feeling this time...
19:03 NotFound Paul_the_Greek: Commit it and let's see what happens on linux, unless you have a linux box at hand and can easily copy to it.
19:05 Paul_the_Greek Sorry, no linux box. It's checking for the local directory separator and for slash, so I think we're good.
19:06 NotFound Paul_the_Greek: commit it, we can quicky revert if break something
19:08 luben nwellnhof, no, it does not help here
19:08 nwellnhof luben: which gcc version?
19:09 luben 4.5
19:09 nwellnhof with -O3?
19:09 luben I could try also with 4.4
19:09 luben yes
19:09 dalek parrot: r48886 | plobsing++ | branches/oplib_handling_cleanup:
19:09 dalek parrot: creating branch to clean up the handling of ops and oplibs
19:09 dalek parrot: should address TT #1758
19:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48886/
19:09 dalek parrot: r48887 | Paul C. Anagnostopoulos++ | trunk/tools/dev/headerizer.pl:
19:09 dalek parrot: fix headerizer to correctly skip src/ops/ files
19:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48887/
19:10 luben nwellnhof, recompiling now with gcc-4.4
19:10 nwellnhof luben: can you check if trace_system_stack really doesn't get inlined in trace_system_areas
19:11 luben how could I check this
19:11 NotFound nwellnhof: don't fix for me in gcc 4.3.2
19:11 cotto_work Paul_the_Greek: it works but I'm not entirely sure that's the right place to fix that problem.
19:11 luben nwellnhof, it fixes gcc-4.4 -O2
19:12 luben but does not fixes gcc-4.4 -O3
19:12 cotto_work We should probably be using @slash@ much more often than we do in the makefile template.
19:12 nopaste "nwellnhof" at 192.168.1.3 pasted "check if function is inlined" (45 lines) at http://nopaste.snit.ch/23279
19:12 Paul_the_Greek I'm committed it, but I agree that it makes more sense to eliminate core_ops from the headerizer list.
19:13 Paul_the_Greek Bit of a trick, though.
19:13 NotFound cotto_work: or much less often. All windows versions understand /
19:13 jan left #parrot
19:14 Paul_the_Greek If we don't eliminate core_ops from the headerizer list, we have to check for it somewhere.
19:15 dalek plparrot: 2b0aabf | leto++ | / (2 files):
19:15 dalek plparrot: Allow Perl 6 Grammars as return values of stored procedures
19:15 dalek plparrot:
19:15 dalek plparrot: When defining a global grammar for later use, the return value of the
19:15 dalek plparrot: stored procedure was a Grammar object, which PL/Perl6 did not know how
19:15 dalek plparrot: to convert to a Postgres datatype, so the sausage machine came to a
19:15 dalek plparrot: grinding halt. We catch these and just return a true value instead.
19:15 dalek plparrot:
19:15 cotto_work Sure.  I'm just saying that we shouldn't need to check the path against two regexes.
19:15 dalek plparrot: There is currently a bug in Rakudo where Grammar.WHAT is "Code", and
19:15 dalek plparrot: somehow that gets turned into a "Sub", so that was worked around as
19:15 dalek plparrot: well.
19:15 dalek plparrot: review: http://github.com/leto/plparrot/commit/2​b0aabfea0d45947ef0a9a9eccc7866367559e4c
19:15 luben nwellnhof, it's not inlined here
19:16 NotFound Paul_the_Greek: fill a ticket about that, to give our perl fluent friends something to do.
19:16 Paul_the_Greek Will do.
19:17 nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (20 lines) at http://nopaste.snit.ch/23280
19:17 nwellnhof luben: which gcc version and optimization level?
19:17 ash_ Paul_the_Greek: where are you having problems with perl?
19:17 luben gcc-4.5 -O3
19:18 Paul_the_Greek It's not a problem with Perl. It's a problem with the headerizer having to skip some files explicitly.
19:18 luben with gcc-4.5 -O2 , the bug does not shows
19:18 NotFound Having to skip some files that are explicitly passed to it.
19:19 nopaste "nwellnhof" at 192.168.1.3 pasted "Another try at disabling inlining" (25 lines) at http://nopaste.snit.ch/23281
19:19 NotFound Will be easier to pass the full tree and let it choose ;)
19:20 nwellnhof luben: but the first patch fixed gcc 4.4 for you which didn't work before?
19:20 luben yes
19:20 Paul_the_Greek It could simply skip files with headerizer markers, but that seems dangerous.
19:20 luben let me check again
19:20 Paul_the_Greek s/with/without/
19:20 nwellnhof can you also try the second patch?
19:21 luben yes, now I am compiling stock version with gcc-4.4 -O2
19:22 cotto_work Talk about fighting the compiler.
19:22 luben hmm, strange, gcc-4.4 -O2 works fine on base64 test. Running the test suite
19:23 luben there were more tests failing
19:23 NotFound Paul_the_Greek: Headerization complete.
19:23 NotFound Works fine in linux
19:23 nwellnhof luben: the mime base64 test might be a different issue.
19:24 NotFound Hey, you closed the ticket before hearing my report ;)
19:24 luben there are some failing test - t/pmc/packfile.t
19:24 luben oo, no. it is ok
19:24 luben make test passes
19:26 luben compiling now with gcc-4.3
19:27 luben mime64 test fails with gcc-4.3 -O2
19:27 dalek TT #1773 closed by Paul_the_Greek++: make headerizer fails on Windows XP
19:27 dalek TT #1773: http://trac.parrot.org/parrot/ticket/1773
19:28 Paul_the_Greek NotFound: Oops, sorry. What report?
19:29 luben with the second patch the build does not finish (gcc-4.3 -O2)
19:29 NotFound Paul_the_Greek: Verifying that works in linux
19:30 jan joined #parrot
19:31 Paul_the_Greek I'm sorry, when you said "commit it and we can quickly revert" I got carried away.
19:32 NotFound With the current urge to close tickets, I understand ;)
19:32 cotto_work I also verified that it worked.
19:33 NotFound NM
19:33 Paul_the_Greek New Mexico?
19:33 purl There's a NEW Mexico now!
19:34 cotto_work Nocturnal Monkeys
19:34 cotto_work also, never mind
19:35 nwellnhof luben: when does gcc 4.3 fail? can it build libparrot?
19:35 luben let me check
19:36 NotFound I don't understand that comments about need to regenerate pbc. packfile test shouldn't be using native_pbc since some time.
19:37 luben nwellnhof, yes it is built, fails on parrot-nqp call
19:38 nwellnhof luben: can you check if trace_system_stack gets inlined?
19:38 luben yes
19:40 nwellnhof it gets inlined with gcc 4.3 although we have the noinline attribute?
19:40 luben hmm...
19:40 nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (17 lines) at http://nopaste.snit.ch/23282
19:41 nwellnhof can you show a dump of trace_system_areas?
19:41 luben how to do that?
19:42 nwellnhof just disas trace_system_areas instead of trace_system_stack
19:42 luben aha.. ok
19:43 nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (16 lines) at http://nopaste.snit.ch/23283
19:44 nwellnhof that seems ok. so, no progress on gcc 4.3
19:44 Coke in general, don't use config{slash} when a plain ole / will do. We were overusing the heck out of it and I ripped it out of several locations.
19:46 Coke (there are only a very few places on win32 where it's really needed)
19:47 NotFound Is nolinline or __noinline__ ?
19:48 GeJ Bonjour everyone.
19:52 Coke moshi moshi
19:52 purl moshi moshi is what Japanese people say when they pick the phone up
20:01 whiteknight left #parrot
20:02 dalek parrot-linear-algebra: 673cca5 | Whiteknight++ | src/ (4 files):
20:02 dalek parrot-linear-algebra: ComplexMatrix2D now extracts a complex value from PMCs using role-based rules instead of checking equality on vtable->base_type. As of Parrot r48883 this allows using subclasses of Complex for most operations. All tests pass again
20:02 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/673cca5647a168e51dc2dfeca2616b3c485a282b
20:02 dalek parrot-linear-algebra: 973d65c | Whiteknight++ | t/ (2 files):
20:02 dalek parrot-linear-algebra: make the test harness a little bit more tolerant of tests which abort early. This whole thing is becoming ripe for a complete refactor
20:02 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/973d65c2300c566caf2b9ab030b8bc32a597c20a
20:02 dalek parrot-linear-algebra: 7e0058d | Whiteknight++ | t/harness:
20:02 dalek parrot-linear-algebra: complete rewrite of t/harness. Break it up into classes and simplify a few things. Might not cover all cases that the old one has, I've done limited testing of it.
20:02 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/7e0058d001714df7864efdc78b740bab8f87f395
20:02 ash_ left #parrot
20:07 davidfetter left #parrot
20:08 fperrad left #parrot
20:15 Paul_the_Greek ping cotto_work
20:16 patspam joined #parrot
20:16 cotto_work pong
20:16 dalek parrot: r48888 | NotFound++ | trunk/t/pmc/hashiteratorkey.t:
20:16 dalek parrot: rearrange HashIteratorKey tests and add a few more
20:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48888/
20:19 Paul_the_Greek cotto_work: Would you like me to work on this ticket: http://trac.parrot.org/parrot/ticket/650
20:19 Paul_the_Greek It would be a good excuse to suck it up and learn Perl.
20:21 dukeleto Paul_the_Greek++
20:21 dukeleto Paul_the_Greek: which languages are you most familiar with?
20:22 NotFound Paul_the_Greek: please don't learn how to comment perl code from some of our sources %-)
20:22 cotto_work It's fine if you need an excuse to learn Perl.  That's one of the systems that'll go away when Lorito arrives at some indeterminate point in the future.
20:22 Paul_the_Greek Perl and I are ... how to put this ... not entirely compatible. But that is no excuse.
20:23 cotto_work There are many ways to write Perl 5.
20:24 Paul_the_Greek I will write it trying to avoid lots of _* thingies and other things that seem like chicken scratching.
20:24 Paul_the_Greek In other words, in a simple manner.
20:25 cotto_work There are pleny of people around who can review anything you're not entirely confident about.
20:25 Paul_the_Greek cotto_work: If pmc2c is not really broken, perhaps there are better things for me to do.
20:25 Paul_the_Greek Such as thing one: http://trac.parrot.org/parrot/ticket/1041
20:25 contingencyplan left #parrot
20:26 Paul_the_Greek But again, if it's going away sometime ...
20:27 cotto_work I personally wouldn't take on a pmc2c task unless it were causing immediate pain or likely to do so.
20:27 Paul_the_Greek That seems like a good philosophy. I shall continue my search for a good ticket.
20:27 dukeleto Paul_the_Greek: I have something for you
20:28 Paul_the_Greek Uh oh.
20:28 Coke is it ... a knuckle sandwich!?!
20:28 NotFound A pony?
20:28 purl a pony is multi-functional or http://www.angryflower.com/pony.html or http://svn.rcbowen.com/svn/​public/mod_pony/mod_pony.c
20:28 sorear has pmc2c been rewritten in nqp-rx yet?
20:28 dukeleto Paul_the_Greek: http://trac.parrot.org/parrot/ticket/370
20:28 dukeleto Paul_the_Greek: that ticket has lots of tests already. You just need to make them pass.
20:29 dukeleto Paul_the_Greek: there are some edge cases in our VTABLES, where Inf/NaN gets converted to a machine value
20:29 Paul_the_Greek Yes, I've seen those in my recent travels.
20:29 dukeleto Paul_the_Greek: i've played with it a bit, but maybe both of us together can make it work
20:30 cotto_work sorear: nope.  The current plan is to have the next (and hopefully last) major PMC refactor be to rewrite them in Lorito.
20:30 Coke what does "in lorito" mean? ;)
20:30 cotto_work Something that gets translated to L1 ops.
20:30 * Coke is just trolling
20:30 atrodo I would guess that you would want to rewrite PMCs in NQP
20:30 Paul_the_Greek dukeleto: Okay, I'm game. I'll grab that ticket and start looking at it.
20:30 NotFound loritops?
20:31 cotto_work er, M1
20:31 dukeleto Paul_the_Greek++ while(1);
20:31 atrodo LM1?
20:31 Paul_the_Greek cotto_work: So let's just write a C-to-L1 compiler and Bob's your uncle.
20:31 cotto_work That's two of the things we're explicitly trying to avoid.
20:32 cotto_work (nothing against Bob)
20:32 dukeleto Paul_the_Greek: if you finish that one or need something else to work on, http://trac.parrot.org/parrot/ticket/987 may be fun for you. I can help with parrot_debugger questions
20:32 NotFound While you are at it, write also a C++ compiler
20:32 dukeleto Paul_the_Greek: fixing that ticket would actually make the parrot_debugger useful, and that would be pretty awesome.
20:33 Paul_the_Greek dukeleto: I'll take that one, too. Should be mighty amusing.
20:33 dalek parrot: r48889 | NotFound++ | trunk/src/pmc/bytebuffer.pmc:
20:33 dalek parrot: drop a no longer needed call to STRING_validate in ByteBuffer, the tests will avoid regressions
20:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48889/
20:34 Paul_the_Greek But don't we have the world's best compiler writing tools? Compiling C should be a piece of cake.
20:34 Paul_the_Greek Well, a large piece, I suppose.
20:35 NotFound Paul_the_Greek: sure, but other C compilers have decades of advantage.
20:35 Paul_the_Greek Right, but unless we code directly in L1, we're relying on a good compiler anyway.
20:35 Paul_the_Greek Wait, are you talking about coding the PMCs in L1?
20:38 NotFound Paul_the_Greek: the idea is that coding the PMC and the ops in something that gets compiled to loritops is the way to avoid the need to use inner loops in vtable and method calls
20:38 NotFound Ideally, to avoid inner loops at all.
20:38 Paul_the_Greek Fill me in on these inner loops.
20:39 sorear Do you mean inferior runloops?
20:39 atrodo Inner loops are when the run core calls C, which calls the runloop
20:39 cotto_work sorear: same thing
20:40 NotFound I don't like the word "inferior" ;)
20:40 atrodo I do
20:40 cotto_work think of it as a technical term
20:40 bluescreen left #parrot
20:41 cotto_work meaning "not as good"
20:41 NotFound Technically inferior?
20:41 Paul_the_Greek What's a common example of when an inferior loop occurs?
20:42 atrodo Inferior, as in subjugated to another?
20:42 NotFound Paul_the_Greek: when a vtable function is overriden on a pir class
20:42 sorear Any time a vtable needs to call pir/nqp code
20:42 sorear or a pccmethod
20:42 purl a pccmethod is the thing that  will eventually be renamed after the deprecated METHOD, it is for pmc method that don't fit in the pmc table
20:42 cotto_work forget a pccmethod
20:42 purl cotto_work: I forgot pccmethod
20:43 sorear inferior runloops are unavoidable if we're binding to a C library with callbacks
20:43 Paul_the_Greek So some C-implemented operation needs to have pir code executed ...
20:43 sorear e.g. most GUI stuff
20:44 Paul_the_Greek Why can't it just futz the stack and then return to the current runloop?
20:44 Paul_the_Greek Ah, because it needs to execute again afterward?
20:44 NotFound sorear: some people said there may be ways to avoid it in such cases, but I doubt it.
20:44 bluescreen joined #parrot
20:45 NotFound Paul_the_Greek: because the caller usually don't expect to be discarded
20:45 nwellnhof have two separate stacks?
20:45 sorear Paul_the_Greek: C code expects to store return frames in a contiguous block of memory indexed off the stack pointer
20:45 sorear Parrot code expects to store them in the heap
20:46 Paul_the_Greek Right.
20:46 sorear the inferior runloop system is essentially just impedance matching for return paths
20:46 NotFound If some day we have a wonderful threads impelementation, it may be ways... in some platforms.
20:46 nopaste "bluescreen" at 192.168.1.3 pasted "adding methods using vtable's 'add_method' generates problems with methods's parameters" (15 lines) at http://nopaste.snit.ch/23284
20:47 Paul_the_Greek But no amount of cleverness would avoid inner loops for, say, callbacks.
20:48 Paul_the_Greek So the problem with inner loops is ... there's overhead to start them up and shut them down?
20:49 NotFound Paul_the_Greek: the main problem is that passing arguments from parrot to C to parrot.... is expensive
20:49 NotFound One of the main problems, at least.
20:49 Paul_the_Greek Ah, indeed. Too much enboxification.
20:50 cotto_work bluescreen: the method needs to have .param pmc self as its first param
20:50 bluescreen really...
20:50 bluescreen that make sense
20:50 Paul_the_Greek But again, you can't avoid that when calling external libraries.
20:50 bluescreen let me try that
20:50 cotto_work also, you don't want :init there
20:50 cotto_work :main or nothing would be better
20:50 bluescreen ok
20:51 bluescreen thanks cotto_work++
20:51 cotto_work np
20:52 cotto_work :init means it'll execute twice, since the first sub has an implicit :main
20:52 cotto_work rather, the first sub has an implicit :main if nothing else has an explicit :main
20:53 NotFound But better be explicit, implicit main may be deprecated some day...
20:53 cotto_work If nothing else, explicit :main is less magical.
20:53 bluescreen is :init in pir as BEGIN is for perl ?
20:54 Paul_the_Greek Boo! implicit :main
20:55 Paul_the_Greek ping dukeleto
20:55 cotto_work bluescreen: no.  It's more like :immediate
20:55 tcurtis Paul_the_Greek: fun side-effect of implicit main: nullary subs can't really be checked for the right number of parameters (IIUC), since the main sub can either have a slurpy args parameter or no parameters.
20:56 Paul_the_Greek What about other subs?
20:57 Paul_the_Greek Wait a minute, why does that matter? It's either defined with no params or with a slurpy one.
20:57 tcurtis Paul_the_Greek: Because the main sub gets called with the command-line arguments whether or not it's defined with parameters.
20:58 tcurtis I think.
20:58 Paul_the_Greek That doesn't seem right.
20:58 Paul_the_Greek Don't pass the arguments if it's not defined to take them.
20:59 Paul_the_Greek Whose idea was it to pass command-line arguments to main functions, anyway?
20:59 tcurtis Paul_the_Greek: both implicit :main and lack of checking of arguments to :main subs are deprecated. http://trac.parrot.org/parrot/br​owser/trunk/DEPRECATED.pod#L318
21:00 tcurtis I'm not sure if that means :main subs will be required to have a slurpy param or if Parrot will detect whether or not it does.
21:00 NotFound tcurtis: they are, but AFAIK no one has even started to think about fixing the test suite.
21:00 Paul_the_Greek There you go.
21:01 Paul_the_Greek I'd vote for detecting whether it has one.
21:02 Paul_the_Greek Not really a big deal either way, I suppose.
21:02 NotFound I noticed a problem with the installed winxed compiler: there is no way to look for the :main flag in a Eval
21:03 NotFound I used the dirty trick of looking for the name 'main' for a now.
21:03 whiteknight joined #parrot
21:04 Paul_the_Greek .sub not_main :main
21:05 NotFound Maybe the good solution is to run the compiled code in a child interpreter
21:07 dalek parrot: r48890 | nwellnhof++ | trunk (4 files):
21:07 dalek parrot: [gc] Make sure that trace_system_stack is not inlined
21:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48890/
21:20 bluescreen left #parrot
21:21 tcurtis left #parrot
21:23 * whiteknight is thinking about writing up an ncurses wrapper for Parrot
21:23 dukeleto Paul_the_Greek: pong
21:24 NotFound whiteknight: I think we already have one.
21:24 whiteknight do we? I wasn't aware of any
21:24 sorear Curses in the libraries, no?
21:25 NotFound runtime/parrot/library/ncurses.pir
21:25 dukeleto whiteknight: that sounds useful
21:25 dukeleto does anything actually use the ncurses library, tho?
21:25 sorear Tene has a Rakudo rebinding of it
21:25 sorear I think there are a couple users on that side
21:26 Paul_the_Greek dukeleto: The NaN rounding problem is more complicated than it first appears.
21:26 Paul_the_Greek dukeleto: $I0 = 1e20 doesn't throw an exception, either.
21:26 whiteknight ah yes, I think we do have an ncurses interface here
21:26 whiteknight runtime/parrot/library/ncurses.pir
21:28 Tene i do remember doing something ncurses before...
21:28 dalek winxed: r618 | NotFound++ | trunk/winxedst1.winxed:
21:28 dalek winxed: update to parrot encoding/charset massacre
21:28 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=618
21:28 Tene Yeah, I've used that from rakudo, iirc.
21:32 NotFound Talking about wrappers, I'm making progress with Gtk2 via blizkost
21:33 dalek winxed: r619 | NotFound++ | trunk/pir/winxed_compiler.pir:
21:33 dalek winxed: update pir installable files
21:33 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=619
21:33 dukeleto Paul_the_Greek: yes, there are some layers to the onion :) I have been unraveling them slowly
21:34 dukeleto Paul_the_Greek: $I0 = 1e20 works like it should
21:35 dukeleto Paul_the_Greek: Inf and -Inf can't be stored in an integer register
21:35 dukeleto Paul_the_Greek: so $I0 stores the smallest machine value
21:36 dukeleto Paul_the_Greek: that issue is different that floor(NaN) returning the smallest machine integer
21:37 dukeleto iirc, +-Inf and NaN can only be stored in $P* and $N* registers
21:37 ruoso left #parrot
21:38 * nwellnhof thinks about a bitmask for the attrs of a PMC that need to be marked.
21:38 NotFound We don't have invented NaI yet,
21:39 NotFound (Not a Integer)
21:40 dalek parrot: r48891 | nwellnhof++ | trunk/src/pmc/packfileannotations.pmc:
21:40 dalek parrot: [pmc] Mark gr_byte and gr_entries in PackfileAnnotations PMC
21:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48891/
21:41 * nwellnhof thinks that such a bitmask could be easily generated by pmc2c
21:45 patspam left #parrot
21:55 dukeleto NotFound: Gtk2 via blizkost sounds promising, what kind of stuff are you running into?
21:56 NotFound dukeleto: I'm workarounding blizkost limitations. I inherit from Sub in a class that overrides invoke, and use that class to pass data to callbacks.
21:57 NotFound I'm wondering about changing the check isa Sub to does invokable in blizkost
21:57 dalek parrot: r48892 | plobsing++ | branches/oplib_handling_cleanup (6 files):
21:57 dalek parrot: add interp.op_hash to map op names to op info
21:57 dalek parrot: will replace hacking core_ops to accomplish the same
21:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48892/
21:58 NotFound Inheriting from Sub is a ugly hack.
22:01 nopaste "NotFound" at 192.168.1.3 pasted "Work in progress - using Gtk2 via blizkost with winxed" (277 lines) at http://nopaste.snit.ch/23286
22:01 NotFound Here is what I have.
22:03 dukeleto NotFound: very cool.
22:04 NotFound I need to improve some things in winxed to make it better.
22:04 dukeleto NotFound: i can apply changes to Blizkost if you need them. We need to make sure we don't break the few things that use blizkost now
22:05 NotFound dukeleto: What do you think about the switch from isa Sub to does invokable?
22:10 sjn left #parrot
22:15 jnthn isa Sub => does invokable doesn't sound immediately problematic to me, fwiw.
22:16 NotFound I'll try it and do a pull request if sucessful, then.
22:21 dalek tracwiki: v23 | cotto++ | GitMigration
22:21 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=23&amp;action=diff
22:23 sorear if you can figure out how to make blizkost not stupid, it doesn't really mater how much you break
22:23 sorear everything that uses it now is just kludges on top of kludges
22:24 dukeleto NotFound: i say go for it
22:24 sorear in particular, I gave up on making arrays and hashes work through blizkost out of frustration and confusion
22:27 dukeleto sorear: what problems did you run into?
22:27 sorear dukeleto: iterator and container semantics are confusing, inconsistant, and not very compatible with Perl5
22:30 dukeleto sorear: what is the fallout from that? i.e. what is not possible because arrays/hashes don't work through blizkost?
22:31 dukeleto cotto_work: there you go, adding to the yak pile .... ;)
22:36 * cotto_work hands dukeleto a handful of yak hair
22:36 cotto_work I've got plenty more where that came from.
22:37 tcurtis joined #parrot
22:39 Paul_the_Greek dukeleto: $i0 = 1e20 sets the register to the minimum integer. That doesn't seem right.
22:40 cotto_work I can't think of anything smaller than 1e20.
22:41 Paul_the_Greek Huh?
22:42 Paul_the_Greek 1e20 - 1 ?
22:44 cotto_work Woah.
22:46 Paul_the_Greek Horses about?
22:51 dukeleto Paul_the_Greek: so you are saying that it should be the max integer?
22:51 Paul_the_Greek I have no idea what any of these should be. They are all undefined in C.
22:51 Paul_the_Greek I think we should throw an exception.
22:51 Coke msg chromatic - how does r48878 get any improvement?
22:51 purl Message for chromatic stored.
22:51 aloha OK. I'll deliver the message.
22:52 Paul_the_Greek "Unable to convert real to integer."
22:52 Paul_the_Greek Or else specify that they are undefined.
22:52 dukeleto Paul_the_Greek: hmmm
22:52 plobsing Paul_the_Greek: handling the constant gets done in the PIR compiler. IMCC is pretty much high-priority bugfix only at this point. If *you* want to fix it, go ahead.
22:53 dukeleto Paul_the_Greek: it may be that $I0 = 1e20 is just wrapping around to a negative #, not necessarily setting it to the min integer
22:53 Paul_the_Greek dukeleto: Or we could conditionalize the exception like it is for integer overflow.
22:53 Paul_the_Greek Let me check ...
22:54 NotFound I think I've discovered the difference between build from git and from svn
22:54 Paul_the_Greek dukeleto: What a coincidence. Yes, some sort of bizarre wrapping is going on.
22:54 NotFound A $Id in nci_thun_gen.pir
22:55 dukeleto Paul_the_Greek: in C, floor() and ceil() are defined to return +-MAXINT if the values are too big
22:55 dukeleto Paul_the_Greek: iirc, ansi89 says that, or some relative of it
22:55 Paul_the_Greek Ah, okay, but they are undefined for Inf and NaN.
22:55 Paul_the_Greek Let me check that ...
22:56 dukeleto Paul_the_Greek: i think that is normal "C" wrapping behavior. if you do "int i = HUGENUM" in C, you will get +- HUGENUM % MAXINT
22:56 dukeleto Paul_the_Greek: where % is the modulus operator
22:57 Paul_the_Greek dukeleto: There is no floor() => int in C.
22:57 dukeleto C doesn't throw an exception when assiging too-large a number to an int, and Parrot inherited that behavior, for better or worse
22:57 dukeleto Paul_the_Greek: maybe i am thinking of the cmod function
22:57 Paul_the_Greek Let's see what it says about assignment conversion ...
22:58 Paul_the_Greek "The behavior ... is undefined if the floating-point value cannot be represented even approximately in the new type"
22:58 sorear dukeleto: that's for unsigned integer overflow
22:59 Paul_the_Greek So we leave it undefined or we throw an exception. I would not start defining all these conversion combinations.
23:00 dukeleto Paul_the_Greek: i tend to agree
23:00 sorear dukeleto: if $arr is a Perl ARRAY ref, you'll want to do my &arget = eval('sub { $_[0][$_[1]] }', :lang<perl5>); say arget($arr, 5);
23:01 Paul_the_Greek Let's document it as undefined. If there is a compelling reason to throw an exception in the future, we can always do that.
23:01 sorear Undefined behavior or undefined result?
23:02 Paul_the_Greek Undefined result.
23:02 Paul_the_Greek I'll find the correct place to document this.
23:03 dukeleto Paul_the_Greek: you can't store an Undef in an integer register
23:03 Paul_the_Greek Right, so it will come out as some random integer.
23:04 Paul_the_Greek That's what we mean by "undefined result."
23:04 Paul_the_Greek I will word it as "the result is an arbitrary integer" or something like that.
23:05 Paul_the_Greek Making sure not to imply that we have some special integer that indicates "undefined."
23:05 dalek parrot-linear-algebra: a1189e5 | Whiteknight++ | t/harness:
23:05 dalek parrot-linear-algebra: uncomment extra directories and run all tests. All tests pass
23:05 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/a1189e54ec6494f43fb74c8e0a3e21514915b5dc
23:05 dalek parrot-linear-algebra: 06e853d | Whiteknight++ | .gitignore:
23:05 dalek parrot-linear-algebra: add generated html files to .gitignore
23:05 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/06e853d5071b17ed11d429ffd9bba418782766cb
23:06 dukeleto whiteknight++ # getting all your tests passing
23:07 whiteknight dukeleto: and there are a LOT of tests in PLA now
23:07 whiteknight I don't know if you've played with it lately, but it's getting to be quite an impressive little library
23:08 dukeleto whiteknight: it is definitely on my (ever-growing) list of parrot stuff to play with
23:08 cotto_work I wish I had the background to care about PLA.
23:09 dukeleto whiteknight: it would be interested to benchmark PLA vs Math::MatrixReal from perl 5
23:09 dukeleto s/interested/interesting/
23:09 whiteknight dukeleto: yes, that would be nice. I bet the perl5 version would win just because of Parrot method call overhead
23:09 whiteknight though if you stuck to vtable calls, it would probably be quite competitive
23:09 dukeleto cotto_work: yeah, it takes a special kind of nerd to get excited about linear algebra. i am one of those nerds :)
23:10 dukeleto whiteknight: you don't know unless you benchmark it :)
23:10 dukeleto whiteknight: PLA's memory footprint is probably better, but who knows
23:10 cotto_work and a special type of nerd to get excited about Parrot, so the intersection is special indeed
23:10 dukeleto cotto_work: mmmm, venn diagrams, ....
23:11 tcurtis mmmm, set operations, ....
23:13 cotto_work mmmm. nerds.
23:14 dukeleto whiteknight: now that PLA is passing it's test suite, does that mean you will be hacking on matrixy now?
23:15 dukeleto plobsing: does your recent commit help with this TT? http://trac.parrot.org/parrot/ticket/1500
23:15 whiteknight dukeleto: entirely possible. I am at a good stopping point for now. I am trying to get a release out for PLA first
23:17 dukeleto whiteknight: cool. i am gonna check out the repo and run the test suite right now :)
23:17 plobsing dukeleto: not really yet. it makes getting at op_info easier. unfortunately, AFAIK, opcode group information is not available at runtime.
23:17 plobsing but if and when it becomes available, it will most likely be accessible via op_info
23:19 dukeleto plobsing: so it helps in the journey. that is good to hear
23:22 dukeleto whiteknight: have you thought of making PLA come with Kakapo?
23:23 dukeleto whiteknight: i compiled pla successfully on 64bit linux, let's see if I can run your tests
23:26 dukeleto whiteknight: the debian packages you list in the README seemed to have changed names
23:28 dukeleto whiteknight: you could just ship a kakapo pbc file, it looks like.
23:33 dukeleto wow. kakapo has a lot of stuff
23:36 dukeleto whiteknight:  http://gist.github.com/572779 <-- kakapo seems to be blowing up on the PLA test suite, for me
23:36 dukeleto whiteknight: that is with parrot r48772
23:37 dukeleto whiteknight: when i run kakapo's test suite, it runs 0 files. that seems funky
23:40 Coke msg kid51 r48875 - Please fork nqp-rx on github and patch that in the source. There's no point in updating the generated code in parrot.
23:40 purl Message for kid51 stored.
23:40 aloha OK. I'll deliver the message.
23:41 dukeleto http://www.bioperl.org/wiki/Using_Git <-- useful guide to crimp from for the parrot git docs
23:42 Coke msg Paul_the_Greek r48887 - why is that 2 regexes and not just {src/ops} !?
23:42 purl Message for paul_the_greek stored.
23:42 aloha OK. I'll deliver the message.
23:42 Paul_the_Greek Coke: It has to match slash and also the local directory separator.
23:43 Paul_the_Greek I'm sure you can do that in one regex, but I couldn't figure out how.
23:46 Coke Paul_the_Greek: it was matching the local directory separator. you added a hardcoded forward slash.
23:46 Coke so presumably, you (on windows!) needed the hardcoded forward slash. yes?
23:47 Paul_the_Greek The idea was that forward slash always works, and then the local separator also works.
23:47 Paul_the_Greek They may be the same, or not.
23:47 Coke but the local separator DID NOT work for you. yes?
23:47 Coke in the case where local separator was \
23:47 Paul_the_Greek On Windows, both / and \ work.
23:48 Coke then how were you getting the failure on \ ?
23:48 Coke scratch that.
23:49 Paul_the_Greek makefile uses /, but that wasn't being matched on Windows.
23:49 Coke so if / and \ work for you, (and you added / even though theoretically (but not practically) working with \), and / works everywhere else we care about... why not just kill the original regex and leave yours?
23:50 Paul_the_Greek In case a path with \ shows up in the headerizer.
23:50 Paul_the_Greek on Windows.
23:50 Coke ... but you just said it's using /
23:50 Paul_the_Greek makefile is using /. I could invoke the headerizer directly.
23:51 Paul_the_Greek Or, in the future, configure could generate a makefile with \.
23:51 Coke no, it won't
23:51 Paul_the_Greek Since both / and \ work, shouldn't the headerizer handle that?
23:51 Paul_the_Greek It's not an efficiency issue or anything.
23:52 Coke as I specifically ripped all that out and used / everywhere, even on windows, because it works with far less code.
23:52 Paul_the_Greek (Note that this was not a unilateral decision.)
23:52 Coke the "because I might run it from the command line" is the best reason I've heard, but I don't know anyone who does that, even on linux.
23:52 Paul_the_Greek So you're saying we should just ignore config(slash)?
23:53 Coke ... in the cases where it is a waste of time, yes.
23:53 Paul_the_Greek But surely you're not suggesting that extra test matters in the headerizer?
23:54 Coke technical debt?
23:54 purl technical debt is the debt you build up of stuff you have to do later. http://c2.com/cgi/wiki?TechnicalDebt or http://www.media-landscape.co​m/yapc/2006-06-26.AndyLester/
23:54 Paul_the_Greek I'm not sure why it is, but I'm not trying to make some big case here.
23:55 Paul_the_Greek We all just figured both separators should work.
23:56 Paul_the_Greek I'm happy to remove the use of config(slash).
23:57 Coke no, you gave a perfectly good reason to need it.
23:58 Coke I just committed a small change to document that so you don't get some jerk like me giving you a hard time.
23:58 Coke also, note the one-character smaller regexp.
23:59 Paul_the_Greek The slash configuration item is used in four *.pl files.
23:59 Paul_the_Greek Let me check ...

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced