Parrot 1.0 Released | parrot.org | 380 RTs left!
Set by moderator on 28 March 2009.
cotto I'll see if I can get our friendly neighborhood jit hacker to fix it. 00:01
seen tewk 00:02
purl tewk was last seen on #parrot 3 days, 4 hours, 16 minutes and 37 seconds ago, saying: Thats a good sign. [Apr 7 19:43:50 2009]
cotto Whiteknight, I'd appreciate it if you could file a bug on that and point tewk toward it if he shows up. 00:08
cotto is going afk
00:09 AndyA joined
cotto is really afk now 00:11
dalek rrot: r38042 | cotto++ | trunk (6 files):
[PMC] get rid of PMC_int_val, the last of the PMC UnionVal macros
 00:12
bacek hooray! UnionVal is dead! 00:13
jonathan So, this means every PMC is using ATTRs now? :-)
COKEINATORINATOR_AF can we remove the deprecated noteice? 00:19
bacek jonathan: I've got some "answers" of Packfile PMCs :) 00:20
in r38026 00:21
Two main points: 1. PackfileSegment.pack is pretty useless. It's almost impossible to pack segments individually because Directory contains offsets to them. 00:22
2. Current implementation of PackFile_*_pack functions based on polymorphic functions in PackFile.PackFuncs. So it's impossible to pack segment without PackFile. 00:23
jonathan OK, my aim with this was that we'd call .pack on each segment 00:24
So the directory PMC would hold the segments.
bacek PackfileDirectory.pack requires to pack all segments upfront.
jonathan And .pack on the directory would .pack each thing and fill out the directory as it learned the lengths up front.
erm
s/up front// 00:25
bacek What's the point?
jonathan Why? You can .pack each segment and then know that segment's length.
And then construct the directory from knowing that.
I saw this interface replacing the current bunch of polymorphic functions... 00:26
Such that in the end most of packfile.c as it stands today would go away.
bacek What about "pure C" interface?
jonathan And each segment type PMC would have the stuff inside it that knew how to pack and unpack that sort of segment.
bacek Like in IMCC
jonathan You can interact with PMCs from C. And there's nothing wrong with having a trixy way to get at the raw bit of memory backing, say, the bytecode segment. 00:27
If IMCC has to work through more of an interface, that's probably a Good Thing for maintainability.
bacek IMCC works with Interpret directly... And than just pack it. 00:28
jonathan I don't consider this a good thing.
bacek It's definitely not 00:29
jonathan But I can appreciate that it's a _lot_ of work to tease this lot out.
bacek Indeed. What about Interpret by itself? It still need "unpack". 00:30
Preferably in pure C without PMCs overhead.
jonathan Yeah, true. 00:31
I figured we'd probably cheat quite a bit behind the PMCs at times...
(Example: I figured we'd always have a pointer to the memory behind the constants PMC for fast constant access and not force that through the PMC.)
bacek I "cheated" little bit in my patch - create underlying C structs from PMCs and pack it. 00:32
jonathan So basically .pack exists at the "top level"?
But not on each segment?
bacek No
jonathan Is that No to the first or second? :-) 00:33
bacek Ad top level it's "Packfile.get_string" according to pdd13
s/Ad/At/
But it's technically top-level "pack"
(And it's faster because uses VTABLE get_pointer :) 00:34
jonathan bacek: Ah, yes, you're right.
bacek I thinks that no one need PackfileSegment.pack in public API. It's implementation details 00:35
But we need PackfileRawSegment.get_type/set_type for creating DEBUG segments. 00:36
Or create PackfileDebugSegment.
(For consistency sake)
And rename Raw to Bytecode 00:37
jonathan The reason it's Raw is because it can be used for more than just bytecdoe.
It was also going to be the PMC in front of the now-gone PIC segment, for example.
bacek Bytecode and Debug IIUC
jonathan Yes, Debug too
So IMO that watns to stay as Raw
To indicate it's not *just* for bytecode. 00:38
bacek But we can subclass it to Bytecode and Raw.
Otherwise we can't pack it.
Because of Segment.type
(subclass to Bytecode and Debug) 00:39
jonathan Oh, now I see what you mean about get_type and set_type 00:41
I'd go for that approach rather than subclass.
Don't want too many PMCs...
bacek Ok, I prefer this for such trivial things too.
jonathan OK, good.
bacek So, 1. Remove public PackfileSegment.pack; 2. Add get_type/set_type accessors to RawSegment. ? 00:42
jonathan 2 for sure
Let me ponder (1) a bit more.
I get your point about it not being so useful in the public API. 00:43
bacek Ok.
jonathan Well
I get it's not too useful from PIR probably.
But I like the way it points to an implementation where each segment can know about itself in a clean, isolated way. 00:44
bacek BTW. RawSegment named incorrectly in PDD. I think it should be PackfileRawSegment 00:45
jonathan *nod*
Consistency FTW.
bacek jonathan: I prefer too. But current PBC structure holds forward offsets to segments... 00:46
jonathan Yes, but I don't see how that gets in the way. 00:48
bacek without them we can implement "streaming" packing.
But it will require to read full PBC on unpack... 00:49
dalek rrot: r38043 | bacek++ | branches/packfile_revamp/src/pmc/packfilerawsegment.pmc:
Fix PackfileRawSegment creating.
 00:53
rrot: r38044 | bacek++ | branches/packfile_revamp/t/pmc/packfilerawsegment.t:
Convert t/pmc/packfilerawsegment.t to PIR.
rrot: r38045 | bacek++ | branches/packfile_revamp/docs/pdds/pdd13_bytecode.pod:
[pdd13] Rename RawSegment to PackfileRawSegment for consistency.
bacek jonathan: what about adding iterator interface to all Packfile*Table? 01:01
01:05 eternaleye joined
jonathan bacek: Could be a nice thing, yes. 01:10
bacek: Maybe to directory to, to iterate the segs?
*too
bacek Directory is a Hash. At least AFAIU 01:11
(From external point of view)
We probably need something like "find_by_type" for it 01:13
jonathan OK, I need sleep now 01:14
Thanks for working on packfile stuff :-)
bacek good night :) 01:15
I'll have more stuff for you tomorrow
jonathan uh-oh ;-) 01:19
night! :-)
01:26 Whiteknight joined
Coke irc logs? 01:37
purl irc logs are nothing like http logs... very low overhead and storage
Coke irclogs?
purl irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
02:01 japhb joined 02:03 braceta joined 02:13 TiMBuS joined
dalek rrot: r38046 | bacek++ | branches/packfile_revamp/include/parrot/packfile.h:
Explicitly set PF_*_SEG enum values and generate packfile_segments.pasm
 02:25
