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.
dukeleto Paul_the_Greek: awesome, will keep that in mind 00:00
Paul_the_Greek Burn, baby, burn.
00:00 Psyche^ joined
dalek TT #1200 closed by Paul_the_Greek++: sprintf formatting for exponents needs to be standardized 00:00
TT #1200: trac.parrot.org/parrot/ticket/1200
00:01 Patterner left, Psyche^ is now known as Patterner
Paul_the_Greek If I add a benchmark, do I need to register it in any file? 00:06
00:07 theory left 00:11 Paul_the_Greek left
Coke 00:18
cd sandbox
ww
cotto_work error: sandbox not found
I was sure you'd left it somewhere around here. 00:19
00:25 plobsing joined
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.
dukeleto for now, anyway.
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
dukeleto cotto_work: best of luck. let me know how it goes 00:28
00:30 cognominal left
darbelo Hm, I think MANIFEST is used by our install scripts to determine what they should install. 00:35
00:35 ascent left, ascent joined
darbelo Although it might be less relevant now that we don't care about install vs install-dev. 00:35
00:37 kid51 joined
dukeleto kid51: how goes it? 00:42
00:45 cognominal joined
dukeleto Finaly Summary of GSoC 2010: leto.net/dukeleto.pl/2010/09/google...mmary.html 00:48
kid51 dukeleto hello 00:52
dukeleto kid51: howdy 00:53
dalek rrot: r48874 | coke++ | trunk/t/op/calling.t:
avoid use of deprecated method to test this feature
 00:56
