Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Long live Git! github.com/parrot/parrot | git clone git://github.com/parrot/parrot.git
Set by moderator on 18 November 2010.
chromatic A better solution seems to be making sure that any properties added are also constant. 00:00
plobsing my ultimate solution would be to get rid of the concept of constant PMCs altogether 00:01
they are the source of far too many bugs for their value
chromatic They're just one kind of a generation.
00:02 mikehh joined
plobsing that's true. but in a naive MS GC all members from all generations get marked. 00:06
chromatic Seems like a lot of extra work though. We *know* some things will never get collected until interpreter shutdown. 00:10
plobsing OK, but how deep is that property? 00:11
will those immortal objects be mutated?
chromatic and can they point to objects of other generations? 00:12
I agree. It's not easy.
jnthn There's kinda two use cases. Things you know will never mutate at runtime, and things that are deserialized but stand a chance of mutation. 00:13
Example: a meta-object may be deserialized, but a method may get added at runtime.
nopaste "cotto" at 192.168.1.3 pasted "update version info in generated files" (44 lines) at nopaste.snit.ch/25935 00:14
cotto_work anyone care to apply that?
plobsing objects from the constant table (ie: deserialized objects) aren't marked constant ever
jnthn Ah, OK
plobsing: Which things are?
plobsing that's another place where constant is a misnomer
chromatic Really, the current use of "constant" is a misnomer.
jnthn Yeah, it's called the constants segment but, well, those things aren't made constant in any way really. 00:15
plobsing jnthn: only really internallish things like native library PMCs
jnthn ah, k
plobsing jnthn: the thing is, at the current time, there is no way to mutate the addresses in the constant table
so in some sense, they are constant
jnthn I guess maybe it's more useful to talk about mutability. 00:16
plobsing but really, they're more like a static-name-resolution table
jnthn *nod*
chromatic The other axis is their lifespan. 00:17
00:21 theory joined 00:26 allison left
dalek rrot: cfd1601 | plobsing++ | / (2 files):
add libdeps field to PackFile_ByteCode

allows tracking of non-dynoplib dependancies		 00:34
rrot: 94a6b22 | plobsing++ | compilers/imcc/ (4 files):
use libdeps to track .loadlibs in imcc
rrot: a48eca8 | plobsing++ | / (4 files):
remove HLL_lib HLL registry entry type

this is now handled per-bytecode segment as libdeps
rrot: 679b349 | plobsing++ | / (2 files):
headerizer
rrot: acf5e00 | plobsing++ | src/packfile.c:
[codetest] assert_args
rrot: d84a26f | plobsing++ | compilers/imcc/pbc.c:
avoid segfaults in IMCC when compiling to PIR/PASM
rrot: 8e09232 | plobsing++ | src/pmc/parrotinterpreter.pmc:
eliminate typemap restoration from PBC

PBC depending on typemappings existing should map types themselves or ensure other libraries which do so are loaded
rrot: b8112ff | plobsing++ | src/pmc/ (2 files):
eliminate merging HLL info from parrotinterp found in PBC

in stead, Sub PMCs which actually consume HLL info create their HLL if it is not yet present
rrot: 36eed0f | plobsing++ | / (2 files):
stop using parrotinterp as first PMC constant

this is no longer necessary. also disallow freezing parrotinterp since this no longer serves a useful propose.
rrot: 2bf863b | plobsing++ | src/pmc/imageio (3 files):
eliminate parrotinterp special case in imageio

this ill-behaved PMC is now not allowed to be frozen
rrot: 7ee8fd9 | plobsing++ | / (14 files):
Merge branch 'parrotinterp-freeze-unhack'
00:35 seanstickle joined
cotto_work sr3d.github.com/GithubFinder/ 00:35
shiny and fast interface to github
00:39 whiteknight joined
dalek rrot/embed_api: 7c6c829 | Whiteknight++ | / (28 files):
Merge remote branch 'origin/stdhandle_meths'
 00:43
