Camelia, the Perl 6 bug

IRC log for #parrot, 2010-10-02

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:11 davidfetter left #parrot
00:15 ash__ left #parrot
00:16 ash_ joined #parrot
00:17 ash_ left #parrot
00:18 ash_ joined #parrot
00:18 pmichaud joined #parrot
00:20 ash_ left #parrot
00:20 ash_ joined #parrot
00:24 bacek joined #parrot
00:26 whiteknight it's been quiet in here today
00:30 ruoso left #parrot
00:41 GeJ Bonjour everyone.
00:42 plobsing hi GeJ
00:43 Psyche^ joined #parrot
00:43 GeJ Hello plobsing.
00:43 GeJ Quick questions :
00:43 Psyche^ is now known as Patterner
00:43 GeJ 1) is there a performance benefit in using pasm over pir?
00:44 plobsing No. Anything you can do in PASM, you *can* do in PIR.
00:45 plobsing The more natural way to do things in PIR (lots of subs) does cost a little more though.
00:45 plobsing But I'm fairly sure that tradeoff can easily be made in the name of good software design
00:47 GeJ 2) If I were to rewrite a component in library/ (with different behavior) should that be considered for deprecation cycle?
00:48 plobsing if it changes something user-visible (and what in runtime/library isn't?) then it needs deprecation
00:48 plobsing unless you can argue that the behaviour you are destroying is somehow fundamentally flawed.
00:49 plobsing eg: you don't need deprecation to eliminate something that always segfaults
00:49 GeJ 3) since I'm going to start a new branch, should I stick to svn or can I create it on github already?
00:50 plobsing my opinion: svn branch merging is no better than applying honking huge patches (which you can get from git). The only benefit you get from an svn branch is publicity.
00:51 whiteknight I would do it in svn for now
00:51 whiteknight that's the system, and we haven't migrated yet
00:52 ruoso joined #parrot
00:53 Patterner left #parrot
00:54 GeJ fine... thanks for the info.
00:54 whiteknight GeJ: you a big git fan?
00:57 GeJ not necessarily a fan, but I started using it last year at work for every piece of code I begin and for everything personal too. So I'd say I'm getting more confortable using it than svn.
01:00 GeJ But before I start anything, I'll have to read more PIR first.
01:01 GeJ The other option I was considering was creating a project on its own and import it to parrot when it's done.
01:03 plobsing GeJ: what is this awesome thing that you are creating?
01:06 GeJ I intend to make Data::Dumper return a string instead of plain old printing.
01:08 GeJ My secret plan would be to have it return any king of string : classing Dumper, JSON, YAML or eval-able code.
01:09 GeJ sadly, thatere's this __dump callback thingy that makes my changes user-visible.
01:10 plobsing next supported release is this month. get the dep notice in and wait a couple weeks.
01:11 plobsing wait... is that how dep works? I can never remember
01:14 GeJ I haven't started anything yet. That sounds a little early for me to announce anything while I'm still in the "damn, how does that StringBuilder stuff works" phase. :-)
01:19 bacek left #parrot
01:25 kid51 joined #parrot
01:35 whiteknight left #parrot
01:35 GeJ clock?
01:35 aloha GeJ: LAX: Fri, 17:57 PDT / CHI: Fri, 19:57 CDT / NYC: Fri, 20:57 EDT / UTC: Sat, 00:57 UTC / LON: Sat, 01:57 BST / BER: Sat, 02:57 CEST / TOK: Sat, 09:57 JST / SYD: Sat, 10:57 EST
01:46 sjn that clock seems a bit off..
01:46 Util joined #parrot
01:47 kid51 Yes, 38 minutes off.
01:47 kid51 Well, I, for one, have never thought aloha to be an adequate replacement for purl.
02:15 sorear aloha: msg bacek "clock?" is 38 minutes off.
02:15 aloha sorear: OK. I'll deliver the message.
02:15 aloha sorear: Okay.
02:16 sorear aloha: aloha: msg bacek "clock?"?
02:16 aloha sorear: I have no idea.
02:22 kid51 left #parrot
02:36 janus left #parrot
02:57 dalek parrot: r49405 | nwellnhof++ | trunk/config/gen/config_pm/myconfig.in:
02:57 dalek parrot: [configure] Add more variables to myconfig
02:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49405/
03:13 janus joined #parrot
03:47 Andy joined #parrot
03:58 dalek parrot: r49406 | plobsing++ | trunk/src/runcore/trace.c:
03:58 dalek parrot: fix trace core for dynop_mapping
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49406/
05:05 cotto anyone know a good way to figure out which tab in Firefox is eating my cpu and making the browser unresponsive?
05:12 sorear bisect
05:12 sorear close half of them, top, repeat
05:12 sorear one at a time *might* work better
05:17 * cotto doesn't want to lose his tabs.  Also, it's pretty hard to do anything.
05:17 cotto I was thinking more along the lines of thread debugging.
05:28 Andy left #parrot
05:55 theory left #parrot
06:14 Patterner joined #parrot
06:22 cotto Apparently http://trac.parrot.org/parrot/changeset/48412 was the page that was killing firefox.
06:22 cotto silly browser
06:23 cotto karma bacek
06:23 cotto aloha, karma bacek
06:23 cotto aloha--
06:33 * cotto wants the annoying but reliable purl back
06:39 cotto NotFound, ping
06:39 cotto aloha, msg cotto test
06:39 aloha cotto: OK. I'll deliver the message.
06:39 cotto ~~
06:40 cotto at least that works
06:44 sorear karma bacek
06:44 sorear karma aloha?
06:46 sorear hmm.  maybe I should dig up lambdabot.
06:48 fperrad joined #parrot
06:54 Patterner left #parrot
07:05 Patterner joined #parrot
07:05 plobsing left #parrot
07:07 cotto This stupid bird is hacks on top of hacks.
07:18 cotto plobsing++ for the TT #1745 report, even if the karmabots aren't listening
07:33 dalek parrot: r49407 | cotto++ | trunk/src (2 files):
07:33 dalek parrot: comment alignment cleanup; no functional changes
07:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49407/
08:12 particle1 joined #parrot
08:14 plobsing joined #parrot
08:15 particle left #parrot
08:16 jsut_ left #parrot
08:16 jsut joined #parrot
08:35 cotto plobsing, ping
08:41 plobsing cotto: pong
08:41 cotto aloha msg plobsing What'd be needed to make examples/pir/make_hello_world_pbc.pir work post-dynop_mapping?
08:41 aloha cotto: OK. I'll deliver the message.
08:41 cotto er, s/aloha msg//
08:41 plobsing heh
08:42 cotto From what I can tell, there'll at least need to be a way to expose op mapping to the packfile pmcs.
08:42 plobsing I don't think that will be necessary
08:43 plobsing If we make use of Opcode PMCs, the mapping could be done automatically
08:43 plobsing first though, I think we seriously need to create a speciallized bytecode segment type
08:43 cotto Where do the mappings live now?
08:43 plobsing shoving bytecodish stuff into raw segment is just wrong
08:44 cotto they don't show up in the output of pbc_dump
08:44 cotto though the mapping is clearly at work
08:45 plobsing yeah, I tried to make it *transparent* to the user.
08:45 plobsing so you shouldn't see it poke through anywhere
08:46 plobsing they get populated by src/packfile.c:byte_code_unpack
08:47 plobsing that function as well as 'struct PackFile_ByteCode' should give you a good idea of how things work
08:48 cotto ok.  Thanks.
08:59 * cotto is sad to see himself moving toward marking dummy contexts as such as a solution to #1745.  Maybe sleep will help.
09:03 dukeleto left #parrot
09:03 dukeleto joined #parrot
09:04 plobsing I'm also not a fan of dummy contexts. But I'm not familiar with TT #150.
09:18 frodwith left #parrot
09:18 frodwith joined #parrot
09:36 tadzik joined #parrot
10:06 esskar_ joined #parrot
10:09 esskar left #parrot
10:09 esskar_ is now known as esskar
10:20 tadzik left #parrot
11:39 ash_ left #parrot
11:46 whiteknight joined #parrot
11:52 GeJ clock?
11:52 aloha GeJ: LAX: Sat, 04:05 PDT / CHI: Sat, 06:05 CDT / NYC: Sat, 07:05 EDT / UTC: Sat, 11:05 UTC / LON: Sat, 12:05 BST / BER: Sat, 13:05 CEST / TOK: Sat, 20:05 JST / SYD: Sat, 21:05 EST
11:52 GeJ whiteknight: that's early for a Saturday. Go back to bed!
11:53 whiteknight 7AM isn't too early.
11:53 GeJ On a Saturday? Yes it is :)
11:53 whiteknight my kid usually wakes us all up at 4AM, so this is "sleeping in"
12:00 GeJ 4AM... that's just a concept for me. I deny the existence of such an early hour.
12:00 GeJ and yes, even if I have to feed my offspring (which I don't have yet).
12:03 GeJ How old is your little one?
12:07 lucian joined #parrot
12:11 kid51 joined #parrot
12:19 kid51 left #parrot
12:31 fperrad left #parrot
12:40 whiteknight GeJ: 10 months
12:48 * whiteknight can't wait to get his development computer back
12:50 GeJ what happened? hardware failure?
13:12 mikehh left #parrot
13:12 whiteknight GeJ: yeah, the hinges that hold the screen to the chassis broke
13:13 whiteknight so I had to disassemble it, to prevent the monitor signal wires from rubbing against the broken hinges and fraying
13:17 whiteknight plobsing: ping
13:19 Psyche^ joined #parrot
13:20 Patterner left #parrot
13:20 Psyche^ is now known as Patterner
13:21 lucian_ joined #parrot
13:22 lucian left #parrot
13:26 kid51 joined #parrot
13:37 kid51 left #parrot
13:37 kid51 joined #parrot
13:40 kid51 left #parrot
14:14 GodFather joined #parrot
14:23 whiteknight left #parrot
14:31 kid51 joined #parrot
14:41 davidfetter joined #parrot
14:43 whiteknight joined #parrot
14:46 LaVolta joined #parrot
14:47 LaVolta left #parrot
14:50 whiteknight Does anybody know anything about the function Parrot_setup_event_func_ptrs()?
14:59 lucian_ left #parrot
15:00 lucian joined #parrot
15:06 plobsing whiteknight: pong
15:07 whiteknight plobsing: sorry, I think I already answered by question
15:07 whiteknight turned interp->op_func_table into interp->code->op_func_table
15:07 whiteknight or, whatever it is called
15:07 plobsing seems about right
15:09 plobsing whiteknight: what do you need to know about Parrot_setup_event_func_ptrs()?
15:10 plobsing other than it is dead
15:10 whiteknight it is dead? If I have code that was calling it, do I need to replace that with anything or just delete the reference?
15:11 plobsing it depends. I don't really understand why code would be calling it.
15:11 whiteknight ha
15:12 whiteknight I'm working on the parrot-instrument project, trying to get that to build again.
15:12 whiteknight I've got the PMC files to build, I'm working on getting the test suite to run, and then I will know if there are any problems
15:13 plobsing was it calling setup_event_func_ptrs because it wanted interp->evc_func_table populated?
15:13 whiteknight I suppose so
15:13 plobsing maybe it was going to substitute it's own variant of check_events__ there?
15:15 plobsing because now, evc_func_table is populated/expanded lazily in src/runcore/main.c:enable_event_checking
15:15 whiteknight ok
15:16 whiteknight I haven't read through all this code, so I don't know exactly what all it was trying to do. I'll know once these damned tests get running
15:25 tadzik joined #parrot
15:35 M_o_C joined #parrot
15:39 tadzik1 joined #parrot
15:39 tadzik left #parrot
15:40 tadzik1 is now known as tadzik
15:45 whiteknight is there any way to get some extra diagnostics about library loading?
15:45 ash_ joined #parrot
15:46 whiteknight I've got this test suite that's trying to load a dynpmc group, but it never loads no matter what I try. I can't figure out why it's failing or even which paths it's searching
15:46 cotto whiteknight++
15:47 cotto The more I think about it, the more I agree that that code should be in core.
15:47 whiteknight how's my miserable failure worth karma?
15:47 cotto you're trying
15:47 cotto are you working on the svn branch?
15:47 whiteknight no, on github
15:48 whiteknight I have the lib building, and it gets put in ./dynext/instrument_group.so
15:48 whiteknight I have a test file that does "$P0 = loadlib './dynext/instrument_group'"
15:48 whiteknight but it always returns false
15:48 cotto You might just work on the svn branch, since that's already in core.
15:48 whiteknight actually, I
15:49 whiteknight 'm working on a fork
15:49 whiteknight github.com:Whiteknight/parrot-instrument
15:49 whiteknight I just pushed a bunch of fixes, if you want to take a look at it
15:49 * cotto looks
15:50 mikehh joined #parrot
15:52 cotto whiteknight, do you know that parts of those pmcs are generated?
15:52 whiteknight what?
15:52 whiteknight there are parts?
15:53 cotto I don't see the scripts in the git repo.
15:53 whiteknight what scripts?
15:53 cotto I'm pretty sure I got him to put them in svn.
15:53 cotto just a sec
15:54 whiteknight when I started on this, somebody said that the most recent version of the code that I should be playing with was in github
15:55 cotto I know that khairul hadn't got the build working in github when I last checked.  It's likely that he forgot to move the pmc generation scripts over.
15:55 whiteknight and either way, still doesn't explain why Parrot can't load this damned library
15:55 cotto tools/build/gen_*_stubs.pl in the gsoc_instrument branch
15:55 cotto They're only needed for updating the PMCs, but they'll save some sanity when the need arises.
15:56 whiteknight Yeah, I just fixed the one with all the vtables
15:56 cotto That's what brought the scripts to mind.
15:57 cotto I think the best approach would be to sync gsoc_instrument with trunk, copy your changes from github and go from there.
15:58 cotto Parrot's not stable enough for that kind of project to live out in the wild where it could easily be ignored and bitrot.
16:00 whiteknight okay, the gsoc_instrument branch has all the most recent code?
16:01 whiteknight minus my fixes
16:01 cotto I think the only changes in the github branch are the attempts to get it to build with distutils
16:01 whiteknight ok
16:01 cotto I need to verify that though.
16:01 whiteknight well, i do have it building. That still doesn't explain why I can't loadlib the generated .so
16:01 cotto yup, plus a single change
16:02 dalek parrot: r49408 | mikehh++ | trunk/config/auto (2 files):
16:02 dalek parrot: set svn properties
16:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49408/
16:03 cotto It builds fine and runs its tests (t/dynpmc/instrument* and t/library/instrument*) fine from the svn branch, so that's a good starting point.
16:03 * cotto wonders if svn supports syncing with tags rather than trunk
16:04 whiteknight a tag is just acopy
16:04 whiteknight you can always sync with a copy
16:04 cotto I'd be surprised if it didn't work, I just haven't needed to do it before.
16:04 moritz that's the beauty and the problem with tags
16:05 moritz you can commit to a tag... which kinda doesn't make sense to me
16:05 whiteknight a "tag" is just a copy with a special name. Everything else is just convention
16:07 whiteknight building gsoc_instrument now...
16:10 cognominal left #parrot
16:13 cognominal joined #parrot
16:14 plobsing cotto: being in core doesn't prevent bitrot. both the profiling and tracing runcores were broken after dynop_mapping and we're just now getting around to fixing them.
16:15 lucian left #parrot
16:16 whiteknight bitrot is definitely not a great reason to move code into core, even if there is a beneficial effect for it
16:16 whiteknight these PMCs really do poke into Parrot internals more than most things should
16:16 GodFather left #parrot
16:16 lucian joined #parrot
16:17 whiteknight but they also give an important base for writing tools that we will want like new debuggers, profilers, mock objects, and other introspective features
16:17 dalek parrot: r49409 | mikehh++ | trunk/config/auto/stat.pm:
16:17 dalek parrot: replace hard tabs
16:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49409/
16:20 whiteknight I would like to see things like e.g. the debug and tracing runcores be based on these instrument PMCs
16:21 whiteknight because then we get the ability to easily plug new tracers/debuggers, to subclass them, etc
16:21 whiteknight we could plug our debug tool into our profiling tool and make our debugger run faster
16:22 cotto plobsing, yes, but the instrument code has existing tests.  I'm sure they're not complete, but they do give a general idea of whether the instrument code has some basic level of functionality.
16:22 theory joined #parrot
16:22 cotto The trace and profiling runcores are broken because no tests covered the behavior that broke.
16:23 * moritz suggests importing rakudo as a big test case
16:23 cotto whiteknight, yes.  The instrument code is a great foundation for higher-level tools.
16:24 kid51 left #parrot
16:25 cotto In general I'm happy with code living outside core, but these PMCs are (and probably need to be) pretty tight with Parrot internals.
16:25 whiteknight cotto: how to run the instrument tests in the gsoc_instrument branch? When I try to run them they die\
16:26 cotto prove t/dynpmc/instrument* t/library/instrument_*
16:26 cotto the parallel build is goofy in the branch.  You might need to run a serial build.
16:26 cotto (They're also run as part of make test, but you're probably not that patient.)
16:28 cotto They work fine on my x86 ubuntu box.
16:36 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#398) fulltest) at r49409 - Kubuntu 10.10 RC amd64 (g++-4.5)
16:45 cotto mikehh, could you run those tests in the gsoc_instrument branch?
16:45 cotto prove t/dynpmc/instrument* t/library/instrument_*
16:49 cotto I don't want to start bring the branch up to date with trunk until I know that it at least passes on x86 and x64
16:51 patspam joined #parrot
16:51 patspam left #parrot
16:54 mikehh cotto: 'k
17:02 cotto thanks
17:03 cotto I'm working the dependencies, but expect bumps in the parallel build.  Re-running make after make -jN fails works fine.
17:05 cotto fix committed
17:05 cotto (But don't worry if you already have it build.  It's just a makefile fix.)
17:06 cotto s/build/built/
17:14 whiteknight cotto: okay, I see the tests running now. I did a make test but didn't see those tests get run
17:16 whiteknight I'm going to create a new branch to bring gsoc_instrument up to date with trunk
17:16 cotto they're easy to miss
17:16 cotto good idea
17:18 whiteknight this particular operation would be much easier in git
17:18 dalek parrot: r49410 | cotto++ | branches/gsoc_instrument/co​nfig/gen/makefiles/root.in:
17:19 dalek parrot: add dependencies for Instrument/Instrument.pir, hopefully fixing the parallel build
17:19 cotto patience
17:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49410/
17:19 dalek parrot: r49411 | whiteknight++ | branches/gsoc_instrument2:
17:19 dalek parrot: creating a new branch to work on getting the gsoc_instrument work up to date
17:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49411/
17:21 cotto I wonder if TT #1745 will bite gsoc_instrument too.
17:23 whiteknight blah. I need to focus on one problem at a time
17:23 cotto but there are so many to choose from
17:32 mikehh cotto: got it to build/ 1 codetest failure (pod_syntax in  examples/library/tracer.nqp [which it should not be testing])  and t/perl/Parrot_Test.t -  Failed test:  70
17:34 dalek parrot: r49412 | whiteknight++ | branches/gsoc_instrument2:
17:34 dalek parrot: deleting this branch, trying something else
17:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49412/
17:35 mikehh anyway will do some more testing later, got to do something else at the moment
17:37 tadzik left #parrot
17:43 dukeleto_ joined #parrot
17:51 whiteknight the gsoc_instrument merge to trunk is going to be extremely messy, it seems
17:54 dukeleto_ 'ello
18:02 bluescreen joined #parrot
18:08 Andy joined #parrot
18:09 dukeleto_ left #parrot
18:12 dukel3to joined #parrot
18:28 Andy left #parrot
18:29 Andy joined #parrot
18:44 tadzik joined #parrot
18:52 whiteknight left #parrot
18:52 lucian_ joined #parrot
18:55 lucian left #parrot
19:03 Andy left #parrot
19:09 Andy joined #parrot
19:31 whiteknight joined #parrot
19:33 Andy left #parrot
19:48 Andy joined #parrot
19:52 whiteknight okay, let me refine my statement from earlier. The gsoc_instrument branch merge is going to be *EXTREMELY* messy
19:53 whiteknight I've been typing "p" for the past 5 minutes, and the end is nowhere in site
19:53 whiteknight sight
19:54 whiteknight in SVN, the new rule should be "Never, ever ever ever update your branch from trunk."
20:04 tcurtis joined #parrot
20:08 plobsing cotto: (wrt value of instrument tests) external project tests are great but do not in and of themselves constitute are strong argument for core-ing. What we really need is a test-universe utility. possibly tied in with plumage.
20:10 petdance joined #parrot
20:12 petdance left #parrot
20:12 whiteknight Text conflicts: 113
20:12 whiteknight Property conflicts: 2
20:12 whiteknight Tree conflicts: 88
20:12 whiteknight plobsing: I was actually thinking about that exact kind of thing this morning
20:13 whiteknight all the better if it files smoke reports
20:13 plobsing I think for a universe-type test, we should be more interested in failure deltas than total failures.
20:14 Andy left #parrot
20:14 whiteknight that may be
20:14 plobsing I don't care your external project doesn't currently pass all tests, but I sure as hell care that I broke half of your previously passing tests.
20:15 whiteknight aloha msg cotto I tried a gsoc_instrument branch merge. Very messy. 113 text conflicts, 88 tree conflicts. I'm not going to spend several hours fixing them all. I'm going to focus back on the github repo instead
20:15 aloha whiteknight: OK. I'll deliver the message.
20:15 whiteknight plobsing: yes, that's a very good point
20:16 whiteknight plobsing: but that's going to require infrastructure to keep track of the number of passing tests, and fire an alert when there's a delta.
20:16 whiteknight we don't have anything like that
20:19 plobsing it is a timewise-directed graph of deltas. sounds a lot like git to me. wonder if it could be made to work.
20:21 whiteknight it would make for an interesting project
20:21 whiteknight in the mean time, I think adding a "smoke all" target to plumage would be fantastic
20:22 whiteknight a monitor utility to watch uploads to smolder and calculate deltas would be a nice second step
20:22 plobsing true KISS style. I like it.
20:26 sorear whiteknight: I think more useful than dfailures/dt would be dfailures/dparrotrev (external rev fixed)
20:29 M_o_C left #parrot
20:33 ash_ left #parrot
20:38 whiteknight sorear: that does sound useful too.
20:38 whiteknight of course, the usefulness of hypothetical tools is limited by how much they don't exist
20:38 whiteknight very likely, we will just use whatever tool somebody makes for us first
20:45 whiteknight aloha msg cotto when you get a chance, can you clone my parrot-instruments fork at github and give it a test? I want to see if there is some kind of problem on my machine that prevents me from loading instrument_group.so. Thanks
20:45 aloha whiteknight: OK. I'll deliver the message.
20:46 * whiteknight logs off
20:46 whiteknight left #parrot
21:11 tadzik left #parrot
21:20 kid51 joined #parrot
21:25 dukel3to msg whiteknight http://help.github.com/splitt​ing-a-subpath-to-a-new-repo/ <-- could be useful for you for the languages repo
21:25 aloha OK. I'll deliver the message.
21:25 kid51 ~~
21:25 dukel3to kid51: how goes it?
21:25 kid51 Okay.  A
21:26 kid51 Have been in Toronto for past few days.
21:26 dukel3to kid51: did you vacation start already?
21:26 kid51 Did lightning talks at tpm Thursday night.
21:26 kid51 Vacation I
21:26 dukel3to kid51: what needs doing re: the pdx parrot hackathon?
21:26 kid51 Vacation II starts in a week
21:26 kid51 Well, as you see, I've secured space.
21:27 kid51 So now, we just need to get people to come!
21:28 dukel3to kid51: we need a plan for that
21:29 dukel3to kid51: here is a nice example of hackathon marketing http://loqi.me/poll/geoloqi-hackathon-2010
21:40 jsut_ joined #parrot
21:45 jsut left #parrot
21:50 kid51 dukel3to: Yes, but that's a bit more advanced than what I think we're aiming for right now.
21:50 kid51 It's more than I can think of organizing from 2800 miles away :-)
21:52 dukel3to kid51: i hear ya. i just wanted to give it as an example of marketing for a hackathon
21:52 dukel3to kid51: it is something to aim for
21:52 * dukel3to goes into the rare PDX sunshine
21:58 kid51 That kind of hackathon is something we can aim for when we've increased our "customer base" ...
21:58 nopaste "plobsing" at 192.168.1.3 pasted "float sigbus test" (14 lines) at http://nopaste.snit.ch/23924
21:59 kid51 ... whereby "customer" I mean: Any OS project building on top of parrot that has >= 2 active committers.
22:01 bluescreen left #parrot
22:02 lucian_ left #parrot
22:03 plobsing sorry about nopaste. not intended for this channel
22:10 bluescreen joined #parrot
22:25 dalek parrot: r49413 | nwellnhof++ | trunk (6 files):
22:25 dalek parrot: [str] Add own encoding for null string
22:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49413/
22:25 dalek parrot: r49414 | nwellnhof++ | trunk (2 files):
22:25 dalek parrot: [str] String API optimizations
22:26 dalek parrot: Simplify the argument checks of some string functions. This is in
22:26 dalek parrot: preparation of the following commits that will move these checks
22:26 dalek parrot: directly into the encoding functions, and switch a lot of Parrot code
22:26 dalek parrot: to the new string macros.
22:26 dalek parrot: With the exception of STRING_length and STRING_byte_length, the string
22:26 dalek parrot: macros don't check the string argument for NULL pointers. So the
22:26 dalek parrot: following commits also fix some places that still didn't use
22:26 dalek parrot: STRING_IS_NULL and STRINGNULL.
22:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49414/
22:26 dalek parrot: r49415 | nwellnhof++ | trunk (23 files):
22:26 dalek parrot: [str] Switch to STRING_ord macro
22:26 dalek parrot: Move the whole 'ord' logic into the string vtable functions.
22:26 dalek parrot: Also modifies Parrot_str_indexed to accept negative indices as well. The old
22:26 dalek parrot: string_ord function can finally be deprecated.
22:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49415/
22:26 dalek parrot: r49416 | nwellnhof++ | trunk (46 files):
22:26 dalek parrot: [str] Switch to STRING_equal macro
22:26 dalek parrot: Move the whole 'str_equal' logic into the string vtable functions
22:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49416/
22:38 bluescreen guys, what would be the best method to debug parrot's guts I'm trying to take a look at http://trac.parrot.org/parrot/ticket/1769 ?
22:41 dalek parrot: r49417 | nwellnhof++ | trunk (25 files):
22:41 dalek parrot: [str] Switch to STRING_substr macro
22:41 dalek parrot: Move the whole 'substr' logic into the string vtable functions
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49417/
22:41 dalek parrot: r49418 | nwellnhof++ | trunk (8 files):
22:41 dalek parrot: [str] Switch to STRING_hash macro
22:41 dalek parrot: Move the whole 'str_to_hashval' logic into the string vtable functions
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49418/
22:41 dalek parrot: r49419 | nwellnhof++ | trunk (8 files):
22:41 dalek parrot: [str] Switch to STRING_compare macro
22:41 dalek parrot: Move the whole 'compare' logic into the string vtable functions
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49419/
22:41 dalek parrot: r49420 | nwellnhof++ | trunk (13 files):
22:41 dalek parrot: [str] Switch to STRING_index macro
22:41 dalek parrot: Move the whole 'index' logic into the string vtable functions. This also
22:41 dalek parrot: changes the index opcode to throw when the source string is null. If this
22:41 dalek parrot: change causes problems, we can add a deprecation notice or revert it.
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49420/
22:41 dalek parrot: r49421 | nwellnhof++ | trunk/src/string/encoding (3 files):
22:41 dalek parrot: [str] Make some string code work without ICU
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49421/
22:41 dalek parrot: r49422 | nwellnhof++ | trunk/src/string/api.c:
22:41 dalek parrot: [str] Optimize str_rep_compatible
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49422/
22:41 dalek parrot: r49423 | mikehh++ | trunk/src/string/encoding/null.c:
22:41 dalek parrot: add svn properties
22:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49423/
22:44 plobsing bluescreen: gdb is my first resource with such problems.
22:45 bluescreen is parrot compiled with symbols by default?
22:48 plobsing should be (no opt generally includes symbols). but rakudo's default parrot doesn't IIRC.
22:49 bluescreen that's ok I'm using trunk's parrot
22:50 mikehh get g++ build errors:
22:50 mikehh src/string/encoding/null.c:245:13: error: redefinition of ‘STR_VTABLE* Parrot_null_encoding_ptr’
22:50 mikehh ./include/parrot/encoding.h:29:13: error: ‘STR_VTABLE* Parrot_null_encoding_ptr’ previously declared here
22:52 mikehh builds ok with gcc
23:04 cotto Hmmm.  I tried syncing gsoc_instrument with trunk and got a single conflict on MANIFEST.
23:05 cotto I can say with near certainty that the instrument code won't build or run correctly, but the merge seems to have worked.
23:05 nopaste "kid51" at 192.168.1.3 pasted "'make' fails at r49423 on Darwin/PPC" (705 lines) at http://nopaste.snit.ch/23926
23:05 nwellnhof joined #parrot
23:05 cotto svn--
23:05 cotto aloha, karma svn
23:06 cotto aloha, status
23:06 cotto aloha msg aloha aloha
23:06 aloha cotto: OK. I'll deliver the message.
23:06 kid51 nwellnhof:  Can you take a look at http://nopaste.snit.ch/23926 ?  After your recent commits, I got a make fulltest PASS on Linux/i386, but had build failure on other system
23:09 cotto aloha msg whiteknight I don't know what caused all those merge conflicts but I only found a trivial one when I tried to sync with trunk.  gsoc_instrument only adds files and a bit of build infrastructure (I took care of merging any changes to core) so syncing should be easy.
23:09 aloha cotto: OK. I'll deliver the message.
23:09 mikehh kid51: it's the same error I get trying to build with g++, it builds for me with gcc (see above)
23:09 nwellnhof i'm on it.
23:10 kid51 mikehh: Consistent.  On Darwin/PPC, I use gcc for 'cc' but g++ for --link and --ld
23:11 kid51 left #parrot
23:11 mikehh nwellnhof: I get (with g++ build):
23:11 mikehh src/string/encoding/null.c:245:13: error: redefinition of ‘STR_VTABLE* Parrot_null_encoding_ptr’
23:11 mikehh ./include/parrot/encoding.h:29:13: error: ‘STR_VTABLE* Parrot_null_encoding_ptr’ previously declared here
23:17 GeJ Bonjour everyone.
23:17 GeJ I think I have dreamt of Data::Dumper last night. Is it serious doctor?
23:18 cotto I always take it as a good sign when I dream about something technical like that.
23:18 mikehh GeJ: got to be, dreaming of things like Data::Dumper cdan get you committed
23:19 mikehh can
23:19 mikehh sorry about the pun :-}
23:21 nwellnhof i hope that r49424 fixes the g++ build. it works for me with --cc=g++ --ld=g++ --link=g++
23:21 mikehh nwellnhof: let me check
23:26 mikehh nwellnhof: looks good
23:27 Searle joined #parrot
23:27 dalek parrot: r49424 | nwellnhof++ | trunk/include/parrot/encoding.h:
23:27 dalek parrot: [str] Fix g++ build
23:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49424/
23:30 Searle left #parrot
23:37 nwellnhof btw, the branches charset_massacre and string_macros can be deleted.
23:38 dukel3to left #parrot
23:52 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#401) fulltest) at r49424 - Kubuntu 10.10 RC amd64 (g++-4.5)

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced