Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | smoke GC-related branches and attack GC tickets
Set by moderator on 1 October 2010.
00:24 dngor_ joined 00:25 dngor left
bacek_at_work ~~ 00:47
cotto ~~
01:04 dngor_ is now known as dngor 01:36 kid51_ joined 01:42 kid51_ left 01:57 silug joined 01:58 kid51 joined
dukeleto hola 02:11
kid51 duke fyi I got the same errors in mk_language_shell.t on Darwin/PPC 02:17
dukeleto kid51: which errors? 02:18
kid51: are you using --prefix ? 02:19
kid51 the FAILs
no, not using --prefix
dukeleto kid51: have you done a recent smoke report? some better diagnostics have been added to the tests 02:20
nopaste "kid51" at 192.168.1.3 pasted "mk_language_shell.t still has two FAILs (but better diagnostics)" (26 lines) at nopaste.snit.ch/24241 02:22
02:23 ruoso left
dukeleto kid51: can you paste the actual output of the commands that those tests are running? 02:26
kid51: perl mk_language_shell.pl test_lang; cd test_lang; parrot setup.pir build; parrot setup.pir test 02:27
kid51: the output of that on your machine would be very helpful
kid51: i am smoking it on my darwinppc box now, which uses --prefix. Let's see what happens 02:29
kid51: the parrot you run in the above command should be the currently compiled one, not the system parrot, if it exists 02:30
kid51 bash: cd: test_lang: No such file or directory
dukeleto kid51: something to watch out for
kid51: what did the output of mk_language_shell say? it is supposed to create that directory 02:31
kid51: your test report says it creates the directory, but the building + testing fails
kid51 What directory is mk_language_shell.pl in? 02:33
dukeleto kid51: tools/dev 02:34
kid51: perl tools/dev/mk_language_shell.pl test_lang; cd test_lang; parrot setup.pir build; parrot setup.pir test 02:35
02:35 janus left 02:36 ruoso joined
nopaste "kid51" at 192.168.1.3 pasted "tools/dev/mk_language_shell.pl" (28 lines) at nopaste.snit.ch/24243 02:38
dukeleto kid51: you have an installed parrot 02:40
PackFile_unpack: This Parrot cannot read bytecode files with version 5.4.
kid51: that means it is finding an old version of parrot
kid51: what happens when you do "which parrot" ? 02:41
kid51: i just reported a PASS on darwinppc on smolder
kid51: i will see if I can tweak the test so that it won't find installed parrots 02:42
nopaste "kid51" at 192.168.1.3 pasted "Output (from Linux/i386) once I've accounted for the cd" (37 lines) at nopaste.snit.ch/24245 02:43
dukeleto kid51: hmmm. do you have an installed parrot in the build dir ?
kid51: that paste is very interesting. You should add it to the TT 02:45
kid51 no installed parrots 02:46
bbl
02:46 kid51 left
dukeleto Looks like making a new language depends on install_config.o being around, which isn't built unless "make install" is called 02:52
All my machines install into the build dir before testing, so it doesn't happen on them.
03:00 janus joined 03:53 tadzik left 04:13 kid51 joined
kid51 dukeleto: That sounds like a good diagnosis. 04:14
But no tests run during 'make test' should depend on a parrot having been installed anywhere.
Created TT #1823 for this. 04:29
dukeleto kid51: these are special kinds of tests 04:35
kid51: i am thinking these tests should have a special make target
kid51: that has a dependency on install_config.o or whatever it is
kid51: creating languages currently requires an installed parrot. I am not sure how to get around that, but asking on parrot-dev could be useful 04:36
kid51: it is possible we can create that .o file without running install, and then maybe it will work. Or fail for a different reason anyway
04:37 ruoso left
kid51 I have a feeling that if we are going to include code in the repo that is only intended to be run post-install, then both that code and its associated tests ought to go into special directories. 04:38
e.g. tools/postinstall/, t/postinstall/
"creating languages currently requires an installed parrot. I am not sure how to get around that," -- but why would we want to get around that? That seems quite plausible. 04:39
dukeleto kid51: no, I don't think it is plausible. It is a limitation. 04:50
kid51: creating special directories means the tests will never get run
kid51: it should either be fixed to Do The Right Thing, or have a special make target. 04:51
kid51 dukeleto: agreed, but that doesn't rule out the existence of special directories.
Not too long ago, I had a ticket that repositioned quite a few programs under tools/ 04:52
... hoping to get more logical groupings.
In fact, constructing special 'make' targets is probably easier when all the important code is grouped in special locations. 04:53
bacek_at_work dukeleto, make src/install_config.o
dukeleto bacek_at_work: thanks. it looks to be a single compilation directive 04:54
bacek_at_work: any reason not to make that part of the normal build process?
kid51 dukeleto: I can confirm that if (a) I configure with a --prefix=/somedir and (b) call 'make install', mk_language_shell.t will PASS
dukeleto kid51: yes, it all comes down to making sure src/install_config.o is there before you run those tests 04:55
04:55 plobsing left
dukeleto kid51: we can create the object file without installing 04:55
kid51: are there any guidelines for adding new make targets? 04:56
kid51 dukeleto: No. 04:57
dukeleto kid51: we have some options : the tests can see if install_config.o exists, and SKIP if it doesn't. Or we can make install_config.o get created in a normal build.
kid51: do you have a preference?
bacek_at_work: do you have a pref for always creating isntall_config.o vs. making the tests SKIP if it doesn't exist?
kid51 dukeleto: my preference is to SKIP 04:58
dukeleto kid51: any reason why?
kid51 Because it's starting to sound like we're creating install_config.o *solely* for the purpose of getting these tests to pass. 04:59
smells bass-ackwards.
dukeleto kid51: no, it would be so that mk_language_shell and create_language could be used without installing parrot 05:00
kid51 Adding the SKIP allows you -- who always install -- to get the PASSes you want ...
dukeleto kid51: the tests passing is a consequence of that
05:00 theory joined
dukeleto kid51: always creating install_config.o makes it so that our tools work without installing parrot. SKIPPing means keeping the requirement that parrot be installed to create a HLL 05:01
do we want that limitation, even if it is easy to fix?
bacek_at_work I vote for always build installed_config.o
kid51 But does it make sense for *these two tools* to be able to work in the absence of an installed parrot? 05:02
dukeleto kid51: yes, because all the other tools don't require an installed parrot. They are the odd ones out. 05:03
bacek_at_work kid51, erm. Why not?
dukeleto this limitation only exists for these two scripts
kid51: consistency guides us to make them work on un-installed parrots
kid51 Understand, I don't have a hard-and-fast opinion here.
I'm trying to play devil's advocate. 05:04
I can see an argument being made: All the scripts in tools/dev/ function "pre-parrot". 05:05
These tools sound more like "post-parrot".
dukeleto kid51: devil's advocate is useful :)
kid51 I have never used any of the language creation programs myself. 05:06
But it seems to me that you wouldn't use them unless and until you've already got a parrot executable.
In which case, *testing* these programs can plausibly deferred to a post-"make install" time. 05:07
Under what circumstances would a language implementor want to run those programs in the absence of an installed parrot? 05:09
dukeleto kid51: needing to install parrot to run those 2 scripts is an arbitrary limitation 05:10
kid51 dukeleto: That doesn't answer my question.
dukeleto kid51: i want to create a new HLL without installing parrot. That is the use case. 05:11
kid51 In fact, it's *not* an arbitrary limitation if there is no point in running them before parrot is installed.
dukeleto kid51: there is no point in requring an installed parrot. The burden of proof lies on needing to install, since no other tool requires it. 05:12
kid51 dukeleto: Well, as I said, I've never created an HLL either before or after install.
It's just that I can only imagine doing it after install.
But why don't you (a) post in the ticket; (b) raise on #parrotsketch 05:13
dukeleto kid51: i have wanted to do it without installing, but it doesn't work, because of this exact problem
bacek_at_work: what it the best way to make sure install_config.o gets created in a normal make ?
bacek_at_work: i have considered adding it to O_FILES, but then it gets added to the static and dynamic libs, which seems unnecessary. 05:14
bacek_at_work dukeleto, I'm not an expert in our makefiles. Add to "all" target somewhere in config/gen/makefiles/root.in
kid51 dukeleto: This adds one more file to be installed. But didn't someone on parrot-dev today say, "+1 to lightening our load, so we can deploy to embedded/mobile devices"? 05:17
Hey, that was ... you!
dukeleto kid51: .o files don't get installed 05:18
kid51 What happens to them? What are they for, then? 05:19
dukeleto kid51: they are object files, used in linking 05:21
kid51: actually, they are used in compilation
kid51: you can compile N *.c files into *.o files, then compile them all together later
kid51: they are kind of like temporary storage for the compiler 05:22
kid51: the stage between source and executable
kid51: they never get installed
05:23 theory left
kid51 Well, I recommend posting in the TT. 05:23
bacek_at_work dukeleto, we shouldn't add installed_config.o to O_FILES. Just independent target.
dukeleto bacek_at_work: yes, i agree. 05:24
kid51 dukeleto: My preference for you right now would be to SKIP those tests, post in the TT, solicit comment for a few days, then implement the change in make targets and remove the SKIPs. 05:26
That way, you've argued your case in the appropriate venue, given people an opportunity to comment, and implemented your plan per the case you argued. 05:27
dukeleto kid51: that seems like a lot of extra work 05:28
kid51: like i said, the burden of proof lies in the other direction
kid51 dukeleto: I disagree. 05:29
Until recently, no one cared (afaict) where those tools worked in the absence of installed parrot or not. 05:30
You're the one who's saying "They should work in absence of installed parrot." 05:31
"And to do so, we have to change config/gen/makefiles/root.in"
dukeleto kid51: well, I did. So did cotto++. That is why we wrote tests for them.
kid51 Where did you make that case?
dukeleto kid51: is there a moratoriam on changing that file? Do I have to sing a special song? I don't understand the ceremony. 05:32
kid51 I may not have seen it.
dukeleto kid51: i meant that we cared that the tools *worked at all*
what exactly is your concern with what could go wrong? 05:36
kid51 I don't have specific concerns. I simply think it's a good idea to give other people notice when you're making a change. 05:37
dukeleto kid51: if i thought anybody would even notice or care, I would. But I think this is just going to make something work and most people won't even notice. 05:38
kid51 Go ahead, then.
dukeleto it hath slithered into the intertubes. 05:39
kid51: please svn up and confirm that the latest commit fixes this issue 05:44
kid51: i am running the test on a non-installed parrot on darwinppc now
kid51: one thing to learn about this: Most smoke reports from users will be from non-installed parrots, since that is what our wiki says 05:46
kid51: if we want people to smoke with installed parrots, we need to update the wiki
dalek rrot: r49502 | dukeleto++ | trunk/config/gen/makefiles/root.in:
[t][TT#1823] Always create src/install_config.o, so that mk_language_shell and create_language can be used without installing Parrot
 05:47
dukeleto I just got some very good news for Parrot + Perl 6. 05:50
kid51 dukeleto: Confirmed on linux/i386. I don't think this was an OS issue, but the verification on Darwin will take longer 05:51
dukeleto: Yes, I think we've always assumed that smokes are from non-installed. 05:52
dukeleto kid51: i am about to submit a smoke report from darwinppc
kid51 After all, 'smoke' is just an extension to 'test' ... and 'test' does not depend on 'install'
dukeleto kid51: yes. I learned to install from the build dir from chromatic++. It is useful if you want to tell Rakudo to use a specific version of parrot, but you don't want to install it system-wide 05:53
kid51: smolder.parrot.org/app/projects/rep...etails/538 PASS from darwinpcc un-installed parrot 05:54
kid51: i will give you the pleasure of closing the ticket
kid51 smolder.parrot.org/app/projects/rep...etails/537 was mine from linux
05:56 wagle left 05:57 wagle joined 06:13 uniejo joined 06:15 kid51 left 06:23 jjore left
dukeleto anybody know anything about buildbot? 06:30
bacek_at_work is it still alive?
06:31 jsut joined
bacek_at_work aloha, taptinder? 06:31
aloha bacek_at_work: I give up.
dukeleto bacek_at_work: yep. lots of peeps seem to use it. I am thinking Parrot should to.
bacek_at_work aloha, taptinder is continues integration tool - taptinder.org . For Parrot project running on tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot. 06:32
aloha bacek_at_work: Okay.
dukeleto taptinder?
aloha, taptinder?
aloha dukeleto: taptinder is continues integration tool - taptinder.org . For Parrot project running on tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
bacek_at_work aloha, ttbot?
aloha bacek_at_work: Dunno.
bacek_at_work aloha, ttbot is see taptinder
aloha bacek_at_work: Okay.
bacek_at_work aloha, ttbot?
aloha bacek_at_work: ttbot is see taptinder
bacek_at_work seen mj41 06:33
aloha mj41 was last seen in #perl6 2 days 11 hours ago joining the channel.
dalek rrot: r49503 | dukeleto++ | trunk/NEWS:
[doc] Add note to NEWS about scripts no longer requiring an installed parrot
bacek_at_work aloha, msg mj41 looks like taptinder is down...
aloha bacek_at_work: OK. I'll deliver the message.
dukeleto aloha, coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/ 06:36
06:36 jsut_ left
aloha dukeleto: Okay. 06:36
dukeleto bacek_at_work: i can get to TapTinder 06:37
06:38 jjore joined
bacek_at_work dukeleto, hmm... Looks like Chrome is less permissive in HTTP protocol errors 06:43
06:43 cosimo left, jjore left 06:44 cosimo joined
bacek_at_work msg mj41 TapTinder sends duplicated Content-Length headers. It confuses Google Chrome (at least) 06:44
aloha OK. I'll deliver the message.
06:45 jjore joined 06:54 cosimo left 07:17 jsut_ joined 07:22 jsut left 07:25 cosimo joined 07:41 bacek joined
bacek ~~ 08:11
Tene !! 08:15
bacek ??
moritz rakudo: say True ?? "yes" !! "no" 08:20
p6eval rakudo 5bdbd4: OUTPUTĀ«yesā¤Ā»
moritz rakudo: say True ~~ 1 ?? "yes" !! "no"
p6eval rakudo 5bdbd4: OUTPUTĀ«yesā¤Ā»
moritz now all three operators are in :-)
dalek rrot: r49504 | bacek++ | branches/generational_gc/lib/Parrot/Vtable.pm:
Add VTABLE_IS_WRITE_BARRIER_FLAG.
 08:21
