Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Onward and upward with Google Code-In | Please test rakudo with bleeding edge parrot! | Remove deprecations | close tickets | merge html_cleanup and embed_api2
Set by moderator on 14 December 2010.
cotto dukeleto, can you invalidate socghop.appspot.com/gci/task/sugges...9270216789 ? kid51 took care of it before a student could get to it. 00:00
00:01 whiteknight left 00:19 nopaste left 00:20 TonyC left 00:27 TonyC joined, nopaste joined 00:35 kennym left
dalek rrot: 0b20a82 | plobsing++ | DEPRECATED.pod:
deprecations for planned :init and :load flag related changes
 00:42
rrot: 3749000 | NotFound++ | t/pmc/namespace.t:
test Namespace get_pmc_keyed RSA key with a null element
 00:46
00:46 Kristaba left
dalek rrot: c51b642 | plobsing++ | DEPRECATED.pod:
remove deprecation notice for PIR assignment syntax

we're not going to fix this mistake. see TT #906 for why.		 00:47
TT #1895 created by plobsing++: [DEPRECATED] difference between :load and :init Sub flags 00:54
TT #1895: trac.parrot.org/parrot/ticket/1895
TT #1896 created by plobsing++: [DEPRECATED] :init Sub flag
TT #1896: trac.parrot.org/parrot/ticket/1896
TT #1897 created by jkeenan++: Implement 'silent' configuration 01:10
TT #1897: trac.parrot.org/parrot/ticket/1897
01:13 nwellnhof left 01:50 kid51 is now known as kid51_at_dinner
dalek tracwiki: v2 | plobsing++ | PackfileTasklist 01:59
tracwiki: add note about :load/:init deprecations
tracwiki: trac.parrot.org/parrot/wiki/Packfil...ction=diff
rrot/errors_globals_flag_deprecation: d9e5a88 | plobsing++ | / (7 files):
remove deprecated PARROT_ERRORS_GLOBALS_FLAG constant
 02:22
rrot/errors_globals_flag_deprecation: 9c05317 | plobsing++ | DEPRECATED.pod:
remove deprecation notice for PARROT_ERRORS_GLOBALS_FLAG
tracwiki: v9 | plobsing++ | ParrotDeprecationsFor3.0 02:32
tracwiki: add PARROT_ERRORS_GLOBALS_FLAG deprecation info
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v25 | plobsing++ | ParrotDeprecations
tracwiki: add note about PARROT_ERRORS_GLOBALS_FLAG deprecation
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
GeJ anyone else having troubles with github? 02:38
02:38 bluescreen left
plobsing GeJ: seems fine to me. what problems are you having? 02:39
GeJ lots of errors 502 when pulling from different repos. 02:42
Dancer, dist-zilla, diaspora are concrete examples. 02:43
those are read-only pulls.
parrot pulls fine (as a read-write repo). 02:44
plobsing ohm-eta-wink-kzd pulls are fine for me (r/w)
GeJ rakudo (read-only) pulls fine. hmmm. 02:45
`git clone github.com/rcaputo/bot-pastebot.git Bot-Pastebot` returns "error: RPC failed; result=22, HTTP code = 502" 02:46
so I'm not completely crazy. Anyway, I'll wait and retry some time later. Sorry for the noise.
02:48 bluescreen joined 02:55 kid51_at_dinner is now known as kid51
dalek m-eta-wink-kzd: a8743c4 | plobsing++ | src/ometa-base.winxed:
lookup rules in super calls correctly
 03:20