rrot/embed_api: 0671540 | Whiteknight++ | / (4 files):
Merge branch 'master' of github.com:parrot/parrot
rrot/embed_api: 687438e | Whiteknight++ | src/embed_api.c:
add in the prototype embedding API functions I've been playing with
rrot/embed_api: 3c06baa | Whiteknight++ | / (4 files):
some small tweaks. The interp has a field to store a jump buffer. If we have a jump buffer defined, jump there instead of killing the process in Parrot_exit.
rrot/embed_api: 669ccd4 | Whiteknight++ | / (4 files):
start putting together the api.h file, which will be what embedding applications, and only the embedding applications, should use
rrot/embed_api: 4a128d5 | Whiteknight++ | src/ (4 files):
lots of little changes
rrot/embed_api: 7a89af6 | Whiteknight++ | / (1822 files):
merge in dukeleto's history changes
rrot/embed_api: f2252b4 | Whiteknight++ | / (4 files):
remove the two-stage initialization dance. We can now initialize an interpreter by passing in a struct of options
whiteknight ...is this going to go though the whole list?
rrot/embed_api: 8499c81 | Whiteknight++ | src/embed/api.c:
add some brackets in my macros to make things a little safer
rrot/embed_api: d67e5d4 | Whiteknight++ | src/embed/api.c:
borrow some code from the old PARROT_CALLIN_START macro set, and ensure the stacktop pointer is set/reset
rrot/embed_api: 9afb8d6 | Whiteknight++ | src/embed/api.c:
rearrange some bad code to be slightly less bad
rrot/embed_api: 100d17b | Whiteknight++ | src/embed/api.c:
remove some unnecessary lines
rrot/embed_api: d4e8708 | Whiteknight++ | src/embed/api.c:
add a failure macro for when an API call fails. Implement a few more functions for working with bytecode and executing it. Needs work
rrot/embed_api: 3259cda | (Mariano Wahlmann)++ | src/embed/api.c:
First cut of Parrot_api_set_stdhandles API function
rrot/embed_api: 3e24c1d | (Mariano Wahlmann)++ | src/embed/api.c:
Fix typos on stdout & stderr branches
rrot/embed_api: bce0e57 | (Mariano Wahlmann)++ | src/embed/api.c:
Fix typo in stdin branch
rrot/embed_api: 9d25cd4 | Whiteknight++ | / (5 files):
change the imcc_run function to return a PackFile PMC so we can use it with the new API. Add a long series of API functions that are needed by main.c. Go through main.c and start converting to the new API.
rrot/embed_api: b90d959 | Whiteknight++ | src/embed/api.c:
resolve conflict
rrot/embed_api: 3f8ed92 | Whiteknight++ | / (6 files):
fix some file references and run headerizer to see my work so far
rrot/embed_api: 1a692e9 | Whiteknight++ | src/ (2 files):
_set_executable_name takes a C string instead of a Parrot string, for consistency with other functions of this level. merge _destroy_interpreter and _exit_interpreter, since it's nonsensical to call one without the other, or to call them in any other order. Several fixes/changes/tweaks to main.c
rrot/embed_api: f68bf56 | Whiteknight++ | src/ (2 files):
add Parrot_api_flag and Parrot_api_debug_flag. Use these in main.c instead of some particularly lousy macros
rrot/embed_api: 1b6d1ce | Whiteknight++ | src/embed/ (3 files):
start breaking up the embedding stuff into multiple files. Add embed_private.h and strings.c for various purposes
rrot/embed_api: a496cf1 | (Mariano Wahlmann)++ | examples/embed/embedded_pir.c:
Minimal Parrot API use case
rrot/embed_api: 6e5f297 | (Mariano Wahlmann)++ | examples/embed/hello_world.pir:
Minimal Parrot API example
rrot/embed_api: 3ea891c | (Mariano Wahlmann)++ | / (4 files):
First round of syntax error fixes
rrot/embed_api: e98ef02 | Whiteknight++ | / (10 files):
lots of fixes. We still don't build completely, but we are much closer than we were
rrot/embed_api: c1ab56e | (Mariano Wahlmann)++ | / (4 files):
More fixes, almost there
parrot/embed_api: f41cf98 | Whiteknight++ | / (10 files):
00:44 dalek left
cotto_work apparently it is 00:44
whiteknight great
well, now everybody knows what I've been up to 00:45
cotto_work You killed my brother. I mean irc bot.
I'm going home.
whiteknight :)
goodnight cotto_work 00:46
00:46 dalek joined
plobsing whiteknight: looks like you were just too awesome for dalek 00:46
whiteknight that doesn't surprise me :)
sorear umm
dalek has turned red
whiteknight sorear: my sincere apologies
GeJ what was that? I just blinked, and dalek did a TO on the channel?
00:46 theory left
sorear 1. whitenight does branch merge 00:47
GeJ Oh, and Bonjour everybody.
sorear 2. dalek spits 200 lines of text to the channel
3. dalek sees the server go unresponsive (busy) 00:48
4. dalek quits
this doesn't explain why the debug console has switched to red on black, though
00:48 theory joined 00:52 seanstickle left 00:55 theory left
whiteknight bluescreen: ping 01:02
bluescreen pong 01:08
whiteknight: what's up? 01:11
whiteknight bluescreen: I made a commit, and copied all my changes to the embed_api branch in the parrot repo
miniparrot builds but fails an assertion. I did a little debugging, but wasn't able to find out what was going wrong 01:12
the interp->code pointer is null, which is supposed to be set from the packfile->cur_cs member, but that member is null coming out of IMCC
bluescreen right 01:13
whiteknight I haven't had a chance to run the debugger in master to see what is supposed to happen, but I did a quick comparison and it looks like I am calling all the same functions
bluescreen I'll take a look tomorrow... after sailing :D
whiteknight ah, okay. that would be awesome
bluescreen my first time ... sailing ... hehe 01:14
plobsing whiteknight: after your API work is done, pirc should be able to survive outside of core right? could we jettison it then?
whiteknight plobsing: PIRC? you mean IMCC?
plobsing no I mean compilers/pirc
whiteknight oh, I don't know. I'm not touching PIRC at all 01:15
plobsing noone is touching it. since like forever. it is dead weight.
whiteknight what do you mean "jettison it"? you mean to trash it, or to make it into a separate library?
ah, gotcha. A case could be made to abandon it and delete it
plobsing do what we did with the languages. abandon them to the web.
whiteknight we can do that without the API work
01:16 dmalcolm left
plobsing but with the API work, a) we can make the argument that we aren't killing it and b) it might make an interesting test case. 01:17
01:18 arnsholt left
whiteknight yes 01:18
and if it works out as a suitable test case, we can trash IMCC. I suspect it would take far less work to convert PIRC to the new API than it would take to convert IMCC to use it 01:19
sorear is it possible to run whiteknight-parrot sans imcc? 01:20
bluescreen i thought PIRC was already gone
whiteknight sorear: not at the moment, no 01:21
plobsing bluescreen: it is still in the source tree
whiteknight I mean, you could run it, but it would only be able to take bytecode files, not PIR or PASM files
01:24 arnsholt joined
whiteknight plobsing: where does the packfile->cur_cs pointer get set in IMCC? 01:26
cotto ~~
whiteknight I can't seem to find out where it is supposed to be set in master, and it's clearly not being set in my branch because I get assertion failures 01:27
plobsing whiteknight: my guess, PF_create_default_segs 01:31
wait, that's not right either
urg.
tangly
whiteknight urg indeed
sorear sounds like a job for watchpoints 01:33
whiteknight yeah, I just haven't had time to do it yet. 01:34
plobsing whiteknight: I'll have a crack at your bug after a little dinner 01:38
whiteknight plobsing: thanks! I'm going to look at it later too, but I don't have huge expertise in this area
and when I asked myself who might, your name jumped to the top of the list
kid51 A git question: 01:41
I want to do the equivalent of 'svn up' in a branch.
I can say: git checkout gc_ms2_faster_list
but then I want to get any updates from the remote
and I can't get the 'git pull' syntax correct 01:42
And, BTW, this is an older version of git: git version 1.5.6.5 (blame debian)
Suggestions?
'git pull' seems to work just fine when i'm in 'master' but not elsewhere 01:43
Tene kid51: older versions (not sure of version numbers) don't set up tracking branches automatically when you make a local branch 01:45
kid51: you'll want to talk to dukeleto for recommendations on workflow for older git.
I think.
kid51 Tene: I'm aware that there are differences. However, on this box when I've been downloading branches, I've been careful (I think) to include the -t option so that my branch tracks origin. 01:46
whiteknight kid51: where do you want to pull from? The master on github, or the associated branch on github? 01:47
cotto plobsing, do you think the current PMCs can be made suitable for routine pbc generation or that we should start over?
kid51 The associated branch on github
in this case, I want to see whatever bacek has committed in last 24 hours
01:48 theory joined
kid51 The man page says: git-pull <options> <repository> <refspec>... 01:48
but I seem to be missing something.
Tene kid51: the defaults for 'pull' are probably not right for that. You probably have to say: git pull origin <branch-name>
kid51 lemme try that 01:49
Tene what were you running?
kid51 $ git pull origin gc_ms2_faster_list 01:50
fatal: Couldn't find remote ref gc_ms2_faster_list
Brute force solution: I deleted my local gc_ms2_faster_list branch and then said: git checkout --track -b gc_ms2_faster_list origin/gc_ms2_faster_list 01:54
dalek rrot/tt532_headerizer_refactor: b0a5ec7 | jkeenan++ | tools/dev/headerizer.pl:
Eliminate sub main() in favor of direct code.
 01:56
