Parrot 0.9.1 Released | parrot.org/ | 458 RTs left!
Set by moderator on 18 February 2009.
dalek rrot: r36898 | whiteknight++ | failed to fetch changeset:
[Book] Some miscellaneous fixes to chapter 5, courtesy hexcoder++
 00:03
00:07 Ademan_ joined 00:08 allison joined 00:09 AndyA joined 00:42 leto_ joined 00:48 kid51 joined
dalek rrot: r36899 | chromatic++ | trunk/src/pmc/integer.pmc:
[PMC] Explicitly initialized initial value for Integer PMC's instantiate()

but also because that's what the documentation says should happen.		 01:37
rrot: r36900 | chromatic++ | trunk/t/pmc/pmc.t:
[t] Removed a skipped test for the non-existent instantiate opcode.
 01:41
rrot: r36901 | chromatic++ | trunk/src/pmc/bignum.pmc:
[PMC] Fixed some "used unitialized" compiler warnings that would have caused

almost caused me to remove them.		 01:45
02:02 gravity joined 02:08 leto_ joined
cotto What is a typedef doing inside a function in nci.pmc? 02:13
There's two of them. 02:14
02:18 leto_ joined
Infinoid cotto: Why not? They aren't public. 02:19
Bigint and bignum declare their own data structures too. Seems appropriate.
Without the typedefs, those nci function pointer types would be a pain to deal with... 02:20
cotto It seems a hackish to have it sitting there in the middle of a function rather than at the beginning of the file.
I'm glad they're somewhere. I'm just question the location. 02:21
Infinoid Eh. They're declared where they're used
If they were used in more than one place, I'd feel more strongly about it
cotto That may change, depending on how I feel when I fix the segfault du jour.
Infinoid Now, if they were #defines... 02:22
dalek rrot: r36902 | chromatic++ | trunk/docs/pdds/pdd22_io.pod:
[PDD] Updated PIR in examples to work with current PIR specification.
 02:28
kudo: 0691afa | (Patrick R. Michaud)++ | docs/spectest-progress.csv:
More partial spectest-progress.csv update.
 02:41
shorten dalek's url is at xrl.us/begvjr
rg msg NotFound for those of us without jit, you need to add vJ to src/call_list.txt or the latest embed.t fails. 03:01
purl Message for notfound stored.
03:48 janus joined 04:13 magnachef joined 04:21 rurban_ joined 04:31 Tene_ joined 04:44 eternaleye joined 04:56 leto_ joined 05:00 eternaleye joined 05:06 eternaleye_ joined
dalek kudo: 5423d30 | (Patrick R. Michaud)++ | docs/spectest-progress.csv:
spectest-progress.csv update: 6843 passing, 1 failing
 05:06
shorten dalek's url is at xrl.us/begvxb
05:07 leto_ joined 05:32 leto_ joined 05:39 masak joined 05:47 bacek joined 05:55 MariachiElf joined 06:00 Andy joined
dalek rk: 4c4df21 | (Chris Dolan)++ | Makefile:
Better Makefile dependency map
 06:01
shorten dalek's url is at xrl.us/begvz6
dalek rk: dc4fd26 | (Chris Dolan)++ | (3 files):
Support namespacing with packages and inner classes
shorten dalek's url is at xrl.us/begvz8
06:50 Theory joined
masak chromatic++ # writes so well that people listen 07:18
dalek rrot: r36903 | chromatic++ | trunk/src/packfile.c:
[src] Tidied file and improved documentation; no functional changes.
 07:23
07:28 uniejo joined
dalek kudo: ab75eb1 | (Moritz Lenz)++ | (3 files):
implement Hash.reverse
 08:17
shorten dalek's url is at xrl.us/begv7u
dalek kudo: 344b93a | (Moritz Lenz)++ | src/setting/ (5 files):
[setting] add vim modeline to *.pm
shorten dalek's url is at xrl.us/begv7w
dalek kudo: f7c0c0b | (Moritz Lenz)++ | (3 files):
move Str.reverse to setting/
shorten dalek's url is at xrl.us/begv7y
dalek kudo: dcbbde3 | (Moritz Lenz)++ | src/classes/Str.pir:
remove a TODO comment that's implemented in any-str.pir already
shorten dalek's url is at xrl.us/begv72
dalek kudo: f9beed2 | (Moritz Lenz)++ | t/spectest.data:
add a newly fudged test to t/spectest.data
shorten dalek's url is at xrl.us/begv74
dalek kudo: 9377288 | (Moritz Lenz)++ | src/classes/Str.pir:
remove a TODO comment; there's no Str.pos anymore
shorten dalek's url is at xrl.us/begv76
dalek kudo: 529396a | (Moritz Lenz)++ | CREDITS:
[CREDITS] join the two entries for Ovid++
shorten dalek's url is at xrl.us/begv78
dalek rrot: r36904 | allison++ | trunk/src/library.c:
[install] Try standard search paths ('dynext/', etc) from current

without installing into languages/lang/dynext/.		 08:26
moritz Infinoid: dalek doesn't spread its rakudo updates on #perl6 08:38
dalek kudo: 6c7a7a9 | (Moritz Lenz)++ | t/00-parrot/05-var-array.t:
Fixe test as reported in RT #63346
 08:41
