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 31 January 2010.
dalek rrot: r43700 | darbelo++ | branches/pmc_freeze_with_pmcs/src/pmc/imageio.pmc:
Add props, adjust the Copyright, trim long lines and generally try to make codetest happy.
 00:00
00:01 cxreg2 joined
kurahaupo Aah, that's quite possible. Needed FreeNode during LCA2010. 00:01
Whiteknight darbelo: is that branch ready for testing?
kurahaupo1 msg plobsing The "array unshift" problem has gone away because the Array PMC has been removed. Please close TT#1399
darbelo Whiteknight: Yep.
Whiteknight w00t. Updating now 00:02
darbelo There's still some codinstd issues. So don't expect a clean fulltest.
But make test should be passing now.
Haven't checked the c++ build either. 00:03
Whiteknight I'll run some tests 00:04
00:04 jjore joined, Khisanth joined 00:05 bacek joined 00:06 FullMetalHarlot joined, rhr_ joined, kthakore_ joined 00:07 slavorg joined
Whiteknight darbelo: build breaks for me in array.pmc. Can we update from trunk to have that killed? 00:08
darbelo I did.
Whiteknight did you commit it? because I up'd and didn't get those changes 00:09
purl Message for plobsing stored.
darbelo Whiteknight: r43696 00:11
Coke ... purl, you're slow. 00:13
Whiteknight the correct term is "stupid"
00:14 TimToady joined
darbelo Whiteknight: did you try a make realclean? 00:15
Whiteknight I did. And now fresh checkout
dalek rrot: r43701 | whiteknight++ | branches/kill_array_pmc:
branch merged into trunk at r43695 with help from bacek++. Deleting branch
 00:17
