Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | fix 'make html' (talk to Coke), update tutorial (talk to tcurtis)
Set by moderator on 21 July 2010.
chromatic www.modernperlbooks.com/mt/2010/07/...-star.html 00:20
just for the record
particle did i miss the size of the p5 binaries? 00:24
chromatic Yes, one moment. 00:25
particle it's a little succinct, but it basically gets the point across.
Tene 99,944 MB of virtual memory? 97GB? 00:27
oh, 99.944
>< 00:28
particle points tene to code.google.com/webfonts
maybe something bigger? :P
whiteknight Austin: ping
chromatic 1,239,686 MB file size for p5121.
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
Tene particle: no, it actually has a comma there. 00:30
That was copy/pasted from the post.
My realization was that it was a typo.
chromatic I don't see MB there... now.
particle ah, so it does! i hadn't looked.
better. 00:31
now, off to the farmers' market! 00:32
chromatic Don't come back without a farmer.
NotFound The better part of developing a new language is not having to do comparatives with other versions X-) 00:34
Winxed is the better Winxed version that exists, period X-) 00:35
whiteknight If I want to add a method to a built-in type, what's the preferred way to do that, if any? 00:39
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 () {...} }"
whiteknight I don't think the namespace way is the right way, but I can't remember how PMCProxy does the search
tcurtis whiteknight: I don't know if it's the right way, but it appears to work.
whiteknight tcurtis: yeah, but I'm trying to inject them programmatically at runtime
tcurtis whiteknight: ah. I'm not sure, then. 00:41
sorear chromatic++ SANITY 00:43
chromatic I've so rarely been accused of that. 00:44
tcurtis whiteknight: have you tried add_method? It appears to work. 00:45
Tene yeah, add_method probably. 00:46
I expect.
whiteknight add_method? on Class? 00:47
tcurtis whiteknight: right.
whiteknight I can't remember if I tried that. I will now
tcurtis Well, on the Foo class, rather. 00:48
whiteknight error:imcc:syntax error, unexpected '(' ('(')\tin file 'EVAL_1' line 28032377 00:58
I won't even look, because I don't think my file has 28 million lines 00:59
imcc--
sorear sounds like the time gcc started complaining about a syntax error in /usr/include/wx/wxcore.h, near "#inelude" 01:00
chromatic I blame cotto. 01:01
NotFound At least is inteligent enough to figure it was unexpected X-) 01:02
cotto_work oh noes
What did I do?
Coke chromatic: nifty article. +1. 01:04
chromatic++
chromatic Thanks. 01:06
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:07
szbalint chromatic++ # indeed. 01:10
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
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:32
chromatic Why would it need a stack? 01:33
cotto_work to know where to return to
chromatic Not with CPS, right? 01:34
cotto_work CPS is on top of Lorito, so it can't be used in Lorito itself.
chromatic Unless we always know the location of the return PC. 01:36
But I see your point.
I think goto is sufficient at M0.
Coke hears fallout 3 calling him. 01:39
cotto_work To put it more concretely, what does a recursive function-based fib function look like in Lorito? 01:40
chromatic Let me type up some ideas. 01:43
cotto_work goes hoem 01:44
atrodo working on "invokeable" pmc's now 01:45
sorear> it should be mentioned that / in pascal is the floating point divide. The DIV operator is the integer divide. 01:47
sorear atrodo: the code I was reverse engineering was written dumbly, ok. I beleive that. 01:49
NotFound Maybe it was intentional. 01:52
BTW freepascal has condtional operator? I never seen that thing in pascal. 01:53
atrodo plus, i've never been a big fan of fpc. 01:56
whiteknight saying "cps is on top of Lorito" is sort of a misconception 02:04
it's not on top of Lorito, it's just explicit in it
the first argument of every function call is considered to be a return continuation
so a "return" statement is really a "invoke argument 1" operation 02:05
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
nopaste "chromatic" at 192.168.1.3 pasted "rough description of recursive, non-optimized fib in M0 for cotto" (30 lines) at 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
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
atrodo: but "classic" CPS treats the return continuation as the first argument of every function call
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:10
kid51 atrodo: Will the code at github.com/atrodo/lorito compile independently of parrot? 02:12
atrodo kid51> yes 02:13
kid51 So, in principle, it can be treated as its own little OS project.
atrodo At this point, yes
chromatic You can emulate stackful calling with CPS, but you can't go the other way around. 02:15
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
we can "cheat" a little
chromatic Cheat how? 02:17
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.\\
atrodo strictly speaking, i don't think we do. But it makes it convenient for the common case. 02:21
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
chromatic It's at least one extra GCable per invocation.
atrodo but you have that GCable anyways. It a matter of is it passed in the context or as an arg 02:23
sorear> kylix 3 takes a program of that snipplet and makes it 30k. fpc makes it 121k 02:24
chromatic I have Kylix around here somewhere. 02:26
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?
atrodo hmmmm, i suspect I may not understand your methodology 02:28
chromatic fib( CONTINUATION, number ) 02:30
To return, invoke the CONTINUATION
Oh, I see what you're saying. 02:31
I figure that CONTINUATION *contains* the registers
Other person in office: Are you mad? 02:32
Me: No, I just confused myself.
02:32 davidfetter joined
atrodo A continuation is just a reference to a point in the code? 02:33
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.
whiteknight it's a snapshot of the state of the VM 02:35
purl forget not just
purl whiteknight: I forgot not just
sorear atrodo: I don't know what kylix is but it doesn't affect my point - *free pascal* sucks for performance coding 02:38
atrodo kylix == delphi for linux 02:39
and you're right, it doesn't affect your point. But it peaks my interest
kid51 msg Coke please see trac.parrot.org/parrot/attachment/t...cg.pl.diff 02:40
purl Message for coke stored.
02:41 janus joined
atrodo sorear> 13 instructions for kylix 02:46
dalek kudo: 685c1e7 | (Solomon Foster)++ | src/core/Range.pm:
Try to optimize finite Int Range iteration.
 02:52
