Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 18 May 2010.
00:15 kurahaupo joined
whiteknight I can't really trace through this code without more info. There are three interpreters: INTERP, attrs->supervised, and attrs->supervisor 00:15
without knowing which is which, I can't really figure all this out
cotto_work supervisor is the same as INTERP 00:16
I mentioned that a couple weeks ago.
supervised iirc is what runs the instrumentation 00:18
I need to dig into that. 00:20
00:35 tetragon joined
whiteknight purl msg tcurtis I'm interested in your project. you can contact me for feedback (sorry I didn't respond to your email) 00:36
purl Message for tcurtis stored.
tcurtis purl, messages erase 00:37
purl tcurtis: what?
cotto_work needs to be in privmsg
tcurtis noted, whiteknight.
dalek tracwiki: v23 | cotto++ | CottoTasklist 00:39
tracwiki: add gsoc stuff for khairul's project
tracwiki: trac.parrot.org/parrot/wiki/CottoTa...ction=diff
whiteknight purl msg bacek let me know if you need help with gc_massacre. I'm glad to lend my feeble human meat-paws to the effort
purl Message for bacek stored.
cotto_work current work is going on in the no_constants branch of the branch iirc 00:42
bacek_at_work whiteknight, yes, getting rid of awful "constant" pmcs will help
cotto_work so the plan for that branch is just to avoid any creation of constant PMCs? 00:43
whiteknight bacek_at_work: do you have a fancy plan for doing it? The big reason why we have constant PMCs (that I know of) is to solve order of destruction issues for PMCs that don't get anchored
like library PMCs, a reference might not be kept to the library but we can't collect it if we are using methods from it
bacek_at_work we can explicitly use Parrot_pmc_gc_register for them. 00:44
current blocker in branch - packfiles are not properly marked. 00:45
whiteknight bacek_at_work: okay, we can do that. Maybe we can add an attribute to NCI PMCs for the library PMC that they come from
then it will get marked like normal so long as we still have a reference to any NCI PMC from that library
the scheduler too, but that's anchored in interp 00:46
checking out the _no_constant branch now 00:47
I don't think we want to register libraries, because then they will never be unregistered
bacek_at_work Do we have way to unload library??? 00:48
cotto_work what bacekbot said
library unloading sounds like something that we don't want to never allow, but also that we don't care about for now 00:53
ash_ couldn't you unload a library if all references to it disappeared? 00:54
whiteknight bacek_at_work: not yet, but I don't see why we wouldn't 01:00
if no references to the library or any methods from it exist, the GC can unload it automatically
because if no references exist, we can't use it
I'm adding a ->library attr to NCI.pmc now that includes this information 01:01
01:01 abqar joined
bubaflub where does Configure.pl figure out which libraries to link to? 01:01
whiteknight no idea. Ask kid51 01:02
bubaflub okey dokey
Coke I need git help.
bubaflub Coke: whatcha need? 01:03
whiteknight bacek_at_work: on _no_constants, did t/pmc/threads.t fail already?
or, did I just break it?
Coke um. unloading libraries like that won't work.
whiteknight Coke: why not?
Coke else how can I loadlib something somewhere, and then get_global it later to invoke it?
bubaflub Coke: i thought you were referring to the SCM git 01:04
whiteknight Coke: how does get_global find it? If we have a reference to the library anywhere visible or searchable, the GC will find it and protect it
Coke bubaflub: I have a local branch. I have a fork I'm trying to cherry pick into my branch. I'm trying to get it to refer to the original committer, but cherry-pick seems to just apply it as if I'm the author. 01:05
bubaflub hmmmmm
ash_ bubaflub: Configure.pl adds them at auto time
Coke bubaflub: yes, I'm having 2 conversations simultaneously. =-)
ash_ links
bubaflub Coke: haha, ok. sorry, i'm in and out of my VM
Coke whiteknight: perhaps I'm conflating c-library and parrot-library.
bubaflub Coke: you might be able to try a rebase instead
Coke: rather than squashing the commits, you might be able to rebase a few of the commits onto your branch 01:06
Coke: and i believe that should save all the original commit information
ash_ Coke: www.gitready.com/intermediate/2009/...mmits.html
bacek_at_work whiteknight, yes
whiteknight okay, I'm going to commit my change then
bubaflub ash_: (re Configure.pl) do you know which config step does it? 01:07
Coke bubaflub: I'm not squashing anything.
I'm trying to cherry-pick a single commit.
ash_ any of them can, during auto, if your tests for whatever library work out fine, you can append them to the conf
bubaflub Coke: right. i believe you can rebase *without* cherry picking 01:08
Coke er, what does the rebase buy me in this case?
bubaflub errrr
wait, sorry
Coke: i mean i think you rebase without squashing
Coke bubaflub: I'm more concerned at how to do it right before a rebase becomes necessary. 01:09
perhaps I wanted git commit -C <old sha> ?
dalek rrot: r47272 | whiteknight++ | branches/gc_massacre_no_constant/src (2 files):
[gc_massacre_no_constant] Add a ->library attr to nci to keep track of the ParrotLibrary PMC that originates it. This way the library will automatically be marked by GC if any references to any NCI functions from it are reachable.
 01:10
ash_ each one of the Parrot::Configure::Step's runstep's takes 1 param (the configuration reference) and you can use $conf->data->add( ' ', hash_key => value); to append stuff to a current config flag, like if you want to add a library (like i am doing for libffi): $conf->data->add( ' ', libs => $libffi_options_libs ); that adds a make link
rrot: r47273 | tcurtis++ | branches/gsoc_past_optimization (5 files):
Initial non-working commit of PAST::Pattern(well, it works when matching doesn't work!).
bubaflub Coke: what version of git are you running?
Coke 1.7.0
bubaflub hmmm... then that's not it either. 01:11
i haven't done too many cherry picks, but i haven't had the problem with overriding the author
i'm at a loss, if dukeleto is around his git-fu is stronger than mine
Coke bubaflub: aha. cherry-pick -se worked. Though I swear it failed earlier. 01:14
bubaflub Coke: great. i suggested rebase because i imagined you had multiple patches you wanted to apply... cherry-pick is definitely the way to go for a single or a few patches 01:15
ash_ if i get my libffi work going, parrot won't need core_thunks or any thunks anymore 01:16
s/going/working/
cotto_work assuming we don't mind having it as a core dependency
ash_ well, i am keeping the old nci around too
if it detects libffi, it tries to use that but if you don't have libffi it uses the current nci stuff (or if you do --without-libffi) 01:17
it won't be required, but then you'll be working with the old nci limitations 01:18
dukeleto 'ello
tcurtis loves seeing the amount of red go down every time he types "prove t/library/pastpattern.t"(well, until he adds tests more tests and is back up to lots of tests failing). 01:20
Coke ok, one more git question - if I have a branch that I created as a local, how do I push that back to the server? "git push origin <branchname>" ? 01:21
ash_ yes 01:22
Coke ... bah. one more question! 01:24
git pull is now telling me that I have to pick where I want to merge changes to. Shouldn't a git pull just pull /everything/, and only merge changes relevant to the current branch?
ash_ git pull is multiple operations in one 01:25
git fetch just pulls changes
git pull fetches and merges if your in a tracking branch
Tene so "git pull" can only merge if it knows which remote branch you want to merge into the currently-checked-out branch. 01:26
ash_ yeah
dalek rrot: r47274 | whiteknight++ | branches/gc_massacre_no_constant/src (2 files):
[gc_massacre_no_constant] add ->library to UnManagedStruct too, since it can be associated to a library through the dlvar opcode
dukeleto Coke: what is your current branch?
rrot: r47275 | whiteknight++ | branches/gc_massacre_no_constant/compilers/imcc/pbc.c:
[gc_massacre_no_constant] the namespace_name attr in Sub.pmc is marked, so it doesn't need to be constant. Plus, I think GC is currently disabled during IMCC anyway, so no sense safeguarding it
Coke ah. so when I created this branch locally, and pushed it back, that's not sufficient to figure out the tracking?
dukeleto: 'revive' on partcl/partcl 01:27
Tene Coke: it should be.
dukeleto Coke: git pull origin revive
ash_ you can make the local branch a tracking branch by doing git branch --track <branch> <remote-branch>
Tene not really here, on the bus.
dukeleto trackign is default when you create it locally
ash_ then you won't have to do the longer command to pull
dukeleto Coke: also, there is a setting for your ~/.gitconfig 01:28
Coke dukeleto: I did a checkout <sha1> -b revive, and later did a push origin revive ; but if I am in the revive branch locally and do a "git pull", it squawks.
dukeleto [push] default = current
that makes "git push" always push into the remove version of your branch 01:29
ash_ i thought you had to set branch.autosetupmerge to true for it to make local branches tracking by default
dukeleto Coke: hmmm, not sure
ash_: git checkout foo will track origin/foo be default 01:30
netsplits--
01:30 tetragon joined, kurahaupo joined, jsut joined, bubaflub joined, whiteknight joined, snarkyboojum joined, ash_ joined, bline joined, cotto_work joined, Chandon joined, eternaleye joined, janus joined, confound joined, PacoLinux joined, aloha joined, bacek joined, mikehh joined, cosimo joined, mberends joined, cognominal joined, contingencyplan joined, sorear joined, jnthn joined, particle joined, preflex joined, TimToady joined, pmichaud joined, Util joined, spinclad joined, simcop2387 joined, nopaste joined, TonyC joined, silug joined, arnsholt joined, moritz joined, ttbot joined, knewt joined, ascent joined, Ryan52 joined, tewk joined, sri joined, slavorg joined, dngor joined, bacek_at_work joined, treed joined, GeJ joined, cotto joined, nnunley joined, Maddingue joined, krunen joined, Tene joined, dmagnus_ joined, Infinoid joined, szabgab joined
whiteknight bacek_at_work: okay, I'm going to bed now. The two instances of Parrot_pmc_new_constant in src/packfile.c can't be removed yet, they cause test failures. I will try to figure that out later if you don't beat me to it 01:31
goodnight, er'body
bacek_at_work whiteknight, good night
dalek rrot: r47276 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/PAST/Pattern.pir:
PAST::Pattern passing all existing tests. Time to add more.
 01:43
01:50 kid51 joined
Coke is kind of freaked out by the BEAR NOISES coming from his back yard. 01:51
thought he lived close enough to the city to avoid that sort of thing.
ash_ anyone know what github.com/leto/parrot/blob/upstrea...ot.in#L242 is for? that file doesn't exist... 01:52
jnthn Coke: Is there...akshually a bear?! 01:53
Coke jnthn: well, based on some recordings of bears I found on the internet looking for milk... possibly. 01:54
Coke will call animal control tomorrow. in the meantime, all kids, pets, and spouses are indoors.
ash_ www.youtube.com/watch?v=6DXs4UuuM7M you need that cat 01:55
(its the video of a cat scaring off a bear so people know)
jnthn is sure he saw that one on icanhascheezburger before now 01:57
ash_ yeah, it was there, i think thats where i found it 01:58
Coke wonders why the OS pmc thinks he's trying to call "get_string" on it. :P 01:59
02:00 jsut joined, snarkyboojum joined, ash_ joined, cotto_work joined, eternaleye joined, janus joined, aloha joined, mikehh joined, contingencyplan joined, sorear joined, jnthn joined, TimToady joined, slavorg joined, sri joined, tewk joined, Ryan52 joined, ascent joined, knewt joined, ttbot joined, moritz joined 02:01 sorear joined 02:02 kurahaupo joined 02:14 bluescreen joined
Coke msg plobsing - all tests now pass in revive branch with that old parrot version. 02:22
purl Message for plobsing stored.
02:30 snarkyboojum joined
kid51 msg bubaflub As others have noted, there's no one step where linker libraries are set. To trace the evolution of the value assigned to any entry in lib/Parrot/Config/Generated.pm, try Parrot::Configure::Trace. 02:33
purl Message for bubaflub stored.
ash_ what is the first param to $conf->data->add for ? I saw how it was used but i don't understand the first param's purpose 02:38
kid51 ash_: Specific context? File? 02:40
Documented starting at line 174 of lib/Parrot/Configure/Data.pm 02:41
ash_ github.com/ashgti/parrot/blob/gsoc_...ine.pm#L96
i'll go read that
ah, its the deliminater, got ya 02:43
kid51 To the pre-existing value of the 'libs' element in the Parrot::Configure object's data structure (specificially, the 'data' part thereof), append value of libs using wordspace as delimiter.
02:44 plobsing joined
kid51 ... which goes back to the msg I just left for bubaflub: 'libs' is one of those attributes that gets built up over the course of the 60+ configuration steps. 02:44
If you need to know what value of 'libs' is at any one step, use Parrot::Configure::Trace. 02:45
dalek rrot: r47277 | tcurtis++ | branches/gsoc_past_optimization/t/library/pastpattern.t:
Add tests for exact matching on the "name" attribute.
 02:49
rrot: r47278 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/PAST/Pattern.pir:
Switched to using a macro for class-checking.
02:55 theory joined 03:13 janus joined
dalek rrot: r47279 | cotto++ | branches/gsoc_instrument/MANIFEST:
manifix
 03:22
03:35 kurahaupo joined 03:43 LoganLK joined 03:50 TiMBuS joined
cotto seen khairul 03:56
purl khairul was last seen on #parrot 8 hours, 4 minutes and 5 seconds ago, saying: see t/pmc/scheduler.t
04:00 snarkyboojum joined 04:02 kurahaupo joined 04:25 parthm joined 04:28 eternaleye joined
dalek rrot: r47280 | tcurtis++ | branches/gsoc_past_optimization (6 files):
Rewrote what I had of PAST::Pattern in NQP.
 04:28
04:36 Chandon joined
dalek rrot: r47281 | plobsing++ | trunk/t (2 files):
un-dynext some coretests
 05:01
05:01 kurahaupo joined 05:10 mj41_ joined 05:12 elmex joined, dalek joined 05:13 AzureStone joined, eternaleye joined, wagle joined, mikehh_ joined
cotto I want to pick some delicious brains. 05:14
05:17 baest joined
plobsing ENOBRAINZ 05:25
plobsing wonders if purl picked that up 05:26
cotto?
purl, cotto? 05:27
purl no idea, plobsing
bacek_at_work aloha... 05:31
plobsing purl, bacek_at_work! 05:33
purl plobsing: sorry...
bacek_at_work aloha. bacek?
aloha bacek_at_work: Sorry, I don't know.
bacek_at_work aloha, bacek is magical coding robot
aloha bacek_at_work: Okay.
bacek_at_work aloha. bacek?
cotto hi
aloha bacek_at_work: Dunno.
bacek_at_work aloha, bacek?
aloha bacek_at_work: bacek is magical coding robot
bacek_at_work it does work...
sorear aloha, sorear? 05:34
aloha sorear: Dunno.
cotto background: We'll eventually want to have some kind of meeting to discuss Lorito. Some decisions will be necessary to nail down before interested parties can start hacking, others are best left until we've got some code to play with. 05:37
With that, here's what I've got so far for the various questions about Lorito's design and which of those questions should be decided when: 05:38
nopaste "cotto" at 192.168.1.3 pasted "Lorito planning priorities" (13 lines) at nopaste.snit.ch/20822
ttbot Parrot trunk/ r47282 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/334382.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 05:47
sorear cotto: by "INS or INSP" did you mean "INP or INSP"? 05:48
plobsing [I]nteger [N]umval [S]tring [P]MC 05:49
cotto That point wasn't phrased well at all.
plobsing pmcs are high level and possibly not part of lorito 05:50
cotto plobsing, exactly
plobsing wheee! my patch found a bug in parrot's build process!
dalek rrot: r47282 | plobsing++ | trunk (4 files):
make failing loadlib PIR directive abort compilation loudly (TT #437)
 05:51
sorear plobsing: if lorito can't express PMC registers than it can't be used to implement PMCs. You have to store self somewhere 05:52
unless we're going *really* low level and PMC pointers are kept in I registers
cotto That's part of what we'll want to address. (no pun intended, but welcomed nonetheless) 05:53
dalek tracwiki: v11 | cotto++ | LoritoRoadmap 05:55
tracwiki: split design issues into primary and secondary based on when they'll need to be settled
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
plobsing urg. 'loadlib_sc' doesn't exist to IMCC right now. this would be solved with const-unfolding 05:56
dalek TT #437 closed by plobsing++: .loadlib fails silently 05:57
TT #437: trac.parrot.org/parrot/ticket/437
06:05 uniejo joined
dalek rrot: r47283 | plobsing++ | trunk/runtime/parrot/library/parrotlib.pir:
loadlib at runtime to avoid newly-failing compilations thanks to TT #437 fix
 06:07
mikehh opbots, names 06:15
cotto clock? 06:17
still no purl facts
sad face
06:18 cognominal joined
dalek rrot: r47284 | NotFound++ | trunk/examples/nci/xlibtest.pir:
use a new 'FileHandle' and its methods instead of open and close opcodes in example xlib
 06:24
06:25 snarkyboojum joined
kurahaupo msg Whiteknight we don't need a "busy" flag; all we need is an atomic overwrite of the vtable pointer, done twice: the first time points it at a "spin" vtable, all of whose entries do nothing but "yeild" and then re-invoke the same method, and the second is the actual new vtable (or possibly the original one) after all the structural changes have been done. Of course, if we used non-overwrite semantics the whole problem would go away, 06:29
purl Message for whiteknight stored.
kurahaupo aloha msg Whiteknight we don't need a "busy" flag; all we need is an atomic overwrite of the vtable pointer, done twice: the first time points it at a "spin" vtable, all of whose entries do nothing but "yeild" and then re-invoke the same method, and the second is the actual new vtable (or possibly the original one) after all the structural changes have been done. Of course, if we used non-overwrite semantics the whole problem would go 06:34
cotto: does Purl pass messages or am I wasting my time? 06:35
sorear msg kurahaupo yes
purl Message for kurahaupo stored.
plobsing kurahaupo: I got some this evening
06:35 fperrad joined
cotto purl should 06:35
purl cotto: huh?
kurahaupo Well, today wasn't much of a de-lurk after a few months away, but dinner calls. Hopefully I can be a bit more participative soon. Until tomorrow... 06:39
06:40 fperrad_ joined 06:44 parthm left 06:47 aukjan joined
cotto time for sleep 06:51
07:02 s1n joined
dalek tracwiki: v12 | cotto++ | LoritoRoadmap 07:02
tracwiki: add purpose, minor fixes
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
07:16 mikehh_ joined
fperrad ping bacek 07:20
bacek_at_work fperrad, short pong 07:29
fperrad bacek, I miss something when I tried to convert Cardinal to the new NQP, could you take a look ? 07:31
$ parrot cardinal.pbc -e "print 'hello';" # works fine
bacek_at_work fperrad, not now. In about couple of hour after loosing my "_at_work" suffix 07:32
07:52 s1n joined
dalek rrot: r47285 | tcurtis++ | branches/gsoc_past_optimization (2 files):
All tests pass. More attributes tomorrow(fortunately, should be easy). Also, make codetest happy.
 08:03
08:08 viklund joined 08:13 mikehh joined 08:18 jsut_ joined
dalek TT #1658 closed by plobsing++: Change to config hash (45623) broke partcl 08:26
TT #1658: trac.parrot.org/parrot/ticket/1658
08:38 clinton joined
dalek rrot: r47286 | bacek++ | branches/gc_massacre/src/interp/inter_create.c:
Create interp.gc_registery early
 09:58
rrot: r47287 | bacek++ | branches/gc_massacre/src/call (2 files):
Add a lot of assertions to help catching too-early-collected-context failure
rrot: r47288 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Avoid double-initialisation on TMS in child interp.

proper merging of GCs later.
rrot: r47289 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Quick hack - register "constant" pmcs in interp.
rrot: r47290 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
A lot of fixes for TMS.

   marked
  * Don't GC during deinitialise
  * Embed gc_ms_mark into gc_tms_mark for simplicity and performance.
rrot: r47291 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Yay! Final fix for TMS.is_pmc_ptr to properly find all roots!
 10:15
10:19 gbacon joined
bacek msg whiteknight Ignore _no_constant branch. I've made ugly workaround for it. 10:24
purl Message for whiteknight stored.
dalek rrot: r47292 | bacek++ | branches/gc_massacre/src/gc (2 files):
Add List.pop function
 10:31
rrot: r47293 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Minor cleanup
rrot: r47294 | bacek++ | branches/gc_massacre/src/gc/system.c:
Restore calculating of prefix for old MS GC.
rrot: r47295 | bacek++ | branches/gc_massacre/src/gc/list.c:
Make GC.list compilable in optimized builds
tracwiki: v13 | bacek++ | GCMassacre 10:39
tracwiki: Add TODO section for gc_massacre branch.
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
bacek msg mikehh You can start your magical codetest fixing in gc_massacre branch now :) 10:47
purl Message for mikehh stored.
10:47 masak joined
nopaste "bacek" at 192.168.1.3 pasted "It's fast :)" (13 lines) at nopaste.snit.ch/20826 10:52
dalek tracwiki: v14 | bacek++ | GCMassacre 11:13
tracwiki: More todo
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
mikehh bacek: ok - will give it a go 11:19
bacek mikehh, thanks! 11:22
11:31 tetragon joined
dalek nxed: r487 | julian.notfound++ | trunk/winxedst1.winxed:
quick fix for empty argument list
 11:44
11:48 snarkyboojum joined 11:52 kurahaupo joined 12:01 whiteknight joined 12:07 JimmyZ joined 12:08 ruoso joined
whiteknight good morning, #parrot 12:08
JimmyZ morning, whiteknight 12:09
whiteknight good morning, JimmyZ
12:10 bluescreen joined
dalek rrot: r47296 | mikehh++ | branches/gc_massacre/src/gc/gc_tms.c:
fix g++ build failure, remove trailing space
 12:10
12:16 ruoso joined 12:21 davidfetter joined
dalek rrot: r47297 | mikehh++ | branches/gc_massacre (2 files):
some headerizer changes
 12:26
rrot: r47298 | mikehh++ | branches/gc_massacre/src/gc/pool_allocator.c:
add ASSERT_ARGS
rrot: r47299 | mikehh++ | branches/gc_massacre/src/gc/list.c:
add ASSERT_ARGS
 12:43
Coke plobsing++ 12:44
(for TT#906) 12:46
masak since we last spoke, I've (re-)discovered at least two new problems with Parrot and string encodings. I'll see if I can produce short examples of them. 12:49
12:52 Chandon joined
masak actually those were the same issue. you can trigger it by running perl6 -e '"ƶ".encode("UTF-8")' on latest Rakudo. 12:55
the error is 'unimpl fixed_8'
and it seems to occur for all non-ASCII characters. 12:58
is there some fundamental ASCII restriction in Parrot of which I'm not yet aware?
Coke masak: you'll see a lot of NYI in src/strings/*/*.c 12:59
masak ok.
I guess I expected obstacles of this type, to be honest.
that's why I'm glad it's a grant; otherwise I'd proabbly have given up and let someone else solve it. :) 13:00
so, what's my best chance of getting this fixed_8 thing impl? I'm not familiar enough with people's areas of expertise in the project. 13:02
13:02 ComLock joined
bacek masak, src/string/encoding/fixed_8.c, line 179... 13:04
masak looks 13:05
Coke I would recommend opening a ticket with a short example (PIR is best if you can manage it). ... or get bacek's attention.
masak bacek: ok. that tells me only what I already know. :)
Coke: I think I can manage PIR. will create a ticket. 13:06
Coke :q
ww.
13:16 atrodo joined
Coke is this decl right? 13:16
=item B<mul>(invar PMC, invar PMC, invar PMC)
should that first invar be an inout?
dalek rrot: r47300 | coke++ | trunk/runtime/parrot/library/Crow.pir:
Avoid use of deprecated PIR syntax. (can't use assignment syntax here.)
 13:17
bacek Coke, it should be inout (or out). But current runcore doesn't properly distinguish it 13:27
masak here's my ticket. trac.parrot.org/parrot/ticket/1671 13:29
my GSoC work is partially blocking on this issue, so I'd appreciate if someone would have a look at it.
dalek rrot: r47301 | coke++ | trunk/t (2 files):
Avoid use of deprecated PIR syntax. (can't use assignment syntax here.)
 13:33
rrot: r47302 | mikehh++ | branches/gc_massacre/src/gc/list.c:
add documentation
13:34 Chandon joined
Coke bacek: plobsing's recent patch causes $P1 = mul $P2, $P3 to be an error, which I don't think it should be. 13:35
Coke added a note to the ticket.
bacek Coke, just change op.
Coke bacek: someone can, sure. I'm just raising the issue. =-) 13:36
($DAYJOB)
bacek slacker!
Coke IZ NOT ROBOT
plus, someone would really have to review all the opcodes. 13:37
Sure it's not just mul.
dalek TT #1671 created by masak++: Can't encode strings with non-ASCII characters in them 13:42
TT #1671: trac.parrot.org/parrot/ticket/1671
13:50 aukjan joined 13:53 plobsing joined
Coke plobsing: hio. 13:55
13:58 gbacon joined
plobsing hi Coke 14:00
looks like you've been working on the TT #906 test failures 14:01
why does vtable multiply take 3 args anyways?
Coke so you can pass in a destination. 14:03
IIRC.
plobsing yeah, looks that way. Haven't seen that done much in parrot.
particle still, it must be possible, or hll devs will have to code around it 14:05
$P1 = $P2 ; mul $P1, $P3 14:06
dalek rrot: r47303 | fperrad++ | trunk/examples/languages (2 files):
[languages] clean up, now .loadlib could throw an exception
particle or some other workaround, maybe with clone
plobsing yes true. But it does make "$P1 = mul $P2, $P3" invalid by the no input values in assignment op forms 14:07
rule
NotFound Coke: I think there is a lot of 'in' that should be 'inout' in opcodes. 14:08
That can also explain some failures in register allocation, 14:09
plobsing I had a patch against opsc to catch those, but opsc was a little b0rked internally, so it didn't work 14:10
whiteknight the third argument to the various arithmetic vtables is almost universally ignored in practice 14:30
the implementations don't use them, so PIR code doesn't bother with it
it's a huge waste
14:42 tcurtis joined 14:45 patspam joined
NotFound masak: I fail to understand your encoding problem. You can't encode a codepoint > 255 in any fixed 8 way. 14:46
masak then I'm probably slightly on the wrong track.
jnthn NotFound: IIUC, masak wants to be able to get the individual bytes that make up a UTF-8 encoded string. 14:47
masak maybe you can show how I can encode a codepoint > 255 in some other way?
jnthn: yes, but that's a different problem. that's the decoding.
Coke whiteknight: didn't pmichaud disagree with that statement?
masak here I'm just trying to get the encoding right, something I thought already worked.
14:47 bubaflub joined
whiteknight Coke: whether those vtables *should* do something is a different matter. Currently, almost every implementation completely ignores it 14:48
NotFound jnthn: but the ticket is not about what he wants, but about how he does.
whiteknight Coke: I suggest we either change the current implementations to make proper use of the third argument, or we remove the third argument from the spec 14:49
Coke "unimpl" is probably not the right exception for "i can't do that, dave."
whiteknight but having it and ignoring it is not a good thing
NotFound masak: I don't know if it works right now, but if you want a binary string you can't just change the encoding, you must change the charset.
Coke whiteknight: I would have to fact check your statement there before I can agree with what to do next.
masak NotFound: gotcha.
NotFound: are there examples of this kind of conversion (str -> bytes) somewhere in Parrot already? 14:50
NotFound masak: I don't think so, given that until recently all that things barely worked,
masak again, I'm a pioneer. yay. 14:51
whiteknight Coke: hmmm...Maybe it's been fixed. The code I'm looking at now is different from what I remember
Coke: in that case, ignore me
NotFound masak: anyway, I think that the best way to handle such conversions is creating a ByteBuffer PMC. 14:52
masak ok. that is probably a bit beyond my reach, though. 14:53
whiteknight actually, nevermind. I'm finding more broken code in scalar.pmc, which is inherited by float.pmc
so it's only been partially fixed.
NotFound BTW, trans_encoding ascii to fixed_8 is a noop, ascii is always encoded as fixed_8
jnthn NotFound: Would us having a first-cut byte buffer implementation as a dynpmc in Rakudo, that Parrot may then adopt into core if it wishes, be a good way forward? Or do you (or @other) see this being something Parrot does RSN? 14:54
NotFound jnthn: I think parrot need it, but the idea hasn't been discused yet. 14:56
jnthn OK. 14:57
NotFound If you implement it in rakudo with the idea of parrot adopting it later, please make clear that the copyright can be transferred to PAFO.
ash_ how do code reviews work? if I have something i'd like someone else to look at incase they can come up with a better solution, or to make sure i didn't do dumb things, do i just need to ask someone here to look at my code? 15:00
Coke ash_: if you're working on a branch, you can commit first and ask questions later.
if you're /really/ unsure, make a patch hit the list with it. 15:01
*and
ash_ kk
NotFound masak: BTW if you try to trans_charset to binary you get "to_charset for binary not implemented" 15:03
whiteknight ash_: some help is volunteered if somebody is watching. Other help can always be requested 15:04
15:07 theory joined
ash_ is it safe to use Parrot_str_to_cstring and just use a string as a cstring? 15:12
NotFound ash_: "just" and "safe" are usually incompatible ;) 15:13
ash_ I'll stick with the defined string manipulation methods then 15:15
Coke ash_: yah. unless you're trying to pass the string to a C library, that's probably best 15:16
ash_ I am just trying to parse the strings, determining prefix, infix, postfix, circumfix modifiers on base identifiers is trickery than i thought it would be, well i am not using regex's. they would make it easier, but I don't think there is a regex api for the C side of things is there? 15:18
Coke not in parrot, no. 15:21
sounds like you want a grammar in NQP. 15:22
whiteknight a simple regex engine in Parrot might be nice to have for basic string ops 15:23
Coke but would duplicate effort already present in PGE/NQP. 15:24
ash_ Coke: i am working in the C parts of parrot though, not pir 15:26
or any of the other bits, otherwise i would use a grammar
Coke ash_: you can still invoke all that from C.
ash_ hmm good point 15:27
Coke (assuming a built parrot)
er, standard lib.
ash_ hmm i think i'll stick with doing it in C, most of this is not to bad, i know some things about all of my identifiers too, that can help (like they are all 1 char in length, so i don't need to look ahead more than 1 char) 15:28
Coke WFM. 15:29
particle we have index and rindex and substr, write your own regex engine :P
ash_ i'll do that next summer... 15:30
:P 15:31
nopaste "NotFound" at 192.168.1.3 pasted "Patch: to_charset to binary from anything" (40 lines) at nopaste.snit.ch/20837 15:34
NotFound masak: ping
masak NotFound: pong
NotFound masak: does this patch what you want? 15:35
masak looks
it sounds like it could be what I want yes. I won't know for sure until I get a list of bytes out of an arbitrary string, but it looks promising. :) 15:36
ash_ are $I0 registers limited to 32 bits? 15:37
NotFound masak: is just a test, I'm still not sure is a desired feature.
masak NotFound: understood.
purl understood. are you on schedule?
masak purl: forget understood
purl masak, I didn't have anything matching understood
masak purl: forget understood.
purl masak, I didn't have anything matching understood
masak kicks purl
NotFound ash_: if you want to be fully portable, you must restrict to 32 bit values. 15:38
ash_ thats not 100% true... if you overflow 32 bits you can upgrade to a different container that, there are lots of various int containers that support larger integers than your system supports 15:40
NotFound ash_: you asked for a I register, registers aren't containers.
ash_ ah 15:41
i didn't realize that
so you'd have to go to a pmc of sorts then if you want larger than 32 bits?
particle NotFound, ash_, actually it's a compile-time constant, not strictly 32
iirc 15:42
NotFound ash_: unless you want to restrict to 64 bits platforms or parrot configured for that in lesser platforms, yes.
particle and IREGs are subject to platform semantics
overflow, etc
if you want portable, you use PMCs, like Integer or BigInt
NotFound That's the point. If you want to be fully portable, *you* must restrict the usage. 15:43
particle aye
ash_ github.com/ashgti/parrot/blob/gsoc_..._h.in#L118 15:44
i don't think it uses 64 bits on systems that support it yet
15:48 Andy joined
tcurtis ash_: I think that just means that there's no support for explicitly 64 bit registers. It uses long for INTVAL on at least my system. So, if long is 64 bit, all INTVALs are probably 64 bit. 15:49
ash_ long is never 64 bits by definition unless your c compiler isn't following the specs 15:50
long long is 64 bits, long is 32 bits
NotFound ash_: what specs?
purl specs are almost more design than spec. they already know what they want in too much detail. that bodes poorly for the project
ash_ the C spec
NotFound ash_: the C spec says nothing about that. It just says that sizeof long >= sizeof int 15:51
tcurtis I thought those were just the minimum sizes, ash_.
NotFound ash_: and int can also be 64 bits. 15:52
particle yep
NotFound Or more.
ash_ yeah, your right, sorry those are min values, not absolute values 15:53
www.open-std.org/jtc1/sc22/WG14/www.../n1256.pdf sections 5.2.4.2.1 and Annex E say the limits on int are the same as short, but i guess most compilers don't strictly follow the standard 16:06
and i suppose thats c99, not c89 which is what parrot is supposed to follow 16:07
tcurtis ash_: "Their implementation-deļ¬ned values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign." 16:08
ash_ ah, i need to read better 16:09
NotFound ash_: parrot supports C89, and even restricts it to allow C++ builds. 16:15
But the type size limits are the same. 16:16
16:23 theory joined
particle the one extension to C89 i know of is our use of long long 16:24
whiteknight do we use long long internally, or do we just allow it as a confgure option? 16:26
NotFound We don't use long long, we use typedef or macros that may be long long in platforms that have it, that's the trick. 16:28
particle correct, NotFound
NotFound And maybe some conditionally compiled code.
ash_ are there plans to support a long long $I register one day? or should that always be done in a pmc? 16:29
particle if things are working correctly, it can be specified now at config-time 16:30
you'd probably also need to make sure your pointer size is also set to long long, though 16:31
i'm not sure all the intsize==ptrsize assumptions have been excised
whiteknight I'm certain they have not 16:32
NotFound That's a weak point.
ash_ in stdint.h there is intptr_t uintptr_t which are ints that are the right sizes to hold pointers
whiteknight ash_: on Win64 I had to do this dance. perl Configure.pl --intval="long long" -opcode_t="long long"
or something like that, I cant remember the exact names of the options
NotFound whiteknight: Because of some parrot generic thing, or because of the win32 platform specific code? 16:34
ash_ I am mostly interested in this because if you specify something in NCI as a 64 bit value, i will need to put it on the right container/register/object/parrotthing
i am also going to have to figure out a new object for unions 16:35
NotFound ash_: a platform that doesn't have 64 bit ints is highly unlikely to have native interfaces that uses it.
particle ash_: you're going to have to query parrot and see what size IREG is, or stick everything into PMCs
whiteknight NotFound: on 64-bit windows, and the windows compiler, the size of "int" and "long" are both 32 bits 16:36
but pointers are 64 bits
particle and long long is 64 bits
whiteknight on that compiler, to get a 64-bit integer you need to use "long long"
particle: right
NotFound Oh, so nice, back to the times of win16/win32
ash_ Parrot_Int should be the same as $I0 right?
whiteknight ash_: yes
they're all INTVAL
ash_ i wonder why it defaults to i386 on OS X and not x86_64 16:38
NotFound whiteknight: maybe we should tell Configure to use that values as default in that platform, then.
whiteknight NotFound: maybe. It doesn't matter though. Last I checked Parrot didn't work there no matter what I did 16:39
I don't even have a 64-bit windows install anymore
NotFound Looks like our ratio of windows-developers/windows-support-asks is extremely low. 16:40
whiteknight yes, I would agree to that completely 16:44
but windows isn't free, I don't currently have it, and I can't afford to procure a copy
ash_ I can get a copy of it, if I can find a computer to run it on, (i am still in school, and our school provides free copies of xp pro, vista pro, and 7 pro) 16:45
NotFound I have a Vista that came with the machine, but rarely use it and is 32 bits anyway.
whiteknight I had vista that came with my machine, but I tried dual-booting, had problems with GRUB, gave up, and reformatted the whole damn thing 16:46
tcurtis On which note, what's a good Windows IRC client? Assuming I can find an IRC client and editor I like for Windows, I could start developing and testing on 64-bit Windows 7.
NotFound tcurtis: last time I looked, mIRC was the most used. 16:47
moritz tcurtis: I use putty to connect to a linux box, and use irssi there :-)
NotFound And a lot of silly scripts for it X-) 16:48
moritz in a screen session, so that I don't have to restart it every day
Coke joined the POI dev mailing list. just saw: 17:03
Fixed in r950611 17:04
dalek rrot: r47304 | NotFound++ | trunk/t/pmc/resizablepmcarray.t:
tests for RPA delete_keyed, exists_keyed and get_repr vtables
 17:08
17:13 cotto_work joined
whiteknight Coke: .95 million commits? which repo is that? 17:15
bubaflub whiteknight: POI is an apache project that deals with Microsoft Office / Open Office documents 17:16
via java api
whiteknight okay. That's still a gigantic number of commits
bubaflub agreed.
purl msg kid51 thanks for the tip - for now i've overridden the linked libraries in the hints file 17:20
purl Message for kid51 stored.
Coke ugh. very fun trying to bisect through the revisions that tried to delete $PERL. 17:23
(*&#@#
17:29 cotto_work joined 17:45 Chandon joined
dalek rrot: r47305 | tcurtis++ | branches/gsoc_past_optimization/runtime/parrot/library/PAST/Pattern.nqp:
Switch PAST::Pattern to .attr() like PCT::Nodes do.
 17:57
Coke only 13 commits between the TT#389 and immutable strings hitting. blah. 18:01
18:01 cotto_Work joined 18:05 spinclad joined 18:10 joeri joined
Coke plobsing, finally back to the colons issue. =-) 18:16
so, when tt #389 hit, my code that does "set_hll_global 'foo', bar" is now returning NULL whenever I get_hll_global it. 18:17
(and bar is not null when I set_hll_global it.
sorry, I set_hll_global 'foo', bar in HLL baz, and then later do get_root_global ['baz'], foo 18:20
(and of course my 10 line demo PIR program works. bother.) 18:23
18:28 cotto_work joined 18:31 darbelo joined
nopaste "coke" at 192.168.1.3 pasted "this prints "not ok". Should it?" (16 lines) at nopaste.snit.ch/20849 18:39
whiteknight can you store pmcs in the root namespace? 18:41
I would use get/set_hll_global instead, probably
or just get/set_global 18:42
18:58 ilbot2 joined
moderator Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
nopaste "Coke" at 192.168.1.3 pasted "this prints "not ok". Should it?" (12 lines) at nopaste.snit.ch/20850 18:59
dalek rrot: r47307 | NotFound++ | trunk/t/pmc/threads.t:
delete the loadlib myops_ops line that is not used, assumed to be let alone from a previous version
 19:05
pmichaud Coke: I'm needing to build a recent copy of Parrot as well 19:06
whiteknight moritz++ # Runge-Kutta solver
pmichaud one moment
pmichaud has five parallel threads going on right now, starting to thrash.
moritz whiteknight: do you read #perl6? or follow github?
whiteknight moritz: follow github. 19:07
Coke pmichaud: don't worry about it, I'll open a ticket.
whiteknight I follow #perl6 sometimes at home, but at work I only watch #parrot
Coke I'm pretty sure it's a bug.
pmichaud Coke: I should know shortly.
Coke TT #1672 19:10
(There's a stripped down version of the PIR there.)
looks like trac lost its style sheet. 19:12
cotto_work Coke, wfm
whiteknight Coke: don't we have tests similar to that code snippet you posted? Shouldn't something like that have been caught in coretest? 19:13
Coke chrome, then. ah well.
whiteknight: not for subs.
not for subs created dynamically, that is.
would have been caught if partcl hadn't been killed by an earlier commit. 19:14
whiteknight $P1 in your example is a Sub?
Coke an Eval.
whiteknight ah, okay
Coke you could probably get the same effect by going after the PIR compreg and building a sub. 19:15
dalek TT #1672 created by coke++: TT #389 fix introduced regression with globals. 19:16
TT #1672: trac.parrot.org/parrot/ticket/1672
NotFound Coke: looking at what the Namespace PMC does, I think that you are right, its changes caused the problem.
Coke and I see no way to fix it either! =-)
whiteknight dukeleto: ping 19:17
Coke: I think it's becoming pretty obvious that NameSpace PMCs are being tasked with solving too many storage-related tasks 19:18
pmichaud Coke: your code works in 2.3.0
it fails in current trunk
NotFound I don't think this is a storage-related task, is a pir-related task.
whiteknight They store normal :nsentries, they store references to nested sub-namespaces, they store methods (though separately from :nsentry subs) and they store global data
that's quite a lot of things to be storing in a single PMC 19:19
dukeleto whiteknight: pong
whiteknight dukeleto: do you have more info about that bug you mention with dunoplib libraries?
is there a ticket for those?
pmichaud Coke: ah, I see you already detected that it worked in 2.3.0
(sigh)
Coke: no, I don't have a workaround handy. I'm not even sure what's causing the problem. Might be that PGE is missing an :nsentry flag somewhere
whiteknight the damn tt#389 bug is the worst 19:20
dukeleto whiteknight: i talked with chromatic++ about it, he said it is a long standing bug due to dynops being dependent on load order
NotFound whiteknight: I think the problem is that is trying to guess things, instead of receiving enough information about the task asked for. 19:21
Coke pmichaud: check the new sample. it's note PGE at all. :P
dukeleto whiteknight: he said dynops don't have a constant global number, they get assigned them at runtime
Coke *not
it's just the namespace PMC.
pmichaud Coke: it's worth nothing that what comes back from PGE::P6Regex isn't a Sub, but rather an Eval PMC
whiteknight dukeleto, could you create a ticket for it so we can track it and have a record of it?
pmichaud new sample?
Coke pmichaud: yup. namespace is refusing to store any dynamic isasubs.
whiteknight pmichaud: but Eval isa Sub, right?
dukeleto whiteknight: so if you have a PBC with two dynops, then you load them in a different order from another snippet of PIR/PBC, the dynop #'s get confused 19:22
Coke trac.parrot.org/parrot/ticket/1672
cotto_work whiteknight and dukeleto, plobsing is working on that problem
whiteknight cotto_work: okay, that makes me feel better
pmichaud whiteknight: it's a Sub that likely doesn't have any flags, a :subid, a :nsentry, etc.
cotto_work It's not a simple fix though.
Coke pmichaud: and I see no way to add an :nsentry to a sub that is not created via .sub in PIR. 19:23
cotto_work very possible, just not simple
dukeleto whiteknight: yes, will create a ticket
whiteknight cotto_work: no, I wouldn't suggest that it is simple.
pmichaud Eval is a Sub pretty much only in declaration, it doesn't have most of the other things that a Sub PMC now has
Coke pmichaud: check the new sample. =-)
pmichaud Coke: I'm only seeing the one that uses PGE 19:24
cache issue again, perhaps?
nopaste "coke" at 192.168.1.3 pasted "avoid trac cache for pmichaud" (10 lines) at nopaste.snit.ch/20852
19:24 davidfetter joined
dukeleto whiteknight: the thread "[RFC] Dynop Opnum Mapping" talks about the issue 19:25
whiteknight: but the tt# mentioned there is wrong
whiteknight dukeleto: thread in the ml? 19:26
dukeleto whiteknight: yes, on parrot-dev
whiteknight: i think trac.parrot.org/parrot/ticket/1663 is the same issue
whiteknight: but manifests in a different way
whiteknight ok 19:28
davidfetter waves to dukeleto 19:29
NotFound The problem is easy to trigger, just load_bytecode a pbc that have dynops loaded in a different order than the main program. 19:30
dukeleto waves to davidfetter
NotFound A real pbc, hiding the problem by loading the pir is not a solution ;)
davidfetter what's the latest in pl/barratry?
dukeleto NotFound: can you write a test for that? does one already exist?
19:31 mj41 joined
NotFound dukeleto: I'll try to write a short example. 19:31
19:32 Khisanth joined, dmalcolm joined, bluescreen joined
dukeleto NotFound: that would be awesome! 19:32
19:32 japhb joined, patspam joined, jan joined, gaz joined, Andy joined 19:34 s1n joined
nopaste "NotFound" at 192.168.1.3 pasted "Example of dynop loading problem" (17 lines) at nopaste.snit.ch/20854 19:40
NotFound dukeleto: here is
Comment the .loadlib in the main program and works fine. Uncomment it and opcodes magically change meaning. 19:41
19:41 masak joined
whiteknight If I may ask a devil's advocate kind of question, are dynops worth having? 19:43
I mean, there are relatively few of them, few people made any use of them before the os_massacre branch, and the people who are using them now report problems 19:44
NotFound Don't know, I never used it.
cotto_work Are you devilishly advocating using a C library?
whiteknight cotto_work: well, we have dynpmcs which can be written in C and do whatever we need. We have NCI to call C functions. I'm trying to figure out what niche dynops fill, and whether they are worth the effort 19:45
cotto_work they integrate better with Parrot than NCI (and moreso after plobsing's fix) 19:46
whiteknight "better"? How so?
NotFound cotto_work: look at that example and tell me again that they integrate well X-)
cotto_work "easier"
whiteknight I don't agree. I don't think there is any ease-of-use benefit to using them 19:47
They are a pain in the ass to write and compile, a huge pain internally to load them and reallocate the op table, they cause problems in bytecode even considering plobsings patch, etc 19:49
And when you consider how under-utilized they are, maybe it's not worth the development effort to keep them
cotto_work If we want to drop them, we'll have to provide a workable alternative to Rakudo first.
moritz drop what? dynops? 19:50
whiteknight yes, they do have one dynop that they use
moritz: yes
it's just a suggestion, but I don't see a huge benefit to keeping them if they have bugs
if we look forward to Lorito, we're not going to have dynops as they currently exist anyway 19:51
cotto_work they actually have a handful
whiteknight do they? last
i looked they only had 1
cotto_work 72 with all params expanded
19:51 LoganLK joined
whiteknight last I looked, they only had rebless_subclass. The rest of this list is new 19:52
cotto_work 15 distinct ops
moritz some for signature handling
whiteknight if they had a "utilities" dynpmc with methods, they would be able to do all these things still 19:53
some of them look like they could be translated into vtables for ease 19:54
moritz with similar performance?
Coke whiteknight: partcl uses dynops extensively. as does rakudo.
I'm not saying we /have/ to, but they are heavily used currently.
whiteknight Coke: that does take some of the wind out of my argument, but hardly changes my mind 19:55
Coke I know you like to rip stuff out of parrot, but people are using it. =-)
whiteknight Coke: it's not that I like to rip stuff out. I want Parrot to have what it needs, and not be forced to support things that it doesnt
there are lots of things I want to add, for instance 19:56
Coke the thing is, it needs what the HLLs need.
whiteknight if dynops are the best solution to a particular problem, then that's one thing. If they are one possibility among a list of equally-good solutions, that's another
Coke now, I'm not saying in this particular case, that partcl, e.g., needs dynops.
NotFound A possible way to simplify things might be to associate dynops with HLL, not with any PBC loaded.
whiteknight NotFound: another would be to include an opnumber->opname map in the PBC header, so we could do translation later 19:58
NotFound whiteknight: yes, some variants of that were commented in the mailing list. 19:59
TimToady phone 20:00
NotFound And I think some variant of that is the only way compatible with the current usages and implementable in reasonable time.
It will increase the pbc size, but I don't care. 20:01
sorear Why are you ignoring the suggestion round which was done on parrot-dev? 20:02
20:02 Psyche^ joined
whiteknight sorear: what suggestions on parrot-dev? 20:03
nevermind, I see it
NotFound sorear: maybe for fear of people assuming that the ones championing an option must implement it X-) 20:04
Coke Where there's a will, there's a ... benficiary.
*bene
moritz where there's a will, there's a coleda *SCNR*
whiteknight I like the idea of just using a simple opnumber-opname hash, because we can use existing machinery to store that has in the constants table 20:05
or, some other cache-like object to store also a frozen reference to the dynoplib so it can be immediately thawed and loaded when the PBC is read
The biggest problem isn't even storing this information in the PBC anyway, it's arranging the optable at runtime to be what we need. 20:06
I'm wondering what we do if we try to execute an op from PBC which hasn't been loaded yet, but an entry for it exists because a subsequent library has been loaded
NotFound And don't forget that in order to make pbc_disassemble a barely usable tool, it must do something with that information. 20:07
Coke moritz: you mean, it's always christmas when I'm aroudn? 20:09
whiteknight some of these perl6 ops could easily be moved into Parrot. find_method_null_ok and x_setprophash are perfect examples
moritz Coke: the other way round: when it's christmas, you are somewhere
NotFound whiteknight: Making them parrot dynops? =:o 20:10
whiteknight allocate_signature does nothing that new_p_s_i can't do
NotFound: not dynops. Regular, normal built-in ops
transform_to_p6opaque could be turned into a "transform" op in Parrot that does vtable swaps for isomorphic types 20:11
NotFound I think that a way to avoid the null_ok, notnull and such will be to adopt the idea of a Undef type that throws when used for anything other than check for definedness. 20:12
whiteknight NotFound: that too
NotFound Just put in it the appropiate message for the exception, and there is no loss of information. 20:13
20:13 snl joined
NotFound You check the result if you want, and let it throw when used if not. 20:14
whiteknight it's a good idea
20:15 theory joined
NotFound It came from perl6, so it must be good ;) 20:15
dalek p-rx: 8483d1f | pmichaud++ | src/PAST/Compiler-Regex.pir:
Avoid "Can't substr beyond end of string" errors -- if we're already
 20:18
p-rx: 55d87b8 | pmichaud++ | t/nqp/50-regex.t:
Add test for "match beyond end of target" bug.
Coke whiteknight: In my case, I'm storing something /in the namespace/ so I can pull it out of the namespace. I don't see why this needs some other abstraction. 20:22
(re TT#1672)
whiteknight Coke: because lots of things are storing lots of othre things in NameSpaces, and we're running into collisions and problems
I suspect that if we fix your issue, we are going to break part of TT#389 again, and vice-versa
Coke yes, but I'm not.
whiteknight Coke: you're part of the problem because you're trying to store anything in there 20:23
and everything else is trying to also store other crap there too
GeJ Good morning everyone.
NotFound Drop the namespaces and problem solved X-)
whiteknight good morning, GeJ
NotFound BTW, someone has an opinion about my patch in TT #1671 ? 20:26
whiteknight Coke: look at the evil that is NameSpace.set_pmc_keyed_str 20:27
that's the VTABLE that is used for storing everything. It's basically a collection of special-cases
NotFound A problem is that Namespace in practice is not HLL mapable, so it must be all for everyone. 20:29
whiteknight NotFound: part of the reason why it is not mappable is because it relies on all sorts of crap to separate out all these different storage tasks
get/set_pointer_keyed is a perfect example. You can't override that from PIR I don't think
but the NameSpace interface requires it because get/set_pmc_keyed is so overloaded 20:30
if you want to store items of like type by name, use a PMC that's designed to do that, like Hash
anyway, it's time for me to go home now. Later 20:32
20:33 theory joined 20:34 eternaleye joined
Coke once I bandaid the sub issue (by storing it in a RPA and popping it out each time I get it), I am now finding issues with vtable overrides. 20:36
that is less surprising, though.
whoops, this is just a method. 20:37
dalek rrot: r47308 | moritz++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp-rx] update stage0 files with fixes to char classes
 20:45
sorear pmichaud: did you see allison's questioning of the suitability of NQP? 20:50
pmichaud sorear: I did.
I have no immediate comment. I'll let the marketplace decide that question.
so far she's the first person I've heard claim that writing things in PIR was easier/better than in NQP :-) 20:51
darbelo sorear: The suitability of NQP for any given task can't be questioned?
pmichaud (I grant that it may be better in some instances... which is why I still write things in PIR from time to time.)
cotto_work istr that plobsing felt the same way. I remember it because I thought it was unusal. 20:52
sorear darbelo: if NQP's utility for something that it was designed to be is questioned by a credible person, something is Wrong and the NQP pumpking needs to know
cotto_work in his case it was the NCI thunk generator
20:53 patspam1 joined
darbelo NQP is a layer removed from some of parrot's features. It provides abstraction. If you want to get at those features, then you'll find NQP to be in the way. There's nothing surprising about that. 20:55
pmichaud sorear: allison++ and I have long had philosophical differences over the design of the various toolsets; this is likely another example. Thus I think I'll let the marketplace decide this one. If there were any specific items that are "hopelessly byzantine" I'm happy to discuss them, but so far it's just a general claim.
moritz pmichaud: I think the use of curlies is enough for a python fan to call something "hopelessly byzantine" (not entirely serious here :-) )
NotFound cotto_work: plobsing has been assimilated for the Winxed horde X-)
Tene I don't think I remember ever seeing the other side of those, what sort of design allison would advocate.
pmichaud NQP does try to make it possible to get at the features when they're needed, though. 20:56
(in answer to darbelo's point)
granted, there are some places where even that's not possible, but we try to add them in as we can (examples are pir:: and bacek++'s recent work with enabling multisubs) 20:57
bacek morning 20:58
darbelo Sure, but if I know more about parrot than about NQP, then I have to stop and think "How do I get at that from here?"
bacek pmichaud, speaking of which... :)
pmichaud darbelo: yes. But experience with Rakudo has shown that eventually you learn those few cases and then NQP seems preferable (more)
darbelo The first time you use a seatbelt, you have to remember it's there and disengage it before getting out of the car. 20:59
pmichaud an analogy might be "I know more about C than Perl 5... but I have to stop and think 'How do I get at that from here?'"
Tene again, it's a question of optimizing for people who don't know the language.
in some cases, that's great. Many people differ on what cases those are, though.
s/differ/disagree/
darbelo If all you wanted is to get out of the car, the seatbelt is in the way. This is not an argument against seatbelts.
pmichaud at some point I tend to go with Perl 5 because I can be overall more productive with it and remember the paths to the few places where I really need C. 21:00
anyway, NQP and PCT both take an unapolegetically OO look at everything; Parrot doesn't (and that's where a lot of the mismatch occurs). 21:01
dalek rrot: r47309 | darbelo++ | branches/gsoc_nfg/src/string (2 files):
Headerize.
pmichaud so, for example, NQP doesn't have an equivalent of $P0 = new ['FileHandle']
Tene no way to pass a key to pir::new? 21:02
pmichaud and so someone who wants to do things directly on the bare Parrot classes has to do a little work on them
Tene: keys in general are currently problematic (so no)
Tene 'k
sorear however, pir::new will accept a string or RPA equally well
21:03 ash_ joined
pmichaud one can do pir::new(['FileHandle']) or pir::new(['Regex','Cursor']) 21:03
(as sorear++ correctly states)
jnthn NQP supports anonymous array declarators like that?
Oh. :-)
sorear is there any update on the ParrotGrandPlan to deprecate keys in favor of good ol' arrays of arrays? 21:04
21:04 LoganLK joined
sorear jnthn: NQP supports anonymous *arrays* fine 21:04
jnthn Yes, arrays
:-)
sorear it has trouble with hashes, because of the block/hash ambiguity
dalek p-rx: 69506cb | moritz++ | src/stage0/ (4 files):
update stage0 files
jnthn Heh. I could probably clean up some code of mine knowing that...
p-rx: f65cbf3 | moritz++ | (2 files):
second shot at the substr-out-of-range error in <alpha> rule; with test
p-rx: b338c2b | moritz++ | src/stage0/ (4 files):
update stage0 files, again
pmichaud actually, nqp could detect the difference between a block/hash okay also
sorear neither pmichaud nor I are happy with the concept of copying the Perl6 magic hash block
jnthn (that's probably where I go and find I used anonymous arrays somewhere and then forgot 'em... :-)) 21:05
pmichaud the tricky part is that Parrot doesn't have a Pair PMC :-)
sorear NQP supports <Foo Bar> syntax btw
pmichaud I can't complain about that, though, since I advocated eliminating Pair :-)
sorear pmichaud: nqp has syntactic pairs, we use them for named arguments...?
pmichaud named argument != Pair
foo(a => 3) # named argument
21:05 theory joined
pmichaud foo('a' => 3) # Pair 21:05
foo($a => 3) # Pair 21:06
anyway, back in december I looked at adding hash blocks to NQP, but it was non-trivial enough to make me decide to go ahead and wait :) 21:07
moritz speaking of hash blocks... the hash vs. block distinction makes some very nasty rakudobugs these days
sorear I wonder if allison knows about wiki.github.com/perl6/nqp-rx/requests 21:08
jnthn moritz: Such as?
(can take over on #perl6 maybe)
Coke hey, I still have stuff on that list! 21:10
21:10 gbacon joined
bacek pmichaud, any progress with multis in nqp? 21:12
21:13 ruoso joined, theory joined
pmichaud bacek: I'll definitely check it tonight. 21:13
bacek pmichaud, ok :)
atrodo So here's a question. Can I do '$P0 = compreg "nqp"' and get a NQP compiler object? I'm having the hardest time getting it to work
21:14 kurahaupo joined
bacek atrodo, try 'NQP-rx'. 21:14
atrodo, and you do want .loadlib 'parrot-nqp' before it :) 21:15
atrodo bacek> I'm also in 2.3 right now, so I think that makes a difference. Let me try and upgrade real quick 21:16
bacek atrodo, do you have .loadlib 'nqp'?
atrodo Yes
pmichaud atrodo: $P0 = get_root_global ['parrot'], 'NQP' also works.
and it's load_bytecode, not loadlib 21:17
thre is no 'nqp' loadlib afaik
oops
atrodo: $P0 = get_root_global ['parrot';'NQP'], 'Compiler' also works.
sorear AFAIR the compiler's name is "parrot"
not any variation of "nqp"
atrodo Actually, I'm using load_language 'nqp', which does look to work (since the tracing spewed out massive amounts after it) 21:18
pmichaud the nqp-rx compiler is under 'NQP-rx'
dalek rrot: r47310 | moritz++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp-rx] update stage0 files again, with another fix for the <alpha> char class
pmichaud so $P0 = compreg "NQP-rx" should work.
(I didn't want to use 'NQP' because that would conflict with the old nqp compiler from compilers/nqp/. Eventually I planned to make nqp-rx available under both names.) 21:19
I don't think load_language 'nqp' can work, because nqp-rx isn't stored as 'nqp' anywhere.
atrodo It did work because I was using parrot 2.3 21:20
pmichaud ah
then you were getting the old nqp
atrodo but not with compreg. compreg never gave me a non-null pmc 21:21
pmichaud Strange.
purl Strange. are you using the current mod_perl engine and catalyst?
pmichaud old nqp should've been available as compreg 'NQP' in 2.3.0
in fact, NQP itself even uses that 21:22
.sub 'main' :main .param pmc args $P0 = compreg 'NQP'
argh newline fail
Coke I see purl is back. wonder wtf happened.
going to yapc::na 2010?
pmichaud purl, going to yapc::na 2010?
purl wish i knew, pmichaud
pmichaud purl, going to yapc::na ?
purl pmichaud: bugger all, i dunno
Coke wtf. ok, still lobotomized.
bacek purl, purl? 21:23
purl bugger all, i dunno, bacek
pmichaud purl: Okay, so you know "Strange." but nothing else useful. You continue to be an annoyance. :)
purl pmichaud: huh?
bacek purl, purl is little annoying bot
purl OK, bacek.
bacek purl, purl?
purl bacek: no idea
atrodo Ah ha! it's "load_language "nqp" " and "$P0 = compreg "NQP" "
Coke only thing worse than purl is my own infobot. :P 21:24
atrodo That will, complicate, my code since I was planning on using the same string for load_language as compreg. But, what surprises will 2.4 hold for me
Tene atrodo: there are some significant issues with case there. 21:25
HLL namespaces are all lowercased.
pmichaud and NQP comes from before there were any standards on the topic.
Tene with current parrot, if you want this to NOT SUCK, you shouldn't ever have a language name with uppercase letters. 21:26
pmichaud (and I don't know that there are any standards yet on the topic)
atrodo Also, another embedding question, parrot_config.o, can that become a .so or could it not be compiled with PIC? 21:31
darbelo atrodo: What do you want to do with parrot_config.o? 21:36
21:37 theory joined
atrodo Well, I've got a bit of an issue. I'm using kylix (delphi for linux) and it doesn't understand the "__i686.get_pc_thunk.bx" section when I include the .o 21:38
And I have to use it since I'm embedding to get the load_library et. all opcodes to be reasonable 21:39
darbelo Ehm, that is not a library. It's an executable.
Or, it used to be. 21:40
atrodo it's both
sorear __i686.get_pc_thunk.pc is what powers PIC
take it out and you don't have PIC anymore
atrodo Yep, which I think is fine since it gets staticly linked as a .o 21:41
I've turned it into an .so and include it that way as a work around 21:42
darbelo> It's both a executable to get the parrot config options on the command line, but also a .o to include so you can call "Parrot_set_config_hash()" and get libparrot sane 21:44
darbelo atrodo: linking to that yourself is going to hurt later. 21:45
atrodo darbelo> Why? My understand is that's what I'm suppose to do 21:46
darbelo It might help if I knew what you are up to. But if was supposed to be a .so it would be. 21:47
atrodo I'm just trying to embed and interact with parrot in my application 21:48
21:50 eternaleye joined
dalek rrot: r47311 | mikehh++ | branches/gc_massacre/src/gc/pool_allocator.c:
add documentation
 21:51
darbelo And why can't you just use Parrot_set_config_hash_internal? 21:52
I know, it has _internal on it, but it's documented in embed.pod as valid... 21:53
NotFound "Called by Parrot_set_config_hash with the serialised hash which will be used in subsequently created Interpreters." 21:55
You can't just use it. 21:56
darbelo Parrot_set_config_hash isn't in libparrot.
NotFound darbelo: yes, that's the reason to have to link an .o file. 21:57
21:57 whiteknight joined, elmex joined
darbelo The problem is that he can't link to the .o file. 21:57
NotFound darbelo: but if you need the info to call Parrot_set_config_hash_internal, calling it doesn't solve anything. 21:58
bacek mikehh, Parrot_gc_pool_free is actually "Frees a fixed-size data item back to the pool for later reallocation" 21:59
NotFound What I don't know is if there is a reason to not have that info in libparrot or is just an historical artifact. 22:00
darbelo And all Parrot_set_config_hash does is delegate to Parrot_set_config_hash_internal with the data contained in the config fpmc. There's no black magic in there.
NotFound darbelo: the magis is just that you need the .o 22:01
darbelo No you don't. You need the .fpmc, that's where the config data is.
NotFound darbelo: yes, provided that you know where to locate it. 22:02
dukeleto is watching chromatic++ talk at OSBridge
darbelo include/config.fpmc on any installed parrot?
22:03 theory joined
darbelo Or provide your own, if the default doesn't do what you want. An embedder whould be able to choose where he gets his config from. 22:04
s/whould/should/
NotFound darbelo: being able is good. Being forced is not. 22:05
darbelo True. But I think I've already forgotten what my original pooint was. 22:06
sorear dukeleto: Is he talking about anything interesting?
NotFound The point is that the current way sucks, I think.
darbelo So we're agreeing, then! 22:07
NotFound At least! ;)
dalek rrot: r47312 | mikehh++ | branches/gc_massacre/src/gc/gc_ms.c:
add documentation
 22:08
darbelo I remember now! 'Link to a magic .o file' should not be the default way for embedders to get at our config data.
I'm not against keeping it as an option. I just hate it as a default.
whiteknight dukeleto: link to chromatic? 22:10
NotFound I don't like an option like that, except as a last resource. I'd like to have his information, or the minimal part of it requeired to load the rest, available in libparrot.
darbelo The problem with that is that I'd have to recompile libparrot if I want different defaults on my application 22:12
OTOH, some of the stuff we store in that hash shouldn't be on libparrot at all. 22:14
NotFound Not necesarily, you can have the information available without being forced to use it.
Just the path to the default .fpmc should be enough. 22:15
darbelo Parrot_set_config_hash_default() and Parrot_set_config_hash_from_somewhere_else() ? 22:16
NotFound Something like that will be fine, yes. 22:17
darbelo I like that.
22:18 lucian joined, kurahaupo joined
NotFound Also, the ability to load the default and ways to change anything not directly related with the internal of the machine. 22:19
Not being forced to create a .fpmc just to change some path. 22:20
darbelo Good point. 22:21
tcurtis whiteknight: opensourcebridge.org/sessions/399 appears to be the description of his talk.
darbelo "Defeating the Inevitable Zombie Apocalypse with Perl and Parrot"? I want a copy. 22:23
cotto_work darbelo++ 22:24
darbelo chromatic++ # It's his book.
cotto_work btw, this is pretty awesome, pythonic though it may be - github.com/phreeza/cells 22:27
NotFound Is a good title, but I've recently seen "Pride and Prejudice and Zombies" and is hard to beat that X-)
tcurtis cotto_work: The author plans to add support for non-Python languages at some point. news.ycombinator.com/item?id=1395858 22:30
cotto_work so hypontic 22:35
mikehh bacek: gc_massacre branch passes codetest (except c++ comments in src/gc/gc_tms.c) but the documentation probably needs some work (especially in src/gc/gc_tms.c)
22:37 hercynium joined
dalek rrot: r47313 | mikehh++ | branches/gc_massacre/src/gc/gc_tms.c:
add documentation
 22:41
