Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: deprecated core PMCs and VTABLE entries | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 26 January 2010.
00:11 tetragon joined
darbelo replaces conditional with API 00:14
cotto_work replaces darbelo with API 00:15
00:16 kid51 joined 00:22 ash_ joined
cotto_work darbelo, thanks for doing this work, but is it going to be in one huge commit that's hard to review? 00:28
darbelo Probably.
cotto_work Is that evitable?
Whiteknight we'll review it 00:29
darbelo Sure.
Right now I'm doing exploration mostly.
cotto_work Sure. It'll just be nicer to review if it's in smaller chunks.
darbelo I can commit it in chunks once I decide which way is the correct one. 00:30
cotto_work Great. Thanks.
darbelo That will happen after I get it to build, for starters.
cotto_work Bah. A working build is overrated.
darbelo Also, the need for foods is overpowering me. 00:32
cotto_work I feel the same way about the need for not being at work. 00:33
darbelo I'll probably get something commit-worthy in, say, two or three hours. With a full stomach.
Whiteknight my kill_array_pmc branch has some failures in the packfile* tests, so I'm very much looking forward to this cleanup 00:35
00:35 mj41_ joined, lichtkind_ joined
darbelo I can probably de-Array-ize the code too. 00:36
What did you replace Array with in pmc_freeze.c ? 00:37
Coke . 00:42
darbelo Coke: ping
Whiteknight darbelo: RPA 00:43
but it isn't straghtforward
Array returns null on shift when it's empty. RPA throws exception 00:44
Coke I'm here.
darbelo Coke: After one_make merged, we're pretty much moving into a least-common-denominator make strategy, right?
00:45 lichtkind_ joined
Coke darbelo: yes. 00:45
darbelo Tha means that we can kill the config step that determines your particular make?
Coke ... but there are some things, like dummy targets, that we can do by using the make-specific variants.
darbelo: isn't that still useful to say "now run <YOUR MAKE>" ? 00:46
darbelo I have two makes, both work. Why is Configure telling me which to use? 00:47
Coke fair enough.
darbelo That's the point of using least common denominator. You can use any make you please. 00:48
00:51 dduncan joined
darbelo leaves 00:51
Be back in afew hours
01:05 dduncan left 01:10 cconstantine joined 01:44 chromatic joined 01:46 LaVolta joined
dukeleto 'ello 01:57
cotto 'i
Whiteknight hello
plobsing hi
dukeleto so we should start planning for GSoC and stuff 01:58
i have lots of project ideas for parrot
shall we start a wiki page?
cotto Coke, ping
Whiteknight we have wikipage 01:59
trac.parrot.org/parrot/wiki/BigProjectIdeas
just very sparse
dukeleto we may want something specific to GSoC10 02:01
so "small" projects on that page are GSoC-worthy? 02:02
also, what about non-core stuff. should that get listed there?
cotto It depends on the student.
dukeleto i.e. i have ideas for PL/Parrot and other HLL-related stuff
cotto Ideally they'll talk with us some and figure out what they can handle.
dukeleto cotto: sure. but having some high level descriptions really helps bring in students 02:03
they come to us *after* they have seen a cool project idea, usually. rarely is it the other way around. of course, the best students break this rule
cotto That's probably how it'll be. 02:04
dalek tracwiki: v24 | cotto++ | GitObjections 02:05
tracwiki: Mark most objections as addressed. Feel free to disagree.
tracwiki: trac.parrot.org/parrot/wiki/GitObje...ction=diff
tracwiki: v10 | whiteknight++ | BigProjectIdeas
tracwiki: added NFG and updated size descriptions
tracwiki: trac.parrot.org/parrot/wiki/BigProj...ction=diff
Whiteknight medium projects on that page are gsoc-worthy, i think
dukeleto: that's good question (re: non-core projects). PLA could use some love of that type 02:06
apps and libraries that target parrot are always good things 02:07
cotto I'm all for having non-core Parrot-related GSoC projects. The wiki seems like the best place for it. 02:11
Whiteknight I am going to advertise all project ideas on my blog. from the two posts I've had so far I've already heard from 3 potential students and 2 potential new developers 02:28
is there anybody around who can explain why TT #389 is really a necessity? 02:30
the ticket doesn't say, only that it is a "blocker for Rakudo"
ash_ Whiteknight: i'd like to work on a GSoC project if your thinking of ideas, i am still in college 02:40
02:40 chromatic joined 02:47 hercynium joined 02:48 kid51 joined, eternaleye joined 02:52 mikehh joined 02:59 eternaleye joined 03:01 cconstantine joined
Whiteknight ash_: awesome! anything in particular catch your fancy? 03:02
ash_ well, anything related to dynamicsm particularly llvm stack frame builder and l1
Whiteknight oh, nice 03:03
lots of projects in that area
ash_ Whiteknight: I am working on an indedpendant study, (just started) with a professor at my college on compilers, we are basically going to go through the dragon book this semester, but my kinda on-going goal is an implemetation of nqp-rx that builds against the llvm, more to see if i can figure it out and learn how all that stuff works than anything else but we'll see how that pans out 03:05
Whiteknight that sounds like a really cool project
there are a whole suite of optimizations that need to be added to NQP-RX and PCT 03:06
ash_ my professor liked the idea of how nqp-rx can define a mutable grammar, he's been looking into that, he hasn't currently seen a tool to do what it does
Whiteknight adding the ability for NQP-RX to directly output bytecode is a big need
03:06 mikehh joined
kid51 ash_ Some groundwork for LLVM was laid in trac.parrot.org/parrot/ticket/1075 03:06
Whiteknight ash_: I've got to sign off and head to bed now. Let's definitely talk about projects later? 03:07
ash_ sure, i can email you or leave a comment on your blog
Whiteknight excellent (both of which end up in my email inbox!)
ash_ i did see the llvm detect branch
Whiteknight I'll talk to you later
kid51 Am I correct in thinking that if you only have a single core on a machine, 'make -j' is of no benefit over and above 'make'? 03:08
ash_ i hear most people do # of cores + 1
plobsing kid51: there may be some benefit for IO bound steps
ash_: if you're looking to build a frame builder, feel free to ask me questions 03:09
ash_ yeah, i saw your libjit one
i am not currently working on it, but maybe later, if i have spare time
i still wish libjit would compile on OS X
plobsing I hear ya 03:10
ash_ i never tried the libjit-linear-scan-register-allocator version on google code, maybe i'll do that one real quick 03:11
03:11 mikehh joined
ash_ i duno if its just me, but i feel a bit like libjit is ummm disorganized 03:11
plobsing ash_: It's kinda moot right now, the branch is stalled out because of GC interferance (yet again)
plobsing wishes that people would just insert more ram when their programs ran out of memeory 03:12
ash_ haha
swapon!
its like a super power for operating systems
03:16 mikehh joined
ash_ didn't someone use the boehm_gc? would that affect libjit any? 03:17
plobsing ash_: not sure. my issues stem from the fact that if you change the size of PMCs used in tests, GC passes change location wrt surrounding code, revealing and hiding bugs 03:18
kid51 IIRC bacek was experimenting with Boehm GC. I think whiteknight commented on those efforts on his blog.
ash_ wrt? i am not familiar with that abbr. 03:19
plobsing with respect to
too many math courses
ash_ ah, got ya 03:20
hmmm
so gc moved your pointer around?
plobsing more like: I moved GC around and GC blew away someone elses pointer because they aren't respecting GC's requirements 03:21
ash_ ah 03:22
plobsing at least, that's my side of the story
ash_ is the gc_encapsulation branch maybe helpful? (seems like gc isn't properly encapsulated)
plobsing perhaps. I'm trying to stay away from GC (too much on my plate already) 03:23
ash_: a good example of a bug I hit a lot is TT #1142
ash_ *foosh sounds as things fly over my head now* 03:24
plobsing yeah, these things tend to involve a lot of components all at once. 03:27
ash_ i'd argue i am smarter than your average bear, but most of the real issues in parrot are beyond me, so... ima just keep working on my nqp thing for now
kid51 msg bacek Did you ever get the access to languages/ you requested in TT #894 ? 03:32
purl Message for bacek stored.
03:33 mikehh joined
dalek rrot: r43644 | darbelo++ | branches/pmc_freeze_with_pmcs/src/pmc/imageio.pmc:
Add a do-nothing ImageIO pmc.
 03:34
cotto "Imagio" sounds like it'd be a good name for a fancy hotel. 03:42
03:48 samlh joined 03:52 darbelo joined
darbelo thaws 03:52
plobsing darbelo: are you doing a verbatim copy of src/pmc_freeze.c?
btw darbelo++ on pmc_freeze_with_pmcs branch 03:53
darbelo plobsing: Not completely. 03:56
But it starts out that way.
I did a proof of concept that replaced some conditionals with API before dinner. 03:57
Right now I'm doing a incremental conversion into that to simplify review.
cotto darbelo, you might want to hold off until kill_array_pmc gets merged. It'll affect some of the freeze/thaw code. 03:58
darbelo I asked whiteknight about that. It's a straightforward change. 03:59
plobsing I ask because I have it in for 'id_list'. It is the same thing as 'seen'. They really should just be one element
cotto ok.
darbelo plobsing: I haven't got rid of that yet.
But I think I can make it more easily killable. 04:01
I also could make ->what irrelevant at the same time. 04:02
Let me check that.
...
dalek rrot: r43645 | darbelo++ | branches/pmc_freeze_with_pmcs/src/pmc/imageio.pmc:
Start filling out the VTABLEs.
 04:07
darbelo Say, what is the 'new' way to call PMC methods from C ? 04:12
I haven't used that since before the big calling conventions redoing. 04:13
Parrot_pcc_invoke_method_from_c_args ? 04:14
cotto sure 04:16
kid51 must sleep 04:20
purl $kid51->sleep(8 * 3600);
cotto Is that in ms, because that's not very long. 04:21
darbelo And "PS->" is takes PMC and STRING, with nothing coming out, right? 04:22
04:35 LaVolta joined 04:36 ash__ joined 04:38 cconstantine_ joined 04:43 cconstantine_ joined 04:47 cconstantine joined
plobsing woot! just finished a rewrite of tools/build/nativecall.pl in PIR. 04:51
cotto w00t to you sir 04:57
plobsing++
you could also use nqp 04:58
cotto hopes not to hear a headdesk
plobsing cotto: I tried. did not enjoy. 05:03
cotto The learning curve can be really annoying. 05:04
darbelo Hm. That didn't work as expected.
cotto You've learned something.
darbelo That exploratory programing should be done after fixing the build. 05:05
cotto "explodatory" programming? 05:12
05:13 cconstantine joined
darbelo It would have been. If I hadn't broken the build before trying :) 05:13
plobsing cotto: it's not really the learning curve, it's that NQP has a different market which drives the design in directions that don't work out well for me
darbelo "Lets see if this works... It's no more broken than before! I'm sure it will work when I fix all of the other problems!" 05:14
05:27 cconstantine_ joined
cotto wonders how "r->color = add_const_str(interp, r);" ever made sense to someone 05:27
05:27 cconstantine joined
cotto pirc can't be ready soon enough 05:28
dalek rrot: r43646 | plobsing++ | trunk/tools/build/nativecall.pl:
eliminate return_type_decl field in nativecall.pl
 05:31
rrot: r43647 | plobsing++ | trunk/tools/build/nativecall.pir:
rewrite nativecall.pl in PIR.
cotto yay! We get our first chicken and egg problem!
well, another one 05:32
plobsing, you could check in a generated src/nci.c and make an optional target to rebuild it
plobsing cotto: my plan is to build miniparrot with a null_nci.c and then use it to build the full parrot 05:35
we already do that for config I beleive
the version controlled generated files is my fallback
darbelo So, miniparrot can't do NCI? 05:36
Not a huge loss.
cotto Isn't nci used internally for something? 05:37
plobsing cotto: methods on C-based PMCs
otherwise, internally we use raw nci PMCs, which don't need the frame builder thunks
darbelo Oh. CRAP.
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc 05:38
Method 'visit_freeze_normal' not found
current instr.: 'main' pc 1214 (config_lib.pasm:324)
darbelo facepalms.
plobsing mentioned trying to stick to VTABLEs on the wiki. they make life so much easier
darbelo Yeah. 05:39
I see that now.
05:43 cconstantine_ joined 05:54 eternaleye joined
nopaste "tene" at 76.27.121.193 pasted "broken lazy gather/take for pmichaud" (124 lines) at nopaste.snit.ch/19414 05:59
pmichaud you're missing a pop_eh in "caught" 06:02
should go right after the .get_results
Tene >< 06:03
pmichaud (no, it probably shouldn't matter.)
other than that, your code looks to me like it ought to work 06:04
Tene It does work, for the simple cases. Try calling .get twice on the returned iter, though. 06:05
pmichaud how are you getting the returned iter?
just a sec, I'll apply locally and see what I see
Tene my $x = gather ...
pmichaud have a good failing test? 06:06
Tene my $x = gather for 1..10 { take $_*2 }; say 'A'; say $x.get; say 'B'; say $x.get;
Oh, that fails differently than it did before... 06:07
pmichaud yeah, forgetting to pop an exception handler introduces odd behaviors.
Tene ah, because I popped the eh, yes. 06:08
The problem is that the second time in .get, it invokes a continuation that then throws back into *the first .get* call.
pmichaud ohhhhhhhhh crap
Tene yeah, see? 06:09
I had a way to deal with this before, but I don't remember it.
pmichaud this is where we really need Parrot to fix its roll-up semantics 06:10
Tene I think I kinda know what we can do... lemme go explore a bit. 06:11
pmichaud if you just want to do an eager implementation for now, that's fine also. 06:12
having a working gather/take is more important than a lazy one at this point
(since a lot of our builtins depend on it)
Tene what data type should gather {}; return, then, in the new world order?
pmichaud GatherIterator is fine for now 06:13
Tene oh, but just prepopulate a list that it walks over, or something?
pmichaud oh, you mean for an eager one
you can create a Parcel with the returned values
so, Parcel
Tene 'k 06:14
pmichaud basically $P0 = new ['Parcel']
and then push the payload from each take exception onto $P0
(note that it has to be the opcode push, not the method call)
that's..... weird 06:16
(looking at the results after the patch, w/pop_eh remembered) 06:17
Tene I'll go do that first, and then go play stack gymnastics.
pmichaud hmmm
continuations might not be a workable way to do this
or we might need a helper block somewhere 06:18
Tene the latter is what I was going to explore.
pmichaud I think I know what is happening--want the gory details?
cotto Just as a sanity check, the things in a PackFile's constants table are never modified, right? 06:20
pmichaud afaik
oh, maybe not
I know subs get modified
cotto I care about strings.
pmichaud I'm not sure what all goes in the constants table
anyway, very few things in Parrot actually seem to be constant :-|
Tene: When we resume back into the block, it thinks its caller is the first get invocation 06:21
(and it is.)
Tene pmichaud: Yes, exactly what I said.
Well, approximately what I said. 06:23
pmichaud my best guess is to use a coroutine (yield) here.
Tene I'll try that, too.
pmichaud essentially, the coroutine is the wrapper 06:24
pmichaud drafts
Tene Ah, yes, I see.
I'll try exactly that, after I test this eager gather patch.
pmichaud want me to draft code for it? 06:25
actually, the coroutine is almost exactly the eager gather patch :-)
except instead of pushing into a parcel, you yield the payload back to the caller :-)
Tene Still want me to push this eager gather commit? 06:26
pmichaud either push it or nopaste it
push is fine if it works :-)
then I'll make suggestions for making it lazy :) 06:27
Tene Oops, forgot that the bot doesn't see ng1. 06:31
I pushed a while ago.
pmichaud ah
looking/working 06:36
(looks good so far)
Tene Writing a coro-based sketch in PIR now.
pmichaud same here.
I'm just going to draft, then let you steal/debug :)
nopaste "pmichaud" at 66.25.4.52 pasted "draft of gatheriterator (for Tene++)" (102 lines) at nopaste.snit.ch/19415 06:43
pmichaud I moved !GATHER out of control.pir and into GatherIterator 06:44
Tene Looks like what I have. I'll report back in not too long. 06:45
pmichaud okay, great 06:46
Tene Parrot seems to break when I try it with lexicals... seems capture_lex doesn't work on coroutines, or something. Works fine when I save state in the GatherIterator, though. 06:56
oh, newclosure instead? 07:02
Oh, no, that doesn't help either. I'll stick with the attribute version. 07:03
07:12 cconstantine joined
pmichaud oh, I suspect you're right about coroutines and lexicals 07:19
Tene s'okay, it's working. 07:22
I just spent 15 minutes hunting a typo. :) 07:23
nopaste "tene" at 76.27.121.193 pasted "working lazy gather/take example" (21 lines) at nopaste.snit.ch/19416 07:27
07:34 fperrad joined
pmichaud Tene++ 07:35
07:35 eternaleye joined
nopaste "tene" at 76.27.121.193 pasted "Another fun example" (15 lines) at nopaste.snit.ch/19417 07:38
07:42 eternaleye joined 08:39 treed joined 08:46 treed joined 08:49 sri joined 08:50 treed joined 09:15 patspam joined
Tene pmichaud: right now, some weird stuff happens in some cases with gather/take. I can only reproduce it when it's in a method on a class, not standalone. 09:20
nopaste "tene" at 76.27.121.193 pasted "Weird breaking case for pmichaud++" (21 lines) at nopaste.snit.ch/19418
09:52 iblechbot joined 09:55 TimToady joined 09:58 chromatic joined 10:06 cotto_w0rk joined
dalek rrot: r43648 | cotto++ | trunk/src/packdump.c:
[packfile] make pbc_dump output line up more nicely
 10:07