rrot: r38047 | bacek++ | branches/packfile_revamp/src/pmc/packfilefixupentry.pmc:
Fully implement PackfileFixupEntry.

  * Use set_pointer to initialize from PackFile_FixupEntry
  * Use get_pointer to create PackFile_FixupEntry
rrot: r38048 | bacek++ | branches/packfile_revamp/t/pmc/packfile_common.pir:
Add helper function _get_fixup_table
rrot: r38049 | bacek++ | branches/packfile_revamp/t/pmc/packfilefixupentry.t:
Rewrite t/pmc/packfilefixupentry in PIR
rrot: r38050 | bacek++ | branches/packfile_revamp/src/pmc/packfilefixuptable.pmc:
Imlement PackfileFixupTable set_pointer/get_pointer
rrot: r38051 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Add test for FixupTable/FixupEntry pack/unpack
02:29 wayland76 joined 02:32 braceta left, braceta joined 02:41 janus joined 02:51 braceta joined
Whiteknight anybody here on i386? 03:17
dalek rrot: r38052 | whiteknight++ | trunk/src/jit/i386/jit_defs.c:
attempted JIT fix, since my earlier commit apparently broke it. I'm not on i386, so if anybody is, please test this and let me know if I borked it worse please
 03:22
Whiteknight TO BED! I AM OFF!
dalek rrot: r38053 | coke++ | trunk (2 files):
[docs] Keep news up to date.
 03:55
04:05 davidfetter joined 04:16 particle1 joined 04:46 msmatsko joined 05:43 amoc joined 05:54 Theory joined 07:09 Tene joined 07:33 Khisanth joined, Santtu joined
dalek rrot: r38054 | fperrad++ | trunk/compilers/pct/src/POST/Compiler.pir:
[pct] code cleanup
 07:43
