Camelia, the Perl 6 bug

IRC log for #parrot, 2009-05-29

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:18 bacek_ joined #parrot
00:20 dalek TT #426 closed by jkeenan++: install_files.pl and install_dev_files.pl have a fair bit of duplicate ...
00:20 uniejo joined #parrot
00:28 dalek parrot: r39229 | jkeenan++ | trunk/docs (3 files):
00:28 dalek parrot: Applying patch contributed by amk in https://trac.parrot.org/parrot/ticket/704:  minor touch-ups to documentation.
00:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39229/
00:28 dalek decnum-dynpmcs: r69 | darbelo++ | trunk/src/pmc/decnum.pmc:
00:28 dalek decnum-dynpmcs: Add is_equal VTABLE.
00:28 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=69
00:33 dalek TT #704 closed by jkeenan++: Minor markup/grammar fix for Parrot book
00:48 dalek decnum-dynpmcs: r70 | darbelo++ | trunk/src/pmc/decnum.pmc:
00:48 dalek decnum-dynpmcs: Add get_bool VTABLE.
00:48 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=70
00:57 Austin_Hastings left #parrot
01:00 Infinoid kid51: Does post-1.2.0 parrot build for you on darwin?
01:04 mikehh joined #parrot
01:05 dalek partcl: r381 | coke++ | trunk/t/cmd_return.t:
01:05 dalek partcl: add a TODO test - we need this feature for [unknown] handling to work.
01:05 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=381
01:06 Coke Infinoid: it builds for me on x86/10.4.x
01:07 Coke which implies very little about kid51's machine, if history is any guide.
01:08 Infinoid ok.  his result will be a good indication of whether #675 is closable
01:25 dalek partcl: r382 | coke++ | trunk/t/cmd_return.t:
01:25 dalek partcl: fix test plan
01:25 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=382
01:25 dalek partcl: r383 | coke++ | trunk/src/macros.pir:
01:25 dalek partcl: library/ is now harmful when loading stdlib.
01:25 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=383
01:28 kid51 Infinoid:  Yes.
01:30 kid51 Here's a Smolder from last night at r39203:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/22842
01:30 kid51 10.4 PPC
01:33 Whiteknight joined #parrot
01:39 kid51 Infinoid:  I got successful builds at 39171 and 39203.  So I see no obstacle to closing it.
01:39 dalek partcl: r384 | coke++ | trunk/ (2 files):
01:39 dalek partcl: add support for [return -options], pass the todo test.
01:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=384
01:42 tetragon joined #parrot
01:43 Coke Anyone wanna write some PIR? =-)
01:47 cotto how shiny is it?
01:47 Coke not very.
01:47 Coke working on it now, think I can hack it out.
01:50 dalek TT #675 closed by Infinoid++: r38804 breaks on darwin/OSX
02:09 Coke cotto: commit incoming. Think I got it.
02:09 Coke thanks.
02:13 dalek partcl: r385 | coke++ | trunk/ (2 files):
02:13 dalek partcl: add support (and a test) for [return -level 1]
02:13 dalek partcl: this level is basically the same as a normal return, we don't add any
02:13 dalek partcl: infrastructure to support more complicated return levels, but this is
02:13 dalek partcl: a requirement for unknown
02:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=385
02:34 darbelo joined #parrot
02:35 janus joined #parrot
02:38 dalek partcl: r386 | coke++ | trunk/runtime/builtin/return.pir:
02:38 dalek partcl: silently ignore 2 valid return options.
02:38 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=386
02:54 davidfetter joined #parrot
02:57 ZuLuuuuuu joined #parrot
03:02 dalek partcl: r387 | coke++ | trunk/ (2 files):
03:02 dalek partcl: add a barebones [namespace which]
03:02 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=387
03:24 mugwump joined #parrot
03:24 mugwump hey I notice that http://alioth.debian.org/projects/pkg-parrot/ only has 0.7.0 debs, but 1.0.0 are in Debian
03:25 mugwump ...and there's no debian/ on svn trunk
03:26 Coke allison's probably the best person to talk to about that.
03:26 mugwump also, rakudo stable seems to require parrot svn
03:26 mugwump at least, in terms of the Configure.pl
03:26 dalek partcl: r388 | coke++ | trunk/ (3 files):
03:26 dalek partcl: use init.tcl's [unknown] instead of trying to roll our own.
03:27 dalek partcl: - bare [parray a] now auto-loads parray.tcl via the magic of [unknown] +2 tests.
03:27 mugwump what parrot release is r39025?
03:27 dalek partcl: - unknown is failing to barf for a deleted command: -1 tests.
03:27 dalek partcl: - invalid calls to [parray] that require an autoload are failing. [catch] needs
03:27 dalek partcl: to be smarter, but I don't quite know which smarts it needs yet.
03:27 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=388
03:29 Theory joined #parrot
03:30 * mugwump copies parrot-1.0.0/debian to parrot-1.2.0, runs debchange -v 1.2.0-1, crosses fingers
03:31 Coke mugwump: yes.
03:31 Coke rakudo requires a very specific minimum parrot version that isn't necessarily a release. (at least for rakudo-svn)
03:31 mugwump rakudo-svn ?  ;)
03:31 Coke I think rakudo-release is supposed to work with parrot-release-just-prior.
03:31 Coke rakudo-git
03:31 mugwump :D
03:31 pmichaud Rakudo releases correspond to parrot releases, yes.
03:32 pmichaud but Rakudo head development often (usually) requires versions of parrot since its latest release
03:32 mugwump hey wow I got parrot 1.2.0 debs out of that
03:32 mugwump would it be possible to make that explicit?  ie, when changes in parrot are required the version is bumped?
03:32 pmichaud that's what happens now.
03:33 mugwump ok
03:33 mugwump parrot_config --dump | grep ^revision
03:33 mugwump revision => '0'
03:33 mugwump :(
03:33 pmichaud I can't do anything about parrot not reporting the correct revision number, though.
03:34 pmichaud short of figuring out hwo to get it to report the correct one :-|
03:34 mugwump hmm
03:34 Coke if you depend on a release and not an svn revision, shouldn't you be tracking either revision or release, depending on your needs?
03:35 pmichaud do the released versions of parrot not provide a revision number?
03:35 Coke I don't think it's safe to always assume that there is a revision of trunk that corresponds to a release.
03:35 mugwump Well, I built from the debian source
03:35 mugwump ie the tarball release
03:35 mugwump maybe it's getting that number from an 'svn info' command or something, which doesn't work because it's a tarball release
03:35 pmichaud that's possible.
03:36 mugwump this is probably easily fixable by making rakudo's Configure.pl allow minimum versions to be release versions
03:36 pmichaud I don't quite understand that.
03:36 mugwump build/PARROT_REVISION is currently a svn rev
03:37 mugwump it could also have a release revision, if it corresponds to that
03:37 Coke s/release version/, to avoid confusion.
03:37 mugwump ie what 'parrot_config VERSION'
03:37 mugwump is returning
03:37 Coke so, r32343 or "1.2.0"
03:37 mugwump right
03:37 pmichaud Oh, I get it.
03:38 pmichaud so, PARROT_REVISION of 1.2.0 means we check VERSION, but anything else means we check revision
03:38 Coke I'd flip it and have r.* mean revision and anything else be version, but yes. =-)
03:38 pmichaud iwbni Parrot provided an easy-to-compare revision number.
03:38 mugwump sure.  I'd think having both there, to depend on either SVN revision X _or_ release version Y
03:38 pmichaud mugwump: "or" probably doesn't work.
03:39 Andy joined #parrot
03:39 Coke pmichaud: in general, you can't say revision X at head == release FOO.
03:39 pmichaud If Rakudo depends on a revision of parrot that comes after the release, allowing a release version doesn't work
03:39 mugwump yes of course
03:39 pmichaud Coke: I can't?
03:39 Coke not in general, no.
03:39 mugwump but presumably a random svn revision of parrot won't identify as '1.2.0'
03:39 mugwump or maybe it will
03:39 Coke we happen to have released most of our revisions that way so far.
03:39 pmichaud actually, it does.
03:40 Coke but there's nothing stopping someone from tagging from a branch.
03:40 pmichaud Coke: I don't understand.
03:40 mugwump and ... if you build from a branch, what's your revision number ?  :->
03:40 Coke pmichaud: branch trunk to "release_1.3_prep". cut the release from there, including the tag.
03:40 Coke fold those changes back into trunk.
03:40 Coke delete the branch.
03:40 * mugwump prefers git-describe over svn r-numbers any day
03:41 Coke no revision at trunk corresponds to teh release.
03:41 pmichaud ah, and updates occurred to trunk in between the branch and mergeback
03:41 Coke (presuming a commit or two in trunk while the branch is going.)
03:41 Coke right. we happen to not do that, for the most part, but at least one release did it that way.
03:41 pmichaud yes, that's a possibility.
03:42 Coke I would say, if you've specified a revision, you really mean "I know the latest release is no longer any good.", but if you specify a release, then you want that release # to match (and that would include the 1.2.0-devel notation for svn changes post-release.)
03:43 Coke assuming you have a way for users to say "I already have a parrot, please use mine."
03:43 pmichaud We do.
03:43 Coke so the only thing to worry about (I think) is a user with no parrot when you've said "release 1.2" - and I think then you can get away with checking out the tag'd version of the release.
03:43 pmichaud I again repeat my point that "iwbni parrot provided an easy-to-compare version number"  :-)
03:44 Coke pmichaud: this is kind of apples and oranges.
03:44 pmichaud comparing "1.2.0" isn't easy
03:44 pmichaud i.e., it's not easy to determine that 1.10 is in fact > 1.2
03:44 pmichaud Coke: I think you're misinterpreting what I'm saying.
03:45 Coke OH.
03:45 Coke yes, I am.
03:45 Coke you have perl5 at the time, no?
03:45 pmichaud Yes.
03:45 Coke (I was thining you wanted 1.2 to compare nicely to r14343. =-)
03:46 pmichaud No, that's not what I was asking for.  :-)
03:46 Coke Perl::Version ?
03:47 pmichaud pmichaud@plum:~$ perldoc Perl::Version
03:47 pmichaud No documentation found for "Perl::Version".
03:47 Coke http://search.cpan.org/~andya/Perl​-Version-1.009/lib/Perl/Version.pm
03:47 pmichaud I'd prefer not to make that my first (and only) required CPAN module.
03:48 * pmichaud notes in passing that Rakudo release numbers are easy to compare.
03:48 Coke If you ask, I'm sure someone can whip up something that takes converts 1.2.0 and 1.10.0 to 1.002000 and 1.010000 as that module does and then you can compare those.
03:48 pmichaud anyway.
03:48 pmichaud oh, I can whip that up also.
03:48 Coke we already had that discussion and everyone lost.
03:48 pmichaud agreed, we lost.
03:50 mugwump http://github.com/samv/rakudo/commit/07​dc258cd83b7269ddde5323ffefbdf28870a5b7 ?
03:50 mugwump gah, whitespace
03:50 mugwump > Patches to Rakudo should be submitted to RT; pull requests via github tend to be ignored, discarded, or take a very long time to process.
03:50 mugwump FAIL
03:51 pmichaud mugwump: the problem with that approach is that if someone doesn't have any version of Parrot installed, Configure.pl doesn't know what revision to pull from svn
03:51 mugwump ah true
03:52 mugwump if only svn supported tags
03:52 Coke 1.2.0 == tags/RELEASE_1_2_0
03:52 mugwump ah yep
03:52 pmichaud I don't want to pull from tags/ because then "svn up" doesn't dtrt
03:52 mugwump well use svn switch then
03:53 pmichaud hmmm, switch might work
03:53 * mugwump tries building parrot HEAD against parrot 1.2.0...
03:54 pmichaud I'd still be concerned that one of the devels might accidentally commit to tags/ though.
03:55 pmichaud I'm thinking PARROT_REVISION needs to remain the same, and we just need another way to identify when it's okay to use a release version.
03:55 pmichaud oh.
03:55 mugwump \nrevision
03:55 mugwump ?
03:55 pmichaud PARROT_REVISIOn could be
03:55 pmichaud (for example)
03:56 pmichaud r39025 1.2.0
03:56 pmichaud actually
03:56 pmichaud "39025 1.2.0"
03:56 pmichaud which means that we want revision 39025, but will accept 1.2.0 if the revision number isn't available
03:56 pmichaud if we later bump it, it becomes
03:56 pmichaud "39214"
03:56 pmichaud which means that we absolutely require r39214, and no released version of parrot is sufficient
03:58 pmichaud afk for a short while
04:01 tetragon joined #parrot
04:03 mugwump hmm lots of $(BUILD_DIR)'s in rakudo's build/Makefile.in
04:03 mugwump those won't exist with a binary install of parrot
04:04 davidfetter OH HAI
04:05 davidfetter anybody in KL for malaysia osconf?
04:07 dalek TT #718 created by wayland++: Documentation on MANIFEST files should be moved, and other doco improved.
04:10 mugwump darn my parrot packages didn't install a 'runtime' dir
04:11 wayland76 mugwump: Which distro
04:11 purl Which distro are they in?
04:11 mugwump wayland76: I took the parrot source package from unstable, copied the debian/ dir into the 1.2.0 release, and built
04:11 wayland76 OK
04:11 mugwump hmm I'm not sure what the right thing to do with this Makefile.in is
04:11 mugwump eg
04:11 mugwump PARROT        = $(BUILD_DIR)/parrot$(EXE)
04:11 wayland76 I found that Rakudo wouldn't build on installed Parrot
04:12 mugwump yeah me too, I'm trying to patch it
04:12 wayland76 So I sent in a patch, which hasn't been accepted yet
04:12 wayland76 I'll send you the ticket number
04:12 wayland76 ...
04:12 wayland76 https://trac.parrot.org/parrot/ticket/712
04:13 wayland76 I sent this patch to a Gentoo packager who wanted it too
04:13 wayland76 Rakudo also needs patching to work with RPM
04:13 wayland76 I can send you that link too, if needs be
04:15 mugwump can you just put a link to my github parrot fork on that?
04:16 mugwump gotta scram
04:16 mugwump also note that I'm pretty sure that 'Makefile.in' shouldn't be using BUILD_DIR if it's using an installed parrot
04:17 mugwump I'll sign up next time :)
04:17 mugwump thanks people... &
04:19 nopaste joined #parrot
04:33 pmichaud back again
04:33 pmichaud I'm seeing two failures in trunk:
04:34 pmichaud t/dynoplibs/myops.t    1   256    10    1  7
04:34 pmichaud t/pmc/eval.t           1   256    17    1  12
04:34 pmichaud known/expected?
04:41 dalek parrot: r39230 | pmichaud++ | trunk (2 files):
04:41 dalek parrot: [core]  Add "get_subid" method to Sub PMC.
04:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39230/
05:08 Theory joined #parrot
05:59 cognominal joined #parrot
06:00 afk_coke codetest failures again: http://smolder.plusthree.com/app/p​ublic_projects/smoke_report/22895
06:05 dalek parrot: r39231 | coke++ | trunk (3 files):
06:05 dalek parrot: pass trailing_whitespace.t
06:05 dalek parrot: http://smolder.plusthree.com/app/pu​blic_projects/report_details/22895
06:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39231/
06:28 dalek parrot: r39232 | NotFound++ | trunk/src (2 files):
06:28 dalek parrot: [cage] add ASSERT_ARGS to 2 functions that lacked it
06:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39232/
06:32 Coke ... you beat me.
06:33 Coke NotFound++
06:37 dalek partcl: r389 | coke++ | wiki/ParrotIssues.wiki:
06:37 dalek partcl: no more showstoppers; re-org remaining items.
06:37 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=389
06:42 dalek partcl: r390 | coke++ | wiki/ParrotIssues.wiki:
06:42 dalek partcl: This bug we no longer care about.
06:42 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=390
06:43 iblechbot joined #parrot
06:46 Coke TT #66 has an old segfault that's still there.
06:46 Coke If anyone wants some C code to plow through. =-)
06:52 dalek partcl: r391 | coke++ | wiki/ParrotIssues.wiki:
06:52 dalek partcl: segfaults are bad, especially when running spectests.
06:52 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=391
06:57 * Coke starts up a spectest run to see how bad the damage is.
07:02 dalek partcl: r392 | coke++ | trunk/tools/ (2 files):
07:02 dalek partcl: Update testing tools to work with an installed parrot.
07:02 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=392
07:06 Coke frabulous joy. :|
07:06 Coke out of memory panic.
07:07 nopaste "tene" at 166.70.38.237 pasted "Weird behavior under rakudo for pmichaud++" (2 lines) at http://nopaste.snit.ch/16711
07:07 Tene pmichaud: that's $☕
07:08 Coke what does it do?
07:08 Coke (is it another "parrot was expecting an ascii string bug found unicode" bug?
07:08 Tene seems to just spin the cpu
07:09 Tene I've left it running ever since I tried it.  Still no output.
07:09 Tene steadily increasing memory usage.
07:09 Tene About to start going into swap...
07:09 Tene any second now...
07:09 Tene SWAP!
07:10 Tene That was exciting.
07:12 Coke I'm at 18% of the memory on feather right now testing tcl.
07:12 Coke ... out of memory panic, dump core.
07:13 Tene yay!
07:18 dalek TT #719 created by coke++: out of memory running a tcl spec test
07:19 Coke that error message should not reference parrot bug or the email list, but probably trac.
07:21 dalek partcl: r393 | coke++ | wiki/ParrotIssues.wiki:
07:21 dalek partcl: YA "crash a spectest" bug.
07:21 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=393
07:46 preflex joined #parrot
08:12 donaldh joined #parrot
08:58 mikehh and the latest make -k fulltest report at r39232 on Ubuntu 9.04 i386
08:59 mikehh codetest, manifest_testsm examples_tests FAIL, all others PASS
09:06 nopaste "mikehh" at 90.209.206.247 pasted "make -k fulltest summary at r39232" (98 lines) at http://nopaste.snit.ch/16712
09:16 cognominal joined #parrot
09:37 wayland76 joined #parrot
09:37 bacek joined #parrot
09:44 dalek parrot: r39233 | chromatic++ | trunk/compilers/imcc (5 files):
09:44 dalek parrot: [IMCC] Fixed several memory leaks of string constants in IMCC.  There may be a
09:44 dalek parrot: few more, but these are the pesky ones I had trouble tracking down for so long.
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39233/
09:54 dalek parrot: r39234 | chromatic++ | trunk/src/pmc/continuation.pmc:
09:54 dalek parrot: [PMC] Plugged the memory leak of a Parrot_cont in the destination PMC returned
09:54 dalek parrot: from Continuation's clone().
09:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39234/
09:54 dalek parrot: r39235 | chromatic++ | trunk/src/pmc/sub.pmc:
09:54 dalek parrot: [PMC] Tided code; no functional changes.
09:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39235/
09:55 ZuLuuuuuu joined #parrot
10:07 dalek parrot: r39236 | chromatic++ | trunk/src/pmc/lexpad.pmc:
10:07 dalek parrot: [PMC] Plugged a memory leak in the LexPad PMC by enabling its active destroy
10:07 dalek parrot: flag.  All PMCs with ATTRs need this flag and a destroy entry.
10:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39236/
10:11 dalek parrot: r39237 | chromatic++ | trunk/src/pmc/fixedintegerarray.pmc:
10:11 dalek parrot: [PMC] Fixed a memory leak when thawing a FixedIntegerArray PMC; it didn't have
10:11 dalek parrot: its active destroy flag set.
10:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39237/
10:21 cognominal joined #parrot
11:07 muixirt joined #parrot
11:11 burmas joined #parrot
11:14 muixirt please, someone fix pdd19_pir.pod line #1055
11:20 donaldh joined #parrot
11:56 muixirt2 joined #parrot
12:11 dalek TT #718 closed by jkeenan++: Documentation on MANIFEST files should be moved, and other doco improved.
12:14 Austin_Hastings joined #parrot
12:14 Austin_Hastings ¡Hola, #parrot!
12:24 Coke muixirt: done. Thanks.
12:26 dalek parrot: r39238 | coke++ | trunk/docs/pdds/pdd19_pir.pod:
12:26 dalek parrot: fix pod typo.
12:26 dalek parrot: Courtesy muixirt from #parrot.
12:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39238/
12:26 Whiteknight joined #parrot
12:32 ZuLuuuuuu joined #parrot
12:35 muixirt Coke, sorry for bothering you, but I overlooked the other places with =cut
12:35 muixirt it seems more complicated than i thought :-)
12:44 jsut joined #parrot
12:45 iblechbot joined #parrot
12:45 dalek rakudo: 77b920a | masak++ | src/builtins/eval.pir:
12:45 dalek rakudo: [src/builtins/eval.pir] s/@INC/@*INC/
12:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​7b920ac2891d23bf7dd8c2530c137a8f659ecee
13:00 gryphon joined #parrot
13:02 Andy joined #parrot
13:05 hudnix joined #parrot
13:23 Coke If you can make a patch, that'd be great; if not, if you can open a ticket (well, either way, do that.), we can programatticaly go through. I have to bug out right now, though.
13:24 Coke chromatic++ for fixing memory leaks.
13:26 Whiteknight chromatic++ # Agreed
13:26 Whiteknight karma chromatic
13:26 purl chromatic has karma of 2032
13:26 Whiteknight karma karma karma chameleon
13:26 purl karma karma chameleon has neutral karma
13:27 Whiteknight karma chameleon
13:27 purl It comes and goes.
13:28 Whiteknight now THAT's comedy
13:29 Infinoid (karma karma chameleon)++
13:29 Infinoid (karma karma chameleon)--
13:32 Whiteknight good morning Infinoid
13:32 Infinoid ohai
13:33 Whiteknight I don't know if you have taken a look at the io_rewiring branch lately. It shows some of what I was envisioning
13:33 * Infinoid is updating now
13:33 Whiteknight Some test failures still though in the packfile stuff, I suspect the FileHandle attributes are hardcoded somewhere
13:34 Whiteknight but I'm not too worried about that yet
13:39 Infinoid so, Handle objects can't be created directly?
13:40 * Infinoid is wanting an fdopen()-like interface for the Pipe stuff
13:41 Whiteknight no, Handle is abstract
13:41 purl okay, Whiteknight.
13:41 Whiteknight purl forget Handle
13:41 purl Whiteknight: I forgot handle
13:41 Infinoid ok, I'll create a subclass for pipe endpoints (but this subclass will be *very* generic)
13:41 Whiteknight okay. Just make sure your pipes "does pipe"
13:42 Whiteknight or "does file", if the interface is consistent
13:42 Whiteknight or whatever
13:42 Whiteknight we may need to create a src/io/pipes.c file, if you have a lot of specialized ode
13:42 Infinoid it isn't consistent, no seek()
13:43 Infinoid there's very little specialized code... maybe some OS-specific stuff to create the things, that's all
13:43 Infinoid but I think we already have that
13:43 Whiteknight okay, then nevermind that
13:44 Whiteknight Once we get a little further, I would like to time it out and see if we have an actual speed improvement using this mthod
13:45 Infinoid I doubt it.  I'm doing this for flexibility, not speed
13:45 Infinoid (unless you've improved something else?)
13:45 Whiteknight Removing the PCCINVOKE calls is going to be a major performance improvement
13:46 Infinoid oh, awesome
13:46 Whiteknight especially for programs that make a lot of calls
13:46 Infinoid I don't understand tho... don't you still need PCC to call METHOD read(INTVAL length)?
13:49 skids joined #parrot
13:49 Whiteknight right, but there are two entrypoints: FileHandle.'read'(), and the read opcode
13:49 Whiteknight the opcode used to call the method
13:50 Whiteknight now, it doesn't
13:50 Infinoid oh, ok.  I'm looking at your changes to Parrot_io_flush() in r39211
13:51 Infinoid So will that if/else chain be expanded for every IO type?
13:51 Whiteknight no, only for every IO role
13:52 Whiteknight so there is a "file" role, and all PMCs that do that role will perform that logic
13:52 Whiteknight so FileHandles and all subclasses of it
13:52 Whiteknight there's also a socket role and a pipe role, and that's all I can think of
13:52 Whiteknight oh, a string role too, for StringHandle and descendents
13:52 Infinoid does role define the API or the implementation?
13:53 Whiteknight I'm thinking the API
13:53 * Infinoid is a little worried about things that claim to support the "file" API, but have extra layers of buffering that Parrot_io_flush_filehandle() doesn't know how to handle
13:53 Whiteknight you're right about that, it is worrisome
13:53 Whiteknight there are improvements that need to be made to this methodology still
13:54 Infinoid Sorry.  I'm not trying to put you through a full code review, I'm just trying to understand your strategy so I can work with it :)
13:54 Whiteknight no, code review is very good. Want to work out the kinks earlier rather then later
13:54 purl okay, Whiteknight.
13:54 Whiteknight purl forget code review
13:54 purl Whiteknight: I forgot code review
13:57 dalek TT #720 created by Klaus++: [PATCH] Typos in pdd19_pir.pod
13:57 Infinoid ok.  I'm not really sure that the pipe role adds any functionality.  it's *very* basic, none of the extras you get with files or sockets, that's why I would have just returned generic Handle objects if I could
13:58 Infinoid anyway, I'll add pipes first, and then add fcntl() and some kind of setvbuf() frontend to the Handle base class
14:00 Infinoid Do you know if the C library (or the kernel) does isatty() internally to determine whether to do line or block buffering for pipes, or if that's something the shell does itself?
14:01 Infinoid oh, duh.  pipes are never ttys.  nevermind
14:02 Andy joined #parrot
14:07 Whiteknight yeah
14:08 Whiteknight I'm not sure about adding the fcntl and setvbuf stuff to Handle, because not all Handles (StringHandles) support it
14:09 Whiteknight I think the "pipe" role is useful because pipes have different internal data structures then files do, and we don;t ever want to be doing PARROT_FILEHANDLE(pmc) on a pipe PMC
14:11 Infinoid true, but that means the role defines the implementation
14:11 Infinoid for my purposes, having these things as generic as possible is perfect.  For performance purposes, avoiding PCC is also useful
14:11 Infinoid Is there a way we can have both?
14:11 Whiteknight what we have is a conundrum: The PMCs themselves define their implementation and API, so we need foreknowledge of one in order to use the other
14:12 Infinoid I mean, FileHandles will definitely need to be optimal, because we're going to be using them *a lot* before we even start executing user code
14:12 Whiteknight We need to fix the API if we want to properly encapsulate the internals, but not all IO PMCs have a common API. Plus, methods are expensive to call from C
14:13 Whiteknight so we leave the API up in the air, but monkey around with the internals directly.
14:13 pmichaud I'm still bisecting, but some change in Parrot between r39215 (works) and r39225 (fails) has significantly broken Rakudo.
14:13 Infinoid right.  So can we have two kinds of objects?  The low level, bare metal "I know what I'm doing" interface for when we know exactly what the object is, and the "omg what am I?  better be as compatible as possible" alternate base class that uses PCC everywhere?
14:13 Whiteknight pmichaud: how significant?
14:14 pmichaud Whiteknight: significant spectest failures.  Method calls are coming back with "Cannot invoke namespace"
14:14 Whiteknight Infinoid: Sort of. I've been envisioning the built-in PMCs as the bare-metal "IM IN UR INTERNALS" pmcs, and subclasses of those will Just Work
14:14 pmichaud i.e., the following Perl 6 code fails:     my $x = 1+0i;   say $x - $x;
14:15 Whiteknight pmichaud: ouch, that sounds like a doozie.
14:15 Infinoid ok.  the part I'm not clear on is whether we can make both entry points work with the same objects, or if we should just have separate base classes for the two cases
14:15 Whiteknight Did NotFound's PMCProxy work happen in that revisionr range?
14:15 pmichaud Yes.
14:16 Whiteknight pmichaud: check that then, he did some refactoring vis namespaces and PMCProxies
14:16 pmichaud Whiteknight: I had already reviewed (and approved) that patch, so I'm not so sure that's the issue.
14:16 Whiteknight oh, okay then. It's just something that sticks out in my mind as being a potential source of "cannot invoke namespace" problems
14:16 rdice joined #parrot
14:17 pmichaud Whiteknight: agreed; but the problem seems to be specifically related to PIR method invocation more than PMCProxy
14:17 pmichaud r39220 fails
14:17 Whiteknight pmichaud: Okay then
14:18 pmichaud (that's the one that had NotFound's patch, fwiw)
14:18 pmichaud trying r39218
14:20 Whiteknight Infinoid: Two base classes might be reasonable. Nothing says we need to have a single "pretty" hierachy
14:20 Whiteknight The only important point in this is that the IO objects need to be clear about what roles they do and do not does
14:21 Infinoid If does(file) implies details about the object's internals, then that means the genericified version needs to not declare that
14:21 Infinoid if we fall back to the PCC case when we can't find more specific bits to twiddle, that should work
14:22 Whiteknight Infinoid: I like that idea. An expensive fallback is okay if it's rarely used
14:22 Whiteknight the only things about the internals that the does(file) role expects is the names and types of attributes
14:22 Whiteknight or, that's all it should expect
14:23 Infinoid ok.  So we have frontend Parrot_io_* functions calling PMC methods, which call backend Parrot_io_* functions.  That's going to be a little confusing
14:23 Infinoid ok
14:23 Whiteknight that's how the system is now in trunk
14:23 Infinoid yeah, I know
14:24 Whiteknight I want to change it so we have frontend Parrot_io_* functions which call backend Parrot_io_functions only, not methods
14:24 muixirt2 joined #parrot
14:24 Infinoid well, methods are the compatible fallback path
14:24 Infinoid But then those methods must not call Parrot_io_*
14:24 Infinoid or at least, not the same ones
14:25 Infinoid reentrancy is fine but we don't want to get caught in a call loop
14:27 NotFound Are you blaming me?
14:28 pmichaud r39218 passes, trying r39219
14:28 NotFound I deny everything! ;)
14:28 Infinoid I want to implement a socket subclass for TLS/SSL.  In the TLS case, it will act exactly like a Socket, in the SSL case it will begin negotiation immediately, but once it starts doing the crypto thing, it's just going to call functions in libssl and not use parrot's helpers for much of anything
14:28 Whiteknight NotFound: Not blaming, just suggesting that the PMCProxy system is too messy and lousy and convoluted to be tamed by meer mortals
14:29 NotFound Whiteknight: I don't know if I'm mortal, no first hand experience yet.
14:29 Infinoid hmm.  I do wonder how that's going to interact with string encodings tho
14:29 Infinoid NotFound: That's a good thing :)
14:32 AndyA joined #parrot
14:34 NotFound I have a doubt: why we have output opcodes that use stdout by default, but no input opcodes that use stdin?
14:34 pmichaud r39219 passes, retrying r39220 as a check.
14:39 NotFound Whiteknight: for the handle work: maybe an schema like the used by c++ streams make sense: having a class that does formating and related tasks, and buffer classes that does the low level work.
14:39 Whiteknight NotFound: I was thinking about that idea too
14:40 Whiteknight I'm just worried about creating so many new PMC types
14:40 Whiteknight But you're right, separating out buffering logic from the core PMC types is probably a good thing
14:42 pmichaud uh oh, I know why r39220 fails....
14:42 Austin_Hastings Umm, why are these pmc types, necessarily?
14:42 Austin_Hastings At some point you need to get off the pot, and start building parrot in parrot, no?
14:43 NotFound Whiteknight: maybe some types may be classes created at runtime.
14:44 NotFound Austin_Hastings: almost all people wants fast IO.
14:44 Austin_Hastings Granted. How much of Java io is written in C, and how much is in Java?
14:45 NotFound Austin_Hastings: you can build whatever deep hyerarchy of slow classes on top, but the low level support needs to be fast.
14:47 Austin_Hastings NotFound: And the low level support presumably is fast. You've got IO, but no buffering. How many ops do you expect buffering to add?
14:47 NotFound Ops?
14:47 purl Dark room, Strong stomach, Kneepads.
14:48 Whiteknight NotFound, IO classes created a runtime are going to have to be subclasses of an existing tye
14:48 Whiteknight type*
14:48 NotFound I don't think we need any other op right now.
14:48 Austin_Hastings operations, not opcodes.
14:49 NotFound I fail to understand the point.
14:49 Whiteknight pmichaud: Why does it fail?
14:49 Whiteknight (I have my suspicions, but I can't test it here)
14:49 pmichaud because the proxy object is clobbering an existing symbol entry
14:50 Whiteknight oh, okay
14:50 Austin_Hastings NotFound: The point is that buffering is not something that has to be written in C. It could reasonably be a PIR class.
14:50 pmichaud I have a small PIR test program to demonstrate.
14:50 pmichaud (updating to latest Parrot first)
14:52 Whiteknight NotFound: An IOBuffer PMC type, that's low-level and non-subclassable would be a good thing. Then IO objects that does "buffering" would be expected to have a reference to one
14:52 nopaste "pmichaud" at 72.181.176.220 pasted "Proxy / method collision in parrot trunk" (22 lines) at http://nopaste.snit.ch/16715
14:52 Whiteknight If we could find a way to strictly implement buffering behavior through VTABLEs, we could make it subclassable
14:53 Coke ~
14:56 NotFound Whiteknight: I was thinking about having a Handle (or a better name) class that does formatting and buffering, and contains a reference to another type of class that does the real input/output.
14:57 pmichaud Coke:  mind if I revert r39220 ?
14:58 NotFound Then we can have classes derived of Handle that during creation/open create the IO class, set the buffering state or mechanic, whatever.
14:59 Whiteknight NotFound: That's an interesting idea although I worry that not all IO classes will want a buffering facility
14:59 Whiteknight but if we can implement it in an agnostic way in Handle, I would be fine with that
14:59 NotFound Something like the stream/streambuffer ralationship in C++ standard lib.
14:59 Whiteknight NotFound: Yeah
15:00 Whiteknight NotFound: Take a look at the io_rewiring branch. you can add stuff there so long as you don't break the build too bady
15:00 Whiteknight badly
15:00 NotFound Whiteknight: I don't tike I'll have much time this weekend.
15:00 Whiteknight yeah, me either.
15:00 NotFound s/tike/think
15:00 Infinoid for Sockets, buffering is off by default and (for the UDP/nonblocking case at least) I'd like to keep it that way
15:01 NotFound Infinoid: something like a setbuffersize(0) will be easy.
15:01 Infinoid for files and pipes, block buffering is the default, but there are occasionally reasons to change that
15:01 Infinoid yeah, that's why I was thinking of putting some interface to setvbuf() in the base class
15:02 Infinoid I won't get to that in the near future tho
15:03 Infinoid should the "clone" vtable create a deep copy or a shallow one?
15:04 NotFound It must take a gun and kill the programmer that uses it ;)
15:07 Infinoid which Parrot_io_* function can I call to do that?  Seems a bit OS-specific :)
15:08 pmichaud aha, found it.
15:08 pmichaud src/oo.c:409
15:12 NotFound Infinoid: we're expected to do the hard, os dependant tasks, isn't it? ;)
15:13 NotFound I'm almost sure the DeathStation OS has a system call for that,.
15:15 Infinoid Parrot_ex_fail_and_execute​_programmer(PARROT_INTERP)
15:15 NotFound http://www.cramster.com/reference/wi​ki.aspx?wiki_name=DeathStation_9000
15:19 NotFound pmichaud: What's the problem with that line? Isn't that that the proxy creation is supposed to do?
15:19 NotFound Or is the check for namespaci'ng what is wrong?
15:20 donaldh joined #parrot
15:22 pmichaud it's creating the wrong namespace, I think.
15:22 pmichaud There's some incorrect (and circular) in that function.
15:22 pmichaud er, incorrect (and circular) logic
15:23 NotFound Do you think about creating a proxy for the namespace pmc?
15:24 pmichaud first question:   is it ever possible for   interp->vtables[type]->_namespace  to be null?   (line 397)
15:24 Coke pmichaud: checking.
15:24 purl checking is probably just different
15:24 pmichaud regardless,  whatever comes back from ->_namespace certainly *isn't* the hll_ns
15:25 pmichaud so we shouldn't be using that on line 409 to create the ns
15:25 Coke pmichaud: if you revert that, I will start failing tests.
15:25 pmichaud Coke: without reverting it, I'm failing tests.  :-)
15:25 Coke (I believe. i can double check, but I'm pretty sure that's the one that fixed my [namespace children] failures.
15:25 pmichaud See http://nopaste.snit.ch/16715
15:25 pmichaud Coke: yes, that's the one that fixed your namespace children failures.
15:26 Coke I would vote against reverting it, then. =-)
15:26 pmichaud if   interp->vtables[type]->_namespace   can be null, then it's useless for us to try to use it to determine the HLL namespace of the type
15:26 Coke I presume there's a hypothetical patch that makes both of us happy, though.
15:26 NotFound pmichaud: Is supposed to be namespace of the hll that owns the pmc.
15:27 pmichaud really?
15:27 pmichaud I thought it's the namespace of the PMC itself
15:27 pmichaud I think that   interp->vtables[type]->_namespace  is the namespace for the PMC itself
15:27 pmichaud not its hll namespace
15:27 NotFound In that case, my patch was wrong.
15:27 muixirt2 joined #parrot
15:28 pmichaud PMC    *_namespace;     /* Pointer to namespace for this class */
15:28 pmichaud (from include/parrot/vtable.h:271)
15:28 pmichaud anyway, as I was saying
15:28 pmichaud if   interp->vtables[type]->_namespace   can be null, then it's useless for us to try to use it to determine the HLL namespace of the type
15:28 pmichaud if  interp->vtables[type]->_namespace isn't null, then we already have the namespace for the class, and don't need to create it.
15:29 pmichaud I'm working on a fix, but it's causing other failures.
15:30 nopaste "pmichaud" at 72.181.176.220 pasted "Proxy / method collision in parrot trunk, first attempt at fix" (34 lines) at http://nopaste.snit.ch/16717
15:30 NotFound pmichaud: I thinked that this check was just a way of avoiding crashing on unexpected usages.
15:31 pmichaud what check?
15:32 NotFound The nullness of _namespace.
15:32 pmichaud note that _namespace is never checked for nullness in current trunk
15:36 pmichaud I think we just have to force PMCProxy lookup to always work from the parrot hll namespace
15:36 pmichaud (under the assumption that all PMC types live in the 'parrot' HLL)
15:37 NotFound Maybe the cleaner solution will be to add a hll_namespace field to the vtable, and set it during parrot initializtion/dynamic pmc creation.
15:37 pmichaud I doubt that.
15:37 pmichaud The cleaner solution would be to make sure that _namespace is always initialized
15:38 pmichaud (to the correct namespace)
15:38 NotFound Creating the proxies, then,
15:38 Whiteknight I doubt you want to always search for and create PMCProxies in the "parrot" HLL
15:39 pmichaud Whiteknight: at present we don't have any way to create PMCs outside of the 'parrot' HLL.
15:39 Whiteknight pmichaud: oh, I didn't realize that. That's a short-term setback though, not  a long-term decision?
15:39 NotFound Make sure that all PMC get his proxies created during initialization.
15:39 pmichaud NotFound: that's a possibility also.
15:40 NotFound Then we don't need to crate them on demand.
15:40 pmichaud anyway, those are both bigger efforts than I want to do myself at the moment.
15:40 NotFound Same here
15:40 pmichaud so I think I'll just force creation in parrot hll
15:42 Coke pmichaud++
15:42 Coke I appreciate any love tcl gets. =-)
15:42 pmichaud Coke: well, the [namespace children] failure was/is also an issue for Rakudo, if only because it's the source of our slowdown as well.
15:43 Coke still, thanks. =-)
15:43 pmichaud I suspect that Rakudo gets back to its non-HLL speed with the r39220 patch in place.  If only it didn't cause Rakudo to break.  :-)
15:43 Theory joined #parrot
15:47 darbelo joined #parrot
15:48 Coke oooh. I think I can start shipping a little more of the standard library (core tcl written in tcl) and pass more tests.
16:10 AndyA joined #parrot
16:27 AndyA joined #parrot
16:36 pmichaud Coke:  when you get a chance, maybe verify that r39239 still does the right thing for partcl
16:36 pmichaud (just committed)
16:37 pmichaud so far it's doing the right thing for rakudo.  :-)
16:37 pmichaud (running a spectest now)
16:38 dalek parrot: r39239 | pmichaud++ | trunk (2 files):
16:38 dalek parrot: [core]:  Revise r39220 commit for PMCProxy, to avoid conflicts with methods.
16:38 dalek parrot: Adds a test as well.
16:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39239/
16:52 jonathan Turns out methods on Parrot's Role PMC were...not the best idea. :-|
17:06 coke_afk pmichaud: checking now.
17:07 iblechbot joined #parrot
17:10 Coke pmichaud: namespace test passes.
17:10 Coke doing a full make test now.
17:11 Coke ... is it me or are things much faster now?
17:12 Coke it's just me. =-)
17:13 pjcj joined #parrot
17:15 AndyA joined #parrot
17:16 Coke pmichaud: no new failures. Thank you!
17:39 Austin_Hastings joined #parrot
17:53 burmas joined #parrot
17:54 Coke pmichaud: any idea why this test might go into the weeds?
17:54 Coke test regexpComp-22.0.1 {Bug 1810038} {
17:54 Coke evalInProc {
17:54 Coke regexp ($|^X)* {}
17:54 Coke }
17:54 Coke } 1
17:55 ZuLuuuuuu joined #parrot
17:55 Coke evalInProc basically turns it into a sub and runs it there. consumes all memory trying to do the match.
17:56 Coke lemme see if I can make it into a simple regex match and do the same thing.
17:57 Coke yup. just [regexp ($|^X)* {}] goes into the weeds...
18:01 Austin_Hastings Maybe $ is a zero-width assertion and it's matching them repeatedly?
18:01 Austin_Hastings (A similar thing happened to me y-y-day.)
18:02 bacek joined #parrot
18:13 dalek TT #721 created by coke++: PGE::P5Regex consumes all memory
18:14 Whiteknight that does make some sense, PGE is recursive descent and could get tripped up by left recursion if it wasn't checking for those kinds of conditions
18:14 Coke That's an old bug. I just finally isolated it.
18:18 contingencyplan joined #parrot
18:26 nopaste "Coke" at 65.91.151.195 pasted "tcl code that burns through memory:" (38 lines) at http://nopaste.snit.ch/16720
18:27 Coke so that just creates a list with a bunch of integers in it. the list type is a PMC subclass of RPA.
18:28 Whiteknight joined #parrot
18:28 Coke I am guessing there are some PMCs not getting reclaimed in that inner loop.
18:46 mikehh joined #parrot
18:52 Whiteknight do you have the raw PIR file that's generated from that?
19:02 ruoso joined #parrot
19:17 dalek rakudo: 951ffe5 | pmichaud++ | build/PARROT_REVISION:
19:17 dalek rakudo: Bump PARROT_REVISION to get some recent changes, including get_subid.
19:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​51ffe5a402952536c964005d1682fe93bb409c4
19:17 burmas left #parrot
19:24 Coke Whiteknight: no. tcl doesn't use PCT, and the handrolled PIR step I had had to be removed at one point.
19:25 Coke You can run it with parrot -D60 tcl.pbc foo.tcl and get all the auto-gen'd stuff.
19:25 Coke (warning: there's a LOT, especially since are using the tcl equivalent of rakudo's setting)
19:27 Whiteknight oh, right
19:28 Whiteknight (not using PCT)--
19:28 Coke until recently, it was a step back!
19:28 Coke (no HLL)
19:28 Coke btw, http://code.google.com/p/p​artcl/issues/detail?id=59 :P
19:33 dalek partcl: r394 | coke++ | wiki/ParrotIssues.wiki:
19:33 dalek partcl: track another parrotbug
19:33 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=394
19:57 dalek TT #722 created by bobw++: Rewrite of t/pmc/capture.t in PIR
20:09 dalek rakudo: c36d4f2 | pmichaud++ | src/parser/grammar.pg:
20:09 dalek rakudo: Correct qw() and other quotes-that-are-really-functions (TimToady++).
20:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​36d4f22e2735aade4078905d6279ba99bf6ff6a
20:23 amoc joined #parrot
20:26 dalek rakudo: 92c78fa | tene++ |  (2 files):
20:26 dalek rakudo: Fix cross meta ops to work with more than two args
20:26 dalek rakudo: I think this needs to happen for more metas
20:26 dalek rakudo: sbp++
20:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​2c78fae1ef740d44408259d83dcf3e48ac76a0a
20:29 Coke pmichaud: ping.
20:29 pmichaud Coke: pong
20:30 Coke I opened a ticket today and cc'd you on it - #721. Just wanted to ping you here also.
20:31 Coke I'm assuming it's a PGE thing, but could be wrong.
20:31 pmichaud Yes.  WE should probably reference it from the existing RT ticket (and perhaps close the RT ticket).
20:31 pmichaud RT #37745
20:32 Coke I already opened a ticket on that? =-)
20:32 * Coke digs.
20:32 Austin_Hastings pmichaud: Is there a reason why "Method 'can' not found for invocant of class 'PAST;Var'" ? It seems that PAST;Node is a p6metaclass, and so should inherit all the HOW/WHAT/isa/can stuff, no?
20:33 Coke pmichaud: ah, didn't realize it was that one!
20:33 pmichaud Austin_Hastings: only the metaclasses get .can
20:33 pmichaud we don't give every object a .can
20:33 Austin_Hastings So $x.WHAT.can() ?
20:33 pmichaud $x.HOW.can(...)
20:33 pmichaud (.WHAT gives the protoobject, not the metaclass)
20:34 Austin_Hastings I'd say "of course" except then my head would explode. :-|
20:34 Coke pmichaud: made both tickets ref each other.
20:35 Austin_Hastings 3 args expected??
20:35 Austin_Hastings wtf?
20:35 pmichaud the first argument has to be the class you're testing.
20:35 pmichaud it's not my design -- I'm following the Perl 6 spec there.
20:36 pmichaud I don't think I'd be opposed to adding .can to PCT;Node though.
20:36 pmichaud like we've done for .isa
20:39 Austin_Hastings so $x.HOW.can($x, "scope") ?
20:41 pmichaud I think it might have to be  $x.HOW.can($x.HOW, "scope")
20:41 pmichaud which is why I think I might be okay with adding .can to PCT;Node :-)
20:41 pmichaud then it would just be $x.can("scope"), which is what you want :-)
20:41 Austin_Hastings Well, the code says $P0 = obj.WHAT() ; $I0 = can $P0, x
20:42 Austin_Hastings The suggestion is that .param obj supports WHAT, which seems like it should be an object.
20:42 pmichaud well, everything supports .WHAT
20:42 pmichaud (in p6object)
20:42 Austin_Hastings fsck
20:43 pmichaud anyway, you're right,  $x.HOW.can($x,"scope") looks like it will work.
20:43 pmichaud so I'd go with that.
20:43 Austin_Hastings Yeah, I will until it explodes.
20:44 Austin_Hastings Don't bother with putting can on Node, since there's no guarantee I'm poking at a node (my code might be buggy)
20:45 Austin_Hastings I guess the whole .HOW.can($x, $meth) thing is okay, if the objects eventually get .can($meth) behind the scenes.
20:46 Austin_Hastings But it seems like a long way to go...
21:22 Whiteknight joined #parrot
21:28 donaldh joined #parrot
21:35 Infinoid Uh.  is PARROT_CAN_RETURN_NULL actually valid on functions which don't return pointers?
21:36 dalek parrot: r39240 | chromatic++ | trunk/src/pmc/coroutine.pmc:
21:36 dalek parrot: [PMC] Removed an unnecessary destroy which could cause double context recycling
21:36 dalek parrot: and plugged a memory leak in clone.
21:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39240/
21:37 coke_afk Infinoid: don't think so.
21:40 Infinoid Ok, I'll clean that up then
21:40 Infinoid pmc2c is beautiful.
21:40 Infinoid ATTR PMC *reader;           /* Readable IO handle */
21:40 Infinoid ./src/pmc/pipe.pmc:184: warning: assignment from incompatible pointer type
21:40 Infinoid when I switch "PMC *reader" to "PMC* reader", it builds without warning
21:41 cotto I think I added a patch to fix that, but I also seem to remember it being reverted.
21:42 Infinoid Hopefully not by me
21:43 rdice joined #parrot
21:47 Infinoid Whiteknight: Do we have a decision-making process for which functionality should go in src/io/ and which functionality should go in src/pmc/?
21:48 Infinoid I'm finding myself pushing a lot of accessor functions into src/io/ for things like create and close, just because that's what filehandle does.
21:48 Whiteknight Infinoid: not yet, really. my primary concern is to remove PCCINVOKE calls right now
21:48 Infinoid ok
21:48 Whiteknight yeah, it probably will need major cleaning as time goes on
21:48 Infinoid I'm just looking for a way to get it right now, if I can
21:49 Whiteknight yeah, I know what you mean
21:49 Infinoid I was looking for a close() to stick in Pipe.destroy.  First thing I grepped for was Parrot_io_close, which exists, but ... it's a switchcase that only handles core types, and I'd have to add code to it
21:49 Infinoid then I see it calls Parrot_io_close_filehandle, which looks like something low level.  "oh goodie", I thought.  So I go and look, and it takes a PMC* too
21:49 Whiteknight Unfortunately, the way this method is playing out is that a lot of stuff is moving into src/io
21:50 Whiteknight We can change a lot of those backend methods to take the raw file descriptors instead of PMCs
21:50 Infinoid I guess it makes sense...  if we want enough abstraction to be able to call some close() method and let it do data-specific close() or fclose() or shutdown() or whatever, it can
21:50 Infinoid but I'm not sure it's the best thing from a DRY perspective
21:50 Whiteknight that way we reduce the number of places where PMCs need to be manipulated
21:51 Whiteknight I see src/io/api.c as a layer that facilitates interaction between Parrot core (PMCs, STRING, etc) and the underlying IO system (file descriptors and char *)
21:51 Whiteknight maybe not a perfect layer in that regard, but better then nothing
21:52 Infinoid It's a good start.  Lots of things seem to sidestep it entirely
21:52 Infinoid Sockets, for example, have their own api source file
21:52 Infinoid and PIO_SOCKET() is a #define that calls directly into src/io/socket_<platform>.c
21:52 Whiteknight yeah, and an ideal sockets implementation will be more closely integrated with the rest of the IO system
21:52 Whiteknight instead of essentially being a separate system
21:53 Infinoid "You are in a maze of twisty examples, all wrong."
21:53 Whiteknight "here there be dragons"
21:53 Whiteknight okay, I have to get out of here for a while. I'll talk to you later
21:53 Infinoid I can spend some time integrating sockets with the rest of it
21:53 Infinoid thanks
21:53 Whiteknight np. Later
21:55 Infinoid Does anyone in here know a lot about I/O on win32?  (Specifically, whether parrot uses HANDLEs for everything, or if we mix and match with stdio FILE*s?)
21:57 * Infinoid is gonna say screw it and make a Parrot_io_close that always deals with PIOHANDLEs, just to see what breaks.
22:06 dalek parrot: r39241 | chromatic++ | trunk/src/pmc/float.pmc:
22:06 dalek parrot: [PMC] Plugged a memory leak in the Float PMC by setting its active destroy
22:06 dalek parrot: flag.  CAGE cleaners?
22:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39241/
22:31 rg joined #parrot
23:08 cotto There was a recent commit that added some opcodes but didn't bump PBC_COMPAT.
23:08 cotto Does anyone recall which revision that was?
23:09 bacek joined #parrot
23:10 cotto nm.  found it by checking ops.num's history
23:13 dalek parrot: r39242 | cotto++ | trunk (9 files):
23:13 dalek parrot: [ops] add an op wrapper, documentation, a PBC_COMPAT bump and pbc updates for cmp_pmc
23:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39242/
23:17 skids joined #parrot
23:20 bacek joined #parrot
23:29 Austin_Hastings joined #parrot
23:30 Whiteknight joined #parrot
23:36 Whiteknight Are there any Parroteers in Norfolk VA?
23:41 tetragon joined #parrot
23:50 dalek parrot: r39243 | chromatic++ | trunk (3 files):
23:50 dalek parrot: [runcore] Plugged a memory leak when registering but never freeing dynop
23:50 dalek parrot: libraries.
23:50 purl libraries is what those perl people have to rely on because their language isn't good enough
23:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39243/

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

Parrot | source cross referenced