Parrot 3.8.0 "Magrathea" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 29 September 2011.
benabik whiteknight: Saw you talking with nine about the exception problems on his branch. Did you two figure out anything? 00:00
whiteknight I haven't really been able to look at it
00:13 eternaleye joined, arnsholt joined, AzureStone joined, perlite joined 00:14 particle1 joined, TiMBuS joined, dod joined 00:18 AzureStone joined 00:19 particle joined, nopaste joined
cotto zackarymorris.tumblr.com/post/10973...s-terrible 00:40
~~ 02:14
crickets chirp 02:20
02:29 nbrown_ joined
cotto the dis spec reminds me of M0. I'm sure it'd be the other way around if I'd seen it first. 02:32
www.vitanuova.com/inferno/papers/dis.html
plobsing remembers chromatic posting that a year or so ago. everything old is new again. 02:34
cotto I'm pretty sure I originally heard about it from him. 02:35
plobsing it may be worth noting that, IIRC, there was a gsoc task this year (not sure if they got a student) to *replace* dis. 02:40
if I can find where I read that, I'll link it so we can learn from their mistakes 02:41
code.google.com/p/inferno-os/wiki/I...LimboPlans has hints 02:47
I'm not finding a lot of information about the current inferno community. I'm starting to turn up completely unrelated information. 03:10
www.hpi.uni-potsdam.de/hirschfeld/p..._AcmDL.pdf
unrelated, but interesting
04:29 nbrown joined 05:37 SHODAN joined
cotto plobsing, Hmm. I'm not sure what to do with that. 06:00
06:23 Coke joined 07:06 baest joined 07:11 rfw joined 07:41 schmooster joined 07:57 mj41 joined 08:25 lucian joined 08:39 jkitazawa joined 08:50 lateau joined 09:12 baest joined 10:03 schmooster joined 11:22 lateau joined 11:36 benabik joined 11:42 Psyche^ joined 12:02 bluescreen joined 12:13 whiteknight joined
whiteknight good morning, #parrot 12:14
benabik o/ whiteknight 12:15
whiteknight good morning benabik. How are you doing today? 12:16
benabik whiteknight: tired and don't wanna study 12:17
whiteknight so don't! Procrastination is a wonderful, magical time machine to awesome adventures
except, you don't feel like going right now
12:46 Themeruta joined
dukeleto ~~ 13:15
whiteknight good morning, dukeleto 13:18
dukeleto whiteknight: how goes it? 13:33
dukeleto has been on vacation and out of the loop
whiteknight dukeleto: it's going very well. Where was the vacation?
I started adding pcre support and RegExp to Jaesop over the weekend, along with basic IO, so that has me very happy 13:36
dalek kudo/nom: 299e5af | moritz++ | src/core/Mu.pm:
Mu.not
 13:38
kudo/nom: 545638a | moritz++ | src/Perl6/Actions.pm:
deal with "require ::"
dukeleto whiteknight: visiting family in Florida 13:39
whiteknight: i am very happy to see Jaesop happily hopping along
benabik nine's been busy on getting tasks in place, but has been hampered by strange behavior involving longjmp + data corruption. 13:40
whiteknight the pcre bindings are one of the last big things before the stage0 compiler is usable to bootstrap. I have to add a few more runtime details, but we should be able to get started on stage1 soon if we are so inclined 13:41
I would like to have 6model in place beforehand, and I would love to be able to use a new PACT instead of PCT for the backend if possible
dalek esop: 6187388 | Whiteknight++ | t/stage0/regexp.t:
Add in a quick test for RegExp.compile
 13:42
benabik Maybe post-midterms I'll try to get the low-level of PACT stubbed out... 13:43
dukeleto whiteknight: i have heard rumors of PACT, but haven't seen a spec for it yet 13:44
whiteknight dukeleto: no spec. We're shooting from the hip
dukeleto A good reason to never write ASM for performance reasons: zombe.es/post/4059999783/openssl-outmoded-asm
benabik I've been collecting my thoughts in a gist: gist.github.com/05267b2b46beca86b8da 13:45
dukeleto I found that link from DJB's twitter account ( twitter.com/#!/hashbreaker ) which means we live in the future now. 13:46
whiteknight: i like shooting from the hip, as long as I have a flamethrower 13:47
whiteknight I think we've learned quite a good deal over the years from PCT and tree-optimization and the like 13:53
and if we start small, PACT can benefit from trial and error 13:54
dalek esop: a868012 | Whiteknight++ | t/stage0/regexp.t:
add in another quick test for /regexp/ syntax, which should be the same as the explicit constructor
13:54 mtk joined
dukeleto benabik: i would like to see that gist go into a doc in a branch 13:59
benabik dukeleto: If I get it into some kind of organization, sure. If someone else wants to do the same, sure. But at the moment it's more a "pile of benabik's brainstorming" than anything else. 14:22
14:23 alester joined
benabik Some thoughts added, including how I was thinking about building PACT (under bottom up) 14:30
whiteknight I had been meaning to take a stab at organizing it 14:40
I'll look at it today
benabik Although I was although thinking PACT wouldn't be developed in parrot.git. A small separate repository might be easier to work on. Wouldn't have to integrate with parrot build system, could use outside dependencies like Rosella for tests. 14:47
But since I don't have the time to build it myself, I can't really complain about what someone who does does with it.
whiteknight I'm not against all that, in theory. I would even be perfectly happy to have it as a part of Rosella, if you like that idea 15:14
or separate too 15:15
benabik I'm a fan of the UNIX philosophy… Separate small things each doing their job. :-D 15:17
whiteknight that's fine too. 15:18
benabik But, as I said, I don't have time to work on it enough, so feel free to do it however's convenient for you. 15:19
whiteknight :)
dalek sella: c2edf5e | Whiteknight++ | src/unstable/container2/ (3 files):
Throw in a few quick notes about rewriting the Container lib
 15:25
