"Parrot 0.6.4 "St. Vincent Amazon" Released | parrotcode.org/ | 15/648/80 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today".
Set by moderator on 15 July 2008.
00:07 timbunce joined 00:10 AndyA joined 00:21 vhold joined 00:27 Theory joined 00:30 Limbic_Region joined 00:50 Ademan joined 00:55 Psyche^ joined
dalek r29637 | Whiteknight++ | gsoc_pdd09: 01:09
: [gsoc_pdd09] coding standards: fix macro arguments to use parenthesis properly
diff: www.parrotvm.org/svn/parrot/revision?rev=29637
01:41 kid51 joined
dalek r29638 | jkeenan++ | parallel: 01:42
: Add tests for existence of files prerequisite to gen::config_h's operation. Add POD.
diff: www.parrotvm.org/svn/parrot/revision?rev=29638
r29639 | jkeenan++ | parallel: 02:03
: gen_config_h: Delete unneeded sub import.
: gen_core_pmcs: Test that the prerequisite parts of the Parrot::Configure
: object can be located.
diff: www.parrotvm.org/svn/parrot/revision?rev=29639
r29640 | jkeenan++ | parallel: 02:05
: Correct spelling error in test description.
diff: www.parrotvm.org/svn/parrot/revision?rev=29640
r29641 | jkeenan++ | parallel: 02:18
: config/gen/crypto.pm: Pull hard-coded %digest into step's data structure (as
: done for other config steps). Some typographic reformatting. Write first
: tests for gen::crypto; so far, the case where crypto is unavailable.
diff: www.parrotvm.org/svn/parrot/revision?rev=29641
r29642 | jkeenan++ | parallel: 02:32
: Correct syntax error.
diff: www.parrotvm.org/svn/parrot/revision?rev=29642
02:41 TiMBuS joined 03:11 apple-gunkies joined 03:20 teknomunk joined 03:22 daxelrod joined 03:39 buildbot joined
ewilhelm parrotcode.org says nothing about sat hackathon? 04:37
04:52 teknomunk joined 05:09 Andy joined 05:19 Psyche^ joined, purl joined 05:30 purl joined 05:35 purl joined 05:54 uniejo joined 06:00 uniejo joined 06:11 Theory joined
cotto_home dino? 06:31
purl, dino?
purl cotto_home: i don't know
cotto_home that's not very helpful
purl I'm only as helpful as the hyoomuns programming me, cotto_home
06:32 tuxdna joined 06:50 Ademan joined 07:12 barney joined 07:30 cosimo joined 07:31 iblechbot joined 07:38 timbunce joined 07:52 Casan joined
dalek r29643 | fperrad++ | trunk: 08:06
: [Lua]
: - add lua_is* (needed by GL/GLUT)
diff: www.parrotvm.org/svn/parrot/revision?rev=29643
08:06 tuxdna joined, masak joined
dalek r29644 | fperrad++ | trunk: 08:09
: [Lua] OpenGL
: - start implementation of few methods
diff: www.parrotvm.org/svn/parrot/revision?rev=29644
08:09 timbunce joined
dalek r29645 | bernhard++ | trunk: 08:21
: [urm] Use $FindBin::Bin instead of $FindBin::RealBin
diff: www.parrotvm.org/svn/parrot/revision?rev=29645
r29646 | moritz++ | trunk: 09:17
: [lua] codingstd: make file_metadata.t happy
diff: www.parrotvm.org/svn/parrot/revision?rev=29646
09:20 uniejo joined
dalek r29647 | moritz++ | trunk: 09:21
: [rakudo] add S04-statements/return.t to spectest_regression, Auzon++
: +12 pass, +2 skip
diff: www.parrotvm.org/svn/parrot/revision?rev=29647
09:23 Debolaz joined 09:34 zostay joined 10:00 Ademan joined
dalek r29648 | moritz++ | trunk: 10:27
: [rakudo] add S04-statements/given.t to spectest_regression. Auzon++
diff: www.parrotvm.org/svn/parrot/revision?rev=29648 10:28
11:06 AndyA joined 11:22 Whiteknight joined 11:25 barney joined 11:37 ruoso joined
dalek r29649 | bernhard++ | trunk: 11:47
: [Pipp PCT] Check the maximal number of digits in hex and octal escape sequences.
diff: www.parrotvm.org/svn/parrot/revision?rev=29649
11:52 iblechbot joined
dalek r29650 | infinoid++ | pdd13pbc: 12:36
: [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: www.parrotvm.org/svn/parrot/revision?rev=29650
r29651 | infinoid++ | pdd13pbc: 12:43
: [PDD13]
: Remove some useless pack() and unpack() stubs, the parent class handles
: those.
diff: www.parrotvm.org/svn/parrot/revision?rev=29651
12:45 contingencyplan joined
dalek r29652 | infinoid++ | pdd13pbc: 13:11
: [PDD13]
: * Implement the following PackfileDirectory methods:
: - elements
: - get_pmc_keyed_int
: - get_string_keyed_int
: * Test basic enumeration of PBC segments from PIR.
diff: www.parrotvm.org/svn/parrot/revision?rev=29652
13:16 gryphon__ joined 13:17 Ademan joined
dalek r29653 | infinoid++ | pdd13pbc: 13:19
: [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: www.parrotvm.org/svn/parrot/revision?rev=29653
Infinoid 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? 13:23
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 13:24
13:27 donaldh joined
jonathan Infinoid: I'd just implement the new one. 13:27
But that is a bit of work.
Infinoid ok, thanks. For now, I'll just return PackfileRawSegments for debug segments, and basically ignore them 13:28
jonathan That sounds like a good interim solution. 13:35
14:07 uniejo joined 14:16 jhorwitz joined
donaldh How do parrot and rakudo types interoperate? 14:22
If I construct a SQL ResultSet using parrot types, what does it look like to rakudo?
for example. 14:23
14:23 Andy joined
donaldh is trying to decide how much lifting to do in PIR versus perl6 14:24
moritz donaldh: I think it only looks like anything from p6 if you register it with P6Meta 14:25
but the cross-HLL isn't done yet, mostly
donaldh moritz: that's what confuses me. intproto defines a new Int class that has Integer and Any as parents. 14:26
moritz: is Integer the parrot type? 14:27
moritz donaldh: dunno, I'm just picking up random stuff that scrolls down before my eyes ;-) 14:28
donaldh is wondering if he constructs a list of Integers in parrot, will he get p6 Ints when he is running within Rakudo
moritz why don't you just try it with a small sample? 14:29
donaldh is just about to ;-)
donaldh needs to invoke a few satanic verses to export the functions into the p6 namespace first. 14:30
masak donaldh: actually, all perl6 stuff works better with angelic invocations :) 14:31
donaldh masak: that's where I've been going wrong ;-)
masak clearly. :)
14:34 paco joined
Infinoid if(SELF.does("satanic")) real_exception(interp, NULL, E_ImportError, "invocant from wrong plane of existence"); 14:46
donaldh :D
donaldh has his answer 14:47
If I allocate and return a new Integer in parrot, then int_val().WHAT returns 'Int' 14:48
i.e. the p6 type.
Infinoid cool.
donaldh So I can write pir to convert a SQL result set into parrot types and perl6 code will get p6 types. yay. 14:49
I have no idea how this would work in a multi-HLL world. 14:50
Infinoid I suppose each HLL should just convert it to whatever integer type it's comfortable with 14:51
(but I know nothing about the HLLs)
donaldh It appears to work because rakudo has the last say on what prototype is registered for Integer. 14:52
Infinoid but ... does it change the actual data type, or just wrap it somehow?
donaldh Infinoid: I have no idea. 14:53
Infinoid (I'm just curious, if your p6 code then passes that value to tcl, would tcl see an Integer, or an Int)
donaldh I think tcl would see an Int. But the Int isa Integer
nopaste "donaldh" at 144.254.89.228 pasted "the Int prototype" (9 lines) at nopaste.snit.ch/13628 14:54
donaldh But if tcl expects its own integer type then it will be disappointed. 14:55
15:11 apeiron joined
dalek r29654 | moritz++ | trunk: 15:12
: [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: www.parrotvm.org/svn/parrot/revision?rev=29654
jhorwitz donaldh: i believe HLL type mapping is supposed to handle the type conversion for each HLL. but that's not in place yet. 15:13
not sure if/how it handles objects though
donaldh 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. 15:14
jhorwitz 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. 15:15
Infinoid I'm guessing the problem isn't the value itself, but the methods wrapped around it
jhorwitz yeah
pmichaud, jonathan, and probably DietCoke can explain the type issues better than i can. 15:17
dalek r29655 | moritz++ | trunk: 15:19
: [rakudo] whitespace fixes in spectest_regression.data
diff: www.parrotvm.org/svn/parrot/revision?rev=29655
donaldh 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 15:22
moritz it replaces only the names, right?
15:22 DietCoke joined
DietCoke reviews. 15:22
purl reviews are hard since you have to read with a different eye than just for learning. or not written by yowling racists at all.
donaldh yes, it replaces the binding for ResizablePMCArray so that it is now implemented with a List (isa ResizablePMCArray) 15:23
DietCoke 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.
jhorwitz parrot *should* be able to handle the simple cases though. i wonder about arrays and hashes... 15:24
DietCoke 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. 15:25
donaldh has opened a can of worms
DietCoke it needed opening.
jhorwitz really.
jhorwitz realizes there are no simple cases now. :(
particle1 sometimes i think we should rename parrot to pandora
moritz particle1++ 15:26
DietCoke 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.
particle as i recall, dan left it as a hll implementor's problem
DietCoke which is, IMO, a recipe for failure. 15:27
donaldh Are HLLs all building their own types?
jhorwitz wants the teachers edition so he can see the answers.
DietCoke (unless all the HLL implementors agree.)
moritz and doesn't really reflect our current design philosophy, I think
DietCoke 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. 15:28
15:28 Andy joined
donaldh 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. 15:29
Tene I vote that we standardize on lolcode's types.
DietCoke donaldh: not everyone agrees how things like division on ints or increment on strings should work, e.g.
donaldh Sure. But Perl6::increment can be separated from Tcl::increment.
DietCoke donaldh: they are.
donaldh As long as the storage is portable. 15:30
DietCoke donaldh: that would require a complete re-thunk of PMCs, I fear.
Tene my $i = eval('1', :lang<tcl>);
$i++;
Is that Tcl::increment or Perl6::increment?
Infinoid karma $i 15:31
purl $i has karma of 280
DietCoke karma $foo
purl $foo has karma of 49
donaldh karma donaldh
purl donaldh has karma of 1
moritz karma i
purl i has karma of 73
Infinoid donaldh++
donaldh thanks
particle my Int :lang<tcl> $i = eval('1', :lang<tcl>); would make things more clear
moritz $i++ much more frequent than i++? wow
DietCoke So, basically, there isn't a fully developed plan on how this is going to work out between HLLs. 15:32
donaldh karma c++
purl c++ has karma of -81
moritz karma c
purl c has karma of 7026
DietCoke solving it for PCT will work for many languages, but not all.
donaldh DietCoke: I was getting that impression ;-)
the problem is letting HLLs diverge with their own prototypes. 15:33
If they could share prototypes it would be easier.
DietCoke but can they?
Do you mean, if everyone used "Integer" instead of creating their own HLL type?
donaldh I think so. 15:34
DietCoke 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.
donaldh And perl6 could extend the Integer prototype, as could Tcl, etc.
moritz but if the spec says it should be called "Int"?
DietCoke donaldh: they're both doing that now.
TclInt isa Integer, e.g.
15:34 magnachef joined
donaldh Yes, but TclInt isa Int == false 15:35
DietCoke there is no Int.
donaldh perl6 Int ?
DietCoke ah.
Int isa Integer too, innit?
donaldh yep.
DietCoke ... so we're already doing that, then, aren't we?
donaldh Circle isa Shape. 15:36
Square isa Shape.
Circle is not a Square.
DietCoke ... 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)
donaldh I'm wondering if it's a Perl6TclInt when I use both HLLs. 15:37
DietCoke no.
it's one or the other.
moritz can't it be TclInt in tcl and Perl6Int in Perl 6?
DietCoke ... "how"?
donaldh Without conversion?
Infinoid ... meaning the HLLs wrap their own classes around the base type, on the fly?
moritz by magic hllmap tables?
Infinoid: yes 15:38
DietCoke 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.
moritz it would convert to the native parrot type (Integer, or whatever it's called), and the HLL auto-wraps it?
Infinoid you'd need pir-level subroutines to have strong prototypes, and conversion functions called as needed 15:39
DietCoke I wouldn't expect the HLL to do anything.
I'd expect it to be handled by parrot.
Infinoid and parrot would try to find a conversion function from the main type, and then try the base type(s) if that fails
DietCoke Or else we're going to write an insane amount of scaffolding.
Infinoid starts having nightmares about haskell
donaldh 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. 15:40
DietCoke yes, that would be spiffy. =-) 15:41
You can't do that today, SFAIK.
donaldh 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.
DietCoke I mean, you can use the standard parrot types, sure.
Tene my $a = eval 'class ZOMGLOL; def foo(n) puts n ; end ; end', :lang<ruby>;
erm.. instantiate at the end of that.
DietCoke no, Perl6 is doing something on its own that isn't done by anyone not using PCT.
purl okay, DietCoke.
DietCoke whoops.
moritz hehe 15:42
donaldh DietCoke: that's where I started. If I create a ResizablePMCArray of Integers in PIR then I get a List of Ints in perl6.
moritz purl: Perl6?
purl i guess Perl6 is doing something on its own that isn't done by anyone not using PCT.
moritz purl: Perl 6?
purl Perl 6 is the spec, rakudo and pugs are two of the implementations.
moritz purl: Perl6 is see Perl 6
purl ...but perl6 is doing something on its own that isn't done by anyone not using PCT....
moritz purl: no, Perl6 is see Perl 6
purl okay, moritz.
DietCoke moritz: that works in private messages. 15:43
moritz DietCoke: ok
sorry
DietCoke 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).
donaldh Ah, okay.
DietCoke Targetting PCT is not a terrible thing, but it does mean you're leaving out a class of implementations.
(or they'll work differently) 15:44
particle the lowest common denominator is parrot base pmc types
DietCoke 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
particle us ethose
DietCoke well, he is. So that's ok. 15:45
donaldh Except that in Tcl you could use Tcl::stringify
DietCoke 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.
particle right, but every hll will need to deal with them
DietCoke "completely"
purl "completely" is relative.
donaldh DietCoke: agreed. 15:46
DietCoke 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) 15:47
and then make parrot do all the hard work for us.
donaldh yes.
DietCoke (though really, tcl would always convert. Which makes me wonder if anyone else would not just always convert.)
moritz DietCoke: perl6 wouldn't necessarily, I think. You can use different storage for objects of the same class, so it doesn't have to 15:48
15:48 MagNET joined
Tene I'm not sure it's such a good idea to convert anything at all automatically. 15:48
We'd have unpredictable behavior. 15:49
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? 15:50
moritz sounds scary
15:50 Theory joined
Tene Where is the boundary, exactly, and what are the reasons for placing it there? 15:50
For rakudo, do we convert from subset types, for example? 15:51
What if we mixed a role into the object?
donaldh Maybe HLLs just need to accept parrot base types.
particle again, that's the lcd. 15:52
donaldh So Tcl sees perl6 datastructures downgraded to parrot types.
particle: yes.
Tene 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) 15:53
donaldh sometimes there is no Point ;-)
Tene What about: class Magic { extends Int } ?
particle 1) every hll must be able to convert to/from base pmc types 15:54
Tene If I make a custom class extending a class which would be converted? Will that be converted too?
DietCoke particle: hell no!
that's what .HLL_map is for. I don't want to have to write code for that...
particle 2) parrot has a defined mechanism to allow intra-hll conversions
Tene Isn't 1) what the HLL mapping is supposed to take care of? Or just 1)a?
particle dietcoke: yes, that's what .HLL_map does 15:55
moritz 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
Tene moritz: Right, type declaration on the variable you're assigning to.
particle 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
DietCoke particle: That sounds very handwavy to me. =-)
what's simple? what's complex? how do the conversions happen? when do they happen? 15:56
15:56 grim_fandango joined
Tene particle: explain what 2) might look like. 15:56
particle freeze/thaw?
purl freeze/thaw are the Format
DietCoke particle: that's what .HLL_map -should- do, but yes. =-) 15:57
Tene particle: explain what you mean by intra-hll conversions.
moritz Tene: don't know if that's the way to go. It would imply that Int:lang(tcl).isa(Int)
Tene: and I doubt that's compatible with linkovsky substitutability, or whatever it's called
particle some wrapper around thaw that allows you to specify the language and translates the impedance mismatches
*liskov 15:58
Tene 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
?
particle yes, or call a runtime library
DietCoke 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? 15:59
particle parrot only needs to provide an api
it doesn't have to do everything, and it can't
DietCoke ... then there's no point in my working on partcl any more. =-)
particle parrot will make hll interop possible... this we've promised
Tene 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?
DietCoke particle: yes, but so far every plan I've heard will make it possible in a very unhelpful way. 16:00
particle parrot 1.0 needs to make it possible.
parrot 2.0 can make it easy.
Tene 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?
DietCoke 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. 16:01
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.
donaldh is .HLL_map documented anywhere other than pdd19_pir.pod ?
particle no, i haven't talked to anyone about it 16:02
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
DietCoke yes, that would be lovely. 16:03
particle hll interop is largely unaddressed and unsolved 16:04
donaldh Reading pdd19, it seems that .HLL_map only covers mapping from c code to the current HLL.
16:04 Casan joined
DietCoke particle: yes. and it's supposed to be one of our -core- features. 16:04
particle yet there's no pdd 16:05
DietCoke yes.
Tene So let's first get the .HLL stuff *working* in PCT and get the various languages using it.
particle and it's not a major milestone in the nlnet grant
DietCoke tene: s/in PCT/, but yes.
particle so, that's a problem
DietCoke what, that we're not getting paid for it?
Tene DietCoke: is it not working at all right now?
DietCoke tene: parts of it are working. Since it is not well spec'd or tested, it's hard to say for sure. 16:06
Tene I'll work on investigating that tonight.
DietCoke there's at least one part that's broken (and an RT for it.)
Tene #?
DietCoke tene++
Tene particle: I'm not getting any money from nlnet anyway, so that's not a problem for me. :)
particle DietCoke: can we schedule some teleconference time with you if needed during oscon/post-oscon hackathon to discuss issues like this? 16:08
DietCoke tene: rt.perl.org/rt3/Ticket/Display.html?id=56958
We can try, sure.
particle i'll keep it in mind
DietCoke I can't make any promises on my schedule atm.
particle sure, same here :)
i'm kinda sick of conferences atm, and not looking forward to oscon :( 16:09
i'd rather be home enjoying my new deck, which i finished saturday
DietCoke 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.
donaldh particle: enjoy your deck. I built mine and the rain started. I'm still waiting for weather to enjoy it. 16:10
particle thanks :) 16:12
i have until october before the rains start here
donaldh Going back to PMCs, it seems to me that PMCs are being used to implement different types while supporting conversion between types. 16:13
They're also being used to implement the same types in different languages. 16:14
Is it necessary to use them for the second case?
particle pmcs are an abstract datatype
they allow you to create your own data types, and they provide a defined method of access 16:15
donaldh 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.
particle 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 16:16
it has Scalar
donaldh Hmmm.
DietCoke tcl's ints don't autopromote to float on division, e.g. 16:17
donaldh 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.
DietCoke 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... 16:18
donaldh all very good questions.
DietCoke yup.
I would be most pleased if someone started keep track of these, say, on the wiki. =-) 16:19
donaldh Well I opened the can of worms, so I could have a go at summarizing this discussion. 16:20
moritz donaldh++ 16:21
donaldh karma donaldh
purl donaldh has karma of 3
donaldh yay! 16:22
moritz you won't be able to tripple it again so easily ;-)
donaldh does purl bump self promoters? 16:23
moritz not bump, but ignore I think
and /msg'es them
donaldh very wise
NotFound purl++ 16:33
16:43 Theory joined 16:47 parrot-poke joined 17:04 ruoso joined 17:14 dngor joined 17:22 Theory joined 17:25 cotto_work joined 17:32 Andy joined 17:45 rurban joined 17:51 ewilhelm left
rurban Anyone has an idea how make install will work somewhen? how to replace builddir with the prefix in the pbc's? 17:53
17:58 timbunce joined
Andy let's have a "How you can get started in Rakudo/Parrot" BOF 18:16
18:31 purl joined 18:44 Ivatar joined
Tene rurban: Sometimes #parrot is a bit quiet, yes. 18:49
rurban Ok, I'll just do it for the cygwin package somehow. But don't complain then. 18:50
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 19:21
19:23 purl joined 19:30 donaldh joined
Tene rurban: If #parrot is quiet, your best option is to send a mail to the parrot mailing list. 19:32
Should be perl6-internals@perl.org, maybe?
rurban nada ditto 19:33
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 19:34
/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. 19:35
Since we have fixed pbc's with hardcoded paths, those have to be recompiled. 19:36
and worst, lib_path is hardcoded in the shared lib, which means this has to be recompiled also 19:37
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. 19:38
japhb 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. 19:42
rurban well, moving all the runtime/* dirs below lib/ would be fine e.g. 19:43
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? 19:44
japhb 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
rurban you have to see my strace stat calls of all the useless dir lib_path traversal
Ah OSCON! That's why. 19:45
japhb I believe you ... it's a side effect of too much encapsulation.
rurban I'll patch library.c so my liking and see how far I'll get.
japhb nod
Tene Great plan. :)
19:48 pac1 joined
rurban just did. 19:48
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 19:49
but for the pbc 19:50
but for pbc's i must have overlooked something simple
19:51 pac1 left
rurban A similar trick to the installable_<utils> targets 19:52
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 19:56
installable_perl6 -v now runs into Can't read '/usr/runtime/parrot/include/config.fpmc': No such file or directory 19:57
good
20:03 Theory joined 20:04 Andy joined 20:17 davidfetter joined 20:30 rafl joined 20:34 Andy joined 20:35 teknomunk joined
rurban got it. pbc_to_exe now accepts infile --install. if --install links to install_config.o and prefixes the exe with installable_ 20:37
20:39 rurban_ joined 21:00 ruoso joined
dalek donald@sealgair.com | Parrot: 21:13
link: www.perlfoundation.org/parrot/index.cgi?parrot
21:25 Whiteknight joined 21:29 Andy joined
dalek r29656 | Whiteknight++ | gsoc_pdd09: 21:37
: [gsoc_pdd09] update to trunk r29655
diff: www.parrotvm.org/svn/parrot/revision?rev=29656 21:38
21:42 rurban left
moritz Whiteknight++ gsoc_pdd09 branch building, and mostly even passes tests 21:44
if all tests were passing i'd be suspicious ;-) 21:45
dalek donald@sealgair.com | Intra-HLL Mapping Notes: 21:50
link: www.perlfoundation.org/parrot/index...ping_notes
r29657 | coke++ | trunk: 21:53
: [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: www.parrotvm.org/svn/parrot/revision?rev=29657
21:59 Andy joined
dalek r29658 | coke++ | trunk: 22:06
: [tcl] docu-clean up
diff: www.parrotvm.org/svn/parrot/revision?rev=29658
22:14 teknomunk_ joined 22:15 Andy joined 22:29 Theory joined 22:35 cj joined 22:48 TiMBuS joined
Whiteknight thanks moritz, I've been working hard on it 22:51
22:55 hachi joined
dalek r29659 | Whiteknight++ | gsoc_pdd09: 23:00
: [gsoc_pdd09] small codingstd fix 23:01
diff: www.parrotvm.org/svn/parrot/revision?rev=29659
23:06 Limbic_Region joined 23:17 hachi joined 23:20 slavorgn joined 23:24 Sartak left 23:41 teknomunk__ joined 23:47 bacek joined
pmichaud particle: ping 23:51
23:55 Andy joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!