kid51 So I know how to push to a remote branch but not how to pull from one.
01:56 allison joined
whiteknight git pull origin/gc_ms2_faster_list? 01:59
kid51 Tried it. No luck. But now I'm going to focus on something I already know how to do: writing tests for Perl. 02:01
plobsing whiteknight: that won't work because I deleted that branch (it had been merged) 02:04
cotto: the current packfile PMCs are *designed* for routine pbc generation. they should be good for that. but they aren't designed to be used by parrot internally, and that is the issue. 02:05
cotto plobsing, ok. What needs to be fixed? 02:06
plobsing cotto: I envision something akin to the Context PMC which is more or less a glorified struct.
cotto: what needs to be fixed for what?
dalek lek-poller: 9d471b9 | sorear++ | modules/local/ (2 files):
Use CREDITS data for tpfwikilog
cotto plobsing, what needs to be fixed for them to be used internally? 02:07
or how would they be designed differently?
whiteknight kid51: ah, that's your problem. The branch you are attempting to track is deleted
plobsing cotto: copy the contents from the equivalent structs. Parrot_PackFileX_attributes * should be identical to the struct it came from. 02:08
kid51 whiteknight: Then why does it still show up when I say; git branch -a ?? 02:10
whiteknight kid51: I don't know. 02:11
kid51 And why was I just now able to do a fresh checkout ?
sorear now that we're using git, is there any reason to keep make realclean?
plobsing cotto: that way we can just drop them in
cotto plobsing, allowing for easier porting at the cost of less encapsulation?
you beat me
kid51 sorear: To restore your working directory to the pre-Configure.pl state. 02:12
Invaluable for smoke testing.
plobsing encapsulation is not desirable for packfile PMCs. we *want* to be able to access constants with only a few pointer derefernces
we *want* to be able to get an INTVAL from bytecode through pointer dereferences
otherwise the whole VM becomes several orders magnitude slower 02:13
cotto likely true
sorear that's what git clean -dfx does, only with more chances to be wrong
cotto and even without that benefit, ease of porting is huge
kid51 sorear: But what if someone is building from a tarball, or on a system where git is not installed (cf TT #1850)? 02:16
dalek TT #1859 created by jkeenan++: 'make realclean' fails to remove release tarballs 02:18
TT #1859: trac.parrot.org/parrot/ticket/1859
whiteknight do we have any darwin experts around? 02:24
cotto: I want to add a get_user_id functionality to Parrot somewhere. Any preference for where it gets added? 02:30
I was thinking a method on the Env PMC
cotto does it need to be exposed to pir? 02:31
whiteknight yes, for TT #731, among others 02:32
primarily TT #731
we used to have an OS PMC. that would have been the best I think
cotto that's an interesting question. It doesn't really fit in Env. 02:33
whiteknight If we change the definition of the Env PMC to be a general interface to the environment, instead of a wrapper around the environment variables, it does 02:34
of course if the PMC was named EnvironmentVariables instead of Env, there would be no room for interpretation
cotto Why'd OS die. 02:35
whiteknight I have no idea
but I'm looking at the list, and it ain't here 02:36
02:37 rurban_ joined
cotto whiteknight, it's a dynpmc now 02:38
whiteknight ah
that makes more sense
cotto yeah
I'd put it there.
02:39 rurban left
whiteknight done 02:39
thanks.
02:39 rurban_ is now known as rurban
dalek rrot/get_user_id: b97b353 | Whiteknight++ | / (7 files):
add initial plaform code for a new getuid() wrapper function. Untested
 02:41
rrot/get_user_id: 7566f55 | Whiteknight++ | src/dynpmc/os.pmc:
add a get_user_id method to OS
rrot/tt532_headerizer_refactor: 02f5b42 | jkeenan++ | tools/dev/headerizer.pl:
Move call to constructor closer to where object is first used.
 02:53
02:54 kid51 left
dalek rrot/get_user_id: 32dbeca | Whiteknight++ | src/dynpmc/os.pmc:
add stub methods to determine basic file permissions to OS.pmc. Need win32 implementations
 03:06
whiteknight I have no idea in hell how to do that on win32
plobsing whiteknight: pf->cur_cs *doesn't* get set in the packfiles created by imcc. because IMCC operates on interp->code, you never had to load the packfiles created by imcc. 03:27
whiteknight really? Thats...weird 03:28
thanks for looking!
plobsing it's consistent with IMCC's expectation that the interp object is it's private dumping ground
sorry that doesn't get you very far though. miniparrot doesn't fail an assertion but in stead produces no output. 03:29
whiteknight plobsing: no, I think that information is exactly what I needed. I think I can get miniparrot working now 03:30
plobsing++ 03:31
dalek rrot/dynlexpad_get_iter: aecd881 | Whiteknight++ | src/dynpmc/dynlexpad.pmc:
add iter logic to dynlexpad PMC for TT #1028
 03:42
whiteknight okay, that's two of Coke's tickets that are seeing movement, finally 03:45
msg Coke I have started work on TT #1028 and TT #731. I have prototype code in place for both, but I need tests to verify them. If you can provide tests, or even stub tests, I can verify the behavior and merge. 03:48
aloha OK. I'll deliver the message.
dalek rrot/embed_api: 98cd26c | Whiteknight++ | src/embed/api.c:
don't call Parrot_pbc_load if the PBC comes straight out of IMCC. IMCC dumps it's code segment directly to interp->code, not to pf->cur_cs, so we don't need it. In other cases, we might need it
 04:06
whiteknight plobsing++
plobsing: that change worked. If I don't call Parrot_pbc_load, miniparrot runs to completion. It doesn't do anything, but it does run
plobsing true, but I *wish* it worked the way you had it before 04:07
whiteknight yeah, I think we can set pf->cur_cs = interp->code in imcc_run() and get more consistent behavior
well, I've done more than enough for one night. I'm out. Goodnight 04:13
04:13 whiteknight left 04:29 bluescreen left 05:26 contingencyplan left 05:34 theory left
dalek rrot: 1413960 | plobsing++ | / (10 files):
eliminate deprecated :unique_reg PIR value flag
 07:09
rrot: 14a6501 | plobsing++ | DEPRECATED.pod:
remove completed :unique_reg deprecation entry
tracwiki: v6 | plobsing++ | ParrotDeprecationsFor3.0 07:11
tracwiki: add deprecation information for :unique_reg
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v22 | plobsing++ | ParrotDeprecations
tracwiki: add removal note for :unique_reg
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
TT #1622 closed by plobsing++: [DEPRECATED] :unique_reg flag
TT #1622: trac.parrot.org/parrot/ticket/1622
08:20 fperrad joined 08:38 chromatic left 09:19 plobsing left 09:51 contingencyplan joined 10:36 rurban_ joined 10:39 rurban left, rurban_ is now known as rurban 10:50 lucian left 11:00 SingAlong joined
tadzik i18n support -- looks like something I could do. Along with Polish translations 12:32
SingAlong Is this the right state of the Actions.pm file pastebin.com/ysgFshh6 after the episode-3 frm the PCT tutorial here docs.parrot.org/parrot/latest/html/...3.pod.html 12:34
anyone? 12:36
tadzik sorry, I have no idea 12:37
SingAlong tadzik: thats fine :)
tadzik but I promised myself to go through this too some time ago
13:24 Patterner left 13:34 Psyche^ joined, Psyche^ is now known as Patterner 13:36 SingAlong left 13:42 M_o_C joined 14:05 kid51 joined
mikehh I am still getting an invalid git describe -> RELEASE_2_10_0-406-g14a6501 14:25
15:03 whiteknight joined
dalek rrot: ca026f3 | mikehh++ | MANIFEST.generated:
add some 2.10.1 Release information
 15:05