Coke I'm getting failures in 'make test' 00:58
(and I'm not on amd64!)
MANIFEST.generated is used for the installs. 00:59
cotto ~~
Coke (no?)
dalek rrot-linear-algebra: 297a02f | Whiteknight++ | t/pir-subclass/nummatrix2d.t:
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
rrot-linear-algebra: 2c8ae58 | Whiteknight++ | t/pir-subclass/nummatrix2d.t:
flesh out the nummatrix2d subclass tests. This appears to cover all VTABLEs that use mapped types
Coke I forgot about the use of MANIFEST for /making/ the tarball.
dalek rrot-linear-algebra: ac8772b | Whiteknight++ | /:
teh mergz
01:01 tcurtis joined
cotto Looks like allison saved me from an unnecessary branch, for now at least. 01:03
whiteknight how? 01:04
cotto gave a good reason why we keep MANIFEST around 01:05
(et al)
01:06 kid51 is now known as kid51_at_dinner
dukeleto cotto_work: we need MANIFEST, it is just how we go about generating it and maintaining it 01:07
Coke so much for hacking on parrot tonight. (TT #1779) 01:12
dalek TT #1779 created by coke++: test failures on OSX 01:25
TT #1779: trac.parrot.org/parrot/ticket/1779
01:27 nwellnhof left
nopaste "Whiteknight" at 192.168.1.3 pasted "Why I hate GDB sometimes" (7 lines) at nopaste.snit.ch/23274 01:36
whiteknight seriously. There's a segfault happening, and GDB doesn't stop at all for it 01:38
blargle. I'll deal with all of this crap tomorrow. Goodnight 01:59
02:00 kid51_at_dinner is now known as kid51
dalek rrot-linear-algebra: 73ed80c | Whiteknight++ | / (3 files):
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
kid51 Oh, how we need our smolder server back! 02:05
dalek kudo: 859f2d9 | colomon++ | src/core/Iterable.pm:
Add Iterable.Numeric so that Arrays (and other Iterable types) numify to Int rather than to Num.
kid51 That's the only way we can keep track of which configuration variants result in which build/test failures.
02:09 whiteknight left 02:14 darbelo left 02:15 darbelo joined
dukeleto hola 02:17
darbelo aloha: msg whiteknight (Re: 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.
aloha darbelo: OK. I'll deliver the message.
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.
aloha OK. I'll deliver the message.
kid51 dukeleto++ for GSOC blog post: leto.net/dukeleto.pl/2010/09/google...mmary.html 02:29
dukeleto is listening to chromatic++ talk about modern perl philosophy at PDX.pm
kid51: thanks
darbelo dukeleto: Audio or it didn't happen :) 02:30
02:30 theory joined
kid51 FWIW: at r48874 I got PASS for 'make test' on both Linux/i386 (--optimize) and Darwin/PPC. 02:32
Are these test failures all in the 64-world?
(And on Linux/i386 'make fulltest' PASS except for 3 codingstd fails, 2 of which I've fixed) 02:33
dukeleto there is a podcast being made and someone is livestreaming it, i think 02:34
live stream: ustre.am/p0
darbelo Nice.
02:35 janus left
kid51 merlyn is the streamer 02:35
dalek rrot: r48875 | jkeenan++ | trunk/ext/nqp-rx/src/stage0/HLL-s0.pir:
Correct 2 pod formatting errors.
 02:36
rrot: r48876 | jkeenan++ | trunk/src/spf_render.c:
[codingstd] Correct c_parens error -- but c_function_docs error remains.
02:42 Andy joined 02:47 janus joined
dalek rrot: r48877 | mikehh++ | trunk/src/spf_render.c:
sort out documentation to pass c_function_docs.t
 02:53
nopaste "kid51" at 192.168.1.3 pasted "hash_inlined_func branch: t/pmc/hash.t continued failures" (182 lines) at nopaste.snit.ch/23275
03:01 kid51 left 03:45 arnsholt left 03:46 hercynium left 03:52 arnsholt joined 04:13 arnsholt left 04:14 plobsing left 04:33 arnsholt joined 04:51 jsut joined 04:55 jsut_ left 05:26 Andy left 06:07 darbelo left 06:23 uniejo joined 06:27 esskar left
dalek rrot: r48878 | chromatic++ | branches/hash_inlined_func/src/hash.c:
[hash] Optimized parrot_hash_mark().

effects for any GC-heavy code.		 06:47
rrot: r48879 | chromatic++ | branches/hash_inlined_func/src/hash.c:
[hash] Fixed key annotation for key_hash().

have to catch undesired NULLness.
06:50 fperrad joined 07:10 theory left, theory joined, theory left
dalek rrot: r48880 | chromatic++ | trunk/src/gc/mark_sweep.c:
[GC] Sprinkled consts in Parrot_gc_sweep_pool().

hot path.		 07:20
08:23 cotto_work left 08:24 cotto_work joined 09:12 ttbot left 09:22 ttbot joined 09:44 tcurtis left 10:14 PerlJam left, PerlJam joined, Util left, Util joined, dukeleto left, dukeleto joined 10:23 dukeleto left, pmichaud left, Util left 10:24 PerlJam left, PerlJam joined, dalek left 10:29 dukeleto joined, dalek joined 10:34 Util joined 10:39 pmichaud joined 11:23 luben_work joined 11:34 GodFather joined 11:55 contingencyplan left 11:59 contingencyplan joined
smash hello everyone 11:59
12:12 whiteknight joined 12:14 plobsing joined
whiteknight good morning, #parrot 12:29
smash whiteknight: mornin'
whiteknight hello smash, how are you today? 12:31
smash whiteknight: fine thank you, and you ? 12:33
whiteknight fine as well. Could always use more sleep, but can't complain otherwise 12:34
12:35 bluescreen joined
smash nice, could use some mre sleep as well 12:38
12:50 ash_ left 13:10 ash_ joined 13:14 fperrad left 13:17 uniejo left, Patterner left 13:23 uniejo joined
dalek rrot: r48881 | mikehh++ | trunk/src/namespace.c:
fix g++ build - namespace is a reserved word in C++
 13:33
rrot: r48882 | whiteknight++ | trunk/src/pmc/complex.pmc:
Complex pmc now provides 'complex' role, to help ease working with it and various subclasses
13:43 Psyche^ joined, Psyche^ is now known as Patterner
dalek rrot: r48883 | whiteknight++ | trunk (2 files):
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
13:50 uniejo left
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) 13:58
macruby is almost to the point where it could be an alternative syntax for obj-c 14:00
14:09 ash_ left
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:09
14:11 fperrad joined 14:22 ash_ joined
ash_ just have to figure out how to cross compile parrot using XCode... 14:24
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, particle joined 14:50 theory joined 14:59 shockwave left 15:07 patspam joined
pmichaud good morning, #parrot 15:09
(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
15:10 GodFather left
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
(and reused)
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 :-)
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:18
it still may be worth adding streq_at to our permanent set 15:19
moritz once we have a generational GC, the long lived objects shouldn't matter that much 15:20
pmichaud right
moritz then avoiding GCables makes sense again
pmichaud I keep wondering when "once" will be. :-)
moritz christmas!
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 15:22 mikegrb joined
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:22
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.
pmichaud NotFound: as long as NQP also gets rid of its other needs for substr, yes. 15:24
based on past experience, the cost of indexing into variable width encodings is a significant cost.
especially as source code gets longer.
15:24 fperrad_ joined
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:25
I fully plan to take out the substring operation from NQP when we have efficient unicode strings. :) 15:27
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
15:28 fperrad left, fperrad_ is now known as fperrad
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.
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.
NotFound Oh, nqp, sorry.
pmichaud or nqp, for that matter.
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
s/uff/utf
pmichaud I think that anytime we can avoid variable width encoding internally that's likely to be a nice win. 15:34
oh, there's another possibility
(not a great one, but it exists)
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.
We'd still end up switching things back into strings to be able to do case conversions and property checks, though. 15:36
(or we'd have to develop opcodes that know how to do those kinds of things for RIA instead of strings)
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?
pmichaud maybe, but that's probably the easiest part of that switch 15:38
NotFound Is the easier to test, at least.
pmichaud doing a literal comparison between two integer arrays doesn't strike me as being nearly as efficient as saying iseq $S0, $S1
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)++
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
So we can take it as fixed width safely,
pmichaud as long as I can get directly to offset $n without having to scan from the start of the string :-)
s/I/Parrot/ 15:43
NotFound Reamining CodeString usages, checked with ack, are in compilers/tge compilers/pge and compilers/data_json 15:50
If someone get rid of that, I bet that debugging the amd64 problems will be easier. 15:51
pmichaud does anything use those? 16:00
I mean, does anything use tge/pge/data_json
rakudo doesn't use them.
put another way, I don't think that tge/pge/data_json are at all involved in the amd64 problems. 16:01
NotFound data_json is heavily used 16:02
pmichaud it's used by... ?
NotFound mime_base64, for example, wich is mentioned in several reports about the mad64 problems. 16:03
tools/dev/nci_thunk_gen.pir also uses it 16:04
And is also related with the problems of gargbage in generated code.
pmichaud generated code from... ?
NotFound from nci_thin_gen
nci_thunk_gen 16:05
pmichaud ah
well, I don't have any plans to try to rewrite pge to avoid codestring, as it's being deprecated.
better would be to rewrite data_json to not use tge/pge
NotFound I've tried, but don't know how to get 'unique' from, for example.
Tried to avoid CodeString, that is. 16:06
pmichaud oh, PCT::HLLCompiler provides a replacement 'unique'
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
I'm tempted to write a json parser in C.
pmichaud $P0 = get_hll_global ['PCT'], 'HLLCompiler'
something = $P0.'unique'()
json_data returns a Sub? 16:08
interesting.
NotFound pmichaud: yes, that is part of I'd like to get rid of.
pmichaud you want it to return the data structure directly? 16:09
NotFound Yes
pmichaud jeepers, I bet I could write this in NQP very quickly.
it's just a compiler.
NotFound Generating code for such thing is a waste and serves no useful purpose.
pmichaud oh, I disagree. Currently the only good way we have to serialize data structures for libraries is as Parrot subs. 16:10
16:10 patspam left
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:11
pmichaud anyway, I can write a replacement for data_json, if that will help the amd64 efforts. 16:12
I can have it generate either a sub or a data structure. 16:13
making other components work with the new data_json.... not something I'm likely to do :)
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:14
16:16 nwellnhof joined
luben_work I maight have an idea about amd64 optimized build 16:16
pmichaud a compreg object that has different targets
luben_work why they are broken
whiteknight ah crap. I forgot to test the optimized build last night when I was home
pmichaud basically, the other target would switch out the action methods to return the data structure directly instead of PAST nodes
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.
I can just add a target=data
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
NotFound luben_work: please explain
16:19 ruoso joined
luben_work does our GC check for pointers in "args passing registers" - and "saved register" on AMD64 16:19
on AMD64 some of the function args (first 6 integer args) are not passed on the stack
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
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.
nwellnhof the code is here: trac.parrot.org/parrot/browser/trun...tem.c#L122
luben_work and so if the only pointer to GC-able object is in register, we get a boom....
dalek TT #1780 created by whiteknight++: Using StringHandle for STDERR can cause segfaults
TT #1780: trac.parrot.org/parrot/ticket/1780
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
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
(Unless we lie to the compiler, as we sometimes do)
luben_work NotFound, but if it does not have to survive...
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
NotFound whiteknight: we don't know if the problem is something being recycled
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:27
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:28
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.
That may means a pmc being premturely collected, ot misused strings, or who knows. 16:30
nopaste "nwellnhof" at 192.168.1.3 pasted "bits/setjmp.h" (5 lines) at nopaste.snit.ch/23277 16:31
nwellnhof it seems that the jump buffer contains only 8 words on amd64. so we might really be missing some registers. 16:32
16:32 baest left
ash_ is it not using the defined jmp_buf type? From setjmp.h? 16:32
NotFound ash_: I suppose that bits/setjmp.h is the system header internally used by setjmp.h 16:34
The file /usr/include/bits/setjmp.h in linux systems 16:35
Coke ~~
luben_work here is a scenario I have in mind: pastebin.com/hs62XbkP
ash_ on OS X, the 64 bit jmp_buff is int jmp_buf[37]; and the i386 is int jmp_buf[18] 16:37
but that is architecture dependent
NotFound luben_work: x can't be in a temporary register overwritable by function calls if it is used later.
luben_work NotFound, its not used in the function more 16:38
NotFound No sane C compiler can do that.
luben_work: I see it in the return line
luben_work it is returned, may be in different register or memory
NotFound Sorry? 16:39
purl It's okay, NotFound.
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.
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.
NotFound We definitely have problems, but usually are cause by ourselves, not by the C compiler. 16:42
16:42 tcurtis joined 16:52 nwellnhof left
dalek rrot: r48884 | NotFound++ | trunk/src/string/api.c:
avoid segfaulting in string_rep_compatible is a string has null encoding for some reason, TT #1779
 16:55
