Camelia, the Perl 6 bug

IRC log for #parrot, 2010-07-31

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:20 chromatic http://www.modernperlbooks.com/mt/2010/07/an-acc​urate-comparison-of-perl-5-and-rakudo-star.html
00:20 chromatic just for the record
00:24 particle did i miss the size of the p5 binaries?
00:25 chromatic Yes, one moment.
00:25 particle it's a little succinct, but it basically gets the point across.
00:27 Tene 99,944 MB of virtual memory?  97GB?
00:27 Tene oh, 99.944
00:28 Tene ><
00:28 * particle points tene to http://code.google.com/webfonts
00:28 particle maybe something bigger? :P
00:28 whiteknight Austin: ping
00:28 chromatic 1,239,686 MB file size for p5121.
00:29 Tene particle: why are you pointing me at fonts?
00:29 particle so you can find one with a greater difference between , and . and stop squinting
00:30 Tene particle: no, it actually has a comma there.
00:30 Tene That was copy/pasted from the post.
00:30 Tene My realization was that it was a typo.
00:30 chromatic I don't see MB there... now.
00:30 particle ah, so it does! i hadn't looked.
00:31 particle better.
00:32 particle now, off to the farmers' market!
00:32 chromatic Don't come back without a farmer.
00:34 NotFound The better part of developing a new language is not having to do comparatives with other versions X-)
00:35 NotFound Winxed is the better Winxed version that exists, period X-)
00:39 whiteknight If I want to add a method to a built-in type, what's the preferred way to do that, if any?
00:40 whiteknight Do I get the proxy and add the method to its hash of methods, or do I add the method to the namespace?
00:40 tcurtis whiteknight: NQP's setting does "module Foo { method bla () {...} }"
00:40 whiteknight I don't think the namespace way is the right way, but I can't remember how PMCProxy does the search
00:40 tcurtis whiteknight: I don't know if it's the right way, but it appears to work.
00:40 whiteknight tcurtis: yeah, but I'm trying to inject them programmatically at runtime
00:41 tcurtis whiteknight: ah. I'm not sure, then.
00:43 sorear chromatic++ SANITY
00:44 chromatic I've so rarely been accused of that.
00:45 tcurtis whiteknight: have you tried add_method? It appears to work.
00:46 Tene yeah, add_method probably.
00:46 Tene I expect.
00:47 whiteknight add_method? on Class?
00:47 tcurtis whiteknight: right.
00:47 whiteknight I can't remember if I tried that. I will now
00:48 tcurtis Well, on the Foo class, rather.
00:58 whiteknight error:imcc:syntax error, unexpected '(' ('(')in file 'EVAL_1' line 28032377
00:59 whiteknight I won't even look, because I don't think my file has 28 million lines
00:59 whiteknight imcc--
01:00 sorear sounds like the time gcc started complaining about a syntax error in /usr/include/wx/wxcore.h, near "#inelude"
01:01 chromatic I blame cotto.
01:02 NotFound At least is inteligent enough to figure it was unexpected X-)
01:02 cotto_work oh noes
01:02 cotto_work What did I do?
01:04 Coke chromatic: nifty article. +1.
01:04 Coke chromatic++
01:06 chromatic Thanks.
01:07 chromatic Throw in List::Util, Scalar::Util, List::MoreUtil and a few others and... well, startup and memory use don't seem so strange anymore.
01:10 szbalint chromatic++ # indeed.
01:13 Coke makes me almost feel like we didn't waste the last 10 years. ^-^
01:13 chromatic There's also the fact that a bunch of that stuff wouldn't exist for Perl 5 if Perl 6 hadn't invented it.
01:19 rurban_ joined #parrot
01:32 cotto_work chromatic: how can Lorito have pseudo-function calls if it doesn't have some sort of stack and if CPS is implemented on top of it?
01:33 chromatic Why would it need a stack?
01:33 cotto_work to know where to return to
01:34 chromatic Not with CPS, right?
01:34 cotto_work CPS is on top of Lorito, so it can't be used in Lorito itself.
01:36 chromatic Unless we always know the location of the return PC.
01:36 chromatic But I see your point.
01:36 chromatic I think goto is sufficient at M0.
01:39 * Coke hears fallout 3 calling him.
01:40 cotto_work To put it more concretely, what does a recursive function-based fib function look like in Lorito?
01:43 chromatic Let me type up some ideas.
01:44 * cotto_work goes hoem
01:45 * atrodo working on "invokeable" pmc's now
01:47 atrodo sorear> it should be mentioned that / in pascal is the floating point divide.  The DIV operator is the integer divide.
01:49 sorear atrodo: the code I was reverse engineering was written dumbly, ok.  I beleive that.
01:52 NotFound Maybe it was intentional.
01:53 NotFound BTW freepascal has condtional operator? I never seen that thing in pascal.
01:56 atrodo plus, i've never been a big fan of fpc.
02:04 whiteknight saying "cps is on top of Lorito" is sort of a misconception
02:04 whiteknight it's not on top of Lorito, it's just explicit in it
02:04 whiteknight the first argument of every function call is considered to be a return continuation
02:05 whiteknight so a "return" statement is really a "invoke argument 1" operation
02:05 whiteknight The only difference between Lorito and what we now have in PIR is that the return continuation is passed explicitly instead of implicitly. The mechanism is always the same
02:07 nopaste "chromatic" at 192.168.1.3 pasted "rough description of recursive, non-optimized fib in M0 for cotto" (30 lines) at http://nopaste.snit.ch/22482
02:07 atrodo whiteknight> it sounds like there are a lot of theories floating around on how it's going to work
02:08 NotFound Talking about unfair comparaisons: $ time perl -e 1 real    0m0.002s $ time winxed -e '' real    0m0.040s
02:08 whiteknight atrodo: of course, this is the design period of a very important new language
02:08 whiteknight atrodo: but "classic" CPS treats the return continuation as the first argument of every function call
02:10 atrodo The way I look at is that not all the languages on top of parrot are going to be CPS, so why enforce that policy on everyone?
02:12 kid51 atrodo:  Will the code at http://github.com/atrodo/lorito compile independently of parrot?
02:13 atrodo kid51> yes
02:13 kid51 So, in principle, it can be treated as its own little OS project.
02:13 atrodo At this point, yes
02:15 chromatic You can emulate stackful calling with CPS, but you can't go the other way around.
02:16 atrodo chromatic> I agree.  I'm pro-CPS, but i don't think we have to go full CPS to satisfy both camps
02:16 atrodo we can "cheat" a little
02:17 chromatic Cheat how?
02:18 atrodo A little bit like we do now.  The context has a return continuation that is easy/automatic to fill in, but can be left null for pure CPS
02:18 chromatic I don't know why we need a separate return continuation, to be honest.\
02:21 atrodo strictly speaking, i don't think we do.  But it makes it convenient for the common case.
02:22 chromatic How so?
02:22 atrodo it's a minor tweak that'll make things easier for now, and should be easy to take out if it comes out to be more of a liability later
02:22 chromatic It's at least one extra GCable per invocation.
02:23 atrodo but you have that GCable anyways.  It a matter of is it passed in the context or as an arg
02:24 atrodo sorear> kylix 3 takes a program of that snipplet and makes it 30k.  fpc makes it 121k
02:26 chromatic I have Kylix around here somewhere.
02:26 chromatic If you don't have a separate return continuation -- if you can invoke the calling continuation to "return" as the normal operation -- where's the extra GCable?
02:28 atrodo hmmmm, i suspect I may not understand your methodology
02:30 chromatic fib( CONTINUATION, number )
02:30 chromatic To return, invoke the CONTINUATION
02:31 chromatic Oh, I see what you're saying.
02:31 chromatic I figure that CONTINUATION *contains* the registers
02:32 chromatic Other person in office: Are you mad?
02:32 chromatic Me: No, I just confused myself.
02:32 davidfetter joined #parrot
02:33 atrodo A continuation is just a reference to a point in the code?
02:34 whiteknight not just
02:34 purl hmmm... not just is one of them XS and probably a shitton faster, but the strptime I think is shitass bugged.
02:35 whiteknight it's a snapshot of the state of the VM
02:35 whiteknight purl forget not just
02:35 purl whiteknight: I forgot not just
02:38 sorear atrodo: I don't know what kylix is but it doesn't affect my point - *free pascal* sucks for performance coding
02:39 atrodo kylix == delphi for linux
02:39 atrodo and you're right, it doesn't affect your point.  But it peaks my interest
02:40 kid51 msg Coke please see http://trac.parrot.org/parrot/attachmen​t/ticket/1715/install_pprof2cg.pl.diff
02:40 purl Message for coke stored.
02:41 janus joined #parrot
02:46 atrodo sorear> 13 instructions for kylix
02:52 dalek rakudo: 685c1e7 | (Solomon Foster)++ | src/core/Range.pm:
02:52 dalek rakudo: Try to optimize finite Int Range iteration.
02:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​85c1e7a42243c987d075a51811a751a706e358c
02:52 dalek rakudo: 9b6189d | (Solomon Foster)++ | src/core/Range.pm:
02:52 dalek rakudo: Just go ahead and pass an Array to ConsIter -- makes the code a bit cleaner,
02:52 dalek rakudo: fixes a bug, and doesn't seem to negatively impact the speed of things too
02:52 dalek rakudo: much.
02:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​b6189d78f7a21368b2caa3688a4c71489b6af5b
03:37 dalek joined #parrot
03:39 dukeleto joined #parrot
03:41 PerlJam joined #parrot
03:44 Util joined #parrot
03:44 pmichaud joined #parrot
03:48 chromatic joined #parrot
04:51 eternaleye_ joined #parrot
04:57 cotto kylix?
04:57 purl kylix is an object-pascal based RAD platform. IE, VB with a lower level language. It shouldn't have passed Q&A. It's located at http://www.borland.com/kylix . gilc is a kylix coder.
06:07 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#35188), fulltest) at r48233 - Ubuntu 10.04 amd64 (gcc with --optimize)
06:19 cotto atrodo, what are those instruction counts you've been posting?
06:28 cotto nm.  found it
06:34 robin-gvx joined #parrot
07:06 fperrad joined #parrot
07:06 AzureStone joined #parrot
07:08 jjore joined #parrot
07:11 snarkyboojum joined #parrot
07:52 eternaleye joined #parrot
07:52 AzureStone joined #parrot
07:52 darbelo_ joined #parrot
08:33 eternaleye joined #parrot
09:21 rurban_ joined #parrot
09:38 snarkyboojum joined #parrot
09:39 cognominal joined #parrot
09:41 cognominal joined #parrot
10:15 lucian joined #parrot
11:18 whiteknight joined #parrot
12:04 kid51 joined #parrot
12:04 tommyd joined #parrot
12:17 baest joined #parrot
12:28 rurban joined #parrot
12:53 hudnix joined #parrot
12:53 khisanth_ joined #parrot
13:06 allison joined #parrot
13:06 allison I need documentation for ops2c for the Debian manpage.
13:06 allison (the manpage is required for every binary)
13:08 robin-gvx joined #parrot
13:09 allison in theory, it shouldn't be installed, but in practice Rakudo depends on it
13:12 jnthn In practice, every language that has dynops would depend on it, no?
13:14 allison in the past we've used other tools for that, but yes, in the future all languages should use opsc
13:14 allison it really should have been named parrot-opsc, though
13:15 allison installing a binary as generically named as opsc into the main usr/bin of the distro is very unfriendly
13:16 NotFound De we really need a binary? A pbc isn't enough?
13:16 allison jnthn: how horrific would it be if I installed it as parrot-opsc in Debian?
13:16 allison jnthn: would that make it impossible to build Rakudo from the distro version of parrot?
13:17 allison NotFound: I'm just going on what I was told by a Debian user, that Rakudo requires the binary to be installed
13:17 jnthn I'd guess so - I wonder where we get our path to that from thoug.
13:17 allison NotFound: my goal here is to make it possible to package Rakudo * for Debian
13:18 jnthn OPS2C            = $(PARROT_BIN_DIR)/ops2c$(EXE)
13:18 jnthn Yes, it's hardcoded as looking for ops2c, so renaming it would break things.
13:18 NotFound I think we should add an option to parrot to search for pbc in the runtime dir, and use that instead of fakecutables,
13:19 NotFound I don't see great benefit in using parrot_some_tool instead of parrot --run some_tool
13:19 allison jnthn: okay, for now we'll keep it as opsc$(EXE) and get it changed to parrot-opsc$(EXE) for 2.9
13:20 jnthn allison: OK, sounds workable.
13:20 NotFound (Don't even talk about debates over parrot_... vs parrot-....)
13:20 allison NotFound: if I can ever spend the afternoon getting the busybox hack working in Parrot, you're right, but for now it's the best way
13:20 allison NotFound: heh :)
13:21 allison NotFound: personally I go for "foo_bar" is a function name and "foo-bar" is an executable
13:21 allison NotFound: perhaps a group reviewed coding standards entry is in order
13:22 allison I'm going to add a README file to compilers/opcs based on the sketchy info I have, people can updated it
13:22 NotFound I prefer to avoid the issue by having the less fakecutables as possible, and having non-prefixed non-confusing names for the ones that keep on.
13:23 allison if the fakecutables are just symlinks, it's far less of a headache
13:23 NotFound There are platforms without symlinks.
13:24 allison yup, and there are platforms without shebang lines
13:24 allison (which would be the other simple solution)
13:24 allison we have the same problem for language binaries
13:25 NotFound To using shebang lines with pbc we'll need to change pbc header and some trickery.
13:28 NotFound Java lives well without such trickeries. People that likes to tweak its system to run jvm binaries like native ones can do, but the machinery doesn't depend on it.
13:29 jnthn On Windows it's just a file extension association. :-)
13:29 jnthn Windows++
13:29 jnthn karam Windows
13:29 jnthn aww
13:29 jnthn :-)
13:30 NotFound jnthn: ...that almos nobody uses X-)
13:30 allison it's easy enough to run parrot foo.pbc
13:30 allison but the killer is the *path* to foo.pbc
13:30 NotFound allison: we just need to add an option to enable libpath search
13:31 allison NotFound: don't we already have libpath search?
13:31 allison ah, you mean from the command-line
13:31 NotFound allison: for load_bytecode, but not for command line main program.
13:32 allison but then we'd just be duplicating the PATH of existing operating systems
13:33 NotFound allison: like almost any other complex system in this world does.
13:33 allison if it's running as the main script, it's not a library, it's an executable
13:34 allison perl doesn't, python doesn't
13:34 allison if Java does, I don't take that as a good example
13:34 allison (I've been in Java dependency hell)
13:34 allison not necessarily saying we shouldn't
13:34 NotFound We are in fakecutable hell right now.
13:35 allison just saying I'm not sure it's an improvement over our fakecutables
13:35 allison it'd be nice to trim down our fakecutables to simple PIR scripts that load the library
13:36 bacek joined #parrot
13:36 allison instead of the current bloatware
13:36 kthakore NotFound: hi
13:36 NotFound kthakore: ho
13:36 allison that would be a step in the right direction
13:36 kthakore NotFound: that incremental patch idea is .. not working
13:37 kthakore NotFound: stringhandle needs more tought ...
13:37 kthakore any place I can go to learn more about io/api.c and general IO philoshy in parrot?
13:37 kthakore NotFound: deeper down the parrot hole ...
13:38 NotFound kthakore: my main view about IO philosophy in parrot is: it needs a lot of work ;)
13:38 kthakore NotFound: lmao ... ok break
13:38 kthakore gonna go outside ...
13:38 ambs joined #parrot
13:39 kthakore NotFound: I spent a good ... 4 hrs on this .... and still the brain is broken
13:39 allison kthakore: there's the design document docs/pdds/pdd22_io.pod
13:39 allison kthakore: that's the best place to start
13:39 kthakore allison: oh thanks I looked at that
13:39 kthakore what I am confused is
13:39 NotFound kthakore: Can't you start by the simple step of changing the way open works?
13:39 kthakore why some IO handles (string in this case)  have the guts in io/api.c
13:40 kthakore I mean wouldn't it make more sense to just call straight to Perl_io_open
13:40 kthakore then decide which open to call on the pmc
13:40 kthakore but it doesn't do this
13:40 allison kthakore: they shouldn't have guts in io/api.c
13:41 kthakore I know! That is what NotFound asked me to fix
13:41 s1n joined #parrot
13:41 kthakore allison: I think it has just gotten ... messier with age
13:41 allison In the first version of the current I/O implementation, open did just call a method on the PMC
13:41 allison but, it was slow
13:41 kthakore NotFound: I have done that ... but other things start braking
13:41 kthakore oh ...
13:41 NotFound kthakore: probably just because someone wrote it that way and no one has refactored yet. In some cases, trying to gain some speed.
13:42 kthakore I see
13:42 allison kthathore: yes, it has. I think of it as a "recent refactor", but it was in fact a year and a half ago
13:42 kthakore ok so what if we not have Perl_io_open
13:42 kthakore and just call open stright to pmc for file and string
13:42 allison I don't know what you mean by Perl_io_open
13:42 kthakore it is a method in io/api.c
13:42 NotFound allison: what is slow is to call a method for any IO operation, but open and close are hardly as critical.
13:43 allison kthakore: you mean Parrot_io_open?
13:43 kthakore oh!
13:43 kthakore sorry
13:43 kthakore allison: I have been staring at code for too long
13:43 kthakore allison: my apologies
13:44 PacoLinux joined #parrot
13:44 kthakore the ticket in question is 1639
13:44 NotFound allison: StringHandle open call open in io/api, and thus io/open needs to abuse StringHandle internals.
13:44 allison NotFound: that's what we thought, yes, that I/O was so slow that the method call wouldn't hurt. but it really killed all our language implementations
13:45 NotFound allison: What languages have critical speed problems with StringHandle open?
13:45 kthakore NotFound: allison: I really need a break. Please update the ticket on your thoughts. I will hack it that way.
13:45 kthakore http://trac.parrot.org/parrot/ticket/1639
13:45 kthakore thank you.
13:45 allison but, we've killed the 'open' op now anyway
13:45 allison so, the only way to call Parrot_io_open is from within C
13:46 NotFound Even less sense on doing open that way, then.
13:46 allison yeah, we're not gaining anything anymore
13:47 NotFound I thought that was a easy task, can't figure what problem he's having.
13:47 NotFound Maybe just summer ;)
13:49 allison he's right that there's confusion in the code base on what the purpose of the I/O subsystem is
13:49 NotFound Yeah, but the change in StringHandle shouldn't be that hard.
13:49 allison it's both serving the purpose of providing an interface to the C-level filehandles, and providing part of the functionality of of the PMCs
13:50 allison it should probably only be providing the interface to the C-level filehandles
13:50 NotFound BTW we've not killed open, just moved it to dynpmc
13:50 allison and StringHandle shouldn't be calling Parrot_io_open at all
13:51 allison fair enough
13:51 allison and we don't really want the opcode deciding whether to call a method or not
13:51 allison though, it's better than hardcoding behavior into Parrot_io_open
13:52 NotFound I'll try to do that change in StringHadle myself, to see if there is some unknown issue and avoid discouraging kthakore
13:52 allison What if the 'open' opcode made a simple choice, "call Parrot_io_open if I'm a ParrotFileHandle, otherwise call the 'open' method"
13:53 allison at least then we're not special casing for each special filehandle type
13:53 kthakore NotFound: you can never discourage me :D
13:53 NotFound allison: avoiding the special case in StringHandle is the first step in that direction.
13:53 kthakore NotFound: crap chores are calling
13:55 allison NotFound: actually, the special case in Parrot_io_open looks like it's already entirely avoidable
13:56 allison NotFound: just make sure StringHandle has a method named "open".
13:56 NotFound allison: it has... It call io_open
13:57 allison which calls Parrot_io_open and starts a loop?
13:57 allison does that actually do anything for StringHandle?
13:58 NotFound StringHandle open call Parrot_io_open, and Parrot_io_open special cases it to avoid calling the open method. That's the issue.
14:01 allison All Parrot_io_open does for the 'open' method is set the mode flags, which can be done directly
14:06 Austin whiteknight: pong
14:06 allison adding my comments to the ticket
14:10 darbelo_ o/
14:10 darbelo \o
14:18 NotFound Done
14:22 darbelo allison: Did you see my last blog post?
14:22 dalek parrot: r48234 | NotFound++ | trunk/src (2 files):
14:22 dalek parrot: call StringHandle.open from Parrot_io_open, not the other way
14:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48234/
14:25 patspam joined #parrot
14:28 NotFound (Killing cows)++ and make steaks of them even better.
14:32 allison darbelo: not yet
14:33 darbelo NotFound: To be fair, bacekd did most of the cow-killing, I'm just cutting it up into stakes.
14:33 NotFound I have other idea for reducing string memory footprint. Make a struct with the relevant information and function pointers for charset and encoding togeheter, fiill one of these for any valid charset/encoding combionation and make the string header point to it instead of charset and encoding separately.
14:34 darbelo allison: I'm looking at ways to make the gsoc_nfg branch use less memory.  Ideally, by doing away with the 'extra' pointer I've been using to hold the grapheme table.
14:34 allison darbelo: one primary point of immutable strings was to eliminate copy on write, why do we still support it
14:35 NotFound allison: for substr optimization, I think.
14:35 NotFound Is not cow anymore, but still uses the cow support structures.
14:36 allison okay, it sounds like a great target for a little post-refactor cleanup
14:36 darbelo allison: We have a few leftovers, if I can remove them we can save a pointer in the string struct.
14:36 allison figuring out the sensible way to support substr's features
14:37 allison darbelo: yes, I'm in favor of it
14:37 allison we didn't make a clean break with COW when we shifted to immutable strings, so it's time to take the next steop
14:37 allison step
14:39 darbelo allison: Should I do that as part of the gsoc_nfg branch (which is the place where I need this the most) or is it better to do the work on a new branch?
14:39 NotFound I've just noticed I ran out of coffee! Don't know if I can keep talking.
14:41 NotFound darbelo: I think it can be done in trunk.
14:42 NotFound Unless it's too dificult to keep your branch in sync.
14:43 atrodo allison> cotto mentioned that you have some concerns about p&w?
14:44 robin_gvx joined #parrot
14:45 darbelo NotFound: I guess trunk is an option too. My options are 'Inside the branch' which makes it easy for me, or 'outside the branch' which isn't really hard to do either.
14:46 darbelo I think I should go with 'outside' since it's really independent of nfg.
14:47 allison atrodo: p&w?
14:47 purl i heard p&w was http://tinyurl.com/23dfwut
14:47 atrodo botsnack
14:47 purl :)
14:48 allison atrodo: ah, yes. We don't need yet another stock model from somebody else, we need an object model that solves our problems
14:48 allison p&w have some good ideas, but it's not a perfect fit
14:48 allison basically, they weren't thinking of Parrot, so there's no way they could design perfectly for Parrot
14:49 atrodo thoughts on how to make it better?
14:49 allison darbelo: if we can develop it independently of the gsoc branch and merge it quickly, that'd be ideal
14:50 darbelo OK, I'll get on it
14:50 jnthn On object model stuff, the mail I sent to parrot-dev yesterday contains a brain-dump at a high level of where things are heading in terms of the P6object replacement.
14:50 allison atrodo: it goes the other direction "what of their idea should we include in Parrot?"
14:50 allison jnthn: thanks, that's helpful
14:51 allison it may be that Parrot's object model can be vastly simplified now, since it's not trying to support all of Perl 6's features
14:51 patspam joined #parrot
14:51 allison all it needs to provide is a core base
14:51 jnthn allison: Well, I've a high degree of interest in "small core" too.
14:51 darbelo simpler++
14:52 allison (I realize that Parrot's current core model is now completely out-of-sync with current Perl 6, but that was the original goal.)
14:52 jnthn allison: I think what we really need to work out is, "what do we need to do for interop"
14:52 allison jnthn: it is largely the same question
14:53 allison jnthn: and the simple answer is "as little as possible"
14:53 jnthn allison: But as I mentioned in the mail, I think that's better worked out once there's something concrete to discuss.
14:53 allison jnthn: we probably don't have the luxury of waiting that long
14:53 allison jnthn: (if you mean "wait until we have two interoperating languages")
14:54 allison jnthn: and really, I'm doubting more and more that interoperability is as important a feature as we've made it out to be
14:54 macroron joined #parrot
14:54 allison jnthn: the reason it's so poorly tested, exercised, etc, is that no one really has a critical use for it
14:55 NotFound Maybe the problem is to try to overengineering interoperability.
14:55 allison NotFound: "avoid"?
14:56 allison (wondering if there was a missed word in there)
14:56 NotFound allison: I've made simple test of compiling and calling functions with mixed languages and haven't any problem, without even having to use export_to or alike.
14:56 jnthn allison: Oh, I agree with "as little as possible", or at least in the sense of "as little as possible to be useful".
14:56 allison what interoperability doesn't mean is that a (for example) Python object will support all the Perl 6 method calls
14:57 NotFound So I fail to understand the discussions about supporting interoprability.
14:57 allison it does mean that you can use a Python object to the extent of calling its methods and accessing its attributes from within Perl 6
14:58 jnthn allison: Aye, though things get more interesting when you start asking questions like, "should I be able to take a Python class and subclass it in Perl 6", or vice versa.
14:58 allison jnthn: it does, and I'm happy to punt to "delegate"
14:59 jnthn allison: Yes, a delegatory model is certianly the view we're tending to look at from the Perl 6 side.
15:00 NotFound That's what I call overengineering, trying to solve problems that no one had yet.
15:02 jnthn allison: If language interoperability isn't an important thing for Parrot, though, then I do have to wonder what the motivation for targetting it is.
15:02 allison NotFound: we've done a lot of that in the current object model, and can do a lot less of it in the refactor
15:02 whiteknight joined #parrot
15:02 [1]Casan joined #parrot
15:02 allison jnthn: the motivation is that it *has* been considered an important thing in the past
15:03 allison jnthn: it's still worth supporting to the extent that it doesn't totally foobar the system
15:03 allison jnthn: but perhaps not quite as important to be quite as... er, extensive?... in supporting it
15:04 NotFound For me is an important thing, just think that is rather good right now, and people sometimes talk abou it as if it where something that needs to be done.
15:05 allison NotFound: yeah, I think what we have now is pretty good
15:05 allison NotFound: and not at all costly, it just falls out naturally from the way we do subs, objects, and namespaces
15:06 [2]Casan joined #parrot
15:06 NotFound allison: agree
15:07 allison NotFound: so the key is to keep that simplicity as we refactor the core object model and Perl 6's object model
15:07 atrodo allison> sorry, got pulled away suddenly.  I think the most important thing is to enable languages to use their own object models.  If they happen to interoperate, great
15:07 allison NotFound: (and maybe even enhance the simplicity)
15:07 atrodo but I'm asking these questions on the lorito side
15:08 allison atrodo: back to p&w?
15:08 atrodo the object model ideas in general
15:09 atrodo or rather, object model for pmc's in general
15:11 allison The most important things are a) to merge C PMCs with PIR PMCs, b) to keep two sets of object behavior (roughly corresponding to our current "vtables" and "methods") one being publicly accessible to users, the other providing base functionality
15:12 allison c) to provide attributes storage and retrieval, d) to provide invocation for both public and hidden functionality
15:13 NotFound Extra bonus point if it can support some degree of public/protected/private support.
15:14 atrodo NotFound> that's actually a flaw I've yet to solve, or even decide if it's reasonable or possible
15:15 NotFound atrodo: hard access control is probably not reasonable, but some help for languages that want to have it will be nice.
15:15 allison NotFound: that seems like an extension beyond the core object model, as many languages won't use it, and shouldn't bear the cost of the checks
15:17 allison NotFound: as in, any language should be able to call a standard method for "fetch attribute" or "invoke method" and it's up to the object to decide if the caller has appropriate credentials to actually access that attribute or invoke that method
15:17 allison I should say "call a standard thingy"
15:17 NotFound allison: C++ for example doesn't do runtime checks, it just uses the information to be able to signal the error while compiling.
15:18 allison NotFound: compile-time checks like that are language-specific
15:18 atrodo NotFound> Most static languages i've encoutered have always had that as security by obscurity.
15:19 NotFound allison: sure, but if you want the ability to it with already compiled classes a way to store that information will ne useful.
15:19 jnthn NotFound: That's what meta-objects are for.
15:19 atrodo allison> I thought that the desire was to combine vtables and methods
15:19 NotFound atrodo: that's an error. Is not security, is design,
15:20 atrodo aye, but if i wanted to, i can find and call private methods and access private data
15:20 allison NotFound: the feature is essentially a level of optimization "I've already checked access restrictions at compile-time, I'm only running trusted code, disable runtime access restriction checks"
15:20 NotFound Obscurity will be: "that method doesn't exist", design is "that method is provate"
15:20 allison atrodo: the desire is to do away with the current implementation distinctions between vtables and methods, yes
15:21 allison atrodo: but, we will still have some "methods" that are for internal use, rather than exposed for direct calls from the users
15:21 allison atrodo: things like "get_bool" to access the boolean value of the object
15:22 NotFound atrodo: you can call private methods and you can divide by zero, yes.
15:22 allison atrodo: (which needs to be standard across all objects in the system, but is not a standard name in all languages)
15:22 allison atrodo: if it helps, think of it as "what objects expose to the language users" and "how objects talk to each other"
15:23 NotFound BTW, there is some way to call set_bool from pir?
15:23 allison nope, just set_integer_native
15:25 NotFound I fail to see the usefulness of that vtable. The clarity improvement it provides is near zero.
15:25 atrodo allison> okay.  So in a p&w sense, it would be like you have a lookup method for "vtables" and another lookup method for the actual objects themselves?
15:27 allison NotFound: it's very different when you're evaluating an object in boolean context versus using it in a numeric context
15:27 NotFound allison: that's get_bool, I mean set_bool
15:28 allison NotFound: as far as I know, no current PMC is using set_bool (precisely because it isn't exposed from PIR)
15:28 NotFound That's the point.
15:28 NotFound Let's deprecate it.
15:28 allison but if all "vtable" functions were exposed from PIR, it's perfectly possible to need to set the two values differently
15:29 allison NotFound: let's not deprecate it, and just say it falls by the wayside when we get rid of the fixed set of vtable functions
15:30 allison NotFound: (at that point, any object that defines it, has it, and any object that doesn't define it ignores it)
15:30 NotFound WFM, the only problem is to have less nice green in the coverage report ;)
15:32 atrodo allison> got to go, but I've got lots to think about.  Thanks for the braindump
15:38 Austin msg whiteknight I'm going to lunch, and then to lawn-maintenance-ville, but I'll be around this afternoon/evening if you still need me. Regardless, I'd like to talk to you about what's up with your Kakapo branch - it sounds like you've made some progress I need to steal^W find out about...
15:38 purl Message for whiteknight stored.
15:38 whiteknight ok
15:38 whiteknight I'll be around
15:42 allison joined #parrot
16:00 mokko joined #parrot
16:00 mikehh can't figure out how to do a proper todo using runtime/parrot/library/Test/More.pir
16:00 dalek parrot: r48235 | allison++ | trunk/ports/debian/parrot-devel.install.in:
16:00 dalek parrot: [debian] Apply a patch from Matt Kraai selecting appropriate new NQP files to
16:00 dalek parrot: install, and installing the opsc command-line and supporting library.
16:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48235/
16:01 mokko Hi! I am trying to install/compile rakudo on cygwin. thought that now is finally the time.
16:01 mikehh it seems you can use todo but it doesn't actually run the test
16:02 mokko make complains with cannot find -lparrot
16:07 simcop2387 joined #parrot
16:07 mokko any help appreciated
16:24 mokko I get the same error with rakudo star tar and with source from github
16:26 allison mokko: I don't have an install of cygwin handy to help you
16:26 allison mokko: are you using parrot cygwin packages, or letting rakudo build parrot itself?
16:29 mokko I tried cygwin packages but they are old (parrot 2.3). I wanted to try rakudo star, so I try to compile myself. I don't really understand ld. I was able to compile parrot 2.6.0, but not rakudo.
16:29 mokko in the meantime I uninstalled cygwin packages
16:30 allison mokko: you'll probably have more success if you let rakudo build parrot for you
16:30 mokko I have a self-compiled parrot 2.6 and I tried to let rakudo to make a parrot inside parrot_install
16:31 mokko @allison. Yes, I tried that. Then I run into the ld error saying it cant find lparrot
16:32 mokko when I compiled parrot myself under cygwin, I had problems with that cygparrot_2_6_0.dll, could it be the same?
16:33 allison mokko: it's possible, yes
16:34 mokko how do I get from -lparrot to cygparrot2_6_0.dll? Or: where would rakudo expect that library to be? And how does is it expecting it to be called? Can I see that in the Makefile, for example?
16:36 particle mokko: you may need to move libparrot.lib to the root directory of the build, rather than in some subdir
16:36 particle move/copy
16:36 mokko thanks. I will try.
16:44 mokko I don't have libparrot.lib anywhere on my system, although I should have about 3 of them. One from compiling parrot myself, one from rakdudo via github and one from rakudo-star.tar.gz. I suspect that under cygwin it is compiled instead as cygparrot2_6_0.dll. I will try to compile with this library in various directories (rakudo-star-2010.07 etc.)
16:48 mokko In other words: I don't know where the libparrot.lib NOR cygparrot.dll (if assumption above is correct) should be and I don't know if Makefile should point explicitly to cygparrot instead of libparrot.lib
16:53 * Coke reads backscroll. Wow. pretty much the only reason I spend time on the parrot project is for hope of interop. Will be sorry to see that go.
16:54 allison Coke: not go
16:54 allison Coke: it's just that there are an infinite number of definitions of what "interop" means
16:55 allison Coke: so we pick a sane one
16:55 NotFound Coke: I think the same, but I think no one is proposing it should go.
16:56 allison Coke: (plus, my doubts about how useful it is are entirely my own, so if you have a good use, please contradict me)
16:57 NotFound allison: I'll tell you one good use. Some time ago I read about the python module Mechanize, wich is a clone of the perl one with the same name. They say they wrote it because they liked the module but needed to work with python.
16:58 mikehh I thought the concept was that running on parrot Rakudo should be able to use Pynie libraries or whatever
16:58 Coke allison: the WHOLE point of parrot for me was being able to invoke code written in other languages.
16:58 NotFound The good use is to avoid that.
16:58 patspam1 joined #parrot
16:58 Coke the "provide a base for brand new languages" was an interesting tangent, but not one I cared about.
17:00 NotFound Coke: I care. I wrote winxed thanks to that.
17:00 allison Coke: we've often advertised it as Parrot's best feature, but it's a feature that apparently no one outside of the Parrot project actually cares about
17:00 allison Coke: as in, no one currently using Python 2.5 is going to switch to Parrot in order to use libraries from Perl
17:01 ruoso joined #parrot
17:01 Coke allison: how many languages target parrot at the moment that are in any way complete?
17:01 allison 0
17:01 jnthn allison: Er, maybe because there's no Python 2.5 compiler?
17:01 NotFound allison: they don't even switch to later pythons, no wonder.
17:01 particle lua is complete.
17:01 jnthn allison: That's not a demonstration of lack of interest in language interop.
17:01 allison yes, I agree that they can't at the moment anyway
17:01 jnthn allison: That's a lack of ability to even try it.
17:01 Coke allison: wow, did you miss the Rakudo * release this week? ;)
17:01 allison but they aren't even interested anymore
17:02 NotFound Note also that people most interested in such interoperability already joined parrot ;)
17:02 Coke I don't think lack of interest in the /idea/ is the problem.
17:02 mikehh we have not got a demo of interoperability, so we have no use cases
17:02 allison Coke: re Rakudo, that's being billed as useful, usable, early adopter, not "complete
17:03 particle i don't see how anyone wouldn't be excited by the possibility of using p6 regexes in their language
17:03 Coke allison: never mind.
17:03 allison I'm not trying to argue that we drop interop
17:03 allison I'm more offering a perspective on what interop means
17:04 Coke particle: not to rain on YOUR parade, but I can name 2 right off the bat. Java developers at work, guy in Albany.pm who doesn't even use p5 regexes in his perl. just to give you more data points. =-)
17:04 Coke allison: your perspective on it in the past was pretty much "so little as to be useless", as I recall.
17:04 allison it means the ability to call functions, call methods on objects, and set and get attributes of objects
17:04 particle Coke: are those the same people who have been shitting on parrot for years?
17:04 Coke not that /you/ phrased it that way. (was how I read it.)
17:05 Coke particle: no. they don't care about parrot enough to do that.
17:05 Coke they're just trying to get their jobs done.
17:05 allison yah, that's what I'm trying to get at, most people are just trying to get their jobs done
17:05 allison if we can help them, we're compelling
17:06 NotFound There is phrase... something like: "I had a problem and tried to solve it with regexes, now I have two problems" X-)
17:06 allison heh :)
17:06 allison it's just so freakishly hard to write for users when you don't have any :(
17:07 allison honestly, I don't know if interop is useful or not, and won't know until a user asks for it
17:07 allison it probably is useful
17:07 Coke [: facepalm :]
17:07 Coke so, allison; we never had elections. presumably we are in violation of our charter or something?
17:08 mikehh bearing in mind most parrot 'users' would be developers
17:08 allison there's not a strict time on it
17:08 allison just, have to have elections annually
17:08 allison we could announce them tomorrow and hold them in two weeks and be fine
17:09 NotFound Actually I don't care much about interop because all tests I've do worked.
17:09 NotFound If I locate a problem, I'll care about it.
17:10 allison NotFound: it's a good perspective, but again runs into the lack of users
17:10 allison NotFound: if we had a hundred users with active production code using libraries from other languages, I'd feel more confident that we have all the features we need
17:10 Coke user's can use what isn't there.
17:10 Coke *can't*
17:11 allison and they can't ask for what they don't know they need
17:11 NotFound Use cases will come with interesting modules.
17:11 allison and interesting modules will come with... a usable system?
17:11 NotFound Yeah
17:11 mokko @allison: seems to work now. I had to copy cygparrot.dll to parrot_install/bin
17:12 Coke which, after 10 years, we're nearly there. ;)
17:12 allison mokko: excellent!
17:12 purl Smithers, release the hounds!
17:12 mikehh if we get stuff working with plumage, surely that is some form of interop
17:12 Coke mokko: rurban is in #perl6 on freenode right now working on packaging things up. You could talk to him.
17:12 allison mmm... well it seems like a usable system somewhat depends on use cases
17:12 allison (knowing what you're implementing for)
17:12 Coke I'm leaving now. =-)
17:12 Coke left #parrot
17:13 mikehh dammit, wanted to ask Coke something
17:13 NotFound Last month I've been able to do a non trivial opengl demo in a high level language. That qualifies as a usable system for me.
17:14 mikehh NotFound: yes it seemed to work quite well
17:15 NotFound mikehh: I've having it running for several days, without crashing and without leaking memory.
17:16 NotFound And without freezing hell. The opposite, maybe X-)
17:16 mikehh NotFound:  haven't tried any of my own examples, but ran quite a few from the winxed examples directory
17:17 mikehh NotFound: think there was a problem with for.winxed
17:17 NotFound There is a problem with the gc, though. I need to insert a explicit sweep to have things collected.
17:18 NotFound Looks like the gc is never invoked from inside of the opengl main loop.
17:19 mikehh NotFound: I only ran the examples (opengl) for a few minutes
17:19 NotFound mikehh: ah, yes, I've forgot to fix that several times.
17:20 rurban_ joined #parrot
17:21 theory joined #parrot
17:33 rurban mokko: my patches for the cygwin package are at http://code.google.com/p/cygwin-rurba​n/source/browse/trunk/release/parrot
17:40 dalek parrot: r48236 | allison++ | trunk/ports/debian/patches (2 files):
17:40 dalek parrot: Add a patch to insert a man file for the ops2c executable.
17:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48236/
17:40 dalek parrot: r48237 | allison++ | trunk/ports/debian (4 files):
17:40 dalek parrot: [debian] Prepare for 2.6 packages.
17:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48237/
17:40 dalek parrot: r48238 | allison++ | trunk/compilers/opsc/README.pod:
17:40 dalek parrot: [cage] Add a basic readme file, needed for generating a manpage for the executable.
17:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48238/
17:40 rurban mokko: how do I get from -lparrot to cygparrot2_6_0.dll? via libparrot.dll.a (the importlib)
17:42 rurban mokko: BTW parrot-2.6.0 for cygwin is almost ready to be uploaded. I just want to test rakudo-star with it
17:43 eternaleye joined #parrot
17:56 dalek parrot: r48239 | allison++ | trunk (2 files):
17:56 dalek parrot: [opsc] Manifest and metadata for new document file.
17:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48239/
17:56 dalek parrot: r48240 | mikehh++ | trunk/t/op/64bit.t:
17:56 dalek parrot: put in TODO for MSWin32 (64 bit) - tested what I could but not on that platform
17:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48240/
17:57 jdv79 is anyone working on IPC type stuff lately in parrot?
17:58 allison afterthought: rather than looking at users as an unsolvable dependency loop, can look at it as a virtuous cycle of refactoring (implement for the best guess, improve based on user feedback)
18:00 mikehh not 100% happy with r48240 - can someone else look at it regarding the todo bit
18:00 tcurtis joined #parrot
18:01 mikehh also test it on MSWin32 64 bit
18:03 tcurtis pmichaud: ping
18:04 NotFound Now that I think of it, a good use case can be using rakudo minidbi from other languages.
18:07 pmichaud tcurtis: pong
18:08 tcurtis pmichaud: should P6protoobject's ACCEPTS method be able to handle null PMCs?
18:09 tcurtis pmichaud: instead of dying with "Null PMC access in can()"?
18:09 LoganLK joined #parrot
18:09 pmichaud tcurtis: my initial reaction is that no, it shouldn't
18:09 jnthn No
18:10 tcurtis Alright.
18:26 chromatic joined #parrot
18:27 cotto For the record, my primary interest in Parrot is helping get it to the point where I can (1) have a performant and highly-compatible PHP implementation and (2) use libraries and functions from less crappy languages in code that runs on that implementation.
18:29 cotto but that possibility doesn't seem to be in any danger
18:29 NotFound How's php doing recently?
18:29 cotto Pipp?  It's been inactive for a long time.
18:30 mikehh NotFound: having problems with g++ build with src/utils.c:933: error: ‘Parrot_ext_call’ was not declared in this scope and also src/interp/inter_cb.c and src/scheduler.c and src/thread.c
18:30 NotFound No wonder I haven't seen any word about it, then X-)
18:31 NotFound mikehh: uh... I was about to buid trunk with c++ right now.
18:31 mikehh NotFound: get warnings in gcc build
18:31 NotFound mikehh: I usually look at warnings, but today is very hot day here.
18:32 mikehh not too bad here in Northern Scotland - onle 15 deg C
18:32 mikehh only
18:32 Austin Cotto will be the first to release PHP 6...
18:33 allison cotto: that's useful to know
18:33 cotto From what I've heard, it certainly won't be the PHP team itself.
18:34 Austin :-)
18:34 Austin Possibly one of their smarter decisions
18:35 cotto . o 0 (That language is such a mess.)
18:36 mikehh dunno: got to install PHP on my system as I just contracted to set up a web site that I worked on a year or so ago and got to build it from a backup from June last year :-{
18:39 NotFound mikehh: fixed, will commit in a few moments.
18:40 cotto allison, what are the necessary and sufficient criteria need to be met for Parrot's new object model?  The points you mentioned earlier seem necessary but not sufficient.
18:41 allison cotto: yes, that was describing the M0 level
18:41 NotFound cotto: it should work
18:41 cotto So anything that meets those criteria is a good possibility?
18:42 allison cotto: sufficient is "able to provide the base features necessary to implement Rakudo/Python/PHP/etc" object model
18:42 allison cotto: plus "able to provide the standard features those different models will use to talk to each other"
18:42 cotto I suppose "efficiently" should be in there too.
18:42 allison yah, efficiency is huge
18:46 cotto I guess if it were easy we'd already have such a model.
18:46 cotto ;)
18:46 jnthn It'd be wonderful if there was a way to say "I want a blob of memory that is the things needed for it to be a PMC + this extra amount"
18:47 dalek parrot: r48241 | NotFound++ | trunk/src (5 files):
18:47 dalek parrot: add extend.h in several places that needs it because of the swith to Parrot_ext_call, mikehh++
18:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48241/
18:47 jnthn Then a Rakudo object could be allocated as a single chunk of memory.
18:47 jnthn Rather than multiple.
18:47 jnthn Just a data point.
18:47 jnthn (For now, I suspect REPRs would just allocate the blob of memory they want and hang it off the data pointer...)
18:49 Austin Tene++ # git reset to your commit runs ok (won't say works, yet)
18:50 chromatic I'd like to get rid of the data pointer.
18:50 jnthn chromatic: Aye, but that depends on having a way to do what I just mentioned. :-)
18:51 jnthn chromatic: But halving the number of allocations we need for PMCs would seem like a big plus. :-)
18:51 chromatic Huge plus.
18:51 NotFound That conflicts with the desire of heavy use of fixed size allocators.
18:52 Austin msg Tene Based solely on visual inspection, your mod looks good. It does :nsentry for "our method" and doesn't do it for "method". Thanks! Tene++
18:52 purl Message for tene stored.
18:52 jnthn NotFound: Objects tend to outnumber types of objects, so you'd probably still get a good hit rate.
18:52 jnthn *vastly outnumber
18:53 chromatic If we merge PMCs and Objects and a PMC is a header + its necessary attribute storage allocated in one chunk, allocation gets a *lot* faster.
18:54 NotFound That can be tested right now without even get rid of the pointer, for pmc that uses auto_attrs.
18:55 NotFound You just allocate and set the pointer to allocated position.
18:55 chromatic Ah, true.
18:56 chromatic Requires GC changes though.
18:56 chromatic ... or test with the infinite GC.
18:56 NotFound Yes
18:57 NotFound Mmmm... the infinite GC isn't very appropiate to check speed benefits.
18:58 NotFound chromatic: Did you see my comment about the GC problem with opengl main loop?
18:58 chromatic I did, but I don't understand.
18:58 chromatic The infinite GC test could test allocation speed before and after.  It won't show speed of anything else.
18:59 NotFound I need to insert a sweep in the idle or timer function, or garbage doesn't get collected.
18:59 chromatic That's odd.
19:00 NotFound Don't have any idea why
19:00 sorear Don't forget morph.
19:00 * chromatic deprecates morph retroactively with his time machine
19:01 jnthn sorear: Just not going to implement morph for the Rakudo objects.
19:01 jnthn :-)
19:01 jnthn There, forgotten. :-)
19:01 NotFound Say it other way: Don't forget pmc_reuse
19:02 chromatic PMCS ARE NOW IMMUTABLE
19:02 sorear jnthn: Anybody who currently depends on autovivification may desire your hide for that
19:02 jnthn sorear: Auto-viv doesn't work like that.
19:02 chromatic Nor do windmills.
19:04 NotFound $ ack pmc_reuse src/ | wc -l
19:04 NotFound 77
19:04 chromatic $ ack -l pmc_reuse src/ | xargs rm
19:04 chromatic There, fixed!
19:07 sorear NotFound: That counts generated files!  Where do I sign up for the "write ack 2.0 and add svn:ignore support" post?
19:07 kthakore chromatic: hi
19:07 kthakore chromatic: I wanted to ask your permission to use perl6 book's layout for SDL::Manual
19:08 kthakore chromatic: http://sdlperl.ath.cx/SDL_Manual.letter.pdf
19:08 NotFound sorear: In a t-shirt at some convention, I guess
19:08 chromatic Fine by me, if moritz agrees.
19:09 jnthn chromatic: Did you get chance to look thorugh my parrot-dev post yesterday?
19:10 kthakore chromatic: thanks ... next to hunt mortiz
19:10 kthakore moritz
19:11 chromatic jnthn, I did right before sleep, and then I had weird dreams.
19:11 chromatic I need to think a lot more about protoobjects.
19:11 lucian joined #parrot
19:13 chromatic Arguably the distinction between "class" and "object" isn't useful with a MOP.
19:13 jnthn chromatic: It's really not.
19:13 jnthn chromatic: But I think a general "I want to serialize these objects" approach would give us what's needed.
19:13 chromatic You have *something* on which you can invoke an operation to "give me back something new".
19:13 jnthn chromatic: And kill a bunch of other birds with the same stone.
19:14 jnthn chromatic: *nod*
19:14 jnthn Well, I more explained those bits to set the scene for what I am looking for on the serialization front.
19:14 chromatic I think what you're asking for is "Give me a way to serialize things that don't have to be constant at PBC load time and forever after that."
19:15 jnthn chromatic: Right
19:16 jnthn chromatic: But more than that
19:16 jnthn chromatic: I'm asking for a way to attach objects to a "serialization todo list" as I generate PAST, so I can then put references to those things into the PAST tree (and thus eventually the PIR).
19:16 jnthn chromatic: And then when we make a PBC, we'd bundle those serialized things in thre.
19:17 jnthn *there
19:17 chromatic Right.
19:18 jnthn chromatic: The harder part is knowing where to stop and say "oh, here I want to serialize something saying it's actually a reference to this thing in this other PBC"
19:19 jnthn chromatic: I *think* easiest is that each thing registered for serialization gets a pointer to it's SC, and when we've deserialized things they also have a pointer to their SC, so we can just compare pointers as we walk the objects.
19:19 chromatic That sounds like a topological sorting of a graph.
19:20 jnthn Hmm, perhaps it could be seen that wya.
19:20 jnthn *way
19:20 jnthn chromatic: I'm currently working on prototyping a bunch of stuff. I'll try and add this into my prototype and see how it ends up.
19:22 chromatic That's separate from the MOP though.  I think I'd find them easier to understand if they stayed separate.
19:23 jnthn chromatic: +1
19:23 purl 1
19:23 jnthn purl: i hate you
19:23 purl jnthn: i'm not following you...
19:23 jnthn That's what she said.
19:23 chromatic Better serialization helps lots of things in Rakudo, not just the object system.
19:24 chromatic (summarizing for everyone else who might not have followed what I meant)
19:24 jnthn chromatic: Right, that's exactly what I was alluding to int he mail. :-)
19:24 jnthn *in the
19:24 jnthn chromatic: Done right, we can built Rat constants, Str literal objects, etc.
19:24 jnthn And use the same mechanism.
19:24 chromatic Let us celebrate our agreement with the adding of ice cream to pie.
19:24 jnthn \o/
19:24 chromatic I have some notes on a bare-bones MOP built from parametric roles.
19:25 jnthn Sounds kinda interesting.
19:25 chromatic First, I must clean house.
19:25 jnthn :-)
19:25 * jnthn should get on with his YAPC slides too
19:36 dalek parrot: r48242 | coke++ | trunk/runtime/parrot/library/P6object.pir:
19:36 dalek parrot: Avoid creating a PMC here, rely on autoboxing instead.
19:36 dalek parrot: Definite speedup in simple Rakudo benchmark. (.61s to .56s)
19:36 dalek parrot: all tests pass in rakudo & parrot.
19:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48242/
19:53 dalek winxed: r585 | NotFound++ | trunk/examples/for.winxed:
19:53 dalek winxed: remove for example, was buggy and a bad example
19:53 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=585
19:59 dalek blizkost: 5950aec | rurban++ | Configure.pl:
19:59 dalek blizkost: fix cygwin gcc detection
19:59 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​5950aecb70baaf651291cad0ff313f901388057f
20:04 dalek blizkost: 20b630e | rurban++ | src/pmc/bkmarshal.c:
20:04 dalek blizkost: windows linker
20:04 dalek blizkost: src/pmc/bkmarshal.c:299: error: external linkage required for
20:05 dalek joined #parrot
20:07 zostay joined #parrot
20:11 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#35198), fulltest) at r48242 - Ubuntu 10.04 amd64 (g++ with --optimize)
20:21 kthakore japhb: you will like this!
20:21 kthakore japhb: http://sdl.perl.org/blog-0001.html
20:35 petdance joined #parrot
21:10 baest joined #parrot
21:14 japhb kthakore, *chuckle*  Been there, done that!  :-)
21:14 japhb I bet Talon^ is having a blast ...
21:15 japhb kthakore, Who did the background for that page?
21:17 kthakore japhb: FROGGS
21:17 kthakore japhb: do it with the new SDL it is faster!
21:17 kthakore :D
21:17 kthakore japhb: except texturing sucks
21:18 kthakore gtg to a bday party
21:20 * tcurtis has seemingly managed to migrate PIRATE to use Tree::Optimizer in a branch. :)
21:23 mikehh rakudo (9b6189d) builds on parrot r48242 - make test PASS, spectest_smolder -> #35199 (pugs r31833) FAIL - Ubuntu 10.04 amd64 (g++ with --optimize)
21:23 mikehh t/spec/S02-builtin_data_types/bool.rakudo - Failed test:  41
21:23 mikehh t/spec/S05-mass/rx.rakudo - Failed tests:  91, 206-210
21:31 mikehh winxed r585 - builds on parrot r48242 - make test/test1/test2 PASS - Ubuntu 10.04 amd64 (g++ with --optimize)
21:36 tommyd joined #parrot
21:38 chromatic How far away is PIRATE?
21:47 tcurtis chromatic: from completeness, I don't know. From being fast enough to be sensibly usable, extremely far.
21:52 cotto It all comes back to making nqp's generated parsers faster.
21:54 chromatic There's a chicken and egg there; if better register allocation improves GC performance....
22:46 mikehh joined #parrot
23:13 chromatic Promoting a free software project (LWN guidelines): http://lwn.net/SubscriberLi​nk/397441/dbe389388398f604/
23:31 cotto good stuff there
23:43 theory joined #parrot
23:54 gbacon joined #parrot
23:58 Psyche^ joined #parrot

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

Parrot | source cross referenced