rrot: 766d18f | mikehh++ | README:
add some 2.10.1 Release information
rrot: 89f2691 | mikehh++ | docs/parrothist.pod:
add some 2.10.1 Release information
mikehh where does git describe --tags get its info from 15:12
kid51 mikehh I'll have to RTFM on that. But you are correct in thinking that as long as 'git describe --tags' returns RELEASE_2_10_0-409-g89f2691, we will have an invalid version. 15:17
mikehh kid51: yes - git describe --tags -> RELEASE_2_10_0-409-g89f2691 15:18
which is what I get when I configure 15:19
kid51 The command finds the most recent tag that is reachable from a commit. 15:20
If the tag points to the commit, then only the tag is shown. Otherwise,
it suffixes the tag name with the number of additional commits on top
of the tagged object and the abbreviated object name of the most recent
commit.
mikehh AFAIKS all my details are 2.10.1, except that git describe
kid51 --tags
Instead of using only the annotated tags, use any tag found in
.git/refs/tags.
(This admittedly, is from an older version of git) 15:21
I suspect that the key phrase is "the most recent tag that is reachable from a commit". 15:22
Does that suggest that tag RELEASE_2_10_1 is *not* reachable from whatever someone has as HEAD? 15:23
mikehh kid51: I dunno, this is driving me nuts (not that that is something new :-} ) - will try and work it out later - got to go out now
mikehh bbl
kid51 Latest commit is 89f2691d... 15:27
But when I say: 'git describe' or 'git describe master', I get: fatal: cannot describe '89f2691db32fa45d5f85bbbef87f4824b7526198' 15:28
15:32 cognominal left 15:36 M_o_C left 15:43 cognominal joined
moritz git describe --tags 15:58
kid51 I suspect that somehow we have to establish the following commit as an ancestor of HEAD: 16:09
cat .git/refs/tags/RELEASE_2_10_1
7240365cbf1ac9709f17f72b949d09b83b468027
The tag would then be "reachable" from HEAD and 'git describe --tags' should do the right thing. 16:10
But I don't know how to retroactively establish an older commit as an ancestor of HEAD.
PerlJam I'm pretty sure, it's not the age of the commit, but rather it's position in the DAG 16:17
kid51 I think I've got a workaround 16:21
smoking
dalek rrot: 9560334 | jkeenan++ | /:
Trying to merge the tag with trunk.
 16:27
16:32 kid51 left 16:39 kid51 joined
dukeleto kid51: what were you trying to accomplish with the last commit? I don't think you understand what a tag is. 17:01
kid51 dukeleto: I was attempt to get the git describe step to report 2_10_1 17:03
perl mikehh's complaints
dukeleto kid51: yes, but what commands did you run to attempt to do that?
kid51 See backscroll; if that wasn't right, revert.
I identified the sha for the commit corresponding to RELEASE 2_10_1 17:04
I then said: git merge HEAD <that sha number>
I resolved two small conflicts and committed
From that point forward, lib/Parrot/Git/Describe.pm, when it called git describe --tags, found 2_10_1 as more recent than 2_10_0 17:05
config/auto/git_describe.pm wraps around Parrot::Git::Describe
dalek rrot: 16e3709 | dukeleto++ | docs/project/git_terminology.pod:
Add 'tag' to our Git Terminology
dukeleto kid51: i've read the backscroll.
kid51: it seems to have worked, good job :) 17:06
kid51: I didn't think what you did would fix "git describe", but it has, so ignore me :) 17:07
kid51: thanks for making the wheels turn
kid51 From googling, it appeared that the only way to make the 2_10_1 tag "reachable" from HEAD was to conduct a merge
dukeleto Sounds reasonable. 17:08
kid51 Earlier in the day, I used the gitk utility. It confirmed that, at that point, the 2_10_0 tag was an ancestor of HEAD but 2_11_0 was not.
dukeleto: I have to go now ... but can you comment in the Trac ticket about RTEMS? 17:09
17:09 kid51 left
dukeleto kid51: remember, it is "master" now, not "trunk" ;) 17:19
dalek p-rx/nom: c0a8057 | jonathan++ | build/Makefile.in:
Stub in stuff to build dynops and dynpmcs in the Makefile.in.
 17:32