rrot: r49505 | bacek++ | branches/generational_gc (2 files):
Add VTABLE_IS_WRITE_BARRIER_FLAG to avoid wrong sealing of already
rrot: r49506 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Add couple of functions for debugging purpose.
rrot: r49507 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Avoid propagating already propagated objects.
rrot: r49508 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
sweep pool in separate phase
08:28 jsut joined 08:33 jsut_ left 09:01 bacek left
dalek rrot: r49509 | bacek++ | branches/generational_gc/src/string/api.c:
Hack string api to clear gengc flags for new strings.
 09:07
rrot: r49510 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
"Remark" objects from current generation during propagate. We do need to
rrot: r49511 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Special handling for oldest generation.
rrot: r49512 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Temporary turn on dumb mode for propagating objects
09:25 mikehh joined 10:16 contingencyplan left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#542) fulltest) at r49512 - Kubuntu 10.10 RC amd64 (g++-4.5) 10:17
ha, it's no longer the RC 10:18
10:34 fperrad joined 12:30 smash left 12:51 jsut_ joined, jsut left 13:20 Patterner left 13:29 theory joined 13:30 Psyche^ joined, Psyche^ is now known as Patterner 13:34 theory left, plobsing joined 13:54 ruoso joined 14:01 Andy left 14:09 uniejo left 14:39 theory joined 14:42 dmalcolm joined 14:44 silug left, fperrad left 15:37 tadzik joined 15:38 contingencyplan joined 15:41 bluescreen left 15:42 bluescreen joined 15:48 plobsing left 16:05 theory left 16:29 davidfetter left 16:33 Andy joined 16:50 silug joined 17:00 x3nU left 17:08 silug left
dukeleto aloha, msg darbelo can you tell me why the String.reverse VTABLE was removed? 17:51
aloha dukeleto: OK. I'll deliver the message.
dukeleto Does anybody know why String.reverse was removed in r46290 ? 17:57
It seems to have been part of the "immutable strings" stuff, but why not make reverse return a reversed copy? 18:01
are people supposed to use a StringBuilder now?
that doesn't have reverse either. But StringIterator looks like it can go in reverse. 18:05
18:06 jsut_ left 18:08 tadzik left 18:09 jan left 18:14 jan joined 18:27 AzureStone left 18:32 AzureStone joined 18:34 hudnix joined 18:38 M_o_C joined
dalek rrot: r49513 | nwellnhof++ | trunk (17 files):
[t] Convert most unicode:"" string literals to utf8:""
 18:50