darbelo Damm weird. I don't have array.pmc here
And it's not on the makefile either.
Whiteknight I just built on the fresh checkout 00:18
darbelo I tell you, svn is going to turn me into a git convert one of this days. 00:19
kurahaupo1 wonders what svn has done to darbelo? 00:20
dukeleto svn eats babies for brunch
darbelo It tried to trick me into thinking it was an improvement over CVS. 00:21
chromatic It *is* an improvement over CVS.
darbelo Not enough of an improvement in my books. 00:22
kurahaupo1 I concur with chromatic
chromatic I wonder how much you worked with CVS then... ouch, branching.
Lack of atomic commits.
kurahaupo1 Last time I tried "cvs rename dir1 dir2" it was ... horrible.
chromatic Oh wow, I totally forgot renaming. Yes.
Editing the ,v files directly... and sometimes needing to and being unable to do so! 00:23
kurahaupo1 We could always go back to RCS. :-)
darbelo Actaully, I've worked enough with CVS that I know how broken it is and how to avoid it's brain damage. 00:24
Whiteknight or go all the way back to chiseling FORTRAN into stone tablets
kurahaupo1 Nah, chiseling takes too much effort. Much prefer to rub magnets over core memory. 00:25
chromatic "What are all of these white dots?" "Bits."
Whiteknight darbelo: all pass 00:26
darbelo Whiteknight: excelent.
Whiteknight you haven't even seen how poorly SVN is used at my work 00:28
my boss insists on storing the binaries for all third-party compilers and utilities in the repo with the source code
..which got a little bit absurd when we started using VisualStudio 00:29
darbelo UGH:
Whiteknight it's the same boss who also insists on storing all object files and executable files in the repo too
...you know, if you need to build the software but you only have some tape, a paper clip, and a linker 00:30
TonyC one of the microsoft software development books recommends keeping the tools in the repo (so you can be sure version N is build with the same tools you originally built version N with)
darbelo That's ...
darbelo lacks the adjectives needed to describe such horror. 00:31
Whiteknight that's a GREAT idea, if people in the workplace are just using random software versions and there is no effort to standardize 00:32
TonyC well, if you're trying to track down a production problem in version N, since CC N+M might have introduced bugs/fixes that interfere
darbelo Ph'nglui mglw'nafh Cthulhu R'lyeh wgah-nagl ftaghn.
Whiteknight or, you don't upgrade your tools without proper regression testing
kurahaupo1 is melting, and begs apologies in advance for any strange comments he may make. It's 27°C. With no wind. In bright sun. At 100% humidity. All at once. 00:33
chromatic Go indoors.
kurahaupo1 me *is* indoors.
chromatic Go indoors INDOORS.
darbelo Outdoors is ~32
C over here
kurahaupo1 That would put you in, oh Brisbane? 00:34
darbelo Nope, north of Buenos Aires.
Today was a hot day.
kurahaupo1 wonders about the thoughts now going through the Northern Hemisphere contingent, what with us complaining about the heat in the midst of their winter. 00:35
TonyC 27C here (Sydney)
kurahaupo1 Hope you have aircon, or at least some wind. 00:36
darbelo Highest recorded temperature in this year, so far, was 41.3�C IIRC. 00:37
treed yeah, it's like 12 here
and cloudy
TonyC a fan for now
00:38 ash_ joined
kurahaupo1 I notice that Array.pmc has finally been removed. Having tried to debug #1399, it was a good idea in theory, but nasty can of worms in practice. 00:48
(Just to get back on the topic of Parrot for a change)
00:56 abqar joined
Whiteknight So I've got an idea for RPA with using two resizable memory buffers, one with negative indices 01:02
should give identical shift/unshift performance as for push/pop 01:03
kurahaupo1 Why not just a single one, but with head & tail indeces? 01:04
Whiteknight because realloc can't grow a buffer at the head. Only grows at the tail
alternative is to use realloc/memcpy which is expensive
kurahaupo1 Realloc normally does a memmove under the hood. If we open the lid and do the memmove ourselves, that problem goes away. 01:05
Having said that, I think we have a big problem with arrays not being thread safe, or at least, badly suboptimal in performance. 01:06
Whiteknight realloc only does a memmove if the block can't grow linearly
kurahaupo1 If you have two blocks, only one of them can possible grow by expanding into the unused heap. Well, okay, if there's a big enough hole, maybe both. But then we could potentially grow downwards into a preceding hole. 01:08
chromatic Make one single buffer, but don't start at its start. Leave a few blocks free to shift/unshift. 01:10
Whiteknight that's all well and good unless the array is only used for shift/unshift access and needs to grow persistently inthat direction
for cases that never shift/unshift, we have unused wasted sapce 01:11
space
bacek_at_work for the record: it's just "unshift" 01:12
chromatic We always have wasted space; we never allocate only one block at a time.
Whiteknight the one case where my idea doesn't work is where an RPA is used as a FIFO queue 01:13
the only reason I think about this at all is because plobsing reported O(n**2) performance on RPA for shift/unshift benchmarks, as opposed to Array with O(2n) 01:14
"TODO: This always moves the array memory, which is not very performant" 01:18
kurahaupo1 I remember looking at that last year and thinking "it needs fixing". 01:21
Apropos realloc: if you increase the allocation size geometrically, it amortizes out to O(n) 01:22
cotto When in doubt, double something and hope it works out. 01:24
01:31 cotto_work joined
Whiteknight 2**N allocation sizes is definitely the way to go 01:37
but constant memmoves is not good either 01:38
kurahaupo1 cotto: Ratios other than 2 also work. It depends on how short of memory you are.
Whiteknight powers of two has always been preferred where I have seen, but I guess other numbers aren't bad either 01:40
I guess it depends on the OS allocator, which is out of our domain 01:41
chromatic Only if you're afraid of sbrk
Whiteknight I'm going to put together a prototype of my RPA idea with double-buffers. worst case, there is no benefit 01:42
kurahaupo1 Theoretical optimal is about 1 : 1.9276, on the assumption that reallocation can re-use earlier versions. But 1:2 is easier to compute and near enough to same efficiency.
Whiteknight best case, I think we win in some benchmarks
kurahaupo1 How will it do as a FIFO?
01:43 LaVolta joined
Whiteknight kurahaupo1: I'm thinking that if it gets too lopsided we throw in a normalization step 01:44
so if the buffer is 2x larger than the data, we memmove and realloc
kurahaupo1 I suspect you'll want more hysteresis than 2:1, after all that's what you have immediately after the buffer's expanded. 01:47
Whiteknight kurahaupo1: of course, I'm just being brief
kurahaupo1 I've been pondering using arrays in pure-functional languages, and in thread-safe ways. Do we have any concept of a write-only object? (That is, one which is partially initialized, and throws and exception if you try to read from it.) 01:49
Whiteknight if there is more free space at the beginning of the floating buffer than there is data at the end, we memmov.
if there is more than 4x space than data, we realloc down
01:49 eternaleye joined
kurahaupo1 It sounds like you'll want some heureustics to guess whether you're seeing stack-like or queue-like behaviour. 01:49
So that you can choose whether to swap halves when one gets to zero size. 01:50
Whiteknight ideally, we would have different, speciallized datatypes that were either stack-like or FIFO-like 01:52
but no, people want everything
kurahaupo1 Ideally, yes. In Perl, not for a while.
Maybe we should have a default array implementation that has deliberately abysmal performance, and only provide other versions that are optimized for index/queue/stack/whatever but omit "difficult" functionality. :-) 01:53
chromatic Yep. 01:55
Whiteknight so instead of improving RPA performance, we add new types with great performance in limited areas 01:56
kurahaupo1 Exactly. 01:57
Whiteknight PMCStack and PMCQueue types
kurahaupo1 And PMCIndexable and PMCReversable and ... 01:58
Whiteknight well, that's pushing it. We could lazily reverse an RPA by negating an index on a flag
kurahaupo1 Reason I mention pure-functional is the side-effects of single assignment and referential identity. First is, the easy way to roll an array is just to generate a proxy that tweaks index, length, etc and/or concatenates additional or replaced elements.
And reverse is similarly trivial. 01:59
Whiteknight Parrot-linear-algebra uses that trick to do transpose on arrays
we don't actually transpose, just flip an "is transposed" flag
FixedPMCArray and ResizablePMCArray already are optimized for fast indexing 02:00
well, not optimized but not bad either
kurahaupo1 thinks if he was designing Parrot from scratch, there would be I, N, S, C and V registers. C = container, V = value.
My other thought about arrays is that we should separate the type-specific stuff from the byte-munging stuff. How hard is it to do mix-ins in C (in "core" types)? 02:02
chromatic Depends if you only want to mark capabilities or you want to share implementations at the VTABLE level. 02:03
kurahaupo1 Mixing up the vtables I guess. AnyIntegerArray::get_element(int i) would call self.get_byte_ptr(i*sizeof(INTVAL)), which could be supplied by either ResizeableAnyArray or FixedAnyArray. 02:05
chromatic That's much easier in a Lorito world. 02:06
kurahaupo1 To give you ResizeableIntegerArray and FixedIntegerArray. 02:07
Hmmm, sounds like there's a bunch of stuff we need to plan a long way ahead.
02:17 hercynium joined
Whiteknight sounds like that might make an interesting project: a loadable library of optimized storage types like specialized stacks and queues 02:46
throw it together on github, and if things go well maybe get merged into trunk one day
02:52 mikehh_ joined 02:53 plobsing_ joined, Themeruta joined 02:54 jan_ joined, treed_ joined 02:55 szabgab_ joined, kurahaupo joined 02:56 PacoLinux_ joined 02:57 abqar_ joined 02:58 Tene_ joined 02:59 Hunger- joined, PerlPilot joined, davidfetter_ joined 03:00 japhb_ joined 03:01 pmichaud_ joined, ascent_ joined, rhr joined, dukeleto_ joined 03:03 wagle joined, ttbot joined, Coke joined, theory joined, elmex joined, bacek_at_work joined, nopaste joined, TonyC joined, Ryan52 joined, purl joined, chromatic joined, kthakore joined, TimToady joined, LaVolta joined, jjore_ joined, eiro joined, cxreg joined, Infinoid joined, confound joined, hicx174 joined 03:04 ingy joined, bacek joined, Khisanth joined, krunen joined, slavorg joined, tewk_ joined, eternaleye joined, slavorgn joined, integral joined, ttbot joined 03:12 redbrain joined, cotto_w0rk joined 03:22 ilbot2 joined
moderator 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
03:24 pmichaud joined 03:26 kurahaupo joined 03:28 estrabd_ joined 03:30 cotto_working joined, hudnix joined 03:31 jan_ joined, Coke_ joined, zostay_ joined, solarion_ joined, mikehh joined, frodwith_ joined, pjcj joined 03:32 Psyche^ joined, jsut joined, darbelo joined, rhr joined, szbalint joined 03:33 Maddingue joined, GeJ_ joined 03:34 Themeruta joined, ttbot joined 03:35 wagle joined 03:40 Util joined, mj41 joined, payload joined 03:41 elmex joined 03:42 PacoLinux_ joined 03:43 hercynium joined 03:44 krunen joined, integral joined, ascent joined, he joined, dukeleto joined, slavorgn joined, redbrain joined, slavorg joined, preflex joined, kjeldahl__ joined, Khisanth joined, Hunger joined, theory joined
kurahaupo wonders what's up with six people entering #parrot all at once? Connectivity problems somewhere? 03:47
Tene netsplit
TonyC servers under attack
03:52 slavorg joined 03:59 workbench joined 04:41 kurahaupo joined 04:46 LaVolta joined 04:56 silug joined 05:09 patspam joined
cotto chromatic, ping 05:40
chromatic pong 05:41
cotto how deep of a change would it be to store bytecode with subs in pbc? 05:43
chromatic I don't know.
Overall I think it may be doable. 05:44
I don't know if there are any deeper implications to the change.
cotto How much imcc hacking do you think it'd entail? 05:47
chromatic Hopefully minimal to none. IMCC should go through src/packfile.c and other files. 05:49
05:53 kurahaupo joined 06:06 eternaleye joined 06:23 mikehh joined
dalek rrot: r43702 | mikehh++ | trunk/MANIFEST.SKIP:
Regenerate MANIFEST.SKIP
 06:28
