Parrot 0.9.0 | parrot.org/ | 566 RTs left.
Set by moderator on 31 January 2009.
Infinoid NotFound: what does it break? 00:02
rg are you sure it's the no-star part, not the exactly one whitespace part? there's another version of that regexp above that states \\s* 00:03
NotFound Anything that tries to use a PMC * or STRING * PMC attribute from a pir subclass
rg: mmmm.... I think you are right. 00:04
Infinoid the lack of * after \\s looks like an oversight, considering it's there for the get_attr case and also for STRING in both set/get
Whiteknight use: /PMC\\s\\*[^\\*]?/
the question mark at the end makes the last character optional
Infinoid You probably want \\s*\\* too, not \\s\\*
rg whiteknight: that you can just aswell leave it out completely 00:05
s/that/then/ 00:06
Infinoid NotFound: do you have a test case?
NotFound Now I see an interesting point: the re is not the same in GET_ATTR and in the SET_ATTR parts. 00:08
Infinoid yeah, that to me looks like a typo
NotFound : /PMC\\s*\\*[^\\*]/ /PMC\\s\\*[^\\*]/
Infinoid the former will match "PMC* foo" and "PMC *foo"; the latter will only match "PMC *foo" 00:09
NotFound And a violation of the principle: "Don't copypaste code"
00:09 AndyA joined
particle there's an easy way to fix that, Don't Repeat Yourself. 00:11
chromatic I wouldn't mind disallowing PMC* foo. 00:26
rg you can always match \\s+ ;) 00:27
chromatic I could, but I think it might break something. 00:28
NotFound Well, I think that fixes part of the problem, but we have another one: get_attr_str does not get the pmc base attr from the pir derived class. 00:29
And all complicated by other known bug: exceptions thrown while searching from a handle enter infinite recursion 00:30
rg yes, i'd like to see a solution for that, too. 00:31
Infinoid chromatic: If we're going to disallow it, we should at least be consistent about it. 00:32
NotFound At least we must have codingstd test for ATTR syntax. 00:33
chromatic Agreed. 00:38
00:41 davidfetter joined
dalek rrot: r36407 | NotFound++ | trunk/lib/Parrot/Pmc2c/Attribute.pm:
[lib] fix handling of ATTR types in Pmc2c
 00:49
NotFound Let's go step by step 00:50
Whiteknight what are you guys updating? the ATTR syntax? 00:52
particle we don't allow STRING* syntax. there must be whitespace. that's in pdd07. 00:53
NotFound particle: I was worried about accepting valid things, not rejecting invalid ones. 00:55
Whiteknight: fixing, not updating 00:56
Whiteknight okay 00:57
cotto NotFound, that pmc2c code needs to reject things like STRING **. 01:05
(i.e. for FixedStringArray)
NotFound cotto: it does 01:06
cotto NotFound, you're right. I somehow missed the $ 01:07
NotFound I think that what this code really need is tests
01:09 tetragon joined
Whiteknight I think I have a fix coming through for the cpu_ret issue too 01:10
I was perfectly happy with documentation saying "just don't use this freaking opcode ever, or we'll find you", but no. Coke can't have that 01:11
dalek rrot: r36408 | NotFound++ | trunk/src/scheduler.c:
[core] quick hack to avoid infinite recursion when an exception is thrown while looking for a handler
 01:14
01:23 Andy joined
dalek rrot: r36409 | NotFound++ | trunk/src/pmc/exceptionhandler.pmc:
[pmc] One step towards fixing problems with pir classes derived form ExceptionHandler
 01:30
01:35 kid51 joined
Coke is glad to see his new president can swear convincingly. 01:44
kid51 Links?
purl i think Links is the linker rel
Coke kid51: digg.com/politics/Audio_clips_of_Ba...a_swearing 01:45
shorten Coke's url is at xrl.us/befcm6
kid51 Thx 01:49
So, if anyone wants to respond to any of my pokes from the last week concerning RT tickets, we might be able to push the number of unresolved RT tickets down below an important threshold ... 01:52
01:55 Piper joined
Piper Hi there. I am Piper. I am now publicly logging this channel. If you don't want to be logged, please leave now. 01:55
kid51 Piper, didn't you used to log here 6 or 7 months ago? And where did you disappear to? 02:01
Piper, we rely on masak's log now!
rg i thought it was moritz, but yeah, we have a good log. 02:02
kid51 rg: You're correct.
Speaking of bots, what's up with dalek. I made a commit 5 minutes ago and it hasn't been posted! 02:14
cotto dalek's been slacking off lately. Infinoid also lost a commit yesterday iirc. 02:15
dalek is a slacker
dalek?
purl i heard dalek was dha's distributed perl community badger badger badger attack or ourworld.compuserve.com/homepages/g...lek_fr.htm or 'Dalek' for the language, and 'dalek' for the program or www.daleklinks.co.uk/ or a Dr Who baddie or {see: dalek meme} or at www.deviantart.com/deviation/20016573/ or www.asciiartfarts.com/20020615.html or xrl.us/2doh
kid51 purl, dalek is also a bot (not unlike purl) who reports SVN commits on #parrot 02:17
purl wish i knew, kid51
kid51 Our FreeBSD Smolder reports are stuck at SVN r 29890 -- or at least the report is saying that's where they're being generated from. 02:30
Example: smolder.plusthree.com/app/public_pr...ails/17790
shorten kid51's url is at xrl.us/befcqq
rg if you want a freebsd smolder, i believe i can help. what's required to be useful? 02:44
Coke "make smoke" every so often. 02:46
after an svn up; the problem with the current ones is that it's stuck in a checkout from perl.org and can't update.
rg should i rather do it automatically or manually after i've updated and did a make test anyway? 02:47
kid51 If, whenever you normally say 'make test', you say 'make smoldertest' instead, you get the smolder report for free. 02:48
The TAP from the tests is exactly the same. It just takes a few seconds at the end to transmit the tarball.
(or however it transmits the report) 02:49
Coke automatically is easier to set and forget, but manually is fine, too.
rg hmm make smoke just told me i need TAP::Harness::Archive. this might take a minute 02:51
kid51 Uh, yeah, that's correct. I should have mentioned that. 02:52
03:11 Zaba_ joined
rg ok ... here we go 03:20
03:22 Andy joined
rg oh hmm. maybe i shouldn't send in smoke reports for a tree that is already patched 03:23
ok, it worked: smolder.plusthree.com/app/public_pr...ails/17825 03:33
shorten rg's url is at xrl.us/befcum
03:34 Whiteknight joined
Whiteknight if there's one thing I didn't miss, it was piper 03:34
we've got about 11 tests failing on Win32-x86 JIT 03:35
03:36 janus joined 03:40 Zaba joined
kid51 rg: Thanks. I was able to close one ticket with that report ... which puts at the magic number of 500 unresolved RT tickets: tinyurl.com/cbub2z 03:41
Whiteknight kid51++ 03:42
kid51 So, if one test failure will cause 'make fulltest' to halt, is there any way around that other than running the remaining targets individually? 03:43
Whiteknight your best bet is to write up a little shell script to run all the tests in sequence 03:44
I had a script like that at one point but I deleted it
moderator Parrot 0.9.0 | parrot.org/ | 500 unresolved RTs left. 03:44
rg you could copy the invocation from the makefile and run with make -k instead (or edit the -k into your makefile) 03:45
but on a related note, we might want to skip the jit tests on platforms that don't support jit, otherwise fulltest reports lots of errors 03:46
Whiteknight I'm getting a test failure in t/pmc/freeze.t. Win32-x86. Anybody else seeing this? 03:49
rg i've just sent in a succesful smoke for freebsd/amd64, so not me ;) 03:50
Whiteknight crap
03:57 Whiteknight_ joined 04:10 bacek joined
kid51 must sleep 04:21
purl $kid51->sleep(8 * 3600);
04:24 Andy joined 04:26 petdance joined
petdance I need a good picutre of pmichaud 04:32
and by "good" I mean "preferably embarrassing"
Andy Putting a shout-out to kid51 in my keynote 04:49
05:00 Zaba_ joined 05:05 Andy joined 05:37 mberends joined 05:42 Andy joined 05:57 Andy joined 06:21 Theory joined 06:30 TiMBuS joined 06:43 rurban_ joined 06:53 alinbsp joined 07:32 bacek joined
bacek rakudo: say "hi" 07:36
polyglotbot OUTPUT[hiā¤]
mberends bacek: say "hi" 07:46
07:49 chromatic joined 08:22 iblechbot joined 08:39 alvar joined 08:45 rurban_ joined
rurban_ Infinoid: A got now a gdb for mingw and added a bt to TT #276. encoding=0 on the DynLexPad indeed 08:46
08:52 cosimo joined
bacek Is git://github.com/rakudo/rakudo.git now official source for Rakudo? 09:11
rurban_ yes
for now 09:12
bacek rurban: great! 09:13
it there any particular instructions for build rakudo outside of parrot? 09:14
rurban_ not yet, sorry. I never do that 09:15
bacek rurban: no worries. perl Configure --help is enough :)
oh shi... It requires a lot of fixes to work with standalone parrot in separate directory... 09:20
cognominal rakudo has move out of parrot? 09:25
*moved
TiMBuS why has this not been announced yet? 09:26
cognominal this is a question, not an affirmation 09:27
TiMBuS well, the answer is yes
cognominal and parrot will not more to a git repository? 09:28
TiMBuS but it really needs to be announced. its kind of a big thing 09:29
cognominal *move
TiMBuS i don't think so 09:30
09:30 barney joined 10:11 Zaba joined
rurban_ I'm close to fixing TT #276. encoding=0 after whoami = CONST_STRING_GEN(interp, "DynLexPad"); 10:16
10:45 iblechbot joined
dalek rrot: r36412 | fperrad++ | trunk:
[rakudo] remove some perl6 references
 11:02
11:04 kj joined 11:05 rob joined
dalek rrot: r36413 | fperrad++ | trunk:
[rakudo] leaves on github
 11:11
tracwiki: v47 | fperrad++ | Languages
tracwiki: trac.parrot.org/parrot/wiki/Langua...version=47 11:12
rrot: r36414 | barney++ | trunk/src/ops/core.ops:
[codingstd] c_parens.t
11:16 kj joined 11:19 masak joined 11:21 rob joined
rurban_ TT #276: I think I have to give up in this for now. charsets are not initialized on a dynpmc init. but other ptrs are also not initialized. Null PMC access in get_integer() 11:28
12:03 alinbsp joined 13:02 rurban_ joined 13:05 Fayland_logger joined 13:09 Limbic_Region joined 13:13 bacek joined 13:14 kid51 joined 13:24 Fayland joined, rurban_ joined 13:48 alinbsp joined
dalek rrot: r36415 | barney++ | trunk/languages/pipp/t/php/control_flow.t:
[Pipp] add first TODO test for 'switch'
 13:52
rrot: r36416 | barney++ | trunk/languages/pipp:
[Pipp] Parse dummy switch control structure
 13:53
Infinoid rurban_: the strange thing here is that the failed assertion was ASSERT(encoding), yet the backtrace says the function was called with encoding=0x3d4d60 13:56
rurban_ Infinoid: I showed here two cases: first cygwin good, then the mingw bade case 13:57
sorry
I thought it's a simple data structure error, then I found it it's a missing init
Infinoid oh ok
rurban_ we still have to check if it's msvc also, or only mingw, kjs should know, or smolder 13:58
13:58 Whiteknight joined
rurban_ but if you give me some hints I can test and verify. 13:58
Infinoid Does your mingw build with libicu?
rurban_ I assume it's some strange dllinit thing
without
kj rurban_: hi 13:59
rurban_ I haven't installed it
oh hi!
did you have the dynpmc foo error on msvc?
kj yes
it came back recently
rurban_ ok, we shoudl note that in the ticket. so it's mingw and msvc
kj rurban_: i'm not sure, didn't look into the test too closelyk but ISTR it's something with loading some lib without extension? 14:00
rurban_ no, i noted it in the ticket. it's a missing charset initialization in every dynpmc 14:01
and there are more inits missing
the vtable are also missing
purl okay, rurban_.
kj rurban_: I'm not sure if particle had that test failing as well
but for me it has failed for a long time 14:02
rurban_ I'll try to bisect it. sooner or later...
kj it would be weird if it's only on some win systems (like mine) but not others; haven't heard jonathan about it, either; he's on win as well
Infinoid hmmm 14:04
rurban_: look at src/string/encoding.c line 369, if you haven't already
that line is where the pointer gets initialized... yet it is NULL later on 14:05
and it is being called with the right string and a nonnull pointer, it's #3 in your first backtrace 14:06
which sounds like either STREQ() does't work (unlikely), or the pointer is being overwritten later on? 14:07
kj afk #shopping
moritz programming is hard; let's go shopping 14:09
Infinoid hehe
rurban_ did you see my nopaste patch? 14:10
Infinoid no. (sorry, I just woke up) 14:11
rurban_ I fixed the encoding init, but then the vtable's had the Null config
So I stopped, because I thought there's a biugger pircture involved.
Infinoid which nopaste? 14:12
There are race conditions with encoding and charset initialization, because the init functions create STRINGs to store the encoding names, yet those STRINGs have null charsets or encodings at times. I mentioned this a while ago, Allison suggested we split labeling out from init and do that part later 14:14
But this looks like a different issue.
It really seems to me like the pointer is being set, and then overwritten later (which sounds like a bug)
NotFound If you want to stop having problems with dll, we must kill global statics. 14:15
rurban_ sorry, no paste, it's in the ticket, comment 3
or 4
f (!PARROT_DEFAULT_CHARSET) { /* hack for TT #276, dynpmc init only on Win32 */ ... 14:16
no I can confirm that the charset is never set, no overwriting
Infinoid hmm. 14:17
When I discovered the init races, I made charset NULLOK (because the encodings were being initialized before the charsets were)
so its crashing on a NULL PARROT_DEFAULT_ENCODING, not PARROT_DEFAULT_CHARSET
rurban_ I said something wrong before: my first bt is from mingw also, but on the first Parrot_str_new_init, the problem inside the dll, initialized later 14:18
bot are 0
Infinoid oh! So its a bad global variable reference?
rurban_ #0 Parrot_str_new_init (interp=0x3d25b8, buffer=0x6778879a "DynLexPad", len=9, encoding=0x0, charset=0x0, flags=12288) at src/string/api.c:767 14:19
encoding is just check first
encoding is just checked first
but encoding is a member of charset
Infinoid charset is never checked, because it is NULLOK 14:20
rurban_ ok
so we should ensure that just the fixed_8 encoding is initialized 14:21
but when you see my fix, you see "Null PMC access in get_integer()"
Infinoid yeah... at the position of your first backtrace, I would love to see a "print Parrot_fixed_8_encoding_ptr" 14:22
and again at the position of your second
rurban_ ok, will do
Infinoid rurban++
Infinoid is going to try moving these into the interp structure, to see if anything breaks.
rurban_ you mean in Parrot_lib_dynlexpad_load 14:23
Infinoid I don't know anything about dynlexpads... I just don't like the global pointers
rurban_ I remember having checked that: in cygwin (or elsewhere) the Parrot_fixed_8_encoding_ptr is kept, but on mingw it was 0x0 inside the (lazy) loaded dll. inside the main process it was okay. 14:24
NotFound Infinoid: an opaque structure known only by this file containing all those global and static globals will be better, IMO
Infinoid ...rather than being in the interp structure?
or does the dll not have access to interp?
NotFound Infinoid: in the interp structure, a pointer to that opaque structure.
rurban_ I'll paste the p *interp, okay? 14:25
Infinoid ok
NotFound The idea is to encapsulate it from other parts of parrot.
Infinoid whatever we do, it should be useful to everything that uses PARROT_DEFAULT_CHARSET and PARROT_DEFAULT_ENCODING
NotFound And add an INTERP parameter to all functions that does not already have one. 14:26
nopaste "rurban" at 143.205.212.10 pasted "TT #276 attempt which shows there's more involved" (58 lines) at nopaste.snit.ch/15523 14:27
rurban_ okay, I think you were right, it seems that it got overwritten. 14:28
I'll have to check the cpp expansion now for the macros
note that this paste already includes my encoding init fix 14:29
Infinoid ok 14:32
rurban_ -g3 doesn't work on mingw-gdb so I cannot expend it there... 14:34
Infinoid are you trying to check the PARROT_DEFAULT_ENCODING macro, or something else? 14:36
rurban_ both. the PARROT_DEFAULT_ENCODING definition and the CONST_STRING_GEN macro (which are both clear to me, but who knows) 14:38
Infinoid there's always gcc -E, I guess 14:42
14:44 rurban__ joined
rurban_ macros are good. I'll paste my result. 14:46
14:48 jan joined
nopaste "rurban" at 143.205.212.10 pasted "verification that constant_pmc_new() is resetting the charset and encoding (win32 only)" (54 lines) at nopaste.snit.ch/15524 14:53
NotFound I'm trying the approach of killing globals.
rurban_ Now I'm tracing into that mess 14:56
Infinoid NotFound: If you're talking about the Parrot_*_encoding_ptr and Parrot_*_charset_ptr globals, I'm working on that too (probably around 70% done) 14:58
NotFound Infinoid: A race? ;) 14:59
Infinoid heh, ok 15:02
first one to nopaste a patch that passes "make test" gets free karma :)
rurban_: so constant_pmc_new is calling the encoding and charset init functions? 15:03
NotFound Infinoid: In each onw system, or in rurban troubled one?
Infinoid I don't know if removing globals will have any effect on rurban's case... 15:04
But removing them is probably useful for it's own sake.
NotFound Infinoid: yeah 15:06
Infinoid hah! now all of a sudden I get a failed assertion 'encoding' too, in the same place as rurban's :) 15:09
has nothing to do with dynlexpad tho 15:10
rurban_ aha 15:11
it's kj also
Infinoid splits encoding/charset labeling from init, to fix that race 15:12
rurban_ Infinoid: not
Infinoid: constant_pmc_new is not calling the encoding and charset init functions, it's nullifying it. Parrot_charsets_encodings_init restores it again, even to the very same ptrs 15:13
Infinoid yeah, they are globals pointing to static structures 15:15
rurban_: the crash I'm seeing is earlier, while parrot itself is initting.
it would be great to find out why your pointers are becoming NULL though
rurban_ you just have to set watch on those two ptrs 15:16
and then step through. not so easy on mingw though
(gdb) watch Parrot_fixed_8_encoding_ptr 15:20
but not! (gdb) watch *Parrot_fixed_8_encoding_ptr 15:34
(I killed my gdb session and even my shell with doing this)
Infinoid hey, no fair! I put the pointers into the interp structure, but then parrot crashes and it's a different interp structure! 15:35
heh, I just had a watchpoint crash gdb here, too.
NotFound I'm having trouble with the jit, not easy to replace the global with a function call in jitted code 15:36
Configuring without jit, in the meantime
Infinoid I guess I didn't hit that, as jit isn't enabled on x86-64 by default anyway 15:40
so I didn't consider that it might be a problem 15:41
cloning the pointers in make_interpreter() seems to have worked. But now I think I see why rurban was suggesting an opaque structure... quicker to copy one pointer rather than 10 15:45
NotFound Infinoid: hey, that was me ;) 15:50
Infinoid heh, ok. NotFound++
15:59 szabgab joined
nopaste "infinoid" at 75.28.75.73 pasted "1-move-encoding-and-charset-into-interp.patch" (1327 lines) at nopaste.snit.ch/15525 16:00
"infinoid" at 75.28.75.73 pasted "2-split-encoding-charset-labeling-from-init.patch" (231 lines) at nopaste.snit.ch/15526
Infinoid That works for me, but as you said, it will probably break JIT 16:01
NotFound Infinoid: you win
Infinoid your opaque pointer idea is a good one 16:02
NotFound But the race was for speed, not for goodness ;)
nopaste "NotFound" at 213.96.228.50 pasted "kill globals from encodings" (872 lines) at nopaste.snit.ch/15527 16:06
NotFound Here is my version, not fully tested yet.
Infinoid oh, searching for it? that will be slower, but more flexible 16:11
rurban_ src\\library.c:335: error: `interp' undeclared (first use in this function)
NotFound Infinoid: that is the way doable without much change, probably will need some functions to directly get the most used ones. 16:12
Well, actually the "most used" are all :D 16:13
Infinoid for now. I think it makes it easier to add more without having to touch a lot of code tho 16:14
nopaste "infinoid" at 75.28.75.73 pasted "3-fix-rurbans-build-error.patch" (33 lines) at nopaste.snit.ch/15528
NotFound Or maybe assign fixed numeric values to some of them. 16:15
Infinoid rurban_: that will probably need a "make headerizer" to be fully correct
NotFound Test pass :)
Infinoid: hey, that is not fair, I headerized mine ;)
Infinoid NotFound: I headerized mine too. But rurban's code is win32-specific, and headerizer only does the stuff that builds on your own platform 16:16
rurban_ 15525+15526, okay, 15527 messed it up for me.
NotFound Ah, all well then
Infinoid so whenever I do a headerizer, it misses all the JIT code 16:17
rurban_ is there a single file patch possible?
Infinoid yeah, I've just been keeping them separate for easier review
NotFound rurban_: 15527 surely is incompatible with the others
16:18 Tene_ joined
nopaste "infinoid" at 75.28.75.73 pasted "single patch for rurban" (1464 lines) at nopaste.snit.ch/15529 16:19
rurban_ sorry, I'm confused now. which pastes should I apply now?
NotFound rurban_: this was not a collaboration, was a competition. You apply either Infinoid patch or mine, but not both at the same time 16:20
Infinoid rurban_: NotFound and I both have our own versions of the patch. NotFound's patch is standalone, 15527. standalone version of mine is 15529
time for breakfast here, back later :)
rurban_ sorry, I'm just in a conference room, so i'm listening to three at once. 16:21
NotFound BTW I modified just the encoding thing, not the charsets yet.
Infinoid yeah. I did both, but didn't try to make it dynamic 16:22
oh, I also managed to remove the NULLOK from charset (something I've been wanting to do for a while now)
NotFound I killed several SHIM_INTERP, wich is also good IMO 16:23
Infinoid yep, I had to do that too... and add PARROT_INTERP in a few new places
and I also got rid of that nasty parrot_init_encodings_2() hack. (but I replaced it with the almost-as-nasty register_encoding_names() hack)
NotFound That _2 is funny, giving that there is no _1 16:24
Infinoid Remember how I said there was a race condition where register_encoding() and register_charset() would create STRINGs before the various encodings and charsets were in place?
parrot_init_encodings_2() went through and fixed up the strings' charset pointers after the fact 16:25
Now I just go through and create the STRINGs after the fact
to me that seems a little more sane.
NotFound Yeah
Infinoid lathos: Your input on this stuff would be valuable. Have you made any attempt to eliminate the Parrot_*_encoding_ptr or Parrot_*_charset_ptr global variables in your strings branch? 16:32
rurban_ got it building now on mingw... wait a sec 16:33
NotFound Why on earth Parrot_str_new_init accepts a NULL charset? 16:35
... and does nothing with it.
Infinoid haha
NotFound: its because register_encoding() creates a string before any charsets have been initialized 16:36
That's what I fixed in 2-split-encoding-charset-labeling-from-init.patch.
(and its what I was just talking about)
NotFound So we can kill that NULLOK when other insanities are also killed. 16:37
Infinoid yes, and I did that
NotFound Good
Infinoid it didn't do nothing with it... it put the NULL pointer into the new STRING structure 16:38
and parrot_init_encodings_2() fixed it up later
NotFound I think that for speed and clarity of the coda we may need to add Parrot_str_new_init_default and Parrot_str_new_init_fixed8
Infinoid I think we might already have macros for that 16:39
NotFound macros are evil
Infinoid (for clarity at least, if not speed)
dalek kudo: a26b223 | (Moritz Lenz)++ | t/harness:
[t/harness] parrot libs can also be in parrot/lib
shorten dalek's url is at xrl.us/befd89 16:40
Infinoid NotFound: macros are evil, you won't find me arguing with that :)
NotFound Macros make the reader think that something is a fast and simple operation when really is a slow lookup.
Specially when they have a hidden interp argument. 16:41
Infinoid We could always go the perl5 ithreads route and stuff the interpreter structure into thread-local context instead 16:42
NotFound Mmmm... you mean pass the conext to most functions, and get the interpreter from it when needed? 16:43
Or just take it from a thread var? 16:44
Infinoid Yeah. They stick the PerlInterpreter into a pthread_getspecific() pointer
so it looks global, but isn't.
kinda. It's another way to have the interp available everywhere without assuming an interp argument 16:45
rurban_ still get errors after make headerize: core.jit:1356: error: `Parrot_fixed_8_encoding_ptr' undeclaredl
Infinoid ah, JIT.
NotFound rurban_: Configure --jitcapable=0 16:46
Infinoid (for the record, I think thread-local variables are even uglier than passing interp everywhere)
rurban_ no problem :)
NotFound We take care of the jit part later
rurban_ src\\pmc\\string.pmc:858: error: `Parrot_ascii_charset_ptr' undeclared 16:47
`Parrot_String_nci_trans': 16:48
NotFound Giving that we allow a full hyerarchy of child interpreters and nothing forbids call one fromm the others inside the same thread, that will be confusing to say the least.
Infinoid yeah, the maintenance overhead of the fixups will outweigh the "casual reading" clarity gains I think
16:50 cosimo joined
Infinoid rurban_: can you change that to interp->ascii_charset_ptr, or should I issue a new patch? 16:50
Ah, there are 4 instances in PMC files that I hadn't fixed up. incremental patch #4 coming up 16:53
nopaste "infinoid" at 75.28.75.73 pasted "4-more-fixes.patch" (56 lines) at nopaste.snit.ch/15530 16:55
rurban_ fixed 4
Infinoid did a clean and rebuild and is retesting now
rurban_ ok, sounds good now 16:56
16:59 kid51 joined
NotFound So we all agree that killing the encoding an charset global variables is the way to go? 17:01
Infinoid I think so, it looks pretty good here (other than jit)
if it fixes rurban's issue, then it proves that shared library semantics are at fault, right? 17:02
17:02 rhr joined
Infinoid I mean, other than some init ordering details, I don't think I changed anything else that would fix mingw 17:02
NotFound Or at least, that using the globals need a serious review for windows dll usage
Infinoid yeah
NotFound And maybe for other platforms shared object semantics. 17:03
So killing them is easier and safer 17:04
Infinoid yeah
This isn't the first time I've seen problems with linking on windows. I've had some issues just accessing the PMCNULL global from time to time 17:05
rurban_ I'm testing cygwin, mingw and msvc6 now. It's just my small laptop.
Infinoid rurban++
rurban: did mingw work, then?
rurban_ still relinking
Infinoid oki
rurban_ the first attempt had an old dynlexpad.c around, which needed an make realclean 17:06
Infinoid is working on better separating his fix-charset-and-encoding-init patch from the remove-globals patch 17:08
I'd like to check in the init-fix stuff first, and independent of the global stuff 17:09
dalek kudo: 6211ae2 | (Moritz Lenz)++ | (2 files):
filetests shouldn't die on non-existant files.
 17:10
NotFound Infinoid: good idea
purl NotFound: Good Idea: Buying a pair of shoes on sale. Bad Idea: Buying a parachute on sale.
shorten dalek's url is at xrl.us/befef6
17:20 Andy joined
dalek rrot: r36417 | petdance++ | trunk/src/exec_save.c:
Found an infinite loop
 17:20
Andy I found a bug, I found a bug.
Whoo
17:22 gerd joined 17:39 Theory joined
dalek kudo: 13f6779 | (Moritz Lenz)++ | config/makefiles/root.in:
[Makefile] don't try to checkout //-URLs.
 17:48
shorten dalek's url is at xrl.us/befej8
18:01 Andy joined
Infinoid Shiny. PARROT_DEFAULT_ENCODING and Parrot_default_encoding(interp) both exist, and they don't always do the same thing 18:11
calling Parrot_make_default_encoding() affects the latter but not the former
18:11 tewk joined
NotFound Infinoid: Parrot_make_default_encoding should be killed 18:11
Infinoid Several pieces of code use PARROT_DEFAULT_ENCODING directly to create strings, so they won't get the new default 18:12
I'm not sure what the design should be here, but this seems like another way the current implementation is broken
NotFound I can't think of any reasonable way of using a mutable default.
Infinoid Removing it is fine with me :) 18:13
NotFound Otherwise we may need a function called: Parrot_default_default_encoding 18:15
Or we can kill completely the default idea. If you want ascii, say it. If you want binary fixed8, say it. 18:16
Infinoid NotFound: Does my patch on TT #286 look reasonable?
NotFound And if you want ebcdic.... er.... did we have someone building in an ebcdic platform?
Infinoid Not that I know of, yet 18:17
well, there are lots of places where having to explicitly specify it clutters things up
Like, do I really want to have to specify that all of my exception strings are in ascii format, for every sanity check I add?
NotFound No mora than explicty specifying DEFAULT
Infinoid that's true. But for most things, I think I'd prefer to have a "don't care" function I can call, instead 18:18
NotFound I thnk that this type of thing must *never* be ascii. If we want to allow localization they must be unicode utf8
Infinoid That's a reasonable default indeed 18:20
And it doesn't affect my code in any way :)
NotFound Yeah, that's the beauty of utf8
Infinoid Except for performance for things like string_equal, I guess
NotFound string_equal can be easily optimized for case of same charset and encoding to a memcmp 18:21
Infinoid Or the string creation function can use ASCII by default for strings that have no high bit set, and utf8 otherwise 18:23
I'm not sure if that makes things better or worse.
NotFound That is the way some parts of parrot use now, and I think that this is effectively pesimizing lots of string operations. 18:24
Infinoid I'm sure if you posted a patch with some measurements indicating improved performance, it would get lots of attention :) 18:25
NotFound Marking them as ascii or latin-1 has the main virtue of making faster access to individual characteres.... but... hey, we don't have functions to access individual characters :D
Infinoid I love how Parrot_str_indexed()'s documentation starts out saying it does that, and then says (maybe) 18:27
I'll be back later :)
NotFound Anyway, for strings destined to show error messages to the user, faster cmp is not a constraint.
18:36 Andy joined
dalek rrot: r36418 | NotFound++ | trunk/src/string/charset/iso-8859-1.c:
[string] fix name inconsistency in charset/iso-8859-1
 19:13
rrot: r36419 | jkeenan++ | trunk:
Applying patch submitted by fperrad in trac.parrot.org/parrot/ticket/284. 'pdump' executable renamed 'pbc_dump' to avoid name conflict with other open source program.
 19:34
19:45 geof joined 20:06 chromatic joined 20:12 Andy joined
pmichaud moritz++ # 13f6779 20:30
21:03 Andy joined 21:12 tetragon joined, idemal_ joined 21:26 bacek joined
dalek rrot: r36420 | petdance++ | trunk/src/pmc/exceptionhandler.pmc:
consting aplenty
 21:27
21:30 turbov21 joined 21:33 Theory joined
turbov21 What does this mean: "load_bytecode" couldn't find file 'PCT.pbc' 21:34
(I'm trying to run a Perl program in Windows)
chromatic Sounds like an improper installation. 21:36
PCT is the base code for a compiler in Parrot.
turbov21 I just ran the Win32 installer off sourceforge 21:38
Perl6 works alone, I can get to a command prompt. It just flakes out when I try to load/run a script. 21:39
dalek rrot: r36421 | petdance++ | trunk:
ornamented some function parameters
 21:40
chromatic Which version of the Win32 installer?
turbov21 0.9.0
0.9.0.1
chromatic Hm. That's fairly up to date. I don't remember if we solved the PCT installation problem by that point though. 21:42
turbov21 I haven't spent time trying to build it from source, just ran the installer. 21:43
chromatic I don't see fperrad on channel right now. He might know better. 21:45
turbov21 Thanks. I'll check back later then. (Finally got Rakudo to build on Linux.) 21:48
dalek rrot: r36422 | NotFound++ | trunk/src/library.c:
avoid some duplications in library.c
 21:54
22:17 szabgab joined 22:44 rurban__ joined 22:54 TiMBuS joined 23:02 dalek joined
dalek rrot: r36423 | NotFound++ | trunk/src/debug.c:
[debugger] avoid headerizer noise in internal functions of debug.c
 23:03
allison@perl.org | Debian/Ubuntu chroot Environment Setup:
link: www.perlfoundation.org/parrot/index...ment_setup
shorten dalek's url is at xrl.us/beesjm
dalek rrot: r36424 | petdance++ | trunk/src:
consting and removing unused vars
 23:04
23:10 Limbic_Region joined 23:12 braceta joined 23:13 braceta joined
dalek rrot: r36425 | petdance++ | trunk/src/pmc:
more consty consty
 23:33
rrot: r36426 | NotFound++ | trunk:
[codingstd] a few fixes
 23:40
23:41 Theory joined
Theory oh joy, piper is harassing me again 23:41
23:52 HG` 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!