m-eta-wink-kzd: a4ebaf2 | plobsing++ | src/winxed-compiler.dual:
winxed does not do semicolon insertion
03:52 kid51 left 04:05 Zaur joined 04:23 Yuki`N left 04:28 contingencyplan left 05:32 rurban_ joined 05:34 rurban left, rurban_ is now known as rurban 05:39 dd070 joined
dd070 hello !! 05:40
05:42 dd070 left 06:47 dd070 joined 06:50 dd070 left 07:48 bacek joined 08:25 contingencyplan joined
cotto hi bacek 08:28
08:42 TonyC left, nopaste left, TonyC joined 08:47 muixirt joined
muixirt good morning 08:48
08:51 nopaste joined 09:14 mikehh left 09:20 rfw left 09:26 fperrad joined 09:36 Coke left 09:42 Coke joined 09:49 Coke left 10:01 Coke joined 10:36 kennym joined
muixirt cotto ping 10:41
11:14 ambs joined 11:53 contingencyplan left 12:26 bluescreen left 12:28 muixirt left 12:31 GreenZED joined 12:34 Zaur left 12:37 bluescreen joined 12:41 Zaur joined 12:43 GreenZED left 12:49 PacoLinux joined 12:52 kennym left 13:09 Kovensky left
bluescreen good morning 13:10
13:20 Kovensky joined 13:30 whiteknight joined 13:32 rurban_ joined
whiteknight good morning, #parrot 13:32
13:34 rurban left, rurban_ is now known as rurban
Coke *cough* 13:35
13:36 muixirt joined
muixirt hi again 13:36
hi whiteknight
whiteknight hello muixirt
muixirt whiteknight: could you please tell me what you think are strong points of parrot? 13:37
whiteknight in what regard? 13:42
muixirt what parts of parrot would you consider worthy if someone asks you to develop a vm from scratch 13:43
design/architecture/concrete parts of the implementation 13:44
whiteknight oh, that's a good question.
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
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
so I would save we have learned quite a lot
many things that we've learned were learned from making and analyzing mistakes over the years 13:46
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:47
Our system of pluggable runcores is good 13:48
dukeleto muixirt: i think the most valuable subsystem of Parrot is the community of people that hack on it 13:49
whiteknight dukeleto: :) 13:50
muixirt dukeleto: I'm not willing to dispute that :-) of course I thought more on technical issues 13:51
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:52
avoiding tight coupling is something we've been doing recently to great effect 13:53
keeping things pluggable is something we do extremely well
pluggable runcores, pluggable dynops, pluggable pmc types
dukeleto muixirt: parrot has learned many lessons. I think, in general, how we handle pluggability is pretty awesome. Even our GC is pluggable 13:55
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
muixirt: is this for a school report or something? Or are you just interested to know what we think?
muixirt just interested 13:57
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
so that makes things go a little more slowly than we would like
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 13:59
muixirt what are your thoughts about the pmc/vtable subsystem 14:00
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
But, they are being replaced soon
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
dukeleto whiteknight: perhaps we just didn't set up our VTABLES correctly?
whiteknight: it seems like a bad design decision, not a problem with VTABLEs 14:03
14:03 ambs left
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:03
There are only a handful of VTABLEs that are truely universal: get_class, get_name, find_method, init, mark, destroy 14:04
maybe a handful of others for efficiency (init_int), but that's the core right there
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
knock jnthn and steal his lunch money too
dukeleto whiteknight: i am stealing many 6model ideas in my lorito branch
whiteknight dukeleto: good. the more the merrier 14:06
dukeleto has been on vacation, so has been doing more thinking than coding
whiteknight dukeleto: when are you back from vacation?
14:06 mtk0 joined
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:08
the new object model may even create some new inefficiencies while we work to transition Parrot over to the new Lorito architecture 14:09
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
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.
muixirt whiteknight: to clarify: I thought of a hl for implementing compilers 14:12
14:12 tikluganguly joined
muixirt *hll 14:12
dukeleto whiteknight: my vacation ends around Dec 25th
whiteknight: i will be traveling on the 23rd and will probably do some hacking then, tho
muixirt I think writing libraries and compilers in pir was a burden, hence the question 14:14
dukeleto whiteknight: if you signup to melange as an org admin, then you will be able to approve and publish tasks 14:15
whiteknight: i think we can have as many org admins as we want. I think
bluescreen muixirt, you can write your (any) compiler using any language
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
bluescreen NotFound wrote winxed stage 0 in C++
dukeleto whiteknight: since particle does not have the time
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.
muixirt bluescreen: yes I know but using a compiler that runs on the vm has some advantages, or what do you think?
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
muixirt what benefits have dynops (and dynpmcs) that outweigh their costs?
Coke IME, having a HLL developed in concert with parrot would have avoid a LOT of problems. 14:22
would have exposed issues with the toolset, the API... 14:23
dukeleto particle: i feel like a William Blake quote is in order... 14:24
14:37 bluescreen left, bluescreen joined 14:50 tikluganguly left
Coke wonders what is driving TT #1895 14:53
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.
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
s/and instead/instead of/
plobsing the feature *is* wrong. and it is blocking internal improvements 15:20
Coke How is it wrong? 15:21
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.
plobsing oh. what is it then? 15:23
I know it has something to do with how a file is loaded. 15:25
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
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:27
plobsing other than the fact that you have no access (nor should you) to "when the interp is initialized" 15:28
Coke Or, "at program startup" if you prefer. 15:29
$DAYJOB 15:30
plobsing what's wrong about prepending that to main?
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:31
:load is executed when we load a bytecode 15:32
so ./parrot foo.pir triggers an :init, while ./parrot foo.pbc triggers a :load
the load_bytecode op always does :load, because it is supposed to be for bytecode
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
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
plobsing you expect IMCC to deal with :init blocks properly? have you seen what it does with :immediate blocks? 15:34
whiteknight I keep forgetting about :immediate 15:35
plobsing I wish I could do that
whiteknight plobsing: either way, that's a PIR syntax issue, and a behavior of the PIR compiler. It has nothing to do with libparrot
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
this might include all :load and a :main function
plobsing: If a compiler wants to execute blocks during compilation, that's a behavior of the compiler
libparrot doesn't need to care that we are even in the middle of compilation 15:37
and we certainly don't need our Sub type to have a flag field for :immediate or :init
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)
that knowledge is libparrot's responsibility
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.
whiteknight I don't follow that
plobsing responsibilities: create packfile => compiler; do things with packfile => libparrot 15:39
compiler doesn't know what happens to the packfile
:init depends on what happens to the packfile
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
whiteknight I need to read over that code again
plobsing in fact ./parrot test.pbc fires :init blocks. how is IMCC supposed to handle that? 15:41
whiteknight okay, then I am definitely misremembering 15:42
what exactly does :init do then?
and how exactly is it different from :load right now? 15:43
plobsing the gory details are in do_1_sub_pragma
if we are going to run a main sub, we run :init subs first. 15:44
whiteknight okay 15:45
plobsing so, the same could be accomplished by prepending a call on to :main
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
then :main becomes nothing besides the last item in the list of :init
This also gives us the ability to sequence things after main, for cleanup etc
plobsing my vision is that packfiles contain exactly two flagged subs (mentioned in the header) - one for :load, one for :main 15:47
HLLs can implement functions in these to provide whatever they need
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
whiteknight but if the packfile returns an invokable, it comes down to the compiler setting that, not anything libparrot needs to care about
plobsing no more looping over all the constants in the PBC a million and one times
whiteknight exactly right. If packfiles cached those things and produced them on demand it would be a huge performance win 15:49
especially considering that people want to be able to specify more constants, and more types of constants in PBC
plobsing its not about cacheing, its about explicitly stating operations (in stead of having parrot perform certain convenient ones automatically)
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
yuk
oh and some core types (eg: classes) depend on this eager loading to register themselves 15:52
whiteknight yeah, and that's all very stupid 15:54
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
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
I prefer a simple interface of "what function will initialize you?" (:load) and "what do you consider main?" (:main) 15:56
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
and easy enough for IMCC to combine all :init functions and the :main function into a single crt0-like entry point
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.
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).
whiteknight and nothing should automatically initialize itself based on the assumption that we eager-load all constants
if it's not in a :load function, it doesn't happen
period
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
PBC_GENERATED_BY_IMCC
the old cruft has to stay as long as IMCC, but with any luck, that won't be that long 16:02
whiteknight yeah, I hate making those kinds of concessions 16:03
First step is really getting packfile PMCs working, and then getting a good interface together so we can build Packfiles reliably without IMCC
we update PCT to generate PBC directly, then we can start ripping IMCC out 16:04
$P0 = new ["Packfile"] \\n $S0 = freeze $P0 should generate a valid .pbc file every time
plobsing what? no! freeze generates a Packfile or PBC from an arbitrary PMC. 16:06
freezing a packfile would create a PBC whose only element was another PBC
that's like what freeze Eval does now. And I'd like to avoid that in the future. 16:07
16:08 Kristaba joined, allison joined
whiteknight okay, forget the freeze opcode. $P0.write_to_file() method is fine too 16:08
16:12 PerlPilot joined
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:12
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:26
16:30 dmalcolm joined
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:30
Coke I don't think typeof(freeze(PMC)) is ever == "PBC" 16:31
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.
plobsing Coke: they share the same header and low-level serialization/deserialization. the idea has always been that they be similar or the same.
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:33
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:34
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
Maybe that's too complicated
plobsing packfiles have more stuff 16:37
we could expose that to arbitrary PMCs in freeze/thaw, but it would be complicated
eg: debug segments, annotations, etc
whiteknight we can get those PMCs from the Packfile PMC, right? 16:41
like we can look up the annotations segment PMC and play with that?
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!
whiteknight ...stupid 16:42
16:42 slavorg left
plobsing freeze/thaw is *how* we find the strings in the first place 16:42
you have to walk the object graph to be able to know what strings you'll need in the the PBC
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
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
whiteknight: you have something better in mind?
oops. misparsed.
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
that is, the constants table isn't in the packfile, it is the packfile 16:45
then we can have anything we want in there: arbitrary constants, bytecode segments, one or many packfiles, etc
I get the feeling I am oversimplifying 16:46
plobsing interesting concept
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
plobsing right now, we just assume the first couple indexes in the packfile directory are constant table, and bytecode segment (which is wrong)
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.
whiteknight I really like the idea of being able to store multiple independent Packfile PMCs in a single .pbc file
turns PBC merge into a 5-line PIR program
plobsing whiteknight: we already sort of do. check out the output of PBC merge. 16:49
it tacks the old segments on to the end.
whiteknight yeah, I've seen it. I don't like what it does merging the constants tables together and all
that whole program is ugl y
plobsing I like the idea of merging constant tables. it allows (in theory) for the elimination of some duplication. 16:52
16:52 PerlPilot left, PerlPilot joined
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:53
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
what about nested constants tables? Then we never need to merge and never need to update indices 16:55
what we do need is to extend constants to take a table ID and an idex
index
plobsing nested constant tables could work 16:56
they'd be a mapping to the lower level table that remained fixed.
at the cost of a bunch of references
which are cheaper than dups if your strings are on average longer than sizeof(INTVAL) 16:57
no need for constants to take a table ID. every bytecode segment keeps track of what constant segment it uses.
whiteknight yeah, that's cool too 16:58
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
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.
whiteknight truer words are rarely spoken 17:00
it's not necessarily that we do fancy poorly, but that we try to build fancy on bad foundations, following incomplete designs
this is why I want to design a new packfile system up front 17:01
17:02 ambs joined
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
ever
17:03 slavorg joined, JimmyZ joined
whiteknight if we defined Packfile PMCs in Lorito directly, and let them handle their own thaw/load behavior, we get that 17:04
assuming Lorito ops don't change or renumber (and there are ways around that)
plobsing delegating thaw behaviour to packfiles themselves is a *bad* idea
I'd like to be able to introspect code without having to run it first please 17:05
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:06
but seeing as how most people only ever use core ops, that doesn't fix much 17:07
but in theory, if we segregated ops into smaller sets, people would be immune to op changes unless they were using that functionality
I've been thinking of doing something similar to enable supprot for dynpmcs in constant tables. 17:08
but if everyone just uses core PMCs, we're stuck with the same problem.
cxreg reading www.artima.com/lejava/articles/azul...ss_gc.html 17:09
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:12
JimmyZ github is down? 17:23
whiteknight plobsing: What I have always wanted is to store the M1 op definitions in the PBC itself 17:36
so the beginning of PBC would be a table showing a mapping between M1 and M0 ops
plobsing and how do I know that one of those is safe? 17:38
whiteknight how do you know anything is safe? Define safe
plobsing maybe I don't want anything touching the disk 17:39
maybe I don't want anything touching the network
security layer has to occur below PBC, M0 is below security layer
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:40
what we need is a way for oplibs of multiple versions to coexist 17:41
and PBC compat isn't just about ops. adding/removing/modifying PMCs causes roughly an equal number of PBC_COMPAT bumps. 17:48
M0 doesn't fix that at all.
nor could a self-unpacking packfile 17:49
Kristaba whiteknight: Hi! Have you any interesting task for me today? :) 17:50
17:54 JimmyZ left 18:09 kennym joined
cotto_work ~~ 18:19
Where's fbrito at? 18:24
Coke nqp: say("does this work?") 18:25
p6eval nqp: OUTPUTĀ«does this work?ā¤Ā»
Coke tcl: puts ok?
whiteknight Kristaba: not today. My computer died last night and I couldn't make any tasks 18:30
Kristaba whiteknight: It died? What happened? 18:35
18:35 slavorg left
atrodo whiteknight> External monitor? 18:35
18:35 slavorg joined
whiteknight the backlights on my monitor stopped working, so I can't see anything on it 18:35
atrodo: yeah, that's probably what I will end up doing in the short-term
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:36
Kristaba Oh, your computer was a laptop? 18:37
Bad luck ::
atrodo but using an external monitor was the only way to use it until it was fixed
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
whiteknight so what I ultimately need to do is open that monitor up again (huge PITA) and take a look
if the connector is unseated, it's an easy fix
if the wire is murderlized, different story 18:40
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:42
Kristaba Yes, it's sure 18:43
18:46 nwellnhof joined
Kapace_ ping dukeleto 18:51
19:05 rfw joined
Kapace_ morning rfw 19:06
rfw morning Kapace_ 19:07
19:16 slavorg left, slavorg joined 19:19 Zaur left 19:21 mtk0 left 19:27 Patterner left 19:30 hercynium joined 19:36 nwellnhof left 19:37 Psyche^ joined, Psyche^ is now known as Patterner 19:56 ligne joined 20:00 contingencyplan joined 20:02 PerlPilot left 20:03 perlpilot joined 20:04 perlpilot left, perlpilot joined 20:06 perlpilot left 20:07 perlite_ joined 20:10 perlite left, perlite_ is now known as perlite 20:16 Kovensky left, Kovensky joined 20:17 kennym left 20:22 Andy joined 20:26 muixirt left, bluescreen left 20:31 khisanth_ joined 20:35 Khisanth left 20:36 rurban_ joined 20:37 bluescreen joined 20:39 kennym joined, rurban left, rurban_ is now known as rurban
dalek rrot/nwellnhof/unicode_io: 479e428 | nwellnhof++ | / (12 files):
[str] Implement partial string scan

Add a new function partial_scan to the string vtable:
INTVAL partial_scan(INTERP, STRING *src, INTVAL count, INTVAL delim);
Scans up to src->bufused bytes in src and sets src->bufused and src->strlen to match the maximum number of complete characters found.
For variable length encodings it is possible that the buffer isn't consumed completely. In that case, partial_scan returns the number of additional bytes needed to decode the next incomplete characters. Otherwise returns 0. This assumes that the initial buffer length in src->bufused is aligned to the unit size of the string encoding.
Scans only up to count characters. Set count to -1 to disable this check.
Stops after decoding a character with code delim. Set delim to -1 to disable this check.		 20:43
rrot/nwellnhof/unicode_io: 4207774 | nwellnhof++ | / (16 files):
[io] Implement Unicode string IO with partial_scan

And get rid of the kludge in src/io/utf8.c
rrot/nwellnhof/unicode_io: 33be1f5 | nwellnhof++ | / (10 files):
[io] Implement readline for Unicode
rrot/nwellnhof/unicode_io: e3a5f25 | nwellnhof++ | src/ (3 files):
[io] Don't use linebuf flag for reading
 20:44
rrot/nwellnhof/unicode_io: 4ab2f48 | nwellnhof++ | src/ (3 files):
codingstd fixes
sorear I should problably set the PEBKAC detection heuristic lower than 15 simultaneous commits
20:45 ambs left
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:48
20:52 khisanth_ is now known as Khisanth 20:57 nwellnhof joined 21:00 dd070 joined 21:10 plobsing_ joined 21:11 whiteknight left 21:15 plobsing left 21:22 Khisanth left 21:30 Khisanth joined 21:32 rurban_ joined 21:34 rurban left, rurban_ is now known as rurban 21:40 davidfetter joined 21:45 perlite left 21:47 dd070 left 21:48 khisanth_ joined 21:54 Khisanth left 22:01 ligne left 22:03 khisanth_ left 22:07 fperrad left 22:16 perlite joined 22:18 khisanth_ joined 22:28 khisanth_ left 22:46 Khisanth joined 23:09 Andy left 23:49 kid51 joined
kid51 cotto_work ping 23:54
cotto_work kid51: pong
kid51 Were you able to get the GCI organization administration issue resolved?
cotto_work nope 23:55
the ticket still exists
er, task
dukeleto was on earlier but I missed him 23:56
kid51 k
23:59 whiteknight joined
whiteknight good evening, #parrot 23:59

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!