Parrot 0.6.0 "P&P" released | Please mentor for SoC | parrotcode.org/
Set by moderator on 7 April 2008.
00:02 paco joined
Coke pongs whoever that was. 00:11
particle lazy bum 00:12
Coke floss? 00:25
purl floss is probably Free/Libre and Open Source Software : en.wikipedia.org/wiki/FLOSS or useless to a toothless bot
diakopter cpan is not installing Test::TAP::HTMLMatrix on x86 solaris 10. grrr. test failures in Petal. 00:26
Coke oh, duh. "make -j realclean" 00:32
(damn that's faster.)
what is t/library/mt19937ar.t ?? 00:44
diakopter well, Petal installed using the system perl. the system perl it is. 00:48
cotto_work that was committed earlier today: www.parrotvm.org/svn/parrot/revision/?rev=26843 00:54
Coke test is failing. 00:55
Coke sees why.
dalek r26849 | coke++ | trunk: 00:59
: [build]
: Generate PBCs for two recently added library PIR files: This allows
: the newly minted test for mt19937ar a chance to pass.
diff: www.parrotvm.org/svn/parrot/revision?rev=26849
diakopter finishes setting up the x86 solaris autosmoker 01:00
tinyurl.com/3ujukq 01:10
skids would like to smoke on hp-parisc debian but still alignment problems as of last night's cvs. 01:15
won't even build.
diakopter takes a vote: netbsd or freebsd for the next autosmoker. or both? 01:16
i'll take that as a both. 01:17
Infinoid both++ 01:32
skids: what alignment is hp-parisc, anyway? and what are the problems?
ok, you know you've been playing too much D&D when you think "alignment" in the "good or evil" sense, and automatically turn that into "big and little endian", without realizing alignment is something else. 01:33
skids I think it's probably the same issue as i86 32bit-on-64-bit would have. Hold on let me grep for the IRC log 01:35
particle you can perl Configure.pl -m=32 or something like that 01:38
that will build 32bit on a 64bit arch
--m=32 Build 32bit executable on 64-bit architecture. 01:39
memory++
Infinoid let me try that 01:40
particle leo used to do it all the time on amd64-linux
Infinoid but, uh... if amd64 running x86 code has different alignment constraints, that doesn't sound like very good x86 emulation
so it surprises me.
particle diakopter: you may find the smoke cycle is faster with rm -rf * && svn extract rather than make realclean && svn up 01:41
yeah, i don't expect different alignment constraints
Infinoid all right, more -j bugs 01:42
src/pmc/parrotio.c:17:35: error: pmc_fixedintegerarray.h: No such file or directory
src/pmc/parrotinterpreter.c:17:35: error: pmc_fixedintegerarray.h: No such file or directory 01:43
particle hrmm
i wonder if that's fallout from recent FIA changes
probably not 01:44
Infinoid Coke seemed to have a master plan regarding automatic dependency generation, which sounded like a good idea
maybe it missed this. or maybe there's something we need to update
skids Infinoid: nopaste.snit.ch/12492 01:45
Oops I guess maybe that expired.
Infinoid needs a libicuuc
(a 32 bit one, that is)
tetragon ICU4C? 01:46
Infinoid that might be a Configure.pl bug. Could it have detected the 64 bit one by accident?
tetragon: huh?
tetragon libicu is from ICU4C
Infinoid [...]/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.3/../../../libicuuc.so when searching for -licuuc 01:47
[...]/ld: cannot find -licuuc
tetragon It's ICU4C
Infinoid thanks. unfortunately, gentoo tends to group 32-bit emulation libs into emulation packages, and I'd rather just find a way to disable ICU in Configure.pl 01:48
(gentoo's system makes it hard to find which package to install)
nopaste "skids" at 71.233.204.100 pasted "parrot build warnings and failure on PA-RISC linux" (70 lines) at nopaste.snit.ch/12643
tetragon --without-icu? 01:49
skids nopaste.snit.ch/12643 <<-- is from older svn co but many of the same warning and same failure when I checked yesterday.
Infinoid oh. pointers have alignment constraints?
tetragon: thanks, trying that now
skids: is there a way we can tell gcc to apply those constraints to the integers (or whatever) that are being casted? can we wrap it up into a PARROT_STRICT_ALIGN macro somehow? 01:50
skids Yeah in some environments various things are aligned differently and pointers have more bits if they are char * or point to code vs data.
Infinoid wonderful. no wonder ia64/pa-risc has the most linker code of any architecture. 01:51
skids Well, if I were a C99 expert I could answer that :-) As it is I can just know vaguely what the problem is.
Infinoid sooo... is there an __attribute__((align=picky)) or somesuch? :)
skids A lot of the code chunks are copying to a local var anyway, and if the macros can rearrange into memcpy that would work... see the URL in the nopaste for a BSD hacker's take on the matter. 01:53
Infinoid I don't see a URL 01:54
particle luckily, that platform isn't required for parrot 1.0
Infinoid thanks for helping me to understand this btw :)
particle it'd be nice to have, but we can march forward without it
skids Well you know -- 64bit -- with it you have huge ass pointers that choke your memory bus. Without it you have crummy memory paging tricks. 01:55
What's a guy to do?
Infinoid we'll see how painful it is to fix up... if we can macroize it into something that gets declared along with variables that get involved with pointer casting, it probably won't be too bad.
particle really wants amd64/win32 fixed up
Infinoid skids: run out of memory, just like I do on amd64 :) 01:56
I used to think 2 gigs was big. Heh.
tetragon Infinoid: I grew used to running out of address space on my 32-bit processes
Infinoid tetragon: yeah, that's a problem too. but my current one is, amd64 process memory footprints are twice as big as x86 ones, so 2GB of RAM just doesn't cut it 01:57
for years I was thinking we should formally introduce RAM as a form of currency. But the inflation rate is horrid. 01:58
tetragon Infinoid: I'm more used to Power/PPC64 than amd64
skids yeah well ram is cheap, bandwidth is the real problem.
Infinoid skids: any chance you can dig up that BSD hacker's URL? 01:59
particle: what's the issue with amd64/win32? does it run? does parrot build? 02:00
particle doesn't config
oh wait 02:01
it builds, but everything's all funky
it basically always segfaults because sizeof int and sizeof ptr are different
the backtraces are fun. the interp is at a different location in every stack frame 02:02
skids mail-index.netbsd.org/tech-kern/200.../0001.html
sorry i thought it was in there
tetragon What's so strange about LP64 platforms?
Infinoid hmm 02:04
particle: what's so different about amd64/linux and amd64/win then? coz it all works here.
JIT is disabled by default... otherwise things are looking pretty good. 02:05
particle it's windows that has the size differences
translating from function to data pointers and vice versa
Infinoid blinks 02:06
both of my pointer types are 64 bit
particle there are incorrect assumptions in the parrot source that sizeof int == sizeof ptr
Infinoid I've fixed all of those that I've come across
are your data pointers and function pointers really different sizes? wow. 02:07
particle i'm updating my 64bit wc, i'll try to rebuild
tetragon msdn2.microsoft.com/en-us/library/a...S.85).aspx
particle yep
Infinoid that sounds painful to fix
particle which is pretty much why it isn't fixed yet 02:09
Infinoid all pointers are 64-bit, here. I'm in shock :)
particle i've gotta eat. perhaps we can take it up later, or tomorrow. 02:12
tetragon++ for the nice link
particle runs configure & make and walks away
skids (and will return to figure out he was not in the cwd he thought he was :-) ) 02:14
02:23 kid51 joined
skids re freeze/thaw what's it used for? Because for complex structures you can spend extra cpu time making them dense for low-bandwidth network transmission, or not if they are just being packed for relocation or something. 02:25
Coke are we still having those new make -j failures? I can't see where the pmcs you refer to actually include those files they were complaining about. 02:48
(and the automatic dependency checker for PMCs is already checked in...) 02:52
Infinoid I'll try to reproduce it, I think the delay from not using ccache helped 02:53
it occurred while I was doing a Configure.pl -m=32 on amd64, so there may have been other weirdnesses occurring
Coke ah. I can duplicate it.
(with a clean, and then "make src/pmc/parrio.o" 02:54
(will have this fixed shortly) 02:58
03:00 purl joined
Coke Infinoid: fixed. 03:13
dalek r26850 | coke++ | trunk:
: [build]
: Improve dependencies-
: * some static .h files depend on autogenerated .h files, be explicit.
: * using METHOD requires FIA.
: This fixes the broken deps for src/pmc/parrot{interpreter,io}.o
: Infinoid++ for finding the bug.
diff: www.parrotvm.org/svn/parrot/revision?rev=26850
03:17 particle joined
Coke writes a quick script to check the deps on all the other pmc files. 03:20
Infinoid Coke++ 03:21
Coke ooh, found one. 03:23
odd, I can't duplicate that one. =-) 03:39
make -j 666 world works. 03:49
Infinoid there isn't enough parallelization in the build tree to allow that many processes 03:50
otherwise, make -j without a count would hose systems
which one was failing?
Coke fixedintegerarray.pmc failed for me once, but I was unable to duplicate it on a retry; I had thought it was because I had added it as another dep of itself, but it seems ok. 04:09
Coke finds a bogus op. 04:29
dalek r26851 | coke++ | trunk: 05:00
: Resolve ticket #46479 (Remove rt.saved.search from tools/util/release.json?)
diff: www.parrotvm.org/svn/parrot/revision?rev=26851
r26852 | coke++ | trunk: 05:10
: Resolve ticket #46911 ([TODO] [Perl] Investigate todo item within tools/dev/install_files.pl)
: Remove old TODO comment that didn't tell us what to do.
diff: www.parrotvm.org/svn/parrot/revision?rev=26852
05:15 Dave joined 06:15 uniejo joined 07:02 iblechbot joined
dalek r26853 | fperrad++ | trunk: 07:30
: [docs]
: since r26756, list_unjitted.pl moved in tools/dev
diff: www.parrotvm.org/svn/parrot/revision?rev=26853
08:33 IllvilJa joined 08:34 Senaka joined
Senaka purl: seen infinoid 08:34
purl infinoid was last seen on #parrot 4 hours and 44 minutes ago, saying: which one was failing?
Senaka hi all... when is the #parrot-sketch meeting? in GMT? 08:35
08:36 cosimo_ joined, cosimo joined
Senaka ok got it 08:37
purl: parrotsketch
purl i think parrotsketch is 18:30 UTC, Tuesdays or a weekly status meeting for parrot design team
08:55 ruoso joined 08:58 Debolaz_ joined 09:01 Maddingu1 joined, skids joined 09:08 particle joined 09:13 ruz joined 09:16 Khisanth joined 09:24 AndyA joined 09:35 tetragon joined, skids joined 10:15 ambs joined
rotty how do the lib/Parrot/Test/<Language.pm> files relate to the test harness? 10:24
10:28 AndyA_ joined 11:36 AndyA joined 11:48 paco joined 11:56 AndyA_ joined 11:58 Daveman joined 12:00 Ademan_ joined 12:02 iblechbot joined 12:15 ambs joined
rotty seen barney? 12:16
purl barney was last seen on #parrot 15 hours and 22 minutes ago, saying: calling it a day, looking forward to rotty's patches
ambs seen merlyn? 12:19
purl merlyn was last seen on #moose 18 days and 14 hours ago, saying: ... methodsandmessages.vox.com/library/...ltalk.html [Mar 20 15:09:20 2008]
ambs :-S
12:50 Daveman joined 12:58 kj joined
dalek r26854 | fperrad++ | trunk: 13:01
: [Lua]
: - fix table.sort()
diff: www.parrotvm.org/svn/parrot/revision?rev=26854
13:05 wknight8111 joined 13:22 skids joined
wknight8111 anybody else try to build this morning on r26854? 13:37
pmichaud I was just about to do so :-) 13:39
takes about 2 min
ambs svnups 13:40
pmichaud seems to work fine here 13:41
at least, I was able to build okay
paco making 13:43
ambs builds ok
diakopter I just smoked r26843 on several platforms 13:44
oops r26853
ambs this is not smoking yet, but with the heat it should smoke soon O:-)
wknight8111 I ran it just now on the latest, and make is complaining about a cyclic dependency
pmichaud wknight8111: what platform? have you recently done a 'make realclean'?
wknight8111 i did nmake realclean, configure, nmake. 13:45
#52596
did it twice, actually. same result both times 13:46
particle nopaste?
purl i think nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or paste.husk.org/ or poundperl.pastebin.com/ or paste.scsys.co.uk/ or don't bother me while I'm eating
nopaste "ambs" at 77.54.92.255 pasted "Test Summary Report - Mac OS 10.5.2" (10 lines) at nopaste.snit.ch/12647 13:49
ambs 1 test failing 13:50
paco on linux make smoke ok 13:51
nopaste "wknight8111" at 71.230.33.251 pasted "Build error on r26854" (56 lines) at nopaste.snit.ch/12648 13:53
Coke wknight8111: bah. that's my fault: gmake apparently says 'oh, that's a circular dep, I'll drop it.'
hang on.
purl i guess hang on. is this from the command prompt, or from within the ide?
wknight8111 okay, thanks 13:54
rotty why does the test harness execute this: [perl -le '... some code...'] ?
13:55 Theory joined 13:56 AndyA joined
Coke wknight8111: is it possible to get nmake to *tell* us what the circular dep is? 13:56
13:58 rdice joined, iblechbot joined
pmichaud coke: nopaste.snit.ch/12648 13:58
says it's src\\pmc\\pmc_fixedintegeraray.h 13:59
Coke ... that tells us one node in the cycle. =-)
pmichaud ah
Coke wknight8111: can you try removing the dep of src/pmc/pmc_fixedintegerarray.h from src/pmc/pmc_fixedintegerarray.dump and rebuild? 14:03
ah, I can at least get the error message with 'make src/pmc/fixedintegerarray.o' 14:05
ambs me too 14:07
diakopter Coke: in languages-smoke on linux, it was hanging up on tcl/t/cmd_expr.t for a very long time 14:08
14:08 Ademan_ joined
Coke diakopter: yes, it's slow. 14:10
wknight8111 I dont think nmake can be more verbose, I'll check the options 14:12
no, it doesnt have a more verbose error reporting mode 14:13
Coke wknight8111: fixed, I think.
sadly, I had a patch very similar to that which i threw out yesterday because it didn't seem to be needed on my box. Thanks for the report. 14:14
dalek r26855 | coke++ | trunk:
: [build]
: Avoid circular dependency for fixedintegerarray: while it's used for METHODs,
: we can't have it require it to be built before it's built.
diff: www.parrotvm.org/svn/parrot/revision?rev=26855
wknight8111 let me try updating to that and see if it fixes my problem
ambs seems to build ok 14:15
ambs makes real clean and tries from scratch 14:16
Coke you'd need a reconfig at least.
14:21 AndyA_ joined
ambs ccache++ 14:22
Coke ... make -j ++ ++ ++ 14:23
ambs Coke: does parrot compile with -j already?
Coke yes. 14:24
if it doesn't, tell me.
ambs nice
paco I can compile with -j
particle can we config with -j ;)
ambs nice
Coke particle: we could if we switched our config to a makefile. 14:25
config dep management.
particle P::FM could be used 14:26
Infinoid make -f Configure.mk -j
make -j
particle but, really, || test is where we need to go
Infinoid make test -j
nopaste "particle" at 24.19.3.148 pasted "infinoid: that stack trace i promised you" (37 lines) at nopaste.snit.ch/12650 14:31
particle has a mexican jumping interp 14:32
libparrot.dll!runops_slow_core(parrot_interp_t * interp=0x0000000000000000, ...
whee!
cognominal scary 14:33
Infinoid stack smash?
particle this is life with parrot on x86_64-msvc 14:34
Infinoid that almost looks like a buggy stack dumper.
thanks for the paste
particle if i step through a program, i can watch the interp move around 14:35
it's not the dumper that's buggy
14:36 AndyA joined
wknight8111 yeah, build worked this time! Thanks Coke++ 14:44
14:48 AndyA joined 15:20 contingencyplan joined 15:27 ask_ joined 15:31 peeps[work] joined 15:35 cognominal joined 15:39 grim_fandango joined, contingencyplan joined 15:48 Theory joined
Coke wknight8111: heh. break the build, fix teh build, get karma. =-) 15:49
rotty karma rotty?
purl rotty has neutral karma
particle rotty++ 15:50
...and it begins.
rotty karma rotty?
purl rotty has karma of 1
rotty :)
thanks
particle karma particle
purl particle has karma of 1277
15:50 nopaste joined
particle waits for 1337 15:51
karma coke
purl coke has karma of 1837
particle karma must be age-based :P
purl must be age-based :p has neutral karma
particle purl is so stupid. 15:52
cotto_work purl, purl?
purl i heard i was going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or so stupid or a smartass or the sixth beatle. or www.infobot.org or dumb or a butt sniffer
15:56 sjansen joined
wknight8111 purl is definitely a butt sniffer 16:00
purl, purl? 16:01
purl i am going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or so stupid or a smartass or the sixth beatle. or www.infobot.org or dumb or a butt sniffer
wknight8111 it's the small things in life 16:02
16:04 contingencyplan joined 16:32 kj joined, kj left
particle Tests=11110 16:46
yay! parrot has thirty tests now. 16:47
Tene hehe
wknight8111 how often is the documentation on parrotcode.org updated to reflect the current file documentation? 16:49
particle every hour or so iirc 16:57
or maybe it's daily. coke would know
wknight8111 oh, i didn't realize it was so frequent. I was under the impression that some of the files were a little out-of-date 16:58
17:03 particl1 joined
particle opbots, names 17:04
17:20 ambs joined
jonathan particle: I can't make parrotsketch, will you be there? If so, I can paste you my report in /msg 17:23
particle paste it to #parrotsketch 17:25
it's logged, after all :)
jonathan oh, good idea ;-)
well, mention I left it there :)
particle sure
jonathan don't want to look like I'm slacking ;-)
ok, done 17:26
gotta go - dinner with $DAYJOB folks
particle ~~ 17:27
Infinoid gets back from the dentist with half his face numb 17:29
particle ...as long as it's not the top half...
pmichaud I always noticed that major portions of my wallet were missing... :)
Coke docs on the website are cached for 24 hours usually.
particle welcomes our viewers who have just returned from scrollbackland 17:30
Coke fires up his UTC clock. 17:32
pmichaud 17:33 here 17:33
Coke hai.
ambs 18:33 here
pmichaud ambs, your UTC clock is an hour off :-)
Coke PS in about an hour, or your parrot is free.
it's 18:33 in london. =-)
ambs Coke: and portugal
purl portugal is .pt
Coke is guessing they just went to DST or something.
ambs yes
pmichaud 18:33 in london, yes. but it's still 17:33 (now 17:34) UTC 17:34
ambs for one week or two. Can't remember
Coke ambs;OH. you meant here==where you are, not here==utc from your standpoint. =-)
ambs pmichaud: true
pmichaud utc is the same everywhere
Coke english is hard.
wknight8111: don't respond to the autoreply, respond to the ticket. =-) 17:35
wknight8111 man, I'm bad at this whole system 17:37
I need to be banned from all this
Coke nbd. just that no one else has your original autoreply, so it shows as two threads now. =-) 17:39
rotty why does the test harness evaluate "perl -le "print join qq[\\n], @INC" ? 17:47
Infinoid are you asking what it does? 17:48
rotty what it does and why it's there
Infinoid it's grabbing perl's module search-path 17:49
avar if it's screwing with your non-p5 harness_perl you might be interested in the hack I used in kp6 to get around that
rotty Infinoid: it does that even when the "exec" parameter to the harness is set to something different from perl, which will not work
avar: kp6? 17:50
purl somebody said kp6 was mean as an infrastrucure to implement STD
Infinoid rotty: where? having trouble grepping for that
avar kindaperl6
rotty avar: where is the kp6 code? it's neither under languages nor compilers... 17:51
pmichaud kp6 is in the pugs repo
rotty Infinoid: don't know, I also could not find the causing place...
Infinoid hmm.
pmichaud who (if anyone) is working on parrot's test harness at the moment? 17:52
avar I basically did exit 0 if "@ARGV" =~ /perl -le "print ... /
in the kp6 executable, there may be a better way around it
Infinoid rotty: oh, it looks like test harness boilerplate. its in Test::Harness::Straps (that's /usr/lib/perl5/5.10.0/Test/Harness/Straps.pm on my system)
Coke kp6 is also "kinda perl 6" 17:53
purl okay, Coke.
rotty can someone fix the Parrot harness to not invoke that boilerplate if exec is not perl? 17:54
rotty is a Perl noob
Coke how are you running the parrot harness if your exec is not perl? 17:55
Infinoid its a side effect of using the normal perl Test::Harness, which was written with perl in mind. I'm not sure what's the best way to tackle that
avar suggests his way of doing it:) 17:56
or write a shellscript wrapper around your program
rotty Coke: use Parrot::Test::Harness language => 'eclectus', exec => [ 'petite', '--script' ],
Coke ah.
rotty Infinoid: can't one somehow override that behaviour in Parrot::Test::Harness ? 17:59
Infinoid rotty: considering your command line is straight from the Parrot::Test::Harness SYNOPSIS, it would probably be a good idea to make it work *somehow* :) 18:02
pmichaud rotty: what problem are you looking at/trying to address?
(high level) 18:03
rotty pmichaud: running tests with an interpreter that is not perl
pmichaud rotty: languages/perl6 does it
as does languages/abc
rotty pmichaud: these use `compiler => ...', not `exec => ...' 18:05
pmichaud so, you need it to run tests with an interpreter that is neither perl nor parrot 18:06
rotty pmichaud: exactly
pmichaud and exec => doesn't work?
rotty pmichaud: it sorta does, but there is an spurious invocation of the interpreter with args only suited for Perl 18:07
pmichaud rotty: okay. I think I remember seeing a problem like that somewhere before. 18:09
I'm of the opinion that we should re-do parrot's test harness from scratch
particle starting... now. 18:11
pmichaud I was going to ask questions about it during #ps today 18:12
should we stick to Test::Harness, or move to TAP::Harness?
Infinoid if you're going to design a new one from scratch, please *please* design it with parallel execution in mind
pmichaud we still need Test::TAP::HTMLMatrix? What dependencies do we have?
Coke ... isn't ewilhelm already on this?
particle ewilhelm or AndyA can tell us a bit about how TAP::Harness fairs on the platforms we care about 18:13
Coke we only need tth for our existing smoke setup, which we've already discussed dumping.
particle or whether they think it's ready to support our needs. i'm fairly certain the answer is "yes"
pmichaud Coke: perhaps, but my impression is that ewilhelm is more interested in helping someone else build the parrot harness as opposed to building it himself
particle the folks in oslo were working on the yaml diagnostics for tap
i don't know how long until we have a framework built around it that we can use for smoke 18:14
pmichaud well, my reason for wanting to support tth is so that we can get a public "here's what passes" display for rakudo
18:15 kj joined
Infinoid can we do that on the server side? 18:15
one less dependency that way :)
pmichaud Infinoid: can we do... what? ... on the server side?
Infinoid the public "here's what passes" display 18:16
pmichaud so, the local make smoke passes the test results to a server which then formats it into html?
in other words, we just need a tap => html tool or something? 18:17
Infinoid maybe I'm confused. how does yaml tie into this?
pmichaud I don't understand that part either :-) 18:18
Infinoid if you guys want to support yaml, you can. it can be converted to html later if needed
particle Infinoid: the tap infrastructure is destined to support yaml 18:19
so the output would be yaml already
then it's a matter of writing something that merges the yaml streams and converts to html
pmichaud does it need to be yaml? why not just parse the tap output? 18:20
Coke "why not just use something that already exists". =-)
pmichaud coke: what do we have that exists and works?
Coke smolder?
purl smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP).
18:22 AndyA_ joined
pmichaud smolder looks promising 18:26
18:28 chromatic joined
particle smolder++ 18:29
ambs seen merlyn 18:30
purl merlyn was last seen on #moose 18 days and 20 hours ago, saying: ... methodsandmessages.vox.com/library/...ltalk.html [Mar 20 15:09:20 2008]
chromatic #ps time
particle merlyn doesn't hang out gere
here
rotty Infinoid++
ambs particle: I know, but purl stands on #perl 18:31
O:-)
Infinoid rotty: what did I do?
rotty you told me about Test::Harness::Straps :) 18:33
19:03 Senaka joined 19:06 Senaka joined, Senaka left, rdice_ joined
dalek r26856 | fperrad++ | trunk: 19:11
: [Lua]
: - fix random library
: - add tests
diff: www.parrotvm.org/svn/parrot/revision?rev=26856
nopaste "particle" at 24.19.3.148 pasted "sizes" (10 lines) at nopaste.snit.ch/12652 19:12
mj41 smolder or my TapTinder .... mj41.cz/wiki/TapTinder :-)
particle hrmm... taptinder. 19:20
nopaste "chromatic" at 63.105.17.30 pasted "Does This Fix 64-bit Pointer Size Problems in UnManagedStruct?" (282 lines) at nopaste.snit.ch/12653 19:24
Coke chromatic++ # managing PS. 19:28
chromatic The src/mmd.c assertion checks for four-byte pointer alignment, I think. 19:29
I'm trying to decide if it has endian problems. I don't think so.
I don't know a portable way to check if a pointer is properly aligned though. I suspect the compiler won't let you make one that isn't. 19:30
(or it's a bad compiler)
Coke chromatic: you have a few tickets assigned to you that may be leftovers. Can you ditch anything that's assigned to you that you don't want?
chromatic ditch or fix?
Coke well, fix would be best, but if they're ones you're not going to get to them soon, ditching them is probably better. 19:31
particle Figuring out how to pack() Parrot's types...Configure.pl: Unable to find an integer type that fits a pointer. 19:32
Infinoid particle: how is your perl built? 19:33
particle tees his configure and make output for 64bit
Infinoid: it's activestate's 64bit build
i can get details. do you want -V ?
Infinoid no thanks, pack() should have something, we're just detecting it wrong 19:34
nopaste "particle" at 24.19.3.148 pasted "perl -V" (93 lines) at nopaste.snit.ch/12654
particle well, there it is anyway
Infinoid twist my arm a little harder. :) 19:35
particle nopaste.pl++
19:36 Theory joined
Infinoid wait, what? 19:37
purl wait, is -L "follow link" or "gimme information about the link proper"...
Infinoid intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
your sizeof(long) isn't sizeof(void*)
nopaste "particle" at 24.19.3.148 pasted "configure output" (86 lines) at nopaste.snit.ch/12655
particle that's correct.
chromatic There's one problem then. 19:38
particle it's how the platform's designed. don't blame me
gotta love that long long isn't c89 19:39
Infinoid purl, forget wait,
purl Infinoid: I forgot wait,
particle so there's no way to fully support c89 on this platform
spinclad there's no uint64 or such? 19:40
particle msdn2.microsoft.com/en-us/library/a...S.85).aspx
rotty seen barney? 19:41
purl barney was last seen on #parrot 22 hours and 47 minutes ago, saying: calling it a day, looking forward to rotty's patches
19:41 ambs joined
Infinoid weird that activestate 64bit is built with use64bitint=define, yet intsize and longsize are both 4 19:42
particle oh, god, no. trying to install parrot 0.4.12? 19:43
Coke is replying.
btw, someone forgot to update parrothist.pod
Infinoid particle: perl -e 'my $var = pack("q", 1); print(length($var), "\\n")'
does that print 8?
Coke ... or, I'm an idiot.
Coke checks.
idiot. check.
Infinoid t/codingstd/idiot.t..... ok (idiot detected) 19:44
particle Infinoid: 8
19:44 Psyche^ joined, allison joined
Infinoid ok, that's the packtype we need, now to get it detected properly 19:45
particle t/project/architect.t...ok (allison detected)
confound haha 19:46
allison hi particle
I was able to get my driver's license and vehicle registration changed, fingers crossed that the license will arrive in the mail before I leave the country next Wednesday 19:47
particle one step forward.... 19:48
Coke what's the new VM for perl6? Chuck Norris. One punch and your code will run in half the time. 19:51
allison :)
pmichaud is that going to be the name of the next release? ;-) 19:52
s/the next/a future/
Infinoid suggests "and boy are its arms tired" 19:53
allison 0.6.1 codename "Chuck Norris"
cotto_work shouldn't that name be saved for a more mature release?
Infinoid hah 19:54
allison 62.99.99
ambs lol
chromatic Re: pa-risc, I vote for removing the lines 1974-1976 in src/mmd.c 19:56
allison those were bad years anyway ;) 19:57
ambs lololol 19:58
ambs wasn't around yet
particle that's why they were so bad
pmichaud (1974-76) I agree. I was quite pleased when the 80s finally rolled around
chromatic ITYM "Morning in America" 19:59
Oh hey, here's the problem. 20:00
include/parrot/parrot.h:142-153
If pointers and intvals are the same size, hooray!
Otherwise if pointers and longs are the same size, hooray! 20:01
particle egad.
chromatic Otherwise, pointers and unsigned ints are the same size! They must be! What else might they be?
confound heh
Infinoid I think win64 needs to use hugeintval here
chromatic I think something needs to use "IT'S NOT AN INT OKAY?" there. 20:02
particle why not check to see if INT64 is defined?
pmichaud argggh, I've been reading perl too long. At first I thought all those lines were comments. :-|
ambs lololol
particle let's set up a trigger to prevent pmichaud from committing c code
Coke sachmet?
confound Coke: not here 20:04
nopaste "Infinoid" at 96.238.213.50 pasted "particle: so... does "long long" work? (possible_win64_fix.diff)" (86 lines) at nopaste.snit.ch/12656 20:07
Infinoid particle: I'm looking at the "Figuring out how to pack() Parrot's types...Configure.pl: Unable to find an integer type that fits a pointer." line from your Configure.pl output. 20:08
Coke confound: I was asking purl. 20:10
confound oh, sorry.
Coke np. =-)
nopaste "particle" at 24.19.3.148 pasted "configure output, post patch" (85 lines) at nopaste.snit.ch/12657
Infinoid you know, I'm not sure the "ptrconst" value probed for is ever actually used 20:11
but I guess that fixed it. thanks for testing, particle
particle i'm rebuilding now 20:12
lots of conversion and pointer truncation warnings still remain 20:13
Infinoid "ack -a" only reports the detection, testsuite, and generated config output. ptrconst isn't ever used, that I can see
Infinoid fixed something worthless! o/
particle priceless.
ambs hehehe 20:14
Coke if it's never used can we rip it out now?
nopaste "chromatic" at 63.105.17.30 pasted "Avoid (Some) Pointer Cast Truncations" (15 lines) at nopaste.snit.ch/12658 20:15
chromatic Does this help, particle?
Infinoid Coke: might as well, and see what breaks.
Coke ... is there an easy way for me to get a list of every generated file in the repo? 20:16
Infinoid MANIFEST.generated ?
purl it has been said that MANIFEST.generated is wrong.
Coke ... hurm. svn st, mebbe.
rotty barney has commit acess right? 20:17
chromatic right
Infinoid svn st --no-ignore | cut -c 8-
(that will also include local modifications.)
rotty anticipates barneys review of his patches 20:18
rotty notes that StGit rocks for managing a patch series
particle chromatic: perhaps some, but still src\\ops\\experimental.ops(51) : warning C4312: 'type cast' : conversion from 'opcode_t' to 'FLOATVAL *' of greater size
zillions of opcode_t and size_t warnings 20:19
ambs makes test one more time, as he does not know enough about parrot atm.
chromatic opcode_t is Parrot_Opcode which is a typdef'd long for me. 20:20
Hm.
Maybe I need to fire up the 64-bit box in the other room and cajole it. 20:21
Infinoid and long is 4 bytes on win64
nopaste "particle" at 24.19.3.148 pasted "partial nmake output after patches" (1400 lines) at nopaste.snit.ch/12659 20:22
Coke Infinoid: I'm taking that list and running the same dependency checker that I used on the PMC .o files. 20:24
hopefully this will rule out any non-race-condition based deps.
wknight8111 is there a way in nqp to initialize an array at once? like @array := (1, 2, 3);?
particle wknight8111: no 20:25
wknight8111 that's what I figured.
thanks
particle no list context
pmichaud that might actually change a bit in a future pct revision
i.e., @array := (1, 2, 3); might work
but not much else will -- i.e., hash initialization will still require individual elements 20:26
wknight8111 I'm trying to write up a simple example of an octal-bin converter, as an intro to PGE. I'm using a lookup table for the conversion
I was just hoping for an easy way to do it
pmichaud I tend to use strings for that sort of stuff. :-) 20:27
particle that's what i was thinking
wknight8111 oh you're right. I could do that, couldn't I?
wknight8111 isn't too bright
particle you'll fit right in.
ambs Files=565, Tests=11150, 333 wallclock secs (224.10 cusr + 49.19 csys = 273.29 CPU) 20:29
:D
Coke finds some missing deps. whee! 20:32
particle coke++
20:35 ruoso joined
Coke will let this run and fix them later. 20:36
wknight8111 is there a way to turn PAST off? I'm writing a little program that parses input, but doesnt form a tree or anything 20:37
pmichaud could just use --target=parse 20:38
depends on what you mean by "turn PAST off", I guess.
chromatic Try to move in after the first date, for another option. 20:39
wknight8111 well, I dont want to make any PAST nodes, but when I run the program I get the rror "Unable to obtain PAST from program::Grammar"
pmichaud the program is written in nqp?
wknight8111 So i've been including an empty "make PAST::Stmts.new()" line
yes
pmichaud did you try it with --target=parse? 20:40
wknight8111 I'm trying to demonstrate PGE, so I have a grammar, and a little NQP that prints out if the input is valid or not
--target==parse prints out the whole parse tree, which I dont want either 20:41
particle languages\\perl6\\src\\utils\\perl6doc\\actions.pm
20:41 AndyA joined 20:42 iblechbot joined
wknight8111 this is such a stupid little program. I'm going to forget about it for a while. thanks 20:44
particle wknight8111: the file i pointed you to will show you how to print from PAST
that's what perl6doc does now
Coke I am interested in consolidating Makefiles. 20:45
(do we really need a separate Makefile for compilers/*, e.g.) 20:46
particle thinks the root Makefile is way to long
pmichaud I find the separate makefiles easier to manage
particle used to work on projects where every directory had a makefile 20:47
Coke you can have separate *input* makefiles, that's fine.
pmichaud do you mean to consolidate multiple *.in files into a single Makefile? 20:48
Coke yes.
pmichaud I don't like it -- too much potential for action-at-a-distance 20:49
unless we have a really well defined set of macros and things that we know exist in the root makefile
(and that other makefiles don't touch)
particle .include is your friend
Infinoid does nmake understand .include? 20:50
particle it has an include syntax. 20:51
!INCLUDE
Coke ... action at a distance?? 20:53
pmichaud if I'm modifying pge.in, the rules I add coule affect other .in files in the master Makefile
s/coule/could/
Coke the separate makefiles we have now prevent using -j on the various subdirectories, and prevent having an understanding of all the dependencies. 20:55
Infinoid I dislike having included Makefiles - wherever the included makefile is in a different directory, all the relative paths are wrong.
rotty what would be the advantage of compiling to NQP instead of PAST?
Infinoid however, I dislike having separate "make" invocations even more, because as Coke says, it breaks -j. 20:56
Coke Infinoid: we could fix that if we did the includes at compile time.
er...
at *configure* time.
when we're already massaging the heck of the .in files.
Infinoid that works for me
pmichaud I'm not sure that having a single makefile means we understand all of the dependencies, but I'll pass on that
personally, -j doesn't seem all that important to me
but that doesn't mean it's unimportant to others, I guess
rotty: (compiling to NQP versus PAST) -- I'm not sure I understand the question? 20:57
particle || test is more important than || make, becausue test takes way longer 20:59
Infinoid t/codingstd/linelengths.tap: t/codingstd/linelengths.t $(PARROT)
it doesn't get much uglier than that. :) 21:00
pmichaud misses the ugliness 21:01
particle times 623 is the ugliness, i think he means
Infinoid yeah, what I just proposed is horrid
pmichaud yes, I'd accept that as being ugly :-)
.t.tap seems better :-) 21:02
Infinoid looks forward to a rewritten harness
particle of course we won't use make to manage || test
rotty pmichaud: barney said the next step for eclectus would be to compile to NQP instead of PAST, and I'm not sure that this will be an advantage
Infinoid at least make wouldn't have blatant perly assumptions about the language of a test script
particle nqp instead of pir? or past?
rotty nqp instead of PAST
pmichaud rotty: I agree -- but I would guess (and this is just a guess) that he meant to use NQP to create PAST instead of some other transformation 21:03
rotty pmichaud: no, as the compiler is implemented in Scheme ;)
particle yeah, that's what i think barney meant, too
barney likes playing with multiple back-end implementations
pmichaud rotty: then perhaps he means to use nqp instead of scheme 21:04
rotty: but you know his statement better than I do
I'm not sure compiling to nqp would be better... but it might not be bad either 21:05
rotty pmichaud: I doubt that (switching to NQP), as (AFAIU) the eclectus language is about a compiler implemented in Scheme 21:06
well, I'll ask barney when he turns up
pmichaud rotty: yes, we'd have to ask barney then
Coke looking at the makefile for PGE... the rules for PGE.pbc seem overly complicated. 21:12
pmichaud first we remove any existing PGE.pbc 21:13
Coke ... why?
pmichaud because if a later step in the build fails, we don't want the old copy sitting around where someone thinks it passed
Coke if you have properly spec'd dependencies, make should handle all of this for you.
no?
purl well, maybe.
pmichaud no.
Coke aside from "the build failed." which should be a pretty big clue. =-) 21:14
pmichaud except that it's all too easy to overlook
I kept overlooking it, which is why I put the rm in there
Coke ok. why do you build PGE twice?
and RM it twice?
pmichaud it's a staged library (more) 21:15
the 'name' rule is written as a perl6 rule (from PGE/builtins.pg)
so in order to compile it, we have to have a working copy of PGE
Infinoid miniPGE? 21:16
pmichaud so we build a copy of PGE with no builtins, then use that copy of PGE to compile the builtin rules, then recompile PGE with the builtin rules
Infinoid we can serialize that nicely, if we can call the two versions different filenames 21:17
Coke ja.
chromatic You should port PGE to JavaScript, then use it to build itself with no rules, then use it to build itself with rules, and then use it to remove PGE.pbc.
I think a Perl 6 compiler magically falls out of there around step 7.
pmichaud except that the program that compiles the builtins (Perl6Grammar.pir) expects to load PGE.pbc
so if we have a miniPGE, we also need a miniPerl6Grammar.pir
Coke we can tweak it to take a param. 21:18
pmichaud and this is all important.... why?
chromatic Is it worth it to take a param though?
Coke pmichaud: because we need someone other than you to be able to maintain the makefile. =-)
pmichaud I can add comments into the makefile
Coke that would be most helpful.
pmichaud but creating a separate minipge seems to me to be more maintenance hassle than what exists now 21:19
Tene pmichaud: can you write a makefile to add the comments for you?
Coke *thwap*
pmichaud and what exists now is fairly robust in that it doesn't leave partially-built pge.pbc files around that might get used
Coke neither would Infinoid's version.
pmichaud yes, it would
at least it would on my system
because if building PGE.pbc fails, the makefile doesn't automatically remove $(PARROT_LIBRARY)/PGE.pbc
Coke not if you spec'd the dependencies properly and didnt' reuse the same name. 21:20
Infinoid when all else fails, output to PGE.pbc.tmp and rename it into place
Tene Oh! We should differentiate based on case! PGE.pbe and pge.pbc.
Infinoid Tene: yeah! and you could have one letter per stage... so it looks like its inflating
pge.pbc
Pge.pbc
PGe.pbc
pmichaud Makefiles don't automatically remove their targets if they fail to build
Tene Best idea ever.
chromatic Parrot writes out unfinished PBC files if they fail to build?
Or am I misunderstanding?
pmichaud parrot doesn't destroy existing pbc files 21:21
Coke I think pmichaud is targetting the case where you've already built once.
pmichaud which may have come from a previous build
Infinoid which is fine, unless something has changed, in which you should depend on something
pmichaud points to the dependency in the rule above
chromatic Okay, I thought it might be that. 21:22
pmichaud I have a dependency in place for $(PARROT_LIBRARY)/PGE.pbc
Coke but if the build fails, it *fails*.
pmichaud but if one of the sources changes, I'm not guaranteed that PARROT_LIBRARY/PGE.pbc isn't the old version
Coke pmichaud: if the make succeeds, you should be. 21:23
pmichaud (if the make fails)
Coke then the make *fails*.
Infinoid and PGE.pbc's timestamp isn't bumped
pmichaud right but the old library is stilla round
Tene Coke: he said earlier that he kept failing to notice that the make failed.
particle have all depend on clean
Infinoid heh
by the way, if pmichaud's caution is warranted, it's probably necessary for more than just PGE.pbc.
pmichaud this is only weird because we have two separate places for PGE.pbc to live 21:24
Coke which we shouldn't.
(which is another issue.)
pmichaud so, you think PGE should be in runtime/parrot/library ?
Infinoid fixing one thing at a time sounds easier
Coke if that's where we're running it from, yes.
what does the compile in compilers do? 21:25
pmichaud nqp and past also?
Coke er..
the 'copy'
purl the 'copy' is, like, named 'clone'
Coke If these are core components of parrot, they should be in a core location.
library seems reasonable to me, yes.
pmichaud tge? 21:26
purl i think tge is slooooow. or the tree grammar engine or how you transform a PGE Match Hierarchy into PIR code.
Coke anything in compilers, yes.
pmichaud imcc?
purl rumour has it imcc is the c of parrot or the problem or the intermediate code compiler
Coke does imcc have any generated PBC files?
pmichaud it's obviously core
so it belongs in.... src?
Coke let me stop you from enumerating: "everything in compilers/ that generates a PBC should probably generate that PBC into the library."
pmichaud and their makefiles should be part of root.in? 21:27
Coke that's a separate issue, but yes, I think os.
"so"
pmichaud what if PGE simply compiled direct to $(PARROT_LIBRARY)/PGE.pbc ? 21:28
and didn't create the copy in compilers/pge/ ?
Coke I'm not entirely sure why it's not already doing that.
+1
purl 1
Coke smacks uprl.
I am having definite transposition issues today. :(
particle uprl yours!
chromatic If PGE put its finished PBC in $(PARROT_LIBRARY), it could build the stage 1 PBC in the local directory and use that for the stage 2 build. 21:29
... provided we can convince Parrot to prefer that PBC over the one in $(PARROT_LIBRARY). 21:30
pmichaud right
chromatic ... which eventually we should be able to do anyway.
pmichaud that's the issue I came up with
particle is there a reason to keep stage 1 around?
if stage 2 builds, remove stage 1
pmichaud as it is now stage 1 isn't kept around
Infinoid doing that keeps it less confusing
Coke it's an intermediate build file. we keep a lot of those around. 21:31
(src/pmc/string.c)
particle no reason to keep those
Infinoid make might try to rebuild if it discovers the intermediate file isn't there
particle except for debugging
but .c is a text file
pmichaud correct, if the intermediate isn't present, make will rebuild the target
particle only if the source is newer than the target 21:32
Infinoid isn't convinced, and goes off to test that.
Coke I need to head out. Regards.
pmichaud well, this would presume that the target lists the intermediate as a dependency 21:33
so if the intermediate is gone, then make treats it as being out of date and rebuilds it, then uses it to rebuild the target
try it with a .o file sometime -- remove the .o, and make will rebuild it and then rebuild the target
Infinoid just tested, GNU make rebuilds a toplevel target if an intermediate target it depends on is removed 21:35
pmichaud yes
this is exactly how make is supposed to work
(see my .o example)
Infinoid yeah
so... keep the intermediate around. if it's too confusing to have two PGE.pbc files in two directories with different attributes, call the intermediate miniPGE.pbc 21:36
pmichaud that doesn't work
because Perl6Grammar.pir expects to find PGE.pbc
Infinoid so we live with the confusion? or overwrite the original?
pmichaud if it's a major pain I'll rework the makefile so that there's only one PGE.pbc (in library) 21:37
Infinoid I doubt it matters, as long as library is where parrot looks first
pmichaud however, keep in mind that if PGE fails to build at some point (and it's often hard to notice because it's in the middle of the long root build), then you end up with an incomplete PGE.pbc and things start failing
chromatic I'm still not sure what the point of rejigging the makefile is at this particular moment. 21:38
pmichaud me neither
wknight8111 aegis.sourceforge.net/auug97.pdf
chromatic ... but I can imagine a couple of ways where it's possible.
wknight8111 link contains lots of good information about make
21:38 Limbic_Region joined
particle coke's aiming to make make -j make faster 21:38
Infinoid pmichaud: how would you feel about removing it upon failure, rather than removing it upon rebuild?
pmichaud hmmm? 21:39
Infinoid something along the lines of: $(CC) -o PGE.pbc <stuff> || (rm PGE.pbc; exit 1)
pmichaud if we can be certain that they remove on failure, sure
Infinoid if that can be made portable
heh. s/CC/PARROT/
pmichaud and make sure that Parrot's exit codes always make sense for -o 21:40
Infinoid which it probably should anyway
pmichaud it should, but I'm not sure that it does
Infinoid do we test that yet? sounds useful.
pmichaud thus I kept overlooking that the PGE build was failing
Infinoid understandable
in that case, make would overlook it too 21:41
pmichaud well, make was overlooking it, so I did
Infinoid all right. tonight I'll write a test
pmichaud I should also note that in the case of PGE, having -j isn't going to help much because it's a sequential process anyway 21:43
even if we list the dependencies "right"
there's no opportunity for parallel build in PGE
the Makefile is essentially a build script that is in the form of a Makefile, with one target. 21:44
increasing the number of targets isn't going to suddenly discover parallelism where it doesn't exist (in PGE's case)
Infinoid right, but that doesn't mean a single all-knowing make couldn't build non-PGE things at the same time 21:45
pmichaud ahhh, having sub-makefiles prevents -j from working? 21:46
I figured it just meant those sub-makefiles couldn't participate in being likewise ||
Infinoid having sub-makefiles makes it more difficult
one moment, let me dig up a svn rev number
ok, sorry, that wasn't as relevant as I had hoped 21:48
pmichaud also, I have trouble seeing what might build in parallel with PGE that can't already do so with the present Makefile
Infinoid the whole compilers/PGE directory is currently treated as a single big dependency, which isn't really that far from the truth 21:49
pmichaud exactly
and tge depends on pge
nqp depends on pct and pge
json depends on pge
Infinoid so... once pge is done, pct and tge could be built in parallel, and then nqp and json could be built in parallel? 21:50
pmichaud actually, I think that pct and pge can be in parallel, then tge and json and nqp 21:51
Infinoid currently, the compilers.dummy rule of the Makefile will build those 5 in serial.
pmichaud right
I'd change it to be
compilers: compilers.pge compilers.pct compilers.tge compilers.json compilers.nqp 21:52
then have separate $(MAKE) for each of those
compilers.pge: $(MAKE) compilers/pge
compilers.tge: compilers.pge \\n $(MAKE) compilers/tge
etc.
Infinoid yeah, something along those lines 21:53
also, I had to fix a faulty dependency in this area, a week or two ago. the dependencies implied libparrot could be built in parallel with pge, rather than libparrot being a dependency of pge
see the latter half of www.parrotvm.org/svn/parrot/revision?rev=26643
pmichaud oh, that looks like a total pain 21:54
because GEN_LIBRARY includes components that depend on PGE.... well, maybe not to build
it seems weird that we would build $(LIBRARY_DIR)/PGE/Util.pbc prior to building PGE itself :-) 21:55
Infinoid see, whenever I see something like that, my makefile-rewriting finger starts itching. 21:56
pmichaud a n y w a y
if you all want to refactor the makefiles, I have no problem with it as long as everything works
Infinoid that's a reasonable goal :)
chromatic PGE depends on libparrot though.
pmichaud building PGE also depends on Parrot/HLLCompiler.pbc
(for now)
I do have a problem with increasing the options or number of source code files that are needed to build PGE 21:58
i.e., if I have to maintain separate Perl6Grammar.pir files or various option switches, that seems like a Net Lose.
I could also eliminate the 2-stage PGE build by simply hand-coding the builtins.pg file as PIR rules 21:59
(there's only one rule in there at the moment)
but if we ever decide we want a library of standard rules to be part of PGE and that those are coded using regexes as source, we'd need a multi-stage build again 22:00
Infinoid if we have to move or copy stuff around to maintain atomicity, it should still all come from one source file... anything else is a DRY fail.
pmichaud I think that adding options that are only used for building is also some sort of fail
chromatic Definitely agreed. 22:01
Infinoid starts adding things to t/run/exit.t
pmichaud afk, dinner 22:02
Infinoid thanks for the discussion, pm
dalek r26857 | bernhard++ | trunk: 22:06
: Regenerate MANIFEST.SKIP
diff: www.parrotvm.org/svn/parrot/revision?rev=26857
22:08 barney joined
dalek r26858 | bernhard++ | trunk: 22:15
: #52556: [PATCH] Eclectus: simplify PAST generation a bit
: Courtesy of Andreas Rottmann
diff: www.parrotvm.org/svn/parrot/revision?rev=26858
rotty hey! :)
hello barney 22:16
barney Hi, just coming home from Frankfurt.pm meeting 22:17
rotty barney: just as an aside: please apply my patches verbatim or reject them (I'm managing them with StGit) 22:18
22:19 kid51 joined 22:20 skids joined
jonathan yawns after a long day's work negotiating 22:22
Four hour flight and airport boringness tomorrow. May get some more Rakudo hacking in. 22:23
barney rotty: Yes, applying the patches is easier when they are in form as mentioned in submissions.pod
skids jonathan: suggestion, if it's easy -- An error message of "Type blah refuses to be assigned type blah " maybe with a "due to where statement" tacked on for refinements -- would be much more useful than "Type check failed". 22:25
rotty barney: what did I do wrong? I did have a look at submissions.pod... 22:26
Infinoid git patches need to be applied with patch -p1, not patch -p0
barney the usual 'patch' does not know about the 'a' and 'b' dirs 22:27
rotty yes, I did not deem this important
Infinoid its a git-ism. I guess I'm used to it.
rotty (as you can just use -p1) 22:28
barney I just tried that. perhaps I mistyped
Infinoid it should work... -p1 tells it to strip the a/ and b/ 22:29
jonathan skids: Completely agree, the first two parts are maybe easy, though for anonymous refinement types it's a tad harder.
But yeah, needs better error message. 22:30
I'll see what I can do.
Thanks for the feedback. :-)
22:30 iblechbot joined
skids thanks for the types ;-) 22:30
particle jonathan: you can use "<anon>" for anonymous types until we have something better 22:31
dalek r26859 | bernhard++ | trunk: 22:32
: #52588: [PATCH] Eclectus: refactor Perl test wrappers
: Courtesy of Andreas Rottmann.
diff: www.parrotvm.org/svn/parrot/revision?rev=26859
jonathan particle: Sure, good idea. 22:33
barney rotty: yes 'patch -p1' works fine 22:35
rotty :-)
particle that'd be a nice detail to document somewhere
jonathan particle: actions.pm is getting kinda...big. What would you think to trying to refactor some of the larger actions a bit to use various subs, and putting those into a separate .pm file or files? It's just that it takes a little while to compile.
By "what would you think to", I'm not asking you to do it - just asking what you think of the idea. :-) 22:36
particle jonathan: i'm not against the idea, as long as they're well-factored
jonathan Sure
Well, actions.pm is close to hitting the minute mark to compile on this laptop.
And yes, I know that really means I need a new laptop...
dalek r26860 | bernhard++ | trunk:
: #52592: [PATCH] Eclectus: Replace brackets with parens
: Courtesy of Andreas Rottmann.
diff: www.parrotvm.org/svn/parrot/revision?rev=26860
rotty barney: what reason do you want to switch to generating NQP instead of PAST for? 22:38
particle heads out for a bike ride &
barney I want to keep the PAST, just change the PAST-generation code from PIR to NQP. 22:39
Just because the syntax is nicer, not so many temporary variables 22:40
rotty ah, I see
barney The PAST generating code can be one big nested constructor 22:41
rotty btw, what do you think about using riaxpander to do the macro expansion stuff for us?
riaxpander is mumble.net/~campbell/darcs/riaxpander/ 22:42
s/is/is at/
btw, there is a good overview of Scheme macro systems at lists.gnu.org/archive/html/chicken-...00013.html 22:43
shorten rotty's url is at xrl.us/bi4y6
22:47 schmalbe joined
schmalbe rotty: I'll take a look at it tomorrow. 22:47
rotty barney: are you ok with a subdirectory for each Scheme we support for bootstrapping, or should that be layed out differently?
schmalbe: ok 22:48
schmalbe subdirs seem sane. Have you checked with Ikarus?
rotty schmalbe: Ikarus doesn't run on my main machine (it needs SSE2 or something) 22:49
(so, no)
dalek r26861 | bernhard++ | trunk: 22:51
: #52600: [PATCH] Eclectus: now works also with Guile
: Courtesy of Andreas Rottmann.
diff: www.parrotvm.org/svn/parrot/revision?rev=26861
rotty schmalbe: we should probably select a few (maybe 3) implementations for bootstrapping, to keep the overhead low 22:55
dalek r26862 | bernhard++ | trunk:
: [Eclectus]
: Set SVN properties for newly added files.
diff: www.parrotvm.org/svn/parrot/revision?rev=26862
rotty I'm very much for dumping Petite chez, its command-line interface is *very* limited 22:56
schmalbe Do you recommend Guile ? 22:58
rotty schmalbe: Guile has some problems with macros and modules; Gauche is better in that respect
dalek r26863 | bernhard++ | trunk:
: Give credit to Andreas Rottmann.
diff: www.parrotvm.org/svn/parrot/revision?rev=26863
rotty (I'm not sure this matters for our purposes, but if we want to use riaxpander, it might) 22:59
schmalbe deprecates Petite Chez Scheme for Eclectus
rotty dalek: are you aware of the harness "-le" problem? 23:00
oh, that should have been schmalbe: ...
schmalbe rotty: Are you on IRC tomorrow? 23:01
rotty the current eclectus codebase is not very much suited for compilers because of the way the test harness works, btw
schmalbe: yes
schmalbe Can we do some planning this evening? (Barney realizes it's past midnight) 23:03
rotty schmalbe: sure
schmalbe calls it a day 23:04
Cool
rotty :-)
23:10 TonyC joined 23:20 nopaste joined 23:21 rdice joined
Infinoid kid51: (re: Perl::Critic disappearing) you could always try the brute force method 23:43
nopaste "Infinoid" at 96.238.213.50 pasted "make perlcritic.t dump @INC to stderr" (12 lines) at nopaste.snit.ch/12660
Infinoid if there's anything weird like the search path being truncated, or another rev of perl being invoked, it'll show up there. 23:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!