p-rx/nom: d09ff5d | jonathan++ | src/ (2 files):
Stub in STable structure and PMC.
p-rx/nom: a933d56 | jonathan++ | src/pmc/ (2 files):
Stub in REPR and RakudoObject PMCs. Also group name should be nqp.
p-rx/nom: d7c1c43 | jonathan++ | src/pmc/repr.pmc:
Oops, forgot REPR stub in last commit.
p-rx/nom: eacdd63 | jonathan++ | .gitignore:
Update .gitignore.
p-rx/nom: 2ba2ff8 | jonathan++ | build/Makefile.in:
Meangingless makefile twiddling.
p-rx/nom: 30b07bf | jonathan++ | src/ops/nqp.ops:
Stub in dynops file.
p-rx/nom: 6c334c6 | jonathan++ | build/Makefile.in:
Remove a copy-pasto.
p-rx/nom: 740820a | jonathan++ | / (2 files):
Final tweaks to mean we get through the build with the added dynpmcs and dynops sections.
p-rx/nom: 6993c74 | jonathan++ | .gitignore:
Few more .gitignore additions. Nice and clean now, on Win32 at least. :-)
p-rx/nom: f8c2bfe | jonathan++ | src/ (4 files):
Add get_how and get_what dynops, along with a few other bits we need to implement them.
p-rx/nom: 92a64b2 | jonathan++ | build/Makefile.in:
Add missing dependency in Makefile.
p-rx/nom: 3bd3746 | jonathan++ | src/metamodel/rakudoobject.h:
First draft of REPR commonalities struct.
p-rx/nom: 56e4f77 | jonathan++ | src/metamodel/rakudoobject.h:
Macros for getting hold of the REPR.
p-rx/nom: 8559903 | jonathan++ | src/ops/nqp.ops:
repr_instance_of and repr_defined dynops.
p-rx/nom: c3fdd59 | jonathan++ | / (3 files):
Implement a first cut of the representation registry and add it to the build.
p-rx/nom: 165c1dc | jonathan++ | src/ops/nqp.ops:
Initialize the representation registry when initializing the dynops.
p-rx/nom: de518d7 | jonathan++ | src/ (2 files):
Add repr_type_object_for op; minor documentation improvements.
p-rx/nom: a811d92 | jonathan++ | src/metamodel/rakudoobject. (2 files):
Another couple of macros and constants, plus some utility functions for common things we'll need to do accross many representations.
p-rx/nom: eabe08e | jonathan++ | src/ops/nqp.ops:
Use the general initialization function from the initialize dynop; we'll put all the other bits in there.
p-rx/nom: b150741 | jonathan++ | / (4 files):
Add first cut implementation of KnowHOWREPR, which bootstraps the object model.
p-rx/nom: 821ae53 | jonathan++ | / (4 files):
Start to get the KnowHOW bootstrap in place.
p-rx/nom: 6e462f2 | jonathan++ | src/metamodel/r (2 files):
Give representation API another Parrot-specific extension for freeing objects.
p-rx/nom: b6dd053 | jonathan++ | src/pmc/rakudoobject.pmc:
The mark and destroy v-tables delegate to the representation, since it's responsible for storage.
p-rx/nom: c0740a4 | jonathan++ | src/ (2 files):
Move mark/destroy flag setting to the Right Place.
p-rx/nom: cf50438 | jonathan++ | src/ (3 files):
Start to get the low-level method finding in place, including stubbing in what'll eventually support lookups optimized by gradual typing.
p-rx/nom: 12bdd74 | jonathan++ | src/metamodel/knowhow_bootstrapper.c:
Fill out a bit more of the KnowHOW bootstrap by getting method dispatch to bottom out. Of course, we can't add and dispatch methods just yet.
p-rx/nom: cc336d8 | jonathan++ | src/metamodel/knowhow_bootstrapper.c:
Implement (representation-polymorphic) type creation by KnowHOWs. Also implement add_method and find_method in the KnowHOW meta-object. This means we can create KnowHOWs, add methods do them and dispatch to them.
p-rx/nom: d7451b9 | jonathan++ | src/metamodel/knowhow_bootstrapper.c:
Add .^compose for KnowHOWs.
p-rx/nom: bf7cb99 | jonathan++ | src/NQP/ (2 files):
Some groundwork for the new meta-model implementation in the grammar and actions. Mostly copied from JnthnNQP.
p-rx/nom: 5d440c6 | jonathan++ | / (4 files):
Start to stub in the P6opaque representation. Doesn't actually compute any slot storage and store attributes yet, but this gets the outline in place.
p-rx/nom: 41e23ef | jonathan++ | src/metamodel/reprs/P6 (3 files):
Add struct definitions for P6int/P6num/P6str representations.
p-rx/nom: 2d11499 | jonathan++ | / (5 files):
Implement P6int/P6num/P6str reprs so far as they are in the .Net version of 6model and add them to the build.
p-rx/nom: 7dcc493 | jonathan++ | build/Makefile.in:
Need to put building the dynops/dynpmcs pretty early.
17:34 dalek left
jnthn er... :) 17:34
tadzik die-hard bot indeed ;)
17:35 plobsing joined 17:36 dalek joined 17:53 chromatic joined 17:57 zby_home joined 17:58 muixirt joined 18:01 tojek joined 18:15 theory joined
dukeleto works on Google Code-In stuff 18:16
whiteknight yeah, that's a good idea 18:18
where do I put new tasks at this point, in Trac still or directly into Melange?
dukeleto whiteknight: have you signed up as a mentor on Melange? 18:19
whiteknight: i didn't see you apply to be a mentor
whiteknight I don't think so. Link?
dukeleto whiteknight: socghop.appspot.com/gci/mentor/requ...oundations 18:20
whiteknight requested 18:21
dukeleto whiteknight++ 18:23
whiteknight dukeleto: do you have a link to that time-planning website for the PDS? 18:30
and when was our last PDS? Was that all the way back on April 11th? 18:33
dalek p-rx/nom: 5341f72 | (Solomon Foster)++ | build/Makefile.in:
Fix missing tabs.
 18:35
18:36 rurban_ joined 18:39 rurban left, rurban_ is now known as rurban
dukeleto whiteknight: doodle.com 18:41
whiteknight: it was a while ago, can't remember exactly. the parrot-dev archives will tell you
whiteknight yeah, I think it was April 11
muixirt hi dukeleto do you plan to resurrect ecmascript? 18:44
seen bnoordhuis
aloha Sorry, I haven't seen bnoordhuis.
dukeleto muixirt: i am interested in Javascript on Parrot, yes. I don't plan on calling it ecmascript, though :) 18:46
muixirt: i think it needs to start from the ground up. The current 'ecmascript' is built on a deprecated foundation
muixirt: are you interesting in JS on Parrot?
s/interesting/interested/
muixirt yes, therefore I forked parrot ecmascript, but I didn't got very far 18:47
what 'deprecated foundation' btw? 18:49
dukeleto muixirt: it uses PGE and nqp 18:52
muixirt built on somewhat 'deprecated foundations' applies to most of those things marked 'active' in trac.parrot.org/parrot/wiki/Languages 18:54
whiteknight I think we can steal the majority of the existing grammar
muixirt dukeleto: any proposals?
whiteknight it shouldn't be too hard to convert that to the new NQP-RX
muixirt this "shouldn't be too hard" marker was given to a lot of parrot related projects... 18:57
dukeleto muixirt: yes, most currenly existing parrot HLLs are built on deprecated foundations.
muixirt: proposals for what? 18:58
muixirt dukeleto: that is sad
dukeleto muixirt: no, it is not sad. It is just how time works. Parrot has been around 10 years. The new foundation for writing langs has only been around for less than a year.
muixirt dukeleto: proposals to solve issues with existing parrot ecmascript or for a new beginning 18:59
dukeleto muixirt: i think current ecmascripts test suite should be salvaged, as well as the grammar
muixirt dukeleto: ok (but sad) 19:00
muixirt has the hazy thought that nqp-rx isn't the answer either 19:01
dukeleto muixirt: nothing is the final solution 19:02
muixirt: but nqp-rx is a lot more friendly to write an HLL on. Have you played with PGE or nqp-rx?
plobsing aren't there LALR parser generators for javascript? shouldn't it be pretty easy to make it self-host?
muixirt dukeleto: could be the new slogan of the Parrot project ;-) 19:03
dukeleto plobsing: do you have a link? There is a JS interpreter written in JS called "Narcissus"
tadzik could someone add me to CREDITS? I know I didn't do anything (yet) but dalek doesn't know my nick when I'm commiting to Perl6-related stuff 19:04
plobsing dukeleto: en.wikipedia.org/wiki/Comparison_of...generators
muixirt plobsing: or the Pratt parser of Doug Crockford
plobsing I've been toying with the idea of adding a Parrot backend to an existing parser/lexer generator. 19:05
muixirt plobsing++
plobsing don't karma me until I actually do something
muixirt plobsing: only to build up some pressure :-) 19:06
sorear tadzik: have do done anything for Perl 6? 19:07
plobsing the problem is, I'd like to be able to work in an arbitrary HLL, and I'm not sure how I could make that work.
dukeleto tadzik: gist what you want your CREDITS info to be
plobsing TGE allowed that IIRC, maybe I should look there
dalek p-rx/nom: 9474e17 | (Solomon Foster)++ | build/Makefile.in:
Catch two more missing tabs that slipped by me the first time.
 19:08
