Parrot 1.2.0 released | parrot.org/ | 303 RTs left | Weekly Priority: Profiling
Set by moderator on 28 May 2009.
00:18 bacek_ joined
dalek TT #426 closed by jkeenan++: install_files.pl and install_dev_files.pl have a fair bit of duplicate ... 00:20
00:20 uniejo joined
dalek rrot: r39229 | jkeenan++ | trunk/docs (3 files):
Applying patch contributed by amk in trac.parrot.org/parrot/ticket/704: minor touch-ups to documentation.
 00:28
cnum-dynpmcs: r69 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add is_equal VTABLE.
TT #704 closed by jkeenan++: Minor markup/grammar fix for Parrot book 00:33
cnum-dynpmcs: r70 | darbelo++ | trunk/src/pmc/decnum.pmc:
Add get_bool VTABLE.
 00:48
00:57 Austin_Hastings left
Infinoid kid51: Does post-1.2.0 parrot build for you on darwin? 01:00
01:04 mikehh joined
dalek rtcl: r381 | coke++ | trunk/t/cmd_return.t:
add a TODO test - we need this feature for [unknown] handling to work.
 01:05
Coke Infinoid: it builds for me on x86/10.4.x 01:06
which implies very little about kid51's machine, if history is any guide. 01:07
Infinoid ok. his result will be a good indication of whether #675 is closable 01:08
dalek rtcl: r382 | coke++ | trunk/t/cmd_return.t:
fix test plan
 01:25
rtcl: r383 | coke++ | trunk/src/macros.pir:
library/ is now harmful when loading stdlib.
kid51 Infinoid: Yes. 01:28
Here's a Smolder from last night at r39203: smolder.plusthree.com/app/public_pr...ails/22842 01:30
10.4 PPC
01:33 Whiteknight joined
kid51 Infinoid: I got successful builds at 39171 and 39203. So I see no obstacle to closing it. 01:39
dalek rtcl: r384 | coke++ | trunk/ (2 files):
add support for [return -options], pass the todo test.
01:42 tetragon joined
Coke Anyone wanna write some PIR? =-) 01:43
cotto how shiny is it? 01:47
Coke not very.
working on it now, think I can hack it out.
dalek TT #675 closed by Infinoid++: r38804 breaks on darwin/OSX 01:50
Coke cotto: commit incoming. Think I got it. 02:09
thanks.
dalek rtcl: r385 | coke++ | trunk/ (2 files):
add support (and a test) for [return -level 1]

infrastructure to support more complicated return levels, but this is a requirement for unknown		 02:13
02:34 darbelo joined 02:35 janus joined
dalek rtcl: r386 | coke++ | trunk/runtime/builtin/return.pir:
silently ignore 2 valid return options.
 02:38
02:54 davidfetter joined 02:57 ZuLuuuuuu joined
dalek rtcl: r387 | coke++ | trunk/ (2 files):
add a barebones [namespace which]
 03:02
03:24 mugwump joined
mugwump hey I notice that alioth.debian.org/projects/pkg-parrot/ only has 0.7.0 debs, but 1.0.0 are in Debian 03:24
...and there's no debian/ on svn trunk 03:25
Coke allison's probably the best person to talk to about that. 03:26
mugwump also, rakudo stable seems to require parrot svn
at least, in terms of the Configure.pl
dalek rtcl: r388 | coke++ | trunk/ (3 files):
use init.tcl's [unknown] instead of trying to roll our own.

  - unknown is failing to barf for a deleted command: -1 tests.
  - invalid calls to [parray] that require an autoload are failing. [catch] needs