10:10 estrabd joined 10:14 bacek_at_work joined 10:18 cotto_w0rk joined 10:21 cotto_work joined
dalek rrot: r43649 | mikehh++ | trunk/MANIFEST:
Re-generate MANIFEST
 10:23
rrot: r43650 | mikehh++ | trunk/tools/build/nativecall.pir:
Add svn properties
cotto The pbc code makes me sad. I need to go to bed.
I can't believe Parrot's running on top of that mess. 10:24
10:24 athomason joined
cotto Actually that's not true. I can believe it. 10:24
sleep &
10:30 workbench joined, estrabd joined, TimToady joined, hudnix joined, jsut joined, jjore joined, purl joined, Infinoid joined, Khisanth joined, FullMetalHarlot joined, wagle joined, nopaste joined, eiro joined, confound joined, cxreg joined, Ryan52 joined, rhr joined, zostay joined
dalek rrot: r43651 | mikehh++ | trunk/tools/build/nativecall.pir:
fix codetest failure - trailing spaces
 10:39
10:43 eternaleye joined
mikehh fulltest - testr FAIL - t/pmc/eval.t - Failed test: 12 - see TT #1142 11:05
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#32001), fulltest) at r43651 - Ubuntu 9.10 amd64 (gcc)
that should be (gcc with --optimize) 11:06
11:09 purl joined 11:18 cotto joined 11:31 iblechbot joined 11:34 joeri joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32002), fulltest) at r43651 - Ubuntu 9.10 amd64 (g++ with --optimize) 11:35
11:46 cconstantine_ joined 12:15 cotto joined, bit-man joined 12:22 LaVolta joined
bit-man Hi 12:32
purl hi, bit-man.
bit-man I'm trying to implement opendir et al. and have some problems
Following docs.parrot.org/parrot/latest/html/...o.pod.html I see that unlink, rmdir, and opendir must be implemented as opcodes 12:33
right ?
The problem is that I figured out how to implement a PMC but not an opcode 12:34
I mean seems that unlink and rmdir are not implemented, right ? 12:35
By chance ... do I have to look at the src/ops folder ? 12:37
12:38 cconstantine joined
bit-man anyone awake ... I'm at GMT-3 ! 12:41
almost noon at Europe and toooo early for US
12:51 cognominal joined
fperrad bit-man, I think pdd22_io is out of date, these features are implemented in the OS PMC, see methods rm & readdir 12:59
bit-man So they must be implemented not as op codes but as OS PMC methods ? 13:00
fperrad, thanks ! 13:03
fperrad bitman, the method rm implements unlink & rmdir 13:08
the method readdir implements opendir/readdir/closedir
but try trac.parrot.org/parrot/ticket/1322
bit-man fperrad, the problem with readdir is that just returns pathnames as strings 13:10
fperrad, I mean all of OS PMC returns and accepts strings then there's no need to return some FileHandle PMC right 13:11
fperrad, Just lets play with strings 13:12
Am i right ?
NotFound What kind of filehandle can rm return? 13:13
bit-man not rm but other methods like readdir 13:14
fperrad bit-man, the opcode open returns a FileHandle PMC 13:15
NotFound Makes more sense to me not having readdir or closedir methods, just opendir.
bit-man fperrad, yes but open cant'be used on folders 13:16
NotFound Then read from and close the object returned by opendir.
bit-man NotFound, for me too but because I was reading pdd22_io and the scenario depicted was completely different
then I thought the dir management methods were not implemented 13:17
or that readdir as implemented that way only for some internal usage
fperrad OS.readdir() returns an array of pathname, it encapsulates all POSIX stuff ie. opendir/readdir/closedir 13:18
NotFound Which is not very consistent with the interest in lazy lists. 13:19
bit-man fperrad, sure and it's great but because pdd22_io was referring to opendir/reddir/closedir then I thought that an implementation according o it was needed 13:20
NotFound, Sorry I don't understand you :-P
13:20 kid51 joined
NotFound bit-man: there is a lot of interest in lazy evaluation in perl6 and parrot. Encapsulating the directory opening/reading/closing in one operation is the opposite way. 13:22
Just imagine a directory with 1e10 entries to see the difference. 13:23
bit-man NotFound, got it
NotFound, :-)
NotFound I've worked with directories of several hundred milliards entries in real work, BTW. 13:24
bit-man Then would be wise to get a single readdir that encapsulates opendir/readdir/closedir 13:27
but that instead of returning an array returns a kind-of-iterator that only reatieves the next entry open request 13:28
and doesn't obtains them all and you iterate through using the Iterator PMC right ?
NotFound Good idea. Iterating should be faster and shorter than calling methods. 13:30
dalek rrot: r43652 | jkeenan++ | branches/tt1393_retcon:
Creating tt1393_retcon in �svn.parrot.org/parrot//branches
 13:53