19:08 dngor left
tadzik sorear: s/do/you/, you meant? E.g. when commiting to Advent Calendar stuff 19:08
sorear yeah. that's enough.
tadzik see? No one even knows who Tadeusz Sośnierz is :) 19:09
dukeleto: can be alike Rakudo CREDITS entry: github.com/rakudo/rakudo/blob/mast...EDITS#L374 19:10
dukeleto plobsing: have you seen peg/leg ? piumarta.com/software/peg/
plobsing dukeleto: not specifically. my primary target ATM is ragel. simpler than a full parser, but still powerful. 19:11
dukeleto plobsing: link? i haven't heard of ragel
plobsing: i've heard peg/leg is extremely fast. 19:12
plobsing dukeleto: www.complang.org/ragel/
it's used in mongrel and hpricot 19:13
it's more than a lexer generator. it is general state machine tool.
re peg/leg: didn't allison have a project for that? 19:15
dukeleto plobsing: don't know
plobsing: how are you integrating ragel into the rest of the toolchain? 19:16
plobsing that's the problem. I want to be able to generate PIR for the state-machine parts, but use arbitrary-parrot-lang for the actions.
I'm not entirely certain it is possible 19:17
dalek rrot: 8e5d0ac | dukeleto++ | CREDITS:
Add tadzik++ to the CREDITS. The karma must flow.
 19:18
