Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit 2300 UTC today | Please test rakudo with bleeding edge parrot!
Set by moderator on 5 December 2010.
fbrito whiteknight: I will push some code soon in my PLA fork and ask for feedback here :) 00:00
Matt_ whiteknight: I searched through the code and the path doesn't seem to be stored in PackFile, so I assign it after calling PackFile_new in functions that get passed the filename as a parameter 00:02
kid51 whiteknight: patches applied to the embed_api2 branch today do not fix the problem on Darwin, though they do reduce the volume of warnings somewhat 00:04
nwellnhof whiteknight: feel free to commit your Win64/MSVC changes to nwellnhof/compilerflags btw 00:05
nopaste "kid51" at 192.168.1.3 pasted "embed_api2: build failures persist on Darwin" (319 lines) at nopaste.snit.ch/26733
NotFound Matt_: Get a filename from the content of a packfile that can not be read? Awesome! 00:07
About the Key thing: if we are planning to replace Key with RPA, as some people have suggested sometimes, a first step should be making its vtable more compatible. 00:12
nwellnhof seems that headerizer needs to be run in branch embed_api2 00:13
kid51 I will try that 00:14
plobsing looking for the error text in TT #1833, it appears only in ImageIOThaw on the arbitrary strings codepath. there is *no* file associated with that error. 00:16
NotFound plobsing: even more amazing! 00:17
plobsing I'd close it as invalid.
fbrito whiteknight: sorry for the silly question, but if I have a 2x2 matrix and try to access a element using "matrix{Key.new(n)}", what should be returned? The n-th element on the 1st row, right? 00:18
plobsing I'd remove the arbitrary strings codepath entirely (it's not particularly useful), but testing ImageIO would get a whole lot more tricky.
Matt_ Hmm ok! Should I withdraw from the task on the GCI site?
plobsing Matt_: yes. sorry. we need better ticket triage it seems. 00:19
kid51 It looks like running headerizer.pl may have done the trick in the embed_api2 branch.
nwellnhof dukeleto: ping 00:23
dukeleto nwellnhof: pong 00:24
nwellnhof in git_workflow.pod, we should document how to create a tracking branch. 00:25
(git checkout --track -b ...)
dukeleto nwellnhof: tracking is default for the versions of git that the workflow recommends 00:26
nwellnhof: and the README mentions --track
nwellnhof: but yes, you are probably correct
dalek rrot/embed_api2: c7def2f | jkeenan++ | / (2 files):
Run 'perl tools/dev/headerizer.pl src/embed/api.o'.
dukeleto nwellnhof: what version of git are you using?
dukeleto 1.5.x is painfully old
00:27 lucian left
nwellnhof git version 1.7.2.3 00:27
plobsing perhaps exceptions originating from c should inlucde __LINE__ and __FILE__, to make tracking them easier so we can avoid thinkos like TT #1833 in the future.
dukeleto nwellnhof: then you don't need --track
kid51 On 1.5.x, when you want to track a branch, the syntax is: git checkout --track -b <newbranch> <origin/newbranch>
nwellnhof dukeleto: simply omit --track?
dukeleto nwellnhof: yep 00:28
kid51 nwellnhof On 1.6 and 1.7, yes. Alas, not on 1.5
dalek rrot: 45523d2 | dukeleto++ | README:
[doc] Tweak formatting in README
dukeleto kid51: you can also use -t
00:31 donaldh left 00:35 kid51 is now known as kid51_at_dinner
dalek TT #1833 closed by plobsing++: Incompatible bytecode error lacks important information 00:35
TT #1833: trac.parrot.org/parrot/ticket/1833
whiteknight fbrito: If you use 1 key, it treats the matrix like a normal C array 00:37
fbrito oh, totally forgot about that. thank you :)
whiteknight fbrito: look at VTABLE get_pmc_keyed_int
dalek rrot: df599f5 | dukeleto++ | docs/project/git_workflow.pod:
[doc] Describe how to track remote branches in elderly Gits
 00:38