rrot: r43653 | jkeenan++ | tags/tt1393_retcon-43651:
Tagging trunk at r43651 so that the tt1393_retcon can later be synched to it.
rrot: r43654 | jkeenan++ | branches/tt1393_retcon/src/pmc/retcontinuation.pmc:
Deleting statement as suggested by lithos in �trac.parrot.org/parrot/ticket/1393#comment:29.
 14:09
14:23 hercynium joined 14:39 cconstantine joined 14:58 TonyC joined
mikehh kid51: I get the same result in tt1393+retcon branch as in trunk 15:00
tt1393_retcon branch - fulltest - testr FAIL - t/pmc/eval.t - Failed test: 12 - see TT #1142
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r43654 - Ubuntu 9.10 amd64 (gcc with --optimize)
kid51 mikehh Thanks for the tests. 15:02
afk
15:02 mikehh joined
mikehh I was hoping that maybe TT #1142 might have got fixed, but unfortunately not - it only fails with gcc on amd64 - passes with g++ on amd64 and all variants on i386 15:02
15:02 lichtkind joined 15:13 plobsing_ joined 15:17 PacoLinux joined 15:24 pmichaud joined, Whiteknight joined 15:30 mikehh joined 15:35 tetragon joined, Psyche^ joined 15:36 cognominal joined 15:44 mikehh joined 15:48 cotto joined 15:54 mikehh joined 16:06 eternaleye joined 16:09 mikehh joined 16:15 dalek left, dalek joined
dalek nxed: r378 | julian.notfound++ | trunk/winxedst1.winxed:
replace literal '__eval__' with a const string
 16:25
