Parrot 1.2.0 released | parrot.org/ | Weekly Priority: Profiling | Parrot VM Workshop, Pittsburgh, June 20-21
Set by moderator on 7 June 2009.
Whiteknight darbelo++\\ 00:00
(going to the hospital if you are sick enough to hallucinate)++
(bringing a laptop so you can continue coding at the hospital)+
Tene darbelo: that's what revision control is for. 00:02
00:04 snarkyboojum joined
Whiteknight what he needs is health control: Revert back to the last healthy state 00:05
GeJ can git do that already?
darbelo Whiteknight: I support the idea as long as you don't need to 'bisect' in order to find the last healthy state. 00:07
00:09 itrekkie joined
jonathan sjohnson: 00:10
oops
00:10 itrekkie left
jonathan I didn't even want to say anything too him. 00:10
pmichaud: Going to rest now, if you want me to test some install stuff tomorrow, drop me a mail or a /msg and I'll try and get to it. 00:11
00:13 bacek joined 00:23 Zak joined 00:29 payload joined
dalek cnum-dynpmcs: r84 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
Move the guts of the set_rounding_mode() METHOD to a helper function.
 00:50
00:56 flexibeast joined 00:58 ZeroForce joined
japhb Tene: about? 01:12
Tene japhb: what's up? 01:24
purl Me, you bitches! I'm high on crack!
cotto and suddenly it all makes sense 01:25
japhb [OT] OK, I don't like purl responding to everything not aimed at a particular user, but I get that people can disagree, fine. However, responding randomly to a directed message? That's just annoying. 01:26
Anyway,
Tene japhb: afaik, I'm still blocking on S11 feedback from pmichaud
cotto japhb, +1
japhb Tene: I've been AFK for a few days. Did you manage to get the export/import stuff further along?
Tene if that's what you're asking.
japhb Ah. Hmmmm. I'm not sure pmichaud still knows he's a blocker. Or if he does, that it is still on his short-term list. 01:27
Can we get at least the export-understands-array-and-hash bit, if not anything else?
Tene purl: msg pmichaud Using OpenGL from rakudo in the next release is blocking on symbol renaming in library export in the 'parrot' compiler, which you asked to block on your API designs from S11 review. 01:28
purl Message for pmichaud stored.
japhb :-)
Tene japhb: I'm actually in a bit of a panic in my life right now, but it shouldn't be too hard to implement whatever API for someone comfortable with PIR. I can show you where. 01:29
runtime/parrot/languages/parrot/parrot.pir
it should be in the 'export' method in that file.
japhb Tene: fair enough. Make my own dogfood, I'm fine with that.
... and sorry to hear about panic. Hope situation improves soon. 01:30
Tene japhb: if you really need me to do it, let me know, and I'll allocate some time, once you've gotten feedback of any kind from pmichaud.
Oh, it will. It's all time-sensitive, and should expire by midway through next week.
It's just that the release is happening the day before my panic expires. :)
japhb Tene: if it's straightforward PIR, I have a decent chance of doing it. It's the Parrot C code that I am in fear of. 01:31
Tene japhb: There's no C involved in this.
so you're safe.
japhb (Mostly because so many of the core Parrot C coders are in fear of it, and I figure there's probably a reason. :-)
Excellent.
Tene it's only that file.
japhb nodnod 01:32
Tene iirc, pmichaud was worried about allowing an API in that would require deprecation notices to remove or change later. That's the main reason he didn't want me to put something temporary in.
japhb Isn't there some way to mark something as experimental? 01:33
In fact, isn't cross-language import/export all in that category?
Tene Well, nobody is actually using this stuff at all for anything yet, afaict.
japhb Since everything I'm doing is experimental, I'm not terribly worried about depending on an API that is officially experimental. :-) 01:34
Tene I think pmichaud wanted to migrate most of the PIR libs to use this sometime soon, maybe. 01:35
Anyway, feel free to experiment locally, or commit to a branch, but confirm with pmichaud before committing to trunk. Having a patch or branch will likely be helpful regardless of how he decides. 01:36
Anything else before I AFK?
japhb Nope, thank you very much.
Tene Yeah, no problem.
japhb: also, in the future, go ahead and just ask your question with my name attached. I'll see it eventually, even if I'm not around right then, and respond similarly. 01:37
AFK, driving home.
japhb Tene: gotcha. Didn't remember you were a backlogger 01:38
pmichaud I haven't forgotten about the S11/api stuff. 01:42
I haven't completely resolved it in my head yet, either. But it's on my agenda to resolve before the release.
japhb pmichaud: Fair enough. I'll ask you the same question I asked Tene: Is there a way to mark an API as officially experimental, to void the whole problem with invoking the wrath of the deprecation gods? 01:43
pmichaud japhb: I'm not aware of one (nor am I the person to be able to create one) 01:44
japhb hmm
pmichaud Our best bet would be to create the API and immediately deprecate it :-)
japhb I doubt it's going to be a problem in this particular case, but generalizing that sure feels like a way for the perfect to become the enemy of the good.
heh
pmichaud I've done that once before.
japhb hmmm 01:45
pmichaud I haven't come up with answers in the next day or so, I'll say to go ahead and apply whatever you and Tene++ have worked out and we'll just deprecate them immediately, so that we have the ability to change it later.
Of course, deprecations don't matter until the July release anyway.
So it's the July deadline that's important, not the June one.
japhb nod
01:52 chromatic joined
japhb pmichaud,Tene: Tene pointed me to the implementation of the parrot compiler's .export() method. Where is import() implemented? 01:53
pmichaud it might not be for the parrot compiler yet.
It is in rakudo, though.
japhb That's the one I'm looking for. 01:54
pmichaud src/builtins/compiler.pir
japhb Ah, OK, I was trying to find it in PCT. 01:55
pmichaud right, that's the part that still needs a bit of design work.
(well, one part among several)
japhb Does Perl6::Compiler::parse_name() handle the ':from<other_lang>' bit? 01:58
pmichaud no.
it's simply to take a name and split it up according to namespace rules (that's in the pdd) 01:59
according to the rules for the language
japhb OK. I think I know what I need to do for a proof of concept. But it will have to wait for dinner. :-) 02:02
02:16 Theory joined 02:18 eternaleye joined 02:28 kid51 joined 02:35 janus joined 02:46 rakudohudson joined
pmichaud is there a way to determine the path sequence that parrot is using for .loadlib ? 02:47
it appears to me that it prefers installed copies of libraries to any locally built ones
02:49 dukeleto joined
chromatic One of the IGLOBALS is an *Array* PMC you can query. I don't remember which one. 02:50
pmichaud that helps.
bacek IGLOBALS_LIB_PATHS
chromatic That sounds right.
bacek get_search_paths in src/library.c 02:51
pmichaud how do I use IGLOBALS?
(haven't used it afaik)
interpinfo? 02:52
purl it has been said that interpinfo is the culprit there.
chromatic There's a constants PASM file that gives you access to individual entries.
I'd have to ack the tests to find an example. 02:53
pmichaud right, I got that part
looks like it's subscript access on a ParrotInterpreter PMC
ResizableStringArray (size:3) [ 02:54
"runtime/parrot/dynext/",
"/home/pmichaud/rakudo/parinst/lib/parrot/1.2.0-devel/dynext/",
"dynext/"
],
that looks.... annoying.
chromatic It's modifiable though, which is a nasty hack. 02:55
pmichaud well, here's the anti-use case
(1) someone downloads Rakudo, builds against installed parrot
(2) install Rakudo, copying the Rakudo dynext into the parrot install tree 02:56
(3) download updated version of Rakudo, build against installed parrot
this last build ends up using the installed dynexts, instead of the ones just created as part of the build
chromatic That does seem wrong. 02:57
It's easy to create another use case where this behavior is right, though.
pmichaud all of the other LIB_PATHS seem to have the current directory before the installed one.
so I wonder why this one is different.
nopaste "pmichaud" at 72.181.176.220 pasted "LIB_PATHS" (39 lines) at nopaste.snit.ch/16857 02:58
pmichaud okay, that was apparently done pre-1.0, so I guess a trac ticket is in order. 03:02
yay, make test is passing! 03:07
dalek rrot: r39502 | cotto++ | branches/pmc_pct (12 files):
[pmcc] finish switching pmcc to use the new vtable dump, delete/update relevant files
rrot: r39503 | pmichaud++ | trunk/MANIFEST.generated:
[install]: additional files needed for building Rakudo from installed Parrot.
 03:11
03:20 donaldh joined 03:27 japhb joined
cotto iwbn if frozen PMCs also depended on PBC_COMPAT 03:35
it would have saved me a good 30m just now 03:36
chromatic You would just have watched TV anyway. 03:38
cotto that's not the point ;)
chromatic Summer reruns! 03:41
Tene japhb: when we discussed this before, we decided that what you wanted to do *really* belonged in export()
cotto Hmmm. The freeze/thaw code already includes a packfile header, it just doesn't bother to check it. 03:42
dalek rrot: r39504 | cotto++ | branches/pmc_pct (152 files):
bring the pmc_pct branch up-to-date with trunk
Tene japhb: you really don't want to require every other language's import() to do extra work just to load OpenGL. The parrot-level import() btw is in the same file you're editing. 03:43
japhb Tene: bak ... OK, so there are two distinct issues:
1. export() takes only a space-separated string as a list of subnames, and it immediately splits that into a list. It should instead take a PMC and do the same thing load_library does: detect if it's already an array, and only split if not. That's an easy change. 03:45
03:45 s1n joined
Tene Sure. 03:45
japhb 2. Making some way for renames to be marked and handled properly. This will require some fixes to export() and probably a one-time minor fix to import() in each language to use the polymorphic namespace API rather than the hash-like API. 03:47
And there's a 2.a ....
2.a. The import that currently exists manually in each language, probably ought to have a default implementation in PCT. Which I believe is where the S11 angst comes in. 03:48
eol
Tene um... what change do you need to make to the import API?
Yes, there should be a default implementation in PCT. That's what we're prototyping here. 03:49
japhb Tene: right now, Perl6::Compiler::import uses: "$P0 = tagns[$S0]; importns[$S0] = $P0", which is to say, the hashlike interface to namespaces. But it should be using the OO interface instead, which is aware of being passed a list of things versus a hash (which implies rename) 03:50
May end up being faster with the OO interface as well.
Tene three issues with that, iirc. 03:51
AFK for a sec, though.
finishing preparing dinner.
japhb And by the OO interface, I mean 'ns.export_to(to_namespace, export_list)' and 'ns.export_to(to_namespace, export_renames)' 03:52
nodnod
Tene japhb: 1) That's an implementation issue, not an API issue. I'm not completely convinced that all languages ever will be returning a namespace of symbols instead of a hash of symbols. 04:07
dalek TT #749 created by cotto++: [CAGE] factor Packfile_unpack into validation and unpacking functions 04:08
Tene All I was thinking of was just a mapping of names to objects.
That's not necessarily a namespace.
japhb Tene: They may not internally be using a parrot namespace, but why wouldn't they be able to respond to that API?
Erm ... that's in my mind the definition of a namespace. 04:09
dalek rrot: r39505 | cotto++ | trunk/src/pmc_freeze.c:
[freeze/thaw] Make ft_init slightly more paranoid about checking header version numbers.
japhb I'm guessing there's a terminology disconnect ...
A Parrot HLL that wants to interoperate with other Parrot HLLs will have to follow some sort of standards. We've certainly said that not all languages need to understand heirarchical namespaces, but I have trouble imagining a language that can't at least *map* their internal name lookup process to the concept of a flat namespace. Assuming it knows what a "name" is at all. 04:11
The only place that right now we're imposing anything other than a flat namespace, which would work equally well with either the OO or hash interfaces, is the EXPORT tag pseudo-namespace. 04:12
Tene Sorry, got disconnected 04:13
japhb np
I'm afraid I feel rather ignorant at the moment, because I'm really not seeing the problem at all.
Tene japhb: I just didn't necessarily want to mandate that it had to return a Parrot namespace or subclass thereof. 04:14
a Hash would be just fine.
But, sure, I can be swayed one way or the other. I don't feel strongly about it.
It just feels a bit restrictive.
moving on
2) the 'export_to' method *requires* a list of names to export. 04:15
And I can't find any way short of making an iterator and stuffing a list one-at-a-time to get a list of all of the symbols in a namespace.
cotto bacek, ping
Tene so I can't just pass that.
dalek rrot: r39506 | cotto++ | trunk/src/pmc_freeze.c:
[stupid] cotto-- is not very good at numbers
 04:16
