Parrot 0.9.1 Released | parrot.org/ | < 1 week to Parrot 1.0!
Set by moderator on 10 March 2009.
dalek rrot: r37335 | jkeenan++ | branches/install_tools (3 files):
In Parrot::Install, begin to add documentation for individual subroutines.

Subroutines are now explicitly imported so they don't need to be fully qualified.		 00:00
purl qualified is the whole module name or?
wayland76 kid51: Maybe I should just leave things to you :) 00:01
With no svn commit, I can't keep up :)
cotto purl, ignore dalek 00:02
purl cotto: i'm not following you...
cotto That's the problem.
wayland76 purl, what can you do? 00:05
purl wayland76: i haven't a clue
wayland76 That sounds about right :) 00:06
kid51 Ah, good evening. Yeah, I got on a roll. But it will give you an idea of how to proceed. 00:08
dalek rrot: r37336 | jkeenan++ | branches/install_tools/config/gen/makefiles/root.in:
Let's run the tests of the install tools as part of make manifest_tests (since
kid51 In particular, inspect tools/dev/install_files.pl. The patch didn't install cleanly, so I had to reconstruct it.
00:09 AndyA joined
kid51 Am going to dinner soon. You can check out the branch and work from there by submitting patches. I'm AFK this weekend, so there still be plenty for you to do. 00:09
wayland76: Does that sound okay? 00:10
wayland76 fine :) 00:12
I'm just trying to resolve the conflicts again now :) 00:13
00:20 Woody4286 joined 00:49 davidfetter joined
wayland76 purl: seen rurban 00:59
purl rurban was last seen on #parrot 6 hours, 20 minutes and 36 seconds ago, saying: I'd need someone for some ptr casting trouble I have on TT#254. Maybe this is fatal on certain compilers
01:47 jimmy joined
jimmy purl, forgot qualified 01:47
purl jimmy: i'm not following you...
jimmy purl, forget qualified
purl jimmy: I forgot qualified
GeJ did something change in the make html target recently? I'm seeing a new warning message: 01:57
How to reproduce: make realclean; <configure>; make html
the message: "Failed to process docs/packfile-c.pod." 01:58
jimmy make html always failed for file changing 01:59
GeJ the way I understand the docs/Makefile, "docs/packfile-c.pod" is generate with the 'all' target.
So now, one must build parrot first before generating the html. 02:00
I'm asking because I used to do it the other way around, and never noticed this message.
I'm trying to browse the commit logs, but can't seem to find anything relevant about this. 02:01
jimmy maybe some .c files had been renamed, 02:02
but 'make html' had not been fixed. 02:03
dalek rrot: r37337 | Util++ | trunk/examples (23 files):
[examples] Typo corrections
02:05 eternaleye joined
allison GeJ: docs/packfile-c.pod was just recently added to the html generated docs 02:07
jimmy I always got that failing
allison GeJ: make html should probably require parrot to be built already
GeJ allison: Ah, ok. I'll update my build script to put html generation after the build. thanks for the heads up. 02:09
rg the docs Makefile has a target to build packfile-c.pod, maybe the html target just needs to depend on it (like the all target)? 02:10
02:10 kid51 joined
GeJ heya James 02:10
kid51 good morning Geraud 02:11
Util: see trac.parrot.org/parrot/ticket/438 02:16
Util Much thanks for taking the time! I was doubting myself after the fulltest/fulltest_all mixup. 02:19
02:29 gryphon joined
Util rg: +1 to that idea. Certainly, parts of parrot need to be built so that `make html` can get at every bit of generated doc, but at leastsome of the built can be delayed/deferred when `html` is all you want to make right now. 02:38
mikehh Util: I somehow missed reading those revisions - I had quite a bit of trouble generating reports for all tests 02:43
02:52 tetragon joined 03:34 Tene joined 03:35 janus joined 03:44 Andy joined 03:47 estrabd joined
dalek rrot: r37338 | Util++ | trunk/languages/cardinal (9 files):
[cardinal] Typo corrections
 03:47
rrot: r37339 | Util++ | trunk/languages/jako/lib/Jako (4 files):
[jako] Typo corrections
 03:55
rrot: r37340 | Util++ | trunk/languages/lisp (3 files):
[lisp] Typo corrections
 03:59
04:10 tetragon joined
dalek rrot: r37341 | Util++ | trunk/languages (8 files):
[languages] Typo corrections
 04:11
04:51 Theory joined
dalek rrot: r37342 | Util++ | trunk/tools (8 files):
[tools] Typo corrections
 04:53
rrot: r37343 | Util++ | trunk/runtime/parrot/library (11 files):
[library] Typo corrections
 05:25
Coke ~ 05:32
dalek rrot: r37344 | allison++ | trunk (8 files):
[cage] Rewrite -r to --run-pbc and use the verbose form in TODO/skip matching.
 05:45