cotto ~~ 18:54
dukeleto hola 18:55
cotto: how goes it up there?
dukeleto doesn't get to say "up there" to many people ;)
cotto It's a good day. 18:56
except that one of Rakudo's tests has been taking way too long to run
dukeleto cotto: I keep running into tests that go in ifinite loops. In multiple projects. It is that kind of week. 18:57
cotto fun 18:58
18:58 M_o_C left
dukeleto cotto: in other news, I got access to a compile farm for Parrot. 19:00
19:00 M_o_C joined
cotto dukeleto, v. nice 19:00
dukeleto cotto: this is a passing smolder_coretest from a PlayStation 3 : smolder.parrot.org/app/projects/rep...etails/540 19:02
cotto: sadly, the full test suite goes into an infinite loop. Yay, bugs!
cotto what's in the farm?
dukeleto cotto: it is the GCC Compile Farm : gcc.gnu.org/wiki/CompileFarm 19:03
cotto: lots of x86 with some sparc, arm and mips thrown in
cotto: i want to setup taptinder and/or buildbot on them 19:04
cotto Wow. Nice job. 19:05
How'd you manage that?
19:06 davidfetter joined
dalek rrot: r49514 | nwellnhof++ | trunk/src (2 files):
[src] Show string encoding in pbc_dump and pbc_disassemble
 19:06