kudo: 9b6189d | (Solomon Foster)++ | src/core/Range.pm:
Just go ahead and pass an Array to ConsIter -- makes the code a bit cleaner,

much.
03:37 dalek joined 03:39 dukeleto joined 03:41 PerlJam joined 03:44 Util joined, pmichaud joined 03:48 chromatic joined 04:51 eternaleye_ joined
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 www.borland.com/kylix . gilc is a kylix coder.
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#35188), fulltest) at r48233 - Ubuntu 10.04 amd64 (gcc with --optimize) 06:07
cotto atrodo, what are those instruction counts you've been posting? 06:19
nm. found it 06:28
06:34 robin-gvx joined 07:06 fperrad joined, AzureStone joined 07:08 jjore joined 07:11 snarkyboojum joined 07:52 eternaleye joined, AzureStone joined, darbelo_ joined 08:33 eternaleye joined 09:21 rurban_ joined 09:38 snarkyboojum joined 09:39 cognominal joined 09:41 cognominal joined 10:15 lucian joined 11:18 whiteknight joined 12:04 kid51 joined, tommyd joined 12:17 baest joined 12:28 rurban joined 12:53 hudnix joined, khisanth_ joined 13:06 allison joined
allison I need documentation for ops2c for the Debian manpage. 13:06
(the manpage is required for every binary)
13:08 robin-gvx joined
allison in theory, it shouldn't be installed, but in practice Rakudo depends on it 13:09
jnthn In practice, every language that has dynops would depend on it, no? 13:12
allison in the past we've used other tools for that, but yes, in the future all languages should use opsc 13:14
it really should have been named parrot-opsc, though
installing a binary as generically named as opsc into the main usr/bin of the distro is very unfriendly 13:15
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?
jnthn: would that make it impossible to build Rakudo from the distro version of parrot?
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.
allison NotFound: my goal here is to make it possible to package Rakudo * for Debian
jnthn OPS2C = $(PARROT_BIN_DIR)/ops2c$(EXE) 13:18
Yes, it's hardcoded as looking for ops2c, so renaming it would break things.
NotFound I think we should add an option to parrot to search for pbc in the runtime dir, and use that instead of fakecutables,
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
jnthn allison: OK, sounds workable. 13:20
NotFound (Don't even talk about debates over parrot_... vs parrot-....)
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
NotFound: heh :)
NotFound: personally I go for "foo_bar" is a function name and "foo-bar" is an executable 13:21
NotFound: perhaps a group reviewed coding standards entry is in order
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.
allison if the fakecutables are just symlinks, it's far less of a headache 13:23
NotFound There are platforms without symlinks.
allison yup, and there are platforms without shebang lines 13:24
(which would be the other simple solution)
we have the same problem for language binaries
NotFound To using shebang lines with pbc we'll need to change pbc header and some trickery. 13:25
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:28
jnthn On Windows it's just a file extension association. :-) 13:29
Windows++
karam Windows
aww
:-)
NotFound jnthn: ...that almos nobody uses X-) 13:30
allison it's easy enough to run parrot foo.pbc
but the killer is the *path* to foo.pbc
NotFound allison: we just need to add an option to enable libpath search
allison NotFound: don't we already have libpath search? 13:31
ah, you mean from the command-line
NotFound allison: for load_bytecode, but not for command line main program.
allison but then we'd just be duplicating the PATH of existing operating systems 13:32
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
perl doesn't, python doesn't 13:34
if Java does, I don't take that as a good example
(I've been in Java dependency hell)
not necessarily saying we shouldn't
NotFound We are in fakecutable hell right now.
allison just saying I'm not sure it's an improvement over our fakecutables 13:35
it'd be nice to trim down our fakecutables to simple PIR scripts that load the library
13:36 bacek joined
allison instead of the current bloatware 13:36
kthakore NotFound: hi
NotFound kthakore: ho
allison that would be a step in the right direction
kthakore NotFound: that incremental patch idea is .. not working
NotFound: stringhandle needs more tought ... 13:37
any place I can go to learn more about io/api.c and general IO philoshy in parrot?
NotFound: deeper down the parrot hole ...
NotFound kthakore: my main view about IO philosophy in parrot is: it needs a lot of work ;) 13:38
kthakore NotFound: lmao ... ok break
gonna go outside ...
13:38 ambs joined
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
kthakore: that's the best place to start
kthakore allison: oh thanks I looked at that
what I am confused is
NotFound kthakore: Can't you start by the simple step of changing the way open works?
kthakore why some IO handles (string in this case) have the guts in io/api.c
I mean wouldn't it make more sense to just call straight to Perl_io_open 13:40
then decide which open to call on the pmc
but it doesn't do this
allison kthakore: they shouldn't have guts in io/api.c
kthakore I know! That is what NotFound asked me to fix 13:41
13:41 s1n joined
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
but, it was slow
kthakore NotFound: I have done that ... but other things start braking
oh ...
NotFound kthakore: probably just because someone wrote it that way and no one has refactored yet. In some cases, trying to gain some speed.
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
kthakore ok so what if we not have Perl_io_open
and just call open stright to pmc for file and string
allison I don't know what you mean by Perl_io_open
kthakore it is a method in io/api.c
NotFound allison: what is slow is to call a method for any IO operation, but open and close are hardly as critical.
allison kthakore: you mean Parrot_io_open? 13:43
kthakore oh!
sorry
allison: I have been staring at code for too long
allison: my apologies
13:44 PacoLinux joined
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.
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
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.
trac.parrot.org/parrot/ticket/1639
thank you.
allison but, we've killed the 'open' op now anyway
so, the only way to call Parrot_io_open is from within C
NotFound Even less sense on doing open that way, then. 13:46
allison yeah, we're not gaining anything anymore
NotFound I thought that was a easy task, can't figure what problem he's having. 13:47
Maybe just summer ;)
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.
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
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
allison and StringHandle shouldn't be calling Parrot_io_open at all
fair enough 13:51
and we don't really want the opcode deciding whether to call a method or not
though, it's better than hardcoding behavior into Parrot_io_open
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"
at least then we're not special casing for each special filehandle type 13:53
kthakore NotFound: you can never discourage me :D
NotFound allison: avoiding the special case in StringHandle is the first step in that direction.
kthakore NotFound: crap chores are calling
allison NotFound: actually, the special case in Parrot_io_open looks like it's already entirely avoidable 13:55
NotFound: just make sure StringHandle has a method named "open". 13:56
NotFound allison: it has... It call io_open
allison which calls Parrot_io_open and starts a loop? 13:57
does that actually do anything for StringHandle?
NotFound StringHandle open call Parrot_io_open, and Parrot_io_open special cases it to avoid calling the open method. That's the issue. 13:58
allison All Parrot_io_open does for the 'open' method is set the mode flags, which can be done directly 14:01
Austin whiteknight: pong 14:06
allison adding my comments to the ticket
darbelo_ o/ 14:10
darbelo \\o
NotFound Done 14:18
darbelo allison: Did you see my last blog post? 14:22
dalek rrot: r48234 | NotFound++ | trunk/src (2 files):
call StringHandle.open from Parrot_io_open, not the other way
14:25 patspam joined
NotFound (Killing cows)++ and make steaks of them even better. 14:28
allison darbelo: not yet 14:32
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.
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
NotFound allison: for substr optimization, I think. 14:35
Is not cow anymore, but still uses the cow support structures.
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.
allison figuring out the sensible way to support substr's features
darbelo: yes, I'm in favor of it 14:37
we didn't make a clean break with COW when we shifted to immutable strings, so it's time to take the next steop
step
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.
darbelo: I think it can be done in trunk. 14:41
Unless it's too dificult to keep your branch in sync. 14:42
atrodo allison> cotto mentioned that you have some concerns about p&w? 14:43
14:44 robin_gvx joined
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:45
I think I should go with 'outside' since it's really independent of nfg. 14:46
allison atrodo: p&w? 14:47
purl i heard p&w was tinyurl.com/23dfwut
atrodo botsnack
purl :)
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
p&w have some good ideas, but it's not a perfect fit
basically, they weren't thinking of Parrot, so there's no way they could design perfectly for Parrot
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
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.
allison atrodo: it goes the other direction "what of their idea should we include in Parrot?"
jnthn: thanks, that's helpful
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
14:51 patspam joined
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.
darbelo simpler++
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"
allison jnthn: it is largely the same question
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.
allison jnthn: we probably don't have the luxury of waiting that long
jnthn: (if you mean "wait until we have two interoperating languages")
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
14:54 macroron joined
allison jnthn: the reason it's so poorly tested, exercised, etc, is that no one really has a critical use for it 14:54
NotFound Maybe the problem is to try to overengineering interoperability. 14:55
allison NotFound: "avoid"?
(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.
jnthn allison: Oh, I agree with "as little as possible", or at least in the sense of "as little as possible to be useful".
allison what interoperability doesn't mean is that a (for example) Python object will support all the Perl 6 method calls
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
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"
jnthn allison: Yes, a delegatory model is certianly the view we're tending to look at from the Perl 6 side. 14:59
NotFound That's what I call overengineering, trying to solve problems that no one had yet. 15:00
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, [1]Casan joined
allison jnthn: the motivation is that it *has* been considered an important thing in the past 15:02
jnthn: it's still worth supporting to the extent that it doesn't totally foobar the system 15:03
jnthn: but perhaps not quite as important to be quite as... er, extensive?... in supporting it
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:04
allison NotFound: yeah, I think what we have now is pretty good 15:05
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
NotFound allison: agree 15:06
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
allison NotFound: (and maybe even enhance the simplicity)
atrodo but I'm asking these questions on the lorito side
allison atrodo: back to p&w? 15:08
atrodo the object model ideas in general
or rather, object model for pmc's in general 15:09
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:11
c) to provide attributes storage and retrieval, d) to provide invocation for both public and hidden functionality 15:12
NotFound Extra bonus point if it can support some degree of public/protected/private support. 15:13
atrodo NotFound> that's actually a flaw I've yet to solve, or even decide if it's reasonable or possible 15:14
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
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
I should say "call a standard thingy"
NotFound allison: C++ for example doesn't do runtime checks, it just uses the information to be able to signal the error while compiling.
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.
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.
atrodo allison> I thought that the desire was to combine vtables and methods
NotFound atrodo: that's an error. Is not security, is design,
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"
NotFound Obscurity will be: "that method doesn't exist", design is "that method is provate"
allison atrodo: the desire is to do away with the current implementation distinctions between vtables and methods, yes
atrodo: but, we will still have some "methods" that are for internal use, rather than exposed for direct calls from the users 15:21
atrodo: things like "get_bool" to access the boolean value of the object
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)
atrodo: if it helps, think of it as "what objects expose to the language users" and "how objects talk to each other"
NotFound BTW, there is some way to call set_bool from pir? 15:23
allison nope, just set_integer_native
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?
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
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.
Let's deprecate it.
allison but if all "vtable" functions were exposed from PIR, it's perfectly possible to need to set the two values differently
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:29
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 ;)
atrodo allison> got to go, but I've got lots to think about. Thanks for the braindump 15:32
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.
whiteknight ok
I'll be around
15:42 allison joined 16:00 mokko joined
mikehh can't figure out how to do a proper todo using runtime/parrot/library/Test/More.pir 16:00
dalek rrot: r48235 | allison++ | trunk/ports/debian/parrot-devel.install.in:
[debian] Apply a patch from Matt Kraai selecting appropriate new NQP files to
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
mokko make complains with cannot find -lparrot 16:02
16:07 simcop2387 joined
mokko any help appreciated 16:07
I get the same error with rakudo star tar and with source from github 16:24
allison mokko: I don't have an install of cygwin handy to help you 16:26
mokko: are you using parrot cygwin packages, or letting rakudo build parrot itself?
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
in the meantime I uninstalled cygwin packages
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
@allison. Yes, I tried that. Then I run into the ld error saying it cant find lparrot 16:31
when I compiled parrot myself under cygwin, I had problems with that cygparrot_2_6_0.dll, could it be the same? 16:32
allison mokko: it's possible, yes 16:33
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:34
particle mokko: you may need to move libparrot.lib to the root directory of the build, rather than in some subdir 16:36
move/copy
mokko thanks. I will try.
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:44
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:48
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:53
allison Coke: not go 16:54
Coke: it's just that there are an infinite number of definitions of what "interop" means
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.
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:56
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:57
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.
NotFound The good use is to avoid that.
16:58 patspam1 joined
Coke the "provide a base for brand new languages" was an interesting tangent, but not one I cared about. 16:58
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
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
Coke allison: how many languages target parrot at the moment that are in any way complete? 17:01
allison 0
jnthn allison: Er, maybe because there's no Python 2.5 compiler?
NotFound allison: they don't even switch to later pythons, no wonder.
particle lua is complete.
jnthn allison: That's not a demonstration of lack of interest in language interop.
allison yes, I agree that they can't at the moment anyway
jnthn allison: That's a lack of ability to even try it.
Coke allison: wow, did you miss the Rakudo * release this week? ;)
allison but they aren't even interested anymore
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.
mikehh we have not got a demo of interoperability, so we have no use cases
allison Coke: re Rakudo, that's being billed as useful, usable, early adopter, not "complete
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.
allison I'm not trying to argue that we drop interop
I'm more offering a perspective on what interop means
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
allison: your perspective on it in the past was pretty much "so little as to be useless", as I recall.
allison it means the ability to call functions, call methods on objects, and set and get attributes of objects
particle Coke: are those the same people who have been shitting on parrot for years?
Coke not that /you/ phrased it that way. (was how I read it.)
particle: no. they don't care about parrot enough to do that. 17:05
they're just trying to get their jobs done.
allison yah, that's what I'm trying to get at, most people are just trying to get their jobs done
if we can help them, we're compelling
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 :)
it's just so freakishly hard to write for users when you don't have any :(
honestly, I don't know if interop is useful or not, and won't know until a user asks for it 17:07
it probably is useful
Coke [: facepalm :]
so, allison; we never had elections. presumably we are in violation of our charter or something?
mikehh bearing in mind most parrot 'users' would be developers 17:08
allison there's not a strict time on it
just, have to have elections annually
we could announce them tomorrow and hold them in two weeks and be fine
NotFound Actually I don't care much about interop because all tests I've do worked. 17:09
If I locate a problem, I'll care about it.
allison NotFound: it's a good perspective, but again runs into the lack of users 17:10
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
Coke user's can use what isn't there.
*can't*
allison and they can't ask for what they don't know they need 17:11
NotFound Use cases will come with interesting modules.
allison and interesting modules will come with... a usable system?
NotFound Yeah
mokko @allison: seems to work now. I had to copy cygparrot.dll to parrot_install/bin
Coke which, after 10 years, we're nearly there. ;) 17:12
allison mokko: excellent!
purl Smithers, release the hounds!
mikehh if we get stuff working with plumage, surely that is some form of interop
Coke mokko: rurban is in #perl6 on freenode right now working on packaging things up. You could talk to him.
allison mmm... well it seems like a usable system somewhat depends on use cases
(knowing what you're implementing for)
Coke I'm leaving now. =-)
17:12 Coke left
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.
mikehh NotFound: yes it seemed to work quite well 17:14
NotFound mikehh: I've having it running for several days, without crashing and without leaking memory. 17:15
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
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.
Looks like the gc is never invoked from inside of the opengl main loop. 17:18
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 17:21 theory joined
rurban mokko: my patches for the cygwin package are at code.google.com/p/cygwin-rurban/sou...ase/parrot 17:33
dalek rrot: r48236 | allison++ | trunk/ports/debian/patches (2 files):
Add a patch to insert a man file for the ops2c executable.
 17:40
rrot: r48237 | allison++ | trunk/ports/debian (4 files):
[debian] Prepare for 2.6 packages.
rrot: r48238 | allison++ | trunk/compilers/opsc/README.pod:
[cage] Add a basic readme file, needed for generating a manpage for the executable.
rurban mokko: how do I get from -lparrot to cygparrot2_6_0.dll? via libparrot.dll.a (the importlib)
mokko: BTW parrot-2.6.0 for cygwin is almost ready to be uploaded. I just want to test rakudo-star with it 17:42
17:43 eternaleye joined
dalek rrot: r48239 | allison++ | trunk (2 files):
[opsc] Manifest and metadata for new document file.
 17:56
rrot: r48240 | mikehh++ | trunk/t/op/64bit.t:
put in TODO for MSWin32 (64 bit) - tested what I could but not on that platform
jdv79 is anyone working on IPC type stuff lately in parrot? 17:57
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) 17:58
mikehh not 100% happy with r48240 - can someone else look at it regarding the todo bit 18:00
18:00 tcurtis joined
mikehh also test it on MSWin32 64 bit 18:01
tcurtis pmichaud: ping 18:03
NotFound Now that I think of it, a good use case can be using rakudo minidbi from other languages. 18:04
pmichaud tcurtis: pong 18:07
tcurtis pmichaud: should P6protoobject's ACCEPTS method be able to handle null PMCs? 18:08
pmichaud: instead of dying with "Null PMC access in can()"? 18:09
18:09 LoganLK joined
pmichaud tcurtis: my initial reaction is that no, it shouldn't 18:09
jnthn No
tcurtis Alright. 18:10
18:26 chromatic joined
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:27
but that possibility doesn't seem to be in any danger 18:29
NotFound How's php doing recently?
cotto Pipp? It's been inactive for a long time.
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-)
mikehh: uh... I was about to buid trunk with c++ right now. 18:31
mikehh NotFound: get warnings in gcc build
NotFound mikehh: I usually look at warnings, but today is very hot day here.
mikehh not too bad here in Northern Scotland - onle 15 deg C 18:32
only
Austin Cotto will be the first to release PHP 6...
allison cotto: that's useful to know 18:33
cotto From what I've heard, it certainly won't be the PHP team itself.
Austin :-) 18:34
Possibly one of their smarter decisions
cotto . o 0 (That language is such a mess.) 18:35
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:36
NotFound mikehh: fixed, will commit in a few moments. 18:39
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:40
allison cotto: yes, that was describing the M0 level 18:41
NotFound cotto: it should work
cotto So anything that meets those criteria is a good possibility?
allison cotto: sufficient is "able to provide the base features necessary to implement Rakudo/Python/PHP/etc" object model 18:42
cotto: plus "able to provide the standard features those different models will use to talk to each other"
cotto I suppose "efficiently" should be in there too.
allison yah, efficiency is huge
cotto I guess if it were easy we'd already have such a model. 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"
dalek rrot: r48241 | NotFound++ | trunk/src (5 files):
add extend.h in several places that needs it because of the swith to Parrot_ext_call, mikehh++
 18:47