Tene ! 05:46
Coke allison: ping 05:52
allison Coke: pong 05:53
Coke allison: is it ok for files in the repo to have multiple copyright statements? 05:54
(e.g. all the IMCC files?)
allison Coke: in general, no, that is, we're trying to remove them
Coke should the copyright test complain about it? 05:55
allison Coke: yes
Coke k.
allison the tricky part is things like Pod::Simple
05:55 masak joined
allison but, we'll move that out of the repository as soon as we can 05:55
Coke those are already skipped by the test. 05:56
allison Coke: okay, good
Coke only failures left are chromatics, and soon to be melvin's.
allison Coke: on IMCC, I can see putting in an exception, at least until we contact him
Coke allison: they happen to pass now because they do have a PaFO copyright. 05:57
Util I sent email to chromatic on Tuesday, re: copyright on his remaining files.
allison Util: ok
Util: those are all Parrot::Embed, right? 05:58
Util Right
allison Coke: ah, okay
Util ext/Parrot-Embed/lib/Parrot/{PMC,Embed,Interpreter}.pm
allison in theory, ext/ means "external", and isn't packaged up with the rest of the repository, but I don't remember if Parrot::Embed is included in the tarball. Probably it is. 05:59
dalek rrot: r37345 | coke++ | trunk/tools/dev/mk_language_shell.pl:
pass 'make codetest' again.
 06:00
