www.parrot.org | Prepare for 1.6.0: Improve test coverage for NameSpace and Continuation PMCs / Stability! / Port tests to PIR / Performance! / No more big branch merging until after 1.6.0
Set by moderator on 8 September 2009.
00:02 MoC joined 00:05 Andy joined 00:26 payload joined 00:29 kid51 joined 00:34 cotto joined 00:43 JimmyZ joined
Coke pmichaud: hio 00:43
00:47 cotto joined
kid51 build failure on Linux at r41243. 00:47
This is serious. 00:48
Have not had a build failure on Linux in many, many months.
nopaste "kid51" at 68.237.0.93 pasted "Build failure on Linux/i386 at r41243" (522 lines) at nopaste.snit.ch/17943 00:49
JimmyZ here parrot never can be a successful build :( 00:51
nopaste "kid51" at 70.85.31.226 pasted "svn diff . -r 41221:41243" (2218 lines) at nopaste.snit.ch/17944 00:53
darbelo NotFound: Ship it!
NotFound darbelo: I don't have an i386 system ATM to test it adequately 00:55
dalek TT #1003 created by NotFound++: Call an exited coroutine fails since some time 00:56
darbelo NotFound: Fine, make someone test it, and then ship it. People here can be so boring at times... 00:57
NotFound darbelo: I'll test it tomorrow morning 00:58
kid51 Note: On same box, at r41221 (20090911), I began to get this warning during 'make': 01:00
grep -n 'request for implicit conversion' *.txt
20090911.41221.parrot.txt:400:./src/pmc/unmanagedstruct.pmc:505: warning: request for implicit conversion from 'void *' to 'char *' not permitted in C++
More complete: 01:01
./src/pmc/unmanagedstruct.pmc: In function 'set_string':
./src/pmc/unmanagedstruct.pmc:505: warning: request for implicit conversion from 'void *' to 'char *' not permitted in C++
Bisecting; build was successful at r41231.
NotFound kid51: Have you made the realclean dance? 01:02
kid51 NotFound: Always do! 01:04
$ make realclean;svn up;perl Configure.pl --test --configure_trace
dalek rrot: r41244 | NotFound++ | trunk (3 files):
[core] signal when invoke is used for a yield operation, TT #1003
 01:06
01:07 nathanmccauley joined
darbelo kid51: Builds fine over here (amd64) 01:08
NotFound kid51: delete src/library.str and make
kid51: and take a look at your pc clock 01:09
kid51 What do you mean: look at your pc clock 01:10
NotFound Maybe the clock is failing and that confuses make
kid51 And why should I try deleting that file?
NotFound kid51: because your nopaste don't show its buiding 01:11
kid51 41239 built okay
NotFound And because the compiler shows a warning about CONST_STRING in library.c 01:12
kid51 Yes, all that stuff starting at line 303 of paste 17943 01:14
NotFound CONST_STRING is defined in the corresponding .str file
kid51 NotFound: that built 01:16
nopaste "kid51" at 70.85.31.226 pasted "Trying to debug by removing src/library.str" (809 lines) at nopaste.snit.ch/17945 01:17
NotFound kid51: strange 01:20
The problem, not the fix
kid51 Yes. I just did 'make realclean;svn up;perl Configure.pl;make --- and the build succeeded! (am now at 41244) 01:23
Am also building at r41242
On r41242, I got past src/library.c without all those warnings 01:25
There were certainly a lot of .pmc files modified today. 01:27
Did someone merge in another branch?
JimmyZ could someone take a look at TT #888? It broke after rXXXXX. 01:28
01:29 rdice joined
NotFound kid51: I think not, just lots of fixes 01:29
01:30 KatrinaTheLamia joined
kid51 JimmyZ: Has it been consistently broken in the past 6 weeks? Or did it "get fixed" for a while and then start breaking anew? 01:31
NotFound It might have broken because of assuming command line options are utf8 since some weeks ago 01:32
JimmyZ yes, It have a successful build, but I don't know when it broke.
s/have/had/ 01:33
NotFound JimmyZ: What platform, windows?
JimmyZ yes
kid51 suspects it may be similar to "whitespace in TEMP PATH" problem reported in trac.parrot.org/parrot/ticket/930
JimmyZ for TEMP PATH containning chinese user name. 01:34
01:35 sri joined
NotFound JimmyZ: at what point it fails? Can you attach a log of the build to the ticket? 01:37
kid51 7 months ago, in TT #326 (cited by JimmyZ in TT #888) rurban noted: "parrot does not accept wchar pathnames" 01:38
Is that still the case?
JimmyZ kid51: that's another issue.
not the same.
NotFound: wait
NotFound The problem is not that it doesn't accept them, is that it does not the correct things 01:39
JimmyZ TT#326 just was failed spec test. but TT #888 is a failure buid. 01:40
kid51 Is the problem reported in TT#326 Windows-specific or more general?
JimmyZ kid51: but the problem is the same. that is, for TEMP PATH containing chinese user name 01:41
kid51 JimmyZ At what revision have you most recently tried to 'make'? 01:42
NotFound kid51: I think the problem is general, is just more evident for windows users with non european locales
JimmyZ NotFound: It just throw a exception from string/api.c, line EXCEPTION_INVALID_STRING_REPRESENTATION, "Malformed string"); 01:43
kid51 NotFound: Sounds plausible.
JimmyZ NotFound: the temp fix for me is that, remove this EXCEPTION check. :( 01:44
kid51 JimmyZ: As NotFound suggested, I recommend you attach a log of your most recent build to #888
Along with a diff with your temporary fix.
JimmyZ ok. 01:45
NotFound I'll give up for today :O
kid51 It's weekend here, so not many eyeballs right now.
JimmyZ: Do you have access to any other OSes that you can try this on? 01:46
JimmyZ kid51: my temp fix is not a correct way.
kid51 JimmyZ: It doesn't have to be correct.
We're asking for it for diagnostic purposes. 01:47
Describe the extent to which it worked for you.
Perhaps that will give someone else a clue as to the correct fix.
JimmyZ kid51: yes, ubuntu. but windows also make a seccess build if I use engliash account on windows.
s/engliash/english/
kid51 Does it fail on Ubuntu if you have Chinese characters in a TEMP path? 01:48
01:49 sri_ joined
JimmyZ kid51: I don't know. 01:49
kid51 Why don't you give it a try? And then post your results in TT #888 as well. 01:50
NotFound: Thanks for your help earlier. Let's hope it's just a one-time weirdness. 01:51
01:51 jhelwig joined
kid51 Damn; Smolder down again within last 30 minutes. 01:52
JimmyZ have a build log to #888 01:53
kid51 JimmyZ: Let me ask a question that reflects my lack of (devel) experience on Windows. 01:54
JimmyZ kid51: go on ;) 01:56
kid51 I see from your paste that you're building Parrot on your F:\\ drive (partition?). But you were configuring on your local drive, and you are apparently set up to have processes look for tempdirs on your C: drive.
Would you get the same problem if you were configured to look for tempdirs on the F:\\ drive?
(I'm mostly grasping at straws here, but I figure asking questions can't hurt.) 01:57
JimmyZ kid51: no.
kid51 So, does the problem only occur when you are configuring and running 'make' from your C:\\ drive? 01:58
Also, can you post in ticket the SVN r number of that build? 01:59
JimmyZ kid51: changes TEMP to any path without chinese. It will be a success build. 02:00
yes, already, r40203
r40203 does the same. 02:01
kid51 Okay, while I don't have any bright ideas, let me make some suggestions:
1. make realclean;svn up; Then configure and build from most recent version.
JimmyZ yes.
kid51 2. Log all of the "Configure.pl' and 'make' output to a plain-text file and *attach* that file to TT 888. 02:02
JimmyZ that is, svn up && make realclean && perl Configure.pl && make.
kid51 Yes.
That way (a) we will know the problem is still current; and (b) we'll have much more data to examine. 02:03
I suspect that the underlying cause of this is the fact that most Parrot developers are in countries where utf8 suffices for things like paths. 02:04
So I can't promise any quick fix.
But it will be helpful to know what workarounds you have tried -- even if you believe they are not permanent fixes. 02:05
Also: include in ticket information on which version of Windows you are using (for both C drive and F drive) 02:06
JimmyZ since it broke, I had taken a look at which commit led to failure. but I can't find :(
kid51 You can do that when you find time. 02:07
I have a hunch that it was only accidentally "fixed" earlier.
Since I suspect we're fairly ignorant of these issues, I'm surprised it ever built at all! 02:08
JimmyZ kid51: I don't know, but I didn't see any commit that looks like a broken one. 02:09
02:13 cotto joined
nopaste "kid51" at 68.237.0.93 pasted "r41244: failures during 'make fulltest' on Linux/i386" (13 lines) at nopaste.snit.ch/17946 02:14
"kid51" at 68.237.0.93 pasted "JimmyZ: Re TT #888: Try bisecting both before and after these SVN revisions" (8 lines) at nopaste.snit.ch/17947 02:16
kid51 jdv79 ping 02:17
JimmyZ kid51: these build successful.
kid51 Okay, so we know that they were working the last time Simon was working on strings. 02:18
JimmyZ seems that it was after may, 2009 02:19
kid51 So, you could try bisecting after that point. 02:20
msg jdv79 Noted Smolder test failures in t/perl/Parrot_Docs.t which may have come from your box ... but I couldn't reproduce them on Linux/i386. 02:21
purl Message for jdv79 stored.
dalek rrot: r41245 | jkeenan++ | trunk/src/pmc/coroutine.pmc:
Correct codingstd error: space between C function and opening parenthesis.
 02:26
rrot: r41246 | jkeenan++ | trunk/MANIFEST:
Two recently added files were not added to MANIFEST, leading to manifest_tests failures; correcting.
TT #1004 created by jkeenan++: t/op/calling.t, t/pmc/sub.t failed at r41244 during 'make testj' 02:30
02:41 janus joined
dalek rkdown: 37bf6f5 | fperrad++ | t/Parrot/Test/Markdown.pm:
run parrot in current directory
 02:48
02:51 snarkyboojum joined
jdv79 kid51: sup? 02:56
purl somebody said sup was a console-based email client written in Ruby, supposedly better than mutt or at sup.rubyforge.org/
kid51 jdv79 left msg for you
jdv79 kid51: yeah, my fault. that test is sensitive to file mod 02:57
*mode. i fixed it. sorry.
any rakudo committers around? 02:59
kid51 Not I, said the cat.
03:27 quek left 03:28 quek joined
kid51 must sleep 03:30
purl $kid51->sleep(8 * 3600);
03:33 quek left 03:37 cotto joined 03:46 quek joined 03:55 Andy joined 04:13 dukeleto joined 04:35 nathanmccauley joined 04:51 payload joined 05:22 flh joined 06:07 kjeldahl joined 06:47 cotto joined
dalek rrot: r41247 | mikehh++ | trunk/tools/dev/vgp_darwin:
codetest/distro_tests failure - set svn properties
 06:53
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41247 - Ubuntu 9.04 amd64 07:03
partcl r731 builds on parrot r41247 - make test PASS - Ubuntu 9.04 amd64 07:11
07:12 markmont joined, dukeleto joined, Andy joined 07:19 petdance joined
mikehh rakudo (0f1edeb) builds on parrot r41247 - make test PASS / make spectest (up to 28222) FAIL - Ubuntu 9.04 amd64 07:25
rakudo - t/spec/S12-introspection/walk.rakudo FAILs and t/spec/S03-operators/arith.rakudo - TODO passed: 120, 131-132
KatrinaTheLamia btw... what was the email to request a shell account...
it is getting annoying running my current method of xchat >.>
meh, guess it is time to see if I actually have logs in Xchat 07:30
mikehh decnum_dynpmcs r181 builds on parrot r41247 - make test PASS - Ubuntu 9.04 amd64 07:31
07:40 Tene joined 07:56 cotto joined
cotto is it still ok to make non-trivial changes or should those wait until after the release? 08:00
Coke, ping 08:13
413/8 08:30
purl 51.625
cotto 8/1.3
purl 6.15384615384615
cotto msg Coke it'd be helpful if you could give me a specific example where the profiling runcore gets the filename wrong. 08:33
purl Message for coke stored.
08:36 chromatic joined
dalek rrot: r41248 | allison++ | branches/pcc_arg_unify/t/pmc/resizablestringarray.t:
[pcc] Pop the exception handler when the anticipated exception has been
 08:38