to be smarter, but I don't quite know which smarts it needs yet.
mugwump what parrot release is r39025?
03:29 Theory joined
mugwump copies parrot-1.0.0/debian to parrot-1.2.0, runs debchange -v 1.2.0-1, crosses fingers 03:30
Coke mugwump: yes. 03:31
rakudo requires a very specific minimum parrot version that isn't necessarily a release. (at least for rakudo-svn)
mugwump rakudo-svn ? ;)
Coke I think rakudo-release is supposed to work with parrot-release-just-prior.
rakudo-git
mugwump :D
pmichaud Rakudo releases correspond to parrot releases, yes.
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
would it be possible to make that explicit? ie, when changes in parrot are required the version is bumped?
pmichaud that's what happens now.
mugwump ok 03:33
parrot_config --dump | grep ^revision
revision => '0'
:(
pmichaud I can't do anything about parrot not reporting the correct revision number, though.
short of figuring out hwo to get it to report the correct one :-| 03:34
mugwump hmm
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?
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.
mugwump Well, I built from the debian source
ie the tarball release
maybe it's getting that number from an 'svn info' command or something, which doesn't work because it's a tarball release
pmichaud that's possible.
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.
mugwump build/PARROT_REVISION is currently a svn rev
it could also have a release revision, if it corresponds to that 03:37
Coke s/release version/, to avoid confusion.
mugwump ie what 'parrot_config VERSION'
is returning
Coke so, r32343 or "1.2.0"
mugwump right
pmichaud Oh, I get it.
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. =-)
pmichaud iwbni Parrot provided an easy-to-compare revision number.
mugwump sure. I'd think having both there, to depend on either SVN revision X _or_ release version Y
pmichaud mugwump: "or" probably doesn't work.
03:39 Andy joined
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
mugwump yes of course
pmichaud Coke: I can't?
Coke not in general, no.
mugwump but presumably a random svn revision of parrot won't identify as '1.2.0'
or maybe it will
Coke we happen to have released most of our revisions that way so far.
pmichaud actually, it does.
Coke but there's nothing stopping someone from tagging from a branch. 03:40
pmichaud Coke: I don't understand.
mugwump and ... if you build from a branch, what's your revision number ? :->
Coke pmichaud: branch trunk to "release_1.3_prep". cut the release from there, including the tag.
fold those changes back into trunk.
delete the branch.
mugwump prefers git-describe over svn r-numbers any day
Coke no revision at trunk corresponds to teh release. 03:41
pmichaud ah, and updates occurred to trunk in between the branch and mergeback
Coke (presuming a commit or two in trunk while the branch is going.)
right. we happen to not do that, for the most part, but at least one release did it that way.
pmichaud yes, that's a possibility.
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:42
assuming you have a way for users to say "I already have a parrot, please use mine." 03:43
pmichaud We do.
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.
pmichaud I again repeat my point that "iwbni parrot provided an easy-to-compare version number" :-)
Coke pmichaud: this is kind of apples and oranges. 03:44
pmichaud comparing "1.2.0" isn't easy
i.e., it's not easy to determine that 1.10 is in fact > 1.2
Coke: I think you're misinterpreting what I'm saying.
Coke OH. 03:45
yes, I am.
you have perl5 at the time, no?
pmichaud Yes.
Coke (I was thining you wanted 1.2 to compare nicely to r14343. =-)
pmichaud No, that's not what I was asking for. :-) 03:46
Coke Perl::Version ?
pmichaud pmichaud@plum:~$ perldoc Perl::Version 03:47
No documentation found for "Perl::Version".
Coke search.cpan.org/~andya/Perl-Version...Version.pm
pmichaud I'd prefer not to make that my first (and only) required CPAN module.
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.
pmichaud anyway.
oh, I can whip that up also.
Coke we already had that discussion and everyone lost.
pmichaud agreed, we lost.
mugwump github.com/samv/rakudo/commit/07dc2...f28870a5b7 ? 03:50
gah, whitespace
> 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.
FAIL
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
if only svn supported tags 03:52
Coke 1.2.0 == tags/RELEASE_1_2_0
mugwump ah yep
pmichaud I don't want to pull from tags/ because then "svn up" doesn't dtrt
mugwump well use svn switch then
pmichaud hmmm, switch might work 03:53
mugwump tries building parrot HEAD against parrot 1.2.0...
pmichaud I'd still be concerned that one of the devels might accidentally commit to tags/ though. 03:54
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
oh.
mugwump \\nrevision
?
pmichaud PARROT_REVISIOn could be
(for example)
r39025 1.2.0 03:56
actually
"39025 1.2.0"
which means that we want revision 39025, but will accept 1.2.0 if the revision number isn't available
if we later bump it, it becomes
"39214"
which means that we absolutely require r39214, and no released version of parrot is sufficient
afk for a short while 03:58
04:01 tetragon joined
mugwump hmm lots of $(BUILD_DIR)'s in rakudo's build/Makefile.in 04:03
those won't exist with a binary install of parrot
davidfetter OH HAI 04:04
anybody in KL for malaysia osconf? 04:05
dalek TT #718 created by wayland++: Documentation on MANIFEST files should be moved, and other doco improved. 04:07
mugwump darn my parrot packages didn't install a 'runtime' dir 04:10
wayland76 mugwump: Which distro 04:11
purl Which distro are they in?
mugwump wayland76: I took the parrot source package from unstable, copied the debian/ dir into the 1.2.0 release, and built
wayland76 OK
mugwump hmm I'm not sure what the right thing to do with this Makefile.in is
eg
PARROT = $(BUILD_DIR)/parrot$(EXE)
wayland76 I found that Rakudo wouldn't build on installed Parrot
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
I'll send you the ticket number
...
trac.parrot.org/parrot/ticket/712
I sent this patch to a Gentoo packager who wanted it too 04:13
Rakudo also needs patching to work with RPM
I can send you that link too, if needs be
mugwump can you just put a link to my github parrot fork on that? 04:15
gotta scram 04:16
also note that I'm pretty sure that 'Makefile.in' shouldn't be using BUILD_DIR if it's using an installed parrot
I'll sign up next time :) 04:17
thanks people... &
04:19 nopaste joined
pmichaud back again 04:33
I'm seeing two failures in trunk:
t/dynoplibs/myops.t 1 256 10 1 7 04:34
t/pmc/eval.t 1 256 17 1 12
known/expected?
dalek rrot: r39230 | pmichaud++ | trunk (2 files):
[core] Add "get_subid" method to Sub PMC.
 04:41