dukeleto plobsing: that ticket you just rejected is a GCI task 00:39
plobsing: and you are wrong that those errors only happen in ImageIO
plobsing: they happen whenever the PBC format changes and the wrong parrot is used to read bytecode
plobsing: which happens a lot
plobsing dukeleto: grep the source. that's the only place it shows up. 00:40
there are only 2 places that call PackFile_unpack. only one of them gives that error on failure. 00:41
dalek rrot: 20ae439 | nwellnhof++ | docs/project/git_workflow.pod:
[doc] Fix order of git command line options
plobsing that error only happens when someone does the equivalent of '$P0 = thaw $S0'. how do you expect the packfile to know where the string came from? 00:42
dukeleto nwellnhof: danke for fixing that typo 00:43
plobsing: i swear that error happens all the time in PL/Parrot when the wrong parrot version reads an incompatible bytecode file
plobsing that may be so, but there is nothing that can be done at the packfile level. 00:44
I suspect that some code may be slurping fpmc files (probably config hash) of the wrong format.
and not handling exceptions appropriately. 00:45
dukeleto plobsing: now that sounds like it is possible
plobsing: is there *any* more info that we can give in the error? Perhaps a backtrace? 00:46
plobsing dukeleto: did you relink with config.o after the parrot update? failure to do that would cause this problem.
dukeleto plobsing: that error is really hard to debug for non-core devs
plobsing dukeleto: I think Parrot_ex_throw_from_c_args should provide a trace somehow.
dukeleto plobsing: it happens occasionally when i recompile a new parrot, but PL/Parrot finds my old parrot, and then Bad Things Happen 00:47
plobsing dukeleto: it is *trying* to save you from a segfault. although libparrot probably causes you to crash and burn anyhow.
dukeleto plobsing: that error segfaults my postgres process every time, so it is failing to save me from a segfault 00:48
plobsing yes, but imageio code is not to blame. exceptions code is. hot potato 00:49
dukeleto plobsing: i still thing that error needs to give more debug info. It is an essentially useless error 00:51
dalek TT #1833 reopened by dukeleto++: Incompatible bytecode error lacks important information 00:52
TT #1833: trac.parrot.org/parrot/ticket/1833
dukeleto plobsing: it doesn't tell the person getting the error how to fix it or what threw the error or anything
i remember getting stuck for weeks on that error and it driving me insane 00:53
plobsing so make Parrot_ex_throw_from_c_args a macro that includes __FILE__ and __LINE__
fire up gdb and break on Parrot_ex_throw_from_c_args 00:54
cotto ~~
plobsing dukeleto: what I'm getting at is that there is no more info that can be included at the point of error. Our exceptions system is lacking when it comes to errors originating from C, and our API is lacking in handling those exceptions. 00:57
01:04 dmalcolm left
dukeleto plobsing: i think i understand now 01:09
01:23 silug joined
nwellnhof plobsing: but shouldn't it be possible to add some meta information to the Packfile struct? like the filename where the data came from? 01:24
plobsing nwellnhof: not at all. '.sub 'main' :main; $S0 = freeze $P0; say $S0; .end' what "file" does that come from? the program that created it, which has no way of knowing the frozen string will be output or that the string it is outputing is a frozen pmc, or the file I may or may not be piping the output to? 01:26
or the c file that pmc gets mangled into? or the object file that c file compiles down to? 01:27
nwellnhof only in case the data comes from a file, of course. 01:28
plobsing if the data comes from a PBC file, that codepath is not taken.
nwellnhof but it seems that people are getting this error when running some files from an old Parrot installation. so it should be somehow traceable to a certain file. at least in theory. 01:32
plobsing it would be best if we got a C backtrace from C exceptions that never hit a runloop (such as is the case here) so we could easily identify the source 01:34
I suspect a stale config-hash is the culprit
kid51_at_dinner embed_api2 now PASS on Darwin: smolder.parrot.org/app/projects/rep...tails/1535 01:36
whiteknight kid51_at_dinner: awesome
I was about to fix it, but I just saw your commit
cotto kid51_at_dinner, nice work 01:38
which ocx?
osx 01:39
01:39 kid51_at_dinner is now known as kid51
kid51 I'm on 10.4 01:39
old school
whiteknight bluescreen++ fixed the underlying error earlier, kid51++ put on the finishing touches
kid51 is bluescreen Mariano Wahlmann? 01:40
cotto yes
kid51 cotto: I doubt /usr/include/stdin.h changes much between Darwin versions, so I suspect we would have gotten this problem on 10.5 or 10.6. 01:41
And, for once, it has *nothing* to do with how much RAM I have.
cotto I'm curious because I just closed an old ticket that was on 10.5 01:42
01:42 Matt_ left 01:48 gg411 left
kid51 Well, I don't think you have to worry too much about that ticket (TT #1247), cotto. 01:50
allison knows how to file tickets ;-)
cotto kid51, I suspect that she does 01:51
nwellnhof plobsing: afaics, the codepath *is* taken when reading a PBC with load_bytecode 01:54
see Parrot_pbc_read in src/embed.c
allison kid51: I really couldn't tell you, I haven't done any Mac development in a long time 01:55
kid51: I would assume it's not an issue any more, as no one else has complained about it
plobsing nwellnhof: look at the *second* line of the error message. now look at the error message in Parrot_pbc_read(). they are not the same. 01:56
this is not the point of failure you are looking for
nwellnhof plobsing: yes, scratch that
kid51 Re trac.parrot.org/parrot/ticket/1883; does anyone understand what 'make bootstrap-ops' is really supposed to do? 01:58
plobsing kid51: it is supposed to rebuild the core ops library. it builds enough of parrot to run ./opsc --core 01:59
then it runs ./opsc --core, and rebuilds. At least that's my understanding.
cotto pretty much 02:00
kid51 So, why is it now DWIMming?
s/now/not
s/now/not/
plobsing looks like a non-default make target exposing a dependancy failure in our makefile. 02:01
fbrito hm, I really have to learn about pointers :P. can someone please take a quick look on this? pastie.org/1354231 02:03
I want to make it work, but without creating a new variable 02:04
plobsing we need to list the dependency of nqp-rx on cclass.pasm
fbrito: (1) doesn't compile because you need to predeclare variables. 'INTVAL element1, element2;' above the code should fix the build error. 02:07
fbrito: not sure why (2) segfaults, but you are aliasing a variable with a variable of a different type which is just asking for trouble. 02:09
fbrito I did what you suggested on (1) and it worked :o but I can't understand why it was working on (3) and not on (1) 02:10
nwellnhof plobsing: i think the problem with #1833 is thawing the config hash in Parrot_gbl_set_config_hash_interpreter in src/global_setup.c
plobsing nwellnhof: I agree with that diagnosis. And the solution to making that error easier to debug would be (a) to have access to a C level backtrace or (b) for it to be possible to handle exceptions from c (so Parrot_gbl_set_config_hash_interpreter() could spit out something intelligent about the situation). 02:12
bluescreen fbrito (2) you are redefining "key"
not PMC *key and then PMC * const key 02:13
plobsing fbrito: C makes the distinction between variable declarations and code. Declarations start with a type and may include statements as initializers. However, once a line of code (which does not start with a type) has been hit, you cannot put another declaration line.
cotto whiteknight, ping 02:14
whiteknight pong
cotto is it a good time to talk about roadmaps?
fbrito plobsing: ahh, now I understand. thank you very much :)
cotto fbrito, you should get a copy of k&r if you don't have one already 02:15
en.wikipedia.org/wiki/The_C_Program...%28book%29
whiteknight cotto: sure
k&r is a good book, but a ripoff 02:16
same price now as it was 40 years ago
fbrito cotto: I will take a look, thank you. Before CGI I (almost) only worked with high level languages, like Python and Ruby 02:17
cotto I've recently become a fan of a minimalist ticket queue, so I'm trying to think if tickets are the mechanism we should use for tracking roadmap items in the future.
whiteknight I dont think so 02:18
cotto Integration with the rest of trac is nice, but if we continued to use them as we have been, most of the work would be pushing tickets back.
whiteknight they end up too vague and open-ended
cotto I want what we to do be transparent and accurate as much as possible.
whiteknight right 02:19
tickets in a huge queue are obuscated
obfuscated
cotto I'm not sure if it's possible, but I'd love to see a 100 ticket queue. 02:20
kid51 For all but a handful of us (not including me), such tickets are untakeable and uncloseable
whiteknight probably not.projects with queues that small are typically smaller and special-purposed
memcached, etc
cotto kid51, that may be an innate problem
most people don't know all parts of parrot or have experience with all platforms 02:21
whiteknight again, Parrot is big 02:22
cotto yes
whiteknight a smaller ticket queue means smaller Parrot
rfw oh, afternoon fbrito o/
cotto there's a correlation, though we're not near optimal yet 02:23
whiteknight no
cotto anyway, if we want the roadmap to be on trac that implies it'll be in either tickets, the wiki or something else I'm missing.\\ 02:24
fbrito rfw: Hello! Good evening (23:23 here :P). We should talk in private. They are discussing some important parrot related things here
cotto fbrito, rfw, no worries. The channel can handle two threads of conversation.
whiteknight I like wiki
rfw (secret: i don't really have anything to talk about, i just wanted to say hi)
cotto whiteknight, me too. It has the issue that it gets stale, but that's more an indication of how we're using it (or not) 02:25
whiteknight tickets get as stale or worse because they get burried 02:26
lost on page 9/12
cotto that's where I usually hunt for lhf for closing 02:27
Do you have any thoughts on how we should structure the roadmap?
I guess that has a lot to do with the tuits of the volunteers working on its items.
whiteknight by supported release 02:28
thats a course enough granularity but still useful
cotto I'm thinking that supported releases are the highest level of granularity we can reasonably say anything about
apart from talking about the next release or two 02:29
bluescreen it is a pain in an company doing roadmap where you can count on heads... can't imagine in an OS project
but the good thing is that in most companies people is unhappy and do the least is expected from them.... here people is really passionated about what they're a doing 02:30
cotto Yes. It's good to know that nobody's here because they have to be. 02:31
plobsing people at companies get to work on their projects 40 hours a week...
cotto or more positively, everyone here wants to be here
whiteknight right, monthlies are too close together, and too hard to manage
people work on what they want, it takes time to prepare a major goal 02:33
cotto What about having a relatively solid per-quarter plan for the next year, a general plan for the n+1 year and a vague idea of after that
whiteknight i like it
cotto and at the post-x.0 PDS, we figure out the next yearly roadmap
whiteknight good plan 02:34
nwellnhof plobsing: is there a way to get PARROT_PBC_MAJOR and PARROT_PBC_MINOR out of libparrot?
plobsing nwellnhof: ack says no. 02:36
and if it were possible, it put money on needing the config hash to get at it ><
s/it put/I'd put/
cotto whiteknight, ok. I should have enough time to blog on that. It's not a very complicated plan. 02:37
whiteknight cotto: general meta-plan out of the way, what are the goals for 2011
?
cotto The next step is to figure out what'll go on the roadmap
plobsing nwellnhof: do you want to compare the version you have versus the version expected? we can modify the error msg to include that info.
whiteknight MOP? Lorito? GC? 02:38
plobsing roads?
nwellnhof plobsing: forget it, it was a thinko.
cotto MOP first
whiteknight GC will happen concurrently methinks
cotto It's insanity to try and move to Lorito and change the mop, and I don't want to have to reimplement the current mop
kid51 What is the minimum set of improvements/feature additions you want to see in each of 3.0, 3.3, 3.6, 3.9? 02:39
cotto sure. it's pretty orthogonal
s/want/expect/
whiteknight jnthn and team have MOP. bacek and co have GC 02:40
I'm sure plobsing and friends have packfile magic too
cotto me and my team have lorito
whiteknight right
and I'm going to be on a beach somewhere drinking mohitos
cotto and there's no reason why we can't do Lorito and the MOP simultaneously 02:41
whiteknight in a secured location
right
kid51 What do the architect and the project manager think they can deliver in each of the supported releases?
cotto whiteknight, wfm as long as you have your laptop with you on the beach
whiteknight :) 02:42
as product manager, it probably makes most sense for me to focus on MOP, packfiles, and GC. in that order 02:43
kid51 As you can tell, I'm recommending confining the roadmap to what the leadership thinks it can reasonably promise to deliver
cotto kid51, absolutely
whiteknight by 3.6 I would like HLLs to be able to output bytecode directly, instead of PIR
kid51 Anything that happens above and beyond that is icing on cake.
cotto I want to underpromise and overdeliver rather than what we've been doing. 02:44
or at least promise accurately
whiteknight MOP and packfile improvements can help to push HLLs to the next level
kid51 Which implies: Nothing on the roadmap that the two of you aren't personally invested in -- even if others do most of the work.
whiteknight nice strategy
kid51: fair
bluescreen whiteknight: +50 to output bytecode... but you have to have a nice debugger 02:45
whiteknight that's ancillary
cotto kid51, I'd say nothing goes in unless one of us or a known-reliable contributor is solidly invested in it
but I agree with the sentiment 02:46
not roadmaps without a champion
kid51 If there are things that the architect and project manager are merely lukewarm about, let others work on them but don't put them on roadmap.
cotto er, items
whiteknight I want the three things I mentioned by 4.0, no exceptions 02:47
cotto We can have a separate wishlist for other items
whiteknight so put my name down for those
a "general" wishlist and a smaller roadmap 02:48
kid51 s/project manager/product manager/
By June, I would like you guys to be capable of giving talks at conferences like YAPC or OSCON where you can say, "We promised to deliver these features/improvements in Parrot in these releases -- and we did." 02:49
cotto A nice roadmap track record will give our community manager something nice to work with.
whiteknight yes
kid51 I want you to be capable of giving the kind of talk pmichaud gave at YAPC this year on Rakudo Start
Star
cotto kid51, I'm planning on doing that kind of thing. It gives me a healthy fear atm. 02:50
kid51 Actually, if there are conferences/user groups in your local areas at which you guys could start doing presentations in, say, February, then that's when you should start doing them. 02:51
cotto kid51, good idea 02:52
whiteknight my availability for those kinds of things is low
kid51 Start with local Perl/Python/Ruby groups
whiteknight good idea, but hard to do
kid51 whiteknight: For you (unlike the rest of us ;-) ), it's mainly a question of editing down what you've already written! 02:53
whiteknight :)
kid51 phila.pm, abe.pm or PLUG would probably be good first audiences
whiteknight PLUG? 02:54
kid51 Phila Linux users group
whiteknight ah 02:55
kid51 Have never attended myself, but mjd and other Phila perlmongers have presented there
cotto whiteknight, one concern I have is jnthn's uncertainty wrt the new MOP will be "ready".
fsvo ready, of course
whiteknight of course
cotto I'd love to hear mjd talk. I'd probably be lost after 5 minutes. It'd be great. 02:56
If I search for "Seattle PHP user's group", the 3rd entry is for a Perl user's group. duckduckgo++ 02:57
I'm mostly curious what such a group would be like. 02:58
there's not much we can do about the MOP design, apart from providing jnthn with extra minions. 02:59
I trust him to get it right though. 03:00
whiteknight yeah, that's one thing we don't need to worry about
What I really would like to do in 2011, is make a bootstrapped JavaScript compiler for Parrot
once we have something that cool in our ecosystem, I think we will be able to start getting devs for other languages interested 03:01
cotto I saw some discussion about that fly by, but had to attend to other things at the time.
03:01 Matt_ joined
whiteknight python people, as an oft-cited example, don't want to make a Python compiler in Perl6 03:01
cotto There's a crazy amount of innovation happing with js right now.
whiteknight yes
There exist JavaScript parsers written in javascript. If we create a Parrot bytecode backend, we have a JavaScript-on-Parrot compiler 03:03
and then we can say to people like Python folks, or PHP folks, "hey, write your compiler for your language in your language. It's all cool with us" 03:04
NQP-RX/PCT is very powerful, but it's Perl. for some people, that's an immediate turnoff
cotto That has potential to be a big draw.
whiteknight not everybody is as open to multiple languages as Parrot folk
exactly
JavaScript devs know JavaScript. They don't necessarily know C or Perl6
so, let them write it in JavaScript, etc 03:05
(repeat that statement for all X, where X is any programming language)
I would like to get at least 1 other bootstrapped compiler project off the ground in 2011, and I think that will be a spark for a lot of people
GSOC could provide us with several, if we play our cards right 03:06
Anyway, I have to get moving to bed nowish. Continue the conversation later?
cotto a minimal bootstrappable language would be an interesting project
whiteknight yes
cotto sure
'night 03:07
whiteknight goodnight
03:07 Matt_ left, whiteknight left 03:19 bluescreen left 03:21 kid51_ joined
dalek rrot: d922b8a | nwellnhof++ | src/global_setup.c:
[src] Better error message when linking against incompatible libparrot