06:38 eternaleye joined 06:53 eternaleye joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32027), fulltest) at r43702 - Ubuntu 9.10 i386 (g++ with --optimize) 06:59
07:08 treed joined
treed did irc.parrot.org stop working? 07:08
07:13 fperrad joined
treed Is it possible to rename a parrot;Class once it's been made 07:18
(or give it a name at that point)
aha, the name method 07:34
07:35 fperrad_ joined 07:37 mikehh joined 07:38 LaVolta left
mikehh where's purl? 07:39
07:40 szabgab joined
treed probably still on the other side of the break 07:40
irc.parrot.org seems to have broken
mikehh well slavorg doesn't seem to be doing whatever he does normally 07:41
treed slavorg/n don't have ops
mikehh only 4 ops at the moment and bot privilages 07:43
well nopaste seems there 07:44
07:46 eternaleye joined 07:51 elmex joined 08:04 iblechbot joined 08:06 eternaleye joined 08:29 sri joined 08:41 hicx174 joined 08:48 eternaleye joined 09:02 eternaleye joined
bacek o hai 09:12
09:25 plobsing joined
mikehh bacek: hello 09:25
bacek mikehh, aloha
09:30 riffraff joined
he "make smoke" ends with "Could not upload report to Smolder at smolder.plusthree.com"... 09:35
09:42 barney joined 09:44 eternaleye joined 09:57 JimmyZ joined 10:04 payload joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32031), fulltest) at r43702 - Ubuntu 9.10 amd64 (gcc with --optimize) 10:08
he; I am getting that a lot usually a timeout error, but the file has uploaded, but not completed server-side before the timout 10:10
check if it has uploadede at smolder.plusthree.com/app/projects/..._reports/8 10:12
he mikehh: ah, I usually took that to mean "complete failure to upload", but now I see the result is there.
mikehh your smoke was #32030
he Yup.
mikehh HTTP CODE: 500 (read timeout) 10:13
got to go out for a bit: bbl 10:15
10:18 gaz joined 10:26 riffraff joined
dalek tracwiki: v28 | allison++ | CallingConventionsOverview 10:56
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
bacek ping Infinoid, TonyC, TimToady 11:30
can someone give op to slavorg?
12:39 iblechbot joined 13:09 kid51 joined 13:17 ruoso joined
Coke_ msg mikehh your MANIFEST.SKIP updates seem to be arguing with everyone elses. 13:26
mikehh Coke: in what way? 13:27
all I do is run tools/dev/mk_manifest_and_skip.pl 13:28
also purl is not around to get messages 13:29
13:29 cognominal joined
Coke_ mikehh: yes. so something is screwed up on your or my account. (look at the last 4 changes to MANIFEST.SKIP) 13:29
do you have any local modifications? 13:30
mikehh Coke: nope - I get a test failure from manifests_tests and so run tools/dev/mk_manifest_and_skip.pl which gives me an svn diff which I commit 13:31
manifest_tests (also part of fulltest) 13:33
Coke_ I wonder if those ignores got screwed up by the merge. 13:43
mikehh: what does "svn pg svn:ignore tools/build" tell you? 13:45
mine shows me dynpmc.pl
dynoplibs.pl
Coke so when I regen it now, it has modifications, on top of your commit. 13:48
I also have no local modifications.
13:49 iblechbot joined
Coke wonders why we even have this file. 13:49
mikehh Coke: "svn pg svn:ignore tools/build" doesn't give me anything 14:06
14:07 whiteknight joined
mikehh let me rebuild and see 14:07
manifest_tests PASS and svn status -u ok 14:12
Coke huh. svn pg svn:ignore svn.parrot.org/parrot/trunk/tools/build agrees with you. 14:20
but my svn:ignore on that dir says otherwise, and 'svn st' shows no local modifications. 14:21
yah. something about my checkout was fubar; it's the directory I originally did one_make in, but I didn't do the final merge to trunk, so: 14:26
svn--
mikehh I actually use different directories for tests on gcc/g++ (with or without --optimize) and every so often do a clean checkout 14:27
and a bunch of branch directories as well 14:28
14:34 whiteknight_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32036), fulltest) at r43702 - Ubuntu 9.10 amd64 (g++ with --optimize) 14:37
14:37 rdice joined 15:01 whiteknight joined
whiteknight bacek: ping 15:12
darbelo: ping 15:14
darbelo whiteknight: pong 15:15
whiteknight darbelo: what's the status on the freeze branch?
darbelo Same as yesterday ;)
It looks like it works.
whiteknight okay, I'm coretesting now 15:16
very much looking forward to this branch
darbelo make test is passing, and all I saw on a fulltest run were codingsdt failures.
15:18 davidfetter joined
whiteknight I really need to add freeze/thaw support to the parrot-linear-algebra types 15:18
darbelo HLLs that implement their own PMCs in C will have to make adjustments to their vtables. 15:19
15:20 hicx174 joined
davidfetter oh hai 15:20
whiteknight darbelo: yeah, that's why I haven't added freeze/thaw to those types yet.\\ 15:24
darbelo If you don't poke too deep into the struct all you should need is a signature change. 15:25
15:32 Psyche^ joined
dalek trixy: 5bcfee0 | Whiteknight++ | t/2-function.t:
fix the number of functions tests from 8
 15:34