shorten dalek's url is at xrl.us/begv87
dalek kudo: 2e438ab | (Moritz Lenz)++ | t/00-parrot/05-var-array.t:
Use == for numeric comparison in 05-var-array.t
shorten dalek's url is at xrl.us/begv89
moritz Infinoid: it worked for 6c7a7a9, but it dropped for example 529396a
TiMBuS it flooded out? 08:44
oh, i get what you mean
08:47 iblechbot joined
dalek rrot: r36905 | rurban++ | trunk/PBC_COMPAT:
[cage] Added comment about the new TODO ticket TT #361
 09:17
09:33 elmex joined 09:41 elmex joined
dalek rrot: r36906 | cotto++ | trunk/src/pmc/string.pmc:
[PMC] make the String PMC more correct, although there's still a bug somewhere
 09:49
cotto It might be time to go to bed. 09:57
dalek rrot: r36907 | cotto++ | trunk/src/pmc/string.pmc:
[PMC] *now* it's less broken
 10:01
10:02 elmex joined 10:03 elmex joined 10:13 elmex joined 10:24 elmex joined 10:28 elmex joined 10:29 bacek joined 10:47 gaz joined 12:19 elmex joined 12:21 rurban_ joined 12:33 rg1 joined 12:42 elmex_ joined 14:06 davidfetter joined
Nom ooo... is NQP low enough to write a language independent module for parrot ? 14:15
ie. something which might talk to a DB
actually, bad example... a db abstraction layer 14:16
moritz I think so, yes
I mean it's just compiled down to PIR 14:17
Coke moritz: that doesn't necessarily mean that if you can do it in PIR you can do it in NQP, neh?
moritz Coke: right 14:18
Coke I'd be willing to hazard that you can do most of the logic in NQP, but you might have to write some embedded PIR in a few places.
Nom That sounds like a plan to me :)
moritz but NQP doesn't do fancy stuff that hinders interaction with other HLLs
(though I agree that that's not what I said earlier)
Nom hmmm... any specific gotchas i should watch out for in the interaction front? 14:19
The main thing is I want to be able to use roles and classes
moritz rakudo: eval('VISIBLE "OH HAI"', :lang<lolcode>) 14:20
polyglotbot OUTPUT[OH HAI␤]
TiMBuS that is cool 14:21
moritz makes way for somebody more qualified to answer Nom's questions
TiMBuS: Tene++ hacked that in shortly before christmas
TiMBuS now all we need is a language to be fully implemented on parrot :( 14:22
Nom Perl6 is close enough for real world use... it just needs a *lot* of libs built for it 14:23
I'm yet to be convinced that performance is a problem, because every example i've seen so far is basically CGI
TiMBuS well its got a few bugs in it.. 14:25
Nom Sure ... but there's bugs in everything ... how often you come accross them is the important question :) 14:26
moritz aye
Coke (performance not a problem) ... I can't speak for rakudo, but partcl is terribly slow. 14:28
moritz rakudo takes 15min to run 7k tests on two cores
that's not all that good, but not exactly terrible either 14:29
TiMBuS the little language i threw in parrot is pretty terrible compared to its C counterpart =/
moritz I'm sure it is
but think of writing something as complex as rakudo entirely in C 14:30
moritz shudders
PerlJam moritz: you know there are such efforts afoot? (see #perl6)
moritz PerlJam: yes - but that's only the backend 14:31
PerlJam: smop doesn't have a C-based parser
Nom nice... looks like our transit is screwed up... can't reach a stack of websites atm :( 14:32
PerlJam Coke: If you'd pave the way with profiling tools to speed up partcl ... ;-)
moritz: okay. I guess I knew you knew, so what you said sounded odd to me. 14:33
14:36 gryphon joined
Coke PerlJam: if you'd teach me C... 14:41
If that were something that were easy for me to do, I'd have done it.
14:42 gaz joined
Nom aww... nqp doesn't support roles 14:44
or multi method... well there goes that idea 14:45
14:45 uniejo_ joined
Coke you could always try rakudo if you want something perl6-like. 14:48
Nom does .pir even support polymorphism ?
moritz parrot's object system supports polymorphism 14:51
Infinoid moritz: hum. Maybe freenode has stricter flood control queue limits? 14:54
moritz Infinoid: don't think so - it didn't complain about a huge svn commit yesterday either
Infinoid: and dalek also swallowed the first of that series of commits 14:55
Infinoid the svn commit was done by a different bot, right?
reported, that is
maybe the svn bot is better at temporally spacing out its messages than dalek is 14:56
(that's the best theory I have at the moment)
moritz it just uses Bot::BasicBot
Infinoid dalek is botnix, and I have gotten dropped message warnings from magnet before 14:57
one moment, I'll check its log
2009-02-20 09:17:11 freenode >> PRIVMSG #perl6 :rakudo: review: github.co 15:03
m/rakudo/rakudo/commit/529396ad10939eeb1bd2be8301b884d2c44225ac
2009-02-20 09:17:11 rakudo: output_item: output rev 529396a
2009-02-20 09:17:11 freenode << ERROR :Closing Link: feather.perl6.nl (Excess Fl
ood)
If I'm poked and prodded enough, I'll write a better IRC bot 15:04
(there are never enough irc bots) 15:05
Another thing the github parser doesn't handle very well currently is out-of-order commits. It only emits commits greater than the previously seen datestamp, which drops the older stuff when you're doing a branch merge
I think it needs an "already seen rev" hash 15:06
rurban has the pmc c-interface a pmc_can method? has this pmc this method?
Coke rurban: Parrot_find_method_* ? 15:09
rurban Can I use this the search for a class freeze or freeze_size method? 15:10
Coke if it is a method, I don't see why not. 15:11
rurban I see the "does" interface, which answers acceptable types
Coke does is merely informative.
dalek kudo: f23eda2 | (Moritz Lenz)++ | build/Makefile.in:
[build] remove perl6_s1.pbc during 'make clean'
shorten dalek's url is at xrl.us/begwvi
Coke any pmc can claim it does anything.
(and lie)
rurban Good, I'll implement TT#362 freeze_size then 15:12
I didn't know about this simple method when I wrote this ticket.
Nom So PIR has classes... does it have abstract classes or interfaces ? 15:15
Coke nom: I'd recommend reading through the PDD.
docs.parrot.org/parrot/0.9.1/html/d...s.pod.html 15:16
shorten Coke's url is at xrl.us/begwv5
15:16 Andy joined 15:19 AndyA joined
rurban docs/pmc.pod needs a lot more info 15:31
15:47 gaz joined
rurban seen Coke 15:50
purl Coke was last seen on #parrot 34 minutes and 1 seconds ago, saying: docs.parrot.org/parrot/0.9.1/html/d...s.pod.html
rurban We are not allowed to change PBC_COMPAT for 6 months starting with 1.0 ??? 15:51
Why not get rid of that ridicolous limitation instead?
(which is make pbc more compatible proof)
Coke rurban: That's a question I have. 15:55
Nom hmm i can't see any examples of a :multi using an int array ... is that even possible to define at :multi? :/
Coke I don't see how we can really guarantee any kind of bytecode compatability in over the life of a six month milestone without some serious limitations on what we can change.
Looks like the long term roadmap addresses this at 2.0
but, basically, I /think/ it means: no opcode changes, no core PMC changes during that timeframe. 15:56
Nom ah i see, never mind... just found the intarray classes
rurban why not work around it? introducing proxies for unknown (new) pmcs, and do not deprecate pmc methods anymore
or provide an interface for the reader to fixup old methods to a new. 15:57
Coke rurban: I'm just telling you problems I see. I'm not saying we /have/ to do it that way.
but we collectively have ignored bytecode compatibility for some time now; I don't see it getting fixed before 1.0
Having a plan on how to address it is definitely a good idea, though.
I'd recommend creating a wiki page and linking the bytecode stuff on the long term roadmap to it. 15:58
and then braining dumping your ideas there.
*braindumping
rurban I've implemented now UUID's to gracefully error on older pbc's.
but this is not satisfactory reading the older design goals... 15:59
wiki or mailing list?
I'll start with the mailing list and put it over to the wiki then. 16:00
I see it as a goal for 19MAY2009, 1.2 16:01
Which is fine because starting on monday I'm three weeks away. I cannot do 64-bit stuff in Germany 16:02
rg rurban: i was trying to build a real sparcv9 (64bit solaris) parrot, but i'm getting a bus error (invalid address alignment) in PF_fetch_integer at line 1079 in file "pf_items.c". 16:08
is that a known bug or a new one?
rurban do you have a backtrace? the release or latest svn? I fixed an error after the release there 16:09
rg this is r36884. it should be almost current. let me check. 16:10
rurban I had not chance to test it and it is very likely that I missed a converter #ifdef 16:11
16:11 Tene joined
nopaste "rg" at 93.104.104.207 pasted "solaris 64bit backtrace" (15 lines) at nopaste.snit.ch/15681 16:13
rg don't get me wrong, i'm not complaining. but given your efforts to get it right on all platforms i'm trying to test it all ;) 16:14
rurban hmm, the converter definition is missing: pf->fetch_iv. strange I didn#t touch these, only the float converters
Is that a private machine or company? can I get access to it? 16:15
And andy dougfherty didn't complain about this.
rg this is a private machine that i can't hand out access to. however i can help you debug
NotFound src/packfile.c 3485 ---> Looks like a typo 16:16
rurban ok, simple. just #define TRACE_PACKFILE in packfile.h to 2
and rerun it
rg this is not a default build. i'm trying very hard to get a pure 64bit binary.
rurban you need better hints?
--ccflags='-m64' --ldflags='-m64' --linkflags='-m64' 16:17
this helped me.
perl -V:ccflags should also be added to ccflags 16:18
rg yes, plus i have to override the compiler, because my perl was built with gcc
i'm using --cc=cc --cxx=CC --ld=cc --link=cc --ccflags='-m64 -g' --linkflags='-m64' --ldflags='-m64' 16:19
rurban and gcc has no 64 bit libs?
NotFound I never remember how to read purl msgs 16:20
rg last time i tried it was getting in trouble mixing 32bit libgcc with 64bit stuff. also it will run into the atan2 bug
rurban NotFound:src/packfile.c 3485 typo where? if (PackFile_map_segments(interp, dir, find_fixup_iter, (void *) ep));
NotFound rurban: yes, the identation does not match the ;
rg do i need realclean or can i just rebuild?
rurban fixing atan2 is simple. -xlibmieee 16:21
16:21 Theory joined
rurban justmake 16:21
ah yes! I already fixed that privately. thansk for reminding me. NotFound++
rg i've read -xlibmieee doesn't work with gcc
NotFound rurban: thank also gcc warnings 16:22
rurban cygwin has less gcc -c warnings but better ld warnings than linux.
I really have to look into my hints to catch more warnings 16:23
16:23 gaz joined
PerlJam pmichaud is in transit today isn't he? 16:23
rg notfound: doesn't purl just tell you the messages? did you get mine now? 16:24
NotFound It tells that I have msgs waiting
dalek rrot: r36908 | rurban++ | trunk/src/packfile.c:
[core] fix typo: additional ; at the end.
 16:25
NotFound I've seen yours by PgUp ;)
dalek rrot: r36909 | NotFound++ | trunk/src/packfile.c:
[cage] avoid a warning when TRACE_PRINTF_VAL expands to nothing
 16:29
Coke is it currently possible to even develop a language outside of a build dir? 16:30
rurban NotFound++ :)
16:30 gaz joined
NotFound Coke: yes, pirric ;) 16:32
rurban rg: how is it going?
rg this thing is taking ages to compile core_ops_cg.c
rurban what is the cmdline? the embed test?
200MHz CPU :)
NotFound I'm building now with --jitcapable=0 to fix it 16:33
Coke NotFound: I don't see pirric on trac.parrot.org/parrot/wiki/Languages, but your smily makes me think I'm missing something.
rg 440MHz ;)
rurban almost. see, I knew it.
Coke NotFound: ah. from examples/ ; yah, that doesn't really help. 16:34
16:34 AndyA joined
NotFound Coke: pirric is in examples/pir, and does not use language infrastructure 16:34
rurban it would be really great if you could create t/native_pbc/integer_6.pbc and number_6.pbc on this sparc. tools/dev/mk_native_pbc --noconf is enough 16:35
rg sure
once we get parrot working ;)
rurban because then I could continue debugging on one side even when I'm in germany 16:36
rg finally past the ops. should be done soon then ;) 16:41
rurban whow!
16:41 Whiteknight joined
rurban A tip. TRACE_PACKFILE can always be 1. it only prints out debug info when --debug cmdline args are given 16:43
But it bloats the lib a lot.
rg i'm not sure i want to get into the details of the pbc files ;) 16:44
Coke is there an easy way to say 'compile this arbitrary c file with the same args you'd compile a parrot file with?' ?
rurban This is bigendian 64bit, completely untested minefield.
Coke: make and paste the xx.c stuff 16:45
Coke rurban: blah. ok.
rurban TEST_EXEC=myexample.c make exec
rg ok, done. no difference 16:46
what extra commandline do i need to get the trace output?
rurban where did it fail exactly? which test or cmdline?
rg it's running ./parrot -o runtime/parrot/include/parrotlib.pbc runtime/parrot/library/parrotlib.pir
rurban so that's when making the very first pbc... 16:48
It's trying to read an integer from the frozen config.fmpc 16:49
dalek rrot: r36910 | NotFound++ | trunk/config/gen/call_list/misc.in:
[nci] add signature to make embed.t work without jittted nci
 16:50