16:28 mikehh joined 16:50 ash_ joined 16:54 mikehh joined 16:59 theory joined 17:12 ash_ joined 17:14 ash_ left 17:18 jan joined
cotto Coke, ping 17:18
17:19 mikehh joined 17:36 fperrad_ joined 17:43 pdcawley_ joined 17:59 davidfetter joined 18:10 mikehh joined 18:33 Whiteknight joined
Whiteknight can somebody explain to me how hash freeze/thaw works? 18:55
because looking at hash.pmc:freeze and thaw, it doesn't look like any of the values in the hash are actually serialized
and I seriously don't understand how the thaw() works there, or where those values are supposed to be coming from 18:56
19:00 theory joined
cotto The actual work happens in src/hash.c hash_visit. From what I remember, hash_freeze and hash_thaw are called via hash_visit via the visit VTABLE function. 19:09
It's a mess and took me a while to figure out back when I worked on Pipp's arrays.
I think the freeze/thaw VTABLEs are called before/after visit and that visit does most of the work. Don't ask me why. 19:10
plobsing_ freeze/thaw are for visiting non-recursive contents. visit is for recursing. it's to maintain some tree traversal ordering or something like that, even though we're not traversing a tree 19:11
cotto that makes sense 19:12
plobsing_ it makes less sense than I'd like. 19:13
cotto considerably 19:14
mikehh but there still seem to be problems thewre - see my latest comment (and plobsing++) on TT #1142
Whiteknight okay, so...how does Hash.thaw() get data from the stream into the Hash?
or is visit called for both freeze and thaw? 19:15
cotto yup
Whiteknight urg
cotto yup
mikehh :-}
Whiteknight is there any reason why this is all so retarded? 19:16
plobsing_ Whiteknight: the values are pulled into the hash in src/hash.c:hash_thaw()
look for the VTABLE_shifts
Whiteknight plobsing: would you mind taking a look at the kill_array_pmc branch? 19:17
I'm getting a failure in AddrRegistry.thaw, which is just a subclass of Hash
it's failing the assertions in Hash.thaw when that gets called 19:18
plobsing_ what are the key and entry types it is trying to use? 19:22
Whiteknight AddrRegistry uses a keytype of 3, and a value type of -92 apparently
that's according to GDB, I need to look up the actual value of that enum
plobsing_ -92 seems pretty bogus to me 19:23
Whiteknight that's what GDB says for "p (int)enum_type_int" 19:26
plobsing_ Whiteknight: what test is failing? 19:29
Whiteknight all the t/pmc/packfile* tests 19:30
packfile.t, packfileannotations, packfilesegment, etc
plobsing_ hmmm...you probably did something that rearanges the PMCs in the image (which means you need to bump PBC_COMPAT) 19:31
and regen the test pbcs
Whiteknight how to regen the test bpcs?
pbcs?
plobsing_ run tools/dev/mk_native_pbc on i386 19:32
Whiteknight damnit.
Whiteknight boots up his Ubuntu/x86 VM 19:33
plobsing_ alternatively, you could modify mk_native_pbc to run anywhere and fix the ensuing bugs on i386 systems that probably can't read 64 bit PBCs 19:35
19:37 chromatic joined
Whiteknight at least I have a Linux/x86 setup where I can run this stuff now 19:40
NotFound mikehh: TT #1142 doesn't fail for me in amd64 19:49
dalek rrot: r43655 | whiteknight++ | branches/kill_array_pmc/PBC_COMPAT:
bump PBC_COMPAT on suggestion from plobsing++
plobsing_ NotFound: it comes and goes, but can be reliably reproduced with 'make testgcd' 20:02
20:06 davidfetter joined
dalek rrot: r43656 | whiteknight++ | branches/kill_array_pmc/t/native_pbc (4 files):
native_pbc platform updates
 20:07