whiteknight darbelo: in branch, all tests pass in parrot-linear-algebra
testing matrixy now 15:35
darbelo Excelent.
whiteknight is there any way to get the ImageIO PMC from PIR now?
darbelo Not yet. Unless you want to create it by hand. 15:37
whiteknight okay, so next step is to add a variant of the freeze opcode that returns P
darbelo Yes, but it's not entirely useful yet. 15:38
whiteknight ok
it can be made useful in a week if we wanted 15:39
matrixy passes all tests
darbelo whiteknight: Yes, this should be much easier to refactor now.
whiteknight that whole subsystem needs an overhaul: renaming functions, refactors, cleanups, etc 15:40
a freeze_cleanups branch might be a nice thing to start immediately after this one lands
15:41 payload joined 15:45 davidfetter joined
davidfetter hello 15:48
davidfetter gesticulates wildly 15:49
whiteknight hello davidfetter
davidfetter is there some way to make a generic NCI API that would be a "plugin" to HLLs?
darbelo How generic?
davidfetter well, it's wrappers around pg's SPI (and possibly a few other, but all known) functions
this would be for PL/Parrot 15:50
fun as writing PL/PIR will be, i don't expect that to drive adoption
Coke (generic NCI API that is a plugin)... don't we already have that? 15:51
(in core, that is?)
davidfetter well, that was what i'm wondering about
darbelo davidfetter: code.google.com/p/parrot-mysql/ ? 15:52
Yeah, I know, wrong db :) 15:53
But did you mean something like that?
davidfetter vaguely
but i want it to actually work 15:54
after years of experience around mysql, i do not assume that anything advertised has even been built, let alone actually works at any level
whiteknight darbelo: all codetests pass in pmc_freeze_with_pmcs after r43704 16:02
merge that sucker
darbelo whiteknight++
16:05 Andy joined
whiteknight most of the functions in src/pmc_freeze.c can just disappear now, I think 16:09
or, with small effort 16:10
dalek rrot: r43703 | whiteknight++ | branches/pmc_freeze_with_pmcs/src/hash.c:
fix codestd failure in src/hash.c
 16:11