dukeleto cotto: It was extremely complicated. I asked for an account. 19:07
aloha, msg nwellnhof tests for r49514 would grealy be appreciated 19:08
aloha dukeleto: OK. I'll deliver the message.
cotto That's all? I'd think they'd be pretty selective about allowing access to a wide variety of hardware like that. 19:09
dukeleto cotto: I had to prove that I was a contributor to Parrot and Perl 6, so I guess that was the hard part :) 19:11
Who has access to modify trac.ini for trac.parrot.org ? 19:12
I would like to add TapTinder to the top navbar, similar to what is described here: buildbot.net/trac/wiki/BuildbotAndTrac
19:12 M_o_C left
cotto If Coke can't do it, it'll probably require osuosl 19:12
Having the navadd plugin will make adding a github link too. 19:13
dukeleto Yes, we need that too.
19:13 silug joined
dukeleto Trac needs to integrate better with all our tools 19:13
Looks like we have a failure on optimized parrots on darwinppc. A wonderful -0 vs 0 bug 19:21
smolder.parrot.org/app/projects/rep...etails/550 19:22
19:29 luben left 19:32 davidfetter left 19:53 davidfetter joined
dukeleto bangs some pots and pans. SURE IS QUIET IN HERE. 19:54
19:59 plobsing joined
davidfetter bangs back 20:05
moritz dukeleto++ # GCC build farm 20:06
cotto dukeleto++
At the very least, we should have a buildbot running on the platforms we list as supported. 20:07
dukeleto cotto: yeah, I don't care whether it is TapTinder or BuildBot, but we should have something running on all of our supported platforms 20:09
cotto: i think the farm has every version of gcc ever as well, so it can be useful for running tests the bleading edge of gcc too, if we want 20:10
moritz: thanks. Hopefully we can do very cool things with the farm.
cotto in case andy++ loses interest in that sort of thing
Andy I'm not interested, other than just disseminating news. 20:16
OH, I see what you mean, bleeding edge GCC
yeah, and I only futz with it monthly at best.
cotto yes
often enough
Andy When I'm stymied on other projects.
cotto gcc releases don't happen that often 20:17
20:50 bacek joined
cotto I see the RTEMS guys are also using the gcc build farm. 21:02
21:04 davidfetter left
Andy RTEMS? 21:07
ewww! OS! OS!
sorear ewww? 21:08
we had a gsoc for the RTEMS port
Andy but to work on writing an OS?
That's so close to the metal!
I break out!
21:11 brianwisti joined
cotto aloha, seen bubaflub 21:12
aloha cotto: Sorry, I haven't seen bubaflub.
21:14 nwellnhof joined
nwellnhof dukeleto: ping 21:14
cotto What happened to his effort to get us working with a separate build dir? 21:16
We need to merge that. It'll go stale pretty quickly.
Hmm. I don't see an svn branch. 21:17
I'd hate to lose that work.
dukeleto, ping 21:20
21:24 theory joined 21:25 davidfetter joined
dukeleto cotto: pong 21:29
nwellnhof: pong
cotto: he has a github repo for his work 21:30
cotto dukeleto, where does bubaflub's gsoc code live?
atrodo dukeleto is popular
dukeleto atrodo: that isn't always a good thing
nwellnhof dukeleto: i'm about to commit some tests for r49514
cotto dukeleto++ I don't usually get an answer before I ask the question. 21:31
dukeleto atrodo: what are the next steps for your lorito stuff?
cotto: bubaflub started a new job recently, so I think he has been really busy with that
cotto chromatic said he had some notes. I need to get him to put them online somewhere. 21:32
dukeleto cotto: also, we might be able to setup Parrot+RTEMS testing on the gcc compile farm, since RTEMS takes care of the hard work. Could be pretty awesome.
cotto I was thinking something along those lines.
dukeleto cotto: i think we need to break bubaflub++'s code into small features that can be added incrementally to core
cotto sounds tricky
or it would, if your git-fu weren't as strong as it is ;) 21:33
dukeleto cotto: yes, it is. Some parts could be easy, like adding new configure steps to figure things out, but some features are huge
cotto: i don't mean using his commits, but looking at things in a different way
cotto: Parrot+RTEMS consists of fixing many things in our build system 21:34
atrodo dukeleto> Docs and Tests. That, and time. But I squeeze in a little bit when I can
dukeleto cotto: so I am more aimed at adding a few small features to our config system that will enable having a seperate build dir
cotto: that is the first step to Parrot+RTEMS
cotto: and there is a parrot branch for that
cotto ok
21:35 bacek left
dukeleto cotto: github.com/parrot/parrot/compare/ma...dir_option 21:35
21:36 davidfetter left
dukeleto cotto: so we need to put the things that bubaflub worked on relating to a builddir into that branch 21:36
cotto From my pov, the next step for Lorito is filling out the gaps in trac.parrot.org/parrot/wiki/LoritoRoadmap (and the pages it links to). 21:39
dalek rrot: r49515 | nwellnhof++ | trunk/t/tools (2 files):
[t] Add tests for r49514
 21:40