Whiteknight plobsing++ # bumping PBC_COMPAT worked. All tests pass in branch
mikehh NotFound: it passes for me with g++ and on i386 - it only seems to fail with gcc and only if it invokes GC mark/collect (which could make it intermittant) 20:11
chromatic You need to disable memory randomization if you're running Linux. 20:13
alias freezemem='sudo echo 0 > /proc/sys/kernel/randomize_va_space'
Whiteknight purl msg bacek once the kill_array_pmc branch merges into trunk, we can update gc_encapsulate and should not have any of the current problems with it. 20:14
purl Message for bacek stored.
Whiteknight parrot-linear-algebra passes all tests on branch 20:19
I have a couple ideas in mind for performance improvements to ResizablePMCArray 20:21
maybe that might make a good branch in the near future
plobsing_ Whiteknight: are those on ArrayTaskList?
Whiteknight plobsing_: no, these are ideas I've only had recently
more exploratory than "to do"
dalek rrot: r43657 | whiteknight++ | branches/kill_array_pmc/DEPRECATED.pod:
remove notice about Array PMC from DEPRECATED.pod
 20:23
Whiteknight that might be an issue with the pmc_freeze_with_pmcs branch too. Probably needs to bump PBC_COMPAT after adding the ImageIO PMC 20:28
purl msg darbelo: On pmc_freeze_with_pmcs branch, I think you can bump PBC_COMPAT to fix most of your test failures 20:30
purl Message for darbelo stored.
Whiteknight actually, I'll test that right now while I have VirtualBox fired up 20:33
purl msg darbelo: I just tested locally. bumping PBC_COMPAT fixes some tests but not all of them. Still plenty of failures in the packfile* tests 20:46
purl Message for darbelo stored.
20:55 mj41 joined 20:56 jan joined 20:58 ttbot joined 21:34 PerlJam joined 21:54 eternaleye joined
davidfetter hello 21:58
purl salut, davidfetter.
davidfetter is there some way to arrange for parrot not to use threads?
dalek rrot: r43658 | mikehh++ | branches/kill_array_pmc/PBC_COMPAT:
PBC_COMPAT requires a tab separated list
 22:00