luben_work on amd64 if we compile with -fno-inline everithing goes OK 17:00
Coke so add that to the config defaults for that platform? 17:01
NotFound Given that the problem is in optimized builds, no wonder that avoiding some optimizations it goes well. 17:02
luben_work yes 17:03
Coke (i imagine ideally we need more compiler annotations on some subs.)
cotto_work ~~ 17:04
NotFound IMO we should not have subs that require annotations, except maybe in some very low level access functions.
And surely packfile reading level is not that low, 17:05
However, if the problem is a bug in the compiler we can make an exception only for that compiler and version. 17:06
Disabling an important optimizations for all gcc or all amd64 looks excesive to me. 17:08
I'll give a try to the patch in TT #1777 17:09
Coke yes, limit it only specific combo.
luben_work NotFound, I agree
NotFound Looks like gcc 4.3.2 is the culprit. Someone is having problems with other version? 17:10
luben_work What versions of GCC you use? 17:11
NotFound In amd64? 4.3.2
luben_work here I have problems with gcc-4.4 -O2 also
NotFound 4.3.2 (Debian 4.3.2-1.1)
luben_work gcc-4.5 -O2 is fine, but gcc-4.5 -O3 is broken in the same way
NotFound Not so easy, then. 17:12
17:15 davidfetter joined
NotFound The __attribute__ ((__noinline__)) makes no difference to me. 17:17
17:24 PerlPilot joined, PerlPilot left 17:26 PerlJam left 17:27 PerlJam joined, nwellnhof joined
dukeleto hola 17:37
cotto_work holla
davidfetter hollla 17:38
dalek rrot: r48885 | NotFound++ | trunk/src/exceptions.c:
avoid redying from unhandled exceptions while dying from unhandled exception, TT #1780
 17:45