bacek Someone have to update pdd17. There is no UnionVal anymore. 07:53
07:56 iblechbot joined
cotto bacek, docs are next on my todo list 07:59
as soon as I admit defeat to the jit code
bacek always happy to add item to someone else todo list
cotto There's a curious parallel between the perl code that generates src/nci.c and the NCI jitting code. 08:01
bacek I don't understand JIT code at all. 08:03
Last assembly language I learn was for Soviet clone of PDP9
cotto admits defeat
dalek rrot: r38055 | bacek++ | branches/packfile_revamp/src (7 files):
[cage] coding standard fixes: whitespaces, comments
 08:16
rrot: r38056 | bacek++ | branches/packfile_revamp/t/pmc/packfile_common.pir:
Add _find_segment_by_type to packfile_common.pir
rrot: r38057 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Add tests for PackfileConstantTable pack/unpack
rrot: r38058 | bacek++ | branches/packfile_revamp/src/pmc/packfileconstanttable.pmc:
Distinguish Keys from other PMCs in PackfileConstantTable.set_pmc_keyed_int.
rrot: r38059 | bacek++ | branches/packfile_revamp/src/pmc/packfileconstanttable.pmc:
Finish implementing PackfileConstantTable.get_pointer
08:28 bsdz joined
dalek rrot: r38060 | bacek++ | branches/packfile_revamp/t/pmc/packfile.t:
Oops. Comment out debug code in test.
 09:39
09:40 jimmy joined
dalek rrot: r38061 | bacek++ | branches/packfile_revamp/docs/pdds/pdd13_bytecode.pod:
[pdd13/spec] Add get_iter vtable methods to ConstantTable, FixupTable and RawSegment.
 09:46
mikehh t/pmc/nci.t - Failed 2/69 subtests 09:56
smolder.plusthree.com/app/public_pr...ails/19777 09:57
shorten mikehh's url is at xrl.us/beomw3
mikehh Failed tests: 66, 69 09:58
11,729 ok, 2 failed, 238 todo, 563 skipped and 0 unexpectedly succeeded
# Segmentation fault in both cases 10:01
bacek purl msg jonathan What about adding PackfileConstant PMC? It will be helpful for iterating over PackfileConstantTable. 10:19
purl Message for jonathan stored.
nopaste "mikehh" at 90.206.38.51 pasted "trace of failing tests in t/pmc/nci.t - nci_66.pir and nci_69.pir" (21 lines) at nopaste.snit.ch/16248 11:00
mikehh both tests fail with a Segmentation fault after invokecc on "nci_vV", "vV" 11:03
bacek mikehh: fail but without segfault on my box. 11:13
mikehh bacek: what are you on - mine is Kubuntu Intrepid i386 11:26
bacek Lenny/i386.
mikehh should give the same results Perl? - 5.10.0 11:27
dalek tracwiki: v11 | bacek++ | IOTasklist
tracwiki: Remove links to resolved or rejected tickets from IOTasklist
tracwiki: trac.parrot.org/parrot/wiki/IOTask...ction=diff
shorten dalek's url is at xrl.us/beom89
bacek it depends. But looks like memory overrun for me
bacek@icering:~/src/parrot$ git bisect good 11:32
Bisecting: 1 revisions left to test after this
[f29221e2854e2d86d40f1214b391e07ce865426d] add a custom destroy method to the Pointer PMC, so it can free the new memory that it allocates
strange...
purl strange is but true
11:41 bsdz joined 12:13 kid51 joined 12:20 iblechbot joined
bacek ok, cotto broke it. 12:26
purl msg cotto Looks like r38040 is main cause for segfault reported by mikehh++. There is a little bit difference between &PARROT_POINTER->pointer and VTABLE_get_pointer. 12:28
purl Message for cotto stored.
mikehh was just looking at that - I figgured it had to be pointer related 12:30
had to go and get everyine some lunch at KFC - a *BIG* bucket 12:32
dalek rrot: r38062 | jkeenan++ | branches/install_tools (5 files):
Applying patch submitted by wayland in
 12:50
12:51 Whiteknight joined 12:54 Tene joined 13:17 joubert joined
dalek rrot: r38063 | whiteknight++ | trunk (3 files):
remove some mentions of PMC_*_val from a few documentation sources, so people don't think that they still exist
 13:23
13:27 jimmy joined
dalek rrot: r38064 | whiteknight++ | trunk (2 files):
Remove src/pmc/scalar.pmc:clone(), which only copied the UnionVal of a PMC. However, since UnionVals aren't used anymore, this is essentially a no-op. Also, remove the PMC_union() macro, which was only used in this location
 13:39