Coke we should either remove the parrot foundation copyright on chromatic's and skip them, or remove chromatics and keep them. 06:03
it's 2am here. quick way to see how many times a RE matches in a string?
allison Coke: definitely keep the parrot foundation copyright 06:04
Coke $count++ while ($str =~ m/foo/g); seems ugly. =-)
allison Coke: and legally, there's no problem removing chromatic's copyright (he already retains copyright under the contributor agreement) 06:05
Coke: it's just that the module is released on CPAN as well as in the Parrot repository
Coke Presumably the copyright statement should match in both places. 06:06
allison Coke: and seems strange to have it appear with different copyright in the two places
Coke: aye
06:06 clunker3 joined
Util Related (allison, Coke): copyright.t scans {C,Perl,Makefile} source, but not {t,PIR} source. 06:12
Is there a reason to omit t/*.t and *.pir files from scanning, or is it just a manpower issue?
Many of the .t and .pir *do* already have copyright statements, but several hundred do not. 06:13
Coke hurm. updating the copyright test to be more finicky about IMCC is more effort than I'm goign to expend right now.
cotto allison, shouldn't the rsync make target should be removed?
Coke Util: t/examples/streams.t is failing for me. 06:16
Util Checking...
Coke I suspect allison's change just before yours fubar'd it. 06:17
that would make it twice she's done that. =-)
Util: I don't know why we don't check t and PIR files.
or really, why we don't just check everything. 06:18
Util Coke: I have a personal TODO to recode that test to remove the hardcoding by duplicating the PIR codepath in Perl, then checking for matching results. 06:20
allison cotto: yes, remove the rsync target 06:28
dalek rrot: r37346 | cotto++ | trunk (5 files):
[makefile] remove the obselete rsync target
 06:35
cotto Whoops. That was way more than I intended to commit. 06:36
06:36 korshak joined
dalek rrot: r37347 | Util++ | trunk/t/examples/streams.t:
[t] Made streams.t match its source input again
 06:39
cotto all better 06:41
Util Coke, it was not allison's doing; I failed to sync the test during a typo batch (r37337). Fixed now. Thanks for spotting it! 06:42
dalek rrot: r37348 | cotto++ | trunk (4 files):
[hash] undo accidental commit
 06:43
Util tries to type something Perlishly witty involving sleep() and alarm(), but fails miserably. 06:47
Night, all.
purl g'mogjt
GeJ purl: what was that? 07:13
purl gej: no idea
07:15 uniejo joined 07:24 janus joined 07:25 Psyche^ joined
dalek rrot: r37349 | fperrad++ | trunk/tools/dev/mk_inno_language.pl:
[inno] add dynext
 07:25
07:31 alvar joined 07:36 wayland76 joined
dalek rrot: r37350 | allison++ | trunk/t (2 files):
[cage] TODO two tests, known failures with lexicals and -r. Patch from Rolf
 07:49
07:50 korshak left 07:59 nick joined, mj41_ joined 08:01 mj41__ joined, nick left 08:03 elmex joined, klapperl joined 08:07 jq joined
dalek rrot: r37351 | fperrad++ | trunk (3 files):
[doc] remove languages
 08:10
cotto someone who knows python should write a fusil fuzzer for parrot
08:14 tetragon joined, zpmorgan joined 08:16 mikehh joined 08:24 contingencyplan joined
wayland76 Do any of the parrot tests test whether the -L option works? 08:30
08:50 tomyan joined 09:16 Gerd joined
wayland76 If I'm putting some printfs into parrot, and wanting to print the contents of a struct STRING, is there an easy way to do that? 09:28
(or, to phrase it alternately, where is struct STRING declared?)
Forget the second way I put the question; I'm not sure it'd help 09:34
purl wayland76, I didn't have anything matching second way i put the question; i'm not sure it'd help
wayland76 That might be because I wasn't talking to you 09:36
TiMBuS wayland76, i think you'e looking for pobj.h
moritz purl: don't forget yourself 09:37
purl moritz: excuse me?
TiMBuS struct parrot_string_t
wayland76 Thanks TiMBuS! I'll try that 09:44
09:46 ujwalic joined 10:05 korshak joined 10:07 korshak left
wayland76 It's not helping me, unfortunately. 10:21
inline op loadlib(out PMC, in STR) {
printf("Preparing to load library %s\\n", $2);
$1 = Parrot_load_lib(interp, $2, NULL);
}
This is taken from src/ops/core.ops 10:22
The only line I added is the printf
Unfortunately, during compilation, it complains that $2 isn't a string (I'll get the exact error later)
Anyone know how to print a STR? 10:23
TiMBuS you gotta print the actual string, which is inside the STRING struct as a pointer 10:26
its $2->thestring (one sec ill get the actual name) 10:27
strstart
purl strstart is going away.
TiMBuS never! 10:28
wayland76 Ah, I need -> -- sorry, I was doing .
:)
(I haven't done much C in quite a while) 10:29
TiMBuS yeah it can get you sometimes when it comes to pointers
10:31 bacek joined
wayland76 Appears to compile now. Now I just have to see whether it will print anything :) 10:37
TiMBuS you also have to hope its a null terminated string because parrot uses buflen for string size and so doesnt need the trailing \\0 :x 10:38
wayland76 Ouch 10:39
Pascal strings :) 10:40
TiMBuS im only assuming here, it might be ok
wayland76 Does Parrot have its own printing function that I can use?
TiMBuS Parrot_io_printf 10:42
io.ops prints strings as such: Parrot_io_putps(interp, _PIO_STDOUT(interp), s); 10:43
s is a STRING*
wayland76 Ok, thanks. I'll try that if I have any more trouble 10:48
10:52 jan joined
wayland76 ordinary printf worked. Thanks! Now I'm getting somewhere with my debugging :) 11:13
dalek rrot: r37352 | fperrad++ | trunk/tools/dev/gen_makefile.pl:
[tools] allows expand_gmake_syntax
 11:37
wayland76 I have a question about src/dynext.c In the Parrot_load_lib function, it suggests the alternate possibility of throwing an exception. Is there a reason this isn't done? 11:48
11:58 rblackwe joined
wayland76 How do I get the Parrot_warn messages to show up? 12:03
Oh, put the -w before the filename :) 12:09
12:33 rg1 joined
dalek rrot: r37353 | fperrad++ | trunk/tools/dev/gen_makefile.pl:
[tools] fix previous commit r37352
 12:48
12:56 Woody2143 joined 13:08 korshak joined 13:09 gryphon joined
dalek rrot: r37354 | coke++ | trunk/runtime/parrot/library/Getopt/Obj.pir:
Fix Pod formatting issue {Eric PERCHE}++
 13:25
13:56 Andy joined 14:01 ron joined
ron karma 14:02
dalek rrot: r37355 | coke++ | trunk/config/gen/makefiles/root.in:
Remove defunct target 'doc_tests'.
 14:03
kudo: c48d6a3 | pmichaud++ | src/ (2 files):
Move ucfirst, lcfirst, chop, and fmt into settings. (RT #63796, cspencer++)

modifications.		 14:34
purl modifications are picked up all the time
shorten dalek's url is at xrl.us/bejbvm
dalek kudo: 087e299 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 317 files, 7153 passing, 0 failing
 14:39
shorten dalek's url is at xrl.us/bejbv8
14:42 particle1 joined 14:44 zpmorgan joined
pmichaud purl, no modifications is <reply> 14:54
purl OK, pmichaud.
Coke modifications? 15:00
purl modifications are picked up all the time
Coke pmichaud: you need "no,"
korshak =)
maybe just "forget"?
pmichaud purl: no, modifications is <reply> 15:01
purl OK, pmichaud.
Coke korshak: if you forget, he can relearn another factoid for that slot later.
if you use this trick, the slot is blocked.
korshak ah, yep
but somebody can define new factoid to "modifications" again anyway 15:02
pmichaud but not inadvertently.
modifications is baloney
modifications?
:-)
korshak purl, modifications?
purl i haven't a clue, korshak
korshak hehe
15:14 rdice joined 15:27 Theory joined 15:33 Psyche^ joined
pmichaud Coke: when you moved various languages to googlecode, did you try preserving the history at all or just move the latest version? 15:39
15:42 korshak left 15:51 Tene_ joined 16:37 davidfetter joined 17:05 Whiteknight joined
Whiteknight pmichaud, ping 17:07
pmichaud Whiteknight: pong 17:08
Whiteknight I've got a PCT question for you, if you have time
What's the status of lexical variables in interactive mode? Is that still an unresolved problem? 17:09
pmichaud yes, still unresolved.
in the general case it's a fairly difficult problem, because parrot lexicals are tied to subs. 17:10
Whiteknight Okay. that's what I figured. I just transitioned our compiler to use all lexical variables and now interactive mode is completely borked
pmichaud but pct should probably come up with some way of solving the general case. 17:11
Whiteknight I had a idea where TOP($/, "close") would query the current lexpad, and export all the variable names/values to a global hash somewhere
but it seems like an awfully hackish solution to me
pmichaud ...and it's also a problem because that's compile-time, not runtime.
but yes, I see the general idea. 17:12
Whiteknight Well, TOP() would call a run-time handler to manage the exports, or something. I haven't fleshed it all out yet
pmichaud it really feels like it ought to be handled somewhere other than the parser, though.
Whiteknight What if the LexPad PMC had some kind of 'export'() method to return a hash of all its current name/value pairs? 17:13
pmichaud my "best" idea thus far has been to have the interactive mode keep track of each sub that gets generated, and attach subsequent lines as inner scopes to the one previously executed. 17:14
well, the LexPad PMC is effectively a hash already -- we should be able to just iterate over it somehow. (But currently that doesn't work.)
Whiteknight what doesn't work for it, string keying? 17:15
because that would be a trivial thing to add methinks
pmichaud I looked at it once before but couldn't figure out the iterator part.
RT #40156 is a related ticket. 17:16
Whiteknight Well, I'm going to start looking at this since I'm butting up against it now. I'll pass any ideas through you
PerlJam what causes class defs to hang around on subsequent lines in interactive mode?
pmichaud they aren't lexical in Rakudo yet.
PerlJam ah, of course :)
pmichaud package variables ("our") also work fine. 17:17
PerlJam do they?
pmichaud well, you have to redeclare them on each input line, but they retain their value.
our $x = 3;
Whiteknight yeah, the "global" keyword in M does the same thing, I'll probably implement that next to get around this.
pmichaud our $x; $x.say; # "3\\n"
PerlJam if you could just hoist lexicals up to a scope that surrounds the entire interactive session ... 17:18
pmichaud that requires being able to know the list of lexicals 17:19
Whiteknight PerlJam, but then the parser would need to know if it was in interactive mode or not?
PerlJam or just put them in a particular scope to begin with.
pmichaud there's not an easy way to iterate a lexpad, though. I haven't thought of trying to iterate a lexinfo, though.
Whiteknight and also know whether it was in the topmost scope, or in a nested scope
pmichaud we might be able to get the list of lexicals from a lexinfo.
anyway, as was briefly discussed at PDS last november, I'd really like to see the internal implementation of Parrot lexicals changed. 17:20
Whiteknight really? what changes you have in mind?
pmichaud we could do a lot better with prototype-based lexpads instead of the lexpad/lexinfo dichotomy
consider the Perl 6: my Int $a; my Str $b is context<rw> = 5; 17:22
currently we have to generate code to attach the type constraints and properties to each lexical as it is created
it would be much better if those constraints and properties were part of the block's "prototype lexpad", and we just clone that lexpad when we need a new one for a block invocation
afk for a while # lunch 17:26
Coke pmichaud: I answered that question in trac.parrot.org/parrot/wiki/LeaveTheNest, but it seems to have been edited away.
trac.parrot.org/parrot/wiki/LeaveT...?version=2 //when partcl left 17:27
pmichaud: (we lost our history)
pmichaud okay, thanks. I think I'll do the same for pynie. 17:28
but, after lunch.
the history is still in the parrot repo if anyone wants/needs it.
Infinoid oh whoa, I'm mentioned on LeaveTheNest. Go me 17:31
17:31 Khisanth joined 17:32 PacoLinux joined
Coke pmichaud: it would be nice if someone from rakudo added a pointer there on your trick to get the version of parrot you want for rakudo. 17:35
I'm planning on eventually making partcl emulate your work there.
Whiteknight makefile(23) : fatal error U1033: syntax error : '=' unexpected Stop. 17:56
anybody have any idea why I would be getting this error when I try to make? 17:57
Infinoid Which platform? 17:58
purl I'm running on OS/2 on an Atari, can you help?
cotto purl wins 17:59
purl MENTALITY!
Whiteknight WinVista 32
Infinoid purl: only if the Atari is really an emulator running on a TI calculator.
purl OK, Infinoid.
Infinoid Whiteknight: random guess, nmake requires a space between the target name and the colon, and the Makefile didn't have one 18:00
or some other similar spacing issue
(is it nmake?) 18:01
18:03 ruoso joined
Whiteknight yeah, it's nmake 18:03
18:03 eternaleye joined
Whiteknight actually, I'm using strawberry perl 18:03
no nevermind, it is nmake
Infinoid all those :='s were ='s until recently, maybe nmake doesn't understand them.
particle1 i don't believe nmake requires a space 18:04
nmake doesn't understand :=
i thought with strawberry, you would use mingw32-make, not nmake
*should use
Infinoid r36940 looks suspicious 18:05
18:05 Whiteknight_ joined
Whiteknight_ Okay, I switched over to mingw32-make and it's working fine 18:06
nmake definitely doesn't like that makefile
particle1 nope. next time read the output of configure :P
Infinoid root.in is apparently edited appropriate for the msvc-config case but not the mingw case
s/appropriate/appropriately/
Whiteknight_ the output of configure is for losers. I don't need no stinking output of configure 18:08
particle1 is that why you're such a winner, failing to build parrot? 18:09
Whiteknight_ one of many reasons :)
particle1 i like visiting #parrot and keeping people feeling good about themselves, and motivated
Whiteknight_ particle1++
Coke ever did see an answer to why we have := at all. 18:13
*never
Infinoid It might shave half a second off the build process. 18:17
Whiteknight it's a half-second that you're never getting back!
Infinoid Refunds are available but only if you have a receipt.
Coke there are better places to shave seconds off the build process that probably won't involve breaking nmake. 18:51
NotFound Breaking it you save the time of the complete build process 18:53
dalek rrot: r37356 | NotFound++ | trunk/examples/tools/pbc_checker.cpp:
[examples] hex dump fp numbers in pbc_checker
 18:56
18:56 Whiteknight joined
pmichaud Coke: (trick to get version of parrot we want) -- we just have a custom Configure.pl that does the magic to build the Makefile, instead of relying on Parrot's Configure.pl to do it. 19:06
that custom Configure.pl also knows how to build Parrot (actually -- it just calls another script to do it)
dalek rrot: r37357 | NotFound++ | trunk/examples/tools/pbc_checker.cpp:
[examples] fix directory format reading and add some more pseudoxml tags in pbc_checker
 19:13
19:24 barney joined
allison relocating 19:24
purl relocating is much nicer than killing them
Coke pmichaud: just that text with perhaps a link to the latest version in your repo would be spif.
dalek rrot: r37358 | NotFound++ | trunk/examples/tools/pbc_checker.cpp:
[examples] fix again directory format reading in pbc_checker
 19:26
rrot: r37359 | fperrad++ | trunk/examples/languages/abc (4 files):
[abc] re-run mk_language_shell.pl
 19:47
rrot: r37360 | fperrad++ | trunk/examples/languages/squaak (2 files):
[squaak] re-run mk_language_shell.pl
 19:51
19:51 particle2 joined 19:54 bacek joined, PacoLinux joined
dalek rrot: r37361 | tene++ | trunk/docs/user/pir/exceptions.pod:
The start of exceptions user docs.
 19:55
pmichaud Coke: added a note to the LeavingTheNest page 20:02
dalek tracwiki: v12 | pmichaud++ | LeaveTheNest 20:05
tracwiki: trac.parrot.org/parrot/wiki/LeaveT...ction=diff
shorten dalek's url is at xrl.us/bejdjz
nopaste "NotFound" at 213.96.228.50 pasted "Encoding not stored in obc" (35 lines) at nopaste.snit.ch/15868 20:08
NotFound Ugh, obc -> pbc 20:09
dalek rrot: r37362 | fperrad++ | trunk (8 files):
[befunge] re-run mk_language_shell.pl
20:13 eternaleye joined
Coke pmichaud++ 20:14
20:15 Theory joined, particle1 joined
Coke t/codingstd/copyright.t is broken again if someone wants to fix it. 20:20
dalek rrot: r37363 | NotFound++ | trunk/examples/tools/pbc_checker.cpp:
[examples] pbc_checker: cleaner dump of bytecode segment
 20:26
20:29 rurban joined
Coke I just noticed that example code is in C++. 20:29
rurban NotFound++ that is yet. yeah
NotFound Coke: I managed to insert it silently at night ;) 20:30
rurban NotFound: did you also found the specials? this explains the debug section 20:31
NotFound rurban: I think that at the current release and after pdd13 study, there are no alignment problems. 20:32
rurban there are on 64bit reading 32. see my patch at TT#254
NotFound Just remains inconsistencies in segment header usage, and unimplemented things. 20:33
rurban: that is not a problem in the pbc format, just in the converting code.
rurban yes, just the reader. writers are fine imho
NotFound rurban: Did you see my correction on your fix? 20:34
rurban the freeze/thaw section is unfortunate, but this is not specified
not yet, busy moving back home tommorrow
NotFound rurban: with a few changes, it builds fine in c++ and without warnings in c 20:35
In gcc, at least
rurban no warnings, great! I did it before also in my very first attempts, but had no time yet
BTW: 64bit big-endian also needs the same int casts. need rg to test 20:36
20:36 bacek joined
rg test what? sorry haven't had much time to work through things 20:36
rurban rg: can you test this trac.parrot.org/parrot/attachment/...it-3.patch with integer_2.pbc 20:37
shorten rurban's url is at xrl.us/bejdo7
rurban pbc_dump t/native/integer_2.pbc
I suspect you get a coredump on Parrot_hash_thaw 20:38
rg i was about to try doughera's patch from TT #364 however to be sure i tried to build parrot without -xmemalign and it just worked
rurban oh, good!
rg i'm running a smolder right now
rurban but maybe it was just luck.
rg maybe, i don't know. it makes it hard to know if a patch actually does something 20:39
the patch you just posted is next on my list
NotFound rurban: Have you seen nopaste.snit.ch/15868 ? 20:40
rurban very good test. we need to add this to the native_pbc tests right? 20:41
and a ticket of course :) 20:42
NotFound I'd like to talk about that with allison first, we may need to set a milestone
dalek rkdown: d9bff5a | (Francois Perrad)++ | config/makefiles/root.in:
re-run mk_language_shell.pl
shorten dalek's url is at xrl.us/bejdqk
rurban do have an idea where it got lost? 20:43
NotFound rurban: is just not written in the pbc
pdd13 is wrong/unimplemented
rurban good, a testcase to work against
where are our other encoding tests btw? 20:44
charsets ditto 20:45
rg isn't there a kinda big rewrite coming?
rurban t/op/string.t is not too good for all the missing charset and encoding tests. maybe we should add t/op/string_enc.t 20:46
NotFound Maybe we must wait for the string reimplementation 20:47
rurban charset test are in t/op/string_cs.t but pbc persistency is missing 20:48
NotFound Or maybe I must do another atempt of my proposal of dropping charsets and treat all as encodings of unicode.
cotto NotFound, strings are on the roadmap for 1.2
dalek rrot: r37364 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[install] fix libpath for mk_inno_language.pl
 20:49
rurban not everybody uses unicode. charsets are useful in lower lands
NotFound rurban: unicode is universal
All charsets can be explained as encodings 20:50
rurban Sure. But I like to use fixed_8 encoding
cygwin has no unicode support in some apis
NotFound unicode fixed_8 is latin-1
rurban in most APIs even
NotFound rurban: *we* support unicode. Talking with the os is our work. 20:51
rurban lots of work, yes. ucs2 path api is missing for me e.g. 20:52
I have a perl5 patch in the works, parrot later
dalek rrot: r37365 | fperrad++ | trunk/docs/compiler_faq.pod:
[pod] fix usage of .tailcall
 20:53
rurban remember jimmy's library.c problem?
NotFound rurban: I'm not saying that we must add full support for all encodings. Just that we can do the same we do now by treating all charsets as encodings, instead of having separated charset and encoding.
rurban I have no opinion on that 20:54
NotFound I'm the only one with that opinion, unfortunately :D 20:55
moritz NotFound: not quite. I have a different opinion, and we've discussed it previously at least twice
NotFound moritz: yes, someone have not opinion, others are agains, I'm the only in favour 20:56
rurban maybe treat that internally unified and provide the seperation externally
that would lead to much simplier implementation and format 20:57
moritz and much less general behaviour
rurban if he writes it that to please you. externally we should support charsets
or provide a pir library for charsets 20:58
... many libraries for all charsets
21:02 Whiteknight joined
NotFound That is exactly the reason for my point. Trating all iso-8859 variants as different charsets is a nightmare. 21:02
rurban yes, and stupid to link as c code to core 21:03
NotFound Treating them as unicode encodings is doable.
rurban but then icu is required. now its optional 21:05
icu is big and hard to build
NotFound icu is required *now* for any realistic usage.
rurban on mingw+msvc I have no icu now
NotFound rurban: Have you done realistic usage with text in foreign languages? 21:06
rurban for sure not
demerque brings up turkish then
NotFound Actually we do just some conversions between iso-8859-1 and unicode utf8, and even for that mininal work we need workarounds. 21:08
rurban and unicode decompose is NYI. RT #59696 21:09
NotFound Well, for 1.0 I think all we can do is fix pdd13 to explain that the encoding field is a proposal, currently unimplemented. 21:12
Or just delete it.
rurban deleting please not. 21:13
NotFound Is not a big task to add it again when implemented. 21:14
rurban rather implement it to fix that annoying bug
wouldn't be too hard I guess
NotFound Do you think we can implement and test it in time for 1.0? 21:15
21:15 eternaleye joined
rurban It will have to stay deleted than until 1.6 21:15
rather ignore it and either implement it or deprecate it properly 21:16
NotFound Deprecate what? A failure to implement something? 21:17
rurban the encoding field
no, the charset field you meant, right?
NotFound We can't deprecate a thing that does not exist.
rurban it exists. it is just 0
NotFound No, charset exists and is used. encoding does not exist, is just a line in pdd13 21:18
Is not written, is not readed.
rurban yes, I see.
Whiteknight does NQP have any support for hashes? 21:19
rurban good argukment for idea to use encodings for that slot then :)
NotFound I think that what it actually does is use the prefered encoding for the charset, but I don't looked at the source yet. 21:20
rurban BTW: I'm testing your revised tt254 -3 patch now and commit it. looks good for now
NotFound rurban: ok
rurban don't we have a string API to make a string with given charset AND encoding?? 21:21
only encoding_lookup_index(encoding) ? 21:22
NotFound rurban: yes, but if we don't have a field for the encoding, we have no option.
rurban requires a PBC_COMPAT change. better now than later :)
aargh, allison disabled my tests again! 21:23
NotFound Is a shame I don't pay enough attention to that thing last week.
rurban I thhink I will give up soon. 21:24
NotFound I'll try a fix and see if it does not broke too much things. 21:25
rurban Looks like some politicians without any idea of the consequences made a useful deprecation commitment, but then paid no attention to the consequences. And then gave no support to the implementors. opsrenumber must not used post 1.0 but instead the native_pbc tests and the comments about the problem where removed. sigh 21:39
oops, orry. I'm really confued. it is actually implemented. sorry 21:40
nopaste "NotFound" at 213.96.228.50 pasted "Patch: add missing encoding field in constant string in pbc" (82 lines) at nopaste.snit.ch/15870
rurban NotFound: not good. you must increment PBC_COMPAT also to 3.39 21:41
NotFound rurban: is just a test
rg btw did you guys fix the extra padding with 64bit? 21:42
rurban yes
just testing 21:43
rg great. thanks.
rurban trac.parrot.org/parrot/attachment/...it-3.patch is the latest fix, but for sparc64 I have one more
NotFound rg: I'm not sure if we fixed something or just managed to understand and correct the docs %-)
shorten rurban's url is at xrl.us/bejdo7
rurban I've fixed two things for sure
and notfound helped to compile it without warnings 21:44
rg ok, here's the smolder showing no more need for -xmemalign: smolder.plusthree.com/app/public_pr...ails/18938
shorten rg's url is at xrl.us/bejd25
NotFound rurban: but that was in the read code, not in alignments in the pbc, it isn't?
rurban yes. just the reader was broken.
the alignment was just misunderstanding 21:45
not alignment: the missing 16byte for 64bit
NotFound And pitfalls in the docs
rg huh? i'm referring to those: 21:46
if (pbc_version <= 0x0325 && opcode_size == 8)
pbcfile.ignore(16);
rurban yes, this was understanding
NotFound Not so bad, just a few errors in make test
Will try again after a realclean 21:47
rurban s/this was understanding/this was misunderstanding/
jonathan pbc_version? 21:48
purl it has been said that pbc_version is a hope that in the future things change
NotFound rg: this code it was just compensating for lack of fields or misinterpretation of his size.
rg so since we're at 0x326 and it's working means it's been fixed, right?
NotFound rg: I'm almost sure that now pbc_checker matches what the parrot code does, and read pbcs right. 21:49
GeJ Good morning everyone 21:52
NotFound All that remains is fix pdd13 to reflect reality
jonathan NotFound: What aspect of PDD13? 21:53
There are a few ways in which reality needs to approach the PDD rather than vice versa...
NotFound jonathan: TT #346
jonathan: TT #436
346 was my typo
jonathan: both things. pdd13 must also document current practice 21:54
dalek rrot: r37366 | rurban++ | trunk/src (2 files):
[core] fix TT#254 64bit failing to read 32bit pbc

  - cast Parrot_Int4 in fetch_op_[bl]e_4 to fix signedness
This strategy still uses nativeptr stepping (fast) and not the more general stepping in bytes (slow but easier to understand). It might introduce a new 'cast increases required alignment' warning, but not on gcc and msvc, and it is safe to use.		 21:57
21:57 rdice joined
NotFound After a realclean, all test pass with the encoding patch. 22:02
rurban In the meantime you have to merge it :) 22:06
NotFound rurban: The value for pbc version is in some source file or is extracted from PBC_COMPAT? 22:07
rurban just PBC_COMPAT
rg++ for testing andys patch 22:08
NotFound++ for fixing my cast warnings
rg well i didn't really get to test it :-/ 22:09
22:09 Limbic_Region joined
rurban Now I can sleep well, good 22:09
NotFound Building with c++ helps cleaning the code a lot.
rurban rg: contra testing is also a test
rg rurban: the revision you just committed is the patch you wanted me to test?
rurban NotFound: --cc=g++ ?
rg: yes current svn should be fine now. 22:10
just the tests have been disabled
rg so i'll just svn up and rebuild
NotFound rurban: yes, I don't think nobody else do it with other compiler.
rg i know, allison disabled the tests again. that doesn't mean i can't run them ;)
nopaste "rurban" at 93.210.229.135 pasted "enable_pbc_tests.patch" (97 lines) at nopaste.snit.ch/15871 22:11
rurban to make it easier
NotFound rurban: ah, you mean the options used? -cc=g++ --cxx=g++ --ld=g++ --link=g++
rg thanks. but leave them disabled for the release to keep the others happy. 22:12
rurban that's the trick! good
maybe that deserves a xconf/samples entry
NotFound If we make the change for the encoding field, all native_pbc must be regenerated. 22:13
rurban rg: sure
NotFound: I have no time for 2 days, but can do that on sunday. tests are skipped anyway
The main thing is: pbcs are now portable again! 22:14
even if we have no test coverage to prove it
NotFound I'll create a ticket with a clean version of the patch and my test case, and hope allison read it soon.
rurban oops. too eraly. still some failures on one of my tests... 22:15
NotFound rurban: Alignment related, or floating point? 22:16
rurban alignment or such. 22:17
this definitely worked yesterday and a few moments ago
src/packfile.c:1029: warning: cast discards qualifiers from pointer target type 22:18
NotFound rurban: In a TRACE? Don't worry, I'll fix that easily. 22:22
rurban I was just trying svn up; svn revert -R . on 64bit 22:23
with the enabled tests, and the 32bit tests failed again
anyway, encodings are more important than portability 22:24
NotFound: can you also the testcase and the PBC_COMPAT change and create ticket? it's definitely pre-1.0 material 22:28
*add* the test
rg rurban++ bytecode portability is working (tested on amd64) :)))
rurban good. 22:29
NotFound rurban: What test fails for yiou?
rg the solaris is slooooow, remember ;)
rurban my amd64 testmachine is gone into nirvana in bwetween. its in poland somewhere
NotFound Slowlaris, some people call it ;) 22:30
rurban well, my solaris on intel is superfast 22:31
and the latest UltraSparc with ~1GHz is fast also
but rg only has a ~350KHz, don't you? 22:32
äh MHz
ok, confirmed, now it works on amd64
rg well 440MHz, but that's not so much better ;) 22:33
rurban 440 but much better caching strategy they say.
Good for heavily loaded servers, not for building parrot :) 22:34
NotFound Build parrot on a heavily loaded server, then ;)
rurban parallize the build 22:35
-j8
rg it's only single cpu, too
rurban now that is crippled indeed
rg that thing is like 8-10 years old (i don't remember exactly)
rurban hmm, I get files like .pod_examinable_oreilly_summary_malformed.sto 22:36
maybe I can fix bignum now 22:37
22:41 bacek_ joined
rurban I forgot the new op to load a language pbc 22:54
rg ahem ... something seems to still be wrong with the native_pbc/number.t 22:56
rurban good, which converter?
Not all codepaths are tested and I want to mark that in the test and code 22:57
rg _2 -> _6 but also the test succeeded even though running it with parrot just outputs junk
rurban junk or 0 (zeros) 22:58
rg zeroes and 3.04813800201757e-319 last
rurban reading 12byte should be disabled. I marked it as untested. will change to tested nok then :) 22:59
rg works on amd64
failed on sparc64
but what worries me more is that number.t didn't catch it 23:00
rurban its a todo test, yet untested
12_le 1 1 0 0 ? => 12_le 1 1 0 0 0
see, 12_le has the most failures 23:01
there are still some more of those ? tests
rg i thought i had enabled them all. i guess i missed that
rurban what about the other 16_le tests? can I put some ? to 1 23:02
16_be sorry
rg oh the test matrix is not a comment
i did miss that
rurban I have two, first the code, and below the comment
removed the comment now. good point 23:03
NotFound I think the encoding thing is unfixable now :(
rurban oh, bad. so perl6 will have no persistant encoding support 23:04
NotFound I'll take a look at imcc before giving up, though.
rurban They still have their source to note down their encoding though. They are not used compiled files anyway 23:05
rg ok, so to test all pbc files on amd64 i'll have to put all 1s in the 16_le column, right?
rurban no. just run it and report sucees if it says so :)
the ? is todo and 0 is known to fail (to avoid coredumps)
better is to run it with perl t/native_pbc/number.t not prove 23:06
rg but there is a 0 in that column, so the test wouldn't be run
rurban sure, because this dumps ocre or is nyi
rg i've just put a 1 and it's still all ok 23:07
rurban now no test should dump core anymore, just return invalid numbers maybe.
good marking this as done now.
rg also, the 16_be is all ? (except native of course) and i'm not getting any unexpected passes :(
rurban 8_le 12_le 16_le 8_be 16_be 23:08
8_le 1 1 1 1 1
12_le 1 1 0 0 0
16_le 0 0 1 ? 1
8_be 1 1 ? 1 1
16_be 1 1 1 ? 1
rg changing that to all 1s doesn't make a difference. I don't think I'm using that correctly 23:10
rurban what does the report say? perl t/native_pbc/number.t 23:12
if there are skips they are reported as such.
rg it looks like it thinks it's 8_be? how could that be?
rurban 16_be is --floatval="long double" 23:13
8byte double only
rg ah, so i *am* not using it correctly ;)
rurban just trust the tests
NotFound imcc and Parrot_str_unescape are broken regarding encodings 23:14
rurban imcc sounds hard
rg well the tests are not noticing that my sparc64 parrot cannot read number_2.pbc
rurban the zero there is ignored? 23:15
there should be a skip 12_le=>8_be not yet implemented 23:16
23:16 kid51 joined
rurban wait, cvt_num12_num8_le is implemented and should work imho, just untested 23:18
rg it would be cvt_num12_num8_be
rurban nope, this is reverse. 23:19
rg ok 2 # SKIP 12_le=>8_be not yet implemented
rurban very confusing. melvin invented that
good, but you can set that to ? or 1 and test that 23:20
or just ./parrot t/native_pbc/number_2.pbc
rg yes, that's how i noticed that i expected it to fail in the first place.
rurban Hmm, so the endianizer needs adjustment there 23:21
dalek rrot: r37367 | pmichaud++ | trunk (5 files):
[pynie]: Remove pynie from parrot repository, now hosted at pynie.googlecode.com
 23:22
rg i'm still a little confused. what's the difference between 32bit sparc (number_3.pbc) and 64bit sparc (number_6.pbc)? 23:23
rurban not much regarding numbers, just the ops are larger 23:25
for consistency I kept the same names
and maybe some other error will crop up. 23:26
rg so i should probably also build a parrot with --floatval="long double"
PerlJam random question: Are all of those ops that come up as experimental during a build going to be in 1.0?
rurban yes, that's what you skipped with --noconf
PerlJam: the plan is to remove all 23:27
rg rurban: i think that plan was changed and they've just been marked as :deprecated
rurban ok, good for me
rg you think? they will probably be removed shortly after the release (if someone still feels compelled to actually do it ;P) 23:30
notfound: so do we have to expect another PBC_COMPAT increase from you? 23:31
NotFound rg: not sure yet
rurban I think he will fail
NotFound: Just joking :) 23:33
NotFound I know 23:39
rurban BTW: where are you from, NotFound? 23:40
NotFound Galicia, Spain
rurban Ah, good waves there 23:41
NotFound Santiago de Compostela
rurban Not so good waves :)
NotFound I hope not :D
Very big tsunami :D
rurban This winter they had 20m waves. The most dangerous bigwaves worldwide 23:42
My biggest was 5m
NotFound I don't surf
rurban And I'll never do that again
Just warning you. Very stupid sport
rg rurban: i'm sorry but i can't really wrap my head around the arch->file->test number correlations 23:43
rurban perl t/native_pbc/number.t is not good enough? 23:44
the number is the size in bytes. for number.t it's the floatvalsize, for integer.t it's the intvalsize
16_be is number_7.pbc 23:45
16_le is _5
rg i don't think we even have that file (_7)
rurban yes, not yet, sorry
you can add it and add the test and testmatrix entries 23:46
I also added _8 for short float, since I have that patch finished also 23:47
But I have no aix nor mips long double. this is know to be problematic as I saw in the gcc sources 23:48
rg perl t/native_pbc/number.t is pretty much the same as prove -v t/native_pbc/number.t which is what i was running
rurban but maybe its just a powerpc64 thing 23:49
rg i'll have to try what my sparc will do for long double
rurban -v good idea.
even with colors!
rg it's not that nice if you have failing tests 23:51
rurban But I got a new good one. ok 3 - 8_be=>16_le PPC double float 32 bit BE opcode_t # TODO 8_be=>16_le yet untested, TT #357. Please report success. 23:52
rg that's not TODO for me. i guess i removed the todo ;)
rurban you are 8_be, not 16_le 23:53
rg *sigh* right. i need to read properly
ok, i guess i could build 16_le pretty fast, but since you already have that i'll skip it. 23:54
rurban I came up with this notation because the pure numbers were even more disturbing
I already have 16_le, but we need 16_be
the testmatrix is already finihed for 16_be, just the test needs to be enabled 23:55
rg let's summarize: =>8_le: all 6 tests passing (i believe i removed a todo there)
rurban you mean =>8_be (ppc) 23:56
rg no, i mean amd64
rurban integer or number?
rg number
rurban 16_le => 8_le is failing for me 23:57
rg i get ok 5 - 16_le=>8_le i86_64 LE 64 bit opcode_t, long double
rurban src/string/charset/ascii.c:835: failed assertion 'source_string->encoding == Parrot_fixed_8_encoding_ptr 23:58
./parrot t/native_pbc/number_5.pbc
rg runs just fine here
rurban Ok, looks a like a lib problem. I'll rebuild
rg => 8_be: skip 12_le=>8_be (it could be todo, but it's not working); not ok 5 - 16_le=>8_be i86_64 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!