rrot: r43704 | whiteknight++ | branches/pmc_freeze_with_pmcs/src/pmc_freeze.c:
fix codetest failure in src/pmc_freeze.c. All codetests pass
16:33 bluescreen joined 16:41 cotto_w0rk joined 16:45 bluescreen joined 16:50 cotto_working joined 16:53 mikehh joined 16:59 mikehh joined 17:11 rdice joined 17:13 hicx174 joined 17:17 mikehh joined, payload joined
darbelo svn-- 17:24
17:27 mikehh joined
whiteknight Coke: ping 17:36
anybody else here on a mac? 17:37
darbelo This merge is full of conflicts on files *I've never touched* WTF?
whiteknight great 17:38
did you merge into your branch from trunk?
darbelo whiteknight: Yeah, right after array died.
whiteknight that could be the problem
svn does not like doing logical things like updating a branch to trunk 17:39
darbelo Wasn't svn sprinkling cute props all over in over to be smarter about that?
Ohh, this is excelent. It's showing conflicts over files that aren't present on *either* side of the merge. 17:41
17:41 rdice joined
darbelo This is retarded. 17:41
japhb__ (reasons we should have switched to git a year ago) += 1
darbelo japhb__: you missed a few zeros after that one. 17:42
cotto If you want to help, you could set up a trac instance to test how well the git plugin works with svn integration.
That'll be the big blocker when it comes time to switch afaict. 17:43
cotto goes to work
17:45 estrabd joined
whiteknight how do I make an exception handler that DOES NOT handle die exceptions? 17:45
NotFound whiteknight: only die, or just sverity less than die? 17:48
whiteknight when I say "die" I want the exception to be unhandled and I want the program to exit
NotFound whiteknight: AFAIk there is no way to distinguish if the exception comes from die or for throw. 17:49
whiteknight ok 17:53
18:01 theory joined 18:13 wagle joined
Coke whiteknight: pong 18:14
whiteknight Coke: are you on a mac now?
Coke whiteknight: I don't currently have a mac.
whiteknight oh, damnit
ls 18:15
Coke sorry, "a mac with gcc."
but I knew that's what you needed. =-)
whiteknight I just need a mac with parrot on it
how parrot got there, I don't care
darbelo "I'm sorry sir, but I have no idea how that parrot got here." 18:16
NotFound BTW, someone has build parrot on Maemo? 18:17
szbalint anyone running parrot on arm lately? 18:20
darbelo We had reports of success, for some values of lately. 18:25
cotto_working #ps in 125
darbelo The new schedule, right? 18:26
cotto_working yup
szbalint wants to be the first person to get Parrot and Perl 6 up and running on a Nokia N900 18:29
darbelo starts considering git-svn
NotFound szbalint: I've just ordered today a N900, hope can help with testing at least. 18:33
szbalint I need to hurry up then =) 18:34
cotto_working I have to wonder how much less painful git-svn would be.
szbalint you're still mostly chained to svn for collaboration
darbelo If I'm not chained to svn for merging, I'm happy. 18:36
NotFound szabgab: Don't worry, most probably I'll try to port my Basic interpreter before attempting something with parrot.
Or any other of my crazy retrocomputing projects.
szabgab NotFound, www.flickr.com/photos/szbalint/3812328050/ 18:37
NotFound szabgab: Ok :D
18:37 allison joined
szabgab :-) 18:37
Coke parrotsketch?
curse you, purl. 18:38
allison delayed by two hours at last email message
darbelo Coke: It got movet to later.
Coke darbelo: I know.
I was making sure purl was updated.
darbelo Purl is dead.
Coke (Did you see I responded to the email on the list?)
allison ah, just saw it now 18:39
darbelo checks
Oh yes you did.
And I saw it too.
allison (had seen a bunch of replies this morning when I checked)
good idea to update the calendar
Coke allison: I'm going to tell robrt to go ahead and kill piper. (tweety is already dead.) 18:40
sokay?
anyone? 18:42
allison sounds good
Coke sent. 18:43
Once I get word back, I'll ping the list.
18:50 plobsing joined, davidfetter joined
dalek trixy: 608798f | Whiteknight++ | (2 files):
update the computer() builtin to have the correct behavior. No tests for it, pending a strategy for doing it
 18:56