mikehh BTW apart from the test I was failing before (t/op/trans) and the new one (t/pmc/nci.t) make testj passes the rest at r38059 om Kubuntu Intrepid i386 13:40
I had some more fun with t/op/trans in the jit core - TT#530 13:41
Whiteknight mikeh++ 13:48
what rev are you at? because I committed a JIT change last night that I wasn't able to test (I'm not on i386)
dalek rrot: r38065 | whiteknight++ | branches/kill_unionval:
Create a new branch to finally kill the UnionVal structure in all the places it's still hiding in
 13:52
13:59 wayland76 joined
mikehh Whiteknight: r38059 at the moment 14:00
Whiteknight okay good. My fix was r38052, so you must be using it without problems 14:01
mikehh I noticed that and thought I would let you know
15:06 amoc joined
dalek rrot: r38066 | whiteknight++ | branches/kill_unionval:
not quite ready to remove UnionVal yet, it's still too entrenched in too many places.
 15:14
15:23 TMC joined
TMC hihi 15:23
mikehh hi de hi 15:24
TMC I was wondering if anyone could answer a question: 15:25
how big is parrot, compiled?
with everything unnecessary removed 15:26
no libraries, no compiler or parser or anything
wondering if it's lightweight enough for use on handhelds
mikehh 75385 BUT needs libraries and stuff 15:27
Whiteknight that's not a terrible estimate
I don't think we can even build it right now without IMCC 15:28
mikehh roll in PIRC
s/in/om/
on 15:29
TMC 75kb?
Whiteknight I'm sure there is a lot of fat that could be cut for bare-bones operation, precompiled JIT thunks come to mind
TMC IMCC?
purl i think IMCC is the c of parrot or the problem or the intermediate code compiler
mikehh this keyboard is killing me - got to get another one
Whiteknight the CG, PCG, and Switch runcores can disappear too probably
jonathan TMC: I think the most honest answer is, we actually don't really know because nobody has found time to try and really strip it down just yet. 15:31
TMC ok
jonathan What you need probably depends on what you want to run too.
Example: if you want to run a HLL on top of Parrot that can eval code at runtime, you'll need to have the Parrot Compiler Toolkit library in many cases. 15:32
TMC that won't be needed
mikehh AFAIK there has been work on embeded Parrot but there are still problems there
TMC is it possible to precompile PASM, so that (in theory, if it's not currently possible) neither MDCC nor PIRC will be required? 15:33
jonathan Yes, compiling to PBC (bytecode format, which the interpreter then can run directly) already works just fine. :-)
TMC great :) 15:34
thanks very much, everyonr
jonathan But the way things are at the moment, choosing to not have IMCC, etc, isn't something that can be trivially done.
TMC *everyone
jonathan I'd love that to change, but like everything, time, effort. :-) 15:35
15:40 iblechbot joined 15:49 bsdz joined 15:52 Psyche^ joined 16:09 tetragon joined 16:10 eternaleye joined
Whiteknight tewk: ping 16:27
dalek rrot: r38067 | whiteknight++ | trunk/src/pmc/coroutine.pmc:
removing RT note for a ticket that I'm rejecting for now. More information will be added shortly to RT #46699
 16:56
17:01 joubert joined
dalek kudo: e931dc0 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 359 files, 10300 passing, 0 failing
 17:03
shorten dalek's url is at xrl.us/beonvz
17:07 joubert_ joined
dalek kudo: bb664df | jnthn++ | src/classes/Object.pir:
Make .?, .+ and .* more likely to work with foreign objects, and also make them able to call methods that were mixed in.
 17:10