jnthn Then a Rakudo object could be allocated as a single chunk of memory.
Rather than multiple.
Just a data point.
(For now, I suspect REPRs would just allocate the blob of memory they want and hang it off the data pointer...)
Austin Tene++ # git reset to your commit runs ok (won't say works, yet) 18:49
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. :-)
chromatic: But halving the number of allocations we need for PMCs would seem like a big plus. :-) 18:51
chromatic Huge plus.
NotFound That conflicts with the desire of heavy use of fixed size allocators.
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.
jnthn NotFound: Objects tend to outnumber types of objects, so you'd probably still get a good hit rate.
*vastly outnumber
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:53
NotFound That can be tested right now without even get rid of the pointer, for pmc that uses auto_attrs. 18:54
You just allocate and set the pointer to allocated position. 18:55
chromatic Ah, true.
Requires GC changes though. 18:56
... or test with the infinite GC.
NotFound Yes
Mmmm... the infinite GC isn't very appropiate to check speed benefits. 18:57
chromatic: Did you see my comment about the GC problem with opengl main loop? 18:58
chromatic I did, but I don't understand.
The infinite GC test could test allocation speed before and after. It won't show speed of anything else.
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.
NotFound Don't have any idea why 19:00
sorear Don't forget morph.
chromatic deprecates morph retroactively with his time machine
jnthn sorear: Just not going to implement morph for the Rakudo objects. 19:01
:-)
There, forgotten. :-)
NotFound Say it other way: Don't forget pmc_reuse
chromatic PMCS ARE NOW IMMUTABLE 19:02
sorear jnthn: Anybody who currently depends on autovivification may desire your hide for that
jnthn sorear: Auto-viv doesn't work like that.
chromatic Nor do windmills.
NotFound $ ack pmc_reuse src/ | wc -l 19:04
77
chromatic $ ack -l pmc_reuse src/ | xargs rm
There, fixed!
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
chromatic: I wanted to ask your permission to use perl6 book's layout for SDL::Manual
chromatic: sdlperl.ath.cx/SDL_Manual.letter.pdf 19:08
NotFound sorear: In a t-shirt at some convention, I guess
chromatic Fine by me, if moritz agrees.
jnthn chromatic: Did you get chance to look thorugh my parrot-dev post yesterday? 19:09
kthakore chromatic: thanks ... next to hunt mortiz 19:10
moritz
chromatic jnthn, I did right before sleep, and then I had weird dreams. 19:11
I need to think a lot more about protoobjects.
19:11 lucian joined
chromatic Arguably the distinction between "class" and "object" isn't useful with a MOP. 19:13
jnthn chromatic: It's really not.
chromatic: But I think a general "I want to serialize these objects" approach would give us what's needed.
chromatic You have *something* on which you can invoke an operation to "give me back something new".
jnthn chromatic: And kill a bunch of other birds with the same stone.
chromatic: *nod* 19:14
Well, I more explained those bits to set the scene for what I am looking for on the serialization front.
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."
jnthn chromatic: Right 19:15
chromatic: But more than that 19:16
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).
chromatic: And then when we make a PBC, we'd bundle those serialized things in thre.
*there 19:17
chromatic Right.
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:18
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.
jnthn Hmm, perhaps it could be seen that wya. 19:20
*way
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.
chromatic That's separate from the MOP though. I think I'd find them easier to understand if they stayed separate. 19:22
jnthn chromatic: +1 19:23
purl 1
jnthn purl: i hate you
purl jnthn: i'm not following you...
jnthn That's what she said.
chromatic Better serialization helps lots of things in Rakudo, not just the object system.
(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. :-)
*in the
chromatic: Done right, we can built Rat constants, Str literal objects, etc.
And use the same mechanism.
chromatic Let us celebrate our agreement with the adding of ice cream to pie.
jnthn \\o/
chromatic I have some notes on a bare-bones MOP built from parametric roles.
jnthn Sounds kinda interesting. 19:25
chromatic First, I must clean house.
jnthn :-)
jnthn should get on with his YAPC slides too
dalek rrot: r48242 | coke++ | trunk/runtime/parrot/library/P6object.pir:
Avoid creating a PMC here, rely on autoboxing instead.