05:08 Theory joined 05:59 cognominal joined
afk_coke codetest failures again: smolder.plusthree.com/app/public_pr...port/22895 06:00
dalek rrot: r39231 | coke++ | trunk (3 files):
pass trailing_whitespace.t
 06:05
rrot: r39232 | NotFound++ | trunk/src (2 files):
[cage] add ASSERT_ARGS to 2 functions that lacked it
 06:28
Coke ... you beat me. 06:32
NotFound++ 06:33
dalek rtcl: r389 | coke++ | wiki/ParrotIssues.wiki:
no more showstoppers; re-org remaining items.
 06:37
rtcl: r390 | coke++ | wiki/ParrotIssues.wiki:
This bug we no longer care about.
 06:42
06:43 iblechbot joined
Coke TT #66 has an old segfault that's still there. 06:46
If anyone wants some C code to plow through. =-)
dalek rtcl: r391 | coke++ | wiki/ParrotIssues.wiki:
segfaults are bad, especially when running spectests.
 06:52
Coke starts up a spectest run to see how bad the damage is. 06:57
dalek rtcl: r392 | coke++ | trunk/tools/ (2 files):
Update testing tools to work with an installed parrot.
 07:02
Coke frabulous joy. :| 07:06
out of memory panic.
nopaste "tene" at 166.70.38.237 pasted "Weird behavior under rakudo for pmichaud++" (2 lines) at nopaste.snit.ch/16711 07:07
Tene pmichaud: that's $ā˜•
Coke what does it do? 07:08
(is it another "parrot was expecting an ascii string bug found unicode" bug?
Tene seems to just spin the cpu
I've left it running ever since I tried it. Still no output. 07:09
steadily increasing memory usage.
About to start going into swap...
any second now...
SWAP!
That was exciting. 07:10
Coke I'm at 18% of the memory on feather right now testing tcl. 07:12
... out of memory panic, dump core.
Tene yay! 07:13
dalek TT #719 created by coke++: out of memory running a tcl spec test 07:18
Coke that error message should not reference parrot bug or the email list, but probably trac. 07:19
dalek rtcl: r393 | coke++ | wiki/ParrotIssues.wiki:
YA "crash a spectest" bug.
 07:21
07:46 preflex joined 08:12 donaldh joined
mikehh and the latest make -k fulltest report at r39232 on Ubuntu 9.04 i386 08:58
codetest, manifest_testsm examples_tests FAIL, all others PASS 08:59
nopaste "mikehh" at 90.209.206.247 pasted "make -k fulltest summary at r39232" (98 lines) at nopaste.snit.ch/16712 09:06
09:16 cognominal joined 09:37 wayland76 joined, bacek joined
dalek rrot: r39233 | chromatic++ | trunk/compilers/imcc (5 files):
[IMCC] Fixed several memory leaks of string constants in IMCC. There may be a
 09:44
rrot: r39234 | chromatic++ | trunk/src/pmc/continuation.pmc:
[PMC] Plugged the memory leak of a Parrot_cont in the destination PMC returned
 09:54
rrot: r39235 | chromatic++ | trunk/src/pmc/sub.pmc:
[PMC] Tided code; no functional changes.
09:55 ZuLuuuuuu joined
dalek rrot: r39236 | chromatic++ | trunk/src/pmc/lexpad.pmc:
[PMC] Plugged a memory leak in the LexPad PMC by enabling its active destroy
 10:07
rrot: r39237 | chromatic++ | trunk/src/pmc/fixedintegerarray.pmc:
[PMC] Fixed a memory leak when thawing a FixedIntegerArray PMC; it didn't have
 10:11
10:21 cognominal joined 11:07 muixirt joined 11:11 burmas joined
muixirt please, someone fix pdd19_pir.pod line #1055 11:14
11:20 donaldh joined 11:56 muixirt2 joined
dalek TT #718 closed by jkeenan++: Documentation on MANIFEST files should be moved, and other doco improved. 12:11
12:14 Austin_Hastings joined
Austin_Hastings Ā”Hola, #parrot! 12:14
Coke muixirt: done. Thanks. 12:24
dalek rrot: r39238 | coke++ | trunk/docs/pdds/pdd19_pir.pod:
fix pod typo.
 12:26
12:26 Whiteknight joined 12:32 ZuLuuuuuu joined
muixirt Coke, sorry for bothering you, but I overlooked the other places with =cut 12:35
it seems more complicated than i thought :-)
12:44 jsut joined 12:45 iblechbot joined
dalek kudo: 77b920a | masak++ | src/builtins/eval.pir:
[src/builtins/eval.pir] s/@INC/@*INC/
 12:45