shorten dalek's url is at xrl.us/beonws
dalek kudo: 5b679a9 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/beonwu
17:18 tetragon joined 17:34 Casan joined 18:41 tetragon joined 18:48 joubert_ left 18:52 contingencyplan joined 19:25 tetragon_ joined 19:43 tetragon joined 20:32 tetragon_ joined 20:39 contingencyplan joined 20:46 riffraff joined 20:56 plathrop joined
plathrop Hello! 21:00
cotto Hi, plathrop. 21:02
bacek, ping
plathrop I'm trying to follow along with the tutorial from parrotblog.org but I'm running into some issues (even before I really get into the tutorial). 21:05
I followed the "Getting Started" page to download and build Parrot.
(version 1.0.0)
But I don't seem to have a NQP binary
Platform is OS X 10.5.6 21:06
Anyone have ideas where I might be going wrong?
"make test" says everything passes.
cotto plathrop, are you working with an installed parrot? 21:07
i.e. did you run make install?
plathrop cotto: Not yet. Is that the missing link? 21:08
cotto I know that when that tutorial was written, the install process wasn't working.
Where are you trying to build your language?
sjn seen pmichaud
purl pmichaud was last seen on #parrot 2 days, 4 hours, 9 minutes and 37 seconds ago, saying: bbl [Apr 9 16:57:34 2009]
plathrop cotto: Well, I haven't gotten that far. I reached the point on the "Getting Started" page where it says to run $ ./nqp hello.nqp 21:09
And, there's no nqp
cotto Which page are you looking at? I don't see anything like that on www.parrotblog.org/2008/03/targetin...ot-vm.html 21:11
plathrop docs.parrot.org/parrot/latest/html/...d.pod.html which I figured was a pre-requisite to starting the tutorial. Sorry I wasn't clear.
shorten plathrop's url is at xrl.us/beooh7
21:12 tetragon joined
cotto plathrop, that page seems to be out-of-date. 21:14
You can run a NQP script with ./parrot compilers/nqp/nqp.pbc foo.nqp 21:15
although the example nqp code should be say("Hello, world") instead of what's there now
plathrop cotto: ah, okay. Thanks.
cotto Look at compilers/nqp/t for more nqp examples. 21:16
plathrop cotto: so, is there anywhere that might show me how to get Parrot installed and ready for me to follow the tutorial? Or is the tutorial hopelessly out of date?
I'm mostly playing around with this to learn a bit about writing a very simple Lisp.
cotto which tutorial? 21:17
purl which tutorial are you talking about?
plathrop cotto: The one that you linked to.
cotto I think that tools/dev/mk_language_shell.pl works outside Parrot's root if you don't need dynops. 21:19
I think you'll be fine using it.
cotto checks
it looks like dynops and dynpmcs don't work from an installed 1.0 parrot, but the tutorial doesn't require them. 21:24
plathrop Thanks, cotto! 21:27
cotto np. Feel free to stick around here and ask if you run into trouble.
21:41 kid51 joined
bacek good morning 22:09
cotto: pong. Sorry, I was wrong in my message.
nopaste "kid51" at 70.85.31.226 pasted "t/pmc/nci.t: Failures in two tests" (56 lines) at nopaste.snit.ch/16249 22:28
bacek kid51: known issue... mikehh reported it. 22:31
kid51 bacek: Thx ; is there a TT? 22:32
bacek kid51: probably no 22:33
cotto bacek, yup. My bisection points to 38036, although some later commits changed the resultant error. 22:43
kid51 I had all tests passing at r38036. I looked there first because 'nci' appeared in the log message. 22:49
Opening TT.
cotto kid51, you're right. It's '37. I just misremembered.
kid51++ 22:52
kid51 trac.parrot.org/parrot/ticket/551 22:58
23:01 Tene joined
Tene I'm having a problem with Parrot_io_eprintf 23:03
when I eprintf("%S", message), it prints nothing
when I eprintf(" %S", message), it prints a space, then the message. 23:04
cotto Tene, is that with a STRING*? 23:13
Tene yes 23:16
cotto I think you have to use %Ss. 23:17
23:19 tetragon joined
cotto confirmed 23:19
Tene yes
:)
thanks
23:46 Whiteknight joined
Tene Okay, lemme commit this line number stuff. 23:47
23:54 davidfetter joined
Whiteknight anybody here on i386? 23:55
mikehh moi - I am
Whiteknight I'm trying to get more information about TT # 551. I'm not on i386, so I can't duplicate it here 23:56
Tene Whiteknight: linux i386? I can give you a shell on my box.
Whiteknight Tene: I wouldn't even know what to do with shell access. I'm a total n00b with that kind of stuff 23:57
mikehh my parrot is still at r38059
Tene Whiteknight: what information do you need?
mikehh I have a version at r38023 23:58
Whiteknight The failure started at 38037, which I knew previously. I thought the error was fixed in r38052

Powered by Cro and the Raku® Programming Language.

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

Thank you!