mikehh whiteknight: I get a couple of t/library test failures in make test for kill_array_pmc branch (Class 'Array' not found) in t/library/range.t and t/library/test_more.t 22:01
davidfetter - supposed to be but aparently it still loads the threads module 22:02
davidfetter hrm
davidfetter thinks threads are just generally fail
it's that paper from cal that really convinced me
www.eecs.berkeley.edu/Pubs/TechRpts...2006-1.pdf 22:03
Infinoid ... is that a problem with threads, or a problem with most languages that use threads? 22:09
pmichaud messages 22:11
22:18 kid51 joined
mikehh davidfetter: interesting paper - I agree with infinoid however - functional typy languages are much better than imperative ones in handling threads 22:20
or should I say concurrency 22:21
davidfetter mikehh, that paper pretty much convinces me that the whole thread concept is fundamentally broken 22:22
mikehh not really, just depends on how you use it - its a bit like the halting problem, in theory it's out to lunch but still we get meaningful work done 22:24
oh and also a lot a of junk (garbage :-}) of course 22:26
Infinoid I prefer to let other, smarter people than me talk about how to do concurrency well at the language level. My main problem these days is that C just isn't particularly well equipped to handle threads, and I can think of several other languages that aren't much better 22:42
when you set out to write a threaded application from the start, you usually end up pretty well off. But I can't even imagine how many hacker hours were spent retrofitting threads into existing apps 22:43
to do this right, gcc would have to give me a big fat warning when I get it wrong, like, "warning: you forgot to unlock, you dork" 22:44
mikehh to work with something like threads is would be better if the abstraction level was a bit higher, as with garbage collection - it should be implicit rather than explicit 22:46
Infinoid an __attribute__((must_be_locked_before(this_other_var))) would not be amiss, either
yes. the C threads API is very much nuts-and-bolts
NotFound Are you calling for Ada?
mikehh yes - we shouldn't be dealing with it directly 22:47
go seems to have an interesting approach
NotFound The gane? 22:48
The game?
purl The game is to get a mild case of HSV
mikehh no golang.org
NotFound code.google.com/p/go/issues/detail?id=9
22:50 PacoLinux joined
Infinoid hah, Issue 9! It reminds me of plan 9 from outer space 22:50
NotFound Note that the issue is date Nov 10 and the status is still "New" 22:51
mikehh most of the same bunch are involved -:-} 22:52
NotFound Infinoid: a little late for that type of jokes, the thread is full of them X-)
mikehh: yeah, some "NotFound" for example. 22:53
Infinoid NotFound: I make being late into an art form :)
NotFound mikehh: forget it, I misunderstood 22:55
purl NotFound, I didn't have anything matching it, i misunderstood
dalek nxed: r379 | julian.notfound++ | trunk/Makefile:
add a 'pir' make target for future setup usage
 23:02
