Camelia, the Perl 6 bug

IRC log for #parrot, 2010-12-20

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 cotto dukeleto, can you invalidate http://socghop.appspot.com/gci/tas​k/suggest_task/google/gci2010/parr​ot_perl_foundations/t129270216789 ?  kid51 took care of it before a student could get to it.
00:01 whiteknight left #parrot
00:19 nopaste left #parrot
00:20 TonyC left #parrot
00:27 TonyC joined #parrot
00:27 nopaste joined #parrot
00:35 kennym left #parrot
00:42 dalek parrot: 0b20a82 | plobsing++ | DEPRECATED.pod:
00:42 dalek parrot: deprecations for planned :init and :load flag related changes
00:42 dalek parrot: review: https://github.com/parrot/parrot/commit/0b20a82b55
00:46 dalek parrot: 3749000 | NotFound++ | t/pmc/namespace.t:
00:46 dalek parrot: test Namespace get_pmc_keyed RSA key with a null element
00:46 dalek parrot: review: https://github.com/parrot/parrot/commit/3749000c7d
00:46 Kristaba left #parrot
00:47 dalek parrot: c51b642 | plobsing++ | DEPRECATED.pod:
00:47 dalek parrot: remove deprecation notice for PIR assignment syntax
00:47 dalek parrot:
00:47 dalek parrot: we're not going to fix this mistake. see TT #906 for why.
00:47 dalek parrot: review: https://github.com/parrot/parrot/commit/c51b64278c
00:54 dalek TT #1895 created by plobsing++: [DEPRECATED] difference between :load and :init Sub flags
00:54 dalek TT #1895: http://trac.parrot.org/parrot/ticket/1895
00:54 dalek TT #1896 created by plobsing++: [DEPRECATED] :init Sub flag
00:54 dalek TT #1896: http://trac.parrot.org/parrot/ticket/1896
01:10 dalek TT #1897 created by jkeenan++: Implement 'silent' configuration
01:10 dalek TT #1897: http://trac.parrot.org/parrot/ticket/1897
01:13 nwellnhof left #parrot
01:50 kid51 is now known as kid51_at_dinner
01:59 dalek tracwiki: v2 | plobsing++ | PackfileTasklist
01:59 dalek tracwiki: add note about :load/:init deprecations
01:59 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pack​fileTasklist?version=2&action=diff
02:22 dalek parrot/errors_globals_flag_deprecation: d9e5a88 | plobsing++ | / (7 files):
02:22 dalek parrot/errors_globals_flag_deprecation: remove deprecated PARROT_ERRORS_GLOBALS_FLAG constant
02:22 dalek parrot/errors_globals_flag_deprecation: review: https://github.com/parrot/parrot/commit/d9e5a88da4
02:22 dalek parrot/errors_globals_flag_deprecation: 9c05317 | plobsing++ | DEPRECATED.pod:
02:22 dalek parrot/errors_globals_flag_deprecation: remove deprecation notice for PARROT_ERRORS_GLOBALS_FLAG
02:22 dalek parrot/errors_globals_flag_deprecation: review: https://github.com/parrot/parrot/commit/9c05317533
02:32 dalek tracwiki: v9 | plobsing++ | ParrotDeprecationsFor3.0
02:32 dalek tracwiki: add PARROT_ERRORS_GLOBALS_FLAG deprecation info
02:32 dalek tracwiki: http://trac.parrot.org/parrot/wiki/ParrotDe​precationsFor3.0?version=9&action=diff
02:32 dalek tracwiki: v25 | plobsing++ | ParrotDeprecations
02:32 dalek tracwiki: add note about PARROT_ERRORS_GLOBALS_FLAG deprecation
02:32 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Parro​tDeprecations?version=25&action=diff
02:38 GeJ anyone else having troubles with github?
02:38 bluescreen left #parrot
02:39 plobsing GeJ: seems fine to me. what problems are you having?
02:42 GeJ lots of errors 502 when pulling from different repos.
02:43 GeJ Dancer, dist-zilla, diaspora are concrete examples.
02:43 GeJ those are read-only pulls.
02:44 GeJ parrot pulls fine (as a read-write repo).
02:44 plobsing ohm-eta-wink-kzd pulls are fine for me (r/w)
02:45 GeJ rakudo (read-only) pulls fine. hmmm.
02:46 GeJ `git clone https://github.com/rcaputo/bot-pastebot.git Bot-Pastebot`  returns "error: RPC failed; result=22, HTTP code = 502"
02:46 GeJ so I'm not completely crazy. Anyway, I'll wait and retry some time later. Sorry for the noise.
02:48 bluescreen joined #parrot
02:55 kid51_at_dinner is now known as kid51
03:20 dalek ohm-eta-wink-kzd: a8743c4 | plobsing++ | src/ometa-base.winxed:
03:20 dalek ohm-eta-wink-kzd: lookup rules in super calls correctly
03:20 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/a8743c4b06
03:20 dalek ohm-eta-wink-kzd: a4ebaf2 | plobsing++ | src/winxed-compiler.dual:
03:20 dalek ohm-eta-wink-kzd: winxed does not do semicolon insertion
03:20 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/a4ebaf299a
03:52 kid51 left #parrot
04:05 Zaur joined #parrot
04:23 Yuki`N left #parrot
04:28 contingencyplan left #parrot
05:32 rurban_ joined #parrot
05:34 rurban left #parrot
05:34 rurban_ is now known as rurban
05:39 dd070 joined #parrot
05:40 dd070 hello !!
05:42 dd070 left #parrot
06:47 dd070 joined #parrot
06:50 dd070 left #parrot
07:48 bacek joined #parrot
08:25 contingencyplan joined #parrot
08:28 cotto hi bacek
08:42 TonyC left #parrot
08:42 nopaste left #parrot
08:42 TonyC joined #parrot
08:47 muixirt joined #parrot
08:48 muixirt good morning
08:51 nopaste joined #parrot
09:14 mikehh left #parrot
09:20 rfw left #parrot
09:26 fperrad joined #parrot
09:36 Coke left #parrot
09:42 Coke joined #parrot
09:49 Coke left #parrot
10:01 Coke joined #parrot
10:36 kennym joined #parrot
10:41 muixirt cotto ping
11:14 ambs joined #parrot
11:53 contingencyplan left #parrot
12:26 bluescreen left #parrot
12:28 muixirt left #parrot
12:31 GreenZED joined #parrot
12:34 Zaur left #parrot
12:37 bluescreen joined #parrot
12:41 Zaur joined #parrot
12:43 GreenZED left #parrot
12:49 PacoLinux joined #parrot
12:52 kennym left #parrot
13:09 Kovensky left #parrot
13:10 bluescreen good morning
13:20 Kovensky joined #parrot
13:30 whiteknight joined #parrot
13:32 rurban_ joined #parrot
13:32 whiteknight good morning, #parrot
13:34 rurban left #parrot
13:34 rurban_ is now known as rurban
13:35 Coke *cough*
13:36 muixirt joined #parrot
13:36 muixirt hi again
13:36 muixirt hi whiteknight
13:36 whiteknight hello muixirt
13:37 muixirt whiteknight: could you please tell me what you think are strong points of parrot?
13:42 whiteknight in what regard?
13:43 muixirt what parts of parrot would you consider worthy if someone asks you to develop a vm from scratch
13:44 muixirt design/architecture/concrete parts of the implementation
13:44 whiteknight oh, that's a good question.
13:45 whiteknight much of Parrot is going to change in the next year, so it's hard to pick something we have that we aren't planning to do better
13:45 muixirt or to put it another way: what have parrot devs learned in the course of the last 10 years
13:45 whiteknight that's sort of a different question. Like I said, Parrot right now is not as good as Parrot will be this time next year
13:45 whiteknight so I would save we have learned quite a lot
13:46 whiteknight many things that we've learned were learned from making and analyzing mistakes over the years
13:47 whiteknight Our calling conventions system is good. Flow control, CPS, etc. The fact that we are stackless and that we use registers are all good things and the implementations of those are good and going to get better
13:48 whiteknight Our system of pluggable runcores is good
13:49 dukeleto muixirt: i think the most valuable subsystem of Parrot is the community of people that hack on it
13:50 whiteknight dukeleto: :)
13:51 muixirt dukeleto: I'm not willing to dispute that :-) of course I thought more on technical issues
13:52 whiteknight muixirt: Some of the things we've learned are about what not to do: our old JIT for instance was a problem and we removed it
13:53 whiteknight avoiding tight coupling is something we've been doing recently to great effect
13:53 whiteknight keeping things pluggable is something we do extremely well
13:53 whiteknight pluggable runcores, pluggable dynops, pluggable pmc types
13:55 dukeleto muixirt: parrot has learned many lessons. I think, in general, how we handle pluggability is pretty awesome. Even our GC is pluggable
13:56 dukeleto muixirt: but as whiteknight said, we will fix many broken things in the next year, such as our Meta Object Protocol and Embedding API. Those will allow many other things to bloom
13:56 dukeleto muixirt: is this for a school report or something? Or are you just interested to know what we think?
13:57 muixirt just interested
13:58 whiteknight much of the development work we do now in Parrot is trying to add cool new things without breaking existing programs that use Parrot
13:58 whiteknight so that makes things go a little more slowly than we would like
13:59 whiteknight if we were starting from scratch we would be able to do the right things more quickly, because we wouldn't have any existing interfaces to maintain
14:00 muixirt what are your thoughts about the pmc/vtable subsystem
14:01 whiteknight muixirt: They were very good and functional prototypes for many years. They enabled us to do a lot of things so far
14:01 whiteknight But, they are being replaced soon
14:02 dukeleto muixirt: cool, just wondering
14:02 whiteknight the problem with VTABLEs is that they just aren't flexible enough for general use. We have 1 invoke vtable that all subs and sub-like things use, but we have like 50 bajillion arithmetic vtables that nobody uses
14:02 dukeleto whiteknight: perhaps we just didn't set up our VTABLES correctly?
14:03 dukeleto whiteknight: it seems like a bad design decision, not a problem with VTABLEs
14:03 ambs left #parrot
14:03 whiteknight dukeleto: The problem really is that we have a fixed set. Every VTABLE structure has all the interfaces that any type needs, which leads to a whole hell of a lot of useless slots
14:04 whiteknight There are only a handful of VTABLEs that are truely universal: get_class, get_name, find_method, init, mark, destroy
14:04 whiteknight maybe a handful of others for efficiency (init_int), but that's the core right there
14:05 dukeleto whiteknight: i really like how 6model does things. Everything has a REPR (representation) and a HOW (everything else)
14:05 whiteknight dukeleto: yes, and we're going to steal 6model wholesale
14:05 whiteknight knock jnthn and steal his lunch money too
14:05 dukeleto whiteknight: i am stealing many 6model ideas in my lorito branch
14:06 whiteknight dukeleto: good. the more the merrier
14:06 * dukeleto has been on vacation, so has been doing more thinking than coding
14:06 whiteknight dukeleto: when are you back from vacation?
14:06 mtk0 joined #parrot
14:08 whiteknight muixirt: The current system of vtables is decent, and helped us get to where we are without too much trouble. There are some bugs and inefficiencies that mostly stem from implementation problems, not design problems
14:09 whiteknight the new object model may even create some new inefficiencies while we work to transition Parrot over to the new Lorito architecture
14:10 muixirt how desirable is a hll language with is develop along with the vm?
14:10 whiteknight muixirt: In some cases, very valuable. you never really know how the VM performs until somebody uses it
14:11 whiteknight and you don't ever really know what users need until you have users
14:11 dukeleto muixirt: HLL languages should be independent of internal dev, but of course HLLs find bugs in Parrot core, which we fix, and then the HLL develops more. It is a feedback cycle.
14:12 muixirt whiteknight: to clarify: I thought of a hl for implementing compilers
14:12 tikluganguly joined #parrot
14:12 muixirt *hll
14:12 dukeleto whiteknight: my vacation ends around Dec 25th
14:12 dukeleto whiteknight: i will be traveling on the 23rd and will probably do some hacking then, tho
14:14 muixirt I think writing libraries and compilers in pir was a burden, hence the question
14:15 dukeleto whiteknight: if you signup to melange as an org admin, then you will be able to approve and publish tasks
14:15 dukeleto whiteknight: i think we can have as many org admins as we want. I think
14:15 bluescreen muixirt, you can write your (any) compiler using any language
14:15 dukeleto whiteknight: particle is the other org admin, because he has been in the past with GSOC, but obviously, you should also be an org admin
14:15 bluescreen NotFound wrote winxed stage 0 in C++
14:15 dukeleto whiteknight: since particle does not have the time
14:16 dukeleto whiteknight: if only 2 admins are allowed (i am not sure), then we should remove particle and put you as the second admin
14:16 particle time is a lion, where i am a lamb.
14:16 muixirt bluescreen: yes I know but using a compiler that runs on the vm has some advantages, or what do you think?
14:17 bluescreen writting the compiler in other languages doesn't means that it won't run in the VM.. you just have to make your compiler emit PIR or PBC
14:17 particle i think more than two are allowed.  i can approve whiteknight's request, too.  actually, i think org admins can invite others to be admins
14:17 muixirt what benefits have dynops (and dynpmcs) that outweigh their costs?
14:22 Coke IME, having a HLL developed in concert with parrot would have avoid a LOT of problems.
14:23 Coke would have exposed issues with the toolset, the API...
14:24 dukeleto particle: i feel like a William Blake quote is in order...
14:37 bluescreen left #parrot
14:37 bluescreen joined #parrot
14:50 tikluganguly left #parrot
14:53 * Coke wonders what is driving TT #1895
15:18 plobsing Coke: it falls out of changes whiteknight has proposed for packfiles (and I've also been wanting to do for a while)
15:18 * Coke wants a tool that will do a "git blame" but ignore whitespace diffs only and follow refactors.
15:19 Coke plobsing: ok. why doesn't the ticket say that and instead just say the feature is wrong when it's in use in several locations?
15:19 Coke s/and instead/instead of/
15:20 plobsing the feature *is* wrong. and it is blocking internal improvements
15:21 Coke How is it wrong?
15:22 plobsing makeing the distinction between whether load_bytecode loaded PIR or PBC is not something we should be doing
15:22 Coke ... that's not what the difference between those 2 things is.
15:23 plobsing oh. what is it then?
15:25 plobsing I know it has something to do with how a file is loaded.
15:26 Coke AIUI (and I'm rebuilding parrot at the moment to verify my recollection), one is for : ./parrot <foo>, and the other is for load_bytecode <foo>
15:26 plobsing that still seems like a silly distinction to be making
15:27 Coke "please run this block of code when the interpreter is initialized". "please run this block of code when we are loaded dynamically into memory" does not seem entirely silly to me.
15:28 plobsing other than the fact that you have no access (nor should you) to "when the interp is initialized"
15:29 Coke Or, "at program startup" if you prefer.
15:30 Coke $DAYJOB
15:30 plobsing what's wrong about prepending that to main?
15:31 whiteknight The difference is that :init should run after compilation, typically to define types and globals, or to insert an aggregate constant into the constants table.
15:32 whiteknight :load is executed when we load a bytecode
15:32 whiteknight so ./parrot foo.pir triggers an :init, while ./parrot foo.pbc triggers a :load
15:32 whiteknight the load_bytecode op always does :load, because it is supposed to be for bytecode
15:33 whiteknight the issue is that libparrot works on bytecode. PIR, it's language constructs, and it's compilation behaviors are external and are part of IMCC
15:33 plobsing this sounds like yet another problem caused by IMCC being special
15:33 whiteknight IMCC can keep :init or any other stupid flags it wants, but libparrot shouldn't be trying to account for those and enforce them
15:34 plobsing you expect IMCC to deal with :init blocks properly? have you seen what it does with :immediate blocks?
15:35 whiteknight I keep forgetting about :immediate
15:35 plobsing I wish I could do that
15:35 whiteknight plobsing: either way, that's a PIR syntax issue, and a behavior of the PIR compiler. It has nothing to do with libparrot
15:36 plobsing it has everything to do with libparrot and how it interacts with compilers, if your compiler interface proposal is where we're going
15:36 whiteknight parrot should have an operation for "load this bytecode" and during that operation it should trigger an ordered list of functions that need it
15:36 whiteknight this might include all :load and a :main function
15:36 whiteknight plobsing: If a compiler wants to execute blocks during compilation, that's a behavior of the compiler
15:37 whiteknight libparrot doesn't need to care that we are even in the middle of compilation
15:37 whiteknight and we certainly don't need our Sub type to have a flag field for :immediate or :init
15:37 plobsing the compiler shouldn't need to know what we're doing with the packfile. :init *only* executes if the packfile is going to be executed (not if it is being compiled to PBC)
15:37 plobsing that knowledge is libparrot's responsibility
15:38 whiteknight plobsing: right. From the point of view of libparrot, the only thing we need to care about is what to do once we load bytecode.
15:38 plobsing and the :init behaviour depends on what we do with the packfile. therefore, it *is* libparrot's problem.
15:38 whiteknight I don't follow that
15:39 plobsing responsibilities: create packfile => compiler; do things with packfile => libparrot
15:39 plobsing compiler doesn't know what happens to the packfile
15:39 plobsing :init depends on what happens to the packfile
15:40 whiteknight maybe I'm misremembering some details of :init
15:40 plobsing therefore, :init cannot be implemented with only the information available to the compiler
15:40 whiteknight I need to read over that code again
15:41 plobsing in fact ./parrot test.pbc fires :init blocks. how is IMCC supposed to handle that?
15:42 whiteknight okay, then I am definitely misremembering
15:42 whiteknight what exactly does :init do then?
15:43 whiteknight and how exactly is it different from :load right now?
15:43 plobsing the gory details are in do_1_sub_pragma
15:44 plobsing if we are going to run a main sub, we run :init subs first.
15:45 whiteknight okay
15:45 plobsing so, the same could be accomplished by prepending a call on to :main
15:46 whiteknight what I would really like to see is for libparrot to be able to query the packfile: "Give me an ordered list of things to execute now"
15:46 whiteknight then :main becomes nothing besides the last item in the list of :init
15:46 whiteknight This also gives us the ability to sequence things after main, for cleanup etc
15:47 plobsing my vision is that packfiles contain exactly two flagged subs (mentioned in the header) - one for :load, one for :main
15:47 plobsing HLLs can implement functions in these to provide whatever they need
15:48 whiteknight I would also really love it if :main could be a multi, like what Rakudo does
15:48 plobsing and :load should register functions, methods, classes, etc. they don't register by default
15:48 whiteknight but if the packfile returns an invokable, it comes down to the compiler setting that, not anything libparrot needs to care about
15:48 plobsing no more looping over all the constants in the PBC a million and one times
15:49 whiteknight exactly right. If packfiles cached those things and produced them on demand it would be a huge performance win
15:49 whiteknight especially considering that people want to be able to specify more constants, and more types of constants in PBC
15:49 plobsing its not about cacheing, its about explicitly stating operations (in stead of having parrot perform certain convenient ones automatically)
15:51 plobsing right now, parrot loops over all the constants, thaws them eagerly, and if they are isa Subroutine, installs them in the appropriate place.
15:51 plobsing yuk
15:52 plobsing oh and some core types (eg: classes) depend on this eager loading to register themselves
15:54 whiteknight yeah, and that's all very stupid
15:55 plobsing whiteknight: the problem with querying for a sequence of invokables is that what needs to be run depends on what you want to do with it.
15:55 plobsing you'd have to be able to tell the library "I want you to be initialized so that I can run arbitrary functions out of you" or "I want you to run through main three times over", etc
15:56 plobsing I prefer a simple interface of "what function will initialize you?" (:load) and "what do you consider main?" (:main)
15:58 whiteknight plobsing: that's fine by me. It should be easy enough for IMCC to take all functions marked :load and combine them into a single onload function
15:58 whiteknight and easy enough for IMCC to combine all :init functions and the :main function into a single crt0-like entry point
15:59 whiteknight and those two things should be stored someplace special so we can find them O(1), not O(n)
15:59 plobsing I suppose IMCC could do the magic for that. Not really liking the idea of doing that work though.
16:00 whiteknight well, in reality it probably won't be IMCC. Jettison the garbage and use PIRATE instead
16:00 plobsing whiteknight: I agree fully on the O(1).
16:00 whiteknight and nothing should automatically initialize itself based on the assumption that we eager-load all constants
16:00 whiteknight if it's not in a :load function, it doesn't happen
16:00 whiteknight period
16:01 plobsing I'm thinking of creating a temporary flag in PBC to allow IMCC to remain ignorant of our improvements, but force new PBC generators to use the new approach.
16:01 plobsing PBC_GENERATED_BY_IMCC
16:02 plobsing the old cruft has to stay as long as IMCC, but with any luck, that won't be that long
16:03 whiteknight yeah, I hate making those kinds of concessions
16:03 whiteknight First step is really getting packfile PMCs working, and then getting a good interface together so we can build Packfiles reliably without IMCC
16:04 whiteknight we update PCT to generate PBC directly, then we can start ripping IMCC out
16:04 whiteknight $P0 = new ["Packfile"] \n $S0 = freeze $P0 should generate a valid .pbc file every time
16:06 plobsing what? no! freeze generates a Packfile or PBC from an arbitrary PMC.
16:06 plobsing freezing a packfile would create a PBC whose only element was another PBC
16:07 plobsing that's like what freeze Eval does now. And I'd like to avoid that in the future.
16:08 Kristaba joined #parrot
16:08 allison joined #parrot
16:08 whiteknight okay, forget the freeze opcode. $P0.write_to_file() method is fine too
16:12 PerlPilot joined #parrot
16:12 whiteknight the important point isn't any specific interface. It's that we should be able to turn a Packfile PMC into a .pbc file without too much effort
16:26 whiteknight it makes intuitive sense to me that a .pbc is simply a frozen Packfile, but I'm not nearly so familiar with the implementation details as you are
16:30 dmalcolm joined #parrot
16:30 whiteknight it does seem to me like that's the easiest way to get a packfile PMC back out when we load it in again
16:31 Coke I don't think typeof(freeze(PMC)) is ever == "PBC"
16:32 whiteknight Coke: it isn't now, but I see no reason why it couldn't be
16:32 Coke I could see that being the natural representation for a frozen packfile, though.
16:32 plobsing Coke: they share the same header and low-level serialization/deserialization. the idea has always been that they be similar or the same.
16:33 whiteknight that's what I'm saying. Freezing a PMC already gives you a packfile header. Just jam in some bytecode after that and the other segments, and we have ourselves a PBC
16:34 plobsing but what happens after the header differs at the moment. my approach to unification is to jam the PMC into a constant table.
16:36 whiteknight I'm not really sure what you mean by that. If we freeze a Packfile PMC we can jam the Packfile itself into the constants table and put in the rest of the segments too
16:36 whiteknight Maybe that's too complicated
16:37 plobsing packfiles have more stuff
16:37 plobsing we could expose that to arbitrary PMCs in freeze/thaw, but it would be complicated
16:37 plobsing eg: debug segments, annotations, etc
16:41 whiteknight we can get those PMCs from the Packfile PMC, right?
16:41 whiteknight like we can look up the annotations segment PMC and play with that?
16:41 plobsing whiteknight: the constants table is particularly tricky. freeze/thaw puts strings into the enclosing constants table. what happens when freeze thaw tries to freeze the constants table strings? it puts the strings into the constant table, which it needs to then freeze!
16:42 whiteknight ...stupid
16:42 slavorg left #parrot
16:42 plobsing freeze/thaw is *how* we find the strings in the first place
16:42 plobsing you have to walk the object graph to be able to know what strings you'll need in the the PBC
16:43 plobsing whiteknight: I suppose it could be made to work with packfile inside of freeze in stead of the other way around; it just seems inside out to me.
16:43 whiteknight I'm getting the impression that we could increase parrot's performance in a wild way if we just cut out all the stupid in the packfile system
16:44 plobsing The way I saw it, freeze on a PMC just created 'Packfile { ConstantTable { PMC } }' and let pbc take care of the rest
16:44 plobsing whiteknight: you have something better in mind?
16:44 plobsing oops. misparsed.
16:44 whiteknight plobsing: it just seems to me that you freeze a Packfile, which freezes all it's children segments and things. We go from having a constants table inside a packfile to having the constants table and packfile(s) and packfile segments in it
16:45 whiteknight that is, the constants table isn't in the packfile, it is the packfile
16:45 whiteknight then we can have anything we want in there: arbitrary constants, bytecode segments, one or many packfiles, etc
16:46 whiteknight I get the feeling I am oversimplifying
16:46 plobsing interesting concept
16:47 plobsing problem though: how do we find which constant is the bytecode segment?
16:47 whiteknight the packfile PMC would contain pointers to it's various children
16:47 plobsing right now, we just assume the first couple indexes in the packfile directory are constant table, and bytecode segment (which is wrong)
16:48 whiteknight we could put the packfile in a special place (constant #1) or we iterate to find it
16:48 plobsing ah. constant #1 is the only special thing. I like that. it's as close to reasonable as parrot is likely to get.
16:48 whiteknight I really like the idea of being able to store multiple independent Packfile PMCs in a single .pbc file
16:48 whiteknight turns PBC merge into a 5-line PIR program
16:49 plobsing whiteknight: we already sort of do. check out the output of PBC merge.
16:49 plobsing it tacks the old segments on to the end.
16:49 whiteknight yeah, I've seen it. I don't like what it does merging the constants tables together and all
16:49 whiteknight that whole program is ugl y
16:52 plobsing I like the idea of merging constant tables. it allows (in theory) for the elimination of some duplication.
16:52 PerlPilot left #parrot
16:52 PerlPilot joined #parrot
16:53 plobsing and if the constant segment is the packfile, you *will* have to update the bytecode upon merge. the indices of all the const-variant ops will be off.
16:54 plobsing or is that complexity being pushed elsewhere?
16:54 whiteknight it seems to me like if we are going to be merging constants table and expecting to remove duplicates that we should either store items with hashes, or we should order them in some way
16:55 whiteknight what about nested constants tables? Then we never need to merge and never need to update indices
16:55 whiteknight what we do need is to extend constants to take a table ID and an idex
16:55 whiteknight index
16:56 plobsing nested constant tables could work
16:56 plobsing they'd be a mapping to the lower level table that remained fixed.
16:56 plobsing at the cost of a bunch of references
16:57 plobsing which are cheaper than dups if your strings are on average longer than sizeof(INTVAL)
16:57 plobsing no need for constants to take a table ID. every bytecode segment keeps track of what constant segment it uses.
16:58 whiteknight yeah, that's cool too
16:58 whiteknight once we have the pbc loaded into memory, we can store a single cache of thawed entries, and go there directly if we've already thawed something
16:59 whiteknight or maybe even do a little bit of bytecode rewriting to update references in place on lookup
16:59 plobsing sure, if you want to get fancy. I like simple. We tend to do fancy poorly around here.
17:00 whiteknight truer words are rarely spoken
17:00 whiteknight it's not necessarily that we do fancy poorly, but that we try to build fancy on bad foundations, following incomplete designs
17:01 whiteknight this is why I want to design a new packfile system up front
17:02 ambs joined #parrot
17:03 whiteknight What I *really* would like to do is to make packfiles more tolerant to change and never have to bump PBC_COMPAT again
17:03 whiteknight ever
17:03 slavorg joined #parrot
17:03 JimmyZ joined #parrot
17:04 whiteknight if we defined Packfile PMCs in Lorito directly, and let them handle their own thaw/load behavior, we get that
17:04 whiteknight assuming Lorito ops don't change or renumber (and there are ways around that)
17:04 plobsing delegating thaw behaviour to packfiles themselves is a *bad* idea
17:05 plobsing I'd like to be able to introspect code without having to run it first please
17:06 plobsing and I've been moving to a more fine-grained approach to PBC_COMPAT. for example, adding/removing an op no longer requires a bump to the global compat, just a library rev bump.
17:07 plobsing but seeing as how most people only ever use core ops, that doesn't fix much
17:07 plobsing but in theory, if we segregated ops into smaller sets, people would be immune to op changes unless they were using that functionality
17:08 plobsing I've been thinking of doing something similar to enable supprot for dynpmcs in constant tables.
17:08 plobsing but if everyone just uses core PMCs, we're stuck with the same problem.
17:09 cxreg reading http://www.artima.com/lejava/a​rticles/azul_pauseless_gc.html
17:12 plobsing whiteknight: I'd also like M0 to *not* be the interchange format. M0 implies trust. We want to allow communication and storage of code that is potentially untrusted. M1 (~current PBC) should be what is exchanged.
17:23 JimmyZ github is down?
17:36 whiteknight plobsing: What I have always wanted is to store the M1 op definitions in the PBC itself
17:36 whiteknight so the beginning of PBC would be a table showing a mapping between M1 and M0 ops
17:38 plobsing and how do I know that one of those is safe?
17:38 whiteknight how do you know anything is safe? Define safe
17:39 plobsing maybe I don't want anything touching the disk
17:39 plobsing maybe I don't want anything touching the network
17:39 plobsing security layer has to occur below PBC, M0 is below security layer
17:40 plobsing not to mention, all those op definitions will get repeated for each and every PBC. seems wasteful. why not package them up as libraries?
17:41 plobsing what we need is a way for oplibs of multiple versions to coexist
17:48 plobsing and PBC compat isn't just about ops. adding/removing/modifying PMCs causes roughly an equal number of PBC_COMPAT bumps.
17:48 plobsing M0 doesn't fix that at all.
17:49 plobsing nor could a self-unpacking packfile
17:50 Kristaba whiteknight: Hi! Have you any interesting task for me today? :)
17:54 JimmyZ left #parrot
18:09 kennym joined #parrot
18:19 cotto_work ~~
18:24 cotto_work Where's fbrito at?
18:25 Coke nqp: say("does this work?")
18:25 p6eval nqp: OUTPUT«does this work?␤»
18:25 Coke tcl: puts ok?
18:30 whiteknight Kristaba: not today. My computer died last night and I couldn't make any tasks
18:35 Kristaba whiteknight: It died? What happened?
18:35 slavorg left #parrot
18:35 atrodo whiteknight> External monitor?
18:35 slavorg joined #parrot
18:35 whiteknight the backlights on my monitor stopped working, so I can't see anything on it
18:35 whiteknight atrodo: yeah, that's probably what I will end up doing in the short-term
18:36 atrodo whiteknight> When I got my mini12, it's backlight was DOA.  A quick service call and a loose connection later, it was happy again
18:37 Kristaba Oh, your computer was a laptop?
18:37 Kristaba Bad luck ::
18:37 atrodo but using an external monitor was the only way to use it until it was fixed
18:39 whiteknight atrodo: I had taken the LCD screen for my laptop apart a while ago to replace a bad hinge. I suspect during that process I left the connection loose, or put the wire back in a position where it was crushed/cut by the new hinge
18:39 atrodo No fun either way
18:39 whiteknight so what I ultimately need to do is open that monitor up again (huge PITA) and take a look
18:39 whiteknight if the connector is unseated, it's an easy fix
18:40 whiteknight if the wire is murderlized, different story
18:42 whiteknight a screen replacement is not cheap. At this point, it might be better for me to just price out a new laptop and spare me from the pain and hassle of buying a new one and installing it, possibly creating new problems
18:43 Kristaba Yes, it's sure
18:46 nwellnhof joined #parrot
18:51 Kapace_ ping dukeleto
19:05 rfw joined #parrot
19:06 Kapace_ morning rfw
19:07 rfw morning Kapace_
19:16 slavorg left #parrot
19:16 slavorg joined #parrot
19:19 Zaur left #parrot
19:21 mtk0 left #parrot
19:27 Patterner left #parrot
19:30 hercynium joined #parrot
19:36 nwellnhof left #parrot
19:37 Psyche^ joined #parrot
19:37 Psyche^ is now known as Patterner
19:56 ligne joined #parrot
20:00 contingencyplan joined #parrot
20:02 PerlPilot left #parrot
20:03 perlpilot joined #parrot
20:04 perlpilot left #parrot
20:04 perlpilot joined #parrot
20:06 perlpilot left #parrot
20:07 perlite_ joined #parrot
20:10 perlite left #parrot
20:10 perlite_ is now known as perlite
20:16 Kovensky left #parrot
20:16 Kovensky joined #parrot
20:17 kennym left #parrot
20:22 Andy joined #parrot
20:26 muixirt left #parrot
20:26 bluescreen left #parrot
20:31 khisanth_ joined #parrot
20:35 Khisanth left #parrot
20:36 rurban_ joined #parrot
20:37 bluescreen joined #parrot
20:39 kennym joined #parrot
20:39 rurban left #parrot
20:39 rurban_ is now known as rurban
20:43 dalek parrot/nwellnhof/unicode_io: 479e428 | nwellnhof++ | / (12 files):
20:43 dalek parrot/nwellnhof/unicode_io: [str] Implement partial string scan
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: Add a new function partial_scan to the string vtable:
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: INTVAL partial_scan(INTERP, STRING *src, INTVAL count, INTVAL delim);
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: Scans up to src->bufused bytes in src and sets src->bufused and
20:43 dalek parrot/nwellnhof/unicode_io: src->strlen to match the maximum number of complete characters found.
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: For variable length encodings it is possible that the buffer isn't consumed
20:43 dalek parrot/nwellnhof/unicode_io: completely. In that case, partial_scan returns the number of additional
20:43 dalek parrot/nwellnhof/unicode_io: bytes needed to decode the next incomplete characters. Otherwise returns 0.
20:43 dalek parrot/nwellnhof/unicode_io: This assumes that the initial buffer length in src->bufused is aligned
20:43 dalek parrot/nwellnhof/unicode_io: to the unit size of the string encoding.
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: Scans only up to count characters. Set count to -1 to disable this check.
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: Stops after decoding a character with code delim. Set delim to -1 to
20:43 dalek parrot/nwellnhof/unicode_io: disable this check.
20:43 dalek parrot/nwellnhof/unicode_io: review: https://github.com/parrot/parrot/commit/479e4281be
20:43 dalek parrot/nwellnhof/unicode_io: 4207774 | nwellnhof++ | / (16 files):
20:43 dalek parrot/nwellnhof/unicode_io: [io] Implement Unicode string IO with partial_scan
20:43 dalek parrot/nwellnhof/unicode_io:
20:43 dalek parrot/nwellnhof/unicode_io: And get rid of the kludge in src/io/utf8.c
20:43 dalek parrot/nwellnhof/unicode_io: review: https://github.com/parrot/parrot/commit/4207774d20
20:43 dalek parrot/nwellnhof/unicode_io: 33be1f5 | nwellnhof++ | / (10 files):
20:43 dalek parrot/nwellnhof/unicode_io: [io] Implement readline for Unicode
20:43 dalek parrot/nwellnhof/unicode_io: review: https://github.com/parrot/parrot/commit/33be1f5c93
20:44 dalek parrot/nwellnhof/unicode_io: e3a5f25 | nwellnhof++ | src/ (3 files):
20:44 dalek parrot/nwellnhof/unicode_io: [io] Don't use linebuf flag for reading
20:44 dalek parrot/nwellnhof/unicode_io: review: https://github.com/parrot/parrot/commit/e3a5f25863
20:44 dalek parrot/nwellnhof/unicode_io: 4ab2f48 | nwellnhof++ | src/ (3 files):
20:44 dalek parrot/nwellnhof/unicode_io: codingstd fixes
20:44 dalek parrot/nwellnhof/unicode_io: review: https://github.com/parrot/parrot/commit/4ab2f48a12
20:44 sorear I should problably set the PEBKAC detection heuristic lower than 15 simultaneous commits
20:45 ambs left #parrot
20:48 PerlJam or change dalek to only show summary information here and the full output on #dalek (or whatever other channel we create for full output)
20:52 khisanth_ is now known as Khisanth
20:57 nwellnhof joined #parrot
21:00 dd070 joined #parrot
21:10 plobsing_ joined #parrot
21:11 whiteknight left #parrot
21:15 plobsing left #parrot
21:22 Khisanth left #parrot
21:30 Khisanth joined #parrot
21:32 rurban_ joined #parrot
21:34 rurban left #parrot
21:34 rurban_ is now known as rurban
21:40 davidfetter joined #parrot
21:45 perlite left #parrot
21:47 dd070 left #parrot
21:48 khisanth_ joined #parrot
21:54 Khisanth left #parrot
22:01 ligne left #parrot
22:03 khisanth_ left #parrot
22:07 fperrad left #parrot
22:16 perlite joined #parrot
22:18 khisanth_ joined #parrot
22:28 khisanth_ left #parrot
22:46 Khisanth joined #parrot
23:09 Andy left #parrot
23:49 kid51 joined #parrot
23:54 kid51 cotto_work ping
23:54 cotto_work kid51: pong
23:54 kid51 Were you able to get the GCI organization administration issue resolved?
23:55 cotto_work nope
23:55 cotto_work the ticket still exists
23:55 cotto_work er, task
23:56 cotto_work dukeleto was on earlier but I missed him
23:56 kid51 k
23:59 whiteknight joined #parrot
23:59 whiteknight good evening, #parrot

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

Parrot | source cross referenced