Meeting time moved 1 hour earlier ! | Priorities for this week: Tests for distutils; no dogs on fire | 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 5 July 2011.
00:51 contingencyplan left 01:23 whiteknight left 02:24 kid51 joined 02:59 kid51 left 05:18 contingencyplan joined 05:32 contingencyplan left 09:45 mikehh joined 09:59 contingencyplan joined 10:06 contingencyplan left 11:36 PerlJam left, tadzik left, Util left 11:46 PerlJam joined, tadzik joined 11:47 Util joined 12:44 bluescreen joined 12:50 PerlJam left 12:52 PerlJam joined 14:27 Coke left, Coke joined 14:41 PacoLinux joined 14:52 PacoLinux left 16:35 darbelo_ joined, darbelo left 16:49 benabik joined 17:01 contingencyplan joined 17:18 atrodo joined
dukeleto What I did: 17:40
* Hacked on parrot-libgit2, which now has passing tests thanks to plobsing++ github.com/letolabs/parrot-libgit2
* Finished my TPF grant and wrote a blarg toast: leto.net/dukeleto.pl/2011/07/a-fina...pdate.html
* Attempted to get PL/Parrot compiling on Parrot master and Postgres 8.4.8 and failed.
* Added some code coverage to the new Embed API
* Started gathering information about Parrot + Parrot Foundation to apply to Software Freedom Conservancy
* Closed some Trac tickets that were no longer valid
What I will do:
* Attempt to get PL/Parrot compiling again
* Write a test to show how to use libgit2 from Winxed
* Send an email about GSoC midterms, which are due soon 17:41
* Planning on writing a Hague grant for PL/Perl6
Blockers:
* Only 24 hours in a day
* Summer
.EOR
17:44 NotFound joined 17:47 whiteknight joined
whiteknight WHAT I DID: 17:48
* Merged whiteknight/packfilewrapper branch, and put out fires immediately thereafter.
* Created a new branch whiteknight/pbc_pbc to start cleaning up the packfiles system, removing cruft, and adding some new interfaces that we should be migrating to over time.
* Commented on several tickets, most at the nudging of kid51++
* Created new tickets to deprecate do_sub_pragmas and associated nonsense, the load_bytecode_p op (to be replaced in my new branch by load_bytecode_p_p). Since replacements aren't in master now, we aren't going to put the deprecation notices in before the release
* Been trying to diagnose and fix windows test failures. We're down to t/library/nciutils.t (TT #2150) and t/dynoplibs/debug.t failures. The nciutils ones are figured out, the debug.t one is not.
* Worked on new Rosella Template library, for doing text templating.
* More work and planning on possible PCC refactors. I have a new writeup to post to my blog soon, and am planning to start a new branch soon to add in the new features so we can start deprecations and migrations.
* More planning for 6model. Have some things to follow up with there, will blog and bother jnthn__++ in the near future about that.
WHAT I WILL DO
* Try to find a good stopping point on whiteknight/pbc_pbc branch, and get it ready to merge shortly after the release.
* Probably start a new branch for PCC refactor work and experimentation
* Several Rosella feature requests. Work more on Template library, and maybe the Benchmark library too.
EOR
17:57 bubaflub joined
benabik DID: 17:59
* Finished a bloggy post: parrot.org/content/gsoc-7-what-newpost
* Merged a couple weeks of master, including pmichaud's updates
* Tested my branch on NQP and nom
* Fixed DESTDIR install of NQP
WILL DO:
* Add a pbc phase to PCT::HLLCompiler
* Make PAST tests run against both PIR and PBC generation
BLOCKERS:
* Lack of central air (It's hot!)
EOR
18:12 rohitnsit08 joined 18:29 bluescreen left
cotto_work *did: 18:31
- benchmarked, improved and merged an hll map optimization suggested by jnthn++ and implemented by NotFound++
-- simple for loop in Rakudo is ~2.4% faster
- M0/mole progress:
-- mostly thinking
-- got a couple new volunteers from chromatic++'s blog post
-- misc spec cleanup
-- found a batch of holes in the M0 spec; not quite done yet
- profiling
-- caught whiteknight, brainstormed for a bit
*todo
- finish M0 spec, get implementation in sync with changes
- get a coherent plan for profiling
- specify mole more completely, write an introductory doc
*eor
18:34 lucian joined 18:44 bluescreen joined
rohitnsit08 DONE 18:51
** support for basic operations
** support for nested Subroutines
** code refactor,removing dependencies of commonjs library
* WILL DO THIS WEEK
** Object system is in the process. 18:52
** restart work on test-suite.
**
* ROADBLOCKS
** implementing scopes and closures.
Coke rohitnsit08++ 19:01
19:02 pmichaud joined, kid51 joined
kid51 kid51's report 19:03
I actually composed my report last night but left it at home on my laptop.
Most relevant part: Via my count, we reduced Trac tickets from 514 to 507.
Am planning for next week's release and presentation at FOSSCON weekend thereafter. 19:04
We need to reduce number of failing tests on Windows as much as possible prior to 3.6 supported release.
EOR for now
lucian lucian's report: 19:05
Done: very little, ran out of money and had to get a temporary job 19:06
mostly real-life stuff
Will do: should have enough time from now on to work on the compiler
have to fix some object system bugs
EOR
NotFound What I did: 19:09
-parrot
* A bunch of miscellaneous improvements: optimizations, dead code deletion
and warning avoiding.
* Updated the winxed snapshot and added a minimal test for it.
-winxed
* Merged include branch.
* Change handling of builtins: now they are looked up like common functions.
* Added builtins trans_encoding, encoding_name, unescape, getcontext,
keyed get/setattribute 19:10
* Fixed and improved encoding handling in sources.
* Indirect attribute access: object.*"attribute"
* Improved checks for non-lvalues.
* for .. in loop now check for nullness and skip the loop in that case.
* Optimize out dead code for loops with always false conditions.
* Several minor refactos and fixes.
What I will do:
* Start winxed version and release numbering.
EOR
bubaflub DID: 19:25
Finished parrot-gmp VTABLEs
Updated some docs
Loads of tests
WILL DO:
Generate NCI thunks to remove libffi dependency
EOR
tcurtis DID: 19:26
* Lookback sets
* Forgot to blog
* Reread part of "Practical Translators for LR(k) Languages"
WILL DO:
* Really blog
* Midterm evals
* Fix bugs.
* Implement various simple transformations that are necessary to get the DPDAs to actually work.
* Comments/tests.
* Write a DPDA interpreter.
EOR
Addendum to report: also WILL DO: pick a time block and devote that time block every day to GSoC work. EOA 19:27
cotto_work hello 19:29
bubaflub hello
NotFound Hola
whiteknight hello
atrodo howdy 19:30
benabik #phasers note: Looks like first nom release will be early August.
Hello
Util Hello # late for pre reporting :(
cotto_work benabik: thanks. 19:31
How'd this week go?
whiteknight busy
rohitnsit08 hello
kid51 Net reduction in # outstanding tickets by ~ 7
cotto_work windows problems look like they're getting some attention. Is it enough?
kid51 No.
whiteknight We're getting attention on it 19:32
kid51 We have considerable variation among the various Windows smoke testers with respect to which files/tests are failing.
whiteknight It's not a matter of "breakage" per se. It's a matter of parrot's default semantics being too linuxy
benabik I'm putting in a bigger hard drive and will put Win7 on it after next OS X release. I can start trying to do testing on it.
Util I am tackling mappedbytearray.t failure, and will be running more smoke on Win32
kid51 We need a plan as to what constitutes "good enough" for 3.6
whiteknight we're relying on unix default behavior, which windows does not support
cotto_work whiteknight: that's not surprising, but also lta
whiteknight kid51: all existing tests pass
anything less isn't good enough 19:34
there's a legitimate question here whether code needs to be added or whether tests need to be deleted. Either could happen to resolve this issue
cotto_work whiteknight: +1. Either we support it or we don't. 19:35
NotFound MappedByteArray worked fine in windows whan I implemented it.
Util NotFound: With MinGW? 19:36
NotFound Util: Strawberry perl 19:37
whiteknight cotto_work: yeah, that's the question. We just have to figure out if we want the behavior that the tests specify, or if we do not
19:38 darbelo_ left
Util MappedByteArray works fine if you create the object, then .open , but fails on Win32 if you specify the filename *while* creating the object. 19:38
kid51 whiteknight: Have you filed a Smolder for "all existing tests pass"?
Util I think that the #ifdef offers no codepath in that situation.
NotFound Sigh... Starting again my old XP home... 19:39
kid51 The other question which we need to ask is: What does Rakudo need in terms of a parrot that builds on Windows?
Util NotFound: Sorry, but I am not the first one to see smoke on this.
whiteknight kid51: I'm not syaing all tests pass. That was my reply to you asking what constitutes good enough
kid51 oh
whiteknight kid51: it is only good enough once all existing tests pass
kid51 There was one smoke report today on Windows which showed fails in only two files. 19:40
That's great ... but what do we do if we cannot reduce that to 0 by next Tuesday?
NotFound What bothers me is: if so many people is interested in using parrot on windows, why no one cares of fixing it?
kid51 NotFound: I think it's more the case that we know Parrot's users (HLLs) must have their programs working on Windows 19:41
cotto_work using software in Windows is much less painful than developing, for the linuxy way we develop
pmichaud Rakudo only needs the parts of Parrot that it uses to work on Windows. The parts of Parrot that Rakudo doesn't use don't have to work on Windows for us to be able to run on Windows. 1/2 :-) (yes, I know, it's a circular answer, sorry) 19:42
NotFound If people this days have forgotten how to program Windows in C, tell them to port parrot to C# or something.
kid51 Well, my needs are very concrete here: [more] 19:43
1. Next week we have quarterly supported release.
Util I care about fixing Parrot on Win32 ...I just get seduced by the Mac side :)
kid51 2. I am Release Mgr
3. I don't have Win box or Win32 expertise.
4. Hence, I can't be the person to do last-minute fixes to get tests to pass on Win32.
5. Hence, alternatives needed.
Are there any recent release managers on channel who can say what we did for, say, 3.0 or 3.3? 19:45
whiteknight We'll get it fixed. There are relatively few failures and the paths to solutions are well mapped 19:46
cotto_work I don't think we had the same failures.
whiteknight the bigger question is how we resolve this issue so we aren't finding last-minute test failures on windows a week before the next release
cotto_work I tend to agree. There aren't so many failures that we should expect to have trouble fixing them. 19:47
whiteknight more windows smolder bots would be awesome
kid51 whiteknight: This is in large part due to Smolder having been down for most of 2 months.
whiteknight has already opened a ticket re t/library/nciutils.t
whiteknight the t/dynpmc/debug.t failures are ugly, but the debugger is basically a hollow shell at this point and I'm willing to nuke the test if necessary. The nciutils.t test is easily solvable, if we can make up our minds how to solve it 19:48
I'm inclined to rip out the offending nciutils.t tests for the release, if we can't sort out the underlying design issues
NotFound whiteknight: Have you seen my last comment on the ticket?
kid51 t/dynoplibs/debug.t also has failures, but if we could get that one done, then Ron Blasch's smoker would be PASS
whiteknight NotFound; yes, already tried it
None of the functions I've seen let you search for a function in the entire process, only in individual modules 19:49
we can loop over all modules in the process, but that requires some ugliness 19:50
kid51 pmichaud: Does Rakudo have someone who regularly tries to build Rakudo on Parrot HEAD on Windows?
pmichaud kid51: afaik jnthn is our own regular Rakudo dev who works from windows 19:51
s/own/only/
I don't know how often he builds against Parrot master HEAD
kid51 cotto, whiteknight: Could you contact jnthn to see if he's in a position to test Rakudo on parrot head on Windows over the course of next week? 19:52
whiteknight sure
pmichaud I can tell you he won't be -- he's going on vacation starting Thurs 19:53
kid51 damn
pmichaud we might be able to get him to do it today or tomorrow
Util pmichaud: what is param in the new build code to allow auto-getting parrot-HEAD?
kid51 pmichaud: That would be very helpful.
pmichaud Util: it only works for nom, atm. It's --gen-parrot=master 19:54
Util pmichaud: thanks
pmichaud Rakudo master doesn't have an equivalent param yet.
kid51 My hunch is that, for 3.6 purposes, we need to designate one particular Win32 box as canonical and work to get both Parrot and Rakudo PASSing on that box
Ideally, that would be jnthn's box, 'cause he's the User. 19:55
cotto_work I can test on windows as needed. 19:57
kid51 cotto_work: Great ... and can you debug there as well? 19:58
cotto_work at a basic level, yes
kid51 cotto_work: Could you see if you can tackle the fail in debug.t? 19:59
NotFound Real programmers don't use debuggers, they fprintf stderr ;)
cotto_work I'm looking at the streams.t failure now.
kid51 k
cotto_work The failures will get the attention they need.
kid51 general: Any fixes you do, please make sure they continue to PASS on *nix, of course. 20:00
cotto_work *nix failures are generally hard to miss
kid51 Well, I just don't want someone committing to master without remembering to test in both environments 20:01
Between now and next Tuesday, commits to master should be sparse unless they fix test failures. 20:02
cotto_work For the time being, let's assume those failures will be addressed. If it's getting close to the release and nothing's happened, feel free to sound the alarm.
kid51 k
let's move on to non-release topics 20:03
NotFound kid51: I'll probably update the winxed snapshot to provide version number
cotto_work Are there other questions? I don't think any were queued.
NotFound q1q
whiteknight q1q 20:04
cotto_work NotFound: go ahead 20:05
NotFound nci thunks: are we going to provide some more?
cotto_work NotFound: what'd be the advantage? 20:06
NotFound For example, I need SppIpI, ppp, Spp and SppI
cotto_work: using strings
These functions are needed to get functions with the appropiate encodings
20:06 darbelo joined
NotFound s/functions/strings 20:07
Getting only with the current platform encoding is plain wrong.
bubaflub could we just add those signatures to extra_thunks ? 20:08
NotFound I think so. The question is what are we going to provide, and if something is going to manage it.
someone
whiteknight is this something that we need baked in to Parrot all the time, or something we can provide in an extension thunk library? 20:09
NCI thunks are cheap, but not free
NotFound whiteknight: I don't think that something as basic as reading a c-string must depend on extensions.
We say something that we fully support unicode... 20:10
whiteknight what exactly are you trying to do? We have ops for changing the encoding of a string 20:11
NotFound Alternatively, provide a way in the nci related PMC to get a string appropiately encoded.
whiteknight is there a function in nciutils for that? 20:12
NotFound whiteknight: if my platform encoding is utf8 and I try to get for example an iso-8859-1 string wicjh is not valid utf8, blam!, and I can't reencode it.
whiteknight As a return value from an NCI function?
NotFound Because I don't have anything to transcode
whiteknight: return value, or pointed to in a struct, or whatever. 20:13
cotto_work NotFound: can you write a quick post to parrot-dev or a nopaste in #parrot with examples of what the thunks enable? I don't object, but I just want to be sure they're actually needed. 20:15
NotFound Other alternative: forget platform encoding, use always binary.
Binary can always be read, and can be transcoded. 20:16
20:20 soh_cah_toa joined
NotFound cotto_work: we can discuse a lot about better ways, but so close from a stable release adding 4 thunks is the less disruptive way, 20:20
whiteknight it would be nice if we had a way to mark a thunk as "experimental" 20:21
adding it for a supported release means we need to support it
cotto_work thunk metadata is sorely lacking
If someone doesn't make an explicit effort to describe a thunk, it's essentially a mystery why it's there. 20:22
TimToady which is why you want a mop that knows native types like thunks as well as user-visible stuff
NotFound 'Parrot_str_new_init', 'SppIpI' is a simple and clean description
'Parrot_find_encoding', 'ppp' 20:24
'Parrot_str_from_platform_cstring', 'Spp'
cotto_work NotFound:
+1 if you add the function names to the thunk file
pmichaud ppp looks like it already exists, unless I'm reading the thunk file wrongly. 20:25
kid51 I would need a lot of convincing to add new features 7 days before supported release
pmichaud I agree that the S* thunks aren't present.
cotto_work It's hardly a feature.
NotFound pmichaud: maybe, but I use it only as auxiliar of Parrot_str_new_init...
cotto_work It's just a bit of data that's used to generate code.
NotFound Uhhh... now that you say it, maybe it must be ppP 20:26
Usage examples: binds for MySql and for libxml2 20:28
20:29 contingencyplan left
cotto_work NotFound: let's move this to #parrot. I suspect whiteknight will need to leave soon. 20:30
NotFound ok
cotto_work whiteknight: go ahead
20:32 contingencyplan joined
whiteknight no question, and I have to leave 20:32
20:32 whiteknight left
cotto_work Any other questions, then? 20:32
soh_cah_toa me
cotto_work soh_cah_toa: go ahead
soh_cah_toa i noticed that we use the open build service (obs) for managing our rpm packages. however, they are severely outdated (v2.5/v3.0). i've been researching obs a little bit and it sounds like something i might like to do 20:33
if i could, i'd like to login to our account and find out a little more about what would be required to maintain the rpm packages.
cotto_work soh_cah_toa: I don't know who has access to that. You should try parrot-dev.
soh_cah_toa sure 20:34
20:34 darbelo_ joined, darbelo left
cotto_work other questions? 20:35
soh_cah_toa yeah, i'll send out a message. and if i don't hear anything i'll just bring it up at the next #ps
cotto_work thanks 20:36
soh_cah_toa eoq
cotto_work any goals for the next week, keeping in mind the upcoming 3.6.0 release? 20:37
soh_cah_toa testing on win32. which i tried to do but was a total pain w/ cygwin 20:38
i'll continue to try though :)
cotto_work kid51: would you like to suggest any goals? 20:40
I've got one goal 20:44
GOAL 1: get tests passing on windows (all)
kid51 cotto_work: No breakage in master before release -- which is pretty much the same as goal 1 20:45
Other than getting all tests to pass on major OSes, the less excitement this week, the better. 20:46
but let's have lots of GSOC excitement in branches :-)
cotto_work kid51: sounds good to me 20:47
exciting branches, boring master
kid51 Well put
bubaflub also a reminder - GSoC mid-term evaluations (from both students and mentors) are due at the end of this week 20:48
cotto_work bubaflub: good point. Thanks for the reminder.
I think we're done. Let's call it a wrap. 20:50
20:51 bubaflub left, kid51 left 20:57 rohitnsit08 left 20:58 rohitnsit08 joined 21:04 pmichaud left
moderator Priorities for this week: all tests to pass on Win32; exciting branches, boring master; no dogs on fire | 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/ 21:05
soh_cah_toa LATE REPORT 21:07
DONE:
* Forget about the #ps time change :(
* Added first implementation of "list" command
* Started writing a tutorial
* Added support for two argument form of "help" command 21:08
* Added first implementation of "run" command
* Blogged
TODO:
* Get "quit" command to stop printing a backtrace
* Fill out mid-term evaluation form
* Blog
EOF
EOR
21:08 bluescreen left 21:09 soh_cah_toa left 21:43 particle joined 21:46 particle1 left 21:51 contingencyplan left 22:06 darbelo_ left 22:10 lucian left 22:37 whiteknight joined 23:13 whiteknight left 23:25 rohitnsit08 left 23:51 NotFound 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!