cotto night 08:43
08:45 proclus joined
dalek rrot: r41249 | chromatic++ | trunk/src/ops/core.ops:
[ops] Replaced some dodgy constructs (direct VTABLE execution?) with cleaner
 09:01
nopaste "flh" at 88.160.47.207 pasted "Hash equality problem" (30 lines) at nopaste.snit.ch/17948 09:13
flh I've just pasted a simple example where "is_equal" between two Hash PMCs fail 09:14
am I asking too much from this method, or does this qualify as a bug?
nopaste "chromatic" at 72.87.39.97 pasted "Hash PMC is equal fix" (15 lines) at nopaste.snit.ch/17949 09:17
chromatic Try that, flh.
chromatic sleeps 09:18
flh testing it right now, but the mmd_dispatch call doesn't cause such trouble for a ResizablePMCArray
your patch makes my example work 09:19
09:33 quek left 09:34 MoC joined
nopaste "proclus" at 88.231.86.115 pasted "how can I incorporate actions into this small PGE example?" (17 lines) at nopaste.snit.ch/17950 10:33
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41249 - Ubuntu 9.04 amd64 10:38
10:46 Whiteknight joined
Whiteknight good morning #parrot 10:49
proclus good morning! 10:51
purl And good moroning to you, proclus.
mikehh rakudo (0f1edeb) builds on parrot r41249 - make test PASS / make spectest (up to 28223) FAIL - Ubuntu 9.04 amd64 10:53
rakudo - t/spec/S12-introspection/walk.rakudo FAILs and t/spec/S03-operators/arith.rakudo - TODO passed: 120, 131-132
partcl r731 builds on parrot r41249 - make test PASS - Ubuntu 9.04 amd64 10:57
decnum_dynpmcs r181 builds on parrot r41249 - make test PASS - Ubuntu 9.04 amd64
Whiteknight purl msg dukeleto I don't know anything about 757. I'm not even really sure why I became the owner of that ticket. 11:04
purl Message for dukeleto stored.
11:14 cono joined
dalek rrot: r41250 | NotFound++ | trunk/src (2 files):
[core] die cleanly when failing to allocate executable memory
 11:26
11:36 bacek joined
Whiteknight NotFound: ping 11:39
NotFound pong 11:40
Whiteknight I want to start planning a fix for this inferior runloops problem, and then create a branch to do it 11:41
If we can plan out a fix I think we can implement it shortly after the release
NotFound Whiteknight: for the exception handling, or in general? 11:42
Whiteknight I was thinking about the specific case of exception handlinger
NotFound Ah, good
Whiteknight I don't have a clear enough understanding of other problems associated with it 11:43
NotFound Maybe there is none, that's why I asked. When we solve, or at least clearly know the problems, we'll be able to know if there are others. 11:44
cognominal can someone look why parrot does not compile on Snow Leopard, it seems that the config executes code for i386 instead of x86_64 in config/auto/cpu? 11:45
0 test_56279 \t0x0000000100000ee6 Parrot_memcpy_aligned_mmx_code + 6 11:48
Whiteknight are any of our developers even on snow leopard?
bacek o hai 11:49
cognominal I don't know anything of the config but it seems the somehow it is addressed has a 32 bit architecture... 11:50
bb in a hour&
is there a way I can add my snow leopard box on your smoke system? 11:51
11:53 TiMBuS joined
Whiteknight NotFound: I think we associate every ExceptionHandler with a runloop id. The scheduler will only find a handler if it is in the correct runloop. 11:54
NotFound: We can have an extra slot inside the interpreter struct to hold an unhandled Exception PMC. when a runloop returns, such as in runops_int we can check for that PMC and rethrow if it exists 11:55
bacek Whiteknight: just put RPA of exception handlers into Context
Every Context has parent_ctx.
Or I missed something obvious? 11:56
Whiteknight bacek: that's reasonable too. Would require completely changing the way exception handlers are stored
bacek: it's not the issue of finding the exception handler, it's making sure we execute it in the correct loop
bacek Whiteknight: it's encapsulated into proper API. Just change couple of functions
NotFound Whiteknight: I think the problem is moe complex. We can't exit the current runloop to handle because that way we lost the way for resuming.
Whiteknight bacek: you're right, it probably is that easy 11:57
bacek Isn't "correct loop" equals to "correct context"?
Whiteknight NotFound: we need to exit the runloop because handlers are just labels, and we end up with nested runloops
bacek: no
NotFound bacek: correct loop is mainly a C stack business. 11:58
bacek ouch...
Why do we have to fight with "C stack" in CPS style VM?
Whiteknight NotFound: if we need to resume, we keep the context information from the inner runloop and create a new runloop with that context to continue 11:59
actually, that won't work either
NotFound Whiteknight: but we lose the C stack
Whiteknight right, I just thought about that
NotFound bacek: because vtable calls, for example, are C calls. 12:00
bacek NotFound: not always... And I hope with Lorito they never will.
NotFound If you have a vtable override, the runloop calls the vtable function, which start a new runloop to run the override 12:01
Whiteknight NotFound: The only way forward may be to make exceptions from nested runloops unresumable
12:01 joeri joined
NotFound Whiteknight: that will be highly inconsistent. Will be better to not have resumable exceptions at all. 12:02
Well, actually we are highly inconsistent anyway X-) 12:03
Whiteknight NotFound: The thing I don't like about exceptionhandlers is that they are labels and not separate subroutines
NotFound Exceptions thrown from C are not resumable, and there are lots of them
Whiteknight If they were separate subroutines, we could resume from them more easily. But since they are labels in existing subroutines we become dependant on the context of that subroutine to execute them 12:04
and we have opcodes now for accessing lexical variables up the call chain, so we could still access values from the caller's context 12:05
NotFound Whiteknight: Maybe we'll be able to add a new type of exception handler that works that way, without interfering with the current one, to test that way. 12:06
Whiteknight NotFound: If we did that, we could make subroutine-based handlers resumable, but other handlers not resumable
dalek TT #1005 created by flh++: Use VTABLE_is_equal instead of MMD in Hash and ResizablePMCArray 12:07
NotFound Whiteknight: the lexical problem can be adressed other way: put context and lexical information in the exception object and look for it in the handler when needed.
Whiteknight yes, that would be fine too 12:08
NotFound Whiteknight: BTW, did we have some good examples of resuming in exception handlers? 12:09
Whiteknight none that I have ever seen 12:10
12:14 quek joined 12:19 darbelo joined
cognominal apparently things have been improved these last two days, parrot and rakudo compile, I have just the ennuying pop-up when the mmx test crashes. that's the mac way to propose to send crash to Apple. 12:21
I just did not want to go back to my old linux box to do rakudo stuff 12:22
12:24 fperrad joined
cognominal salut fperrad 12:26
fperrad cognominal, salut Steph 12:27
cognominal well, that would be stef, my old unix login. 12:33
12:49 whoppix joined 12:50 tetragon joined 12:51 diakopter joined, Eevee joined 13:05 kid51 joined
kid51 msg bacek Why did you close trac.parrot.org/parrot/ticket/983 without addressing the question of the tests failing under 'make testj'? 13:11
purl Message for bacek stored.
dalek TT #983 reopened by jkeenan++: JIT code incorrectly access registers 13:18
13:28 payload joined 13:42 quek left 13:47 tetragon joined 14:20 tetragon joined 14:36 nathanmccauley joined 14:40 bacek joined
bacek kid51: ping 14:46
14:46 Psyche^ joined 14:50 jan joined
Coke msg cotto; here's an example: 1,871,876 runtime/tcllib.pir:Grammar;term [] 14:53
purl Sorry, I've never seen cotto; before.
Coke msg cotto here's an example: 1,871,876 runtime/tcllib.pir:Grammar;term []
purl Message for cotto stored.
Coke msg cotto also 1,871,876 runtime/tcllib.pir:Grammar;term []
purl Message for cotto stored.
Coke whoops.
msg cotto (whoops. also: ) 1,856,960 runtime/builtin/dict.pir:Grammar;_braced_word_past []
purl Message for cotto stored.
14:59 JimmyZ joined 15:11 Zak joined 15:20 nathanmccauley joined 15:22 mtk left 15:42 bacek joined 15:52 mokurai joined 15:57 Zak joined 16:00 ash_ joined 16:33 cotto joined
cotto good morning 16:39
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
cotto Coke, ping 16:40
dalek rrot: r41251 | NotFound++ | trunk/tools/build/nativecall.pl:
[nci] pass NULL for PMCNULL in 'p' signatures
 16:43
NotFound mysqltest works again :) 16:53
dalek rrot: r41252 | NotFound++ | trunk/examples/nci/mysqltest.pir:
[examples] skip the step still not working in mysqltest
 17:00
cotto msg Coke It'd also be helpful if you could show me how to reproduce those examples so I can see when they're working properly again. 17:04
purl Message for coke stored.
17:04 chromatic joined 17:21 theory joined
japhb pmichaud, ping 17:38
Actually, might as well go async ...
pmichaud, any progress on NQP object attribute declaration this week?
NotFound t/spec/S03-operators/arith.rakudo TODO passed: 120, 131-132 17:49
moritz NotFound: that's known, and partially platform dependant 17:50
17:52 zak_ joined 18:03 davidfetter joined
dalek rrot: r41253 | NotFound++ | trunk (3 files):
[pmc] applied patch from TT #1005 (flh++) with test for RPA and modified FPA and RPA to inherit is_equal vtable function
 18:45
19:05 nathanmccauley_ joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41253 - Ubuntu 9.04 amd64 19:06
partcl r731 builds on parrot r41253 - make test PASS - Ubuntu 9.04 amd64 19:10
decnum_dynpmcs r181 builds on parrot r41253 - make test PASS - Ubuntu 9.04 amd64 19:15
rakudo (0f1edeb) builds on parrot r41253 - make test PASS / make spectest (up to 28234) FAIL (1 test) - Ubuntu 9.04 amd64
rakudo - t/spec/S12-introspection/walk.rakudo FAILs and t/spec/S03-operators/arith.rakudo - TODO passed: 120, 131-132
moritz mikehh: walk.rakudo - I see the same. Do you know the last good revision?
NotFound Maybe the next patch from TT #1005 fixes some of that. 19:16
mikehh moritz I think 19:17
NotFound arith pass :)
mikehh r 41796
moritz: the last time I got everything PASSing was r41796 19:18
moritz thanks 19:19
mikehh the first failure I recorded was at r41212 - spec at r28217 (of that test) 19:21
let me do some checking 19:23
NotFound Uh, no, still failures at exit 19:28
moritz the big bunch of segfault-at-exit seems to be fixed to me
dalek rrot: r41254 | NotFound++ | trunk (2 files):
[pmc] applied patch from TT #1005 for Hash is_equal, flh++
 19:36