Tene and 3) that's just an implementation issue... not an API.
japhb re 2: A namespace can be treated like a hash, yes? So we should be able to just ask for its keys .... 04:17
Tene How? Can you show me some PIR that gets a list of names from a namespace PMC?
This certainly could be a lack of knowledge on my part. 04:18
japhb re 3: I guess I'm saying, with a couple minor tweaks, what you have *now* is workable. Not so much a full API, as a working set of conventions. It's a matter of what level in the stack you're trying to solve, and all I'm trying to solve is making interoperabiity *possible* at all. 04:19
pmichaud I think it's possible to simply do: $P0 = iter ns
Tene pmichaud: can I pass an iterator to .'export_to'() ?
pmichaud probably not
Tene exactly 04:20
japhb Then we should Make It So.
pmichaud (I haven't read the backscroll yet, btw)
japhb Actually, that was just a knee-jerk reaction.
pmichaud I don't intend to pass iterators around, no.
Tene pmichaud: thoughts on requiring that symbols be in a NameSpace PMC instead of just that they're in something that responds to 'iter' and keyed lookup?
pmichaud I'd prefer not to require NameSpace PMC 04:21
japhb Seriously, if a namespace wants to pretend to be a hash, it really should handle returning its list of keys. Like a good hash, <pat pat pat>.
Tene japhb: how do you do it for a Hash pmc?
I couldn't find it.
pmichaud I agree with the above that says that Perl6::Compiler::import should be using the OO interface instead of the hashkey interface to import its symbols 04:23
I simply went with the hashkey interface because that's closest to what was there previously (when I refactored) 04:24
OTOH, there's a good argument to be made that the hashkey interface should also go through the OO interface.
also, the OO interface leaves a couple of things to be desired.
japhb Tene: I'll be honest, I hadn't looked at the Hash PMC ... I simply didn't imagine that there wouldn't be a trivial way to get the list of keys. Sigh.
pmichaud: no argument there. 04:25
Tene japhb: me too. :)
pmichaud the way to get the list of keys from a Hash PMC is to iterate over the Hash
I'm not aware of a faster one.
(or more straightforward one)
Tene pmichaud: you can only use the OO interface if it's a NameSpace, not a Hash or other keyed lookup object.
But, a conditional would be fine.
pmichaud when would be importing to something other than a namespace?
*we be
japhb pmichaud (re: Hash keys): That may be the way it happens semantically anyway, but that should be happening down in the C code, not up in the PIR world. 04:26
Tene erm... earlier you said that you preferred not to require NameSpace.
I just didn't know if we wanted to allow for some language to return a Hash of symbols instead of a NameSpace.
pmichaud oh, I assumed that question was aimed at the notion that the exported symbols could be in something other than a Namespace
but storing symbols into a NameSpace sounds OO-ish 04:27
Tene pmichaud: NameSpace has an export_to, but it doesn't have an import_from. Maybe it should?
pmichaud you're saying that a language might prefer to use a Hash instead of a NameSpace as its symbol table
bacek cotto: pong. (I'm quite busy atm... A lot of stuff at $dayjob)
pmichaud (as its internal symbol table, that it imports symbols into)
also, fwiw, this isn't entirely an academic discussion, because Rakudo will eventually need to have exported symbols imported into LexPads 04:28
cotto bacek, should pmcc generate the same class_init that pmc2c does or did you have something different in mind?
japhb pmichaud: or more precisely, something that doesn't do/inherit from NameSpace. I assume that it doesn't have to actually *be* a namespace, just something that supports that interface.
Tene Regardless, this entire part of the discussion isn't actually relevant to API concerns... it's an implementation issue.
bacek cotto: same as in pmc2c. It's easiest way for now.
cotto ok 04:29
pmichaud I think it also important to keep in mind that what is written in the namespace PDD could still be considered highly speculative, for a number of reasons
in other words, if it doesn't match what we think needs to happen, we aren't really bound to it
Tene The only API question is...
pmichaud (we probably need to continue to support whatever is currently implemented for a deprecation cycle, but we don't have to claim that this is the preferred API) 04:30
bacek cotto: btw, we probably have to rethink goals ob this branch. I'm not quite sure that I want to implement half of C99 parser to support PMC.
Tene If I'm a compiler, and someone asks me to load a library for them, does the 'symbols' object that I hand back as part of my response need to contain 'NameSpace' PMCs, or just objects that respond to keyed lookup?
bacek cotto: may be emitting C from NQP and rewrite PMCs in NQP is better.
pmichaud objects that responds to keyed lookup and iteration
bacek (I know, it's crazy idea)
pmichaud a compiler may choose to hand back namespaces, but it's not constrained to do so. 04:31
Tene Okay, that's what I originally planned.
japhb: if you're concerned about speed here, we can consider adding an 'import_from' method to NameSpace PMCs that does everything we want. 04:32
pmichaud I don't think speed ought to be a huge issue here.
Tene accepts anything that implements a hash interface (including other NameSpaces)
pmichaud at least, it shouldn't be a driving issue at the moment.
cotto bacek, how much of C do we really need to parse to replace pmc2c? I thought just did simple textual substitutions.
Tene Neither do I. japhb does, though.
japhb Yes, speed is a concern. I'm slinging many thousands of symbols. But I don't see the need to prematurely optimize. I just need to get to Working Code first.
bacek No. For emitting L1 from same sources we need full parsing 04:33
cotto bacek, We could even swallow up the whole body and do the s/a/b/ on it after parsing.
japhb Right now I can't even do a Hello World equivalent.
bacek cotto: this is pmc2c approach.
cotto right; we could cheat for C and do legitimate parsing for L1
Tene japhb: okay, for right now, don't worry about optimizing rakudo's import, then. When someone cares about optimizing it, my recommendation is to add an 'import_from' method to the NameSpace PMC that mirrors export_to. 04:34
japhb: so let's get back to the part that actually matters.
japhb I'm certainly fine with that.
bacek cotto: to much cheating in parrot already...
cotto it'll just be temporary (fsvo) until L1 takes over 04:35
pmichaud btw, I've just updated the "ins" branch for Rakudo, that attempts to build from an installed parrot. If people could test that it actually builds (especially on Mac/Win environments) I'd be appreciative. I do expect some failures.
(1) clone rakudo repo
(2) git checkout -b ins
(3) perl Configure.pl --gen-parrot
(4) make
Tene pmichaud: pretty sure that checkout will just make a new local branch, not checkout your branch 04:36
confirming...
bacek cotto: there is nothing more permanent than "something temporary" :)
cotto ok. bad excuse
pmichaud oh. 04:37
Tene git checkout --track -b ins origin/ins
cotto I still don't see the problem with cheating for that part of the code, since that's how pmc2c behaves and pmc2c is what we're trying to reproduce
bacek cotto: have to run. Just another meeting.
pmichaud you're correct.
cotto bacek, np
japhb So, Tene: The issue at hand is ... renames? Or did you have something else in mind? 04:38
Tene japhb: yes, the parrot compiler's 'export' method.
japhb I think ... I can make it "just work", by doing the renames while installing into EXPORT::* via the ns.'export_to' on line 56. 04:41
Tene japhb: yes, that's what I would do.
japhb OK, then that will be the plan.
Given that I'm only affecting this file ... do you still want it as a patch, or should I just commit, and we can change it again if you don't like it? 04:42
Tene japhb: I say just commit
japhb excellent.
pmichaud oops, already found an error in branch 04:43
fixing
japhb What test sets should I run before committing? Do Rakudo and/or Cardinal have tests for this?
pmichaud what file did you modify?
Tene japhb: nothing at all anywhere uses that file 04:44
pmichaud: runtime/parrot/languages/parrot/parrot.pir
pmichaud right, we don't rely on that yet.
japhb (*will* modify) runtime/parrot/languages/parrot/parrot.pir ... damn, Tene types a lot faster.
Tene japhb: rakudo or cardinal *could* use it... but there are no PIR libraries that use it yet.
OpenGL will be the first. :) 04:45
japhb heh
Leading by (bad) example ...
04:45 Zak joined
Tene Well, if I moved any of the standard PIR libraries into their own namespaces, everything tha tused them would break. 04:46
iiuc
japhb OK, what is this: svn: OPTIONS of 'svn.parrot.org/parrot/trunk': could not connect to server (svn.parrot.org) 04:53
Coke ~~ 04:54
Tene ā‰ˆ
cotto very smart match 04:56
pmichaud vertical smart match, instead of the horizontal one.
Coke that better be a synonym. 04:59
my client sucks, that's a ? her.e
japhb: server down? 05:01
japhb Coke: responds correctly to GET; currently following the assumption that something is foobar in local SVN config
05:02 dukeleto joined
Coke japhb: 'svn cleanup' ? 05:04
were you trying to svn up?
(I just did an up no problem, so your "it's just you" theory fits. =-) 05:05
japhb 'git svn rebase' got a similar error, so I tried 'svn up' in a pure SVN checkout, and when that failed, I tried to 'svn co' ... all three failed.
japhb has a sneaking suspicion that he has fallen prey to Debian pedantry ...
Normally, I love Debian's packages, but the time I've lost to inane pedantry ... cannot be regained. 05:06
dalek rtcl: r474 | coke++ | trunk/runtime/builtin/proc.pir:
Remove stale comment, useless trans_charset, and explicit unbox.
 05:10
japhb wants to beat SVN with a carp 05:16
japhb decides to use git to version ~/.subversion ... 05:18
dalek rtcl: r475 | coke++ | trunk/runtime/builtin/proc.pir:
switch from die to tcl_error, use better var names, minor cleanup.
 05:39
rtcl: r476 | coke++ | trunk/tools/spec_info.pl:
capture stderr too.
05:47 eternaleye joined
nopaste "GeJ" at 202.171.79.162 pasted "One-line fix for a failing test in t/codingstd/c_parens.t" (11 lines) at nopaste.snit.ch/16858 05:58
GeJ if anyone wishes to take it. 06:00
it fixes a space-before-closing-parens error. 06:01
NotFound Done 06:03
GeJ thank you
dalek rrot: r39507 | NotFound++ | trunk/src/pmc_freeze.c:
[cage] codingstd fix, GeJ++
 06:05
cotto I figured it'd be something I did. 06:07
06:12 uniejo joined 06:13 Theory joined
japhb Well, it appears that the subversion problems I'm having are due to libneon-gnutls, several layers down the stack. And apparently there have been numerous times over the last couple years in which gnu-tls has broken subversion in Debian. Of course, there's a wishlist bug to drop OpenSSL support in libneon entirely, moving libneon-gnutls from merely breaking things by default to being the only available option. Why? Pedantry. Seesh.</m 06:24
ini-rant>
I think I'm going to go to give up on this battle for the night, and try again another time with more sleep.
szbalint pedantry = licensing issues 06:34
I've seen the perl libcurl binding repackaged in debian be forced to switch from openssl to gnu-tls because somone using WWW::Curl might use it in a way that works out weird 06:35
I wish copyright and licensing would go away heh. 06:36
06:52 eternaleye joined 06:53 TonyC joined 06:59 mj41 joined 07:10 chromatic joined
dalek rrot: r39508 | cotto++ | trunk/src/pmc_freeze.c:
[tt] Worst. Dyslexia. Ever. Hopefully the I get the TT number right the third time.
 07:15
07:22 donaldh joined 07:23 dukeleto joined 07:37 viklund_ joined 07:56 barney joined 08:27 clunker3_ joined 08:54 gaurav joined 09:06 particle1 joined 09:22 clinton joined 09:25 particle joined 09:28 bacek joined
cotto bacek, ping 09:39
bacek cotto: pong
You just woke up or didn't sleep yet? :) 09:40
cotto not sleeping yet
not working has its advantages
bacek yeah...
cotto So what are your objections to treating the body of C-based VTABLE (and METHOD, MULTI) functions as text in pmcc's parser and applying regexes like pmc2c does? 09:41
bacek It throw away job. 09:42
s/ / is / 09:43
To emit something apart from plain C we have to fully parse body. Preserving semantic.
cotto It's inelegant, but the alternatives (afaict) are to parse the subset of C or to use a different tool. 09:44
bacek "different language"
for pmc body.
cotto What I'm suggesting is that the C bodies be parsed as a chunk of text, then when we get L1 specified we can use an actual parser for that. 09:45
bacek chicken and egg problem?
To understand what we need for L1 we have to have some examples of parsed pmcs 09:46
cotto Right. We can have a PMC that's mostly C but with one or two test functions written in L1.
That'd give us a nice migration path, if it's feasible.
bacek We can target current PIR as "L1 prototype" 09:47
09:47 snarkyboojum joined
bacek (And have it "for free" because PCT already support it) 09:48
Then we can adjust PCT to emit L1
...
Profit!
cotto I think it's too early in the process to know if PIR would be a good starting point for L1 09:49
bacek I treat L1 as "reduced PIR".
Less ops, less sugar.
cotto like pasm? 09:50
bacek something like pasm.
even more reduced.
cotto but that's the future. 09:51
bacek bright shiny future :)
cotto yes
I'm saying there's no need to write a full (or partial) C parser into pmcc just to do the simplistic stuff pmc2c does. 09:52
plus it violates laziness
bacek to satisfy laziness it's probably easier to try parse C in ops. 09:53
Generally it's simpler than full featured PMCs body. 09:54
L1?
purl hmmm... L1 is a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982
cotto You mean we should parse the C in src/ops/*.ops or we parse C to turn it into L1?
bacek Step 4 from chromatic++ idea 09:55
we parse C in ops to turn it into L1
cotto I don't think he was ever suggesting that we parse C, but that we write something that can be *compiled* into C. 09:56
bacek 5) Write a new backend emitter which targets L1 ops for #3 and #4
cotto Yes. That backend takes L1 and turns it into C, afaiu 09:57
bacek 3) Specify a new language in which to write existing code in .pmc files which the parser written in #1 can emit as the same C code as now.
So, afaiu, we sematically parse PMC's bodys, emit C. Than replace emitter to emit L1. 09:59
cotto so far, so good
*but* since the bodies are currently already C, we don't have to do full-on parsing 10:00
s/C/mostly C/
bacek Almost. But for emitting L1 we need it. And we already have pmc2c which handles first part.
That's why I think that without full body parsing it's "throw away" job. 10:01
cotto I think his step 5 means that the new parser consumes L1 and can spit out either C, LLVM bytecode or rainbows 10:02
not that it takes C and emits L1
bacek Writing PMC in L1??? No way! 10:03
cotto 3) Specify a new language in which to write existing code in .pmc files which the parser written in #1 can emit as the same C code as now.
bacek hate English ambiguity... 10:04
cotto It hates you too, although it hates everyone at some point.
So does it make sense now that we don't need a full C parser? 10:05
bacek $parser->parse($pmc)->emit_c + $parser->parse($pmc)->emit_l1 OR $parser->parse($pmc)->emit_c + $parser->parse($l1_pmc)->emit_c
there is a question
cotto and possibly an answer 10:06
bacek indeed
I treat chromatic's idea in former option. But I don't want to parse C... At least now. 10:07
cotto One of us can get a clarification from chromatic next time we see him.
bacek Or we can agree on something and go ahead :) 10:08
cotto I vote for not parsing C.
ever
bacek Anyway, there is a lot of things which have to be done apart from parsing C. 10:09
cotto quite a few
purl quite a few are funny
bacek
.oO( METHODs... )
cotto I was thinking it'd be pretty simple to finish class_init until I looked at the code in pmc2c that generates it. 10:10
bacek heh. I did same mistake for MULTIs...
cotto btw, I got pmcc working with the vtable dump from compilers/vtdumper
unfortunately freeze/thaw on Captures is b0rked, so I had to convert the PAST to an RPA of Hashes. 10:11
bacek I saw your commits...
cotto ok
no need to repeat them then 10:12
bacek btw, I want to fix Hash/Keys/Iterators support in parrot before return to pmc_pct. 10:13
cotto that's all
bacek "all"? No. Next step - world domination! 10:14
cotto by "fix" do you mean "throw out and rewrite from scratch" or something less drastic
There's some ugly code in Keys.
bacek I can reuse ~10% of code though.
cotto That sounds about right. 10:15
What's the motivation?
purl hmmm... the motivation is just distraction from realization of futility.
cotto no, the motivation is brownies
purl okay, cotto.
bacek Emitting PBC from within PIR. 10:16
cotto so if we're not parsing C and emitting L1, are you fine with the quick approach to dealing with PMC and ops functions written in C? 10:17
bacek And in bright future emit PBC for L1
Yeah, fine. I'll jump back on this train next week. 10:18
cotto right around yapc time
bacek it's on another side of globe... 10:19
cotto as am I, which means I really need to get to sleep 10:20
good night
and happy hacking!
should I relay what chromatic says or will you check the backlog? 10:21
bacek I'll probably will go to sleep soon... ~10 hours work day...
cotto night 10:22
bacek night
10:33 dalek joined 10:34 DanielC joined
DanielC How do you do a string comparison in PIR? I tried "if algo == 'MD5' goto MD5" 10:35
wait... I goofed. 10:36
Yeah, it works :)
10:38 snarkyboojum joined 10:40 ujwalic joined 10:41 ujwalic_ joined 10:51 kid51 joined 11:06 payload joined 11:22 donaldh joined 11:37 flexibeast joined 11:47 contingencyplan joined
dalek rtcl: r477 | coke++ | trunk/docs/spectest- (2 files):
regain 2 spec tests\\nrecord a modest speed improvement.
 11:49
11:54 kj joined, kj left 11:55 kj joined
mikehh make -k fulltest fails manifest_tests, examples_tests and distro_tests PASSes the rest 11:56
Ubuntu 9.04 i386 at r39508 11:57
same result as yesterday - nopaste.snit.ch/16853
should I open a ticket on this? 12:01
kid51 What is the -k option? 12:07
mikehh prevents error exit I think 12:11
-k, --keep-going Keep going when some targets can't be made.
used to use male fulltest_all until I found out about it 12:13
which makes that redundant
kid51 Someone forgot to update MANIFEST.
I just fixed that. 12:14
dalek rrot: r39509 | jkeenan++ | trunk/MANIFEST:
Add src/pmc/handle.pmc; someone forgot it.
mikehh well that should take care of manifest_tests and distro_tests 12:15
just the pod in examples_tests left 12:16
kid51 I'm not sure of the distro_tests. The error message refers to the same file that was absent from MANIFEST.
But I'm not very familiar with t/distro/test_file_coverage.t 12:17
kid51 must go to $job now
12:25 skids joined
mikehh manifest_tests now pass but examples_tests and distro_tests still fail 12:44
distro_tests - # svn ps svn:keywords "Author Date Id Revision" src/pmc/handle.pmc 12:47
and no test files for that file - handle 12:48
examples_tests - t/examples/pod.t - 7 errors in docs/pdds/pdd19_pir.pod and :invocant error in docs/book/ch03_pir.pod 12:51
others all TODO 12:52
12:54 payload joined
dalek rrot: r39510 | barney++ | trunk/src/pmc/handle.pmc:
[distro] set svn properties for handle.pmc
 12:54
13:16 jq joined
barney mikehh: Could you open two tickets, for the missing testfile and for the invalid PIR in the POD-files 13:20
These look like real errors
mikehh ok will do 13:30
13:38 snarkyboojum joined 13:40 Steve_H joined 13:43 snarkyboojum joined
dalek TT #750 created by mikehh++: Failures in examples_tests - t/examples/pod.t - fails 9 tests 13:45
13:56 Whiteknight joined
dalek TT #751 created by mikehh++: test failures related to src/pmc/handle.pmc 14:12
Whiteknight doesn't codetest run as part of fulltest? 14:17
14:21 masak joined 14:23 Theory joined
barney Yes, codetest is part of fulltest, distro_tests is part of fulltest, but not of codetest 14:23
mikehh sure, but you can run them separately as well 14:37
14:37 Andy joined
mikehh as on make codetest or make distro_tests etc. 14:37
s/on/in/ 14:38
14:38 payload joined
Whiteknight okay, I did run fulltest on that branch, but apparently not everything got tested 14:38
mikehh you need to run make -k fulltest so that it cpmplryrs all the tests otherwise it exits on the first test that fails 14:41
completes
14:42 coke_afk joined
mikehh the distro_tests failure is indicating that there is no corresponding test file 14:44
Coke "someone added code without tests." 14:45
or, possibly "tests in the expected location."
the PIR example errors are from the book author/editor, I wager.
barney e.g .macro_local is specced, but not implemented in IMCC 14:47
mikehh at the moment these tests are the only ones failing (for me anyway) on all the tests I have run 14:49
Whiteknight mikehh: ah, that's probably my problem then. I did fulltest and it broke from that MANFEST.generated test failure, so probably didn't do the rest 14:51
14:52 viklund_ joined
Whiteknight I'll fix that handle.pmc thing tonight 14:52
mikehh it only came up with problems with codetest after the manifest_tests problem was fixed 14:53
14:53 davidfetter joined 14:54 bkuhn joined
Whiteknight oh, that one finally got fixed? 14:57
pmichaud I'm looking for folks to test rakudo's new build system (building from installed parrot) 14:58
instructions at 15:00
purl be SPECIFIC for HOLY FUCKING GOD SAKE! trash.chregu.tv/instructions.txt
pmichaud gist.github.com/127957
mikehh I haven't tried installing parrot - I just have the development setup - I build rakudo with --parrot-config=../parrot/parrot_config 15:01
pmichaud the instructions I just gave does a local install inside of the rakudo directory 15:02
(i.e., it doesn't do a systemwide install)
Whiteknight pmichaud, I posted a request for help to the list 15:06
pmichaud Whiteknight: thanks
15:21 donaldh joined 15:31 darbelo joined 15:49 contingencyplan joined
particle tests the instructions on win32/msvc 15:54
parrot is building now... 16:00
16:01 Steve_H left 16:02 HG` joined 16:06 whoppix joined 16:18 benkay joined 16:19 benkay joined 16:25 Psyche^ joined 16:29 davidfetter joined
dalek TT #158 closed by NotFound++: deprecated: :anon and :vtable named parameters to add_method 16:49
particle pmichaud: ... 16:52
NMAKE : fatal error U1073: don't know how to make 'c:\\Users\\particle\\dev\\rakudo-install\\rakudo\\parrot\\install\\bin\\parrot'
Stop.
16:56 d4l3k_ joined 17:01 pmichaud_ joined
pmichaud_ particle: I just pushed a change to github -- perhaps "git pull" and try again? Shouldn't result in rebuilding Parrot. 17:01
(my connection to feather is flaky and keeps dropping out) 17:02
I need to grab lunch and pick up daughter from school.... bbiah
particle do i need to perl Configure.pl again?
pmichaud_ yes.
perl Configure.pl --gen-parrot
particle gen-parrot?
pmichaud_ but it should detect that your parrot is up-to-date and not rebuild it. 17:03
particle seems rakudo is building now
this is just to build against installed parrot, not install rakudo, right?
pmichaud_ correct.
rakudo still doesn't have a 'make install' target.
particle ok, well, it's building, and you'll have my results when you return.
pmichaud_ I'm not exactly sure how to make that one work.
great.
particle building pmc's now 17:04
pmichaud_ expects FAIL
particle fails during link
no argument specified with option /out:
seems an easy fix
pmichaud_ can you nopaste the command/error message?
particle sure... 17:05
nopaste "particle" at 76.121.106.245 pasted "rakudo build error" (6 lines) at nopaste.snit.ch/16863
pmichaud_ why does it not see the argument to out? 17:06
is it not able to accept a -out with a path?
particle probably doesn't like space 17:07
particle checks the parrot makefile 17:08
pmichaud_ yes, apparently spaces are bad.
I took mine from partcl's makefile, which I guess would suffer the same issue
adjusing
adjusting
particle yeah
17:09 NotFound joined
pmichaud_ pushed. 17:09
particle makes 17:12
pmichaud_ I'm guessing it might end up with difficulty handling the double-backslash in src\\pmc\\\\*.obj
but we shall see.
nopaste "particle" at 76.121.106.245 pasted "rakudo build error" (576 lines) at nopaste.snit.ch/16864 17:14
particle another linker error
let's deal in an hour or so, i need to get set up with a $client
pmichaud_ sure, I have to go also. Thanks! 17:15
17:20 kj joined 17:21 dalek joined 17:22 Coke joined
Whiteknight hello kj 17:22
17:23 pmichaud joined 17:25 polyglotbot joined
kj hi w 17:31
Whiteknight: 17:32
geez
i forgot how this works :-) Hi Whiteknight!
Whiteknight hello kj, how's things?
kj not too bad, thanks. Kinda busy, but working from home these days, so can connect to irc again
Whiteknight oh, that's nice
kj yourself?
Whiteknight busy too. Always busy 17:33
managing the release on Tuesday, so preparing for that
kj i saw the email and announcement, yes
Whiteknight what's the state of PIRC right now? 17:34
kj the same as I left it in February I think
I saw there were a few commits from some other people
but those were cleanups I think
the state, to be more precise is this:
Whiteknight ah, I thought PIRC was on the roadmap for 1.3, but looks like it was pushed back to 1.5 17:35
kj the byte code generator module is buggy I think. The second major thing that needs fixing is to store all strings as STRING *, not char *
yes i saw it's pushed back
now, I would hope that fixing the char * -> STRING * stuff solves the bytecode generator 17:36
but I'm afraid it's not that easy
Whiteknight is this something we could parallelize, like if other developers were interested in helping?
kj so the 2 major things to fix are the byte code generator and the char * to STRING conversion 17:37
i think the second, the STRING stuff should be done first
Whiteknight okay, that's really not so bad then
("not so bad" if those are easy issues to resolve)
kj then, *perhaps*, the bytecode stuff is fixed, but that's only a wild guess. The problem with the byte code gen is that there's some segfaulting going on as FLOATs and STRING constnats are not stored properly 17:38
i'm not sure exactly what's the problem, but I have no debugging skills
except for printf()
Whiteknight okay.
kj that is, i have no gdb skillz
17:39 chromatic joined
kj and unfortunately, my work needs full attention at this point as I'm kinda under pressure. 17:39
however, questions about the design I can always answer, but the code is not so fresh in my memory at this point. Hopefully I put in enough comments :-) 17:40
Whiteknight that's okay, I don't want to give you any pressure!
kj yeah it's a pity, but the thing is, I know I cannot really solve it properly, so the motivation to spend a few hours every now and then is really very small, as I kinda feel it doesn't really help. 17:41
Whiteknight yeah, I know what you mean 17:57
maybe we can get a few fresh eyes to take a look at it for you
kj preferably someone who has a lot of knowledge about PBC format. I copied a lot of code from IMCC, and I don't understand all of it... 17:59
perhaps it's a memory problem that I've overlooked.
Whiteknight bacek was doing some stuff with packfiles, maybe he can lend a hand
kj if you use some command line option to just print the output to screen, everything is fine
it goes horribly wrong when dealing with FLOATs and STRINGs 18:00
(there's tickets open for that, btw)
Whiteknight STRING and FLOAT constants?
kj yes
as they are "special"
integer constants are just stored in the byte stream
*byte code stream
so, add_i_ic_ic has 3 operands: the register number of the INTVAL register, and 2 INTVALs, stored immediately into the stream 18:01
dalek cnum-dynpmcs: r85 | darbelo++ | trunk/ (2 files):
Add freeze/thaw functionallity to DecNumContext. Tests included.
kj whereas add_n_nc_nc has 3 operands, but the last 2 are indexes into the const table
I believe just using 1 such op is fine, but 2 consequetive blows up 18:02
Whiteknight hmmm, that's weird
kj yeah, and it also depends whehter you run on windows or linux i think 18:03
i can't remember details
( i switched to macos few months back, so not doing any windows anymore, although I do have access if necessary)
windows is quite forgiving in segfaulting, whereas linux is very clear when things go wrong 18:04
(forgiving, or maybe just keeping silent)
pmichaud particle: I'm back, whenever you're ready to troubleshoot the win build again 18:07
chromatic cotto, bacek, parsing C and emitting L1 is madness. Specify a new language in which to write PMCs, then have pmcc emit either C or L1. The former is the migration strategy to the latter. 18:10
Once we have the former in place, we can use pmcc to replace our current parsing tools. 18:11
Then we can work on making L1 work sufficiently to replace the C generation step.
18:16 burmas joined
cotto chromatic, that's what I thought. I'm glad to have you confirm it. 18:18
chromatic I realize it's more work than replacing things right now from whole cloth, but I'm okay with rewriting the whole system in replaceable chunks over the next year if we can keep things running without disruption. 18:21
I don't know any successful, used, and *interesting* software projects where that's not true.
Whiteknight is "L1" short for anything? 18:28
cotto L1?
purl L1 is, like, a hypothetical language that would be used to implement PMCs and PIR-visible ops so that they could all be easily jitted. or irclog.perlgeek.de/parrot/2009-04-21#i_1083550 or rt.perl.org/rt3/Ticket/Display.html...txn-471982
cotto I think just level-1 language
LOL would also be an appropriate name 18:29
Whiteknight cotto: what's the status of the pmc_pct branch?
18:30 burmas left
cotto It's parsing and emitting a usable vtable dump. I'm working on figuring out what supporting code it needs to emit class_init. 18:31
pmc2c is a bit hairy in places.
Whiteknight you have an ETA on that? Do you suspect it will be ready by this weekend, or after the release?
cotto It *might* be usable by 1.4, but definitely not by 1.3.
Whiteknight okay, thanks 18:32
18:32 payload joined
Whiteknight do we have any idea yet how we are going to implement L1? 18:35
is it going to look like PIR, or something different?
cotto bacek suggested that we use pir as a starting point, but I haven't given it much thought.
istr that chromatic was giving it some thought. 18:36
darbelo cotto: I thought L1 was a different thing from the "PMC Imementation Language" pmcc will parse. 18:37
cotto darbelo, at first pmcc will do the exact same thing as pmc2c. Once it does that, we'll make it parse L1 and emit C. 18:38
Whiteknight maybe it's better to have both tools and a whitelist 18:39
18:40 dalek joined
Whiteknight PMCs get parsed by pm2c by default, and when they've been converted to L1 they get whitelisted and are parsed by pmcc instead 18:40
darbelo cotto: Oh, ok. I read chromatic's "Specify a new language in which to write PMCs, then have pmcc emit either C or L1" as refering to yet another language.
pmichaud me also.
if Ll is easy to parse and convert, I could see using that as the base for writing PMCs 18:41
Whiteknight I can't imagine that you would ever want a tool to emit L1, assuming I understand it's uses correctly
PMCs and OPS, I hope.
makes everything easier to JIT in the future
pmichaud Parrot string magicians: TT #752 :-) 18:42
NotFound pmichaud: \\uxxxx is supposed to be a codepoint? Some time ago we asked for clarifications of the escaping in the pir pdd, but still does not look clean to me. 18:46
pmichaud It's a codepoint. 18:48
At any rate, the first $S0 string is correct.
It's the $S3 string that is incorrect.
chromatic L1 is just a small set of opcodes which are 1) trivial to JIT and 2) sufficient for writing all other opcodes. 18:52
I can't imagine wanting to write anything more complex than an opcode in it.
pmichaud Would PMCs be written in Ll or in opcodes? 18:54
sorry, L1
chromatic We can write PMCs in whatever language we want, but a parser translates them to L1 the same way Perl 5 translates our mismatch of PMC language and C to C now. 18:55
pmichaud okay.
presumably "whatever language we want" would be "not C" though. 18:56
chromatic That's right.
C's semantics are too dangerous and corner casey.
darbelo Doesn't this road lead to a sign with ETOOMANYLANGUAGES at the end? 18:57
pmichaud that sign is also known as "Parrot", fwiw. :-)
chromatic It's the same number of languages we have now. 18:58
pmichaud The whole purpose of Parrot is to be able to support an incredibly large number of languages :-)
darbelo pmichaud: s/ETOOMANYLANGUAGES/MOAR lANGUAGES, PLZ./ then ;)
NotFound I CAN HAZ LANGUAGES? 19:00
darbelo chromatic: I don't really count the C+Boilerplate used for PMCs as another language. 19:01
chromatic I don't see why not; no one who's familiar with C and not Parrot can read it and say "Oh, I just have to look up a few macros or function docs to understand what's going on here." 19:02
If you have to write a parser for it (and I've patched the parser for it more than a few times, so there's a parser for it), I believe it's a separate language. 19:03
NotFound In fact I dont think I know the PMC language, even after fixing problems in a lot of them 19:04
Coke would help if it were ever spec'd. :P 19:07
a lot of the internals just accreted.
chromatic: any luck with the contextualizing?
darbelo Hmm. I see your point, I was thinking along the lines of "I know C, I just have to put this funny decorators on my functions and return funny from methods" vs "I know C, what is this .pmc thing written in again?"
Coke orders a 1TB hardrive for half of what he paid for his last drive.
(which was... what, maybe a third of the size?) 19:08
chromatic Coke, no luck. I have one more idea for debugging, but it might have to wait until the PCC rewiring.
Okay, two more ideas for debugging, but one of them is a nasty hack.
Coke would a small PIR example still help? 19:11
chromatic I can recreate the Sub context leaks just fine; coroutines and returncontinuations seem like the culprits. 19:12
I've used some of the PMC tests, which is fine. 19:13
Coke ok.
have you found if the coroutine is invoking the sub's destroy?
(and if so, is that get_attr macro doing TRT?
chromatic Yes and yes. 19:14
Coke hurm. sub's destroy returns if sub==null; shouldn't it do a free of SELF regardless? 19:15
chromatic The problem is obvious in the "Please don't crash!" check in Parrot_free_context, which skips out on putting the context in the recycling pool if its reference count is less than zero.
If sub is NULL there, it can't access sub's context because sub doesn't have a context. 19:16
NULL sub is NULL.
Coke right, but the context is in the sub; what is mem_sys_free(PMC_data(SELF)); doing?
chromatic If there's no sub, there's no context to free. 19:17
Oh, I see what you mean. 19:18
Coke that should just be attrs, which should just be sub. Not sure if that's a lock, though. 19:19
chromatic Testing now.
Coke (nor how a child of a sub would deal with that.)
(tclproc isa pir .Sub, and also has its own attributes)
chromatic I don't know if that would ever have been a problem, but it's clearly a potential leak written that way.
If that fixes any leaks, Valgrind will report them with the call to mem_allocate_zeroed_typed occurring on line 70 or 71 of ./src/pmc/sub.pmc. 19:21
19:21 donaldh joined
Coke nope. 19:22
here's a crazy thought; why not remove the "please don't crash" warning, and see what happens?
chromatic Crash.
Specifically double-free warnings when freeing the context recycling pool during global destruction.
Coke is that just papering over the fact that our refcounting is wrong? 19:23
that is, if our refcounting was right, we could remove it and not crash?
chromatic Yes. 19:24
The problem is figuring out where our refcounting is wrong.
Coke if we remove the check and crash, can we use that to backtrack?
and/or if we fix our refcounting, will the leak magically go away?
chromatic First answer, not easily. 19:25
Second answer, yes.
FSVO "magically" which means "This is difficult in the same way that space is big."
japhb LOL 19:26
Coke "you thought it was a long way down to the chemists!"
japhb "They call it 'space' ... because there's so much of it."
chromatic You (by which I mean "THIS GUY") end up groveling through a call chain looking for sites which aren't part of the call chain but should be.
Coke is there a "make FOO" target that will force the global destruction? is just 'make sufficient'? 19:27
chromatic If I had an easy way to annotate every access to a context which assumes the context should still be valid, I could do this more easily.
You need to add the --leak-test flag to all Parrot invocations.
dalek rrot: r39511 | chromatic++ | trunk/src/pmc/sub.pmc:
[PMC] Plugged a potential memory leak Coke++ found in the Sub PMC; if a Sub had

This *should* never happen, but now it will never happen.		 19:28
Coke chromatic: would something like a GET_CONTEXT macro that you could override help? 19:29
chromatic Yeah, but you'd have to annotate every access to contexts throughout the system. 19:30
You'd also have to write it in such a way that it performs a PARROT_ASSERT. 19:31
... and, more importantly, you'd have to apply it only to accesses to contexts which can legitimately be undefined.
There are certain cases, I believe, where the from context or calling context don't need reference counts.
At least that's how the code reads now.
Coke chromatic: so, if I do grunt work, someone can fix my bug? 19:32
chromatic Possibly.
Let my try my other two ideas and warn you again that this is an excessive amount of grunt work.
Whiteknight keep in mind, in the not-so-distant future contexts will be garbage collectable
Coke Whiteknight: so I keep hearing. =-)
Whiteknight anythingthat requires codebase-wide annotations at this point is a bad idea
Coke In the meantime, I'm hemmoraging spec tests. 19:33
chromatic That depends on the PCC rewiring branch at some point in the preceding not-so-distant future.
Coke which has been in progess for some time; I have no idea what's left on that, either.
I should try to build that branch.
Whiteknight the only reason I'm waiting for that branch is because I don't want to make a major change to the same subsystem and completely screw the branch up irrepairably
it makes no difference to the Context work whether the branch lands successfully or dies in a fire. Although, I strongly think that landing the branch is more beneficial 19:34
chromatic That branch won't currently build. I believe it's not (yet) passing arguments when entering PIR code from C. 19:35
Coke goes back to cry in his beer.
chromatic Now imagine having to dig through all of this code to figure this out! 19:37
Coke so it sounds like if I want to expend energy to help out, I can't do anything useful atm. =-) 19:38
pcc_rewiring is allison's branch, neh?
(the build gets pretty far, dies with miniparrot.)
chromatic Just like I said. Arguments from C get passed into a CodeSignature, but they don't get passed into the context where PIR code expects to find them. 19:39
19:40 DanielC joined
chromatic That branch has long blocked on one person's availability and interest. 19:40
DanielC Parrot uses OpenSSL to provide hash functions. Right? Would it be hard to get Parrot to also provide the other cool crypto functions that also come with OpenSSL (mainly AES, RSA) 19:41
?
chromatic Any future branch we expect to last longer than a week really ought to have some plan sketched out in the wiki. 19:42
cotto chromatic, your plan for pmcc is that first PMCs and ops will work as written, then we'll be able to write them in L1, and after that we'll be able to write them in any language that can be transformed into L1? 19:44
NotFound chromatic: talking about that... I remember we had some branch about strings, isn't it? 19:45
cotto s/as written/like they are now/
(and the L1 will be transformed into either C or LLVM bytecode) 19:46
chromatic NotFound, Simon Cozens's string branch? I think he was prototyping it in Perl 6 first. 19:48
cotto, skip the second step.
First pmcc translates them as written into C.
Then we port them to a new language which pmcc can translate into C.
Then we get L1 working.
Then pmcc translates them to L1.
NotFound chromatic: I remember some talk about that, but long, long time ago in a galaxy far away.
chromatic seen lathos? 19:49
purl lathos was last seen on purl 108 days, 4 hours, 28 minutes and 54 seconds ago, saying: <private message> [Feb 23 15:16:16 2009]
cotto so the code will go from new language -> L1 -> C?
chromatic There's no -> C once we have L1. 19:50
NotFound About TT #752: IMO the code in Parrot_str_append is completely wrong.
cotto I thought one of the selling points of L1 would be that we'd convert it into either LLVM bytecode (on supported platforms) or C elsewhere. 19:52
NotFound I'm tempted to say the same about the entire strings/api.c file
19:57 pmichaud_ joined 20:07 kj left
DanielC Parrot uses OpenSSL to provide hash functions. Right? Would it be hard to get Parrot to also provide the other cool crypto functions that also come with OpenSSL (mainly AES, RSA) ? 20:11
Coke wonders where feather just went to. 20:13
Whiteknight chromatic: Why would we want to translate anything INTO L1? Don't we want L1 to be the starting point that we can translate into C and LLVM bytecode, and whatever else destination format that the build requires? 20:14
I assumed we would be writing in L1, and translating that into C and others 20:15
chromatic The point is to get rid of C. 20:16
Whiteknight well we need something to compile, and GCC doesn't run on L1 and fairy dust
chromatic L1 is just ops that Parrot can execute.
What's the problem?
purl i heard the problem was getting an installed parrot to recognize dynops/dynpmcs
NotFound I have a Winx Club DVD, if you need some fairy dust. 20:17
Whiteknight I don't think I understand that whole idea. what's the point of L1 if we're not translating that into C and LLVM bytecode and other targets?
I thought automated code generation was the whole idea, instead of having to write out the C and JIT code definitions by hand 20:18
Coke l1 would be the same niche as nqp, neh?
chromatic That's step one, until we can target L1.
Whiteknight target L1 from L1?
chromatic The point of L1 is so that we can stop writing *and executing* C code.
Coke I think L1 is probably a less helpful name than "FOO"
Whiteknight chromatic: we have to execute something 20:19
chromatic Yes, that's L1.
NotFound Or someone
chromatic L1 is a series of simple, low-level ops that can do everything we need to do from C now.
Whiteknight so we're creating a language with the capabilities of C, but not the performance of C? And what benefits, besides "No C" do we get?
chromatic Who says it doesn't have the performance of C? 20:20
C *is* our performance problem right now.
Whiteknight C is a thin layer over ASM, and optimizing it in the compiler is very common. Nothing we write is going to beat that 20:21
chromatic The hell you say!
purl You have no chance to survive make your time.
Whiteknight I'm going to need to see more of a comprehensive manifesto then, because I just don't understand the point of doing it that way
chromatic To call a vtable entry from PIR right now we must 1) check for a PIR override and execute that 2) marshal from PIR calling conventions to C calling conventions 3) execute a C function, possibly calling back into PIR in nested runloops, keeping in mind exception handling 4) unmarshal C return values back into PIR 20:22
This is not a recipe for insane speed.
cotto Isn'
chromatic If PIR is written in L1 and vtable entries are written in L1, you can skip all of those steps. 20:23
cotto Isn't our problem more with switching between PIR and C, rather than the speed of c?
chromatic Yes.
We either translate all PIR programs to C and compile them (facing recompilation when something requiring recompilation changes), or we get rid of calling C back and forth and use a different strategy.
Whiteknight At the end of the day, everything is still the same machine code regardless of whether we write it in C, or assembly, or L1, or VB6
20:24 benkay left
Whiteknight wait, are you talking about using L1 as a sort of microcode? 20:24
chromatic Yes. 20:25
All nanoparrot does is execute L1 ops.
cotto So we want to eliminate C except under the hood so we're never switching between calling conventions.
japhb Actually, it sounds a lot like "primitives" in the Forth sense.
Whiteknight okay, I understand that much better then
chromatic I want to eliminate all C, but I'll start with PMCs and ops for now.
japhb
.oO( Maybe all that time spent understanding Forth threading models has some real-world value after all ... )
 20:26
Whiteknight Okay, that out of the way, I'm heading home. Later
chromatic We can't inline C in PIR, we can't rejoin inferior runloops in C, we can't multiple dispatch in C, we can't perform escape analysis in C. 20:27
Every time we cross that C boundary we give up many, many optimization possibilities.
nopaste "chromatic" at 72.90.115.31 pasted "Let's try this for debugging context leaks" (25 lines) at nopaste.snit.ch/16867 20:34
Coke want me to try that against my tcl code? 20:35
Coke rants that 'will@coleda.com', a hosted google account, is not usable as a google account. 20:36
chromatic It won't fix things. It'll just expose crashes. 20:38
Those crashes are in Parrot though (and miniparrot demonstrates them), so it's probably fixable here.
Coke ok. let me know if you need me to do anything. 20:39
NotFound I have a special-case ugly fix for TT #752 20:46
How big is the urgence for that thing in rakudo?
viklund_ 752, that was the unicode thing right? 20:47
NotFound Yeah
20:47 pmichaud_ joined
NotFound Well, I see it more that a iso 8859-1 thing, but still ;) 20:48
pmichaud_ I've decided that feather has become less-than-useful for irc chatting recently.
the #752 bug is high priority but not critical
Rakudo can continue to make progress without it being fixed (more) 20:49
some people writing applications using Rakudo are blocked (or have to do very nasty workarounds) until it's fixed
NotFound I'll clean, comment and commit the fix, then. At least it will clearly expose the weak point.
pmichaud_ can I see the diff?
I might be able to suggest a way to clean it up
NotFound pmichaud_: give some minutes...
viklund_ pfft, nasty workaround 20:50
viklund_ walks away, muttering
pmichaud_ also, fwiw, it's not feather itself that seems to be the issue, but rather the connectivity between feather and various parts of the outside world
20:54 dalek joined
NotFound IMO the right way to avoid these workarounds is to get rid of the iso 8859-1 charset and reimplement is a an unicode encoding 20:56
pmichaud_ I think that's heading the wrong direction.
We need to support multiple charsets -- including iso-8859-1
wait, I'll rephrase 20:57
NotFound pmichaud_: there is no practical difference to the outside world between considering it a charset or not.
20:57 bacek joined
pmichaud_ I'm fine with switching iso-8859-1 to unicode as long as internally it's still a fixed width encoding. 20:57
if it's a variable length encoding, then we're making things worse. 20:58
dalek nie: r71 | isop44++ | trunk/ (2 files):
Patch by ++amk - Launchpad bug #385394

Python 3.0 dropped a number of built-in functions. Using the list from Python 3.1's code, this patch removes the built-ins that no longer need to be supported.
NotFound pmichaud_: well, if we create an encoding for it, there is no point to make it variable width
NotFound I'm thinking about making a proof of concept using for example iso 8859-16 20:59
pmichaud_ well, keep in mind that there's already been a fair bit of work done on strings design via the strings PDD
it just hasn't been implemented yet
NotFound pmichaud_: a minor detail X-)
pmichaud_ that's where our effort should probably go, rather than trying to patch up what we have today 21:00
21:00 polyglotbot joined
pmichaud_ (by "patch up" I primarily mean "try other proof of concept approaches") 21:00
NotFound pmichaud_: I think the work about normalization and all that unicode subtles is orthogonal with the way of working with iso xxx charsets 21:01
21:02 pmichaud joined, Coke joined
pmichaud_ anyway, for me it's a design topic I'm not wanting to get too deep into. I just want Parrot to work, so I'll keep pointing out the bugs in hopes that someone fixes them :-) 21:02
however, it is the case that Parrot's string model needs to support Perl 6's requirements
NotFound And don't forget that there are lots of iso-8859 variants. Having a charset for each of them looks nightmaresque to me. 21:03
pmichaud_ I agree that we don't need a separate implementation for each iso-8859 variant.
NotFound 'charset' in parrot code meaning
pmichaud_ but just because we don't have an implementation for every iso-8859 variant doesn't mean we shouldn't have any at all 21:04
nopaste "NotFound" at 213.96.228.50 pasted "Patch for TT #752" (44 lines) at nopaste.snit.ch/16869
NotFound pmichaud_: no, but is a good reason for considering alternative ways. 21:05
pmichaud_ that patch looks wrongish to me 21:06
NotFound No worse than current code, to me. And it works, but current code don't. 21:07
pmichaud_ well, it has some special-casing that the current code doesn't have
that's "worse" by some measure
japhb Tene: Now that I finally have (mostly) working subversion again, I'm looking at runtime/parrot/languages/parrot/parrot.pir with fresh eyes. It occurs to me: why does the (_,_) multi of import() bother to compute the target namespace, since the (_,_,_) multi that it .tailcalls to will do that anyway? Is the idea that the (_,_,_) variant will be moved to PCT eventually, so its namespace automagic would be off by one? 21:08
NotFound I was tempted to try a more generic approach, but it risks to slow down lots of curent code.
The same happens every time I look at strings code, BTW 21:09
pmichaud_ api.c:432 looks wrong to me.
NotFound pmichaud_: I try to change that some time ago, don't remember why, and broke lots of things. 21:10
pmichaud_ just because a->strlen == a->bufused doesn't necessarily imply that it's ascii 21:11
NotFound Too much special cases and workarounds everywere.
pmichaud_ well, :432 doesn't look like too much of a special case to me
it makes sense except for that one line
NotFound I see now... It can wrongly convert iso 8859-1 to ascii, right? 21:12
pmichaud_ right.
oddly, the other situation below looks correct to me (line 442) 21:13
NotFound Don't remember if it was different last time I looked at that code.
But that code must have no effect in TT #753, the utf8 strings haven't pure ascii content. 21:16
pmichaud_ Agreed
NotFound I mean 752
pmichaud_ well, in 752, the first string (a) is iso-8859-1 and the second is utf8 21:17
NotFound Second branch applies, result is utf8
pmichaud_ right 21:18
that's what should be happening
and it should be returning utf8 encoding and unicode charset (from b)
line 444
so when we get to line 497 (before your patch), we should be allocating a new unicode/utf8 string, which is indeed what happens 21:19
so the bug is in Parrot_str_append
in Parrot_str_append, "a" is our result string, and "b" is the string being appended
NotFound Before the patch there are 2 str_append calls 21:20
pmichaud_ right 21:21
the first call is appending the iso-8859-1 string to the (empty) utf8 result
NotFound And it does not do a good work, yes.
pmichaud_ on line 546, what is that doing? 21:22
NotFound 546 befor patch?
pmichaud_ yes
/* Is A real? */ 21:23
maybe I should sic gdb on this
NotFound If is NULL, just copy b
pmichaud_ is our result string NULL in this case?
i.e., having just been created by Parrot_str_new_init ? 21:24
NotFound I think not, checks for string null or no buffer 21:25
pmichaud_ I'm walking through this with gdb... just a sec
NotFound And Parrot_str_nee_init in this case tries to create a buffer with the final result bytelength 21:26
I doesn't, but it tries ;)
pmichaud_ correct, we get to "saneify_string" in this case
that appears to simply be a set of PARROT_ASSERT macros 21:27
21:27 payload joined
pmichaud_ aha! 21:28
It is the ascii problem!
line 432 is the problem.
or at least is part of being wrong 21:29
Parrot_str_append calls string_rep_compatible
and when it does, the first parameter is the result string (utf8) and the second parameter is iso-8859-1
NotFound I'm convinced that that line is wrong, but I don't think is the only problem.
pmichaud_ but string_rep_compatible mistakenly returns Parrot_ascii_charset_ptr 21:30
instead of Parrot_iso_8859_1_charset_ptr
dalek cnum-dynpmcs: r86 | darbelo++ | trunk/ (2 files):
Add freeze/thaw VTABLES to DecNum and test them in t/freeze_thaw.t.
 21:31