dukeleto benabik: i don't care if PACT code is in parrot.git, but a more permanent document that parrot devs can edit is better for a spec
benabik: i love gists, but as soon as multiple people want to edit it, it should become a document in a repo somewhere 15:26
benabik: do you want a pact repo in the parrot github org?
whiteknight I can create one there
dukeleto whiteknight++
benabik dukeleto: Once someone else wants to edit it, they're welcome to stick it somewhere. :-D But as long as it's just my notes, I'll leave it in the gist.
dukeleto: Unless/until I sort it out into coherent thoughts instead of random notes. 15:27
It's getting closer each time I poke at it.
dukeleto benabik: sounds good to me 15:28
whiteknight github.com/parrot/PACT 15:30
benabik Huh. Github added an "edit this file" button to the web interface. I can keep just opening it and mucking with it whenever I feel like. :-D 15:32
whiteknight the more mucking, the better 15:36
benabik The less mucking you do, the worse things get. :-D 15:37
dukeleto benabik: yes, they added that just after the merge button. It is like an quick "fork, commit, merge" wearing an Edit button costume 15:38
dalek sella: cac0dec | Whiteknight++ | src/query/Query.winxed:
Add an exploratory routine to Query to install some basic methods on built-in types.
 15:53
16:30 lateau left
cotto good morning 16:34
benabik o/ cotto
cotto dukeleto: nice to see you alive
dukeleto cotto: just been charging my batteries 16:47
cotto: the next release is sneaking up on us. What are we trying to deliver for m0 ?
16:49 dmalcolm joined
cotto dukeleto: I'm getting back in the M0 boat after what turns out to have been a break, but I'm not sure if it makes sense to try to predict what'll be in the release wrt M0. 16:52
dukeleto cotto: i don't care much about timelines, but knowing the next logical steps are useful 16:54
cotto dukeleto: ok
I pushed a couple commits yesterday that'll make it a little easier to add and remove ops. I expect a lot of that to happen in the near future. 16:55
dukeleto cotto: we seem to be at an impasse where we don't know how many m0 ops we want anymore
cotto dukeleto: I wouldn't say that. It's just a change in philosophy 16:56
dukeleto cotto: i like the philosophy of making it easy to add+remove ops and then forging ahead
cotto that's good
dukeleto cotto: ok. so our philosophy about ops has change to "as few as possible" to "the right number to optimize the speed of a jit" ?
s/change/changed/
cotto not necessarily a jit 16:57
M0 should map pretty closely to the operations a CPU can perform so that an optimizer isn't required to generate good code.
dukeleto cotto: isn't that another way of saying the same thing? 16:58
cotto rereads 16:59
dukeleto: pretty similar
dukeleto cotto: i agree with that statement, but it is much to vague too discern exactly which m0 ops should exist. We need specifics
cotto dukeleto: yes. 17:00
dukeleto cotto: and your statement is a bit more generic then my statement about jitting, but they are very similar
cotto dukeleto: my current plan is to plow ahead and look at how CIL and possibly one other VM deal with types (in addition to jvm, nanojit and gnu lightning) and use that as a basis for what'll be in M0. 17:01
The first part of that should be done tonight. 17:03
I'm a bit uneasy about M0 registers, especially since very few processors have 256 general purpose registers. 17:05
;)
dukeleto cotto: i would like to see a table of different vms and how many registers they have, and of what type 17:06
benabik cotto: 256 registers is more "explicit cache page" than register set
cotto I don't fully understand not_gerd's M0+/- proposal, but I like that he's put a lot of effort into making them match x86.
dukeleto: that's close to what I've been producing
it's more of "here's what types VM X knows about and what operations it can perform on them" 17:07
register count doesn't really apply to stack VMs, which is a lot of them
benabik May want to include non-virt in there… i386, x86-64, ARM 17:08
cotto sigh. There you go being all sensible.
benabik sorry
cotto well don't let it happen again 17:09
;]
that'll take longer, but it's a very good idea that I really should have thought of 17:10
dukeleto cotto: yes, the register sets of hardware is actually more useful than software vm register sets
cotto benabik++
dukeleto cotto: because we want parrot to be fast on real hardware, not other vms
benabik Shouldn't take too long...
cotto benabik: no. just another day or so depending on tuits
benabik Depends on how much data you're collating, I guess.
dukeleto cotto: is m0 trying to be risc or cisc ? 17:12
cotto dukeleto: running efficiently on x86/x64 is a high priority, so I'd say cisc-y 17:13
dukeleto cotto: look at that, we have more specifics :) 17:14
cotto whee
dukeleto: nice to have you bach 17:15
*back
or Bach
lulz: arstechnica.com/ 17:18
benabik cotto: engadget.com too 17:19
whiteknight what's going on with those sites? 17:20
benabik DDoSed by people wanting to know what's up with the iPhone 4s
cotto ah. That makes sense.
17:28 contingencyplan joined 17:32 fperrad joined
cotto merbist.com/2011/10/03/about-concur...d-the-gil/ 17:35
17:50 not_gerd joined
not_gerd hello, #parrot 17:50
dukeleto not_gerd: welcome
nine cotto: very interesting read 17:51
cotto hio not_gerd, nine 17:55
not_gerd hello, cotto 18:02
m0- is shaping up to look pretty much like the current m0 spec 18:03
(aside from the register number, that is...)
cotto not_gerd: we were just talking about M0 a bit earlier
interesting
alester so what's up with tt.taptinder.org/buildstatus/parrot/master ? 18:12
It is sad and lonely, it seems.
cotto not_gerd: what's changing about M0-? 18:13
alester: quite 18:14
alester Anything I can do to help things? 18:16
bubaflub i thought Coke was working on a replacement for that
alester What's wrong with the existing one? 18:20
not_gerd cotto: m0- ops are now variable length (ie the number of immediate arguments depends on the op) 18:21
cotto: also, tehre's no longer a single word size (64 bit) because that lead to too much spilling on x86
pointers and memory offsets are now 32 bit
whiteknight can't we have fixed-length ops? That makes traversal and analysis so much easier 18:27
not_gerd whiteknight: you're not supposed to analyse m0- - that's what m0+ is for 18:29
whiteknight oh, okay.
not_gerd whiteknight: you could think of it as the jit target for architectures without dedicated jit
whiteknight okay, that makes more sense then
So long as there is a nice, pretty, friendly, uncompressed instruction format 18:30
cotto #ps in 45 18:45
nine Damn....sometimes reading the docs would be a really great idea: "The stack context will be invalidated if the function which called setjmp() returns." 18:46
whiteknight yes, setjmp is a tricky bastard 18:49
We use it in the embedding API for callin/callout semantics, and we have to jump through some serious hoops there 18:51
nine nice pun ;) 18:52
18:56 fperrad joined
nine So I see two possible ways: try to fix the jump point issue, or try to work around continuations referencing their runloop so I can use runops 18:56
whiteknight what's wrong with the jump points? 19:02
nine The problem is that currently preempting a task means that runops returns. On return the jump point is invalidated according to setjmp(3). So there's no way I can resume that runloop, since it's most central feature is gone. So either runops does not return or I use a new runloop for the resumed task. 19:05
whiteknight why does runops have to return? 19:06
nine The scheduler just Parrot_ext_calls a task. On return it picks the next. I probably could use longjmp instead to return to the scheduler, which would leave the runloop intact. Or I make it work with a new runloop for every part of a task's execution. 19:11
whiteknight okay, that's where my confusion came from. The gsoc_threads branch used a preemptive task switch, so runops never exited 19:12
or, it could exit, but for most cases it didn't need to
in that case, the jump points are preserved
when runops returns, we can call into it again. that's not an issue 19:13
nine I think gsoc_threads never actually really worked.
whiteknight no, it didn't really. It worked for some trivial things, but it didn't work for a lot of it
nine I changed almost nothing. Especially the preemption. So it has to have the same problems. 19:14
whiteknight okay
nine I'll just try the longjmp to the scheduler. Sounds like the least intrusive way. 19:15
whiteknight okay
cotto #ps in 5m 19:25
my how time flies 19:31
dukeleto: care to take a ride on the M0 train? 19:35
er, #ps
train
19:58 mj41 joined 20:01 benabik joined 20:24 dmalcolm joined 20:34 Coke joined
benabik I think the biggest change we'd need to make for parrot to be relocatable is our runtime directories. Linker will be able to find libparrot, but we'd need to do a real search path for includes, dynpmcs, dynops, etc. 20:41
Could have a PARROTLIB environment variable (think PERL5LIB or VIMRUNTIME) or a path given to the interp on creation. 20:45
cotto benabik: that sounds like a good starting point 20:56
21:37 benabik joined 21:48 eqhmcow joined 22:36 dmalcolm_ joined 22:41 dmalcolm__ joined 22:50 whiteknight joined 22:56 bubaflub joined
whiteknight good evening, #parrot 23:02
cotto howdy 23:13
23:22 benabik joined
dalek sella: ebac3aa | Whiteknight++ | src/ (4 files):
Merge branch 'master' of github.com:Whiteknight/Rosella
 23:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!