This should fix TT #1833.		 03:23
03:24 Matt_ joined 03:25 kid51 left
dalek rrot: 7717682 | nwellnhof++ | src/global_setup.c:
[codingstd] Fix line length
 03:29
kid51_ nwellnhof: Is there any test we could write to verify the fix to TT #1833? 03:32
nwellnhof that's hard because one would have to link against a libparrot compiled with a different PBC_MAJOR or PBC_MINOR. 03:33
kid51_ I suspected as much, but I figured it wouldn't hurt to ask :-)
plobsing likely steps to reproduce: (1) build a custom parrot with bumped pbc compat. (2) build rakudo with this custom parrot. (3) swap in normal libparrot into same location. 03:34
kid51_ mucho trabajo
plobsing s/rakudo/any application that embeds libparrot/
kid51_ must sleep 03:35
cotto kid51_, 'night
nwellnhof plobsing: i did something similar: ran an old rakudo build with a custom parrot.
03:38 kid51_ left
plobsing did it work? did you get the message? 03:39
nwellnhof yes, i did.
plobsing \\o/ I'd say this case is closed (aside from broken encapsulation, which I don't know how to avoid in this instance) 03:40
nwellnhof++
03:40 kthakore joined
kthakore seen chromatic 03:41
aloha chromatic was last seen in #parrot 19 hours 34 mins ago saying "Me too, such as it's midnight.".
cotto fbrito, after you're done with k&r, you can go on to the advanced lesson: www.bobhobbs.com/files/kr_lovecraft.html
nwellnhof plobsing: yes, it's somewhat of a hack. but i think it's the best we can do for now. 03:42
bacek_at_work cotto, hey. What about resurrecting pmc_pct? :) 03:45
03:46 Matt_ left
cotto bacek_at_work, would it be more valuable to do that or get the packfile PMCs working? 03:47
03:47 Matt_ joined
bacek_at_work Packfiles are slightly more valuable. 03:47
cotto only slightly?
bacek_at_work But pmc_pct is more fun.
cotto, we do need both at the end of they day. 03:48
03:49 Matt_ left
cotto bacek_at_work, what about irclog.perlgeek.de/parrot/2009-06-30#i_1275754 03:50
cotto gets purl flashbacks
nwellnhof somehow, the whole idea of thawing the config hash seems flawed. if we have a stable embedding API, why shouldn't an executable be able work with libparrots that support different bytecode versions? 03:51
bacek_at_work cotto, yes. This idea still hold. But we need functional l1ops and Packfiles for it.
cotto ok 03:52
I'm inclined to work on packfiles, mostly because I want to finish the work. 03:53
but they're also nice and self-hosty
bacek_at_work, if you were updating the packfiles, would you have one PMC type per struct or would you wrap all the bytecode stuff into a single PMC? 03:54
plobsing nwellnhof: agreed. thawing a config hash is extreme overkill for the ~4 values libparrot uses out of it.
bacek_at_work cotto, I'll give a look at your packfiles branch tonight. May be we can crack it fast. 03:55
afk # meetings
04:28 gg411 joined 04:30 Matt_ joined 04:48 Matt_ left 04:49 Matt221 joined 04:51 Matt221 left
fbrito msg whiteknight I have just updated my GCI task. Please take a look when you have some time: www.google-melange.com/gci/task/sho...9130043418 05:27
aloha OK. I'll deliver the message.
05:34 nwellnhof left 06:09 gg411 left 06:33 Kulag left 06:34 Kulag joined 06:42 Drossel joined 06:43 Kulag left 07:05 fbrito left 07:16 dalek left 07:17 dalek joined
cotto reparrot.blogspot.com/2010/12/roadm...ction.html 07:26
07:52 bacek joined 08:02 jan left
cotto hio bacek 08:03
moritz cotto++ # roadmap thoughts 08:04
personally, I'd even go one step further 08:05
and decouple the development roadmap from the release roadmap completely
cotto moritz, please elaborate 08:06
moritz a time based release schedule is great
but volunteer work doesn't tie well to schedules, in general
cotto It's done wonders for Parrot.
moritz so
I'd propose to only promise dates for parrot releases, not features 08:07
and have a separate development roadmap, which basically manages depencies among feature ideas
like "we need lorito for JIT compilation"
or "we need $thing for lorito first"
and that development roadmap can also have time estimates, but it doesn't really need to 08:08
cotto: does this make some kind of sense to you? 08:09
cotto That's worth thinking about. A separate development roadmap would get daunting, but it'd also show us where to put effort to reach our goals.
very much
moritz well
it would make the release roadmap basically just a list of dates, versions and an [X] for supported releases 08:10
so you'd have two lists to maintain, but one would be rather slim (and mostly autogenerated, if somebody steps up and writes a tool that generates it)
cotto I like the general idea (though I want to have features tied to releases where we know we can get them done), but I don't know how managing that on the wiki would work. 08:11
that being the dev roadmap
moritz neither do I :-) 08:12
I just made the experience that the only time you can plan is your own, and even that only in limits
cotto very true 08:13
btw, I'm loving the Perl 6 Advent Calendar this year.
moritz good to hear, thanks
08:17 jhelwig left
sorear maybe I'll do something for it 08:23
cotto sorear, what do you mean?
moritz like, a post? or two? :-) 08:25
08:31 fperrad joined
sorear moritz: that sort of thing, yes 08:33
I'm still trying to understand what it really *wants* 08:34
moritz that's easy: something related to Perl 6 that outsiders might find interesting to read 08:35
where "outsiders" mostly means "programmers who are familiar with other languages, and have heard a bit about Perl 6"
cotto sleeps 08:44
sorear most of my familiarity with that kind of person involves them laughing at Perl 6 08:52
moritz sorear: you've read too many reddit comments :-) 08:54
sorear: but fact is that many of those posts attract more than 1k readers, and most comments are very positive
sorear moritz: no, I just hang out on irc.perl.org a lot. 08:55
moritz and there's a considerable interest in non-empty Perl 6 talk in the Perl 5 community too, though some p5 people brag very loudly how much they don't care
sorear: don't let a loud minory discourage you 08:56
09:00 lucian joined 09:31 rfw left 10:06 Drossel left, Kulag joined 10:48 dalek left 10:49 dalek joined 11:04 AndChat| joined 11:12 AndChat| left 11:16 contingencyplan left 11:17 lucian2 joined 11:20 lucian2 left 11:21 AndChat| joined 11:25 AndChat| left 11:26 lucian2 joined 11:30 lucian2 left
dalek rrot/nwellnhof/compiler_flags: b6eca53 | fperrad++ | config/auto/gcc.pm:
[mingw] no -fPIC on Windows