tadzik thanks dukeleto
dukeleto tadzik: no worries. Now do something good in parrot.git to earn it :)
tadzik: would you like to mentor in Google Code-In? 19:19
tadzik: we need really smart young people like you to mentor even smarter and younger people ;)
plobsing: what about doing the simplest possible thing that could work, first 19:20
plobsing: what about only allowing nqp-rx for actions?
tadzik dukeleto: oh well, sure!
dukeleto tadzik: socghop.appspot.com/gci/mentor/requ...oundations
tadzik: and look over the tasks on trac.parrot.org/parrot/wiki/GoogleC...n2010Tasks and volunteer to mentor some of them, or add some more :) 19:21
tadzik I'm planning to apply for GSoC, so I'd be into the topic anyway 19:22
dukeleto: are people slightly too old for GCI the target mentors for GCI? :) 19:23
dukeleto tadzik: yes, actually :)
tadzik: you will gain a lot of knowledge that will be useful in next years GSoC 19:24
tadzik GCI is not on summer?
plobsing dukeleto: problem 1 with nqp-rx-only is that I hate nqp
dukeleto tadzik: you will learn how to be a mentor, and then at the next GSoC, you will be on the other side of the table
plobsing: what would you rather use?
tadzik whoa, wait, I haven't yet started coding :) 19:25
dukeleto tadzik: nope, GCI starts on Monday
tadzik: GCI has many tasks types, only 1 is coding
tadzik dukeleto: I was thinking about GSoC
muixirt plobsing++ #nqp haters get some karma for free
plobsing dukeleto: winxed. but I realize that might not have a lot of users 19:26
19:26 dngor joined
dukeleto tadzik: Documentation, Testing, Code, Translation, Training, Research, Outreach, User Interface 19:26
tadzik: those are the task types
tadzik: and tasks are very small, measured in roughly how many hours they should take 19:27
tadzik: much smaller than GSoC proposals
tadzik yeah, I know the GCI tasks
now writing the mentor request as you suggested
dukeleto tadzik++
19:28 zby left
muixirt with lorito coming into existence all pir-based approaches are somewhat a thing with a 'deprecated foundation' 19:29
chromatic Not really. 19:30
plobsing PIR likely won't die. it'll just become less important.
tadzik dukeleto: sent 19:31
muixirt the trac.parrot.org/parrot/wiki/Languages 'Active' Attribute won't die either 19:33
chromatic: 'deprecated foundation' in the sense dukeleto coined it 19:35
dukeleto muixirt: PIR will mostly be generated in the future. Most people don't want to hand code PIR 19:37
19:38 theory left
chromatic Lorito replaces everything underneath PIR. 19:38
muixirt chromatic: so you rip out the old bytecode interpreter and replace it with another 19:39
and so pir turns from 'closely related' to something far related 19:41
chromatic more or less
PIR doesn't have to change.
plobsing muixirt: sort of. current-level opcodes still exist (low-level ops all the time would lead to huge code size), so in some sense it augments it.
dukeleto The *implementation* of PIR may change (i.e. PIRATE). But the PIR language itself is pretty stable 19:42
cotto ~~ 19:43
muixirt dukeleto: oh please from imcc to pirate, that means pir will have 'deprecated foundation' even more so (?) 19:44
it's overkill to use nqp-rx for compiling pir because nqp-rx (and p6regex) is designed with the notion of Perl6 mutable grammar (?) 19:46
plobsing muixirt: well all we have for making parsers right now is nqp-rx. when all you have is a hammer... 19:47
muixirt plobsing: thanks for honest explanation 19:48
dukeleto muixirt: IMCC is probably "the most deprecated foundation" we have in Parrot 19:49
muixirt: so a move to PIRATE would be awesome, but no one seems to have the tuits to make PIRATE viable 19:50
plobsing muixirt: disclaimer - my statements are my own opinions and are likely an extreme position compared to the opinions of most parrot-devs
19:50 dmalcolm joined
muixirt dukeleto: for clearity: PIRATE == github.com/parrot/pir 19:50
?
chromatic PIRATE needs generational GC 19:51
muixirt plobsing: acknowledged
dukeleto only speaks for himself as well. I guess I need to make that more clear, since I am on the Parrot Foundation Board of Directors
muixirt chromatic: puzzled... 19:52
dukeleto All rugs Parrot stands on are being ripped out from us at all times. The key is to learn a useful jig that keeps you off the floor...
muixirt chromatic: you mean PIRATE is only reasonable with gen. GC? 19:53
chromatic Right. 19:54
muixirt chromatic: but you know: gen. GC is no magic dust? 19:55
chromatic I like to think I have a fairly good understanding of Parrot's internals, yes. 19:56
muixirt chromatic: wish I would have that (don't take my complaints to serious)
chromatic PIRATE needs a couple of things. 19:57
NQP-rx needs optimizations in a couple of places. (They're hard to find.)
NQP-rx also churns through temporary GCables very quickly.
PIRATE helps with an improved register allocator, but it also suffers from what I believe are unoptimized hotspots in NQP-rx.
A self-hosted PIRATE built on a PIRATE-optimized NQP-rx with a generational GC should offer performance improvements. 19:58
muixirt chromatic: but it would be hardly faster (or as fast) as imcc?
chromatic As fast as IMCC would be nice. 19:59
Producing better code than IMCC is fairly easy.
Allowing optimizations through tcurtis's work is doable.
... and it can take full advantage of Lorito optimizations.
muixirt but Lorito will not hit the repo. any time soon? 20:00
the task of an assembler is not to optimize the compiler output in any substantial way 20:01
or is it?
cotto I expect that we'll have usable initial implementations by Feb or March. 20:02
chromatic We don't have to replace everything all at once to benefit from replacing pieces.
muixirt chromatic: I recognized the speedup of latest parrot/rakudo but that isn't substantial enough to attract the masses for rakudo perl (orders of magnitude) 20:04
chromatic That's why we're still developing. 20:05
tadzik (personally, I've encountered a slowdown) 20:06
muixirt tadzik: you did?
dukeleto muixirt: your questions are very valuable to us, because you are not tainted by Parrot-internals fairy dust :) 20:07
cotto +1 20:08
tadzik muixirt: sadly, yes
dukeleto muixirt: please continue asking parrot-devs hard questions. I will help you :)
tadzik: do you have a script that i can run on various parrot sha1's that shows your slowdown?
tadzik dukeleto: well, everything I ran was slower. Let me downgrade to 2.9.0 and Rakudo 2010.10 so I will compare that with master 20:09
dukeleto tadzik: i have a script that will run a benchmark script across parrot git commits, collecting benchmark data, so you can see how performance changes between two arbitrary sha1's
tadzik: one thing you need to be very particular about it compiler flags
tadzik: released versions don't have all the optimizations turned on 20:10
allison plobsing: a peg grammar engine? yes, self-generating
dukeleto tadzik: so if you are comparing a custom build vs. a tarball, you might have the compiler flags different
allison: howdy
allison: have you ever heard or used peg/leg ?
muixirt dukeleto: the problem is that I'm a know-nothing but anyhow believes the far more smart parrot devs are on a dead end (or at least explore the wrong path)
dukeleto allison: piumarta.com/software/peg/
20:11 mikehh left
muixirt and of course I can't figure out what is right 20:11
dukeleto muixirt: all parrot devs have their own paths, and parrot is just the weighted average of those paths
allison dukeleto: there are a whole bunch of PEG-based parsers, I wouldn't necessarily say peg/leg is the best
dukeleto muixirt: although we have general directions that most parrot devs want to go in
allison: yes, i've only heard that it is the fastest, not the best
tadzik dukeleto: oh, I have --debugging=0 in releases 20:12
that might be it, no?
chromatic I build with GCC -O3
tadzik -O2 here 20:13
allison dukeleto: fast isn't necessarily an advantage, mine is fast because it's an early prototype with few features
dukeleto: I suspect peg/leg is fast for the same reason
dukeleto: would be interesting to experiment with it, though 20:14
dukeleto: keep in mind that PEG (as it's usually implemented) is a tremendously primitive parsing language 20:15
muixirt tadzik: me uses --optimize="-O3 -g" 20:16
20:20 contingencyplan left
dukeleto allison: i am trying to understand how llvm will actually integrate into Parrot 20:22
allison: the actual specific points of contact to our subsystems
allison: do you have any thoughts on that? Should we isolate llvm to only talk to the innermost subsystem, or will many subsystems need to become llvm-aware ? 20:23
I assume parsing, the metamodel and the GC will need to be llvm-aware. I wonder what else will. 20:31
20:36 whiteknight left, mikehh joined
dukeleto prepares for an amazingly brisk run 20:40
cotto 5 miles in 34 seconds? 20:42
muixirt dukeleto: before I forget it, where is the HOWTO for "All rugs Parrot stands on are being ripped out from us at all times. The key is to learn a useful jig that keeps you off the floor..." 20:58
cotto muixirt, the support and deprecation policy 21:02
muixirt HOWTO != some.policy
cotto Can you be more specific about your question? Do you want to make sure we have a general howto doc or do you want to find out how to work with or hack on Parrot without getting bitten by a deprection? 21:08
allison dukeleto: yes, we should isolate LLVM as far as possible 21:13
muixirt cotto: without getting bitten by a deprecation (which seems very hard in conjunction with parrot compared to for instance the jvm)
allison dukeleto: we may want to provide optional libraries to interface to some features, but for the most part Parrot on LLVM should be indistinguishable from Parrot on gcc
allison heads out for a bit
21:14 mikehh left 21:17 cognominal left
cotto muixirt, Parrot isn't at the same stage of stability as the jvm but we do try hard to provide a relatively stable interface. Our support policy in docs/project/support_policy.pod attempts to outline what's safe to use and how to determine what we'll break in the future. 21:17
If you think an explicit "do this; don't do this" document would be helpful, we could come up with something like that. 21:18
dukeleto allison: i was talking about using LLVM for JIT internally, not compiling parrot with clang. 21:33
muixirt: that would be a useful howto. It is tribal knowledge currently, I guess. What would you want that HOWTO to look like?
muixirt dukeleto: good question... 21:35
muixirt has no idea 21:37
dukeleto What is the easiest way to get the date of the most recent commit to all Parrot projects? 21:39
Perl 6 has a mu and an ecosystem github repo. Parrot doesn't have stuff like that, which we may want to fix.
cotto dukeleto, collect a bunch of rss feeds and hack something to use that? 21:40
dukeleto cotto: blarg. Why can't the irc bots just keep track of a data file, that we can read?
cotto hacking dalek is an option, I guess
it sounds like something that plumage would be good at 21:42
dukeleto, are you looking for something one-off or a more long-term solution? 21:43
21:47 dmalcolm left 21:49 mikehh joined 21:54 nwellnhof joined 21:55 fperrad left
dalek rrot/string_checks: f2fa086 | util++ | t/pmc/string.t:
Repair Unicode strings altered in commit a0f3af439c8eb065c6edd4ab84557471d6202c69
 21:59
rrot/string_checks: e1b18ec | plobsing++ | src/nci/libffi.c:
fix C++ build

C++ - everyone's favorite C superset that actually isn't
rrot/string_checks: 22b943b | plobsing++ | src/nci/libffi.c:
add forgotten return statement
rrot/string_checks: f405e5f | bacek++ | / (1823 files):
Merge branch 'master' of github.com:parrot/parrot
rrot/string_checks: 9de751b | dukeleto++ | lib/Parrot/Harness/Smoke.pm:
[lib] Make Parrot::Harness::Smoke report a git sha1 as the Revision for mikehh++
rrot/string_checks: bec230d | gerd++ | NEWS:
add a news
rrot/string_checks: 20b4cdb | NotFound++ | t/pmc/string.t:
test String set_integer_keyed and set_pmc_keyed vtables
rrot/string_checks: aff3e22 | dukeleto++ | lib/Parrot/Revision.pm:
[lib] Return a correctly formatted lie about our SVN revision
rrot/string_checks: 132cca9 | fperrad++ | t/harness.pir:
[t] send git revision (instead of r1)
rrot/string_checks: c913624 | fperrad++ | / (2 files):
Merge branch 'master' of github.com:parrot/parrot
rrot/string_checks: 7171a0e | unknown++ | t/tools/ (2 files):
[t] fix tests on Windows
rrot/string_checks: 4a8395b | util++ | / (23 files):
Fix typos.
rrot/string_checks: 7c975ba | util++ | / (42 files):
Fix more typos.
cotto fun times
dalek rrot/string_checks: f34b7f8 | dukeleto++ | / (2 files):
[config] Add a config step to determine our Git SHA1
rrot/string_checks: 2598e61 | dukeleto++ | lib/Parrot/Configure/Step/List.pm:
[config] Actually run the new auto::sha1 probe
rrot/string_checks: 3815ba8 | dukeleto++ | .gitignore:
[config] Add cached sha1 file to .gitignore
 22:00
rrot/string_checks: 96696cf | dukeleto++ | t/configure/062-sha1_to_cache.t:
[config] Add tests for caching the auto::sha1 probe
rrot/string_checks: 49ca73e | dukeleto++ | / (3 files):
[config] Add a git_describe config probe and add tests
rrot/string_checks: 2e10036 | dukeleto++ | .gitignore:
[config] Add cached git describe string to .gitignore
rrot/string_checks: b9f40d5 | dukeleto++ | t/configure/063-git_describe_to_cache.t:
[config] Make the git_describe cache tests pass
rrot/string_checks: 2d7a932 | petdance++ | README:
remove an extra dash
rrot/string_checks: b63472c | plobsing++ | config/gen/config_pm.pm:
add pkg-config equivalents to parrot_config
rrot/string_checks: 748cb9d | plobsing++ | docs/embed.pod:
change docs to use parrot_config

pkg-config has problems (TT #1842). autoconf isn't used by any embedders ATM, so is purely speculative.
rrot/string_checks: 79cf2c7 | dukeleto++ | config/auto/git_describe.pm:
[config] Fix the regex that matches a git-describe string, PerlJam++
rrot/string_checks: 8123d2d | moritz++ | lib/Parrot/Configure/Compiler.pm:
fix typo in lib/Parrot/Configure/Compiler.pm
rrot/string_checks: c11d574 | dukeleto++ | config/auto/git_describe.pm:
[config] This almost adds the 'describe' key to the config hash
rrot/string_checks: b18101c | dukeleto++ | lib/Parrot/Configure/Step/List.pm:
[config] Add git_describe to the config step list
rrot/string_checks: 4899abb | dukeleto++ | config/auto/git_describe.pm:
[config] Fix bugs and make the git_describe config key work
moritz wtf?
dalek rrot/string_checks: 0d855e0 | dukeleto++ | config/auto/git_describe.pm:
[config] Remove a dupe config key for our describe string
rrot/string_checks: c1c584a | fperrad++ | t/harness.pir:
[harness.pir] Smolder properties are case sensitive
rrot/string_checks: e4bc674 | fperrad++ | t/harness.pir:
[harness.pir] fix git revision
rrot/string_checks: 71f7dbf | dukeleto++ | / (8 files):
Merge branch 'git_describe'
rrot/string_checks: 258b1d9 | dukeleto++ | t/configure/028-option_or_data.t:
[t] Make t/configure/028-option_or_data.t able to find the modules it wants
rrot/string_checks: 35e413d | mikehh++ | MANIFEST (2 files):
re-generate MANIFEST and MANIFEST.SKIP
rrot/string_checks: 87b7407 | dukeleto++ | / (2 files):
[config] Add tests for fetching the git sha1 from cache
 22:01
rrot/string_checks: 0f1fb9f | dukeleto++ | config/gen/makefiles/root.in:
[config] Add git-related cache files to Makefile template
rrot/string_checks: 8581095 | util++ | / (3 files):
Un-abbreviate cnt
parrot/string_checks: 3c1710d | util++ | / (14 files):
parrot/string_checks: Fix typos.
22:01 dalek left
mikehh what was all that about? 22:03
nwellnhof i merged master into string_checks. seems that dalek reported every merged commit. 22:04
moritz wow. 22:05
mikehh plobsing: ping 22:07
plobsing mikehh: pong 22:09
22:11 dalek joined 22:16 cognominal joined
mikehh plobsing: g++ she don't work with your add libdeps 22:16
plobsing fun times
on it
mikehh plobsing: gcc just gives a warning, but g++ borks 22:18
22:23 muixirt left
dalek rrot: 1526a9f | plobsing++ | compilers/imcc/pbc. (2 files):
headerizer
 22:35
plobsing mikehh: fixed and pushed
mikehh plobsing: great, she builds now 22:45
sorear Would anyone here be offended if I made dalek not use Parrot's CREDITS? 23:00
Instead it'd be in perl6/mu like the poll list is
cotto sorear, why? 23:02
sorear cotto: because tadzik, lichtkind, and jnthn all have broken Parrot entries and I can't do anything about it 23:03
tadzik hmm, I have a fresh one and it's alredy broken?
sorear tadzik: you just complained about it in #perl6, remember? 23:04
16:59 < tadzik> dalek, I don't like this nickname either, but no one knows who Tadeusz Sośnierz is
tadzik sorear: yeah, but I'm suprised that's a matter of a CREDITS entry
cotto sorear, you can send a clone request or nopaste a patch here. It seems like that'd be easier. 23:05
I'm not necessarily against using mu, but it seems like a patch would optimize for laziness. 23:06
plobsing why can't it use both? if it is tracking multiple projects, it stands to reason no one credits file would contain the list of all developers 23:07
23:24 contingencyplan joined
dalek rrot: 6434aa6 | mikehh++ | compilers/imcc/pbc.c:
add missing ASSERT_ARGS and c function docs
 23:33
mikehh plobsing: you might want to check the added documentation to see if you want to add anything to it 23:35
23:36 zby_home left
plobsing mikehh: that seems adequate. if people are going spelunking into imcc, that is the least of their worries. 23:44
23:49 gbacon joined
dalek rrot/string_checks: 776f248 | nwellnhof++ | src/io/socket_ (2 files):
[io] Revert change to socket code for now

It broke Rakudo's IO::Socket and UTF-8		 23:52
cotto anyone feel like going to brazil?
23:59 kid51 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!