rurban rg: do you have gdb or only dbx there?
rg dbx
rurban oh no. but no problem, just more typing 16:51
rg i could build gdb (i hope ;))
rurban I'm first trying it out by myself. dbx --args ./parrot -o runtime/parrot/include/parrotlib.pbc runtime/parrot/library/parrotlib.pir
rg i'm much more comfortable with gdb aswell 16:52
rurban this will last ages. but it's much better, yes
start
break shift_opcode_integer
Coke NotFound: I think you may have just fixed trac.parrot.org/parrot/ticket/363 16:53
NotFound Coke: the error message looks like that it was that thing, yes. 16:55
Coke is rebuilding
rurban sorry. --args is unsupported
rg that worked just fine like with gdb 16:56
dbx parrot; run -o ... 16:57
rurban yes, but it neesds ages to load up all the so's
stop in shift_opcode_integer 16:59
rg ok, i tried installing a gdb package but that didn't work :(
rurban That's the magix cmd
"stop in shift_opcode_integer"
rg i guess we'll have to stick with dbx for now
t@1 (l@1) stopped in shift_opcode_integer at line 874 in file "pmc_freeze.c" 17:01
17:01 AndyA joined
rurban print *pf->fetch_iv 17:01
0 or not? 17:02
rg dbx: "pf" is not defined in the scope `libparrot.so`pmc_freeze.c`shift_opcode_integer`
rurban oops, sorry: print *io->pf->fetch_iv 17:03
rg (dbx) print io->pf->fetch_iv
io->pf->fetch_iv = (nil)
rurban print io->pf
rg that one's pretty big 17:04
rurban good, so is defined. anything very suspicious there?
nopaste "rg" at 93.104.104.207 pasted "print *io->pf" (90 lines) at nopaste.snit.ch/15682 17:05
rg well i find fetch_iv being nil suspicious, so maybe you check for yourself ;) 17:06
rurban fetch_iv nil is okay, defined to NULL
so no conversion should happen, this is the check we are failing.
I'm just trying on my i64 solaris 10 box... 17:07
NotFound Coke: to build the embed tests you need to add the output of parrot_config ld 17:08
And maybe: parrot_config libparrot_ldflags
rurban on gdb I have fetch_iv = 0, not nil, nil is better though it smells lispy
Ah, I have an ideas. maybe pf->fetch_iv == NULL is failing for you 17:09
rg no, look in PF_fetch_integer
it's tested right there
and the return is failing me
something the stream is pointing to is badly aligned 17:10
rurban step 3x
nopaste "NotFound" at 213.96.228.50 pasted "Example Makefile to build embedding test programs" (12 lines) at nopaste.snit.ch/15683
rg only 3?
or 3x after entering PF_fetch_integer? 17:11
rurban no, to get into it.
NotFound "lorito" is little parrot in spanish ;)
rurban print *(*stream) => 35
rg (dbx) print *(*stream) 17:12
**stream = 4
rurban that's what I get
rg uh this is strange. let my try that again 17:14
rurban So we just a broken stream. somewhere, not the first integer. inspecting after the failure would help then 17:15
rg right after the failure it's 35 17:16
it seems to process the ++
rurban what if you run into the error? 17:18
status
purl Since Fri Jan 16 04:09:57 2009, there have been 10404 modifications and 6214 questions. I have been awake for 35 days, 13 hours, 8 minutes, 12 seconds this session, and currently reference 752216 factoids. Addressing is in optional mode.
rurban delete 2
cont
rg i just stepped on 17:19
nopaste "rg" at 93.104.104.207 pasted "stepping on" (19 lines) at nopaste.snit.ch/15684 17:20
rurban 0xc!
it should be even 17:21
rg 12 is even
rurban right
rg but it's not 0x7 aligned 17:22
how that's a problem, i don't know.
after all, i can print it 17:23
rurban I propose to try the fix we just found in src/packfile.c. r36908
rg sure, if you think that's related
rurban this corrupted PackFile_find_fixup_entry 17:24
I'm not sure. Andy didn't report any else on sparc lately, only my double breakage. 17:25
rg a 32bit version compiled just fine
rurban hmm, smells bad.
rg let me rebuild and i'll tell you in like 20-30 mins 17:26
rurban my 64bit le works fine, just be seems to be broken.
be = big-endian
rg i suspect the sparc cpu may be a lot more strict about alignment. i thought you also mentioned something to that effect before. 17:27
rurban I have an idea...
yes, very strict
I know that the alignment macro didn't work fine on 64-bit 17:29
I only aligns to 2 and not 8 or 16 17:30
ALIGN_16 ROUND_16 / sizeof (opcode_t) : 16/8 = 2 17:32
I want to get rid of "/sizeof (opcode_t)"
That's the big plan at least 17:33
My finding was also that the reader should align to the foreign pbc ptrsize, not to the native ptrsize. but since we have strict CPU's we should take more care and align to at least 8 on 64bit 17:36
17:39 pjcj joined
rurban These are a LOT of changes. We did not use ALIGN or ROUND_UP / ROUND_DOWN macros as in the linux kernel. 17:42
rg i really haven't looked at the bytecode format at all, so i can't comment. 17:43
rurban It's the writers and the reader to fix. 17:44
Writers are a lot, reader just a few
I'll try to get access to such a machine to verify that assumption
As I see with Andy Dougherty's reports is that he just uses 32bit on his sparc. 17:45
rg that's the default. sun still thinks people might want to share binaries with older sparc hardware. 17:46
(and i wouldn't be surprised if some still do) 17:47
rurban A big probklem is that the architrerue is not reoported correctly. I changed i86pc to amd when 64int is in archname. but we really must check the compilers ptrsize because we usually override it with -m64 17:49
"to amd64 when"
"0.9.1, Perl 5.8.4 i86pc-solaris-64int, amd64, cc, solaris" is just solaris 32-bit 17:50
I have not found a 64bit big-endian report so far on smolder... 17:51
rg i can set up smolder reports once we have this fixed.
rurban I can prepare a test patch for you to try out. It will be a big one though. 17:53
rg what bugs me a bit about smolder is that the summary doesn't show you if it's a recent checkout.
rurban yep, I created a ticket for that. we need the config hash and all local modifications.
or just myconfig would be fine also, but also $(svn status | grep "M ") 17:54
the cputype I would get with the byteorder then 17:55
rg: can you do grep ptr_alignment config_lib.pasm
rg set P0["ptr_alignment"], "8" 17:56
rurban that's it! our align must use at least that!
That's worth a blocking ticket.
my intel solaris has just set P0["ptr_alignment"], "1"
rg is that a probed value?
rurban yes
config/auto/alignptrs/test_c.in 17:57
do you want to create that ticket? 17:58
rg i would have no idea what to write, sorry
ok, compile is done. problem persists (no difference in values, either) :( 18:02
i wonder why the debugger can print *(*stream) if it's not correctly aligned. 18:03
rurban I'm pretty sure that ther must be a simple compiler switch to relax that (andc make code much slower) 18:04
cc -flags shows nothing? 18:05
rg -xmemalign[=<a><b>] Controls memory alignment, <a>={1|2|4|8|16}, b={f|i|s}. 18:06
not sure what it does
rurban ha, simple as that!
-xmemalign=1i 18:08
i is for int, s for string and f for float I guess
I dont have that on the intel compiler
rg the manpage says its sparc only 18:09
rurban hopefully it does accept "-xmemalign=1" only (for all three types)
rg no, i think you have to give the option 3 times
and ... i would be wrong 18:10
rurban you can use 2 because we align to 2 :)
trac.parrot.org/parrot/ticket/364 a blocker 18:11
rg Accepted values for b are: i Interpret access and continue execution. s Raise signal SIGBUS. f For variants of -xarch=v9 only. [reduced i]
rurban Oh my. 18:12
so i looks fine
2i exactly
rg i think we want 2s then. 18:14
rurban really? no raise, we already have that. but maybe its "raise if violated"
rg i think it's raise if violated 18:15
rurban we can at least try
rg The default for all v9 architectures is -xmemalign=8s.
rurban ... 2o min. you can disable some costly optimizations maybe
rg can i compile without cg cores? 18:16
rurban --cgoto=0
rg just found that. i guess i'll give it a try 18:17
rurban I also saw just--m=32 (for 64bit complers) but we really need the other way -m=64 and this does not work 18:18
rg i think that may work. after configure i now have set P0["ptr_alignment"], "2" 18:20
rurban great 18:21
Coke docs/project doesn't seem to be generated by 'make html' 18:24
rurban did you use 2s or 2i? 18:27
rg i used 2s
rurban I'll note that in the ticket then TT #364 18:28
18:29 barney joined 18:30 braceta joined
rg ah the difference between i and s (with values < 8) seems to be that for i the error is trapped and emulated, whereas code is generated that allowes all other access without any trap. 18:31
oh it says i may need to give the option to the linker aswell 18:32
s/may// 18:33
rurban I'm coding it now away.
rg ?
rurban I write a patch to fix that once and forever.
rg misaligned memory access? 18:34
rurban There's only a 0 allowed as last hexnumber in all addresses from now on.
./pbc_dump -h -e config.pbc 18:35
pre-ALIGN_16: offset=0xfffffe64 src=0x7ffa0000 cursor=0x7ffa0670
ALIGN_16: offset=0xfffffe64 src=0x7ffa0000 cursor=0x7ffa0670
pre-ALIGN_16: offset=0xffffff5f src=0x7ffa0000 cursor=0x7ffa0284
ALIGN_16: offset=0xffffff5c src=0x7ffa0000 cursor=0x7ffa0290
and so on...
rg hmm funny. didn't fail the link *and* parrot works :) 18:36
rurban all those addresses must be aligned, that's the goal
Coke (docs/project) ah. it's just not linked to from anywhere obvious. 18:38
rg yay, compile finished. let's make test 18:39
rurban now just jit is missing :)
rg yeah right. who's going to write sparc jit?
ouch. why is it trying to run a gcc test? 18:40
uh more failures 18:41
Coke can we have osx/86 jit first? please? =-) 18:44
Whiteknight Maybe by the time JIT becomes a mature system, Sparc won't be a target platform anymore
rurban amd64 is first!!!! 18:45
rg would like to see amd64 jit (but not write it ;))
rurban I've already started but got distraced
Whiteknight We need to get the damn x86 JIT working properly first, and I personally want to get AMD64 working too since that's what I have
rurban distracted
Whiteknight and I would gladly do an osx/x86 too, once those are done
rurban I got wonderful crashes with fixing the rounding problem set_i_n, so I have to sit down and write proper gdb macros first 18:46
rg osx/x86 can't be that hard since linux/x86 is already working. but then you'd have to have osx first ;)
Infinoid "We should support JIT on every platform conceivable, as long as it's mine."
rurban IA64 is also important, fastcall!! 18:47
purl okay, rurban.
rg infinoid: you trying to get into the famous quotes list? ;)
18:47 geof joined
Infinoid No, I was just trying to sum up what I'm hearing 18:47
purl well, hearing is not necessary to learn.
Whiteknight If I had solid access to other systems, and some serious time on my hands, I would definitely do more JIT work
Infinoid And along those lines, I want amd64 jit too :)
rurban those new relative MR stuff (offset based) gave me a hard time 18:48
Whiteknight And volunteers work on the projects they want to work on the most. Whichever platform has the most available JIT-interested coders will get the most JIT work
rurban I think I already put my patches into the tickets. #352 and #353 18:49
And I accidently overwrote most of my already written .gdbinit macros for xREG and CONST access 18:50
18:52 davidfetter joined
Whiteknight I really need to get better with GDB, I can pick through it but I'm no wizard or anything 18:52
rurban Ok, TT#359 UUID is finished now. TT #364 ptr_alignment next 18:53
Coke (osx/86 easy since we have x86) - that's what we thought 4 years ago. =-) 18:57
rurban is there really a difference? 18:58
Coke apparently.
rurban that's a plain normal bsd, isn#t it?
Coke ... no
it's darwin.
i'll let chromatic rant about how it's not the same thing. =-)
rurban darwin/ppc ?
Coke no.
darwin/x86
18:58 timbunce joined
rurban OSX 10? 18:58
Coke yes. 18:59
rurban I thought that's a normal bsd, with a good IDE library
cocoa or such
Coke not exactly.
rt.perl.org/rt3/Ticket/Display.html?id=40804 19:00
rg oh opendarwin shut down more that 2 years ago. i didn't notice
so i guess there's no easy way to get something like osx in an emulator
rurban I see. So when I properly align all the addresses to16 it will magically work :) 19:01
Coke rurban: one can hope.
rurban because now it's aligned to 4 on x86 and 2 on 64bit
this cannot work then
but we also have to check ptr_alignment, not only stack_alignment 19:02
our memory on the heap apparently IS 16 aligned, just the bytecode not 19:05
Coke I hate it when mom & dad fight. 19:07
Whiteknight it's more healthy that way: You don't want everybody in the project to be in lockstep with each other 19:24
rurban alignment refactor finished, testing....
Whiteknight and you definitely want to make sure that opposing viewpoints are heard and accounted for
rurban sure!
I think it was a simple coding error, someone just added "/sizeof(opcode_t)" to all align code 19:25
chromatic apparently 19:27
leo got it right
rg tests done. 6 failures. 19:33
rurban worth pasting or just libs?
libpcre likes to fail there
rg auto_gcc-01.t, auto_warnings-01.t and inter_progs-0[1-4].t 19:34
i'll have a closer look.
dalek pp: 24fb6a1 | (Bernhard Schmalhofer)++ | (3 files):
Put library *.pmc files into library.
 19:37