warning: -fPIC ignored for target (all code is position independent)		 11:35
11:45 jan joined 13:11 bluescreen joined
dalek rrot/nwellnhof/compiler_flags: 6d5fc62 | fperrad++ | config/init/hints/mswin32.pm:
[mingw] lib msvcrt not needed
 13:19
13:29 slavorgn left 13:35 smash joined
smash hello everyone 13:38
13:42 whiteknight joined 13:43 Patterner left
whiteknight good morning, #parrot 13:44
smash seen chromatic
aloha chromatic was last seen in #parrot 1 days 5 hours ago saying "Me too, such as it's midnight.".
13:45 bacek left
smash chromatic ? 13:46
13:50 Kulag left
whiteknight good morning, smash 13:50
chromatic is probably still asleep
or, very recently awake
smash nods
i'll see if he pops in the next hours 13:51
13:52 Kulag joined 13:53 Psyche^ joined, Psyche^ is now known as Patterner 13:58 Kulag left, Kulag joined 14:12 ligne joined 14:24 Kulag left, Kulag joined
Coke I'm not sure where he'll respawn. 14:27
whiteknight I think we're going to be able to put together a decent JavaScript on Parrot compiler, and I think we will be able to do it pretty quickly 14:56
atrodo Exciting
dukeleto whiteknight: that sounds exciting 14:57
whiteknight I've been reading over zaach/cafe source all morning, and it looks like it should be pretty easy to add in a Parrot PIR backend 15:00
that gives us a stage 0 pretty quickly
Once we can get the generated compiler to start building itself, we can remove the non-Parrot stuff, or make the Parrot stuff the default and keep everything else 15:01
it looks like he also has an Objective-J frontend, and a Harmony front-end, so we get those for cheap too, if we want 15:02
er, I guess Harmony is just a newer version of JavaScript 15:03
15:05 bluescreen left
whiteknight the hardest part of it is, I think, setting up a good prototype-based object model for the generated code to use so we can approximate JS semantics 15:05
at the very least we will need a temp implementation until Parrot's new MOP_ is in 15:06
atrodo It's sad that's the hardest part
whiteknight atrodo: for a basic implementation I don't think it should be too hard. JavaScript objects are very Hash-like. We would need some kind of a ProtoFactory that we can put in a prototype and get out a new clone 15:07
and then we need to create a bunch of Prototype objects for built-in types, and make sure they all have a .prototype field
atrodo whiteknight> Aye. But I would have hoped that the problem would have already been solved in some regard for another language 15:08
whiteknight atrodo: yes, there just hasn't been much motivation yet. The older ecmascript compiler used the normal Parrot MOP and hacked together a working implementation
atrodo goes to read the cotto and whiteknight blogs 15:11
15:17 dmalcolm joined
NotFound whiteknight: for some value of working, las time I worked on it was only able to run very simple programs. 15:17
15:20 bluescreen joined
bluescreen whiteknight, make sure you blog in a tutorial way about it... that will make it easier for others who want to do a similar task with ruby, python or any other HLL 15:21
NotFound bluescreen: anyone wanting to write a compiler targeting pir have already a good example to borrow: the two stages of winxed. 15:23
bluescreen NotFound, is there any tutorial in how to do it...? or just reading source code? 15:24
NotFound bluescreen: reading source, asking, working and thinking. 15:25
I expect people wantning to write compilers to be able to do that. 15:26
atrodo NotFound> When I'm working, last thing i want to do is think
bluescreen but they have to learn winxed and pir
NotFound bluescreen: poor guys. 15:27
bluescreen and know that winxed already does have a compiler written in winxed
NotFound bluescreen: stage 0 is writen in C++, you don't need to learn winxed.
15:28 plobsing left
NotFound Anyway, if I should write a tutorial about writing a javascript compiler in order for someone to write it, I prefer to write the compiler. 15:29
bluescreen lol
NotFound And about python and ruby, I think there are people in its comunitys able to write compilers. 15:30
bluescreen yeah but we have to give them a few pointers in how to build the gap between the AST and PIR
NotFound trying hard to not make the usual jokes about 'pointers'... 15:31
atrodo NotFound> Actually, how easy/good is winxed at generating bytecode?
NotFound atrodo: any comment about that from me will be highly subjective, 15:33
atrodo NotFound> I can appreciate that, but the question is also highly subjective as well
NotFound About the "easy" part, I really don't know what to say. For me is good. 15:35
atrodo NotFound> When I was trying to write a bytecode generator I tried nqp, not sure if I liked it. But the more I hear about winxed, the more interested I am in it
NotFound atrodo: the bytecode generator is not bad, the bad part is that is has a lot of special cases. 15:36
atrodo NotFound> What kind of special cases?
15:36 Patterner left
NotFound atrodo: maybe is easier to ask what cases are not special X-) 15:37
atrodo NotFound> hehe
NotFound atrodo: a few examples: selecting what king of get/set_...._keyed_... should be intended depending on arguments and return or assign-to types. 15:38
kind
That may be less problem with languages that doesn't use parrot native types. 15:39
15:42 mtk joined
atrodo NotFound> Good to know. When I get back around to that project, I'll probably check winxed out more 15:42
NotFound atrodo: feel free to ask, comment, and criticise.
atrodo NotFound> I will remember that ;) 15:43
15:46 mtk left
NotFound Now that I think about it, there is a sort of step-by-step tutorial: the stage 1 history in the winxed repository. 15:48
I mean, the history of the changes of the winxedst1.winxed file. 15:50
whiteknight creating a bootstrapped compiler is not too hard: Create a stage 0 compiler, in your language, and run it on an existing compiler
then, use the output result to compile itself
when you're doing development, always use the previous version to compile the new version
15:51 mtk joined
NotFound I wrote this post some months ago: notfound.posterous.com/self-hosted-...hy-and-how 15:51
bluescreen is reading winxedst1.winxed 15:52
15:53 mtk left, mtk joined
whiteknight the key is, write the compiler in language X as if you have a compiler for language X around already 15:54
use an existing solution until yours is mature enough to host itself 15:55
no magic. C compilers have been doing it for decades
NotFound And Pascal before it.
bluescreen what should be the minimal features a compiler has to have to bootstrap itself ? string manipulation and io subsystem? 15:56
moritz "io subsystem" is a bit of a stretch :-) 15:57
print() is usually enough
NotFound Yeah
moritz (you can print to STDOUT, and your build system redirects to a file) 15:58
bluescreen but you need at least read stdin
15:58 mtk left
moritz yeah, right 15:58
ok, readline() and print()
15:59 mtk joined
bluescreen and some variables... :) 15:59
atrodo And sanitation!
(Now regrets attempting an obscure Life of Brian reference) 16:00
NotFound If you use an existing language, you can do it step by step. Start with a compiler able to compile a helloworld program.
Then, improve it until is able to compile itself. Easy ;) 16:01
bluescreen yeah... piece of cake! :D 16:02
moritz what people don't realize is that compilers are of the simplest kind of programs really 16:04
they read a file as input, and write a file as output
no concurrency or IPC needed
no interaction with stupid users 16:05
no passwords to be stored
NotFound No databases 16:06
bluescreen mortiz, you have to interact with the user and give them some feedback
moritz bluescreen: you have to give error messages, or say that it compiled OK 16:07
bluescreen: but that's not the same as asking the user "do you want to continue (y/n)?"
bluescreen not at all... but still have to make user's life easier trying to understand what they are trying to do and help them finding the errors 16:08
NotFound bluescreen: people used to write compiler in a few KB in the heroic times of personal computers, with diagnoses like "error x at line y", and they survived.
bluescreen or bare "Syntax error" 16:09
moritz most early bootstrapping stage compilers just have the "syntax error" error :-)
NotFound Having nice messages is nice, of course, but you can live without it.
moritz especially if you wrote the compiler yourself, and know it by heart 16:10
NotFound In fact, winxed stage 0 still sucks at some points... but you can try the chenges with stage 1 first.
bluescreen it doesn't make much sense to give nice error messages in stage 0 16:11
16:11 plobsing joined
bluescreen its a throw away 16:11
NotFound bluescreen: it makes sense if it helps diagnosing. 16:12
bluescreen yourself..?
NotFound Yeah
bluescreen how about: "Something wrong... please check"? 16:13
atrodo Add the word "doofus" and you've got a winner
NotFound bluescreen: sometimes is enough, sometimes is time wasting.
bluescreen NotFound: how long did it take to you to cook stage 0? 16:14
NotFound In the current winxed way, I improve the stage 0 compiler in order to be able to use a better language in stage 1, so having better diagnoses in stage 0 is helpful.
Another way can be writing a stage 2 with the more complete language. 16:15
bluescreen: about two months
bluescreen: a primitive version, of course, not its actual state.
bluescreen it's a shame you don't have the whole process blogged 16:17
NotFound bluescreen: the svn repo has almost the full process. 16:19
16:26 fbrito joined
lucian NotFound: while I think winxed is awesome and you did a great job on it, i think you're underestimating the effort needed to map an existing language to parrot 16:32
NotFound lucian: I just try to avoid overestimating it.
lucian NotFound: sure, it just takes a significant amount of work 16:34
there are a lot of corner cases. I still have no idea how python's sys._getframe() would ever work on parrot
NotFound Of course, writing a implementation compatible with existing ones and passing its test is harder than designing the language as you go. 16:35
But you don't need to start with the full spec. 16:36
lucian yeah
i do think however that parrot suggests new languages to use parrot's compiler tools, and it shouldn't 16:37
NotFound As I said, you can start with something able to compile helloworlds and the like.
lucian they can only be useful for new languages
16:37 Kulag left
lucian NotFound: if you have a new language. but existing languages have existing implementations 16:37
pynie should be written in python, cardinal should be written in ruby, etc 16:38
16:38 Kulag joined
NotFound lucian: if you use an existing implementation to write the compiler, you can *use* the full language, but support only a minimal subset. 16:38
16:38 Patterner joined
lucian NotFound: yes, initially 16:38
i don't think it's important to bootstrap using parrot only 16:39
NotFound For me, the important part is having something that works, and that people like to work with.
Even if 'people' is one person. 16:40
lucian NotFound: for pynie, that would mean passing the Python test suite 16:41
as I said, i think development of new languages is fundamentally different to existing languages
NotFound I'll be hapy if proven wrong by having a working compiler developed by any other process. 16:45
lucian NotFound: :) 16:46
i think i mentioned this before, i'd like to see pynie implemented in pure python, perhaps from PyPy's compiler 16:47
and stay that way, always require a full python implementation for building
whiteknight bootstrapped compilers is probably an area where Parrot is going to shine
PCT/NQP-RX are awesome tools, but there are plenty of people who have a simple aversion to Perl 16:48
being able to write your compiler in your language is a big deal
lucian whiteknight: not only that, but i don't see why you wouldn't self host
NotFound lucian: yeah, but if you use a preexisting self compiler the process is completely different.
lucian if you write a compiler for a language, you most likely like it enough to use it for the actual compiler
whiteknight: and there's the aversion to perl's syntax too, yes 16:49
NotFound Or just lack of confidence and familiarity with that kind of syntax. 16:50
lucian NotFound: no, there's aversion too
NotFound lucian: there is, but is not always such a strong position. 16:51
lucian NotFound: to just the syntax, there's not quite that much (but still significant)
but people hate perl5 and php so much, they associate their failings with the syntax, as well
atrodo The problem with self hosting is you're not necessarily using high quality compiler tools
lucian atrodo: depends on your language, of course 16:52
PerlJam Making Perl 6 regex/grammars available to other languages would help too. Even if people dislike Perl, they tend to see the power behind regex.
lucian atrodo: pretty much all popular languages have good compiler tools 16:53
PerlJam: again, you'll see people disagreeing there
NotFound That depends... there is also people that hate regexes, or using them too much.
PerlJam anyone writing a compiler is going to use regex (or something similiar) if they are sane
lucian PerlJam: and i think regexes are misleading. they imply finite state machines, which suck at parsing
PerlJam: again, MANY people will disagree :) 16:54
16:54 contingencyplan joined
NotFound PerlJam: you can look at winxed sources for an exception ;) 16:54
regexes are used only for including pasm constants, if I remember well. 16:55
moritz wants to point out that a typical p6 grammar for a programming language doesn't have much in common with regexes
NotFound (maybe the "if they are sane" excludes me)
PerlJam moritz: with traditional regex you mean? 16:56
moritz PerlJam: both with traditional regex, and with regex you'd write for an ad-hoc parsing problem in Perl 6
PerlJam Perhaps I'm just too steeped in my own history with using lex/yacc and their progeny so that that's mostly what I see 16:58
NotFound Remember, TIMTOWTDI 16:59
16:59 theory left
PerlJam sure, but using grammars is funnest! :) 17:00
NotFound Fun is in the smile of the beholder 17:01
fbrito whiteknight: ping 17:04
whiteknight fbrito: pong 17:05
cotto_work ~~
whiteknight hello cotto_work 17:07
fbrito whiteknight: about my tests (github.com/fernandobrito/parrot-li...t/1f1e)... should I add/remove something? change their names? where should they be placed? in testlib/matrixtest.nqp or should I copy and paste in pmc/*matrix2d.t?
whiteknight fbrito: let me look 17:08
fbrito: t/testlib/matrixtest.nqp is probably right. The tests will get inherited for all types 17:09
and saves you from having to copy+paste :)
dukeleto cotto_work: mornin' 17:11
fbrito whiteknight: and what about their names? I saw that there are some conventions, like test_MISC or test_VTABLE... but I can't figure out how should I name my tests 17:12
whiteknight fbrito: Those names all use stupid old conventions. Don't worry about them. Your names are good 17:13
I think they need to start with "test_"
otherwise the harness can't find them, but I might be wrong
brb, lunch. back in a few minutes
cotto_work seen chromatic
aloha chromatic was last seen in #parrot 1 days 9 hours ago saying "Me too, such as it's midnight.".
fbrito whiteknight: ok :D 17:14
NotFound whiteknight: what's the nick of the guy with the YCombinator task? 17:27
Don't worry, a search in the irclog told me. 17:30
whiteknight fbrito: I think the code all looks good. When you're ready submit it 17:32
dalek nxed: r701 | NotFound++ | trunk/winxedst1.winxed:
generate internal names for arguments that are unique within the outermost
 17:36
whiteknight NotFound++ 17:37
Coke NotFound: would you could original partcl as "working" ? 17:41
(going back to your send earlier about a working implementation of an existing language)
NotFound Coke: I don't know enough tcl to judge that, 17:42
fbrito whiteknight: have you seen those 2 tests that are failing in the "master" branch? inside methods/complexmatrix2d/ (conjugate and row_combine) 17:43
whiteknight fbrito: yes, those tests are marked TODO, but my test harness is not smart enough to ignore them
annoying, but OK
Coke NotFound: we passed a substantial fraction of the official tcl test suite. 17:44
NotFound Coke: then yes
17:44 theory joined
Coke ok. that was written in PIR&PMCs. 17:45
NotFound Ah, you mean I'm already proven wrong.
Coke I think so. I was scrolling pretty fast. ;)
NotFound That's not fair. I mean doing it now. And fast! ;) 17:46
Coke I would never reimplement partcl using that method, agreed. ;)
whiteknight what method?
Coke "ok. that was written in PIR&PMCs." 17:47
whiteknight ok
NotFound Any method that differs substantially from the things I talked about. 17:48
Coke that said, I'm not sure partcl would be a good candidate for bootstrapping. 17:50
whiteknight The reason I like bootstrapping is because it lets compiler devs write the compiler in whatever language they are most comfortable in 17:51
if TCL doesn't lend itself to that, you pick a different implementation language that you like
Coke like PERL? 17:52
whiteknight if that's what you're comfortable with, yes. We've got a great toolset available if you like Perl
Coke ... I was snarkily pointing out that it's Tcl. 17:53
NotFound You, and preferably the people you like to join the project.
Coke and I'm already using NQP. And I wouldn't call it a great toolset.
whiteknight Coke: well, that's an issue outside of our control. I'm sure pmichaud and co would like any feedback you have
Coke it is easier to develop in than PIR/TGE/PGE/PMCs, I'll grant you that. 17:54
whiteknight: it's too slow and needs better docs. 17:56
(most of which is a parrot issue, as you're dealing with parrot objects most of the time, nqp is just syntax to get at them.)
whiteknight fbrito: I need a few minutes. I have to reinstall Parrot for testing 18:00
dukeleto Coke: i agree with you. nqp-rx is more featureful than everything else, but you pay the price in lack of docs and speed
fbrito whiteknight: ok, no problem
NotFound whiteknight: Are you sure the man-boy program is correct? According to wikipedia: "value k; integer k;", wich I suppose mean k is passed by value. 18:01
whiteknight Notfound: I tried converting it to an int, and I tried making a copy. Maybe you can find a solution 18:02
NotFound doesn't know ALGOL 60
whiteknight From what I gather, k should be pass-by-value, not reference 18:03
so if you know how to change that 18:04
NotFound Problem is, int can't be lexical in winxed.
I'll try some workaround. 18:05
whiteknight could make a copy 18:07
NotFound A workaround seems to work, but runs out of stack at 10 18:12
whiteknight yeah, that's expected 18:13
that thing eats stack space
NotFound Good, I'll elaborate a bit more and post in the issue.
whiteknight Awesome! NotFound++ 18:14
NotFound So winxed is a man now? I tend to antropormorph it as a woman. 18:16
whiteknight a man? 18:17
NotFound man-boy test?
whiteknight ha, okay
woman-girl test
fbrito Woman-girl test? Ahahaha! We just have to test if it throws the BloodException every month. If it does, it is a woman! 18:20
Coke I suspect that send is not cool. 18:21
cotto_work +1
NotFound Fairy-pixie test if you prefer. 18:23
atrodo Perl-php?
whiteknight fbrito: submission pushed. Accepted. Thanks. 18:24
dalek rrot-linear-algebra: 25966ce | fernandobrito++ | src/ (3 files):
Update GET_KEY_INDICES_* macros to use new pmckey_to_coords()
 18:25
rrot-linear-algebra: 1f1e5c9 | fernandobrito++ | t/pmc/pmcmatrix2d.t:
Add tests to new pmckey_to_coords() function
rrot-linear-algebra: 25d9334 | fernandobrito++ | src/ (2 files):
Update pmckey_to_coords() quantity of parameters
rrot-linear-algebra: bd5a52c | fernandobrito++ | src/ (5 files):
Update GET_KEY_INDICES_ROWMAJOR quantity of parameters
rrot-linear-algebra: 66943d5 | fernandobrito++ | t/pmc/pmcmatrix2d.t:
Add more tests to new pmckey_to_coords() function
rrot-linear-algebra: 9a899cd | fernandobrito++ | t/ (2 files):
Move new tests to a place where it will get inherited
fbrito whiteknight: yay! thank you 18:29
tadzik wishes he was younger so he could get involved in funny stuff too :)
fbrito tadzik: are you in university? there is always the Google Summer of Code :) 18:31
tadzik fbrito: yeah, I'm planning that :) 18:32
(actually, it's today I become 2 years too old for GCI :))
18:33 bacek joined
fbrito tadzik: today, like... really today? is today your b-day? :o 18:34
18:34 fperrad left
tadzik fbrito: yep :) 18:36
NotFound No one picks the chunked encoding task? Sigh.
fbrito tadzik: oh!... happy birthday! :) 18:37
tadzik (I even changed my gravatar from a dog to a pic, as if I were mature or something)
fbrito: thank you :)
smash tadzik: happy birthday! 18:38
tadzik thanks smash :)
NotFound light some candles 18:39
tadzik pffffffffffffffffff! 18:41
fbrito NotFound: the chunked encoding task seems really scary to me :(
NotFound fbrito: for me too. That's what I want to pass it to other people ;) 18:42
18:44 jhelwig joined 18:45 whiteknight left, ligne left 18:46 ligne joined
fbrito NotFound: Ahahha, ok. I am going to try a task for another project and then, if no one have claimed the chunked task, I will do it :) 18:46
NotFound fbrito: thanks! 18:47
18:50 whiteknight joined 18:52 ligne left 18:54 wesjdj joined 19:09 theory left 19:13 wesjdj left 19:42 tcurtis joined 19:43 rfw joined 19:45 plobsing left 20:23 allison left, allison joined 20:26 kid51 joined
allison parrotsketch meeting now? 20:31
kid51 Yes
aloha, seen NotFound? 20:38
aloha kid51: NotFound was last seen in #parrot 1 hours 51 mins ago saying "fbrito: thanks!".
kid51 NotFound: available for parrotsketch? 20:39
NotFound Ups, got distracted, sorry.
PerlJam whiteknight++ just read yesterday's blog entry 21:04
21:08 theory joined
bacek_at_work ~~ 21:12
21:19 chromatic joined
chromatic Oh, 20:30 UTC not 21:30 UTC. 21:20
21:56 mtk left 21:57 whiteknight left
cotto_work Interesting. Google's new V8 thingy uses a linear-scan register allocator: blog.chromium.org/2010/12/new-crank...or-v8.html 22:10
22:11 Matt221 joined
dukeleto just got off the PaFo conf call and things look like they are changing for the better 22:19
cotto_work dukeleto: good to hear. What's the upshot? 22:20
22:20 bluescreen left
atrodo dukeleto> that was a long phone call 22:21
dukeleto Parrot Foundation is getting back on track and the Software Freedom Law Center is helping us get there
dukeleto learned a lot about how open source projects + nonprofits/taxes work 22:22
22:24 plobsing joined
nopaste "chromatic" at 192.168.1.3 pasted "Draft of Branch Merge Review Policy" (162 lines) at nopaste.snit.ch/26794 22:28
dukeleto gets popcorn 22:31
cotto_work I like where this is going. 22:33
chromatic It gets speculative later. 22:35
kid51 What is a "shim"?
chromatic Ever had a heavy piece of furniture which wobbled, so you took a small piece of wood or cardboard to make it fit better? 22:36
This is the code version.
22:36 dalek left
kid51 A kludge? 22:37
cotto_work That's way easier to read as pod. 22:38
22:39 p6eval left 22:41 dalek joined
dukeleto chromatic: If you've need any exclusions to the deprecation policy, have you asked for and 22:42
chromatic: some wording need fixin' there
chromatic Will do.
dukeleto chromatic: you may want to mention that coding standard tests are run with "make codingstd" or whatever it is 22:44
chromatic: or just say that all branches should pass "make fulltest"
chromatic Done. 22:45
cotto_work chromatic: is this intended to be a more complete version of docs/project/core_inclusion.pod? 22:46
dukeleto chromatic: i really like what you wrote. a big +1 from me to put that in docs/project as a stand-alone doc
22:46 p6eval joined
cotto_work or a complement? 22:46
dukeleto chromatic: i think it is important enough to have it's own file
kid51 dukeleto: Yes I like the idea of running 'make fulltest' at least once on each branch
dukeleto chromatic: but if you feel it fits better into another already existing file, go for it. But please commit that sooner rather than later 22:47
cotto_work kid51: I think it's silly we're not doing that already.
dukeleto cotto_work: it is, except that "make fulltest" takes an extraordinary amount of time for many people
cotto_work: not everyone has multiple cores and SSDs
chromatic I have no preference for where this document goes.
dukeleto cotto_work: "make fulltest" could take 30 minutes or hours depending on how old the machine is 22:48
cotto_work dukeleto: true. People on slow machines can ask for volunteers to run fulltest though.
dukeleto cotto_work: of course
cotto_work: i wasn't defending not running it, but just documenting *why* people don't run it
kid51 Note that I said: at least once per branch. i.e., I'm not expecting them to do more than once.
In point of fact, t/codingstd/perlcritic.t is the biggest time-sink there. 22:49
I used to dread 'make fulltest', but since we eliminated one core its something I just chuck into a screen session (on Linux -- it's still a multi-hour thing on my iBook) 22:50
cotto_work I <3 screen.
atrodo screen++ 22:52
dukeleto fulltest got a lot faster when me moved to Git, since I got to delete a lot of annoying svnprop tests 22:53
cotto_work Did those take long?
chromatic Longer than you might think.
IO is a bottleneck there. 22:56
dukeleto they took a really long time on non-SSD drives 22:58
22:58 rfw left
dukeleto every file in the repo had to have it's svnprops read, which is time-consuming 22:59
22:59 rfw joined
kid51 What's an SSD drive? 23:20
cotto_work solid state drive drive 23:21
no moving parts, *really* good seek time, quite expensive atm 23:22
dukeleto kid51: it makes git repos insanely faster
dukeleto used to wait 60seconds for a catalyst app to start, now it does it in 3s 23:23
the seek time of SSDs is way less than drives with moving parts
so if you are touching lots of files on the filesystem, they scream. 23:24
23:24 Matt221 left
dukeleto we could also setup a service for "fulltest" to be run on the GCC Compile Farm 23:24
we haven't used the farm at all, mostly because I am the only one that can do stuff on it, and I have been busy with git migration and lots of other stuff 23:25
but we need to use it
also, we don't have coverage reports anymore
aloha, coverage?
aloha dukeleto: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
dukeleto wait, we do!
looks like the coverage reports are talking to git
tapir2.ro.vutbr.cz/cover/cover-resu...2/c_cover/ 23:26
that is good to know
getting coverage reports for certain branches would be pretty killer as well
the String PMC has 83% coverage. That seems a bit too low for such an important PMC 23:27
that would make a good GCI task, to increase the coverage by 5% or so 23:28
NotFound Oh, is alive again? Hurrah!
dukeleto String PMC doesn't have any coverage for "set_bool"
and a bunch of others 23:29
I am going to add that as a GCI task, no one fix it yet!
NotFound dukeleto: set_bool is hard to cover, can't be done from pir
dukeleto NotFound: o rly?
NotFound: we can add a test from the embed interface
NotFound: correct?
String.substr has no coverage either 23:30
and cmp_num. These seem important.
NotFound dukeleto: there is a ticket about the substr vtable 23:31
Surely we can find a way to add a test for set_bool, but I wonder if we should just delete it instead. 23:32
dukeleto NotFound: do you think anybody outside of parrot uses it somehow? 23:33
NotFound: the only way to use it is from embedding, no?
NotFound: i doubt if PL/Parrot uses it. If it does it is on accident.
NotFound dukeleto: I fail to imagine why someone may be using it, but one never knows... 23:34
dukeleto NotFound: indeed. But now we can at least ack through github repos
NotFound: it would be nice to have a script that ack's through the repos of all known parrot projects and says "hey project X is using this thing that is on the chopping block" 23:35
that would be amazingly useful
NotFound dukeleto: aye
dukeleto perhaps that could live on the gcc compile farm. It wouldn't be very hard to do.
NotFound This is the ticket for substr: trac.parrot.org/parrot/ticket/1682 23:37
dukeleto just approved 5 parrot gci tasks and kicked off 1 more task claim request 23:39
someone finally took the "compare Neko VM to Parrot VM" task. I am interested to see what they come up with.
NotFound GCI is being very helpful, much more than I expected. 23:41
cotto_work dukeleto: that'd be amazingly useful. 23:42
It's a bandaid until we finally get deprecations right, but it's a really nice bandaid.
bacek_at_work dukeleto, Neko is stack based. Parrot is register.
One of Neko dev sitting just next to me ):)
cotto_work That's a difference.
bacek_at_work: steal his brane 23:43
NotFound bacek_at_work: you've failed the task, your report is too short ;)
bacek_at_work cotto_work, he refuses to join parrot. And continue LLVM based backend for Neko...
23:43 bluescreen joined
cotto_work Neko isn't entirely unlike what we want from lorito. 23:43
bacek_at_work: his loss ;]
bacek_at_work I think Lorito should be stripped down of current parrot. Register based, CPS. 23:44
May be without multi-dispatch.
lucian bacek_at_work: noooooooo :)
bacek_at_work Rakudo build own anyway.
lucian thinks single dispatch is a subset of multi dispatch, but not the other way around
cotto_work bacek_at_work: the current plan is for CPS and MMD to live on top of lorito. Are you thinking of something else? 23:45
bacek_at_work cotto_work, why? 23:46
I think CPS is core of VM.
MMD is not.
cotto_work Well, anything that's not directly in Lorito will have to be on top of it. 23:47
not necessarily at the same level
dukeleto bacek_at_work: yes, but we are going to get a GCI student to write about it :) 23:48
bacek_at_work I thinks CPS is in. It's just our way of invoking subs.
dukeleto just added a parrot gci task for increasing String PMC code coverage 23:49
fbrito wow, lots of new tasks :) 23:50
23:50 Matt221 joined
dukeleto fbrito: indeed. To keep you busy! 23:51
fbrito: just ping me if you are waiting on a claim request
fbrito: twitter is probably the fastest 23:52
dalek rrot: 8c3a723 | NotFound++ | t/pmc/mappedbytearray.t:
a bit more initial tests for MappedByteArray
dukeleto new string task: socghop.appspot.com/gci/task/show/g...9176557195
chromatic multidispatch at the core makes vtables much nicer
fbrito dukeleto: ok, but right now I am working on a task for Sahana Foundation :o 23:55
dukeleto fbrito: sounds good. I am going to create a huge backlog of tickets before I go on vacation :) 23:56
fbrito dukeleto: when are you going to vacations? if you are coming to Brazil, please let me know :P 23:57
dukeleto fbrito: i will definitely let you know if I am passing by :) 23:58
fbrito: visiting family in the US, this time. But I am sure I will visit Brazil someday. 23:59
bluescreen where are you fbrito? Buzios?

Powered by Cro and the Raku® Programming Language.

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

Thank you!