13:00 gryphon joined 13:02 Andy joined 13:05 hudnix joined
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:23
chromatic++ for fixing memory leaks. 13:24
Whiteknight chromatic++ # Agreed 13:26
karma chromatic
purl chromatic has karma of 2032
Whiteknight karma karma karma chameleon
purl karma karma chameleon has neutral karma
Whiteknight karma chameleon 13:27
purl It comes and goes.
Whiteknight now THAT's comedy 13:28
Infinoid (karma karma chameleon)++ 13:29
(karma karma chameleon)--
Whiteknight good morning Infinoid 13:32
Infinoid ohai
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
Whiteknight Some test failures still though in the packfile stuff, I suspect the FileHandle attributes are hardcoded somewhere
but I'm not too worried about that yet 13:34
Infinoid so, Handle objects can't be created directly? 13:39
Infinoid is wanting an fdopen()-like interface for the Pipe stuff 13:40
Whiteknight no, Handle is abstract 13:41
purl okay, Whiteknight.
Whiteknight purl forget Handle
purl Whiteknight: I forgot handle
Infinoid ok, I'll create a subclass for pipe endpoints (but this subclass will be *very* generic)
Whiteknight okay. Just make sure your pipes "does pipe"
or "does file", if the interface is consistent 13:42
or whatever
we may need to create a src/io/pipes.c file, if you have a lot of specialized ode
Infinoid it isn't consistent, no seek()
there's very little specialized code... maybe some OS-specific stuff to create the things, that's all 13:43
but I think we already have that
Whiteknight okay, then nevermind that
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:44
Infinoid I doubt it. I'm doing this for flexibility, not speed 13:45
(unless you've improved something else?)
Whiteknight Removing the PCCINVOKE calls is going to be a major performance improvement
Infinoid oh, awesome 13:46
Whiteknight especially for programs that make a lot of calls
Infinoid I don't understand tho... don't you still need PCC to call METHOD read(INTVAL length)?
13:49 skids joined
Whiteknight right, but there are two entrypoints: FileHandle.'read'(), and the read opcode 13:49
the opcode used to call the method
now, it doesn't 13:50
Infinoid oh, ok. I'm looking at your changes to Parrot_io_flush() in r39211
So will that if/else chain be expanded for every IO type? 13:51
Whiteknight no, only for every IO role
so there is a "file" role, and all PMCs that do that role will perform that logic 13:52
so FileHandles and all subclasses of it
there's also a socket role and a pipe role, and that's all I can think of
oh, a string role too, for StringHandle and descendents
Infinoid does role define the API or the implementation?
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
Whiteknight you're right about that, it is worrisome
there are improvements that need to be made to this methodology still
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
purl okay, Whiteknight.
Whiteknight purl forget code review
purl Whiteknight: I forgot code review
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
anyway, I'll add pipes first, and then add fcntl() and some kind of setvbuf() frontend to the Handle base class 13:58
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:00
oh, duh. pipes are never ttys. nevermind 14:01
14:02 Andy joined
Whiteknight yeah 14:07
I'm not sure about adding the fcntl and setvbuf stuff to Handle, because not all Handles (StringHandles) support it 14:08
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:09
Infinoid true, but that means the role defines the implementation 14:11
for my purposes, having these things as generic as possible is perfect. For performance purposes, avoiding PCC is also useful
Is there a way we can have both?
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
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
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.
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?
Whiteknight pmichaud: how significant?
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
pmichaud i.e., the following Perl 6 code fails: my $x = 1+0i; say $x - $x;
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
Whiteknight Did NotFound's PMCProxy work happen in that revisionr range?
pmichaud Yes.
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.
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
pmichaud Whiteknight: agreed; but the problem seems to be specifically related to PIR method invocation more than PMCProxy 14:17
r39220 fails
Whiteknight pmichaud: Okay then
pmichaud (that's the one that had NotFound's patch, fwiw) 14:18
trying r39218
Whiteknight Infinoid: Two base classes might be reasonable. Nothing says we need to have a single "pretty" hierachy 14:20
The only important point in this is that the IO objects need to be clear about what roles they do and do not does
Infinoid If does(file) implies details about the object's internals, then that means the genericified version needs to not declare that 14:21
if we fall back to the PCC case when we can't find more specific bits to twiddle, that should work
Whiteknight Infinoid: I like that idea. An expensive fallback is okay if it's rarely used 14:22
the only things about the internals that the does(file) role expects is the names and types of attributes
or, that's all it should expect
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
ok
Whiteknight that's how the system is now in trunk
Infinoid yeah, I know
Whiteknight I want to change it so we have frontend Parrot_io_* functions which call backend Parrot_io_functions only, not methods 14:24
14:24 muixirt2 joined
Infinoid well, methods are the compatible fallback path 14:24
But then those methods must not call Parrot_io_*
or at least, not the same ones
reentrancy is fine but we don't want to get caught in a call loop 14:25
NotFound Are you blaming me? 14:27
pmichaud r39218 passes, trying r39219 14:28
NotFound I deny everything! ;)
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
Whiteknight NotFound: Not blaming, just suggesting that the PMCProxy system is too messy and lousy and convoluted to be tamed by meer mortals
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
NotFound: That's a good thing :)
14:32 AndyA joined
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.
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
I'm just worried about creating so many new PMC types 14:40
But you're right, separating out buffering logic from the core PMC types is probably a good thing
pmichaud uh oh, I know why r39220 fails.... 14:42
Austin_Hastings Umm, why are these pmc types, necessarily?
At some point you need to get off the pot, and start building parrot in parrot, no?
NotFound Whiteknight: maybe some types may be classes created at runtime. 14:43
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?
NotFound Austin_Hastings: you can build whatever deep hyerarchy of slow classes on top, but the low level support needs to be fast. 14:45
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?
purl Dark room, Strong stomach, Kneepads.
Whiteknight NotFound, IO classes created a runtime are going to have to be subclasses of an existing tye 14:48
type*
NotFound I don't think we need any other op right now.
Austin_Hastings operations, not opcodes.
NotFound I fail to understand the point. 14:49
Whiteknight pmichaud: Why does it fail?
(I have my suspicions, but I can't test it here)
pmichaud because the proxy object is clobbering an existing symbol entry
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.
pmichaud I have a small PIR test program to demonstrate.
(updating to latest Parrot first)
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 nopaste.snit.ch/16715
Whiteknight If we could find a way to strictly implement buffering behavior through VTABLEs, we could make it subclassable
Coke ~ 14:53
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:56
pmichaud Coke: mind if I revert r39220 ? 14:57
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:58
Whiteknight NotFound: That's an interesting idea although I worry that not all IO classes will want a buffering facility 14:59
but if we can implement it in an agnostic way in Handle, I would be fine with that
NotFound Something like the stream/streambuffer ralationship in C++ standard lib.
Whiteknight NotFound: Yeah
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
badly
NotFound Whiteknight: I don't tike I'll have much time this weekend.
Whiteknight yeah, me either.
NotFound s/tike/think
Infinoid for Sockets, buffering is off by default and (for the UDP/nonblocking case at least) I'd like to keep it that way
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
yeah, that's why I was thinking of putting some interface to setvbuf() in the base class
I won't get to that in the near future tho 15:02
should the "clone" vtable create a deep copy or a shallow one? 15:03
NotFound It must take a gun and kill the programmer that uses it ;) 15:04
Infinoid which Parrot_io_* function can I call to do that? Seems a bit OS-specific :) 15:07
pmichaud aha, found it. 15:08
src/oo.c:409
NotFound Infinoid: we're expected to do the hard, os dependant tasks, isn't it? ;) 15:12
I'm almost sure the DeathStation OS has a system call for that,. 15:13
Infinoid Parrot_ex_fail_and_execute_programmer(PARROT_INTERP) 15:15
NotFound www.cramster.com/reference/wiki.asp...ation_9000
pmichaud: What's the problem with that line? Isn't that that the proxy creation is supposed to do? 15:19
Or is the check for namespaci'ng what is wrong?
15:20 donaldh joined
pmichaud it's creating the wrong namespace, I think. 15:22
There's some incorrect (and circular) in that function.
er, incorrect (and circular) logic
NotFound Do you think about creating a proxy for the namespace pmc? 15:23
pmichaud first question: is it ever possible for interp->vtables[type]->_namespace to be null? (line 397) 15:24
Coke pmichaud: checking.
purl checking is probably just different
pmichaud regardless, whatever comes back from ->_namespace certainly *isn't* the hll_ns
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.
pmichaud Coke: without reverting it, I'm failing tests. :-)
Coke (I believe. i can double check, but I'm pretty sure that's the one that fixed my [namespace children] failures.
pmichaud See nopaste.snit.ch/16715
Coke: yes, that's the one that fixed your namespace children failures.
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
Coke I presume there's a hypothetical patch that makes both of us happy, though.
NotFound pmichaud: Is supposed to be namespace of the hll that owns the pmc.
pmichaud really? 15:27
I thought it's the namespace of the PMC itself
I think that interp->vtables[type]->_namespace is the namespace for the PMC itself
not its hll namespace
NotFound In that case, my patch was wrong.
15:27 muixirt2 joined
pmichaud PMC *_namespace; /* Pointer to namespace for this class */ 15:28
(from include/parrot/vtable.h:271)
anyway, as I was saying
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
if interp->vtables[type]->_namespace isn't null, then we already have the namespace for the class, and don't need to create it.
I'm working on a fix, but it's causing other failures. 15:29
nopaste "pmichaud" at 72.181.176.220 pasted "Proxy / method collision in parrot trunk, first attempt at fix" (34 lines) at nopaste.snit.ch/16717 15:30
NotFound pmichaud: I thinked that this check was just a way of avoiding crashing on unexpected usages.
pmichaud what check? 15:31
NotFound The nullness of _namespace. 15:32
pmichaud note that _namespace is never checked for nullness in current trunk
I think we just have to force PMCProxy lookup to always work from the parrot hll namespace 15:36
(under the assumption that all PMC types live in the 'parrot' HLL)
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.
The cleaner solution would be to make sure that _namespace is always initialized
(to the correct namespace) 15:38
NotFound Creating the proxies, then,
Whiteknight I doubt you want to always search for and create PMCProxies in the "parrot" HLL
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?
NotFound Make sure that all PMC get his proxies created during initialization.
pmichaud NotFound: that's a possibility also.
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.
NotFound Same here
pmichaud so I think I'll just force creation in parrot hll
Coke pmichaud++ 15:42
I appreciate any love tcl gets. =-)
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.
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 15:47 darbelo joined
Coke oooh. I think I can start shipping a little more of the standard library (core tcl written in tcl) and pass more tests. 15:48
16:10 AndyA joined 16:27 AndyA joined
pmichaud Coke: when you get a chance, maybe verify that r39239 still does the right thing for partcl 16:36
(just committed)
so far it's doing the right thing for rakudo. :-) 16:37
(running a spectest now)
dalek rrot: r39239 | pmichaud++ | trunk (2 files):
[core]: Revise r39220 commit for PMCProxy, to avoid conflicts with methods.
 16:38
