Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 Whiteknight darbelo++\
00:00 Whiteknight (going to the hospital if you are sick enough to hallucinate)++
00:00 Whiteknight (bringing a laptop so you can continue coding at the hospital)+
00:02 Tene darbelo: that's what revision control is for.
00:04 snarkyboojum joined #parrot
00:05 Whiteknight what he needs is health control: Revert back to the last healthy state
00:05 GeJ can git do that already?
00:07 darbelo Whiteknight: I support the idea as long as you don't need to 'bisect' in order to find the last healthy state.
00:09 itrekkie joined #parrot
00:10 jonathan sjohnson:
00:10 jonathan oops
00:10 itrekkie left #parrot
00:10 jonathan I didn't even want to say anything too him.
00:11 jonathan 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:13 bacek joined #parrot
00:23 Zak joined #parrot
00:29 payload joined #parrot
00:50 dalek decnum-dynpmcs: r84 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
00:50 dalek decnum-dynpmcs: Move the guts of the set_rounding_mode() METHOD to a helper function.
00:50 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=84
00:56 flexibeast joined #parrot
00:58 ZeroForce joined #parrot
01:12 japhb Tene: about?
01:24 Tene japhb: what's up?
01:24 purl Me, you bitches!  I'm high on crack!
01:25 cotto and suddenly it all makes sense
01:26 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 japhb Anyway,
01:26 Tene japhb: afaik, I'm still blocking on S11 feedback from pmichaud
01:26 cotto japhb, +1
01:26 japhb Tene: I've been AFK for a few days.  Did you manage to get the export/import stuff further along?
01:26 Tene if that's what you're asking.
01:27 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 japhb Can we get at least the export-understands-array-and-hash bit, if not anything else?
01:28 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.
01:28 japhb :-)
01:29 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 Tene runtime/parrot/languages/parrot/parrot.pir
01:29 Tene it should be in the 'export' method in that file.
01:29 japhb Tene: fair enough.  Make my own dogfood, I'm fine with that.
01:30 japhb ... 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.
01:30 Tene Oh, it will.  It's all time-sensitive, and should expire by midway through next week.
01:30 Tene It's just that the release is happening the day before my panic expires. :)
01:31 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.
01:31 Tene so you're safe.
01:31 japhb (Mostly because so many of the core Parrot C coders are in fear of it, and I figure there's probably a reason.  :-)
01:31 japhb Excellent.
01:31 Tene it's only that file.
01:32 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.
01:33 japhb Isn't there some way to mark something as experimental?
01:33 japhb In fact, isn't cross-language import/export all in that category?
01:33 Tene Well, nobody is actually using this stuff at all for anything yet, afaict.
01:34 japhb Since everything I'm doing is experimental, I'm not terribly worried about depending on an API that is officially experimental.  :-)
01:35 Tene I think pmichaud wanted to migrate most of the PIR libs to use this sometime soon, maybe.
01:36 Tene 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 Tene Anything else before I AFK?
01:36 japhb Nope, thank you very much.
01:36 Tene Yeah, no problem.
01:37 Tene 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 Tene AFK, driving home.
01:38 japhb Tene: gotcha.  Didn't remember you were a backlogger
01:42 pmichaud I haven't forgotten about the S11/api stuff.
01:42 pmichaud I haven't completely resolved it in my head yet, either.  But it's on my agenda to resolve before the release.
01:43 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:44 pmichaud japhb: I'm not aware of one (nor am I the person to be able to create one)
01:44 japhb hmm
01:44 pmichaud Our best bet would be to create the API and immediately deprecate it :-)
01:44 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.
01:44 japhb heh
01:44 pmichaud I've done that once before.
01:45 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.
01:45 pmichaud Of course, deprecations don't matter until the July release anyway.
01:45 pmichaud So it's the July deadline that's important, not the June one.
01:45 japhb nod
01:52 chromatic joined #parrot
01:53 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.
01:53 pmichaud It is in rakudo, though.
01:54 japhb That's the one I'm looking for.
01:54 pmichaud src/builtins/compiler.pir
01:55 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.
01:55 pmichaud (well, one part among several)
01:58 japhb Does Perl6::Compiler::parse_name() handle the ':from<other_lang>' bit?
01:58 pmichaud no.
01:59 pmichaud it's simply to take a name and split it up according to namespace rules (that's in the pdd)
01:59 pmichaud according to the rules for the language
02:02 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:16 Theory joined #parrot
02:18 eternaleye joined #parrot
02:28 kid51 joined #parrot
02:35 janus joined #parrot
02:46 rakudohudson joined #parrot
02:47 pmichaud is there a way to determine the path sequence that parrot is using for .loadlib ?
02:47 pmichaud it appears to me that it prefers installed copies of libraries to any locally built ones
02:49 dukeleto joined #parrot
02:50 chromatic One of the IGLOBALS is an *Array* PMC you can query.  I don't remember which one.
02:50 pmichaud that helps.
02:50 bacek IGLOBALS_LIB_PATHS
02:50 chromatic That sounds right.
02:51 bacek get_search_paths in src/library.c
02:51 pmichaud how do I use IGLOBALS?
02:51 pmichaud (haven't used it afaik)
02:52 pmichaud interpinfo?
02:52 purl it has been said that interpinfo is the culprit there.
02:52 chromatic There's a constants PASM file that gives you access to individual entries.
02:53 chromatic I'd have to ack the tests to find an example.
02:53 pmichaud right, I got that part
02:53 pmichaud looks like it's subscript access on a ParrotInterpreter PMC
02:54 pmichaud ResizableStringArray (size:3) [
02:54 pmichaud "runtime/parrot/dynext/",
02:54 pmichaud "/home/pmichaud/rakudo/parinst/l​ib/parrot/1.2.0-devel/dynext/",
02:54 pmichaud "dynext/"
02:54 pmichaud ],
02:54 pmichaud that looks.... annoying.
02:55 chromatic It's modifiable though, which is a nasty hack.
02:55 pmichaud well, here's the anti-use case
02:55 pmichaud (1) someone downloads Rakudo, builds against installed parrot
02:56 pmichaud (2) install Rakudo, copying the Rakudo dynext into the parrot install tree
02:56 pmichaud (3) download updated version of Rakudo, build against installed parrot
02:56 pmichaud this last build ends up using the installed dynexts, instead of the ones just created as part of the build
02:57 chromatic That does seem wrong.
02:57 chromatic It's easy to create another use case where this behavior is right, though.
02:57 pmichaud all of the other LIB_PATHS seem to have the current directory before the installed one.
02:57 pmichaud so I wonder why this one is different.
02:58 nopaste "pmichaud" at 72.181.176.220 pasted "LIB_PATHS" (39 lines) at http://nopaste.snit.ch/16857
03:02 pmichaud okay, that was apparently done pre-1.0, so I guess a trac ticket is in order.
03:07 pmichaud yay, make test is passing!
03:07 dalek parrot: r39502 | cotto++ | branches/pmc_pct (12 files):
03:07 dalek parrot: [pmcc] finish switching pmcc to use the new vtable dump, delete/update relevant files
03:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39502/
03:11 dalek parrot: r39503 | pmichaud++ | trunk/MANIFEST.generated:
03:11 dalek parrot: [install]:  additional files needed for building Rakudo from installed Parrot.
03:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39503/
03:20 donaldh joined #parrot
03:27 japhb joined #parrot
03:35 cotto iwbn if frozen PMCs also depended on PBC_COMPAT
03:36 cotto it would have saved me a good 30m just now
03:38 chromatic You would just have watched TV anyway.
03:38 cotto that's not the point ;)
03:41 chromatic Summer reruns!
03:41 Tene japhb: when we discussed this before, we decided that what you wanted to do *really* belonged in export()
03:42 cotto Hmmm.  The freeze/thaw code already includes a packfile header, it just doesn't bother to check it.
03:42 dalek parrot: r39504 | cotto++ | branches/pmc_pct (152 files):
03:42 dalek parrot: bring the pmc_pct branch up-to-date with trunk
03:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39504/
03:43 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:
03:45 japhb 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 s1n joined #parrot
03:45 Tene Sure.
03:47 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 japhb And there's a 2.a ....
03:48 japhb 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 japhb eol
03:48 Tene um... what change do you need to make to the import API?
03:49 Tene Yes, there should be a default implementation in PCT.  That's what we're prototyping here.
03:50 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 japhb May end up being faster with the OO interface as well.
03:51 Tene three issues with that, iirc.
03:51 Tene AFK for a sec, though.
03:51 Tene finishing preparing dinner.
03:52 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 japhb nodnod
04:07 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:08 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.
04:08 Tene That's not necessarily a namespace.
04:08 japhb Tene: They may not internally be using a parrot namespace, but why wouldn't they be able to respond to that API?
04:09 japhb Erm ... that's in my mind the definition of a namespace.
04:09 dalek parrot: r39505 | cotto++ | trunk/src/pmc_freeze.c:
04:09 dalek parrot: [freeze/thaw] Make ft_init slightly more paranoid about checking header version numbers.
04:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39505/
04:09 japhb I'm guessing there's a terminology disconnect ...
04:11 japhb 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:12 japhb 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:13 Tene Sorry, got disconnected
04:13 japhb np
04:13 japhb I'm afraid I feel rather ignorant at the moment, because I'm really not seeing the problem at all.
04:14 Tene japhb: I just didn't necessarily want to mandate that it had to return a Parrot namespace or subclass thereof.
04:14 Tene a Hash would be just fine.
04:14 Tene But, sure, I can be swayed one way or the other.  I don't feel strongly about it.
04:14 Tene It just feels a bit restrictive.
04:14 Tene moving on
04:15 Tene 2) the 'export_to' method *requires* a list of names to export.
04:15 Tene 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.
04:15 cotto bacek, ping
04:15 Tene so I can't just pass that.
04:16 dalek parrot: r39506 | cotto++ | trunk/src/pmc_freeze.c:
04:16 dalek parrot: [stupid] cotto-- is not very good at numbers
04:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39506/
04:16 Tene and 3) that's just an implementation issue... not an API.
04:17 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?
04:18 Tene This certainly could be a lack of knowledge on my part.
04:19 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
04:19 Tene pmichaud: can I pass an iterator to .'export_to'() ?
04:19 pmichaud probably not
04:20 Tene exactly
04:20 japhb Then we should Make It So.
04:20 pmichaud (I haven't read the backscroll yet, btw)
04:20 japhb Actually, that was just a knee-jerk reaction.
04:20 pmichaud I don't intend to pass iterators around, no.
04:20 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?
04:21 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>.
04:21 Tene japhb: how do you do it for a Hash pmc?
04:21 Tene I couldn't find it.
04:23 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:24 pmichaud I simply went with the hashkey interface because that's closest to what was there previously (when I refactored)
04:24 pmichaud OTOH, there's a good argument to be made that the hashkey interface should also go through the OO interface.
04:24 pmichaud also, the OO interface leaves a couple of things to be desired.
04:24 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.
04:25 japhb pmichaud: no argument there.
04:25 Tene japhb: me too. :)
04:25 pmichaud the way to get the list of keys from a Hash PMC is to iterate over the Hash
04:25 pmichaud I'm not aware of a faster one.
04:25 pmichaud (or more straightforward one)
04:25 Tene pmichaud: you can only use the OO interface if it's a NameSpace, not a Hash or other keyed lookup object.
04:25 Tene But, a conditional would be fine.
04:25 pmichaud when would be importing to something other than a namespace?
04:25 pmichaud *we be
04:26 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.
04:26 Tene I just didn't know if we wanted to allow for some language to return a Hash of symbols instead of a NameSpace.
04:26 pmichaud oh, I assumed that question was aimed at the notion that the exported symbols could be in something other than a Namespace
04:27 pmichaud 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?
04:27 pmichaud you're saying that a language might prefer to use a Hash instead of a NameSpace as its symbol table
04:27 bacek cotto: pong. (I'm quite busy atm... A lot of stuff at $dayjob)
04:27 pmichaud (as its internal symbol table, that it imports symbols into)
04:28 pmichaud 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?
04:28 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.
04:28 Tene Regardless, this entire part of the discussion isn't actually relevant to API concerns... it's an implementation issue.
04:28 bacek cotto: same as in pmc2c. It's easiest way for now.
04:29 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
04:29 pmichaud in other words, if it doesn't match what we think needs to happen, we aren't really bound to it
04:29 Tene The only API question is...
04:30 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.
04:30 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?
04:30 bacek cotto: may be emitting C from NQP and rewrite PMCs in NQP is better.
04:30 pmichaud objects that responds to keyed lookup and iteration
04:30 bacek (I know, it's crazy idea)
04:31 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.
04:32 Tene 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.
04:32 Tene accepts anything that implements a hash interface (including other NameSpaces)
04:32 pmichaud at least, it shouldn't be a driving issue at the moment.
04:32 cotto bacek, how much of C do we really need to parse to replace pmc2c?  I thought just did simple textual substitutions.
04:32 Tene Neither do I.  japhb does, though.
04:32 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.
04:33 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.
04:33 japhb Right now I can't even do a Hello World equivalent.
04:33 bacek cotto: this is pmc2c approach.
04:33 cotto right; we could cheat for C and do legitimate parsing for L1
04:34 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 Tene japhb: so let's get back to the part that actually matters.
04:34 japhb I'm certainly fine with that.
04:34 bacek cotto: to much cheating in parrot already...
04:35 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.
04:35 pmichaud (1) clone rakudo repo
04:35 pmichaud (2) git checkout -b ins
04:35 pmichaud (3) perl Configure.pl --gen-parrot
04:35 pmichaud (4) make
04:36 Tene pmichaud: pretty sure that checkout will just make a new local branch, not checkout your branch
04:36 Tene confirming...
04:36 bacek cotto: there is nothing more permanent than "something temporary" :)
04:36 cotto ok.  bad excuse
04:37 pmichaud oh.
04:37 Tene git checkout --track -b ins origin/ins
04:37 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
04:37 bacek cotto: have to run. Just another meeting.
04:37 pmichaud you're correct.
04:37 cotto bacek, np
04:38 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.
04:41 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.
04:41 japhb OK, then that will be the plan.
04:42 japhb 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
04:42 japhb excellent.
04:43 pmichaud oops, already found an error in branch
04:43 pmichaud fixing
04:43 japhb What test sets should I run before committing?  Do Rakudo and/or Cardinal have tests for this?
04:43 pmichaud what file did you modify?
04:44 Tene japhb: nothing at all anywhere uses that file
04:44 Tene pmichaud: runtime/parrot/languages/parrot/parrot.pir
04:44 pmichaud right, we don't rely on that yet.
04:44 japhb (*will* modify) runtime/parrot/languages/parrot/parrot.pir ... damn, Tene types a lot faster.
04:44 Tene japhb: rakudo or cardinal *could* use it... but there are no PIR libraries that use it yet.
04:45 Tene OpenGL will be the first. :)
04:45 japhb heh
04:45 japhb Leading by (bad) example ...
04:45 Zak joined #parrot
04:46 Tene Well, if I moved any of the standard PIR libraries into their own namespaces, everything tha tused them would break.
04:46 Tene iiuc
04:53 japhb OK, what is this: svn: OPTIONS of 'https://svn.parrot.org/parrot/trunk': could not connect to server (https://svn.parrot.org)
04:54 Coke ~~
04:54 Tene
04:56 cotto very smart match
04:56 pmichaud vertical smart match, instead of the horizontal one.
04:59 Coke that better be a synonym.
04:59 Coke my client sucks, that's a ? her.e
05:01 Coke 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 #parrot
05:04 Coke japhb: 'svn cleanup' ?
05:04 Coke were you trying to svn up?
05:05 Coke (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.
05:05 * japhb has a sneaking suspicion that he has fallen prey to Debian pedantry ...
05:06 japhb Normally, I love Debian's packages, but the time I've lost to inane pedantry ... cannot be regained.
05:10 dalek partcl: r474 | coke++ | trunk/runtime/builtin/proc.pir:
05:10 dalek partcl: Remove stale comment, useless trans_charset, and explicit unbox.
05:10 dalek partcl: Another artifact from a distant time.
05:10 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=474
05:16 * japhb wants to beat SVN with a carp
05:18 * japhb decides to use git to version ~/.subversion ...
05:39 dalek partcl: r475 | coke++ | trunk/runtime/builtin/proc.pir:
05:39 dalek partcl: switch from die to tcl_error, use better var names, minor cleanup.
05:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=475
05:39 dalek partcl: r476 | coke++ | trunk/tools/spec_info.pl:
05:39 dalek partcl: capture stderr too.
05:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=476
05:47 eternaleye joined #parrot
05:58 nopaste "GeJ" at 202.171.79.162 pasted "One-line fix for a failing test in t/codingstd/c_parens.t" (11 lines) at http://nopaste.snit.ch/16858
06:00 GeJ if anyone wishes to take it.
06:01 GeJ it fixes a space-before-closing-parens error.
06:03 NotFound Done
06:03 GeJ thank you
06:05 dalek parrot: r39507 | NotFound++ | trunk/src/pmc_freeze.c:
06:05 dalek parrot: [cage] codingstd fix, GeJ++
06:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39507/
06:07 cotto I figured it'd be something I did.
06:12 uniejo joined #parrot
06:13 Theory joined #parrot
06:24 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 japhb ini-rant>
06:24 japhb I think I'm going to go to give up on this battle for the night, and try again another time with more sleep.
06:34 szbalint pedantry = licensing issues
06:35 szbalint 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:36 szbalint I wish copyright and licensing would go away heh.
06:52 eternaleye joined #parrot
06:53 TonyC joined #parrot
06:59 mj41 joined #parrot
07:10 chromatic joined #parrot
07:15 dalek parrot: r39508 | cotto++ | trunk/src/pmc_freeze.c:
07:15 dalek parrot: [tt] Worst. Dyslexia. Ever.  Hopefully the I get the TT number right the third time.
07:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39508/
07:22 donaldh joined #parrot
07:23 dukeleto joined #parrot
07:37 viklund_ joined #parrot
07:56 barney joined #parrot
08:27 clunker3_ joined #parrot
08:54 gaurav joined #parrot
09:06 particle1 joined #parrot
09:22 clinton joined #parrot
09:25 particle joined #parrot
09:28 bacek joined #parrot
09:39 cotto bacek, ping
09:39 bacek cotto: pong
09:40 bacek You just woke up or didn't sleep yet? :)
09:40 cotto not sleeping yet
09:40 cotto not working has its advantages
09:40 bacek yeah...
09:41 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:42 bacek It throw away job.
09:43 bacek s/ / is /
09:43 bacek To emit something apart from plain C we have to fully parse body. Preserving semantic.
09:44 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"
09:44 bacek for pmc body.
09:45 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?
09:46 bacek 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.
09:46 cotto That'd give us a nice migration path, if it's feasible.
09:47 bacek We can target current PIR as "L1 prototype"
09:47 snarkyboojum joined #parrot
09:48 bacek (And have it "for free" because PCT already support it)
09:48 bacek Then we can adjust PCT to emit L1
09:48 bacek ...
09:48 bacek Profit!
09:49 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".
09:49 bacek Less ops, less sugar.
09:50 cotto like pasm?
09:50 bacek something like pasm.
09:50 bacek even more reduced.
09:51 cotto but that's the future.
09:51 bacek bright shiny future :)
09:51 cotto yes
09:52 cotto 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 cotto plus it violates laziness
09:53 bacek to satisfy laziness it's probably easier to try parse C in ops.
09:54 bacek Generally it's simpler than full featured PMCs body.
09:54 bacek L1?
09:54 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 http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550 or http://rt.perl.org/rt3/Ticket/D​isplay.html?id=39313#txn-471982
09:54 cotto You mean we should parse the C in src/ops/*.ops or we parse C to turn it into L1?
09:55 bacek Step 4 from chromatic++ idea
09:55 bacek we parse C in ops to turn it into L1
09:56 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
09:57 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.
09:59 bacek So, afaiu, we sematically parse PMC's bodys, emit C. Than replace emitter to emit L1.
09:59 cotto so far, so good
10:00 cotto *but* since the bodies are currently already C, we don't have to do full-on parsing
10:00 cotto s/C/mostly C/
10:00 bacek Almost. But for emitting L1 we need it. And we already have pmc2c which handles first part.
10:01 bacek That's why I think that without full body parsing it's "throw away" job.
10:02 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 cotto not that it takes C and emits L1
10:03 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.
10:04 * bacek hate English ambiguity...
10:04 cotto It hates you too, although it hates everyone at some point.
10:05 cotto 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
10:05 bacek there is a question
10:06 cotto and possibly an answer
10:06 bacek indeed
10:07 bacek 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.
10:08 bacek Or we can agree on something and go ahead :)
10:08 cotto I vote for not parsing C.
10:08 cotto ever
10:09 bacek Anyway, there is a lot of things which have to be done apart from parsing C.
10:09 cotto quite a few
10:09 purl quite a few are funny
10:09 bacek .oO( METHODs... )
10:10 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...
10:10 cotto btw, I got pmcc working with the vtable dump from compilers/vtdumper
10:11 cotto 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...
10:11 cotto ok
10:12 cotto no need to repeat them then
10:13 bacek btw, I want to fix Hash/Keys/Iterators support in parrot before return to pmc_pct.
10:13 cotto that's all
10:14 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
10:14 cotto There's some ugly code in Keys.
10:14 bacek I can reuse ~10% of code though.
10:15 cotto That sounds about right.
10:15 cotto What's the motivation?
10:15 purl hmmm... the motivation is just distraction from realization of futility.
10:15 cotto no, the motivation is brownies
10:15 purl okay, cotto.
10:16 bacek Emitting PBC from within PIR.
10:17 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
10:18 bacek Yeah, fine. I'll jump back on this train next week.
10:18 cotto right around yapc time
10:19 bacek it's on another side of globe...
10:20 cotto as am I, which means I really need to get to sleep
10:20 cotto good night
10:20 cotto and happy hacking!
10:21 cotto 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...
10:22 cotto night
10:22 bacek night
10:33 dalek joined #parrot
10:34 DanielC joined #parrot
10:35 DanielC How do you do a string comparison in PIR? I tried  "if algo == 'MD5' goto MD5"
10:36 DanielC wait... I goofed.
10:36 DanielC Yeah, it works :)
10:38 snarkyboojum joined #parrot
10:40 ujwalic joined #parrot
10:41 ujwalic_ joined #parrot
10:51 kid51 joined #parrot
11:06 payload joined #parrot
11:22 donaldh joined #parrot
11:37 flexibeast joined #parrot
11:47 contingencyplan joined #parrot
11:49 dalek partcl: r477 | coke++ | trunk/docs/spectest- (2 files):
11:49 dalek partcl: regain 2 spec tests\nrecord a modest speed improvement.
11:49 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=477
11:54 kj joined #parrot
11:54 kj left #parrot
11:55 kj joined #parrot
11:56 mikehh make -k fulltest fails manifest_tests, examples_tests and distro_tests PASSes the rest
11:57 mikehh Ubuntu 9.04 i386 at r39508
11:57 mikehh same result as yesterday - http://nopaste.snit.ch/16853
12:01 mikehh should I open a ticket on this?
12:07 kid51 What is the -k option?
12:11 mikehh prevents error exit I think
12:11 mikehh -k, --keep-going Keep going when some targets can't be made.
12:13 mikehh used to use male fulltest_all until I found out about it
12:13 mikehh which makes that redundant
12:13 kid51 Someone forgot to update MANIFEST.
12:14 kid51 I just fixed that.
12:14 dalek parrot: r39509 | jkeenan++ | trunk/MANIFEST:
12:14 dalek parrot: Add src/pmc/handle.pmc; someone forgot it.
12:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39509/
12:15 mikehh well that should take care of manifest_tests and distro_tests
12:16 mikehh 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.
12:17 kid51 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 #parrot
12:44 mikehh manifest_tests now pass but examples_tests and distro_tests still fail
12:47 mikehh distro_tests -  #  svn ps svn:keywords "Author Date Id Revision" src/pmc/handle.pmc
12:48 mikehh and no test files for that file - handle
12:51 mikehh examples_tests - t/examples/pod.t - 7 errors in docs/pdds/pdd19_pir.pod and :invocant error in docs/book/ch03_pir.pod
12:52 mikehh others all TODO
12:54 payload joined #parrot
12:54 dalek parrot: r39510 | barney++ | trunk/src/pmc/handle.pmc:
12:54 dalek parrot: [distro] set svn properties for handle.pmc
12:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39510/
13:16 jq joined #parrot
13:20 barney mikehh: Could you open two tickets, for the missing testfile and for the invalid PIR in the POD-files
13:20 barney These look like real errors
13:30 mikehh ok will do
13:38 snarkyboojum joined #parrot
13:40 Steve_H joined #parrot
13:43 snarkyboojum joined #parrot
13:45 dalek TT #750 created by mikehh++: Failures in examples_tests - t/examples/pod.t - fails 9 tests
13:56 Whiteknight joined #parrot
14:12 dalek TT #751 created by mikehh++: test failures related to src/pmc/handle.pmc
14:17 Whiteknight doesn't codetest run as part of fulltest?
14:21 masak joined #parrot
14:23 Theory joined #parrot
14:23 barney Yes, codetest is part of fulltest,  distro_tests is part of fulltest, but not of codetest
14:37 mikehh sure, but you can run them separately as well
14:37 Andy joined #parrot
14:37 mikehh as on make codetest or make distro_tests etc.
14:38 mikehh s/on/in/
14:38 payload joined #parrot
14:38 Whiteknight okay, I did run fulltest on that branch, but apparently not everything got tested
14:41 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 mikehh completes
14:42 coke_afk joined #parrot
14:44 mikehh the distro_tests failure is indicating that there is no corresponding test file
14:45 Coke "someone added code without tests."
14:45 Coke or, possibly "tests in the expected location."
14:45 Coke the PIR example errors are from the book author/editor, I wager.
14:47 barney e.g .macro_local is specced, but not implemented in IMCC
14:49 mikehh at the moment these tests are the only ones failing (for me anyway) on all the tests I have run
14:51 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:52 viklund_ joined #parrot
14:52 Whiteknight I'll fix that handle.pmc thing tonight
14:53 mikehh it only came up with problems with codetest after the manifest_tests problem was fixed
14:53 davidfetter joined #parrot
14:54 bkuhn joined #parrot
14:57 Whiteknight oh, that one finally got fixed?
14:58 pmichaud I'm looking for folks to test rakudo's new build system (building from installed parrot)
15:00 pmichaud instructions at
15:00 purl be SPECIFIC for HOLY FUCKING GOD SAKE! http://trash.chregu.tv/instructions.txt
15:00 pmichaud http://gist.github.com/127957
15:01 mikehh I haven't tried installing parrot - I just have the development setup - I build rakudo with --parrot-config=../parrot/parrot_config
15:02 pmichaud the instructions I just gave does a local install inside of the rakudo directory
15:02 pmichaud (i.e., it doesn't do a systemwide install)
15:06 Whiteknight pmichaud, I posted a request for help to the list
15:06 pmichaud Whiteknight: thanks
15:21 donaldh joined #parrot
15:31 darbelo joined #parrot
15:49 contingencyplan joined #parrot
15:54 * particle tests the instructions on win32/msvc
16:00 particle parrot is building now...
16:01 Steve_H left #parrot
16:02 HG` joined #parrot
16:06 whoppix joined #parrot
16:18 benkay joined #parrot
16:19 benkay joined #parrot
16:25 Psyche^ joined #parrot
16:29 davidfetter joined #parrot
16:49 dalek TT #158 closed by NotFound++: deprecated:  :anon and :vtable named parameters to add_method
16:52 particle pmichaud: ...
16:52 particle NMAKE : fatal error U1073: don't know how to make 'c:\Users\particle\dev\rakudo-instal​l\rakudo\parrot\install\bin\parrot'
16:52 particle Stop.
16:56 d4l3k_ joined #parrot
17:01 pmichaud_ joined #parrot
17:01 pmichaud_ particle:  I just pushed a change to github -- perhaps "git pull" and try again?  Shouldn't result in rebuilding Parrot.
17:02 pmichaud_ (my connection to feather is flaky and keeps dropping out)
17:02 pmichaud_ I need to grab lunch and pick up daughter from school.... bbiah
17:02 particle do i need to perl Configure.pl again?
17:02 pmichaud_ yes.
17:02 pmichaud_ perl Configure.pl --gen-parrot
17:02 particle gen-parrot?
17:03 pmichaud_ but it should detect that your parrot is up-to-date and not rebuild it.
17:03 particle seems rakudo is building now
17:03 particle this is just to build against installed parrot, not install rakudo, right?
17:03 pmichaud_ correct.
17:03 pmichaud_ rakudo still doesn't have a 'make install' target.
17:03 particle ok, well, it's building, and you'll have my results when you return.
17:03 pmichaud_ I'm not exactly sure how to make that one work.
17:03 pmichaud_ great.
17:04 particle building pmc's now
17:04 * pmichaud_ expects FAIL
17:04 particle fails during link
17:04 particle no argument specified with option /out:
17:04 particle seems an easy fix
17:04 pmichaud_ can you nopaste the command/error message?
17:05 particle sure...
17:05 nopaste "particle" at 76.121.106.245 pasted "rakudo build error" (6 lines) at http://nopaste.snit.ch/16863
17:06 pmichaud_ why does it not see the argument to out?
17:06 pmichaud_ is it not able to accept a -out with a path?
17:07 particle probably doesn't like space
17:08 * particle checks the parrot makefile
17:08 pmichaud_ yes, apparently spaces are bad.
17:08 pmichaud_ I took mine from partcl's makefile, which I guess would suffer the same issue
17:08 pmichaud_ adjusing
17:08 pmichaud_ adjusting
17:08 particle yeah
17:09 NotFound joined #parrot
17:09 pmichaud_ pushed.
17:12 * particle makes
17:12 pmichaud_ I'm guessing it might end up with difficulty handling the double-backslash in  src\pmc\\*.obj
17:12 pmichaud_ but we shall see.
17:14 nopaste "particle" at 76.121.106.245 pasted "rakudo build error" (576 lines) at http://nopaste.snit.ch/16864
17:14 particle another linker error
17:14 particle let's deal in an hour or so, i need to get set up with a $client
17:15 pmichaud_ sure, I have to go also.  Thanks!
17:20 kj joined #parrot
17:21 dalek joined #parrot
17:22 Coke joined #parrot
17:22 Whiteknight hello kj
17:23 pmichaud joined #parrot
17:25 polyglotbot joined #parrot
17:31 kj hi w
17:32 kj Whiteknight:
17:32 kj geez
17:32 kj i forgot how this works :-) Hi Whiteknight!
17:32 Whiteknight hello kj, how's things?
17:32 kj not too bad, thanks. Kinda busy, but working from home these days, so can connect to irc again
17:32 Whiteknight oh, that's nice
17:32 kj yourself?
17:33 Whiteknight busy too. Always busy
17:33 Whiteknight managing the release on Tuesday, so preparing for that
17:33 kj i saw the email and announcement, yes
17:34 Whiteknight what's the state of PIRC right now?
17:34 kj the same as I left it in February I think
17:34 kj I saw there were a few commits from some other people
17:34 kj but those were cleanups I think
17:34 kj the state, to be more precise is this:
17:35 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 *
17:35 kj yes i saw it's pushed back
17:36 kj now, I would hope that fixing the char * -> STRING * stuff solves the bytecode generator
17:36 kj but I'm afraid it's not that easy
17:36 Whiteknight is this something we could parallelize, like if other developers were interested in helping?
17:37 kj so the 2 major things to fix are the byte code generator and the char * to STRING conversion
17:37 kj i think the second, the STRING stuff should be done first
17:37 Whiteknight okay, that's really not so bad then
17:37 Whiteknight ("not so bad" if those are easy issues to resolve)
17:38 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 kj i'm not sure exactly what's the problem, but I have no debugging skills
17:38 kj except for printf()
17:38 Whiteknight okay.
17:38 kj that is, i have no gdb skillz
17:39 chromatic joined #parrot
17:39 kj and unfortunately, my work needs full attention at this point as I'm kinda under pressure.
17:40 kj 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!
17:41 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:57 Whiteknight yeah, I know what you mean
17:57 Whiteknight maybe we can get a few fresh eyes to take a look at it for you
17:59 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 kj perhaps it's a memory problem that I've overlooked.
17:59 Whiteknight bacek was doing some stuff with packfiles, maybe he can lend a hand
17:59 kj if you use some command line option to just print the output to screen, everything is fine
18:00 kj it goes horribly wrong when dealing with FLOATs and STRINGs
18:00 kj (there's tickets open for that, btw)
18:00 Whiteknight STRING and FLOAT constants?
18:00 kj yes
18:00 kj as they are "special"
18:00 kj integer constants are just stored in the byte stream
18:00 kj *byte code stream
18:01 kj 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 decnum-dynpmcs: r85 | darbelo++ | trunk/ (2 files):
18:01 dalek decnum-dynpmcs: Add freeze/thaw functionallity to DecNumContext. Tests included.
18:01 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=85
18:01 kj whereas add_n_nc_nc has 3 operands, but the last 2 are indexes into the const table
18:02 kj I believe just using 1 such op is fine, but 2 consequetive blows up
18:02 Whiteknight hmmm, that's weird
18:03 kj yeah, and it also depends whehter you run on windows or linux i think
18:03 kj i can't remember details
18:03 kj ( i switched to macos few months back, so not doing any windows anymore, although I do have access if necessary)
18:04 kj windows is quite forgiving in segfaulting, whereas linux is very clear when things go wrong
18:04 kj (forgiving, or maybe just keeping silent)
18:07 pmichaud particle: I'm back, whenever you're ready to troubleshoot the win build again
18:10 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:11 chromatic Once we have the former in place, we can use pmcc to replace our current parsing tools.
18:11 chromatic Then we can work on making L1 work sufficiently to replace the C generation step.
18:16 burmas joined #parrot
18:18 cotto chromatic, that's what I thought.  I'm glad to have you confirm it.
18:21 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 chromatic I don't know any successful, used, and *interesting* software projects where that's not true.
18:28 Whiteknight is "L1" short for anything?
18:28 cotto L1?
18:28 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 http://irclog.perlgeek.de/p​arrot/2009-04-21#i_1083550 or http://rt.perl.org/rt3/Ticket/D​isplay.html?id=39313#txn-471982
18:28 cotto I think just level-1 language
18:29 cotto LOL would also be an appropriate name
18:29 Whiteknight cotto: what's the status of the pmc_pct branch?
18:30 burmas left #parrot
18:31 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 cotto pmc2c is a bit hairy in places.
18:31 Whiteknight you have an ETA on that? Do you suspect it will be ready by this weekend, or after the release?
18:31 cotto It *might* be usable by 1.4, but definitely not by 1.3.
18:32 Whiteknight okay, thanks
18:32 payload joined #parrot
18:35 Whiteknight do we have any idea yet how we are going to implement L1?
18:35 Whiteknight is it going to look like PIR, or something different?
18:35 cotto bacek suggested that we use pir as a starting point, but I haven't given it much thought.
18:36 cotto istr that chromatic was giving it some thought.
18:37 darbelo cotto: I thought L1 was a different thing from the "PMC Imementation Language" pmcc will parse.
18:38 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:39 Whiteknight maybe it's better to have both tools and a whitelist
18:40 dalek joined #parrot
18:40 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.
18:40 pmichaud me also.
18:41 pmichaud 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
18:41 Whiteknight PMCs and OPS, I hope.
18:41 Whiteknight makes everything easier to JIT in the future
18:42 pmichaud Parrot string magicians:  TT #752   :-)
18:46 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:48 pmichaud It's a codepoint.
18:48 pmichaud At any rate, the first $S0 string is correct.
18:48 pmichaud It's the $S3 string that is incorrect.
18:52 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 chromatic I can't imagine wanting to write anything more complex than an opcode in it.
18:54 pmichaud Would PMCs be written in Ll or in opcodes?
18:54 pmichaud sorry, L1
18:55 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.
18:56 pmichaud presumably "whatever language we want" would be "not C" though.
18:56 chromatic That's right.
18:56 chromatic C's semantics are too dangerous and corner casey.
18:57 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.  :-)
18:58 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 :-)
18:58 darbelo pmichaud: s/ETOOMANYLANGUAGES/MOAR lANGUAGES, PLZ./ then ;)
19:00 NotFound I CAN HAZ LANGUAGES?
19:01 darbelo chromatic: I don't really count the C+Boilerplate used for PMCs as another language.
19:02 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:03 chromatic 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:04 NotFound In fact I dont think I know the PMC language, even after fixing problems in a lot of them
19:07 Coke would help if it were ever spec'd. :P
19:07 Coke a lot of the internals just accreted.
19:07 Coke chromatic: any luck with the contextualizing?
19:07 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?"
19:07 * Coke orders a 1TB hardrive for half of what he paid for his last drive.
19:08 Coke (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.
19:08 chromatic Okay, two more ideas for debugging, but one of them is a nasty hack.
19:11 Coke would a small PIR example still help?
19:12 chromatic I can recreate the Sub context leaks just fine; coroutines and returncontinuations seem like the culprits.
19:13 chromatic I've used some of the PMC tests, which is fine.
19:13 Coke ok.
19:13 Coke have you found if the coroutine is invoking the sub's destroy?
19:13 Coke (and if so, is that get_attr macro doing TRT?
19:14 chromatic Yes and yes.
19:15 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.
19:16 chromatic If sub is NULL there, it can't access sub's context because sub doesn't have a context.
19:16 chromatic NULL sub is NULL.
19:16 Coke right, but the context is in the sub; what is mem_sys_free(PMC_data(SELF)); doing?
19:17 chromatic If there's no sub, there's no context to free.
19:18 chromatic Oh, I see what you mean.
19:19 Coke that should just be attrs, which should just be sub. Not sure if that's a lock, though.
19:19 chromatic Testing now.
19:19 Coke (nor how a child of a sub would deal with that.)
19:19 Coke (tclproc isa pir .Sub, and also has its own attributes)
19:19 chromatic I don't know if that would ever have been a problem, but it's clearly a potential leak written that way.
19:21 chromatic 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 donaldh joined #parrot
19:22 Coke nope.
19:22 Coke here's a crazy thought; why not remove the "please don't crash" warning, and see what happens?
19:22 chromatic Crash.
19:22 chromatic Specifically double-free warnings when freeing the context recycling pool during global destruction.
19:23 Coke is that just papering over the fact that our refcounting is wrong?
19:23 Coke that is, if our refcounting was right, we could remove it and not crash?
19:24 chromatic Yes.
19:24 chromatic The problem is figuring out where our refcounting is wrong.
19:24 Coke if we remove the check and crash, can we use that to backtrack?
19:24 Coke and/or if we fix our refcounting, will the leak magically go away?
19:25 chromatic First answer, not easily.
19:25 chromatic Second answer, yes.
19:25 chromatic FSVO "magically" which means "This is difficult in the same way that space is big."
19:26 japhb LOL
19:26 Coke "you thought it was a long way down to the chemists!"
19:26 japhb "They call it 'space' ... because there's so much of it."
19:26 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.
19:27 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.
19:27 chromatic You need to add the --leak-test flag to all Parrot invocations.
19:28 dalek parrot: r39511 | chromatic++ | trunk/src/pmc/sub.pmc:
19:28 dalek parrot: [PMC] Plugged a potential memory leak Coke++ found in the Sub PMC; if a Sub had
19:28 dalek parrot: no sub attribute, destroy() would never free the allocated attribute storage.
19:28 dalek parrot: This *should* never happen, but now it will never happen.
19:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39511/
19:29 Coke chromatic: would something like a GET_CONTEXT macro that you could override help?
19:30 chromatic Yeah, but you'd have to annotate every access to contexts throughout the system.
19:31 chromatic You'd also have to write it in such a way that it performs a PARROT_ASSERT.
19:31 chromatic ... and, more importantly, you'd have to apply it only to accesses to contexts which can legitimately be undefined.
19:31 chromatic There are certain cases, I believe, where the from context or calling context don't need reference counts.
19:31 chromatic At least that's how the code reads now.
19:32 Coke chromatic: so, if I do grunt work, someone can fix my bug?
19:32 chromatic Possibly.
19:32 chromatic Let my try my other two ideas and warn you again that this is an excessive amount of grunt work.
19:32 Whiteknight keep in mind, in the not-so-distant future contexts will be garbage collectable
19:32 Coke Whiteknight: so I keep hearing. =-)
19:32 Whiteknight anythingthat requires codebase-wide annotations at this point is a bad idea
19:33 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.
19:33 Coke which has been in progess for some time; I have no idea what's left on that, either.
19:33 Coke I should try to build that branch.
19:33 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
19:34 Whiteknight 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:35 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.
19:37 chromatic Now imagine having to dig through all of this code to figure this out!
19:38 Coke so it sounds like if I want to expend energy to help out, I can't do anything useful atm. =-)
19:38 Coke pcc_rewiring is allison's branch, neh?
19:38 Coke (the build gets pretty far, dies with miniparrot.)
19:39 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:40 DanielC joined #parrot
19:40 chromatic That branch has long blocked on one person's availability and interest.
19:41 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 DanielC ?
19:42 chromatic Any future branch we expect to last longer than a week really ought to have some plan sketched out in the wiki.
19:44 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:45 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/
19:46 cotto (and the L1 will be transformed into either C or LLVM bytecode)
19:48 chromatic NotFound, Simon Cozens's string branch?  I think he was prototyping it in Perl 6 first.
19:48 chromatic cotto, skip the second step.
19:48 chromatic First pmcc translates them as written into C.
19:48 chromatic Then we port them to a new language which pmcc can translate into C.
19:48 chromatic Then we get L1 working.
19:48 chromatic Then pmcc translates them to L1.
19:48 NotFound chromatic: I remember some talk about that, but long, long time ago in a galaxy far away.
19:49 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]
19:49 cotto so the code will go from new language -> L1 -> C?
19:50 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.
19:52 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 #parrot
20:07 kj left #parrot
20:11 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:13 * Coke wonders where feather just went to.
20:14 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:15 Whiteknight I assumed we would be writing in L1, and translating that into C and others
20:16 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
20:16 chromatic L1 is just ops that Parrot can execute.
20:16 chromatic What's the problem?
20:16 purl i heard the problem was getting an installed parrot to recognize dynops/dynpmcs
20:17 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?
20:18 Whiteknight 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?
20:18 chromatic That's step one, until we can target L1.
20:18 Whiteknight target L1 from L1?
20:18 chromatic The point of L1 is so that we can stop writing *and executing* C code.
20:18 Coke I think L1 is probably a less helpful name than "FOO"
20:19 Whiteknight chromatic: we have to execute something
20:19 chromatic Yes, that's L1.
20:19 NotFound Or someone
20:19 chromatic L1 is a series of simple, low-level ops that can do everything we need to do from C now.
20:19 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?
20:20 chromatic Who says it doesn't have the performance of C?
20:20 chromatic C *is* our performance problem right now.
20:21 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!
20:21 purl You have no chance to survive make your time.
20:21 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
20:22 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 chromatic This is not a recipe for insane speed.
20:22 cotto Isn'
20:23 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?
20:23 chromatic Yes.
20:23 chromatic 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.
20:23 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 #parrot
20:24 Whiteknight wait, are you talking about using L1 as a sort of microcode?
20:25 chromatic Yes.
20:25 chromatic All nanoparrot does is execute L1 ops.
20:25 cotto So we want to eliminate C except under the hood so we're never switching between calling conventions.
20:25 japhb Actually, it sounds a lot like "primitives" in the Forth sense.
20:25 Whiteknight okay, I understand that much better then
20:25 chromatic I want to eliminate all C, but I'll start with PMCs and ops for now.
20:26 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
20:27 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 chromatic Every time we cross that C boundary we give up many, many optimization possibilities.
20:34 nopaste "chromatic" at 72.90.115.31 pasted "Let's try this for debugging context leaks" (25 lines) at http://nopaste.snit.ch/16867
20:35 Coke want me to try that against my tcl code?
20:36 * Coke rants that 'will@coleda.com', a hosted google account, is not usable as a google account.
20:38 chromatic It won't fix things.  It'll just expose crashes.
20:38 chromatic Those crashes are in Parrot though (and miniparrot demonstrates them), so it's probably fixable here.
20:39 Coke ok. let me know if you need me to do anything.
20:46 NotFound I have a special-case ugly fix for TT #752
20:46 NotFound How big is the urgence for that thing in rakudo?
20:47 viklund_ 752, that was the unicode thing right?
20:47 NotFound Yeah
20:47 pmichaud_ joined #parrot
20:48 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.
20:48 pmichaud_ the #752 bug is high priority but not critical
20:49 pmichaud_ Rakudo can continue to make progress without it being fixed (more)
20:49 pmichaud_ some people writing applications using Rakudo are blocked (or have to do very nasty workarounds) until it's fixed
20:49 NotFound I'll clean, comment and commit the fix, then. At least it will clearly expose the weak point.
20:49 pmichaud_ can I see the diff?
20:49 pmichaud_ I might be able to suggest a way to clean it up
20:49 NotFound pmichaud_: give some minutes...
20:50 viklund_ pfft, nasty workaround
20:50 * viklund_ walks away, muttering
20:50 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 #parrot
20:56 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.
20:56 pmichaud_ We need to support multiple charsets -- including iso-8859-1
20:57 pmichaud_ 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 #parrot
20:57 pmichaud_ I'm fine with switching iso-8859-1 to unicode as long as internally it's still a fixed width encoding.
20:58 pmichaud_ if it's a variable length encoding, then we're making things worse.
20:58 dalek pynie: r71 | isop44++ | trunk/ (2 files):
20:58 dalek pynie: Patch by ++amk - Launchpad bug #385394
20:58 dalek pynie: Patch to remove builtins dropped from 3.x
20:58 dalek pynie: Python 3.0 dropped a number of built-in functions. Using the list from
20:58 dalek pynie: Python 3.1's code, this patch removes the built-ins that no longer need
20:58 NotFound pmichaud_: well, if we create an encoding for it, there is no point to make it variable width
20:58 dalek pynie: to be supported.
20:58 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=71
20:59 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
20:59 pmichaud_ it just hasn't been implemented yet
20:59 NotFound pmichaud_: a minor detail X-)
21:00 pmichaud_ that's where our effort should probably go, rather than trying to patch up what we have today
21:00 polyglotbot joined #parrot
21:00 pmichaud_ (by "patch up" I primarily mean "try other proof of concept approaches")
21:01 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:02 pmichaud joined #parrot
21:02 Coke joined #parrot
21:02 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 pmichaud_ however, it is the case that Parrot's string model needs to support Perl 6's requirements
21:03 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.
21:03 NotFound 'charset' in parrot code meaning
21:04 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 http://nopaste.snit.ch/16869
21:05 NotFound pmichaud_: no, but is a good reason for considering alternative ways.
21:06 pmichaud_ that patch looks wrongish to me
21:07 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
21:07 pmichaud_ that's "worse" by some measure
21:08 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.
21:09 NotFound The same happens every time I look at strings code, BTW
21:09 pmichaud_ api.c:432 looks wrong to me.
21:10 NotFound pmichaud_: I try to change that some time ago, don't remember why, and broke lots of things.
21:11 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.
21:11 pmichaud_ well, :432 doesn't look like too much of a special case to me
21:11 pmichaud_ it makes sense except for that one line
21:12 NotFound I see now... It can wrongly convert iso 8859-1 to ascii, right?
21:12 pmichaud_ right.
21:13 pmichaud_ 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.
21:16 NotFound But that code must have no effect in TT #753, the utf8 strings haven't pure ascii content.
21:16 pmichaud_ Agreed
21:16 NotFound I mean 752
21:17 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
21:18 pmichaud_ right
21:18 pmichaud_ that's what should be happening
21:18 pmichaud_ and it should be returning utf8 encoding and unicode charset (from b)
21:18 pmichaud_ line 444
21:19 pmichaud_ 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 pmichaud_ so the bug is in Parrot_str_append
21:19 pmichaud_ in Parrot_str_append, "a" is our result string, and "b" is the string being appended
21:20 NotFound Before the patch there are 2 str_append calls
21:21 pmichaud_ right
21:21 pmichaud_ the first call is appending the iso-8859-1 string to the (empty) utf8 result
21:21 NotFound And it does not do a good work, yes.
21:22 pmichaud_ on line 546, what is that doing?
21:22 NotFound 546 befor patch?
21:22 pmichaud_ yes
21:23 pmichaud_ /* Is A real? */
21:23 pmichaud_ maybe I should sic gdb on this
21:23 NotFound If is NULL, just copy b
21:23 pmichaud_ is our result string NULL in this case?
21:24 pmichaud_ i.e., having just been created by Parrot_str_new_init ?
21:25 NotFound I think not, checks for string null or no buffer
21:25 pmichaud_ I'm walking through this with gdb... just a sec
21:26 NotFound And Parrot_str_nee_init in this case tries to create a buffer with the final result bytelength
21:26 NotFound I doesn't, but it tries ;)
21:26 pmichaud_ correct, we get to "saneify_string" in this case
21:27 pmichaud_ that appears to simply be a set of PARROT_ASSERT macros
21:27 payload joined #parrot
21:28 pmichaud_ aha!
21:28 pmichaud_ It is the ascii problem!
21:28 pmichaud_ line 432 is the problem.
21:29 pmichaud_ or at least is part of being wrong
21:29 pmichaud_ Parrot_str_append calls string_rep_compatible
21:29 pmichaud_ and when it does, the first parameter is the result string (utf8) and the second parameter is iso-8859-1
21:29 NotFound I'm convinced that that line is wrong, but I don't think is the only problem.
21:30 pmichaud_ but string_rep_compatible mistakenly returns Parrot_ascii_charset_ptr
21:30 pmichaud_ instead of Parrot_iso_8859_1_charset_ptr
21:31 dalek decnum-dynpmcs: r86 | darbelo++ | trunk/ (2 files):
21:31 dalek decnum-dynpmcs: Add freeze/thaw VTABLES to DecNum and test them in t/freeze_thaw.t.
21:31 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=86
21:31 pmichaud_ however, you're correct -- there's another problem here.
21:31 NotFound Commenting that if has no effect in the problem.
21:31 pmichaud_ because regardless of what it  comes back with, it instantly changes the charset of the result string
21:31 pmichaud_ which it should not do
21:31 pmichaud_ the result string needs to be utf8
21:32 pmichaud_ 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,
21:33 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
21:33 bacek good morning
21:33 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
21:33 NotFound And even if it doed what it expects, the result will not be utf8
21:33 cotto hi, bacek
21:33 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 #parrot
21:33 bacek hi cotto
21:33 NotFound Agreed
21:34 pmichaud_ now, let's see what happens with the second append
21:34 pmichaud_ the second time we're appending the utf8 string to the result (which is now mis-encoded as ascii/fixed8)
21:35 cotto chromatic confirmed that we're not in the business of writing a C compiler: http://irclog.perlgeek.de/p​arrot/2009-06-11#i_1231696
21:35 NotFound pmichaud_: no difference, it does a memcpy anyway
21:35 pmichaud_ it's slightly different
21:35 pmichaud_ here's the bug
21:35 pmichaud_ we call string_rep_compatible
21:36 cotto afk: shopping
21:36 purl somebody said shopping was a drag. or a great time, if it's *barber* shopping! </kitch>
21:36 pmichaud_ and it's returning unicode charset (same as b)
21:37 pmichaud_ but the next line is then assigning that encoding to a
21:37 pmichaud_ that's wrong.
21:37 purl pmichaud_ is channeling thoth!
21:37 pmichaud_ these are lines 558 and 559
21:37 NotFound pmichaud_: it does the same for iso-8859-1, no trascoding at all.
21:37 pmichaud_ right
21:37 pmichaud_ it's still wrong.
21:38 pmichaud_ it's wrong for string_rep_compatible to say that  utf8 and iso-8859-1 are compatible encodings
21:38 pmichaud_ ascii, yes.  iso-8859-1, no.
21:39 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.
21:39 pmichaud_ I disagree
21:39 pmichaud_ It's not Parrot_str_append that is wrong, it's string_rep_compatible
21:40 pmichaud_ lines 429 and 439 are wrong.
21:40 NotFound I see it a different way: string_rep_compatible does a different thing.
21:40 NotFound Is wrong, also, but that is another problem.
21:40 pmichaud_ string_rep_compatible is supposed to find the lowest possible compatible charset and encoding
21:40 pmichaud_ it's not true that the lowest possible charset and encoding for  utf8 versus iso-8859-1 is iso-8859-1
21:41 NotFound But 'compatible' in that case does not mean 'able to memcpy'
21:41 pmichaud_ I think that's exactly what it means.
21:41 NotFound Then iso-8859-1 and unicode utf8 aren't compatible
21:41 pmichaud_ correct.
21:42 NotFound So, all is wrong
21:42 NotFound That was my second comment.
21:42 pmichaud_ I don't know if "all is wrong", but that part certainly is.
21:42 NotFound <NotFound> I'm tempted to say the same about the entire strings/api.c file
21:43 pmichaud_ I wonder if the iso-8859-1 part was added as a workaround to something else.
21:43 GeJ Good morning everyone
21:44 pmichaud_ aha, it was.  That was the workaround for RT #39930
21:44 pmichaud_ that workaround is incorrect.
21:44 NotFound pmichaud_: if we don't take them as compatible, the logic is to convert to utf16, which is not was TT #572 expects.
21:44 pmichaud_ oh
21:44 pmichaud_ then #752 is wrong
21:44 pmichaud_ in truth, I don't care if the result comes back utf8
21:45 pmichaud_ I just care that the result that comes back is correct
21:45 pmichaud_ in this case, it isn't.
21:45 NotFound And probably lots of rakudo, also.
21:45 pmichaud_ no, rakudo doesn't care.
21:45 pmichaud_ utf16 is a fine result for #752
21:45 pmichaud_ "invalid utf-8 string" is not.
21:45 NotFound I don't care what the resut must be, as long as is clearly documented somewhere, which isn''t
21:46 pmichaud_ I'll update the #752 ticket
21:47 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:48 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 %-)
21:48 pmichaud_ No.
21:48 pmichaud_ we don't
21:48 chromatic Isn't UTF-8 variable width?
21:48 pmichaud_ instead of upgrading to utf16, we upgrade to utf8
21:49 pmichaud_ yes, utf8 is variable width.
21:49 pmichaud_ ticket updated.
21:50 NotFound pmichaud_: well, I can try that way and see if it doesn't broke things.
21:50 NotFound Not today.
21:50 pmichaud_ first we have to get rid of the error in str_rep_compatible -- that is what is leading to other incorrect workarounds
21:50 NotFound Too late in CET
21:50 pmichaud_ I might work on it a bit, now that I see where the problem is.
21:55 eternaleye joined #parrot
21:59 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 Whiteknight at least, I'm pretty convinced that would fix it
22:01 chromatic Now try to detect when an exception handler has ended and you need to rejoin the invoking runloop.
22:02 NotFound Whiteknight: that way you can't call sub or methods from C the way is being done now.
22:03 NotFound Maybe that will not be a bad thing.
22:03 chromatic That does hurt an embedding interface.
22:05 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:06 NotFound 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?
22:07 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
22:07 chromatic We have to make the L1 dispatcher responsible for all control flow.
22:08 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
22:08 chromatic We don't rely on C code to throw exceptions.
22:09 Whiteknight NotFound: we could use simple register renaming to overwrite the return addresses
22:09 NotFound Whiteknight: returning to the C caller, I mean.
22:09 Whiteknight chromatic: you're right about that. I can understand that
22:09 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.
22:10 chromatic For *all* exceptions thrown throughout the system.
22:10 chromatic *Even* exceptions thrown from PIR code directly.
22:10 Whiteknight NotFound: that's just a small matter of storing a jump point to the caller
22:11 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
22:12 Whiteknight chromatic: so walk me through how this would be implemented
22:12 chromatic Sure.
22:12 Whiteknight L1 code runs merrily along, throws an exception...
22:12 chromatic The L1 dispatcher sets aside the current continuation and its call graph.
22:12 Whiteknight so on a call stack of some sort?
22:12 Whiteknight or a storage stack?
22:12 chromatic A continuation; it's all CPS.
22:13 Whiteknight right, but where do you store that continuation, a stack?
22:13 Whiteknight so you can return to it
22:13 chromatic You pass it to the exception handler.
22:13 Whiteknight okay, so implicitly push it on the system stack. Gotcha
22:13 dalek joined #parrot
22:13 chromatic No, don't say "push" and don't say "stack".
22:13 chromatic Please don't say "system stack".
22:13 chromatic "System Shock" is okay.
22:14 * Whiteknight resists the urge
22:14 Whiteknight please continue
22:14 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.
22:14 chromatic It's invoking a continuation of some kind, passing the return continuation.
22:15 Whiteknight ok
22:15 NotFound Except that we can have C handlers
22:15 chromatic The only reason I can think of to have C handlers in this scheme is for an embedding interface.
22:16 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.
22:16 Whiteknight ...if I'm thinking about his idea correctly now
22:16 polyglotbot joined #parrot
22:17 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
22:17 Whiteknight ...or that
22:17 Coke joined #parrot
22:17 NotFound Whiteknight: solved if you ignore the inner runloops thing
22:18 Whiteknight I think I see what chromatic is saying now
22:18 chromatic What I'm saying is "We don't need C".
22:18 chromatic As limit -> infinity anyhow.
22:19 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
22:19 Whiteknight like, this is a huge project, and a lot of points-of-no-return where we can't make gradual changes
22:19 chromatic Sure, but look at the pmcc suggestions.
22:20 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.
22:20 chromatic The same goes for a hypothetical ops compiler.
22:21 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.
22:21 chromatic 1) PIR doesn't give the kind of low-level access to memory and calling C functions that we need.
22:21 chromatic 2) Bootstrapping is a pain.
22:22 pmichaud joined #parrot
22:22 chromatic 2.5) More people know C than L1/Cequiv.
22:28 Whiteknight How are we going to get calling access to C functions from L1?
22:29 Whiteknight its not like that need disappears when we switch languages
22:29 bacek joined #parrot
22:29 chromatic Sure, we need to support that to make NCI work too.
22:30 chromatic We probably (and hopefully the short-lived kind of temporarily) need to do that to migrate some PMCs to PMCLang.
22:32 rg1 joined #parrot
22:32 Whiteknight So what's PMCLang going to be? L1, a variant thereof, or another translate-to-pure-C script?
22:33 chromatic L1 is a set of opcodes.
22:33 chromatic It's not a language.
22:34 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.
22:34 chromatic It's not syntax.  It's just a set of opcodes.
22:34 chromatic It's a subset of PIR in the same sense that src/ops/var.ops is a subset of PIR.
22:36 Whiteknight so other ops get translated into L1 through some kind of direct translation, like a lookup table?
22:37 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
22:38 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
22:39 chromatic pmichaud_ has it right.
22:45 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:46 Whiteknight A build step could convert PMC definitions down to arrays of pre-compiled L1 bytecode
22:46 chromatic Yep.
22:46 Whiteknight so no runtime compilation there
22:46 chromatic Nope.
22:47 chromatic 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 chromatic Every time.
22:47 purl rumour has it every time is peak time somewhere
22:47 Whiteknight And without that, I don't think we need anything even resembling a compiler for L1
22:47 sekimura joined #parrot
22:48 kid51 joined #parrot
22:48 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:49 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
22:49 chromatic What's the benefit to that?
22:50 Whiteknight a single translation step, every opcode gets directly translated to a stream of L1 code
22:50 Whiteknight L1 ops are always written in C, PIR ops are always written in l1
22:50 chromatic How does that make L1 its own langauge?
22:50 chromatic *language
22:51 Whiteknight how doesn't it? not defined the same, not executed the same
22:52 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?
22:52 chromatic I suppose you could say that a compiler can turn a textual representation of L1 into L1 ops for nanoparrot to execute.
22:53 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.
22:54 chromatic 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"
22:55 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
22:55 chromatic We need an L1 emitter for PCT.
22:55 Whiteknight then at runtime, we just string together the appropriate arrays into the order specified by the PIR program
22:56 Whiteknight it's like a small Parrot-level JIT
22:56 burmas joined #parrot
22:56 Whiteknight well, conceptually similar
22:56 chromatic But the PIR program becomes a stream of L1 ops.
22:56 Whiteknight right
22:57 chromatic Alright, as long as we're both clear on that.
22:58 Whiteknight I'm thinking PIR->PBC because PBC is going to be more compact, and then PBC->L1BC
22:58 Whiteknight at least, packfiles should be PBC for brevity
22:59 Whiteknight PBC opcode_t could just be indexes into an array of frozen L1BC sequences
23:00 burmas joined #parrot
23:00 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 chromatic 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.
23:01 chromatic 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:02 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 burmas left #parrot
23:02 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.
23:03 Whiteknight me likey
23:03 chromatic Or (and you'll like this one), you can have pluggable, overrideable op libraries.
23:03 chromatic Suppose you want to annotate the memory management ops with profiling information.
23:03 chromatic Load an op overlay which adds a couple of instructions, recompile, and go.
23:03 chromatic Adds a couple of instructions to the memory management ops you defined, I mean.
23:04 Whiteknight right
23:05 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:07 chromatic 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:08 snarkyboojum joined #parrot
23:08 gryphon joined #parrot
23:19 * kid51 interrupts to ask:  chromatic/Whiteknight:  Any thoughts on https://trac.parrot.org/parrot/ticket/281 ?
23:20 kid51 (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 http://nopaste.snit.ch/16872
23:20 chromatic TODO them as specifically as possible.
23:21 donaldh joined #parrot
23:26 chromatic kid51, I just don't want to close tickets before we've solved the problems.
23:27 kid51 Agreed.  Let
23:27 kid51 's see if I can figure it out.
23:32 patspam joined #parrot
23:44 dalek parrot: r39512 | jkeenan++ | trunk/t/op/debuginfo.t:
23:44 dalek parrot: Change handling of 3 tests from SKIP to TODO.  Cf.:  https://trac.parrot.org/pa​rrot/ticket/281?#comment21.
23:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39512/
23:44 purl dalek: that doesn't look right
23:44 kid51 Can you give perl t/harness t/op/debuginfo.t a whirl with the -f, -g, -j and -S options?
23:45 chromatic In a few, yes.
23:58 silug joined #parrot

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

Parrot | source cross referenced