all tests pass in rakudo & parrot.		 19:36
nxed: r585 | NotFound++ | trunk/examples/for.winxed:
remove for example, was buggy and a bad example
 19:53
izkost: 5950aec | rurban++ | Configure.pl:
fix cygwin gcc detection
 19:59
blizkost: 20b630e | rurban++ | src/pmc/bkmarshal.c: 20:04
blizkost: windows linker
blizkost: src/pmc/bkmarshal.c:299: error: external linkage required for
20:05 dalek joined 20:07 zostay joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#35198), fulltest) at r48242 - Ubuntu 10.04 amd64 (g++ with --optimize) 20:11
kthakore japhb: you will like this! 20:21
japhb: sdl.perl.org/blog-0001.html
20:35 petdance joined 21:10 baest joined
japhb kthakore, *chuckle* Been there, done that! :-) 21:14
I bet Talon^ is having a blast ...
kthakore, Who did the background for that page? 21:15
kthakore japhb: FROGGS 21:17
japhb: do it with the new SDL it is faster!
:D
japhb: except texturing sucks
gtg to a bday party 21:18
tcurtis has seemingly managed to migrate PIRATE to use Tree::Optimizer in a branch. :) 21:20
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
t/spec/S02-builtin_data_types/bool.rakudo - Failed test: 41
t/spec/S05-mass/rx.rakudo - Failed tests: 91, 206-210
winxed r585 - builds on parrot r48242 - make test/test1/test2 PASS - Ubuntu 10.04 amd64 (g++ with --optimize) 21:31
21:36 tommyd joined
chromatic How far away is PIRATE? 21:38
tcurtis chromatic: from completeness, I don't know. From being fast enough to be sensibly usable, extremely far. 21:47
cotto It all comes back to making nqp's generated parsers faster. 21:52
chromatic There's a chicken and egg there; if better register allocation improves GC performance.... 21:54
22:46 mikehh joined
chromatic Promoting a free software project (LWN guidelines): lwn.net/SubscriberLink/397441/dbe389388398f604/ 23:13
cotto good stuff there 23:31
23:43 theory joined 23:54 gbacon joined 23:58 Psyche^ 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!