trixy: 38bc659 | Whiteknight++ | (2 files):
fix small problem in filesep
trixy: ee102b7 | Whiteknight++ | (5 files):
refactor the way we handle quit() so that it actually works from interactive mode. exit() is now a toolbox function that calls quit, instead of a builtin
trixy: 50686c2 | Whiteknight++ | src/builtins/quit.pir:
some expansions in quit(), mostly TODO notes to bring it up to standard
trixy: bc99ce8 | Whiteknight++ | t/functions/filesep.t:
add a test for filesep
trixy: 2704312 | Whiteknight++ | toolbox/is (3 files):
add isunix, ismac, ispc functions. No tests yet
18:59 chromatic joined 19:00 SamuraiJack joined
japhb__ plobsing, Is there a doc somewhere that details what nativecall.pir brings to the table? 19:04
Meaning, what can it do that the earlier code could not? 19:05
19:05 estrabd joined 19:06 japhb joined 19:09 athomason joined
whiteknight darbelo: ping 19:10
darbelo whiteknight: pong
whiteknight darbelo: how easy would it be to freeze multiple PMCs and write them to a single file, and then get them back again? 19:11
darbelo You can do that now if you are willing to stick them into an array. 19:12
Coke does /anyone/ use ncigen? 19:13
darbelo Wasn't that needed by OpenGL?
tewk_ ncigen is my baby. you want to chuck it? 19:14
I still think its a cool idea, but the old pge was too slow parsing c, I need to see if the new regex engine is any faster. 19:15
Coke tewk_: see TT#338 - it's the only thing using tools/build/dynpmc.pl, and it's broken. 19:16
plobsing japhb__: there currently is not. I could throw it into NCITasklist if you want. 19:19
whiteknight ah, I hadn't thought of that. Putting it into an array is a good idea
japhb plobsing, please do, thank you.
whiteknight a hash might be better, for matrixy's needs though
Tene Coke: every time I tried to use it, it wasn't able to handle the .h files I wanted to parse. 19:20
tewk_ Coke, I don't think it uses dynpmc.pl, that is just cut and paste Makefile stuff
japhb darbelo, OpenGL works (unless someone changed it while I was out) by writing a massive list of entries to call_list.txt (or rather, to files that feed into it). 19:21
(during configure)
I would be extra-double-plus happy if OpenGL could move out of core, but currently, it can't (and still work). 19:22
Coke japhb: why not? 19:24
oh, because you need call_list updated?
japhb Coke: exactly
Coke I think the long term goal s to make call_list obsolete. 19:25
japhb Nod.
Coke tewk_: it's in there. perhaps the rule that uses it is never invoked.
lemme see if I can rip it out.
plobsing japhb: my long term goal with the nativecall.pl rewrite is to eliminate the need for call_list
japhb plobsing, excellent. The shorter term that goal is, the better. ;-) 19:26
tewk_ Coke, nopaste comming
whiteknight plobsing: how are you planning to do that? 19:27
Coke tewk_: already ripped it out.
tewk_ cool
whiteknight, libjit I'm guessing?
libffi could also do it too 19:28
plobsing whiteknight: not exactly. can be done with static thunk libraries 19:30
writing plans in NCITasklist as we speak
AFK 19:34
Coke NotFound: any reason not to apply tt# 918 now? 19:35
chromatic +1 to applying it now 19:36
NotFound Coke: deprecation notice says 2.1 19:37
Coke NotFound: yes. that's now.
NotFound Oh... yes, confused again %-)
Coke I've got it applied locally and am running a test. 19:38
NotFound Will do, then.
Coke excellent.
all tests pass.
darbelo: what TT is that for? 19:40
(pmc_freeze)
mikehh bah need a re-boot bbiab 19:41
Coke also, test failures following your merge.
darbelo Can't remember the number. Let me check.
Coke ... did you not run make test?
darbelo I ran make fulltest and it worked.
Coke smells like a PBC_COMPAT probem. 19:42
darbelo Bumped that, and regenerated native pbcs before merging.
dalek TT #338 closed by coke++: deprecated: dynoplibs.pl and dynpmc.pl 19:43
tracwiki: v5 | plobsing++ | NCITasklist
tracwiki: trac.parrot.org/parrot/wiki/NCITask...ction=diff
Coke developers.facebook.com/news.php?bl...;story=358 19:44
19:44 mikehh joined
Coke ok. realclean required after your mergeback. thbbthp. 19:44
realclean--
(facebook URL is about a PHP -> C++ code transformer facebook wrote.) 19:45
dalek rrot: r43705 | coke++ | trunk (6 files):
Remove tools/build/dynpmc.pl, resolve TT#338
Coke dalek, keep up , buddy. 19:46
mikehh still no purl - who is purl's mentor?
rrot: r43706 | darbelo++ | failed to fetch changeset:
Merge pmc_freeze_with_pmcs into trunk.
Coke hachi.
IIRC.
chromatic Sounds right. 19:50
19:52 mikehh joined
mikehh my internet connection is causing problems - going to restart it - bbiab 19:53
Coke ughs, as he remembers why he didn't convert dynpmc to a non-recursive makefile earlier. 19:54
19:55 particle joined
dalek rrot-linear-algebra: e7d84d6 | Whiteknight++ | README:
update README to use the new setup.pir utility from fperrad++
 19:55
