% Andy has left Andy!~Andy@64.122.195.246 % barney has joined #parrot % cosimo has joined #parrot % iblechbot has joined #parrot % timbunce has joined #parrot % clunker3 has left clunker3!~IRC@procura.xs4all.nl % Casan has joined #parrot r29643 | fperrad++ | trunk: : [Lua] % tuxdna has left tuxdna!~tuxdna@122.163.235.239 : - add lua_is* (needed by GL/GLUT) diff: http://www.parrotvm.org/svn/parrot/revision?rev=29643 % tuxdna has joined #parrot % masak has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 r29644 | fperrad++ | trunk: : [Lua] OpenGL : - start implementation of few methods diff: http://www.parrotvm.org/svn/parrot/revision?rev=29644 % timbunce has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 r29645 | bernhard++ | trunk: : [urm] Use $FindBin::Bin instead of $FindBin::RealBin diff: http://www.parrotvm.org/svn/parrot/revision?rev=29645 % bacek has left bacek!~bacek@mcas-151.usr.optusnet.com.au % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % uniejo has left uniejo!~uniejo@193.88.64.250 r29646 | moritz++ | trunk: : [lua] codingstd: make file_metadata.t happy diff: http://www.parrotvm.org/svn/parrot/revision?rev=29646 % uniejo has joined #parrot r29647 | moritz++ | trunk: : [rakudo] add S04-statements/return.t to spectest_regression, Auzon++ : +12 pass, +2 skip diff: http://www.parrotvm.org/svn/parrot/revision?rev=29647 % Debolaz has joined #parrot % zostay has left zostay!~Hanenkamp@adsl-75-39-134-250.dsl.tpkaks.sbcglobal.net % zostay has joined #parrot % Ademan has left Ademan!~dan@h-68-164-170-6.snfccasy.dynamic.covad.net % Ademan has joined #parrot r29648 | moritz++ | trunk: : [rakudo] add S04-statements/given.t to spectest_regression. Auzon++ diff: http://www.parrotvm.org/svn/parrot/revision?rev=29648 % barney has left barney!~bernhard@p549A3B42.dip0.t-ipconnect.de % AndyA has left AndyA!~andy@ca93nt.hexten.net % AndyA has joined #parrot % Whiteknight has joined #parrot % barney has joined #parrot % iblechbot has left iblechbot!~iblechbot@ppp-62-216-196-51.dynamic.mnet-online.de % ruoso has joined #parrot r29649 | bernhard++ | trunk: : [Pipp PCT] Check the maximal number of digits in hex and octal escape sequences. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29649 % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % iblechbot has joined #parrot r29650 | infinoid++ | pdd13pbc: : [PDD13] : * Fix inheritance, so that subclasses of PackfileSegment can use the : .pack() method. : * Fix .pack, it seems sometimes Packfile_Segment_pack() doesn't return : the same number of bytes PackFile_Segment_packed_size() said it would. : * Consolidate some PIR test code into a common string. : * Fix the get_directory() test to use the "typeof" op. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29650 r29651 | infinoid++ | pdd13pbc: : [PDD13] : Remove some useless pack() and unpack() stubs, the parent class handles : those. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29651 % contingencyplan has joined #parrot % dngor has left dngor!abuse@adsl-068-213-211-142.sip.bct.bellsouth.net % Ademan has left Ademan!~dan@h-68-167-206-26.snfccasy.dynamic.covad.net r29652 | infinoid++ | pdd13pbc: : [PDD13] : * Implement the following PackfileDirectory methods: : - elements : - get_pmc_keyed_int : - get_string_keyed_int : * Test basic enumeration of PBC segments from PIR. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29652 % gryphon__ has joined #parrot % Ademan has joined #parrot r29653 | infinoid++ | pdd13pbc: : [PDD13] : * Remove an unused variable. : * If the index is out of bounds, raise an exception, don't just return PMCNULL. This : fixes the following warning: : ./src/pmc/packfiledirectory.pmc:102: warning: return from incompatible pointer type diff: http://www.parrotvm.org/svn/parrot/revision?rev=29653 jonathan: is it valid to wrap a PackfileAnnotations object around a PackFile_Debug struct (from a PF_DEBUG_SEG segment), or are they completely incompatible? the pdd says "This is new and replaces and builds upon the debug segment". If they're really all that different, I'm wondering if its worth bothering to wrap the old stuff and then converting to the new format, or just implement the new one from scratch % donaldh has joined #parrot Infinoid: I'd just implement the new one. But that is a bit of work. ok, thanks. For now, I'll just return PackfileRawSegments for debug segments, and basically ignore them That sounds like a good interim solution. % uniejo has left uniejo!~uniejo@193.88.64.250 % uniejo has joined #parrot % uniejo has left uniejo!~uniejo@193.88.64.250 % jhorwitz has joined #parrot How do parrot and rakudo types interoperate? If I construct a SQL ResultSet using parrot types, what does it look like to rakudo? for example. % Andy has joined #parrot * donaldh is trying to decide how much lifting to do in PIR versus perl6 donaldh: I think it only looks like anything from p6 if you register it with P6Meta but the cross-HLL isn't done yet, mostly moritz: that's what confuses me. intproto defines a new Int class that has Integer and Any as parents. moritz: is Integer the parrot type? donaldh: dunno, I'm just picking up random stuff that scrolls down before my eyes ;-) * donaldh is wondering if he constructs a list of Integers in parrot, will he get p6 Ints when he is running within Rakudo why don't you just try it with a small sample? * donaldh is just about to ;-) * donaldh needs to invoke a few satanic verses to export the functions into the p6 namespace first. donaldh: actually, all perl6 stuff works better with angelic invocations :) masak: that's where I've been going wrong ;-) clearly. :) % paco has joined #parrot % tuxdna has left tuxdna!~tuxdna@122.163.235.239 % barney has left barney!~bernhard@p549A3B42.dip0.t-ipconnect.de if(SELF.does("satanic")) real_exception(interp, NULL, E_ImportError, "invocant from wrong plane of existence"); :D * donaldh has his answer If I allocate and return a new Integer in parrot, then int_val().WHAT returns 'Int' i.e. the p6 type. cool. So I can write pir to convert a SQL result set into parrot types and perl6 code will get p6 types. yay. I have no idea how this would work in a multi-HLL world. I suppose each HLL should just convert it to whatever integer type it's comfortable with (but I know nothing about the HLLs) It appears to work because rakudo has the last say on what prototype is registered for Integer. but ... does it change the actual data type, or just wrap it somehow? Infinoid: I have no idea. (I'm just curious, if your p6 code then passes that value to tcl, would tcl see an Integer, or an Int) I think tcl would see an Int. But the Int isa Integer "donaldh" at 144.254.89.228 pasted "the Int prototype" (9 lines) at http://nopaste.snit.ch/13628 % Andy has left Andy!~Andy@64.122.195.246 But if tcl expects its own integer type then it will be disappointed. % _shane_ has left _shane_!shane@hick.org % Debolaz has left Debolaz!~root@195.159.114.206 % Casan has left Casan!~casan@users163.kollegienet.dk % apeiron has joined #parrot r29654 | moritz++ | trunk: : [rakudo] fiddled with spectest_regression: : - added S12-class/inheritance-class-methods.t, masak++ : - fixed typo in name of S12-class/anonymous.t, jonathan++ for implementing diff: http://www.parrotvm.org/svn/parrot/revision?rev=29654 donaldh: i believe HLL type mapping is supposed to handle the type conversion for each HLL. but that's not in place yet. not sure if/how it handles objects though jhorwitz: okay, so type conversion will be needed. I was guessing tthis would be the case. Avoiding conversion would be nice, but then we'd have to standardize a lot of the basic types. depends what you need to do. for mod_parrot, i'm happy to let rakudo stringify Perl6Strs so i can assign them to string registers. I'm guessing the problem isn't the value itself, but the methods wrapped around it yeah % MagNET has left MagNET!~MagNET@213.163.11.138 pmichaud, jonathan, and probably DietCoke can explain the type issues better than i can. r29655 | moritz++ | trunk: : [rakudo] whitespace fixes in spectest_regression.data diff: http://www.parrotvm.org/svn/parrot/revision?rev=29655 It looks like rakudo replaces the parrot types with its own derived versions. So constructing a ResizablePMCArray of Strings will give me a List of Strs in perl6 it replaces only the names, right? % DietCoke has joined #parrot * DietCoke reviews. reviews are hard since you have to read with a different eye than just for learning. or not written by yowling racists at all. yes, it replaces the binding for ResizablePMCArray so that it is now implemented with a List (isa ResizablePMCArray) The plan for HLL_map was for mapping between parrot types and a single HLL; I don't think there's a plan for intra-HLL mappings. that has always been a concern of mine. parrot *should* be able to handle the simple cases though. i wonder about arrays and hashes... if I define a subroutine in tcl, and you invoke with a Perl6Str that doesn't work the way I expect... am I going to have to convert everything to string and then to TclString for it to work? jhorwitz: define "simple case". even integers don't work the same. er, Integers. * donaldh has opened a can of worms it needed opening. really. * jhorwitz realizes there are no simple cases now. :( sometimes i think we should rename parrot to pandora particle1++ % particle1 is now known as particle Back when I was doing more HLL work on partcl, I tried to bring this up many time (I wasn't able to answer the questions myself at the time.) But I stopped working on partcl for some time, and there wasn't a lot of multi-HLL work at the time. as i recall, dan left it as a hll implementor's problem which is, IMO, a recipe for failure. Are HLLs all building their own types? * jhorwitz wants the teachers edition so he can see the answers. (unless all the HLL implementors agree.) and doesn't really reflect our current design philosophy, I think donaldh: many are, yah. well, now that we have 4 or 5 pretty strong (but incomplete) implementations, we can probably get some kind of agreement on how we want parrot to handle this. % Andy has joined #parrot If teh types are _really different_ then we have a problem. But if the HLLs are just additive then they should all be able to extend the same prototypes. I vote that we standardize on lolcode's types. donaldh: not everyone agrees how things like division on ints or increment on strings should work, e.g. Sure. But Perl6::increment can be separated from Tcl::increment. donaldh: they are. As long as the storage is portable. donaldh: that would require a complete re-thunk of PMCs, I fear. my $i = eval('1', :lang); $i++; Is that Tcl::increment or Perl6::increment? karma $i $i has karma of 280 karma $foo $foo has karma of 49 karma donaldh donaldh has karma of 1 karma i i has karma of 73 donaldh++ thanks my Int :lang $i = eval('1', :lang); would make things more clear $i++ much more frequent than i++? wow So, basically, there isn't a fully developed plan on how this is going to work out between HLLs. karma c++ c++ has karma of -81 karma c c has karma of 7026 solving it for PCT will work for many languages, but not all. DietCoke: I was getting that impression ;-) the problem is letting HLLs diverge with their own prototypes. If they could share prototypes it would be easier. but can they? Do you mean, if everyone used "Integer" instead of creating their own HLL type? I think so. That still doesn't answer the question about what if perl6 creates its own, in-language restricted integer type and passes that to another HLL. And perl6 could extend the Integer prototype, as could Tcl, etc. but if the spec says it should be called "Int"? donaldh: they're both doing that now. TclInt isa Integer, e.g. % magnachef has joined #parrot Yes, but TclInt isa Int == false there is no Int. perl6 Int ? ah. Int isa Integer too, innit? yep. ... so we're already doing that, then, aren't we? Circle isa Shape. Square isa Shape. Circle is not a Square. ... so you want Tcl to use Perl6 Int's? no. I read what you started with as starting with the same base type. (which we are. it's just a parrot type instead of an HLL type) I'm wondering if it's a Perl6TclInt when I use both HLLs. no. it's one or the other. can't it be TclInt in tcl and Perl6Int in Perl 6? ... "how"? Without conversion? ... meaning the HLLs wrap their own classes around the base type, on the fly? by magic hllmap tables? Infinoid: yes so whenever you'd call into another HLL's function, parrot would convert the types? it would have to map through parrot's core types. So a Perl6Int would get downconverted to either an Integer or an int, and then promoted up to a TclInt. it would convert to the native parrot type (Integer, or whatever it's called), and the HLL auto-wraps it? you'd need pir-level subroutines to have strong prototypes, and conversion functions called as needed I wouldn't expect the HLL to do anything. I'd expect it to be handled by parrot. and parrot would try to find a conversion function from the main type, and then try the base type(s) if that fails Or else we're going to write an insane amount of scaffolding. * Infinoid starts having nightmares about haskell This is what is confusing me. I want to do the lifting for converting a SQL ResultSet to parrot types in PIR so that the implementation can be shared by many HLLs. yes, that would be spiffy. =-) You can't do that today, SFAIK. It seems to work for any one HLL at a time because perl6 substitutes its own types for the parrot types. I'd assume that Tcl does the same. I mean, you can use the standard parrot types, sure. my $a = eval 'class ZOMGLOL; def foo(n) puts n ; end ; end', :lang; erm.. instantiate at the end of that. no, Perl6 is doing something on its own that isn't done by anyone not using PCT. okay, DietCoke. whoops. hehe DietCoke: that's where I started. If I create a ResizablePMCArray of Integers in PIR then I get a List of Ints in perl6. purl: Perl6? i guess Perl6 is doing something on its own that isn't done by anyone not using PCT. purl: Perl 6? Perl 6 is the spec, rakudo and pugs are two of the implementations. purl: Perl6 is see Perl 6 ...but perl6 is doing something on its own that isn't done by anyone not using PCT.... purl: no, Perl6 is see Perl 6 okay, moritz. moritz: that works in private messages. DietCoke: ok sorry donaldh: Ok. Pretty sure that doesn't work in tcl. Nor in anything that isn't using the Perl6Object stuff. (which is anyone not using PCT). Ah, okay. Targetting PCT is not a terrible thing, but it does mean you're leaving out a class of implementations. (or they'll work differently) the lowest common denominator is parrot base pmc types so if I get an RPA of Integers back, and I try, say, to stringify it, I'll get something very different than if it were a TclList us ethose well, he is. So that's ok. Except that in Tcl you could use Tcl::stringify but it doesn't mean it'll JFW in every HLL like it does in Perl6. donaldh: except that completes defeats the purpose of having PMCs. right, but every hll will need to deal with them "completely" "completely" is relative. DietCoke: agreed. so I'm not really going to go down that path. I suspect we're going to have to amend the calling conventions to say whether or not we wish the HLL conversion to happen. (or passthrough unchanged) and then make parrot do all the hard work for us. yes. (though really, tcl would always convert. Which makes me wonder if anyone else would not just always convert.) DietCoke: perl6 wouldn't necessarily, I think. You can use different storage for objects of the same class, so it doesn't have to % MagNET has joined #parrot I'm not sure it's such a good idea to convert anything at all automatically. We'd have unpredictable behavior. If I'm using cardinal, and I get an object produced by rakudo, it will have Perl's methods, unless it happens to be an object that has a parrot core representation? sounds scary % Theory has joined #parrot Where is the boundary, exactly, and what are the reasons for placing it there? For rakudo, do we convert from subset types, for example? What if we mixed a role into the object? Maybe HLLs just need to accept parrot base types. again, that's the lcd. So Tcl sees perl6 datastructures downgraded to parrot types. particle: yes. What about objects of user-made classes? If I get a Hash, it's converted, but not a Point? (Not that that would make any sense) sometimes there is no Point ;-) What about: class Magic { extends Int } ? 1) every hll must be able to convert to/from base pmc types If I make a custom class extending a class which would be converted? Will that be converted too? particle: hell no! that's what .HLL_map is for. I don't want to have to write code for that... 2) parrot has a defined mechanism to allow intra-hll conversions Isn't 1) what the HLL mapping is supposed to take care of? Or just 1)a? dietcoke: yes, that's what .HLL_map does Tene: I think it needs to be configurable, somehow. You as a programmer have to be able to decide if you'll get a Int:lang(tcl) or an Int out of a library call moritz: Right, type declaration on the variable you're assigning to. if 1 and 2 are satisfied, parrot's job is done. interop for easy things happens automatically and more complex things are possible as runtime libraries particle: That sounds very handwavy to me. =-) what's simple? what's complex? how do the conversions happen? when do they happen? % grim_fandango has joined #parrot particle: explain what 2) might look like. freeze/thaw? freeze/thaw are the Format particle: that's what .HLL_map -should- do, but yes. =-) particle: explain what you mean by intra-hll conversions. Tene: don't know if that's the way to go. It would imply that Int:lang(tcl).isa(Int) % masak has left masak!~user@130.238.45.242 Tene: and I doubt that's compatible with linkovsky substitutability, or whatever it's called some wrapper around thaw that allows you to specify the language and translates the impedance mismatches *liskov particle: so each HLL will need to specify a conversion function for every type it cares about from every other HLL? convert_int_from_lolcode_to_perl6 ? yes, or call a runtime library particle: that is insanely evil. and I think it's a bad idea. how many languages do you plan parrot to support? how many HLL types per language? parrot only needs to provide an api it doesn't have to do everything, and it can't ... then there's no point in my working on partcl any more. =-) parrot will make hll interop possible... this we've promised 1) If your language's numberish thing isa Num, shouldn't parrot be able to take care of assigning it to something else that isa Num in the same way we can go from Float to Int or the other way? particle: yes, but so far every plan I've heard will make it possible in a very unhelpful way. parrot 1.0 needs to make it possible. parrot 2.0 can make it easy. 2) If your language's number isn't an ancestor of Num or whatever, wouldn't there be a reason behind that and type mismatch errors would be the proper behavior if you tried to convert to an Int? particle: you really need to write down these 1.0/2.0 guidelines because I don't agree with many of them, and when you say them, they sound final. even if it's something that you and allison or others have agreed is a good idea (and they're not just you), it needs to be written down. is .HLL_map documented anywhere other than pdd19_pir.pod ? no, i haven't talked to anyone about it % jjore2 has left jjore2!~jjore@mail0.w3data.com and i'm not the architect but we need to keep our scope small to get parrot 1.0 out and we *need* to get parrot 1.0 out soon % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net yes, that would be lovely. hll interop is largely unaddressed and unsolved Reading pdd19, it seems that .HLL_map only covers mapping from c code to the current HLL. % Casan has joined #parrot particle: yes. and it's supposed to be one of our -core- features. yet there's no pdd yes. So let's first get the .HLL stuff *working* in PCT and get the various languages using it. and it's not a major milestone in the nlnet grant tene: s/in PCT/, but yes. so, that's a problem what, that we're not getting paid for it? DietCoke: is it not working at all right now? tene: parts of it are working. Since it is not well spec'd or tested, it's hard to say for sure. I'll work on investigating that tonight. there's at least one part that's broken (and an RT for it.) #? tene++ particle: I'm not getting any money from nlnet anyway, so that's not a problem for me. :) DietCoke: can we schedule some teleconference time with you if needed during oscon/post-oscon hackathon to discuss issues like this? tene: http://rt.perl.org/rt3/Ticket/Display.html?id=56958 We can try, sure. i'll keep it in mind I can't make any promises on my schedule atm. sure, same here :) i'm kinda sick of conferences atm, and not looking forward to oscon :( i'd rather be home enjoying my new deck, which i finished saturday aside from "not being able to attend oscon"; (I was lucky to be able to afford yapc). I will definitely promise to comment on any docs generated as a result of the discussion there. particle: enjoy your deck. I built mine and the rain started. I'm still waiting for weather to enjoy it. thanks :) i have until october before the rains start here Going back to PMCs, it seems to me that PMCs are being used to implement different types while supporting conversion between types. They're also being used to implement the same types in different languages. Is it necessary to use them for the second case? pmcs are an abstract datatype they allow you to create your own data types, and they provide a defined method of access Yes, but we seem to be taking about a divergence of how Integer or String might be implemented in different HLLs at the PMC level. Integer is something different in different languages, so that makes sense some autopromote some are fixed at 32bit perl 5 doesn't even have Integer or String it has Scalar Hmmm. tcl's ints don't autopromote to float on division, e.g. Some conversions between languages don't make sense. E.g if I create a MagicObject in perl6 it might just need to be opaque in Tcl, as long as I could use it as a parameter in another perl6 functon. Yup. And how do we declare which vars we're passing in are opaque, which are translated? How do we declare in the function sig which should be Integers, which should be opaque... all very good questions. yup. I would be most pleased if someone started keep track of these, say, on the wiki. =-) Well I opened the can of worms, so I could have a go at summarizing this discussion. donaldh++ karma donaldh donaldh has karma of 3 yay! you won't be able to tripple it again so easily ;-) does purl bump self promoters? not bump, but ignore I think and /msg'es them very wise purl++ % ruoso has left ruoso!~ruoso@201.45.49.162 % donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com % Theory has joined #parrot % DietCoke has left DietCoke!~coke@cpe-72-228-52-192.nycap.res.rr.com % parrot-poke has joined #parrot % Theory has left Theory!~Theory@ip131.fa1-0-1.occ.iinet.com % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % ruoso has joined #parrot % dngor has joined #parrot % Theory has joined #parrot % cotto_work has joined #parrot % Andy has joined #parrot % rurban has joined #parrot % ewilhelm has left #parrot Anyone has an idea how make install will work somewhen? how to replace builddir with the prefix in the pbc's? % timbunce has joined #parrot let's have a "How you can get started in Rakudo/Parrot" BOF % purl has left purl!~purl@florence.kuiki.net % purl has joined #parrot % purl has left purl!~purl@florence.kuiki.net % Ivatar has joined #parrot % confound has left confound!hdp@floe.aq rurban: Sometimes #parrot is a bit quiet, yes. Ok, I'll just do it for the cygwin package somehow. But don't complain then. % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % Theory has left Theory!~Theory@ip131.fa1-0-1.occ.iinet.com How is it planned to change the lib_path in the installed library? with PARROT_PLATFORM_LIB_PATH_INIT_HOOK? I want to get rid of the unneeded runtime paths % purl has joined #parrot % donaldh has joined #parrot rurban: If #parrot is quiet, your best option is to send a mail to the parrot mailing list. Should be perl6-internals@perl.org, maybe? nada ditto I'm more and more bleieving the whole runtime system is borked. Search paths are handled by Parrot_get_runtime_prefix (config prefix) plus the hardcodded lib_path, which starts with runtime which is non-FHS compliant /usr/runtime/parrot will never be accepted So somehow when installing the lib_path AND prefix must be switched from the build paths to the final paths. Since we have fixed pbc's with hardcoded paths, those have to be recompiled. and worst, lib_path is hardcoded in the shared lib, which means this has to be recompiled also So why messing around with runtime/parrot at all? and don't use lib/parrot as it should be have done from the very beginning on. rurban: I'm guessing that's because of the broken IMHO design of top-level lib belonging to the build process, a Perl 5-ism that I hate. well, moving all the runtime/* dirs below lib/ would be fine e.g. or favor /usr/lib/parrot over /usr/runtime/parrot I hate stat to non-existing dirs at runtime is not tommorrow the next design meeting? If it happens once it's not so bad. If it happens more than once, that's bad. yes well, it normally would be, except it's cancelled for this week ... OSCON So 8 days until next design meeting you have to see my strace stat calls of all the useless dir lib_path traversal Ah OSCON! That's why. I believe you ... it's a side effect of too much encapsulation. I'll patch library.c so my liking and see how far I'll get. nod Great plan. :) % pac1 has joined #parrot just did. Intersting is that the strategy for seperating build time from installed config works perfect for the utils, this includes either parrot_config.o or install_config.o but for the pbc but for pbc's i must have overlooked something simple % pac1 has left #parrot A similar trick to the installable_ targets Ok, got it. pbc_to_exe either links in src/parrot_config.o or with a new switch --install the other src/install_config.o. Then the resulting .exe should be named installable_$exe installable_perl6 -v now runs into Can't read '/usr/runtime/parrot/include/config.fpmc': No such file or directory good % Theory has joined #parrot % Andy has joined #parrot % davidfetter has joined #parrot % rafl has joined #parrot % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % Andy has joined #parrot % teknomunk has joined #parrot got it. pbc_to_exe now accepts infile --install. if --install links to install_config.o and prefixes the exe with installable_ % rurban_ has joined #parrot % rurban has left rurban!~chatzilla@212-183-58-219.adsl.highway.telekom.at % rurban_ is now known as rurban % ruoso has left ruoso!~ruoso@201.45.49.162 % ruoso has joined #parrot % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 donald@sealgair.com | Parrot: link: http://www.perlfoundation.org/parrot/index.cgi?parrot % paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net % Whiteknight has joined #parrot % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % Andy has joined #parrot r29656 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] update to trunk r29655 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29656 % iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-182.dynamic.mnet-online.de % rurban has left #parrot Whiteknight++ gsoc_pdd09 branch building, and mostly even passes tests % ruoso has left ruoso!~ruoso@201.45.49.162 if all tests were passing i'd be suspicious ;-) donald@sealgair.com | Intra-HLL Mapping Notes: link: http://www.perlfoundation.org/parrot/index.cgi?intra_hll_mapping_notes r29657 | coke++ | trunk: : [tcl] Improve the state of fudged tests for the spec test. : * eliminate the 'parsed but failing' category of tests. We can manage all : that through lib/skipped_tests.tcl, and it doesn't need to be in the Makefile : * Still a few that take forever or blow up. : * Removing old [vwait] implementation that seems to hang, leaving a simple : version that just does args checking for now. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29657 % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % donaldh has left donaldh!~chatzilla@host213-123-171-12.in-addr.btopenworld.com % Theory has left Theory!~Theory@ip131.fa1-0-1.occ.iinet.com % Andy has joined #parrot r29658 | coke++ | trunk: : [tcl] docu-clean up diff: http://www.parrotvm.org/svn/parrot/revision?rev=29658 % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % Ivatar has left Ivatar!~graham@tu055.demon.co.uk % teknomunk_ has joined #parrot % Andy has joined #parrot % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % cj has left cj!~cjac@66.152.65.2 % Theory has joined #parrot % gryphon__ has left gryphon__!~gryphon@dsl-209-221-185-54.zipcon.net % cj has joined #parrot % TiMBuS has joined #parrot thanks moritz, I've been working hard on it % slavorgn has left slavorgn!infinoid@omgwtfbbq.info % hachi has left hachi!hachi@cpan.org % hachi has joined #parrot r29659 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] small codingstd fix diff: http://www.parrotvm.org/svn/parrot/revision?rev=29659 % Limbic_Region has joined #parrot % hachi has left hachi!~hachi@shego.kuiki.net % hachi has joined #parrot % slavorgn has joined #parrot % Sartak has left #parrot % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % teknomunk__ has joined #parrot % teknomunk_ has left teknomunk_!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % cout has left cout!~cout@c-68-58-247-49.hsd1.sc.comcast.net % bacek has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 particle: ping % Coleoid is now known as Coleoid_afk % Andy has joined #parrot % AndyA has left AndyA!~andy@ca93nt.hexten.net % dngor_ has joined #parrot % dngor_ has left dngor_!abuse@adsl-068-213-211-142.sip.bct.bellsouth.net % Theory has left Theory!~Theory@ip131.fa1-0-1.occ.iinet.com % AndyA has joined #parrot % timbunce has joined #parrot % ruoso has joined #parrot % Theory has joined #parrot % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net % kid51 has joined #parrot % Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net % Casan has left Casan!~casan@users163.kollegienet.dk r29660 | jkeenan++ | trunk: : Merge revisionpm branch into trunk. Cf.: : http://rt.perl.org/rt3/Ticket/Display.html?id=56948. Refactor : Parrot::Revision and add tests, including one new test file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29660 r29661 | jkeenan++ | trunk: : Revert to previous version due to unintentional commit of several lines. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29661 r29662 | jkeenan++ | revisionpm: : Branch has been merged into trunk and is no longer needed at head. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29662 r29663 | jkeenan++ | revisionpm-29566: : Branch to which tag corresponded has been deleted, so tag may go as well. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29663 % Andy has left Andy!~Andy@ip131.fa1-0-1.occ.iinet.com % parrot-poke has left parrot-poke!~mollusk@user-112vvlr.biz.mindspring.com % cout has joined #parrot r29664 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] Fixes to implementation: : * Added long-missing support for GC_trace_normal and GC_trace_stack_FLAG : * Re-added trace_system_areas() into Parrot_dod_trace_root() diff: http://www.parrotvm.org/svn/parrot/revision?rev=29664 % Coleoid has joined #parrot % Coleoid_afk has left Coleoid_afk!~Coleoid@adsl-75-62-112-74.dsl.bltnin.sbcglobal.net % Coleoid is now known as Coleoid_afk r29665 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] Make GC_finish_FLAG consistent with the other flags. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29665 % teknomunk__ has left teknomunk__!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % gmansi has left gmansi!~gmansi@190.55.35.246 r29666 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] Improve flag logic to account for flag interdependencies diff: http://www.parrotvm.org/svn/parrot/revision?rev=29666 % gmansi has joined #parrot % Andy has joined #parrot % kid51 has left kid51!~jkeen@pool-68-237-6-190.ny325.east.verizon.net % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % Psyche^ has joined #parrot % Patterner has left Patterner!~Psyche@e177228191.adsl.alicedsl.de % Psyche^ is now known as Patterner % timbunce has left timbunce!~timbo@ip131.fa1-0-1.occ.iinet.com % Andy has left Andy!~Andy@069-064-236-003.pdx.net % Andy has joined #parrot % Andy has left Andy!~Andy@069-064-236-003.pdx.net % timbunce has joined #parrot % Theory has joined #parrot purl: coke? rumour has it coke is mailto:will@coleda.com or just a figurehead. or http://coke-floats.blogspot.com/ or DietCoke or a pest % Psyche^ has joined #parrot % grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167932545.dsl.bell.ca % Patterner has left Patterner!~Psyche@e177233011.adsl.alicedsl.de % Psyche^ is now known as Patterner I kinda fixed Coke's hll map problem. OK, Tene, drop the other shoe ... % timbunce has left timbunce!~timbo@12.157.240.2 r29667 | japhb++ | trunk: : Merge branch 'benchmarks' diff: http://www.parrotvm.org/svn/parrot/revision?rev=29667 tewk, chromatic: Not only does it seem to work (well at least, not explode) to treat a ManagedStruct with named members as an array, it seems to be the fastest way to fill at least a small ManagedStruct. See examples/benchmarks/float4.pir % timbunce has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 % timbunce has joined #parrot % Ademan has left Ademan!~dan@h-67-101-43-205.snfccasy.dynamic.covad.net % uniejo has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 % Ademan has joined #parrot % timbunce has joined #parrot % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net % tewk has left tewk!~tewk@ekstrom.org % tewk has joined #parrot % timbunce has left timbunce!~timbo@12.157.240.2 % apple-gunkies has left apple-gunkies!~chatzilla@tx-71-1-49-73.dyn.embarqhsd.net % barney has joined #parrot