17:48 estrabd left 17:49 estrabd joined
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 18:05 patspam joined 18:19 patspam1 joined, patspam left
dalek TT #857 closed by Paul_the_Greek++: Parrot_floatval_time() and Parrot_intval_time() do not match up on Win32 18:20
TT #857: trac.parrot.org/parrot/ticket/857
18:27 Paul_the_Greek joined
Paul_the_Greek Okay, I need a little enlightening. 18:28
PerlJam Paul_the_Greek: 42
Paul_the_Greek Thank you, sir.
NotFound 666
Paul_the_Greek Also good. 18:29
PerlJam shines a light on Paul_the_Greek
Paul_the_Greek So here's what I get when I make headerizer ...
cotto_work There is no spoon?
purl But there is a spork.
Paul_the_Greek can't find HEADERIZER HFILE directive in "src/ops/core_ops.c" at tools/dev/headerizer.pl line 355
Indeed, no headerizer directive in that generated file.
NotFound Paul_the_Greek: windows?
purl windows is one hell of an event! or crashing on someone
Paul_the_Greek But it's listed in makefile as a file to be headerized. 18:30
Yes, Windows XP.
Why doesn't everyone get this error?
cotto_work trying to reproduce now
NotFound Paul_the_Greek: maybe no one has ever used make headerizer in windows
Paul_the_Greek But it's listed as a file to be headerized, in makefile, unconditionally.
I should be getting that error. 18:31
18:31 patspam1 left
Paul_the_Greek Oh wait, is that part of makefile created by the configurer? 18:31
cotto_work yes
Paul_the_Greek Ah. 18:32
cotto_work wfm on linux
Paul_the_Greek Must investigate Configure.pl, then.
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?
Yes, svn.
cotto_work yup 18:34
it is listed there
Paul_the_Greek Second file in the list?
Then please search for O_FILES and tell me if INTERP_O_FILES is in its list. 18:35
cotto_work it is
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.
Paul_the_Greek: config/gen/makefiles/root.in is what much of Makefile is generated from
NotFound Where do you see it listed?
18:36 contingencyplan left
Paul_the_Greek NotFound: What do you mean by "it"? 18:37
NotFound core_ops.c in the Makefile
cotto_work For some reason, .o files are passed to headerizer, not .c
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.
It's right there in root.in, so no surprise it's in makefile.
Why the heck isn't it headerized on non-Windows systems? 18:39
NotFound: Can you check your copy of core_ops.c to see if it has a headerizer tag? 18:41
NotFound adding a few print STDERR to headerizer.pl 18:43
This line seems to be related: next if $ofile =~ m/^\\Qsrc$PConfig{slash}ops\\E/; 18:45
Maybe $PConfig[slahs} is not as expected? 18:46
Paul_the_Greek A highly perspicuous Perl line, as always.
NotFound This will be better? next if $ofile =~ m/^\\Qsrc[/$PConfig{slash}]ops\\E/; 18:47
Paul_the_Greek Can you translate for me?
Oh ...
NotFound Do nothing if the file is in /src/ops
Paul_the_Greek Right, a question of slash vs. backslash.
Where are the PConfig values? 18:48
18:48 contingencyplan joined
NotFound From perl, I think. 18:49
Paul_the_Greek There is a slash entry in config_lib.pir
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 "\\\\".
Yes, it is.
Let me try your fix ...
NotFound I'm not fluent with perl regexes, not sure if that fix is valid.
Paul_the_Greek No, it's not. Hang on ... 18:51
NotFound Uh.... the / probably need to be escaped. 18:52
Paul_the_Greek Yes, it does. What is \\Q and \\E ? 18:53
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
Oh, nice...
Paul_the_Greek Oh, well then that explains why it doesn't work.
18:54 Andy joined
NotFound Going the easy way: duplicate the line. 18:54
Paul_the_Greek All fixed.
No let me do it the right way. 18:55
NotFound Sure
Please add a comment explaining the purpose of that skip 18:56
Paul_the_Greek Will do.
What does $PConfig(slash) mean? Is that interpolated when the pattern is scanned? 18:57
NotFound I told you I'm not fluent with perl regexes ;) 18:58
Paul_the_Greek Yeah, you and me both, baby.
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.
All righty, this is working much better. I'll add a big fat comment and commit it. 19:02
Any test I should run other than make headerizer?
nopaste "nwellnhof" at 192.168.1.3 pasted "This patch might fix the amd64/optimized problems" (14 lines) at nopaste.snit.ch/23278 19:03
luben nwellnhof, trying now
nwellnhof i have a good feeling this time...
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.
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:05
NotFound Paul_the_Greek: commit it, we can quicky revert if break something 19:06
luben nwellnhof, no, it does not help here 19:08
nwellnhof luben: which gcc version?
luben 4.5 19:09
nwellnhof with -O3?
luben I could try also with 4.4
yes
dalek rrot: r48886 | plobsing++ | branches/oplib_handling_cleanup:
creating branch to clean up the handling of ops and oplibs
rrot: r48887 | Paul C. Anagnostopoulos++ | trunk/tools/dev/headerizer.pl:
fix headerizer to correctly skip src/ops/ files
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
luben how could I check this 19:11
NotFound nwellnhof: don't fix for me in gcc 4.3.2
cotto_work Paul_the_Greek: it works but I'm not entirely sure that's the right place to fix that problem.
luben nwellnhof, it fixes gcc-4.4 -O2
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.
nopaste "nwellnhof" at 192.168.1.3 pasted "check if function is inlined" (45 lines) at nopaste.snit.ch/23279
Paul_the_Greek I'm committed it, but I agree that it makes more sense to eliminate core_ops from the headerizer list.
Bit of a trick, though. 19:13
NotFound cotto_work: or much less often. All windows versions understand /
19:13 jan left
Paul_the_Greek If we don't eliminate core_ops from the headerizer list, we have to check for it somewhere. 19:14
dalek parrot: 2b0aabf | leto++ | / (2 files):
Allow Perl 6 Grammars as return values of stored procedures