jonathan Turns out methods on Parrot's Role PMC were...not the best idea. :-| 16:52
coke_afk pmichaud: checking now. 17:06
17:07 iblechbot joined
Coke pmichaud: namespace test passes. 17:10
doing a full make test now.
... is it me or are things much faster now? 17:11
it's just me. =-) 17:12
17:13 pjcj joined 17:15 AndyA joined
Coke pmichaud: no new failures. Thank you! 17:16
17:39 Austin_Hastings joined 17:53 burmas joined
Coke pmichaud: any idea why this test might go into the weeds? 17:54
test regexpComp-22.0.1 {Bug 1810038} {
evalInProc {
regexp ($|^X)* {}
}
} 1
17:55 ZuLuuuuuu joined
Coke evalInProc basically turns it into a sub and runs it there. consumes all memory trying to do the match. 17:55
lemme see if I can make it into a simple regex match and do the same thing. 17:56
yup. just [regexp ($|^X)* {}] goes into the weeds... 17:57
Austin_Hastings Maybe $ is a zero-width assertion and it's matching them repeatedly? 18:01
(A similar thing happened to me y-y-day.)
18:02 bacek joined
dalek TT #721 created by coke++: PGE::P5Regex consumes all memory 18:13
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
nopaste "Coke" at 65.91.151.195 pasted "tcl code that burns through memory:" (38 lines) at nopaste.snit.ch/16720 18:26
Coke so that just creates a list with a bunch of integers in it. the list type is a PMC subclass of RPA. 18:27
18:28 Whiteknight joined
Coke I am guessing there are some PMCs not getting reclaimed in that inner loop. 18:28
18:46 mikehh joined
Whiteknight do you have the raw PIR file that's generated from that? 18:52
19:02 ruoso joined
dalek kudo: 951ffe5 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get some recent changes, including get_subid.
 19:17