rrot-linear-algebra: 4d57990 | Whiteknight++ | src/pmc/ (2 files):
add initial freeze/thaw prototype code for NumMatrix2D. This requires pmc_freeze_with_pmcs branch, which isn't merged into Parrot trunk yet. Will have to set a minimum parrot version once that merges
darbelo Coke: pmc_freeze was TT #1305 19:56
just closed it.
Coke darbelo: don't forget to update DEPRECATED.pod 19:57
darbelo I thought I had done that in the branch...
Coke doesn't look like it made it to trunk. 19:59
darbelo It will after you svn up ;)
dalek TT #1305 closed by darbelo++: [DEPRECATION] The IMAGE_IO structure. 20:00
rrot-linear-algebra: 275596f | Whiteknight++ | (2 files):
add a PARROTREVISION file with minimum required Parrot svn revision number
 20:02
darbelo fperrad: ping 20:03
dalek rrot: r43707 | darbelo++ | branches/pmc_freeze_with_pmcs:
Branch merged into trunk and is no longer needed.
 20:04
rrot: r43708 | darbelo++ | trunk/DEPRECATED.pod:
The visit_info structure is no more. Remove it from DEPRECATED.pod
20:06 iblechbot joined
Coke any web developers here? anthonycalzadilla.com/css3-ATAT/index.html 20:13
NotFound t/tools/pgegrep.t segfaults in amd64 built with c++
20:16 jan joined
Coke chromatic: I had a few links I had meant to send you about modern perl and version numbers, so you could comment on them in a kibo-like fashion. I've lost them. :( 20:17
20:19 kurahaupo joined
chromatic Pity! 20:20
dalek rrot: r43709 | NotFound++ | trunk/src/pmc/imageio.pmc:
[cage] add a cast to make c++ happy
darbelo Aw. I thought I had gotten all of those.
Coke chromatic: I'll try harder not to lose them next time. 20:21
cotto_working #ps in 9
NotFound from outer space 20:22
whiteknight allison: I have a question for you about the get_results refactor 20:28
chromatic Where's the wiki page with our December 2.3 planning notes? 20:29
whiteknight did we have a page for it?
darbelo recall a googe doc. 20:30
ps in 0
chromatic I have the spreadsheet; I can't find the wiki page or the mail.
allison there was a google doc, wasn't that all we did? 20:31
chromatic Maybe so. I only see the spreadsheet we made beforehand though. 20:32
allison chromatic: we edited it in session 20:33
20:33 estrabd joined
dalek tracwiki: v18 | allison++ | CallingConventionsTasklist 20:35
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
tracwiki: v19 | allison++ | CallingConventionsTasklist
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
chromatic That doesn't look like the list though.
dalek rrot: r43710 | NotFound++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc] generate a static function from custom class_init instead of inserting the code into the generated one, TT #918
 20:36
whiteknight allison: after the returns refactor, how would a function get information about expected returns?
Tene whiteknight: out-of-band 20:37
whiteknight out-of-band?
Tene I'll try again.
the same way it could get information about expected type constraints on its returns. 20:38
allison whiteknight: something like a "set_wants" opcode, or the ability to set return expectations on the context
(the CallContext, which is both the call signature and the context)
whiteknight allison, ah, okay
allison I didn't specify the interface because I figure we need to talk that over with the language devs and see what's most useful to them 20:39
but, I'll go add a bullet point now, so we make sure to get language input before the branch lands
whiteknight gotcha. Matrixy definitely is going to want to have information about expected return arguments. Has very complicated handling of variadic output arguments 20:40
moderator Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: deprecated core PMCs, ops -> dynops, GC tuning and implementation | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs 20:40
20:42 joeri joined 20:45 purl joined
whiteknight Tene: Okay, I think I have a better handle on it. I suspect it could be very easy to do by adding a method to the CallContext PMC 20:50
Tene whiteknight: let me give you an example of the functionality this is hoped to handle.
20:51 estrabd_ joined
Tene In Perl 6, when there's an error in normal cases, it's saved in the lexical variable $!, which will hold all of the errors that happened in that block. At the end of the block, or any other way of leaving it, $! is checked for these unthrown exceptions, and if any of them haven't been handled, they're actually thrown. 20:51
21:02 bacek joined 21:05 bacek joined
PerlJam Coke++ 21:12
dalek trixy: 1fa3691 | Whiteknight++ | src/parser/grammar-plan.txt:
update the plan for the parser refactor
 21:13