When defining a global grammar for later use, the return value of the stored procedure was a Grammar object, which PL/Perl6 did not know how to convert to a Postgres datatype, so the sausage machine came to a grinding halt. We catch these and just return a true value instead.
There is currently a bug in Rakudo where Grammar.WHAT is "Code", and somehow that gets turned into a "Sub", so that was worked around as well.		 19:15
cotto_work Sure. I'm just saying that we shouldn't need to check the path against two regexes.
luben nwellnhof, it's not inlined here
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.
nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (20 lines) at nopaste.snit.ch/23280 19:17
nwellnhof luben: which gcc version and optimization level?
ash_ Paul_the_Greek: where are you having problems with perl?
luben gcc-4.5 -O3
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
NotFound Having to skip some files that are explicitly passed to it.
nopaste "nwellnhof" at 192.168.1.3 pasted "Another try at disabling inlining" (25 lines) at nopaste.snit.ch/23281 19:19
NotFound Will be easier to pass the full tree and let it choose ;)
nwellnhof luben: but the first patch fixed gcc 4.4 for you which didn't work before? 19:20
luben yes
Paul_the_Greek It could simply skip files with headerizer markers, but that seems dangerous.
luben let me check again
Paul_the_Greek s/with/without/
nwellnhof can you also try the second patch?
luben yes, now I am compiling stock version with gcc-4.4 -O2 19:21
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
there were more tests failing 19:23
NotFound Paul_the_Greek: Headerization complete.
Works fine in linux
nwellnhof luben: the mime base64 test might be a different issue.
NotFound Hey, you closed the ticket before hearing my report ;) 19:24
luben there are some failing test - t/pmc/packfile.t
oo, no. it is ok
make test passes
compiling now with gcc-4.3 19:26
mime64 test fails with gcc-4.3 -O2 19:27
dalek TT #1773 closed by Paul_the_Greek++: make headerizer fails on Windows XP
TT #1773: trac.parrot.org/parrot/ticket/1773
Paul_the_Greek NotFound: Oops, sorry. What report? 19:28
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
Paul_the_Greek I'm sorry, when you said "commit it and we can quickly revert" I got carried away. 19:31
NotFound With the current urge to close tickets, I understand ;) 19:32
cotto_work I also verified that it worked.
NotFound NM 19:33
Paul_the_Greek New Mexico?
purl There's a NEW Mexico now!
cotto_work Nocturnal Monkeys 19:34
also, never mind
nwellnhof luben: when does gcc 4.3 fail? can it build libparrot? 19:35
luben let me check
NotFound I don't understand that comments about need to regenerate pbc. packfile test shouldn't be using native_pbc since some time. 19:36
luben nwellnhof, yes it is built, fails on parrot-nqp call 19:37
nwellnhof luben: can you check if trace_system_stack gets inlined? 19:38
luben yes
nwellnhof it gets inlined with gcc 4.3 although we have the noinline attribute? 19:40
luben hmm...
nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (17 lines) at nopaste.snit.ch/23282
nwellnhof can you show a dump of trace_system_areas? 19:41
luben how to do that?
nwellnhof just disas trace_system_areas instead of trace_system_stack 19:42
luben aha.. ok
nopaste "luben" at 192.168.1.3 pasted "disassemble trace_system_areas" (16 lines) at nopaste.snit.ch/23283 19:43
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.
(there are only a very few places on win32 where it's really needed) 19:46
NotFound Is nolinline or __noinline__ ? 19:47
GeJ Bonjour everyone. 19:48
Coke moshi moshi 19:52
purl moshi moshi is what Japanese people say when they pick the phone up
20:01 whiteknight left
dalek rrot-linear-algebra: 673cca5 | Whiteknight++ | src/ (4 files):
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
rrot-linear-algebra: 973d65c | Whiteknight++ | t/ (2 files):
make the test harness a little bit more tolerant of tests which abort early. This whole thing is becoming ripe for a complete refactor
rrot-linear-algebra: 7e0058d | Whiteknight++ | t/harness:
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 ash_ left 20:07 davidfetter left 20:08 fperrad left
Paul_the_Greek ping cotto_work 20:15
20:16 patspam joined
cotto_work pong 20:16
dalek rrot: r48888 | NotFound++ | trunk/t/pmc/hashiteratorkey.t:
rearrange HashIteratorKey tests and add a few more
Paul_the_Greek cotto_work: Would you like me to work on this ticket: trac.parrot.org/parrot/ticket/650 20:19
It would be a good excuse to suck it up and learn Perl.
dukeleto Paul_the_Greek++ 20:21
Paul_the_Greek: which languages are you most familiar with?
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.
Paul_the_Greek Perl and I are ... how to put this ... not entirely compatible. But that is no excuse.
cotto_work There are many ways to write Perl 5. 20:23
Paul_the_Greek I will write it trying to avoid lots of _* thingies and other things that seem like chicken scratching. 20:24
In other words, in a simple manner.
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.
Such as thing one: trac.parrot.org/parrot/ticket/1041
20:25 contingencyplan left
Paul_the_Greek But again, if it's going away sometime ... 20:26
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.
dukeleto Paul_the_Greek: I have something for you
Paul_the_Greek Uh oh. 20:28
Coke is it ... a knuckle sandwich!?!
NotFound A pony?
purl a pony is multi-functional or www.angryflower.com/pony.html or svn.rcbowen.com/svn/public/mod_pony/mod_pony.c
sorear has pmc2c been rewritten in nqp-rx yet?
dukeleto Paul_the_Greek: trac.parrot.org/parrot/ticket/370
Paul_the_Greek: that ticket has lots of tests already. You just need to make them pass.
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.
dukeleto Paul_the_Greek: i've played with it a bit, but maybe both of us together can make it work
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? ;)
cotto_work Something that gets translated to L1 ops.
Coke is just trolling
atrodo I would guess that you would want to rewrite PMCs in NQP
Paul_the_Greek dukeleto: Okay, I'm game. I'll grab that ticket and start looking at it.
NotFound loritops?
cotto_work er, M1 20:31
dukeleto Paul_the_Greek++ while(1);
atrodo LM1?
Paul_the_Greek cotto_work: So let's just write a C-to-L1 compiler and Bob's your uncle.
cotto_work That's two of the things we're explicitly trying to avoid.
(nothing against Bob) 20:32
dukeleto Paul_the_Greek: if you finish that one or need something else to work on, trac.parrot.org/parrot/ticket/987 may be fun for you. I can help with parrot_debugger questions
NotFound While you are at it, write also a C++ compiler
dukeleto Paul_the_Greek: fixing that ticket would actually make the parrot_debugger useful, and that would be pretty awesome.
Paul_the_Greek dukeleto: I'll take that one, too. Should be mighty amusing. 20:33
dalek rrot: r48889 | NotFound++ | trunk/src/pmc/bytebuffer.pmc:
drop a no longer needed call to STRING_validate in ByteBuffer, the tests will avoid regressions
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
Well, a large piece, I suppose.
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.
Wait, are you talking about coding the PMCs in L1?
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
Ideally, to avoid inner loops at all.
Paul_the_Greek Fill me in on these inner loops.
sorear Do you mean inferior runloops? 20:39
atrodo Inner loops are when the run core calls C, which calls the runloop
cotto_work sorear: same thing
NotFound I don't like the word "inferior" ;) 20:40
atrodo I do
cotto_work think of it as a technical term
20:40 bluescreen left
cotto_work meaning "not as good" 20:41
NotFound Technically inferior?
Paul_the_Greek What's a common example of when an inferior loop occurs?
atrodo Inferior, as in subjugated to another? 20:42
NotFound Paul_the_Greek: when a vtable function is overriden on a pir class
sorear Any time a vtable needs to call pir/nqp code
or a pccmethod
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
cotto_work forget a pccmethod
purl cotto_work: I forgot pccmethod
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 ...
sorear e.g. most GUI stuff
Paul_the_Greek Why can't it just futz the stack and then return to the current runloop? 20:44
Ah, because it needs to execute again afterward?
NotFound sorear: some people said there may be ways to avoid it in such cases, but I doubt it.
20:44 bluescreen joined
NotFound Paul_the_Greek: because the caller usually don't expect to be discarded 20:45
nwellnhof have two separate stacks?
sorear Paul_the_Greek: C code expects to store return frames in a contiguous block of memory indexed off the stack pointer
Parrot code expects to store them in the heap
Paul_the_Greek Right. 20:46
sorear the inferior runloop system is essentially just impedance matching for return paths
NotFound If some day we have a wonderful threads impelementation, it may be ways... in some platforms.
nopaste "bluescreen" at 192.168.1.3 pasted "adding methods using vtable's 'add_method' generates problems with methods's parameters" (15 lines) at nopaste.snit.ch/23284
Paul_the_Greek But no amount of cleverness would avoid inner loops for, say, callbacks. 20:47
So the problem with inner loops is ... there's overhead to start them up and shut them down? 20:48
NotFound Paul_the_Greek: the main problem is that passing arguments from parrot to C to parrot.... is expensive 20:49
One of the main problems, at least.
Paul_the_Greek Ah, indeed. Too much enboxification.
cotto_work bluescreen: the method needs to have .param pmc self as its first param 20:50
bluescreen really...
that make sense
Paul_the_Greek But again, you can't avoid that when calling external libraries.
bluescreen let me try that
cotto_work also, you don't want :init there
:main or nothing would be better
bluescreen ok
thanks cotto_work++ 20:51
cotto_work np
:init means it'll execute twice, since the first sub has an implicit :main 20:52
rather, the first sub has an implicit :main if nothing else has an explicit :main
NotFound But better be explicit, implicit main may be deprecated some day... 20:53
cotto_work If nothing else, explicit :main is less magical.
bluescreen is :init in pir as BEGIN is for perl ?
Paul_the_Greek Boo! implicit :main 20:54
ping dukeleto 20:55
cotto_work bluescreen: no. It's more like :immediate
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.
Paul_the_Greek What about other subs? 20:56
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.
I think. 20:58
Paul_the_Greek That doesn't seem right.
Don't pass the arguments if it's not defined to take them.
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. trac.parrot.org/parrot/browser/trun...D.pod#L318
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.
Paul_the_Greek There you go.
I'd vote for detecting whether it has one. 21:01
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
I used the dirty trick of looking for the name 'main' for a now. 21:03
21:03 whiteknight joined
Paul_the_Greek .sub not_main :main 21:04
NotFound Maybe the good solution is to run the compiled code in a child interpreter 21:05
dalek rrot: r48890 | nwellnhof++ | trunk (4 files):
[gc] Make sure that trace_system_stack is not inlined
 21:07