dukeleto cotto: yeah. We need a Lorita migration plan, similar to our GitMigration 21:41
nwellnhof++ # yay, tests!
Lorito, even. I guess Lorita is her sister 21:42
brianwisti And now I'm craving Doritos. That can't be good. 21:43
atrodo Doritos made out of Loritos?
cotto question: What if we're building skynet? 21:44
It's remote, but I think it'd be a good idea to prepare for that possibiliy.
possibility, even
brianwisti answer: skynet will probably be nicer than in the movies. 21:45
atrodo and easier to hack
or crash
brianwisti "Hey guys! Let's make another language! Don't make me break out the T-1000's."
cotto Parrot: a framework for allowing dynamic languages to write themselves 21:46
atrodo That is the logical next step 21:47
dukeleto I think we need more references to Skynet in the Parrot codebase.. 21:48
atrodo HCF: Halt, and Catch any possible skynet instance on fire
21:54 bacek joined 22:06 bacek left
cotto Lorito suggestion: use 64-bit values for INSP values in Lorito like Firefox: blog.mozilla.com/rob-sayre/2010/08/...sentation/ 22:09
Hmmm: en.wikipedia.org/wiki/Narcissus_%28..._engine%29 22:14
sorear wow, those comments are horrible 22:17
dukeleto cotto: yes, i have looked at it a while ago. Very interesting
cotto: ieee754-2008 actually defines things called "NaN payloads". NaN boxing seems to be a hackish approximation of that 22:19
cotto That idea may be less attractive when we don't expect nearly as many floats as a js engine would. 22:27
sorear That idea is definitely less attractive when we don't need to treat floats and objects interchangably as a js engine must. 22:29
dukeleto LuaJIT uses NaN-boxing, but calls it NaN-tagging: article.gmane.org/gmane.comp.lang.l...eral/58908 22:32
plobsing the idea is less attractive when you can distinguish INSP, sure. but can we, at an HLL level, really make that distinction consistently? 22:33
does rakudo, for example, use unboxed ints where it can? 22:34
and can it anywhere?
(autopromoting and such)
cotto Perl 6 allows it but I don't think rakudo implements that part of the spec. 22:35
22:36 theory left
plobsing Perl 6 allows Int to map to INTVAL? I thought they had to be BigInt 22:36
cotto I think Perl 6 has a native int type. 22:37
22:37 brianwisti left
cotto the "int" type and other lower-case type names are listed in S02 as being native types 22:39
dukeleto That luaJIT link is full of good ideas. 22:41
plobsing sure. But INTVAL/FLOATVAL registers are not yet sufficient for representing these.
sorear Perl 6 says that Int is an object type.
plobsing also, it would be nice if users didn't *have* to use those types just to get decent performance
cotto looks and hopes to steal
22:41 preflex left
sorear I'm not sure it's possible for us to escape that 22:42
cotto is thoroughly overloaded 22:43
That's a lot. 22:45
bacek_at_work ~~ 23:01
23:02 kid51 joined 23:04 preflex joined
cotto hi bacek_at_work 23:05
bacek_at_work aloha, cotto
kid51 msg dukeleto At r49515 I am not getting the error you are in t/op/number.t on Darwin/PPC -- but I don't configure with --optimize. 23:08
aloha OK. I'll deliver the message.
nopaste "bluescreen" at 192.168.1.3 pasted "Possible patch for tt1821" (84 lines) at nopaste.snit.ch/24296 23:27
bluescreen dukeleto: Could you please take a look at the patch at nopaste? 23:30
kid51 OTOH: I'm getting completely new test failures on Darwin/PPC subsequent to r49513 thru 49515. See: smolder.parrot.org/app/projects/rep...etails/552 23:32
nopaste "kid51" at 192.168.1.3 pasted "pbc_disassemble.t, pbc_dump.t: new failures on Darwin/PPC subsequent to r49513-49515" (56 lines) at nopaste.snit.ch/24297 23:34
nwellnhof kid51: seems that some of the tests i added require ICU 23:35
kid51 msg nwellnhof In r49513-49515, have you accounted for systems with no ICU installed?
aloha OK. I'll deliver the message.
kid51 Ah, we're thinking simultaneously :-) 23:36
IIRC we encountered a problem like this about 10 days ago.
bluescreen kid51: getting failure on the same tests in Linux/i386 23:37
kid51 bluescreen: do you have ICU installed there? (I'd guess not, but Configure.pl output should clarify) 23:38
bluescreen this is the error 'Parrot VM: Can't stat t/tools/pbc_dump.t.9.pbc, code 2.
23:41 dmalcolm left
dalek rrot: r49516 | nwellnhof++ | trunk/t/tools (2 files):
[t] Fix new tests with non-ICU builds
 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!