19:17 burmas left
Coke Whiteknight: no. tcl doesn't use PCT, and the handrolled PIR step I had had to be removed at one point. 19:24
You can run it with parrot -D60 tcl.pbc foo.tcl and get all the auto-gen'd stuff. 19:25
(warning: there's a LOT, especially since are using the tcl equivalent of rakudo's setting)
Whiteknight oh, right 19:27
(not using PCT)-- 19:28
Coke until recently, it was a step back!
(no HLL)
btw, code.google.com/p/partcl/issues/detail?id=59 :P
dalek rtcl: r394 | coke++ | wiki/ParrotIssues.wiki:
track another parrotbug
 19:33
TT #722 created by bobw++: Rewrite of t/pmc/capture.t in PIR 19:57
kudo: c36d4f2 | pmichaud++ | src/parser/grammar.pg:
Correct qw() and other quotes-that-are-really-functions (TimToady++).
 20:09
20:23 amoc joined
dalek kudo: 92c78fa | tene++ | (2 files):
Fix cross meta ops to work with more than two args

sbp++		 20:26
Coke pmichaud: ping. 20:29
pmichaud Coke: pong
Coke I opened a ticket today and cc'd you on it - #721. Just wanted to ping you here also. 20:30
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).
RT #37745
Coke I already opened a ticket on that? =-) 20:32
Coke digs.
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?
Coke pmichaud: ah, didn't realize it was that one! 20:33
pmichaud Austin_Hastings: only the metaclasses get .can
we don't give every object a .can
Austin_Hastings So $x.WHAT.can() ?
pmichaud $x.HOW.can(...)
(.WHAT gives the protoobject, not the metaclass)
Austin_Hastings I'd say "of course" except then my head would explode. :-| 20:34
Coke pmichaud: made both tickets ref each other.
Austin_Hastings 3 args expected?? 20:35
wtf?
pmichaud the first argument has to be the class you're testing.
it's not my design -- I'm following the Perl 6 spec there.
I don't think I'd be opposed to adding .can to PCT;Node though. 20:36
like we've done for .isa
Austin_Hastings so $x.HOW.can($x, "scope") ? 20:39
pmichaud I think it might have to be $x.HOW.can($x.HOW, "scope") 20:41
which is why I think I might be okay with adding .can to PCT;Node :-)
then it would just be $x.can("scope"), which is what you want :-)
Austin_Hastings Well, the code says $P0 = obj.WHAT() ; $I0 = can $P0, x
The suggestion is that .param obj supports WHAT, which seems like it should be an object. 20:42
pmichaud well, everything supports .WHAT
(in p6object)
Austin_Hastings fsck
pmichaud anyway, you're right, $x.HOW.can($x,"scope") looks like it will work. 20:43
so I'd go with that.
Austin_Hastings Yeah, I will until it explodes.
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:44
I guess the whole .HOW.can($x, $meth) thing is okay, if the objects eventually get .can($meth) behind the scenes. 20:45
But it seems like a long way to go... 20:46
21:22 Whiteknight joined 21:28 donaldh joined
Infinoid Uh. is PARROT_CAN_RETURN_NULL actually valid on functions which don't return pointers? 21:35
dalek rrot: r39240 | chromatic++ | trunk/src/pmc/coroutine.pmc:
[PMC] Removed an unnecessary destroy which could cause double context recycling
 21:36