23:04 theory joined
kid51 reads that paper 23:09
mikehh kid51: I tested tt_1393_retcon on Ubuntu 9.10 i386 up to fulltest using g++ with --optimize and gcc -with --optimize - all ok 23:10
kid51 That's good news. 23:11
I hope to get some reports from other interested parties, e.g., Util
dalek nxed: r380 | julian.notfound++ | trunk/setup. (2 files):
Testing setup for plumage usage
kid51 Is there anyone on channel now who could test a branch on Win32? 23:12
NotFound kid51: I can, but on my old laptop not very fast 23:14
kid51 speed is definitely not of the essence
NotFound Booting it... 23:15
kid51 Can you do a smoke on the tt_1393_retcon branch?
"... pruning a wild mass of brambles rarely yields a satisfactory hedge." Nice. 23:17
NotFound kid51: checking out... 23:20
purl i guess checking out is so much work
kid51 It's actually spelled: tt1393_retcon
mikehh just on the threads issue - quoting Rob Pike 23:22
And Go is a really good language for writing multiplex servers in, where you use these things called 'go' routines, which are
kind of like threads but lighter-weight, and some communication primitives to do the multiplexing.
23:23 patspam joined
kid51 "If [Intel is] successful, and the next generation of programmers makes more intensive use of multithreading, then the next generation of computers will become nearly unusable." 23:26
23:32 cconstantine joined
NotFound The funny thing is that the multithread dance started at the times of OS/2 1.0 23:33
dngor OS/2 was threads all the way down. 23:34
NotFound More or less the same as speech recognition.
dngor: yes, and almost nobody knew how to put them to good use... just like now. 23:35
23:50 cconstantine joined
NotFound Oh, great, I must reboot windows to finish install of some cpan module :/ 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!