Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | smoke GC-related branches and attack GC tickets
Set by moderator on 1 October 2010.
00:11 davidfetter left 00:15 ash__ left 00:16 ash_ joined 00:17 ash_ left 00:18 ash_ joined, pmichaud joined 00:20 ash_ left, ash_ joined 00:24 bacek joined
whiteknight it's been quiet in here today 00:26
00:30 ruoso left
GeJ Bonjour everyone. 00:41
plobsing hi GeJ 00:42
00:43 Psyche^ joined
GeJ Hello plobsing. 00:43
Quick questions :
00:43 Psyche^ is now known as Patterner
GeJ 1) is there a performance benefit in using pasm over pir? 00:43
plobsing No. Anything you can do in PASM, you *can* do in PIR. 00:44
The more natural way to do things in PIR (lots of subs) does cost a little more though. 00:45
But I'm fairly sure that tradeoff can easily be made in the name of good software design
GeJ 2) If I were to rewrite a component in library/ (with different behavior) should that be considered for deprecation cycle? 00:47
plobsing if it changes something user-visible (and what in runtime/library isn't?) then it needs deprecation 00:48
unless you can argue that the behaviour you are destroying is somehow fundamentally flawed.
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?
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:50
whiteknight I would do it in svn for now 00:51
that's the system, and we haven't migrated yet
00:52 ruoso joined 00:53 Patterner left
GeJ fine... thanks for the info. 00:54
whiteknight GeJ: you a big git fan?
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. 00:57
But before I start anything, I'll have to read more PIR first. 01:00
The other option I was considering was creating a project on its own and import it to parrot when it's done. 01:01
plobsing GeJ: what is this awesome thing that you are creating? 01:03
GeJ I intend to make Data::Dumper return a string instead of plain old printing. 01:06
My secret plan would be to have it return any king of string : classing Dumper, JSON, YAML or eval-able code. 01:08
sadly, thatere's this __dump callback thingy that makes my changes user-visible. 01:09
plobsing next supported release is this month. get the dep notice in and wait a couple weeks. 01:10
wait... is that how dep works? I can never remember 01:11
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:14
01:19 bacek left 01:25 kid51 joined 01:35 whiteknight left
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
sjn that clock seems a bit off.. 01:46
01:46 Util joined
kid51 Yes, 38 minutes off. 01:47
Well, I, for one, have never thought aloha to be an adequate replacement for purl.
sorear aloha: msg bacek "clock?" is 38 minutes off. 02:15
aloha sorear: OK. I'll deliver the message.
sorear: Okay.
sorear aloha: aloha: msg bacek "clock?"? 02:16
aloha sorear: I have no idea.
02:22 kid51 left 02:36 janus left
dalek rrot: r49405 | nwellnhof++ | trunk/config/gen/config_pm/myconfig.in:
[configure] Add more variables to myconfig
 02:57
03:13 janus joined 03:47 Andy joined
dalek rrot: r49406 | plobsing++ | trunk/src/runcore/trace.c:
fix trace core for dynop_mapping
 03:58
cotto anyone know a good way to figure out which tab in Firefox is eating my cpu and making the browser unresponsive? 05:05
sorear bisect 05:12
close half of them, top, repeat
one at a time *might* work better
cotto doesn't want to lose his tabs. Also, it's pretty hard to do anything. 05:17
I was thinking more along the lines of thread debugging.
05:28 Andy left 05:55 theory left 06:14 Patterner joined
cotto Apparently trac.parrot.org/parrot/changeset/48412 was the page that was killing firefox. 06:22
silly browser
karma bacek 06:23
aloha, karma bacek
aloha--
cotto wants the annoying but reliable purl back 06:33
NotFound, ping 06:39
aloha, msg cotto test
aloha cotto: OK. I'll deliver the message.
cotto ~~
at least that works 06:40
sorear karma bacek 06:44
karma aloha?
hmm. maybe I should dig up lambdabot. 06:46
06:48 fperrad joined 06:54 Patterner left 07:05 Patterner joined, plobsing left
cotto This stupid bird is hacks on top of hacks. 07:07
plobsing++ for the TT #1745 report, even if the karmabots aren't listening 07:18
dalek rrot: r49407 | cotto++ | trunk/src (2 files):
comment alignment cleanup; no functional changes
 07:33
08:12 particle1 joined 08:14 plobsing joined 08:15 particle left 08:16 jsut_ left, jsut joined
cotto plobsing, ping 08:35
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?
aloha cotto: OK. I'll deliver the message.
cotto er, s/aloha msg//
plobsing heh
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
If we make use of Opcode PMCs, the mapping could be done automatically 08:43
first though, I think we seriously need to create a speciallized bytecode segment type
cotto Where do the mappings live now?
plobsing shoving bytecodish stuff into raw segment is just wrong
cotto they don't show up in the output of pbc_dump 08:44
though the mapping is clearly at work
plobsing yeah, I tried to make it *transparent* to the user. 08:45
so you shouldn't see it poke through anywhere
they get populated by src/packfile.c:byte_code_unpack 08:46
that function as well as 'struct PackFile_ByteCode' should give you a good idea of how things work 08:47
cotto ok. Thanks. 08:48
cotto is sad to see himself moving toward marking dummy contexts as such as a solution to #1745. Maybe sleep will help. 08:59
09:03 dukeleto left, dukeleto joined
plobsing I'm also not a fan of dummy contexts. But I'm not familiar with TT #150. 09:04
09:18 frodwith left, frodwith joined 09:36 tadzik joined 10:06 esskar_ joined 10:09 esskar left, esskar_ is now known as esskar 10:20 tadzik left 11:39 ash_ left 11:46 whiteknight joined
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
GeJ whiteknight: that's early for a Saturday. Go back to bed!
whiteknight 7AM isn't too early. 11:53
GeJ On a Saturday? Yes it is :)
whiteknight my kid usually wakes us all up at 4AM, so this is "sleeping in"
GeJ 4AM... that's just a concept for me. I deny the existence of such an early hour. 12:00
and yes, even if I have to feed my offspring (which I don't have yet).
How old is your little one? 12:03
12:07 lucian joined 12:11 kid51 joined 12:19 kid51 left 12:31 fperrad left
whiteknight GeJ: 10 months 12:40
whiteknight can't wait to get his development computer back 12:48
GeJ what happened? hardware failure? 12:50
13:12 mikehh left
whiteknight GeJ: yeah, the hinges that hold the screen to the chassis broke 13:12
so I had to disassemble it, to prevent the monitor signal wires from rubbing against the broken hinges and fraying 13:13
plobsing: ping 13:17
13:19 Psyche^ joined 13:20 Patterner left, Psyche^ is now known as Patterner 13:21 lucian_ joined 13:22 lucian left 13:26 kid51 joined 13:37 kid51 left, kid51 joined 13:40 kid51 left 14:14 GodFather joined 14:23 whiteknight left 14:31 kid51 joined 14:41 davidfetter joined 14:43 whiteknight joined 14:46 LaVolta joined 14:47 LaVolta left
whiteknight Does anybody know anything about the function Parrot_setup_event_func_ptrs()? 14:50
14:59 lucian_ left 15:00 lucian joined
plobsing whiteknight: pong 15:06
whiteknight plobsing: sorry, I think I already answered by question 15:07
turned interp->op_func_table into interp->code->op_func_table
or, whatever it is called
plobsing seems about right
whiteknight: what do you need to know about Parrot_setup_event_func_ptrs()? 15:09
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?
plobsing it depends. I don't really understand why code would be calling it. 15:11
whiteknight ha
I'm working on the parrot-instrument project, trying to get that to build again. 15:12
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
plobsing was it calling setup_event_func_ptrs because it wanted interp->evc_func_table populated? 15:13
whiteknight I suppose so
plobsing maybe it was going to substitute it's own variant of check_events__ there?
because now, evc_func_table is populated/expanded lazily in src/runcore/main.c:enable_event_checking 15:15
whiteknight ok
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:16
15:25 tadzik joined 15:35 M_o_C joined 15:39 tadzik1 joined, tadzik left 15:40 tadzik1 is now known as tadzik
whiteknight is there any way to get some extra diagnostics about library loading? 15:45
15:45 ash_ joined
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++
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?
cotto you're trying
are you working on the svn branch?
whiteknight no, on github
I have the lib building, and it gets put in ./dynext/instrument_group.so 15:48
I have a test file that does "$P0 = loadlib './dynext/instrument_group'"
but it always returns false
cotto You might just work on the svn branch, since that's already in core.
whiteknight actually, I
'm working on a fork 15:49
github.com:Whiteknight/parrot-instrument
I just pushed a bunch of fixes, if you want to take a look at it
cotto looks
15:50 mikehh joined
cotto whiteknight, do you know that parts of those pmcs are generated? 15:52
whiteknight what?
there are parts?
cotto I don't see the scripts in the git repo. 15:53
whiteknight what scripts?
cotto I'm pretty sure I got him to put them in svn.
just a sec
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:54
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
cotto tools/build/gen_*_stubs.pl in the gsoc_instrument branch
They're only needed for updating the PMCs, but they'll save some sanity when the need arises.
whiteknight Yeah, I just fixed the one with all the vtables 15:56
cotto That's what brought the scripts to mind.
I think the best approach would be to sync gsoc_instrument with trunk, copy your changes from github and go from there. 15:57
Parrot's not stable enough for that kind of project to live out in the wild where it could easily be ignored and bitrot. 15:58
whiteknight okay, the gsoc_instrument branch has all the most recent code? 16:00
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
whiteknight ok
cotto I need to verify that though.
whiteknight well, i do have it building. That still doesn't explain why I can't loadlib the generated .so
cotto yup, plus a single change
dalek rrot: r49408 | mikehh++ | trunk/config/auto (2 files):
set svn properties
 16:02
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
whiteknight a tag is just acopy 16:04
you can always sync with a copy
cotto I'd be surprised if it didn't work, I just haven't needed to do it before.
moritz that's the beauty and the problem with tags
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
building gsoc_instrument now... 16:07
16:10 cognominal left 16:13 cognominal joined
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:14
16:15 lucian left
whiteknight bitrot is definitely not a great reason to move code into core, even if there is a beneficial effect for it 16:16
these PMCs really do poke into Parrot internals more than most things should
16:16 GodFather left, lucian joined
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 rrot: r49409 | mikehh++ | trunk/config/auto/stat.pm:
replace hard tabs
whiteknight I would like to see things like e.g. the debug and tracing runcores be based on these instrument PMCs 16:20
because then we get the ability to easily plug new tracers/debuggers, to subclass them, etc 16:21
we could plug our debug tool into our profiling tool and make our debugger run faster
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
16:22 theory joined
cotto The trace and profiling runcores are broken because no tests covered the behavior that broke. 16:22
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
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\\
cotto prove t/dynpmc/instrument* t/library/instrument_* 16:26
the parallel build is goofy in the branch. You might need to run a serial build.
(They're also run as part of make test, but you're probably not that patient.)
They work fine on my x86 ubuntu box. 16:28
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:36
cotto mikehh, could you run those tests in the gsoc_instrument branch? 16:45
prove t/dynpmc/instrument* t/library/instrument_*
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:49
16:51 patspam joined, patspam left
mikehh cotto: 'k 16:54
cotto thanks 17:02
I'm working the dependencies, but expect bumps in the parallel build. Re-running make after make -jN fails works fine. 17:03
fix committed 17:05
(But don't worry if you already have it build. It's just a makefile fix.)
s/build/built/ 17:06
whiteknight cotto: okay, I see the tests running now. I did a make test but didn't see those tests get run 17:14
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
good idea
whiteknight this particular operation would be much easier in git 17:18
dalek rrot: r49410 | cotto++ | branches/gsoc_instrument/config/gen/makefiles/root.in:
add dependencies for Instrument/Instrument.pir, hopefully fixing the parallel build
cotto patience
rrot: r49411 | whiteknight++ | branches/gsoc_instrument2:
creating a new branch to work on getting the gsoc_instrument work up to date
cotto I wonder if TT #1745 will bite gsoc_instrument too. 17:21
whiteknight blah. I need to focus on one problem at a time 17:23
cotto but there are so many to choose from
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:32
dalek rrot: r49412 | whiteknight++ | branches/gsoc_instrument2:
deleting this branch, trying something else
 17:34
mikehh anyway will do some more testing later, got to do something else at the moment 17:35
17:37 tadzik left 17:43 dukeleto_ joined
whiteknight the gsoc_instrument merge to trunk is going to be extremely messy, it seems 17:51
dukeleto_ 'ello 17:54
18:02 bluescreen joined 18:08 Andy joined 18:09 dukeleto_ left 18:12 dukel3to joined 18:28 Andy left 18:29 Andy joined 18:44 tadzik joined 18:52 whiteknight left, lucian_ joined 18:55 lucian left 19:03 Andy left 19:09 Andy joined 19:31 whiteknight joined 19:33 Andy left 19:48 Andy joined
whiteknight okay, let me refine my statement from earlier. The gsoc_instrument branch merge is going to be *EXTREMELY* messy 19:52
I've been typing "p" for the past 5 minutes, and the end is nowhere in site 19:53
sight
in SVN, the new rule should be "Never, ever ever ever update your branch from trunk." 19:54
20:04 tcurtis joined
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:08
20:10 petdance joined 20:12 petdance left
whiteknight Text conflicts: 113 20:12
Property conflicts: 2
Tree conflicts: 88
plobsing: I was actually thinking about that exact kind of thing this morning
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
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.
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.
whiteknight plobsing: yes, that's a very good point
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
we don't have anything like that
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:19
whiteknight it would make for an interesting project 20:21
in the mean time, I think adding a "smoke all" target to plumage would be fantastic
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.
sorear whiteknight: I think more useful than dfailures/dt would be dfailures/dparrotrev (external rev fixed) 20:26
20:29 M_o_C left 20:33 ash_ left
whiteknight sorear: that does sound useful too. 20:38
of course, the usefulness of hypothetical tools is limited by how much they don't exist
very likely, we will just use whatever tool somebody makes for us first
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.
whiteknight logs off 20:46
20:46 whiteknight left 21:11 tadzik left 21:20 kid51 joined
dukel3to msg whiteknight help.github.com/splitting-a-subpath...-new-repo/ <-- could be useful for you for the languages repo 21:25
aloha OK. I'll deliver the message.
kid51 ~~
dukel3to kid51: how goes it?
kid51 Okay. A
Have been in Toronto for past few days. 21:26
dukel3to kid51: did you vacation start already?
kid51 Did lightning talks at tpm Thursday night.
Vacation I
dukel3to kid51: what needs doing re: the pdx parrot hackathon?
kid51 Vacation II starts in a week
Well, as you see, I've secured space.
So now, we just need to get people to come! 21:27
dukel3to kid51: we need a plan for that 21:28
kid51: here is a nice example of hackathon marketing loqi.me/poll/geoloqi-hackathon-2010 21:29
21:40 jsut_ joined 21:45 jsut left
kid51 dukel3to: Yes, but that's a bit more advanced than what I think we're aiming for right now. 21:50
It's more than I can think of organizing from 2800 miles away :-)
dukel3to kid51: i hear ya. i just wanted to give it as an example of marketing for a hackathon 21:52
kid51: it is something to aim for
dukel3to goes into the rare PDX sunshine
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 nopaste.snit.ch/23924
kid51 ... whereby "customer" I mean: Any OS project building on top of parrot that has >= 2 active committers. 21:59
22:01 bluescreen left 22:02 lucian_ left
plobsing sorry about nopaste. not intended for this channel 22:03
22:10 bluescreen joined
dalek rrot: r49413 | nwellnhof++ | trunk (6 files):
[str] Add own encoding for null string
 22:25
rrot: r49414 | nwellnhof++ | trunk (2 files):
[str] String API optimizations

preparation of the following commits that will move these checks directly into the encoding functions, and switch a lot of Parrot code to the new string macros. With the exception of STRING_length and STRING_byte_length, the string macros don't check the string argument for NULL pointers. So the following commits also fix some places that still didn't use STRING_IS_NULL and STRINGNULL.
rrot: r49415 | nwellnhof++ | trunk (23 files):
[str] Switch to STRING_ord macro

Also modifies Parrot_str_indexed to accept negative indices as well. The old string_ord function can finally be deprecated.
rrot: r49416 | nwellnhof++ | trunk (46 files):
[str] Switch to STRING_equal macro
bluescreen guys, what would be the best method to debug parrot's guts I'm trying to take a look at trac.parrot.org/parrot/ticket/1769 ? 22:38
dalek rrot: r49417 | nwellnhof++ | trunk (25 files):
[str] Switch to STRING_substr macro
 22:41
rrot: r49418 | nwellnhof++ | trunk (8 files):
[str] Switch to STRING_hash macro
rrot: r49419 | nwellnhof++ | trunk (8 files):
[str] Switch to STRING_compare macro
rrot: r49420 | nwellnhof++ | trunk (13 files):
[str] Switch to STRING_index macro

changes the index opcode to throw when the source string is null. If this change causes problems, we can add a deprecation notice or revert it.
rrot: r49421 | nwellnhof++ | trunk/src/string/encoding (3 files):
[str] Make some string code work without ICU
rrot: r49422 | nwellnhof++ | trunk/src/string/api.c:
[str] Optimize str_rep_compatible
rrot: r49423 | mikehh++ | trunk/src/string/encoding/null.c:
add svn properties
plobsing bluescreen: gdb is my first resource with such problems. 22:44
bluescreen is parrot compiled with symbols by default? 22:45
plobsing should be (no opt generally includes symbols). but rakudo's default parrot doesn't IIRC. 22:48
bluescreen that's ok I'm using trunk's parrot 22:49
mikehh get g++ build errors: 22:50
src/string/encoding/null.c:245:13: error: redefinition of ‘STR_VTABLE* Parrot_null_encoding_ptr’
./include/parrot/encoding.h:29:13: error: ‘STR_VTABLE* Parrot_null_encoding_ptr’ previously declared here
builds ok with gcc 22:52
cotto Hmmm. I tried syncing gsoc_instrument with trunk and got a single conflict on MANIFEST. 23:04
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 nopaste.snit.ch/23926
23:05 nwellnhof joined
cotto svn-- 23:05
aloha, karma svn
aloha, status 23:06
aloha msg aloha aloha
aloha cotto: OK. I'll deliver the message.
kid51 nwellnhof: Can you take a look at nopaste.snit.ch/23926 ? After your recent commits, I got a make fulltest PASS on Linux/i386, but had build failure on other system
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.
mikehh kid51: it's the same error I get trying to build with g++, it builds for me with gcc (see above)
nwellnhof i'm on it.
kid51 mikehh: Consistent. On Darwin/PPC, I use gcc for 'cc' but g++ for --link and --ld 23:10
23:11 kid51 left
mikehh nwellnhof: I get (with g++ build): 23:11
src/string/encoding/null.c:245:13: error: redefinition of ‘STR_VTABLE* Parrot_null_encoding_ptr’
./include/parrot/encoding.h:29:13: error: ‘STR_VTABLE* Parrot_null_encoding_ptr’ previously declared here
GeJ Bonjour everyone. 23:17
I think I have dreamt of Data::Dumper last night. Is it serious doctor?
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
can 23:19
sorry about the pun :-}
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
nwellnhof: looks good 23:26
23:27 Searle joined
dalek rrot: r49424 | nwellnhof++ | trunk/include/parrot/encoding.h:
[str] Fix g++ build
 23:27
23:30 Searle left
nwellnhof btw, the branches charset_massacre and string_macros can be deleted. 23:37
23:38 dukel3to left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#401) fulltest) at r49424 - Kubuntu 10.10 RC amd64 (g++-4.5) 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!