coke_afk Infinoid: don't think so. 21:37
Infinoid Ok, I'll clean that up then 21:40
pmc2c is beautiful.
ATTR PMC *reader; /* Readable IO handle */
./src/pmc/pipe.pmc:184: warning: assignment from incompatible pointer type
when I switch "PMC *reader" to "PMC* reader", it builds without warning
cotto I think I added a patch to fix that, but I also seem to remember it being reverted. 21:41
Infinoid Hopefully not by me 21:42
21:43 rdice joined
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:47
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
Infinoid ok
Whiteknight yeah, it probably will need major cleaning as time goes on
Infinoid I'm just looking for a way to get it right now, if I can
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
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
Whiteknight Unfortunately, the way this method is playing out is that a lot of stuff is moving into src/io
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
but I'm not sure it's the best thing from a DRY perspective
Whiteknight that way we reduce the number of places where PMCs need to be manipulated
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
maybe not a perfect layer in that regard, but better then nothing
Infinoid It's a good start. Lots of things seem to sidestep it entirely 21:52
Sockets, for example, have their own api source file
and PIO_SOCKET() is a #define that calls directly into src/io/socket_<platform>.c
Whiteknight yeah, and an ideal sockets implementation will be more closely integrated with the rest of the IO system
instead of essentially being a separate system
Infinoid "You are in a maze of twisty examples, all wrong." 21:53
Whiteknight "here there be dragons"
okay, I have to get out of here for a while. I'll talk to you later
Infinoid I can spend some time integrating sockets with the rest of it
thanks
Whiteknight np. Later
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:55
Infinoid is gonna say screw it and make a Parrot_io_close that always deals with PIOHANDLEs, just to see what breaks. 21:57
dalek rrot: r39241 | chromatic++ | trunk/src/pmc/float.pmc:
[PMC] Plugged a memory leak in the Float PMC by setting its active destroy
 22:06
22:31 rg joined
cotto There was a recent commit that added some opcodes but didn't bump PBC_COMPAT. 23:08
Does anyone recall which revision that was?
23:09 bacek joined
cotto nm. found it by checking ops.num's history 23:10
dalek rrot: r39242 | cotto++ | trunk (9 files):
[ops] add an op wrapper, documentation, a PBC_COMPAT bump and pbc updates for cmp_pmc
 23:13
23:17 skids joined 23:20 bacek joined 23:29 Austin_Hastings joined 23:30 Whiteknight joined
Whiteknight Are there any Parroteers in Norfolk VA? 23:36
23:41 tetragon joined
dalek rrot: r39243 | chromatic++ | trunk (3 files):
[runcore] Plugged a memory leak when registering but never freeing dynop
 23:50
purl libraries is what those perl people have to rely on because their language isn't good enough

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!