pmichaud_ however, you're correct -- there's another problem here.
NotFound Commenting that if has no effect in the problem.
pmichaud_ because regardless of what it comes back with, it instantly changes the charset of the result string
which it should not do
the result string needs to be utf8
so there's another issue here 21:32
NotFound I think the problem lies in that string_rep_compatible does a thing, and Parrot_str_append expect that is does another,
cotto darbelo, you can also use is($I0, 0, "happy times") 21:33
dalek TT #728 closed by bacek++: r39273 breaks 'make test' for tcl
bacek good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
NotFound And even if it doed what it expects, the result will not be utf8
cotto hi, bacek
pmichaud_ anyway, after the first Parrot_str_append we end up with the result string being fixed_8 encoding and ascii (wrong)
21:33 Whiteknight joined
bacek hi cotto 21:33
NotFound Agreed
pmichaud_ now, let's see what happens with the second append 21:34
the second time we're appending the utf8 string to the result (which is now mis-encoded as ascii/fixed8)
cotto chromatic confirmed that we're not in the business of writing a C compiler: irclog.perlgeek.de/parrot/2009-06-11#i_1231696 21:35
NotFound pmichaud_: no difference, it does a memcpy anyway
pmichaud_ it's slightly different
here's the bug
we call string_rep_compatible
cotto afk: shopping 21:36
purl somebody said shopping was a drag. or a great time, if it's *barber* shopping! </kitch>
pmichaud_ and it's returning unicode charset (same as b)
but the next line is then assigning that encoding to a 21:37
that's wrong.
purl pmichaud_ is channeling thoth!
pmichaud_ these are lines 558 and 559
NotFound pmichaud_: it does the same for iso-8859-1, no trascoding at all.
pmichaud_ right
it's still wrong.
it's wrong for string_rep_compatible to say that utf8 and iso-8859-1 are compatible encodings 21:38
ascii, yes. iso-8859-1, no.
bacek cotto: I see. So... Why don't use NQP as PMC language? 21:39
NotFound pmichaud_: this was my first comment: <NotFound> About TT #752: IMO the code in Parrot_str_append is completely wrong.
pmichaud_ I disagree
It's not Parrot_str_append that is wrong, it's string_rep_compatible
lines 429 and 439 are wrong. 21:40
NotFound I see it a different way: string_rep_compatible does a different thing.
Is wrong, also, but that is another problem.
pmichaud_ string_rep_compatible is supposed to find the lowest possible compatible charset and encoding
it's not true that the lowest possible charset and encoding for utf8 versus iso-8859-1 is iso-8859-1
NotFound But 'compatible' in that case does not mean 'able to memcpy' 21:41
pmichaud_ I think that's exactly what it means.
NotFound Then iso-8859-1 and unicode utf8 aren't compatible
pmichaud_ correct.
NotFound So, all is wrong 21:42
That was my second comment.
pmichaud_ I don't know if "all is wrong", but that part certainly is.
NotFound <NotFound> I'm tempted to say the same about the entire strings/api.c file
pmichaud_ I wonder if the iso-8859-1 part was added as a workaround to something else. 21:43
GeJ Good morning everyone
pmichaud_ aha, it was. That was the workaround for RT #39930 21:44
that workaround is incorrect.
NotFound pmichaud_: if we don't take them as compatible, the logic is to convert to utf16, which is not was TT #572 expects.
pmichaud_ oh
then #752 is wrong
in truth, I don't care if the result comes back utf8
I just care that the result that comes back is correct 21:45
in this case, it isn't.
NotFound And probably lots of rakudo, also.
pmichaud_ no, rakudo doesn't care.
utf16 is a fine result for #752
"invalid utf-8 string" is not.
NotFound I don't care what the resut must be, as long as is clearly documented somewhere, which isn''t
pmichaud_ I'll update the #752 ticket 21:46
NotFound pmichaud_: I'm almost sure that if we convert things to utf16 we're going to hear lots of crying about things not working without icu. 21:47
pmichaud_ then we should convert to something other than utf16. Like, perhaps utf8. 21:48
NotFound Then we consider utf8 and iso-8859-1 compatible %-)
pmichaud_ No.
we don't
chromatic Isn't UTF-8 variable width?
pmichaud_ instead of upgrading to utf16, we upgrade to utf8
yes, utf8 is variable width. 21:49
ticket updated.
NotFound pmichaud_: well, I can try that way and see if it doesn't broke things. 21:50
Not today.
pmichaud_ first we have to get rid of the error in str_rep_compatible -- that is what is leading to other incorrect workarounds
NotFound Too late in CET
pmichaud_ I might work on it a bit, now that I see where the problem is.
21:55 eternaleye joined
Whiteknight chromatic: the inferior runloop problem can be resolved in C, if we could convert the runloop into a proper coroutine like allison suggested a while back 21:59
at least, I'm pretty convinced that would fix it
chromatic Now try to detect when an exception handler has ended and you need to rejoin the invoking runloop. 22:01
NotFound Whiteknight: that way you can't call sub or methods from C the way is being done now. 22:02
Maybe that will not be a bad thing. 22:03
chromatic That does hurt an embedding interface.
NotFound Yes, will require to provide a way to resume the execution at the C level that may be difficult to understand and use. 22:05
And don't even talk about wirite it %-) 22:06
Whiteknight I'm not sure I understand how L1 would be used to fix that problem. How would it be immune to multiple levels of runloop invocation or exception handlers?
NotFound I also don't understand that. 22:07
Whiteknight NotFound: you could indeed call a sub or method from C with a coroutine-based runloop
chromatic We have to make the L1 dispatcher responsible for all control flow.
NotFound Whiteknight: calling it I don't expect to be the problem. Returning to the call point is. 22:08
Whiteknight right, but how is it going to be responsible for that in a way that doesn't recreate the problems we already have in our C-based runloop
chromatic We don't rely on C code to throw exceptions.
Whiteknight NotFound: we could use simple register renaming to overwrite the return addresses 22:09
NotFound Whiteknight: returning to the C caller, I mean.
Whiteknight chromatic: you're right about that. I can understand that
chromatic PIR code now runs merrily along, throws an exception, suspends that runloop, runs some C code, finds an exception handler which may or may not be in PIR, and if it is invokes a new runloop which now must run until somehow it exits, at which point the C code calling it can return and the previous runloop can resume.
For *all* exceptions thrown throughout the system. 22:10
*Even* exceptions thrown from PIR code directly.
Whiteknight NotFound: that's just a small matter of storing a jump point to the caller
NotFound Whiteknight: that is not the way any C programmer in the world expects and undesrstand. 22:11
Whiteknight NotFound: I didn't say it would be pretty or understandable, but I have a strong belief that it's possible
chromatic: so walk me through how this would be implemented 22:12
chromatic Sure.
Whiteknight L1 code runs merrily along, throws an exception...
chromatic The L1 dispatcher sets aside the current continuation and its call graph.
Whiteknight so on a call stack of some sort?
or a storage stack?
chromatic A continuation; it's all CPS.
Whiteknight right, but where do you store that continuation, a stack? 22:13
so you can return to it
chromatic You pass it to the exception handler.
Whiteknight okay, so implicitly push it on the system stack. Gotcha
22:13 dalek joined
chromatic No, don't say "push" and don't say "stack". 22:13
Please don't say "system stack".
"System Shock" is okay.
Whiteknight resists the urge 22:14
please continue
chromatic Invoking an exception handler is, if you're using CPS which we are, the same as calling a function or returning from a function.
It's invoking a continuation of some kind, passing the return continuation.
Whiteknight ok 22:15
NotFound Except that we can have C handlers
chromatic The only reason I can think of to have C handlers in this scheme is for an embedding interface.
Whiteknight C-based handlers might not be an issue. 22:16
NotFound And exceptions throwing from C that doesn't know what the continuation must be.
Whiteknight ...if I'm thinking about his idea correctly now
22:16 polyglotbot joined
chromatic Exceptions thrown from C theoretically have access to the interpreter which contains the current executing L1 environment. 22:17
Whiteknight NotFound: Exceptions thrown from C now store a jump point instead of a continuation, so that's solved already
...or that
22:17 Coke joined
NotFound Whiteknight: solved if you ignore the inner runloops thing 22:17
Whiteknight I think I see what chromatic is saying now 22:18
chromatic What I'm saying is "We don't need C".
As limit -> infinity anyhow.
Whiteknight you realize this is going to be a pretty radical shift to the core architecture, right 22:19
NotFound Maybe a way to avoid some problems will be to forbid resume to C throwers, just allow it in throw_from_ops
Whiteknight like, this is a huge project, and a lot of points-of-no-return where we can't make gradual changes
chromatic Sure, but look at the pmcc suggestions.
Whiteknight the pmcc thing, I think, can be a pretty gradual change 22:20
chromatic It's only the last point, from PMC Language -> L1 and no C ever again that's a point of no return.
The same goes for a hypothetical ops compiler.
darbelo (gradual changes that bring about total revolution)++ 22:21
chromatic There are only two reasons we can't write all of our PMCs in PIR right now.
1) PIR doesn't give the kind of low-level access to memory and calling C functions that we need.
2) Bootstrapping is a pain.
22:22 pmichaud joined
chromatic 2.5) More people know C than L1/Cequiv. 22:22
Whiteknight How are we going to get calling access to C functions from L1? 22:28
its not like that need disappears when we switch languages 22:29
22:29 bacek joined
chromatic Sure, we need to support that to make NCI work too. 22:29
We probably (and hopefully the short-lived kind of temporarily) need to do that to migrate some PMCs to PMCLang. 22:30
22:32 rg1 joined
Whiteknight So what's PMCLang going to be? L1, a variant thereof, or another translate-to-pure-C script? 22:32
chromatic L1 is a set of opcodes. 22:33
It's not a language.
Whiteknight so is L1 a subset of PIR, or a separate entity entirely? 22:34
chromatic It's a set of instructions that nanoparrot understands, that can be the basis of other opcodes, and (perhaps most importantly) is trivial to JIT.
It's not syntax. It's just a set of opcodes.
It's a subset of PIR in the same sense that src/ops/var.ops is a subset of PIR.
Whiteknight so other ops get translated into L1 through some kind of direct translation, like a lookup table? 22:36
chromatic Or a compiler. 22:37
purl a compiler is, like, a controversial feature of Perl5.005 which will probably be used for evil ends or a way for the unenlightened to make themselves think their programs will run faster
Whiteknight the faster we can do the PIR->L1 translation the better, and a cached lookup table is going to be the best 22:38
pmichaud_ iiuc, we'd need to specify a syntax for defining pmc and ops in terms of L1, and a compiler for it. The analogy is the way we have a syntax (PASM/PIR) for parrot opcodes, and a compiler (imcc) to translate it
chromatic pmichaud_ has it right. 22:39
Whiteknight right, but we're still going to have PASM/PIR and IMCC/PIRC. And we're going to top that with yet another compilation step down to L1? 22:45
A build step could convert PMC definitions down to arrays of pre-compiled L1 bytecode 22:46
chromatic Yep.
Whiteknight so no runtime compilation there
chromatic Nope.
Look at all of the initialization our C-based data structures need to do to create PBC-like data in memory when Parrot starts. 22:47
Every time.
purl rumour has it every time is peak time somewhere
Whiteknight And without that, I don't think we need anything even resembling a compiler for L1
22:47 sekimura joined 22:48 kid51 joined
Whiteknight it's my initial conception that L1 should not be a subset of PIR, but a separate entity entirely. PIR-like, but smaller, faster, more standard, etc 22:48
chromatic L1 isn't a language. It's just a small collection of fundamental opcodes. 22:49
Whiteknight yeah, that's what I'm saying shouldn't be. I'm saying it should be it's own language
chromatic What's the benefit to that?
Whiteknight a single translation step, every opcode gets directly translated to a stream of L1 code 22:50
L1 ops are always written in C, PIR ops are always written in l1
chromatic How does that make L1 its own langauge?
*language
Whiteknight how doesn't it? not defined the same, not executed the same 22:51
chromatic For one thing, you don't need a compiler for L1 if you have a chunk of L1 ops stored on disk. 22:52
Whiteknight what do you mean by that?
chromatic I suppose you could say that a compiler can turn a textual representation of L1 into L1 ops for nanoparrot to execute.
Whiteknight Besides things defined at build time, I don't think we need to keep a textual representation of L1 around 22:53
chromatic That puts it in the category of "Not a language" for me.
It's merely a library of ops. 22:54
Whiteknight I'm envisioning something very simple, like a table-lookup assembler instead of any sort of "compiler"
chromatic Whatever processes PMClang and Opslang has to emit L1, whether in textual form or bytecode. 22:55
Whiteknight right, I'm envisioning compiled to arrays of bytecode
chromatic We need an L1 emitter for PCT.
Whiteknight then at runtime, we just string together the appropriate arrays into the order specified by the PIR program
it's like a small Parrot-level JIT 22:56
22:56 burmas joined
Whiteknight well, conceptually similar 22:56
chromatic But the PIR program becomes a stream of L1 ops.
Whiteknight right
chromatic Alright, as long as we're both clear on that. 22:57
Whiteknight I'm thinking PIR->PBC because PBC is going to be more compact, and then PBC->L1BC 22:58
at least, packfiles should be PBC for brevity
PBC opcode_t could just be indexes into an array of frozen L1BC sequences 22:59
23:00 burmas joined
chromatic Think of it this way: a program or compiler written without C code can include its own ops and PMCs written in L1 and only those ops and PMCs it needs. 23:00
In other words, if you never use the transcendental math ops from src/ops/math.ops or wherever, you don't even have to include them in whatever your PBC becomes.
Even though Parrot includes a built-in PIR compiler right now in the form of IMCC, if there's a self-hosted PIR compiler which relies only on L1 ops at the bottommost level, you don't have to include that. 23:01
Whiteknight So that's an interesting idea, a PBC file can contain a header with the L1BC definitions for the ops it uses 23:02
23:02 burmas left
Whiteknight so you define custom ops and save them to your bytecode, and can execute them on any parrot, even if it doesn't know those ops 23:02
chromatic Exactly.
Whiteknight me likey 23:03
chromatic Or (and you'll like this one), you can have pluggable, overrideable op libraries.
Suppose you want to annotate the memory management ops with profiling information.
Load an op overlay which adds a couple of instructions, recompile, and go.
Adds a couple of instructions to the memory management ops you defined, I mean.
Whiteknight right 23:04
chromatic Optimizations can inline code and coalesce register usage and perform escape analysis and remove duplicate code *even if the optimizer is unaware of the local declaration of those ops* because that doesn't matter. 23:05
The more of Parrot we define in terms of L1, the more of Parrot we can port to other VMs and environments because we only have to port or translate the L1 infrastructure. 23:07
23:08 snarkyboojum joined, gryphon joined
kid51 interrupts to ask: chromatic/Whiteknight: Any thoughts on trac.parrot.org/parrot/ticket/281 ? 23:19
(281 is one of the unowned TTs marked for this milestone.) 23:20
nopaste "pmichaud" at 72.181.176.220 pasted "This gives me a segfault on exit.... and I don't know why. Clues welcome." (71 lines) at nopaste.snit.ch/16872
chromatic TODO them as specifically as possible.
23:21 donaldh joined
chromatic kid51, I just don't want to close tickets before we've solved the problems. 23:26
kid51 Agreed. Let 23:27
's see if I can figure it out.
23:32 patspam joined
dalek rrot: r39512 | jkeenan++ | trunk/t/op/debuginfo.t:
Change handling of 3 tests from SKIP to TODO. Cf.: trac.parrot.org/parrot/ticket/281?#comment21.
 23:44
purl dalek: that doesn't look right
kid51 Can you give perl t/harness t/op/debuginfo.t a whirl with the -f, -g, -j and -S options?
chromatic In a few, yes. 23:45
23:58 silug 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!