21:20 bluescreen left 21:21 tcurtis left
whiteknight is thinking about writing up an ncurses wrapper for Parrot 21:23
dukeleto Paul_the_Greek: pong
NotFound whiteknight: I think we already have one. 21:24
whiteknight do we? I wasn't aware of any
sorear Curses in the libraries, no?
NotFound runtime/parrot/library/ncurses.pir 21:25
dukeleto whiteknight: that sounds useful
does anything actually use the ncurses library, tho?
sorear Tene has a Rakudo rebinding of it
I think there are a couple users on that side
Paul_the_Greek dukeleto: The NaN rounding problem is more complicated than it first appears. 21:26
dukeleto: $I0 = 1e20 doesn't throw an exception, either.
whiteknight ah yes, I think we do have an ncurses interface here
runtime/parrot/library/ncurses.pir
Tene i do remember doing something ncurses before... 21:28
dalek nxed: r618 | NotFound++ | trunk/winxedst1.winxed:
update to parrot encoding/charset massacre
Tene Yeah, I've used that from rakudo, iirc.
NotFound Talking about wrappers, I'm making progress with Gtk2 via blizkost 21:32
dalek nxed: r619 | NotFound++ | trunk/pir/winxed_compiler.pir:
update pir installable files
 21:33
dukeleto Paul_the_Greek: yes, there are some layers to the onion :) I have been unraveling them slowly
Paul_the_Greek: $I0 = 1e20 works like it should 21:34
Paul_the_Greek: Inf and -Inf can't be stored in an integer register 21:35
Paul_the_Greek: so $I0 stores the smallest machine value
Paul_the_Greek: that issue is different that floor(NaN) returning the smallest machine integer 21:36
iirc, +-Inf and NaN can only be stored in $P* and $N* registers 21:37
21:37 ruoso left
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,
(Not a Integer) 21:39
dalek rrot: r48891 | nwellnhof++ | trunk/src/pmc/packfileannotations.pmc:
[pmc] Mark gr_byte and gr_entries in PackfileAnnotations PMC
 21:40