mikehh moritz: seems to pass at r41200 19:47
maoitz: fails at r41210 19:54
Coke msg cotto 'parrot -R profiling tcl.pbc -e "puts hi"', IIRC. 20:02
purl Message for cotto stored.
mikehh moritz: fails at r41204 20:03
maoitz: r40201, 2 and 3 shouldn't have any effect 20:04
moritz: I would say that r41204 was the cause
moritz aye 20:05
mikehh: thanks a lot
mikehh moritz: just to confirm the test t/spec/S12-introspection/walk PASSes at r41203 and FAILs at r41204 20:13
moritz mikehh: I opened a rakudobug for it now, becase I'm not sure if it's rakudo's or parrot's fault 20:18
it might be a case of poking too deeply into parrot internals
20:46 chromatic joined 20:48 KatrinaTheLamia joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41254 - Ubuntu 9.04 amd64 20:51
partcl r731 builds on parrot r41254 - make test PASS - Ubuntu 9.04 amd64
decnum_dynpmcs r181 builds on parrot r41254 - make test PASS - Ubuntu 9.04 amd64 20:54
japhb How does one get the command line arguments supplied to an NQP program (the equivalent of @*ARGS)? 20:56
20:59 KatrinaTheLamia joined
mikehh rakudo (0f1edeb) builds on parrot r41254 - make test PASS / make spectest (up to 28235) FAIL (1 test) - Ubuntu 9.04 amd64 21:01
rakudo - t/spec/S12-introspection/walk.rakudo FAILs and t/spec/S03-operators/arith.rakudo - TODO passed: 120, 131-132
rakudo - no Segmentation faults reported in make spectest
cardinal builds on parrot r41254 - rake test:all - reports same 3 failures - Ubuntu 9.04 amd64 21:03
21:33 fperrad left 21:55 bacek joined
bacek Good morning #parrot 22:19
22:21 bobke joined 22:25 kid51 joined
bacek kid51: hi 22:27
purl que tal, bacek.
japhb Is there a BEGIN {} equivalent in NQP? 22:28
bacek kid51: can you mark JIT-failing tests with SKIP?
japhb: not really.
japhb sigh 22:29
Programming directly in NQP is a great way to appreciate Perl ...
bacek japhb: you can use PIR for implementing such behaviour.
japhb bacek, I'm wanting to make the NQP parser aware of global variables that are declared by a PIR file I load with load_bytecode (because if I don't then I have to declare the globals both in the PIR module and in the NQP so that the parser doesn't complain about undeclared variables) 22:33
How would you do that?
(Any solution you come up with has to work in fakecutable form as well ....)
bacek japhb: checkout ops_pmc branch and look in "compilers/opsc".
japhb: I did quite similar things in it 22:34
japhb I don't see an ops_pmc branch in svn.parrot.org/parrot/branches/ ... 22:35
Did you mean ops_pct?
bacek Ah. Yes. 22:36
clock?
purl bacek: LAX: Sun 3:36pm PDT / CHI: Sun 5:36pm CDT / NYC: Sun 6:36pm EDT / LON: Sun 11:36pm BST / BER: Mon 12:36am CEST / IND: Mon 4:06am IST / TOK: Mon 7:36am JST / SYD: Mon 8:36am EST /
bacek still trying to wake up...
japhb bacek. I'm not seeing the global handling you're talking about. Link? 22:39
bacek japhb: op/oplib.pir 22:40
After "Cheat-cheat!" comment :)
japhb: this .sub works almost same as BEGIN{} 22:41
japhb: but may be I totally misunderstood you question... 22:42
japhb Oh, sure, yes, I know about the :anon :load :init thing ... but I'm not clear on how to make NQP parser know about variables that I create with set_hll_global inside that sub.
22:42 rg1 joined
bacek NQP will just use them afaik. 22:43
dukeleto 'ello
japhb Give me a sec, I'll commit and push and send you a link
bacek japhb: sorry, it's almost $dayjob time... I have to go. 22:44
japhb np, I'll post and you can backlog later 22:46
bacek, gitorious.org/parrot-plumage/parrot...r/Glue.pir
See onload sub, starting at line 94
If I try from NQP to do 'load_bytecode("Glue.pir"); say($PROGRAM_NAME);' it will fail. 22:47
For instance: 22:48
$ time parrot $NQP_PBC -e 'load_bytecode("Glue.pir"); say($PROGRAM_NAME);'
Symbol '$PROGRAM_NAME' not predeclared in <anonymous>
mikehh partcl - make specinfo finally ran to completion 22:50
japhb but add 'our $PROGRAM_NAME;' after the load_bytecode(), and it will ind it.
22:59 snarkyboojum joined 23:06 Whiteknight joined, snarkyboojum joined 23:08 bacek joined
bacek japhb: you have to declare "our $RPOGRAM_NAME" in NQP side. 23:08
japhb bacek, yes, that's what I said. 23:09
My point is that there should be a way from the PIR library to force that declaration into existence.
bacek But you can try $*PROGRAM_NAME instead (if I remember twigil correctly)
japhb hmmm, I wonder if that works in NQP ...
japhb tries 23:10
nope
bacek yeah... twigils are parsed but not handled... 23:12
23:30 jrtayloriv joined 23:38 nathanmccauley joined 23:40 TiMBuS joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!