rg apparently these are Configure tests 19:38
shorten dalek's url is at xrl.us/begxuc
rg all those tests assume they can run gcc (which i have intentionally removed from my path and don't need to build parrot) 19:44
19:49 rob joined 19:50 particle1 joined
rg can it be that nobody has tried to build parrot on a system without gcc before? 19:54
rurban I usually run icc, cc and sometimes llvm-gcc
rg but do you still have gcc in your path?
Coke it is more likely that the person who wrote those tests happens to have gcc. 19:55
rurban llvm-gcc is broken (my fault) and icc on i386 crashes
19:55 ThF joined
rurban yep I do 19:55
msvc has no gcc in the path
this deserves another ticket... 19:56
rg it could be a different problem
if perl was configured with gcc the tests try to run with that configuration instead of what parrot was built with 19:57
it definitely deserves a ticket
i'd like to find out first what's the case here, though.
Coke There may already be a ticket for that from andy dougherty.
rg should i search rt? 19:58
rurban could be, but should not be. we store both options in our $conf->data. ->c and ->p5. here the p5 setting fooled us
please search.
but the new ticket should go to trac 19:59
msvc passes these tests, and I think we assume the gcc with perl should be valid for parrot also
sorry, the "cc" for perl
I've got some strange alignment issues with packout. will not be ready today. sorry 20:01
rg i don't think we should assume the compiler that has built perl, also built parrot. 20:02
i'll wait a bit if kid51 can tell me more about those tests. 20:05
Coke rg: yes. a long standing shortcut.
that has bit us on multiple occasions, usually Andy D.
rg okay, about building those native pbcs ... 20:07
tools/dev/mk_native_pbc: syntax error at line 35: `byteorder=$' unexpected
ah. works with bash. 20:08
where should i put/send them? 20:10
rurban hmm, per mail to parrot-dev 20:11
but zip them please, string_6 is not needed
maybe string_6 as well, just to make sure. 20:12
Infinoid tools/dev/mk_native_pbc has bashisms? we could just rewrite it in perl.
rg well solaris sh is probably also especially picky 20:13
rurban but I'm changing alignment soon, so we need new ones then again
Sure, it has to rewritten in perl, I was just too lazy
rg just wait for perl6 then ;) 20:14
rurban yep. we'll rewrite it in perl6 anyway sooner or later.
Infinoid :) 20:15
Tene rakudo isn't in the tree anymore. a PIR version would be nicer. 20:16
And more feasible.
rurban should we create probes for stack alignment? 20:17
rg well you can generate the pir with perl6 then.
rurban or nqp
rg that will probably always be in the tree too 20:18
rurban I think we need the string tests for testing all the encodings and charsets
rg what do you mean with probes for stack alignment?
20:21 rurban_ joined
Tene or lolcode 20:21
rurban_ rt.perl.org/rt3/Ticket/Display.html?id=40804 is wrong btw. he means the number 16 for alignment, not 16-byte stack alignment 20:23
20:25 magnachef joined
rg i was wondering about that, but 16 bit alignment seems a bit small to me. 20:25
does anyone know those opcodes? 20:26
rurban 16 byte would be for 256bit cpu's
Infinoid ... pie and bacon? 20:27
rurban oops, apparently chip is right. "Moves 128-bit value from an XMM register or 128-bit memory:" 20:28
MOVDQA xmm1, xmm2/mem128 66 0F 6F /r
20:28 Tene_ joined
rurban quad precision double 20:28
Whiteknight chromatic can be very colorful in his metaphors 20:30
Infinoid Makes for interesting reading. :)
cotto I'm sticking with Parrot, but I'd still like that map. 20:38
Coke pah?
I like pah.
Whiteknight loves bacon and pie
jonathan Mmm...bacon and pie.
Infinoid isn't sure the two go together very well
(Having never tried it, I may be wrong.) 20:39
rg who said anything about having them together?
Whiteknight it does sound like a fun experiment
Infinoid I've heard of worse.
jonathan A bacon pie.
Infinoid Peanut butter on a bacon cheeseburger is actually really good
jonathan Wouldn't that be like pork pie?
Coke misses the House of Pi in Houston, Tx.
Infinoid You never know. Maybe he was intending to circle those restaurants who serve a dish named "pie and bacon". That would make the map less time consuming to draw... 20:40
Tene_ What map is this? 20:47
rurban Ah Andy Dougherty spoke up and fixed my wrong calculation. good! TT #364
Whiteknight from chromatic's last email
rurban that's why my fix didn't work
Coke bacon and pie is lists.parrot.org/pipermail/parrot-d...01555.html 20:48
shorten Coke's url is at xrl.us/begx6v
cotto realizes that he has both bacon and microwave 20:49
rurban rg: trac.parrot.org/parrot/ticket/364#comment:4 20:50
the first pf->src address is misaligned, not the stepper.
so chrmatic was right. 20:51
rg i can't say i understand it all. isn't it still the case that 16 bit alignment on sparc is too little for the default compiler settings? 21:00
so if that was a design choice, are we just going to require -xmemalign=2s ? 21:02
(or i guess we could also use -xmemalign=8i and see which one performs better) 21:05
rurban he says that we must align the base src address pf->src 21:10
and that the writers are okay, just the reader needs one alignment. and that my finding of using the foreign ptrsize is right. 21:11
this was the 32<=>64 bit problem 21:13
just two tiny errors, one of it I already tested okay.
rg so do i need to debug anything else? 21:24
rurban I'm just testing 21:39
21:40 mberends joined
rurban passed 21:43
dalek a: 5c66e86 | (Francois Perrad)++ | (3 files):
move pbc libraries in /library
 21:44
a: adf829f | (Francois Perrad)++ | (2 files):
adjust .gitignore
a: 3188461 | (Francois Perrad)++ | (2 files):
add targets : build, installable, install win32-inno-installer
shorten dalek's url is at xrl.us/begyff
dalek's url is at xrl.us/begyfh
shorten dalek's url is at xrl.us/begyfj
rg ah look at that. i now managed to build a 64bit binary with gcc aswell. i wonder what was different the last time i tried. 21:46
and gcc does not have those alignment problems. 21:47
s/gcc/the gcc generated code/
rurban it might be less strict than cc (and slower) 21:48
mem_sys_allocate() should align to ptr_alignment 21:50
Infinoid I'm not sure mem_sys_allocate has any control over how malloc() aligns 21:52
rurban on a sparc I assume system malloc aligns automatically to its wanted size. 21:56
But I want to test that.
21:59 ron joined
Coke msg TimToady the *difference* between, not the *differences*. neh? 22:00
purl Message for timtoady stored.
Coke msg TimToady though i see you just fixed it. nevermind. =-) 22:04
purl Message for timtoady stored.
TimToady I'm not very good at minding at the best of times
dalek rrot: r36911 | chromatic++ | trunk/t/pmc/os.t:
[t] Fixed hardlink to directory tests so that they don't fail when run without
 22:07
22:09 Whiteknight joined
rurban Operation not permitted is not really safe enough 22:10
on german windows its different
msg chromatic "Operation not permitted" on german windows will be different 22:11
purl Message for chromatic stored.
Whiteknight german isn't a dynamic language, so Parrot doesn't support it 22:13
:)
rurban msg chromatic checking errno is safer
purl Message for chromatic stored.
rg aren't there localized versions of linux aswell? solaris for sure. 22:14
also, hardlinking to directories is not a good idea (at least not on ufs). 22:15
Tene_ [sweeks@kweh ~]$ LANG=fr_FR ls /root 22:17
ls: ne peut ouvrir le r�pertoire /root: Permission non accord
rurban nzfs allows it but its neither a good idea. that's why there no tools to support it. just junction 22:18
Tene_ Hm. More accurate would be: 22:19
[sweeks@kweh ~]$ LANG=fr_FR.UTF-8 ln /tmp/tmplink
ln: accès de `/tmp/tmplink': Aucun fichier ou dossier de ce type
ron I have been trying to do some research on rt 40438 (rt.perl.org/rt3/Public/Bug/Display....id=40438). The ticket was initially described as a dynpmc issue which was later corrected to being a namespace issue. The last substantive posting used a getclass operator which has now been replaced by get_class and, as demonstrated by the nopaste to follow shortly, if the current parrot...
...class stuff is used as documented everything seems to me to work fine. Wondering if "classes being defined in parrot namespace" in that last post still makes sense as a problem and if someone might explain a bit what problem if any remains here?
nopaste "ron" at 168.100.250.30 pasted "Updated (working) test code for rt 40438" (13 lines) at nopaste.snit.ch/15686
dalek rrot: r36912 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[install] minor improvements
 22:20
ron If my question would have been better posted to rt or trac please also feel free to comment ... 22:21
22:27 mberends joined
Infinoid ron: looks closeable to me, but I'm not a pir namespaces/subclasses expert. 22:30
22:37 timbunce joined 23:11 Theory joined
dalek rrot: r36913 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[install] add chmod in target install
 23:12
rurban rg: I found a place where this problem was attacked before: src/gc/system.c: Store the code in a union with a double to 23:13
ensure proper memory alignment.
23:13 contingencyplan_ joined 23:14 mikehh joined
cotto Is anyone here somewhat familiar with jit guts? 23:15
rurban a bit
cotto There's something in the jit code that's using an NCI PMC's PMC_struct_val, and I can't find it. 23:16
dalek a: 29dd321 | (François Perrad)++ | config/makefiles/root.in:
fix makefile on linux
 23:17
shorten dalek's url is at xrl.us/begys8
cotto This patch causes most of t/pmc/nci.t to fail:
nopaste "cotto" at 96.26.202.243 pasted "make NCI asplode" (162 lines) at nopaste.snit.ch/15689 23:18
cotto Note that a backtrace on the segfault will result from attempting to jump to 0xbaadf00d, which is what NCI PMCs' PMC_struct_val is set to. 23:19
any clue? 23:21
23:27 Tene joined
cotto msg chromatic can you look at nopaste.snit.ch/15689 and figure out what's accessing NCI's PMC_struct_val? The patch causes most of t/pmc/nci.t to fail. 23:43
purl Message for chromatic stored.
Infinoid hmm. PMC_struct_val, PMC_int_val() and PObj_bufstart() all access the same thing 23:49
I can't reproduce any failures on amd64 with a non-jit-enabled build, so I think you're right that it must be something in jit 23:50
but that sums up the extent of my knowledge of jit.

Powered by Cro and the Raku® Programming Language.

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

Thank you!