Priorities for this week: Pre-post/plan PDS topics & attend PDS; Damn the build, full Awesome ahead! | Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 26 July 2011.
02:01 bluescreen joined 02:05 bluescreen left 02:38 dafrito left 03:01 whiteknight left 07:33 eternaleye_ is now known as eternaleye 10:43 Felipe left 11:04 contingencyplan left 13:25 NotFound joined 18:40 moritz joined 19:22 contingencyplan joined 19:40 soh_cah_toa joined 19:47 particle1 joined, Coke_ joined, spinclad_ joined, Coke left, particle left, spinclad left, Tene left, tcurtis left, TimToady left 19:48 Tene joined 19:51 TimToady joined 19:52 tcurtis joined 19:56 kid51 joined 20:17 kid51 left 20:19 nbrown joined 20:37 pmichaud joined 20:51 mikehh joined 20:52 soh_cah_toa left 20:54 kid51 joined
kid51 PDS in 4 minutes in this channel 20:55
20:56 shockwave joined 20:59 Eclesia joined
kid51 Hello 21:00
moritz hi
Util Hello
kid51 Who do we have here?
shockwave hi 21:01
pmichaud present
cotto hi
Eclesia as a spectator only
mikehh hi there 21:02
kid51 We have a proposed agenda: lists.parrot.org/pipermail/parrot-d...06117.html -- mainly to provide overall structure. 21:04
NotFound Hola 21:05
kid51 Does anyone have additional topics which don't fit into that structure?
Okay, we can adjust as needed 21:07
cotto, do you want to proceed?
21:08 benabik joined
cotto kid51, go ahead 21:08
kid51 okay,
So, Part I of meeting is review since last PDS -- that in turn divided into review of roadmap goals and other 21:09
Let's have some comments on how we did or did not meet roadmap goals.
Benchmarking goal?
cotto It's better, but not where I'd want a roadmap goal to be. 21:10
kid51 can you provide details?
cotto We're slowly moving toward using benchmarks more extensively. 21:11
It hasn't become a regular feature of our development workflow though.
mikehh we were supposed to liase with HLL's on that 21:12
kid51 Did we encounter obstacles toward achieving this goal ... or did we simply not put enough effort into it ... or something else?
cotto who was on that goal?
moritz pmichaud++ has regulary (ie after each release, iirc) posted links to benchmarks 21:13
mostly NQP speed, which reflects parrot speed
cotto moritz, to parrot-dev?
moritz cotto: yes
21:13 benabik_ joined 21:14 masak joined, benabik left, benabik_ is now known as benabik
kid51 Hmm, consulting my post subsequent to May Summit, I see we never assigned specific people to that goal 21:14
Big mistake
pmichaud I don't think I've posted anything permanent since May.
I've run the benchmarks and reported them in IRC (both #parrot and #perl6)
kid51 pmichaud My hunch is that they might have greater visibility if posted to mailing list instead of ( or in addition to ) IRC 21:16
pmichaud kid51: sure... there hasn't been anything earth-shattering about them since May, though. 21:17
kid51 Perhaps outside of this meeting we can work out a standard reporting format, day of month, etc. 21:18
21:18 luben joined
pmichaud and they really are very coarse benchmarks, and they benchmark Rakudo primarily, not Parrot. 21:18
i.e., they show changes to the entire Rakudo+Parrot system
kid51 But it's a starting point, and a meaningful one
pmichaud fair enough. my plan is to post the benchmarks after each (Rakudo) monthly release 21:19
I'll update for the 2011.07 release and post to the mailing lists
cotto Thanks
kid51 Thanks, we can fine-tune from there.
Any other comments on Benchmarking goal? 21:20
pmichaud in some sense seeing those benchmarks will be very un-useful, though, because 2011.07 is the last Rakudo release based on the "ng" branch
i.e., when we get new numbers for 2011.08, we'll be able to say "hey, look how much faster (or slower) nom is than ng", but it won't say much about Parrot performance.
kid51 Understood. Parrot has to work out its own benchmark reporting, but the Parrot-HLL combination is also important 21:21
mikehh We really should have some form of standard parrot/HLL benchmarks that nedd to be run after changes - at least branch merges etc 21:22
need
benabik Ideally run _prior_ to merging the branch…
pmichaud lists.parrot.org/pipermail/parrot-d...06091.html is an example where I posted the benchmark results showing the impact of --optimize, for example
luben we have some microbenchmarks in examples/benchmarks 21:23
21:23 soh_cah_toa joined
kid51 mikehh, luben: Would you be able to work out some form of benchmark reporting that would server that purpose? 21:23
luben some of them are good - e.g. fib
kid51 s/server/serve/ 21:24
luben ok, I could check them and see what is still working
and prepare some scripts to run them all
with proper reporting 21:25
kid51 If we had something that, say, ran once a week and emailed parrot-dev, that would be a good start
cotto I'd love to see that happen. 21:26
pmichaud the scripts I created for rakudo benchmarking can easily do pure parrot benchmarking, fwiw
I just need the benchmarks :) 21:27
luben yes, I will look at them also
kid51 If that's the case, then we can simply continue this roadmap goal into the next quarter -- only this time with real people attached!
mikehh 'k, will also have a look at this
kid51 Excellent! 21:28
21:28 contingencyplan left
kid51 Can we move on to the Profiling roadmap goal? 21:28
Have we "studied our existing profiling tools, determined their strengths and limitations and developed a plan for significant improvements in later supported releases"? 21:29
cotto I don't think we can say that we have a solid plan.
kid51 What obstacles did/do we face? 21:30
cotto I think a significant part of it was communication.
21:31 contingencyplan joined
cotto Whiteknight and I both tried to set aside times to meet, but they never seemed to work out for various reasons. 21:31
NotFound Judging for the comments I've read, a problem is that tools and literature are call/return oriented and have impedance mismatch with continuation based style.
cotto NotFound, the awkwardness of building a profiler for CPS is part of it, but that's not an unfixable problem.
I suspect it would have been better if only one of us had taken it on then had the other one jump in when the time was right. 21:32
kid51 The need for better profiliing tools came from our users. See Item #2 at lists.parrot.org/pipermail/parrot-d...05410.html 21:34
I admit that for me profiling is an esoteric topic -- I've never even done that in Perl 5 -- but it was clearly requested by our number 1 HLL user. 21:37
cotto kid51, haven't you used Devel::NYTProf? 21:38
kid51 Is it simply an uninteresting thing to work on?
cotto: I know it exists, but I've never had to use it myself. 21:39
21:39 wagle left
cotto kid51, not so much uninteresting as awkward. It's hard to find an interface that feels natural. 21:39
21:40 wagle joined
kid51 Well, in pmichaud's original request, he indicated users would benefit from, at minimum, "some basic documentation and clear examples for using Parrot's profiling capabilities" 21:41
21:41 wagle left
kid51 ... that's even before we talk about improvements in what we already have. 21:41
What would it take to get us to that partial goal?
pmichaud can I interrupt for a sec on that? 21:42
cotto ok. that's maybe a couple hours straightforward of work on my part. pmichaud, do you have an example of the kind of documentation format that'd be most useful?
kid51 Yes
pmichaud, proceed
pmichaud what we really need is to know which Parrot-level subroutines are eating up execution time
i.e., how many times a sub is called, and how much time is spent in that sub
I don't know if the current profiling tools can reliably provide this. If they can't, then spending a lot of time documenting them doesn't really help me. 21:43
kid51 k
pmichaud in the past when I tried to use them, they gave nonsensical results.
it could be that they gave nonsensical results because I was using them wrongly. If that's the case, improved documentation is the answer. 21:44
It could be that they gave nonsensical results because they can't handle the types of code execution paths present in NQP and Rakudo (and possibly even Parrot). If that's the case, improved documentation won't help at all.
end of interruption
cotto pmichaud, the current profiling runcore should be able to provide sub-level timing information. I'll look into it as I'm writing the documentation.
pmichaud, what format would you prefer? 21:45
pmichaud cotto: anything is fine, really
I know that the tools have been using kcachegrind, and that works great if it's reliable
cotto Getting kcachegrind to work will take some fiddling, but there are simpler cli tools that should provide something useful. 21:47
pmichaud sure. I can probably do with anything if I just have an example of how to use it.
kid51 cotto, how long would you need to do some improvements in the documentation, and could other people work on some aspect of this?
pmichaud as an aside, since we control the opcode dispatch, it seems like it ought to be really simple to assign the cost of each opcode invocation to the "current sub" in the interpreter.
that would help to avoid trying to figure out the call stack 21:48
maybe. I'm not a profiling expert. :-)
cotto kid51, depends on how you define "improve". I can get something useful in a few hours.
21:49 soh_cah_toa left
kid51 cotto: My thinking is: Let's get something written in, say, next two weeks, that provides incremental improvement that pmichaud can work with. I know you'll want to be focusing on other things, so I wouldn't expect a big time commitment from you on this now. 21:50
If it turns out that what he have now, even with better documentation, is of no benefit to users, then at least we'll know that and can evaluate next steps then 21:51
cotto It's something that I can work on when I don't feel like I'm being productive on M0.
that'll be progress
shockwave I'd like to discuss windows support.
cotto shockwave, don't worry. We will.
kid51 shockwave: The first part of the meeting is review of last 3 months. 21:52
shockwave I have to log off, soon :(
cotto just a bit later in the meeting, I think.
kid51, do you mind switching it around then?
(it being the agenda) 21:53
kid51 shockwave: Could you post two sentences now about your concerns? We'll take them up later but not discuss them in detail now.
shockwave ok
I have a compiler which runs on both Windows and Linux. Parrot 3.6 is supposed to be a 'supported' release, but it doesn't not compile with Visual Studio 2010, on Windows 7, 64bits. 21:54
I need this
pmichaud shockwave: what version of Perl, ooc? 21:55
21:55 soh_cah_toa joined
shockwave ActiveState, 5.12 21:55
kid51 Okay. The specifics of why a specific Parrot release is not building on a specific platform can be handled out side of #parrot.
pmichaud
.oO(outside of PDS, perhaps?)
 21:56
kid51 Assuming we adopt the roadmap goal proposal, we'll be interviewing you (shockwave) and others as to your specific needs for parrot-on-windows
shockwave Well, what I'd like to know is: Is Parrot officially supported on Windows or not?
kid51 shockwave: It is supported, but we acknowledge that the terms of that support need sharpening.
We're going to be discussing that later in meeting.
NotFound "officially" means almost nothing. These are practical problems. 21:57
pmichaud shockwave: I'll be glad to discuss it with you on #parrot right now so PDS can continue on its agenda, if you like.
shockwave ok
thanks
21:57 shockwave left
kid51 NotFound: Fine, but this meeting is not the right context for the very practical problems 21:58
NotFound kid51: My point is that "official" declarations are useless.
kid51 Okay, back to Q2 roadmap goals: Our 3rd goal was "need for Parrot and Rakudo to have relationship managers"
21:59 wagle joined
kid51 I believe we can say that this goal was met. 21:59
cotto I'd say so.
kid51 Any comments on that?
cotto Fortunately the role didn't require too much use.
pmichaud I still need to publish the document into the rakudo repository, but yes, we met the goal.
cotto i.e. there weren't too many problems that required escalation 22:00
kid51 So at this point we're open to discussion of other Parrot developments in the May-June-July period.
Anyone want to speak about topics such as M0? GSOC? Parrot at conferences? 22:01
cotto I've blogged about M0. I don't think it needs much discussion here, but strategic questions are welcome. 22:02
kid51 GSOCers or GSOC mentors: Anything to report? 22:03
soh_cah_toa yes 22:04
kid51 proceed
soh_cah_toa maybe i emailed parrot-dev a little too late but i'd really like to talk about the state of imcc
it's seriously crippling my gsoc project but that aside, i feel it is a very real danger 22:05
i mean, it's a really big part of parrot that is just sitting and rotting
i just don't understand why it isn't considered a high priority item 22:06
22:06 Eclesia left
kid51 soh_cah_toa: A partial refactoring of IMCC was a Roadmap goal for Q1 of this year. 22:06
And work was done on it by whiteknight and (IIRC) bluescreen 22:07
soh_cah_toa ok, i think i missed that one
NotFound soh_cah_toa: the problems are deep, much of the work whiteknight has been doing is oriented to that goal.
cotto soh_cah_toa, up until now it's been non-fatally bad.
nobody likes it, but we've been able to make it do what we need.
soh_cah_toa well now it is: it's fatal to my gsoc project
i truly feel that a debugger is impossible with imcc as it is now 22:08
NotFound soh_cah_toa: What are the blocking problems?
soh_cah_toa it doesn't generate ANY accurate info about compiled pir files
pmichaud that's certainly true. 22:09
well, may it has some accurate info, but much of it is inaccurate. 22:10
*have
cotto very low signal/noise ratio
NotFound Inacureate to the point of being completely unusable?
pmichaud I know to generally ignore the line numbers produced in error messages.
soh_cah_toa NotFound: for me, yes
benabik The file and line annotations are often wrong.
soh_cah_toa always wrong 22:11
literally
pmichaud lately they've been wrong more often than not.
benabik File is only wrong when using a PBC made with pbc_merge, I think.
NotFound Not always. Winxed programas usually report the throwing point accurately.
pmichaud I'll sometimes look at the PIR source to see if I can find the error... but generally I don't even bother to do that anymore 22:12
Util Even if PIRATE (or whatever the latest IMCC replacement candidate is named) is not yet ready for production use, perhaps it is far enough along as to let the debugger be built for it, rather than for IMCC.
soh_cah_toa and i think hll's developers like you ^ shouldn't have to do that
kid51 Are we talking about both the current debugger and hbdb (soh_cah_toa's project)?
pmichaud kid51: we're talking about *imcc* itself, no debugger.
at least, that's what I've been referring to. 22:13
NotFound Last time I used the current debugger was more than a year ago.
soh_cah_toa i don't think PIRATE has even had a commit in several months
though i hadn't checked in a while
mikehh some work was done on that by Paul_the_Greek I think, but then he dissapeared 22:14
cotto It will need significant updating, and it wasn't complete when bacek last worked on it.
kid51 It seems like benchmarking-profiling-debugging is a constellation of developer tools that Parrot has somehow managed to do without :-(
soh_cah_toa kid51: bingo!
NotFound Debugger more or less worked some time ago. I located several hard problems using it, in spite of its poor functionality. 22:15
kid51 NotFound: Can you estimate when it was last of some use? 22:16
NotFound More than a year ago.
mikehh there have been some major changes to IMCC sinc it last worked 22:17
since
kid51 Is it possible that those changes to IMCC, while being an improvement overall, were bad for any debugger?
mikehh yes
cotto imcc line numbers have pretty mediocre test coverage 22:18
NotFound Most of the problem is that the debugger was not kept in synch with other changes, I think.
kid51 Alright, I have a suggestion
Since whiteknight is not here, I'm going to volunteer him for something :-) 22:19
cotto I hope in involves buying a house.
kid51 I know he'll be very interested to get going on importing 6model into parrot
But since he was involved in last major work on IMCC, I'm going to ask him to pause and look at whether/how current IMCC impedes debugging, both current and hbdb 22:20
In other words, we're going to ask a specialist for a consult
soh_cah_toa that. would. be. wonderful.
kid51 Something quick enough that it is useful for soh_cah_toa's GSOC. 22:21
cotto We know how it impedes debugging. It has fictitious line numbers for pir files.
Fixing it is the hard part.
soh_cah_toa i could also use line #'s to opcode mapping
kid51 So, would that consult not be useful?
soh_cah_toa but i'll talk to whiteknight about that
NotFound I'm thinking we need a tool to verify pir info and annotations in PBCs. I'll try to write something. 22:22
cotto soh_cah_toa, that won't work. PIR ops don't always map 1-1 with the actual ops.
soh_cah_toa not necessarily one-to-one it could be one to many
whatever it is. some mapping 22:23
some way to relate the two
kid51 So, can I make a second suggestion? 22:24
NotFound Note that we still have a problem to annotate the start of a sub
soh_cah_toa as many as you want! :)
kid51 2nd: cotto and NotFound: After this meeting can you do a quick write-up on IMCC that enables us to adjust our expectations for what soh_cah_toa can and cannot accomplish in his GSOC? 22:25
NotFound An annotation before .param works since some recent change from plobsing, but fails with methods because of the way of handling 'self'
kid51 Such a write-up would serve as an early draft of a 4th quarter roadmap goal on IMCC, perhaps 22:27
cotto right now, I think single-stepping through instructions and stopping when entering/leaving a sub should be reasonable goals that imcc doesn't impede.
22:27 cotto left
soh_cah_toa i agree, that problem is on my end 22:27
22:28 cotto joined
NotFound The main feature I used in its time was just run n opcodes, without caring about pir o hll files or numbers. 22:28
That allowed a quick location of the exploding point by bisection on n
cotto I'm sure soh_cah_toa is already pretty familiar with what imcc prevents. 22:29
soh_cah_toa yes
kid51 I'd like to move forward with the agenda. cotto, NotFound and soh_cah_toa: I think you can put your heads together and write up a more complete diagnosis that can both give Parrot project guidance on IMCC as well as on Kevin's GSOC 22:30
soh_cah_toa yes
cotto wfm
NotFound ok
cotto soh_cah_toa, can you start a gist (or something) of what imcc has prevented you from doing? 22:31
kid51 Thanks. Any other items about past quarter need discussion? If not, we'll move on to Part II.
soh_cah_toa sure
cotto We can use that as a starting poing.
*point
kid51 Okay, let's move on to Part II. Going Forward. 22:32
Again, divided into two parts.
1. 3Q roadmap goals
2. All other goals and plans.
We had posts for 3Q roadmap goals on parrot-dev on the following subjects: 22:33
* M0
* 6model
* Sharpen Windows support
* User-facing application
Does anyone wish to enter any other topics for consideration as 3Q Roadmap Goals? If not, we'll proceed to discuss them in that order. 22:34
NotFound I have one: NCI and string encodings, but lacked the time to write something about it.
kid51 Okay, we'll see if we can discuss that after the 4 above.
Any others? 22:35
cotto: Can you discuss why/how M0 as roadmap goal for 3.9 (Oct)? 22:36
cotto Sure.
Why: The long-term plan is to replace much of Parrot's C internals with M0. Making sure it's a solid foundation is a priority. 22:37
The how is specified in brief detail in the blog entry I posted to parrot-dev: reparrot.blogspot.com/2011/07/m0-ro...-2011.html
soh_cah_toa this term is used a lot: what exactly is "parrot's internals"? 22:38
kid51 Can you briefly list here things you feel you can safely accomplish by 3.9? 22:39
cotto I hope that by 3.9, we have M0 linked and distributed as part of libparrot and ready to start being used.
soh_cah_toa what areas of "parrot" does m0 affect?
NotFound libparrot, mostly.
cotto soh_cah_toa, in this case anything that's implemented in C, probably excepting GC
benabik To be clear: M0 will be what parrot is written in, not primarily what HLLs will use, yes?
kid51 Who can work on a team in support of this roadmap goal?
cotto benabik, correct. PIR will continue to work with no changes (or very few). 22:40
dukeleto and I will continue to work on it. Others have expressed some interest too.
sorear and atrodo come to mind
kid51 cotto: Any one in particular? (You, dukeleto and whiteknight were spread too thin in past quarter, IMO) 22:41
cotto I don't know if sorear would want to be on the team officially. Either way, I haven't asked him. 22:42
same for atrodo
sorear Hi
cotto hi sorear 22:43
kid51 Well, we know that you and dukeleto have already committed to it, so we have the two-minimum needed for roadmap status. But it would be great if we can improve the bus factor.
cotto Of course, contribution from people who aren't officially on a team are very welcome.
agreed
kid51 cotto: Would you accept as phrasing for the goal: "M0 linked and distributed as part of libparrot and ready to start being used" ? 22:44
cotto for the stage that M0 is at where it needs a great deal of active design work, the synchronization between more than 2-3 people could start to become an impediment.
"a portable C implementation of M0 linked and distributed as part of libparrot and ready to start being used" 22:45
kid51 okay.
Does anyone object to designating M0 as roadmap goal for 3.9: "a portable C implementation of M0 linked and distributed as part of libparrot and ready to start being used"; cotto, dukeleto, et al ? 22:46
cotto I think once the M0 spec is final, it'll be easier to bring more people in. I always welcome feedback and suggestions, I just don't want to get bogged down.
kid51 Next pre-posted proposal for roadmap goal ...
6model
whiteknight not present, but posted here: lists.parrot.org/pipermail/parrot-d...06104.html 22:47
cotto, others: Discussion of that post? 22:50
cotto: Specifically, how does development of 6model in parrot interact with development of M0?
cotto kid51, 6model will need to be our core metaobject model before we start moving that part of the code to M0. 22:51
That stage is still a ways off, and given that whiteknight is committed to 6model, I don't think it will end up being a blocker.
Tene You might want to ask jnthn, who is on irc right now.
kid51 So, does that mean we have to get 6model in before what you are hoping to do with M0 for 3.9?
cotto (I'm also interested in 6model, but hoping that others will volunteer) 22:52
kid51, no
NotFound I think the development of 6model, or any other alternate object model, will be good, because it will allow to clean the coupling to implementation details of Class and Object PMCs from an unknown number of point in the codebase.
benabik is interested in M0 and 6model, but doesn't want to volunteer for anything before GSoC end.
kid51 NotFound: Are you interested in being on a team with whiteknight for 6model?
cotto 6model needs to happen before the "pervasive integration" step in my blog post, but I don't picture that happening before 4.0, probably later.
Tene is interested in 6model, but hasn't usefully contributed in years, so can't commit to anything. 22:53
NotFound kid51: yes
benabik is heading AFKish for dinner, will check backlog and keep an ear out for mentions.
kid51 NotFound: great. That means we can elevate that to roadmap goal status
cotto NotFound++ 22:54
kid51 NotFound: Any specific reactions to whiteknight's post?
22:54 benabik_ joined, jnthn__ joined
Tene jnthn__: 16:50 < kid51> cotto: Specifically, how does development of 6model in parrot interact with development of M0? 22:54
Or, you could just look at the logs, I guess. 22:55
NotFound kid51: nothing in particular.
kid51 Okay, then we can promote initial integration of 6model into parrot as roadmap goal for 3.9 (Oct), with whiteknight and NotFound leading the way. 22:56
GSOCers eligible to join the team after completion of projects.
3rd pre-posted roadmap goal: Sharpen support for Parrot on Windows.
NotFound Better whiteknight leading and me following him ;) 22:57
jnthn__ Since 6model is currently exposed as bunch of C files + 2 dynpmcs (soon to be 1) and some dynops, getting it into Parrot should in theory not be too bad.
Getting it used in place of Parrot's current object model will be the challenge
cotto indeed
jnthn__ Since it needs to supplant PMCs, not be a PMC.
kid51 Goal 3 was proposed by me here: lists.parrot.org/pipermail/parrot-d...06098.html 22:58
NotFound I'd prefer to start by using it in addition of current model, not replacing it.
jnthn__ NotFound: Yes, that'd be the way to start.
Or maybe we just tell people to migrate and make that easy.
That's for Parrot folks to decide though. 22:59
NotFound That way will help to clean the undesired coupling of some internals.
jnthn__ 6model doesn't tie you to one approach or the other. Heck, it doesn't tie much to anything. :)
cotto I think that implementing 6model outside of PMCs will be much more natural than doing so in terms of PMCs.
NotFound Or maybe we can reimplement the current model based on 6model. 23:00
cotto but I haven't tried yet.
NotFound, that's my understanding of the plan
NotFound What do you mean by "outside of PMCs"?
jnthn__ cotto: The only reason there is a PMC at the moment is because that's the only way to expose something in Parrot. 23:01
cotto right
jnthn__ cotto: s/PMC register/Object register/ is where you'd want to end up, perhaps.
Don't need to rename it, more just the mental shift. 23:02
NotFound Better not to rename it while we still have the 'Object' PMC around. 23:03
kid51 Can we move to the remaining goal proposals?
23:03 benabik_ left 23:04 benabik_ joined
cotto sure 23:05
kid51 So the proposal re sharpened focus on Windows arose out of the difficulty of getting consistently PASSing smolder reports from Win32 boxes in the weeks prior to 3.6 release.
The proposal is mainly one of *research*. 23:06
It does not entail writing any code.
It does not entail requiring anyone not currently developing or testing on Windows to begin doing so.
It does require team members to conduct research among Parrot's current developers, our current HLL and other users, and some potential users into questions like: 23:07
On what Windows configurations can be get Parrot to configure, build, test and install?
Can we set up smoke testers for those configurations?
What do we have to know about people who develop on Windows, including professionally, need in order to look seriously at an open-source project? 23:08
I, myself, have never been a professional software developer on Windows ... 23:09
... and the newest version of Windows in my house pre-dates the Parrot project.
NotFound Some of the problems with testing aren't windows exclusive. For example, the ability to create hard or symbolic links depends on the filesystem used in the build tree ot in the temp directory.
kid51 So while I can be part of a team conducting these inquiries, I cannot be the team itself.
NotFound, true we have a long-standing Trac ticket about that 23:10
NotFound The problem is that we are spending much effort is special casing the tests than in the functionality.
soh_cah_toa NotFound: agreed. had that problem w/ openbsd as well
kid51 NotFound: Hopefully, part of the end-product of this goal's work would be a document identifying what's specifically a Windows problem and what's not. 23:11
The sort of issues we referred to #parrot for shockwave an hour ago are the sort of topics such a team would want to research 23:13
NotFound A simple research for those with appropiate windows platforms available is to build using different kinds of filesystems and compare the test results. 23:14
kid51 Well, since people are not clamoring to jump on board, I don't think this is ready for Roadmap Goal status. I'll open a Trac ticket. 23:15
The final pre-posted proposal for Roadmap Goal came from dukeleto.
"user-facing application to attract people to Parrot" -- [my paraphrase, probably not accurate] 23:16
Util I support this as a Roadmap Goal, but since I start a 9-month contract on August 1st, loaded heavy in the early months, my tuits will be much lower during this quarter.
(the Win32 goal)
I could take it on next quarter.
kid51 Util++ I will be in contact
Util OK
soh_cah_toa yeah, i was curious about that. what exactly is a "user-facing application"? 23:17
kid51 cotto: Earlier you had some thoughts about this proposal ... can you share?
NotFound I think it's a good goal, but having a "killer app" is the desire of any emerging platform, hardly a roadmap item.
cotto kid51, I want all of us to be thinking about what Parrot's strengths are and what kind of tool or application can be built on top of it that would be Parrot's killer app, i.e. the thing that gives people a convincing reason to care about Parrot. 23:18
kid51 (This was duke's original post: lists.parrot.org/pipermail/parrot-d...6097.html)
pmichaud from a 'disruptive technology' perspective, it means we need to find the people that would benefit from Parrot, as opposed to trying to compete with established players. 23:19
s/players/products/
NotFound For example, a new spreadsheet will probably not be a good idea ;) 23:20
kid51 NotFound: Agreed (on the hardly a roadmap item thing)
pmichaud a 'killer app' is a product that jolts an industry. while that would be great if we find one, our sights should probably be set on simply finding people who have problems that parrot can solve in the short-term, then using that to leverage into other areas
cotto I don't mean to suggest it as a roadmap item, just as something to be thinking about. 23:21
soh_cah_toa well being a virtual machine, aren't the only people who would care about parrot be hll developers?
pmichaud soh_cah_toa: could be the people using products on top of parrot
Tene I still think that HLL interop and good compiler building tools is the most appealing part of Parrot's potential.
soh_cah_toa was just gonna say that :) ok
kid51 soh_cah_toa: mod_parrot, for example, was a product built on top of Parrot that wasn't a language (AFAIK) 23:22
Tene long-abandoned
soh_cah_toa ah, i see
i think we didn't sorta talk about this a while ago. looking for placed parrot could be embedded
*did
kid51 It's been abandoned for two years. If anyone wanted to resurrect it, I think we would be supportive, even if it didn't become part of our roadmap 23:23
NotFound An idea for people interested in the NoSQL field: make the first working implementation of UnQL.
kid51 Well, it seems like we are segue-ing into the final part of the meeting: Things people want to do with/on top of Parrot outside of roadmap goal items. 23:24
Part II. B., for those who are following along at home.
Are there other things that people are planning to work on in the next 3 months that we have not already named? 23:25
NotFound I've been doing some work towards bindings for libxml2 23:26
kid51 Can you blog about them? 23:27
kid51 notes that earlier we should have mentioned advances in Winxed as significant development for Parrot in Q2
23:28 benabik_ left
NotFound kid51: probably, but I'd like better to do it after cleaning the nci-string encoding issue. 23:28
23:28 benabik_ joined
kid51 Do you want to say anything about NCI-string encoding now? 23:29
Util must leave now; will backlog; apologies to all.
NotFound In short: we need a clean way to get strings with the desired encoding from char * or char arrays got from NCI.
Using the platform encoding detected at startup time is not enough. 23:30
A method un UnManagedStruct, for example, will do the job. 23:31
Of course is dangerous and error prone, but no more than any other usage of NCI. 23:32
Use cases I have in mind: MySql and libxml2 23:33
kid51 So, can I ask that you post more about this on parrot-dev or your blog so that we can build up wider understanding of the issue?
NotFound I'll try to write something during next week. 23:34
kid51 NotFound++
I've pasted here: nopaste.snit.ch/66074 23:35
A rough draft of summary of discussion of Q3 roadmap goals.
23:35 masak left
kid51 Can people take a quick look and see if there's anything wrong/incomplete with it? 23:35
And are there any other Parrot policy or Q3 planning issues we should discuss here? 23:36
NotFound Now that I think about it: we have a complain from an user about lack of support for iso-8859 variants.
kid51 Did that make it into a TT? 23:37
NotFound Specifcally, the euro symbol variant.
kid51 vaguely recalls that as well.
cotto me too
NotFound No, I think it was just a message in the mailing list.
cotto I thought I had a branch
kid51 comments.gmane.org/gmane.comp.compi...devel/5784 23:40
Can someone convert that into a Trac ticket?
NotFound I'll do it.
kid51 Gracias 23:41
I mean, thanks.
NotFound De rien
kid51 Any other business? Otherwise, I'd like to hear a motion to adjourn.
Alright, let's call it a wrap. If you have comments on paste 66074, paste them in this channel; I'll consult before doing a write-up for parrot-dev 23:43
cotto Let's adjourn.
thanks, kid51
soh_cah_toa kid51: yeah, nice job 23:44
23:50 eternaleye left 23:51 eternaleye joined 23:52 soh_cah_toa left, benabik_ left 23:53 kid51_ joined, kid51_ left 23:56 kid51 left

Powered by Cro and the Raku® Programming Language.

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

Thank you!