21:18 AndChat| joined
Coke so, docs is easy enough to update to non-recursive make. dynopslib and dynpmc both require makefile preprocessing, so I'm going to have to generate their .mak files. 21:22
dalek TT #679 closed by coke++: Hash changes to AssociativePMCArray 21:23
NotFound Not so easy the performance test with Winxed, I must improve some type propagation in expressions in Winxed first. 21:24
21:24 rdice joined
plobsing just missed #ps. darn. 21:25
dalek rrot: r43711 | coke++ | trunk/DEPRECATED.pod:
Ticket rejected, remove notice.
21:25 darbelo joined
Coke I'm very interested to see the performance differences. I think that'll definitely help focus dev efforts constructively. 21:25
21:26 payload joined
NotFound Coke: and I'm very interested in having Winxed doing the right thing, expect some results soon. 21:26
Anyway, a pure pir equivalent will not be so hard. 21:27
21:36 jan joined
dalek nxed: r395 | julian.notfound++ | trunk/winxedst1.winxed:
size in array declarations lacked optimize step in stage 1, fixed
 21:39
tracwiki: v6 | plobsing++ | NCITasklist 21:41
tracwiki: trac.parrot.org/parrot/wiki/NCITask...ction=diff
21:41 jan joined
NotFound Unintuitively, with pmc array is a lot faster than with integer array, and I'm not sure ye if it's winxed fault. 21:43
I'll try a pir version first.
AndChat| It's not doing lots of shift & unshift by any chance? 21:45
NotFound Just populating the array and adding his elements several times
21:50 jan joined 21:55 joeri joined
nopaste "NotFound" at 213.96.228.50 pasted "Simple speed comparaison FixedIntegerArray vs FixedPMCArray" (45 lines) at nopaste.snit.ch/19450 21:56
21:58 preflex joined
NotFound Coke: ping 21:58
Coke pong. 21:59
NotFound Coke: here is a simple comparaison
The last nopaste
purl well, the last nopaste is for shared lib... dynamic linking
Coke you must have a fast machine. =-) 22:02
nopaste "coke" at 65.91.151.195 pasted "With a slight modification to" (21 lines) at nopaste.snit.ch/19451 22:03
NotFound Not so bad :)
Coke I thought moritz's machine was fast, but you're running in it 20% of the time his does.
2.592/2.726 22:04
purl 0.950843727072634
Coke 2.726/2.788
purl 0.977761836441894
Coke .541/.692
purl 0.781791907514451
Coke your speedup is more dramatic.
NotFound Is a Intel Qaud Q6700 with Debian amd64 22:05
Quad
Uh... not, those results are from the laptop... 22:07
Intel Dual T3200 with Ubuntu 32 22:08
On the big, less differences, but I have an unoptimized build rigth now. 22:10
22:11 allison joined
NotFound Optimized: PMC user 0m0.428s - Integer user 0m0.368s 22:16
chromatic How about a Callgrind comparison? 22:17
NotFound chromatic: I gently leave that part for you ;) 22:18
chromatic Won't be today sadly! 22:25
cotto_working It's not hard. I'll give it a shot. 22:26
NotFound Coke: please nopaste your version, to use we all the same code
22:27 hercynium joined
dukeleto i think #plparrot sketch it starting now, if anybody wants to join #plparrot on fleanode 22:31
szbalint fleanode++
cotto_working NotFound, here you go 22:38
nopaste.snit.ch/19452
chromatic 8.455% faster using FIA with an optimized Parrot. 22:41
NotFound The differences between optimized and non optimized versions are impressive 22:42
chromatic Much of that is no more PARROT_ASSERT
cotto_working I was surprised.
NotFound Aye
22:51 patspam joined
darbelo purl: msg fperrad See nopaste.snit.ch/19453 for fixes to lua after the pmc_freeze_with_pmcs merge 22:53
purl Message for fperrad stored.
23:08 cotto_w0rk joined 23:09 cotto_work joined
darbelo Hm. How is taking care of LOLCODE this days ? 23:12
s/How/Who/
Tene Me, allegedly. 23:17
I haven't actually done it, but I wrote it, and I should be listed as maintainer.
darbelo You have a failing test, then. 23:18
test 6 of t/01-vars.t fails for me on OpenBSD with the latest trunk. 23:19
Tene Yeah, I don't think that one has ever passed. 23:23
darbelo I'm making a round of HLL testing after the pmc_freeze_with_pmcs merge and noticed that. 23:24
Figured I'd let you know.
23:25 Whiteknight joined
Tene Thank you. 23:27
It's great to hear that it still lives. :) 23:28
I really need to go through and update all the languages to the new HLL interop specs.
I had everything working between several languages, and then it changed. :)
darbelo Not only it lives, but it also might get some attention from the PL/Parrot crowd once that get going. 23:29
dalek cnum-dynpmcs: r195 | darbelo++ | trunk/src/pmc/decnum (2 files):
Update the freeze() and thaw() VTABLEs to the new signatures.
 23:32
dukeleto PL/Parrot folks have been talking about using LOLCODE as our first HLL 23:37
Tene I'd be glad to help with whatever needs to happen there. 23:41
23:56 eternaleye joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!