rrot: r47314 | mikehh++ | branches/gc_massacre/src/gc/pool_allocator.c:
correct some documentation
dukeleto whiteknight: opensourcebridge.org/sessions/399 22:52
22:59 kid51 joined
kid51 Why has the appearance of our Trac tickets changed? 23:00
ash_ someone said earlier that a stylesheet wasn't loading right
cotto_work kid51: how?
kid51 Usually, the different sections appear in various boxes 23:01
Most of the boxes have disappeared
Ex: trac.parrot.org/parrot/ticket/1666 23:02
I'm not a CSS guru, but I agree that non-loading stylesheet might explain it
cotto_work looks fine on my end. seems to be an intermittent thing that's covered up by browsers' caching 23:03
ash_ there are no failed loads for me, hmmm
kid51 I just refreshed one page -- and all styling disappeared completely.
ash_ my computer might be caching everything, let me clear my caches 23:04
kid51 And not just on my ticket pages -- ticket query #10 just lost style as well.
In two different browsers, when I refresh, I lose all styles. 23:06
The text is all there, but, jeez, it looks like 1995 html 23:07
In any event -- I take it that the failures in trunk still persist? 23:08
ash_ what browser are you using? 23:09
kid51 I use both Camino and SeaMonkey.
bacek_at_work mikehh, thanks! 23:10
dalek rrot: r47315 | tcurtis++ | branches/gsoc_past_optimization/t/library/pastpattern.t:
Refactor test_attribute_exact_matching_on_node_attrs so it's less redundant and I don't have rewrite everything for each attr.
 23:14