nwellnhof thinks that such a bitmask could be easily generated by pmc2c 21:41
21:45 patspam left
dukeleto NotFound: Gtk2 via blizkost sounds promising, what kind of stuff are you running into? 21:55
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:56
I'm wondering about changing the check isa Sub to does invokable in blizkost 21:57
dalek rrot: r48892 | plobsing++ | branches/oplib_handling_cleanup (6 files):
add interp.op_hash to map op names to op info
NotFound Inheriting from Sub is a ugly hack. 21:58
nopaste "NotFound" at 192.168.1.3 pasted "Work in progress - using Gtk2 via blizkost with winxed" (277 lines) at nopaste.snit.ch/23286 22:01
NotFound Here is what I have.
dukeleto NotFound: very cool. 22:03
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
NotFound dukeleto: What do you think about the switch from isa Sub to does invokable? 22:05
22:10 sjn left
jnthn isa Sub => does invokable doesn't sound immediately problematic to me, fwiw. 22:15
NotFound I'll try it and do a pull request if sucessful, then. 22:16
dalek tracwiki: v23 | cotto++ | GitMigration 22:21
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
sorear if you can figure out how to make blizkost not stupid, it doesn't really mater how much you break 22:23
everything that uses it now is just kludges on top of kludges
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
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
dukeleto sorear: what is the fallout from that? i.e. what is not possible because arrays/hashes don't work through blizkost? 22:30
cotto_work: there you go, adding to the yak pile .... ;) 22:31
cotto_work hands dukeleto a handful of yak hair 22:36
I've got plenty more where that came from.
22:37 tcurtis joined
Paul_the_Greek dukeleto: $i0 = 1e20 sets the register to the minimum integer. That doesn't seem right. 22:39
cotto_work I can't think of anything smaller than 1e20. 22:40
Paul_the_Greek Huh? 22:41
1e20 - 1 ? 22:42
cotto_work Woah. 22:44
Paul_the_Greek Horses about? 22:46
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.
I think we should throw an exception.
Coke msg chromatic - how does r48878 get any improvement?
purl Message for chromatic stored.
aloha OK. I'll deliver the message.
Paul_the_Greek "Unable to convert real to integer." 22:52
Or else specify that they are undefined.
dukeleto Paul_the_Greek: hmmm
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.
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.
Let me check ...
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.
NotFound A $Id in nci_thun_gen.pir
dukeleto Paul_the_Greek: in C, floor() and ceil() are defined to return +-MAXINT if the values are too big 22:55
Paul_the_Greek: iirc, ansi89 says that, or some relative of it
Paul_the_Greek Ah, okay, but they are undefined for Inf and NaN.
Let me check that ...
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
Paul_the_Greek: where % is the modulus operator
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
Paul_the_Greek: maybe i am thinking of the cmod function
Paul_the_Greek Let's see what it says about assignment conversion ...
"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
Paul_the_Greek So we leave it undefined or we throw an exception. I would not start defining all these conversion combinations. 22:59
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);
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?
Paul_the_Greek Undefined result. 23:02
I'll find the correct place to document this.
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.
That's what we mean by "undefined result." 23:04
I will word it as "the result is an arbitrary integer" or something like that.
Making sure not to imply that we have some special integer that indicates "undefined." 23:05
dalek rrot-linear-algebra: a1189e5 | Whiteknight++ | t/harness:
uncomment extra directories and run all tests. All tests pass
rrot-linear-algebra: 06e853d | Whiteknight++ | .gitignore:
add generated html files to .gitignore
dukeleto whiteknight++ # getting all your tests passing 23:06
whiteknight dukeleto: and there are a LOT of tests in PLA now 23:07
I don't know if you've played with it lately, but it's getting to be quite an impressive little library
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.
dukeleto whiteknight: it would be interested to benchmark PLA vs Math::MatrixReal from perl 5 23:09
s/interested/interesting/
whiteknight dukeleto: yes, that would be nice. I bet the perl5 version would win just because of Parrot method call overhead
though if you stuck to vtable calls, it would probably be quite competitive
dukeleto cotto_work: yeah, it takes a special kind of nerd to get excited about linear algebra. i am one of those nerds :)
whiteknight: you don't know unless you benchmark it :) 23:10
whiteknight: PLA's memory footprint is probably better, but who knows
cotto_work and a special type of nerd to get excited about Parrot, so the intersection is special indeed
dukeleto cotto_work: mmmm, venn diagrams, ....
tcurtis mmmm, set operations, .... 23:11
cotto_work mmmm. nerds. 23:13
dukeleto whiteknight: now that PLA is passing it's test suite, does that mean you will be hacking on matrixy now? 23:14
plobsing: does your recent commit help with this TT? 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
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.
but if and when it becomes available, it will most likely be accessible via op_info
dukeleto plobsing: so it helps in the journey. that is good to hear 23:19
whiteknight: have you thought of making PLA come with Kakapo? 23:22
whiteknight: i compiled pla successfully on 64bit linux, let's see if I can run your tests 23:23
whiteknight: the debian packages you list in the README seemed to have changed names 23:26
whiteknight: you could just ship a kakapo pbc file, it looks like. 23:28
wow. kakapo has a lot of stuff 23:33
whiteknight: gist.github.com/572779 <-- kakapo seems to be blowing up on the PLA test suite, for me 23:36
whiteknight: that is with parrot r48772
whiteknight: when i run kakapo's test suite, it runs 0 files. that seems funky 23:37
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.
aloha OK. I'll deliver the message.
dukeleto www.bioperl.org/wiki/Using_Git <-- useful guide to crimp from for the parrot git docs 23:41
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.
aloha OK. I'll deliver the message.
Paul_the_Greek Coke: It has to match slash and also the local directory separator.
I'm sure you can do that in one regex, but I couldn't figure out how. 23:43
Coke Paul_the_Greek: it was matching the local directory separator. you added a hardcoded forward slash. 23:46
so presumably, you (on windows!) needed the hardcoded forward slash. yes?
Paul_the_Greek The idea was that forward slash always works, and then the local separator also works. 23:47
They may be the same, or not.
Coke but the local separator DID NOT work for you. yes?
in the case where local separator was \\
Paul_the_Greek On Windows, both / and \\ work.
Coke then how were you getting the failure on \\ ? 23:48
scratch that.
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?
Paul_the_Greek In case a path with \\ shows up in the headerizer. 23:50
on Windows.
Coke ... but you just said it's using /
Paul_the_Greek makefile is using /. I could invoke the headerizer directly.
Or, in the future, configure could generate a makefile with \\. 23:51
Coke no, it won't
Paul_the_Greek Since both / and \\ work, shouldn't the headerizer handle that?
It's not an efficiency issue or anything.
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.)
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.
Paul_the_Greek So you're saying we should just ignore config(slash)?
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?
Coke technical debt? 23:54
purl technical debt is the debt you build up of stuff you have to do later. c2.com/cgi/wiki?TechnicalDebt or www.media-landscape.com/yapc/2006-0...ndyLester/
Paul_the_Greek I'm not sure why it is, but I'm not trying to make some big case here.
We all just figured both separators should work. 23:55
I'm happy to remove the use of config(slash). 23:56
Coke no, you gave a perfectly good reason to need it. 23:57
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
also, note the one-character smaller regexp.
Paul_the_Greek The slash configuration item is used in four *.pl files. 23:59
Let me check ...

Powered by Cro and the Raku® Programming Language.

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

Thank you!