rrot: r47316 | tcurtis++ | branches/gsoc_past_optimization/t/library/pastpattern.t:
Fix node_with_attr_set so that setting "source"/"pos" doesn't crash Parrot.
kid51 many failures in 'make coretest'; this is not good; trunk has been broken for at least 3 days 23:16
It's been a long time since that happened
whiteknight: In your cross-thread data sharing post to list, what does STM mean? 23:18
sorear software transactional memory
atomic { y = x; x = 2; }
23:19 mikehh_ joined
kid51 'make test' at any rate, is passing in trunk 23:24
23:24 kurahaupo joined
whiteknight kid51: Software Transactional Memory 23:32
ash_ is parrot going to try to cater to everyones needs with multi-processing or is it going to have its own opinion on how that should be done? 23:33
cotto_work be careful where you point that loaded question ;) 23:34
whiteknight ash_: it will be all things to all people, and it will shit out gold bricks when you press Ctrl+B 23:36
ash_ just wondering 23:37
mikehh_ make corevm/make coretest FAIL - 44 subtests fail, 208 subtests and 1 test not even run, 1 TODO pass 23:39
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr
t/examples/pod.t - Failed tests: 111-112, 191 in examples_tests
all other tests PASS (pre/post-config, smoke (#34184), fulltest) at r47315 - Ubuntu 10.04 i386 (g++)
ash_ not trying to be mean, its just there are so many different ways of handling concurrency, (see pthreads, haskell, erlang, python/ruby, etc.) 23:40
whiteknight ash_: Chandon's GSoC project is to implement a hybrid threading system.
there has been some speculation that in the future we may want something like Erlang's actors model, if we can find a good way to make it work with CPS 23:41
23:42 tetragon joined
cotto_work Yay. I get to see the css-less trac site too now. 23:43
23:43 theory joined
cotto_work I find myself caring surprisingly little. 23:44
whiteknight it's not like Trac was a beauty queen before 23:45
sorear so now everybody gets to share in my delights as an elinks user?
(what happened?)
dalek tracwiki: v13 | cotto++ | LoritoRoadmap 23:47
tracwiki: add concurrency
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
ash_ Hmmm, I still get all of the style sheets 23:54
whiteknight me too 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!