Parrot 3.6.0 "P�jaros del Caribe" released | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 5 August 2011.
davidfetter attended one of those in '08. it's been too long 00:02
dalek kudo/nom: 6e78299 | tadzik++ | src/ (3 files):
Apply the doc trait only for the documented objects
 00:05
rrot/soh-cah-toa/hbdb: 1f7aeb5 | soh_cah_toa++ | / (4 files):
Initial implementation of breakpoints using PC value. It *actually* works. :D
 00:19
rrot/soh-cah-toa/hbdb: 124a205 | soh_cah_toa++ | / (5 files):
Initial implementation of 'backtrace' command. Also fixed how command abbreviations are interpreted.
rrot/soh-cah-toa/hbdb: 290143d | soh_cah_toa++ | src/hbdb.c:
Removed some *really* unnecessary inline comments.
rrot/soh-cah-toa/hbdb: 94a7be0 | soh_cah_toa++ | src/hbdb.c:
Removed definition of INTERP_ATTR since it's no longer needed.
rrot/soh-cah-toa/hbdb: 70b081a | soh_cah_toa++ | / (2 files):
Moved macro and type definitions to include/parrot/hbdb.h as this is a more appropriate place for them.
rrot/soh-cah-toa/hbdb: f3a79cd | soh_cah_toa++ | / (2 files):
Initial work on ranges for 'list' command. Incomplete but mostly works except for numbers < 5.
tadzik oho, soh-cah-toa's back :) 00:21
dalek rrot/soh-cah-toa/hbdb: ee10b3a | soh_cah_toa++ | src/hbdb.c:
Vertically align hbdb_cmd_t definitions.
 00:26
kudo/nom: b1c1886 | jonathan++ | src/binder/bind.c:
Unlike arrays, Parrot Hashes deep clone, which does the very wrong thing if you just want shallow. Fixes nested signatures involving nameds.
 00:38
kudo/nom: 0d9382f | jonathan++ | src/core/Mu.pm:
Mu.Capture, which coerces to a Capture based on the public attributes.
kudo/nom: 65f9068 | jonathan++ | t/spectest.data:
Run S06-signature/tree-node-parameters.t
kudo/nom: 5972bb9 | jonathan++ | src/core/Any.pm:
Add eqv case for Capture. Oddly, if you try and eqv the same Capture with itself it comes back as False; I fear some list nommage is going on somewhere.
kudo/nom: 3aafdc9 | jonathan++ | NOMMAP.markdown:
Update nommap.
 00:42
kudo/nom: e084f6a | jonathan++ | .gitignore:
Add Pod/To/Text.pir to .gitignore.
 00:47
00:49 whiteknight joined
whiteknight good evening, #parrot 00:53
cotto_work hi whiteknight. How's the new house going?
whiteknight it isn't
dalek kudo/nom: 46c05e2 | jonathan++ | src/binder/bind.c:
Unbust hash part of |$c binding in signatures.
 00:55
kudo/nom: e606577 | jonathan++ | NOMMAP.markdown:
Another nommap update.
cotto_work whiteknight: blargh.
whiteknight that's what I said
plus, curse words 00:56
dalek sella/gh-pages: eeb7306 | Whiteknight++ | libraries/ (2 files):
Flesh out template and utilities pages
 01:04
cotto ~~ 02:01
02:18 kurahaupo joined 02:38 elmex joined 02:45 davidfetter joined 03:39 theory joined
dalek website: soh_cah_toa++ | IMCC Wars: Episode IV - A New Hope 04:18
website: www.parrot.org/content/imcc-wars-ep...v-new-hope
cotto hope is good 04:27
04:38 evhan left
dalek kudo/nom: 11d46b3 | pmichaud++ | src/Perl6/Actions.pm:
More hyper metaop code, still not complete.
 05:04
dukeleto msg soh_cah_toa nice blog post 06:19
aloha OK. I'll deliver the message.
06:40 fperrad joined 06:55 woosley joined 08:03 Kulag joined 08:08 mj41 joined 08:16 Kulag joined
dafrito I noticed that the generated PIR for the lua grammar is like, 14k lines. This seems a little excessive, esp. considering lots of it is repetitive 08:19
Am I crazy for wanting to tinker with the PGE source?
sorear Yes. 08:30
PGE is officially unmaintained.
You should consider moving it to NQP or NQP-rx
cotto dafrito, PGE is in update-only mode. We'll keep it running, but nothing more. 08:33
not quite unmaintained, but close 08:37
dafrito cotto, sorear ah, okay, I'll look into those then. lua's compiler uses PGE and TGE. So it'd be beneficial to port that stuff to NQP, right? 08:40
that stuff = lua's compiler
cotto dafrito, it'd be a substantial project 08:41
i.e. complete rewrite
dafrito cotto, hmm, yeah :/ 08:45
cotto btw, thanks for the m0 comments 08:46
dafrito no problem, they weren't groundbreaking by any means ;) 08:47
I look forward to reading the mole spec when it comes around
cotto If you ever wanted to help write a language spec, now's a good time to jump in. 08:48
dafrito cotto, well, honestly, I'd love to. I'm really green when it comes to parrot internals, though. I've mostly just been scouring all the available docs and planet parrot 08:58
and trying to find books on language and compiler design
cotto There's a lot to be said for learning by doing. 08:59
09:03 SHODAN joined
tadzik hello #parrot 09:29
09:32 whiteknight joined
whiteknight good morning, #parrot 09:37
soh_cah_toa++ 09:38
dalek kudo/nom: 3853e1b | jonathan++ | t/spectest.data:
Disabling S02-builtin_data_types/instants-and-durations.t - it reliably hangs for me during the spectest run.
 09:48
10:04 Kulag joined 10:08 Kulag joined
dalek sella/gh-pages: f0f9366 | Whiteknight++ | libraries/template.md:
Fix doc typo
 10:15
dafrito I'd kind-of like to add this diagram to the PCT tutorial: files.dafrito.com/parse-process.png It lists these stages in ep2, and I think an image might be easier on the eyes 10:22
whiteknight dafrito: it's nice, simple, straightforward. I like it 10:23
Add it in, open a pull request
dafrito whiteknight, thanks, will do
10:23 Kulag joined
whiteknight msg NotFound I added a prefix:* operator, which is the same as "using" but an expression: github.com/Whiteknight/winxed/comm...163d04effe 10:24
aloha OK. I'll deliver the message.
whiteknight say(*Rosella.Query.as_queryable([1, 2, 3, 4]).fold(->(s, i) s + i).data()); 10:25
dafrito What should the image URL be? I can easily get it to work locally, but I don't know how that will translate to docs.parrot.org
whiteknight dafrito: let me look. We had another docs image somewhere that you can copy
dafrito whiteknight, oh, nvm, I think I found out how to do it 10:26
whiteknight ok
dafrito pdd15 has an image 10:27
an image that lives in the same directory*
whiteknight yeah, that's the example I was looking for
although, that image doesn't appear to show up on docs.parrot.org 10:28
I'm not expert on the POD used here, or the way it's converted to html 10:30
10:31 woosley left
dalek rrot: 908cd83 | (Aaron Faanes)++ | examples/languages/squaak/doc/tutorial_episode_7.pod:
PCT tutorial: Added a missing space in episode 7
 10:33
rrot: 6801e9a | (Aaron Faanes)++ | compilers/pge/README.pod:
Noted that PGE is in update-only mode
rrot: 2225670 | Whiteknight++ | / (2 files):
Merge pull request #145 from dafrito/doc_fix

Doc fix from dafrito++
10:38 lucian joined
dalek kudo/nom: 614236f | jonathan++ | src/core/Capture.pm:
Avoid usage of $capture.list eating the $!list in Capture by shallow cloning (pmichaud, please review).
 10:39
NotFound whiteknight: ping 10:40
10:42 Kulag joined
whiteknight NotFound: pong 10:47
NotFound whiteknight: I'm wondering about the semantics of that operations. The point is how to be able to specify when we want a function call or a method call. 10:49
If we have a.b.c(), we may wan the method c in the object pointed by the variable a.b, or the function c in the namespace a.b 10:51
lucian NotFound: i don't think it's possible to do that with a single syntax in a language that has both functions and special (non-function) methods 10:54
NotFound lucian: actually we do, but only when we have compile time information of the identifiers involved. 10:55
lucian NotFound: right. and for that i think a module system is necessary
whiteknight NotFound: Right, the *operation is a namespace lookup 10:57
without the *, it's a method call, or a function call pre-declared with using
We can come up with any other syntax we want, of course 10:58
I could move it to a lower precidence, so you would almost be forced to write (*Foo.Bar.baz)() instead of just *Foo.Bar.baz() 10:59
lucian (Foo.Bar.Baz)() looks better to me 11:00
it's very clear that the first is something, and it then gets called
whiteknight lucian: That wouldn't work. The parser would probably try to treat that like an attribute lookup instead of a method lookup
NotFound whiteknight: yes, I was wondering about possible diffreences in semantic depending on the precedence
lucian whiteknight: i know, sadly * is necessary
whiteknight or, we could do something similar in spirit to what NQP does, and use a different separator for namespace lookups 11:01
lucian wishes more languages treated methods as attributes
whiteknight Foo::Bar::baz(), or Foo->Bar->baz(), etc
that's ugly, but distinct
NotFound The problem is that with the parenthesis in (Foo.Bar.Baz)() the parsing is the same as without them.
whiteknight already knows lucian's opinion of the :: syntax
lucian whiteknight: :) 11:02
whiteknight We could use & instead of *. Both of them are C++ish 11:03
lucian could we get away with :Foo.Bar.Baz ?
whiteknight or, we could use comma: Foo,Bar,baz()
though, that's not very visually distinct and harder to read
tadzik backslashes :> 11:04
lucian Foo:Bar:Baz?
whiteknight ["Foo","Bar","baz"]()
lucian tadzik: or forward? Foo/Bar/Baz
whiteknight Foo\\Bar\\baz()
or, unicode Foo{LOWER CASE Q WITH UMLAUT}Bar{LOWER CASE Q WITH UMLAUT}baz()
lucian whiteknight: how about that literal instead of the actual unicode char? :) 11:05
whiteknight lucian: sure. These are all equally bad ideas :)
NotFound Mmmmm... I think I've already have a way, even if ugly, to specify method call: a.b.*"c"(); 11:06
lucian that is ugly, yes
whiteknight <Foo.Bar.baz>() 11:07
NotFound I'm starting to think that the better solution will be: in absence of information, assume namespace lookup for a function. 11:08
That way we don't vene need syntax.
whiteknight that gets rid of most uses of "using <IDENTIFIER>"
NotFound That is: a.b.c() means a::b::c() if a is not known at compile time. 11:09
whiteknight the only time we would need a syntax is if we had a local variable with the same name as a namespace
lucian NotFound: i like that. i'm not convinced fully qualified method calls are necessary
whiteknight lucian: think class A{ var b }, where b is an object. a.b.c() is a method on b
NotFound whiteknight: if you have a local variable with the same name, just rename it ;) 11:10
lucian whiteknight: right
whiteknight NotFound: that's what I'm thinking. I name all my namespaces with TitleCase, and all my variables with lower_case, so it's not an issue
lucian could local variables just shadow namespaces?
it's familiar behaviour from closures 11:11
whiteknight that's what it would be. the parser would fallback to namespace lookup IF a variable with that name wasn't available locally
lucian right, sounds good to me 11:12
whiteknight That would also remove the need for forward declarations of functions
NotFound whiteknight: not at all. Forward declarations allows re-scoping with 'using namespace', which allows cleaner and shorter code. 11:13
whiteknight you're right. It changes from a "need" to a "want" :) 11:14
NotFound Ah, yes.
whiteknight InternalError('Bad thing'); 11:16
I like that
NotFound whiteknight: sometimes I write such things for temporary tests, and then forget to change it. Is some cases it must be "assertion failed" 11:18
whiteknight NotFound: so where do these changes need to be made, MemberExpr and CallMemberExpr?
NotFound whiteknight: yes, but it may be some corner case in other parts, not sure yet. 11:20
whiteknight ok
this task might be beyond my skill 11:21
or, my current knowledge of winxed
NotFound An additional problem is that I don't have enough tests to cover all the current functionality, so changes are risky. 11:22
whiteknight so we need more tests?
NotFound Alway. 11:23
11:23 Kulag joined
NotFound Maybe the easier way will be: break things, and when people complain add regression tests ;) 11:23
whiteknight shoot yourself in the foot first, ask questions later. I like it 11:24
NotFound BTW someone has reviewed the NotFound/nci_as_string branch? 11:25
whiteknight I will look at it now 11:27
NotFound: it looks nice and easy. The only concern I have is that strlen might fail on wchar_t strings 11:37
NotFound whiteknight: is nci, you should know what you are doing.
whiteknight true
merge it. Fix problems later
I may want to try and merge whiteknight/imcc_tag branch soon too 11:38
NotFound Maybe to make easier to diagnose mistakes we can check that the ecnoding is compatible with C strings.
whiteknight NotFound: _str_vtable has a "scan" method which looks like it does what we want 11:41
actually, maybe not 11:42
11:42 Drossel joined
NotFound whiteknight: I've thought about adding a pseudo encoding name called "guess". 11:42
whiteknight We might be able to add a new method to the _str_vtable to scan_raw
NotFound But for a now, I think corner cases can be worked by using binary, and then either looking at the raw bytes or try some trans encoding. 11:43
whiteknight yeah, doing this "right" is going to be a lot of work, but for now we can pass use-cases doing it the fast way 11:44
NotFound Looking at the raw data is easy via ByteBuffer
whiteknight okay 11:45
NotFound Or using sustr and ord in the binary encoded string.
whiteknight true 11:46
NotFound So, we have good building blocks for a lot of things, maybe even open the way for the "Killer App" ;) 11:47
11:48 Kulag joined 11:53 lucian joined
whiteknight plobsing++ 11:53
(I hadn't really looked at his contributions to the whiteknight/imcc_tag branch before)
11:55 kurahaupo joined
dalek rrot/NotFound/nci_as_string_ready: f68edf1 | NotFound++ | / (4 files):
Merge branch 'NotFound/nci_as_string' into nci_as_string_ready
 11:59
12:03 Eclesia joined
Eclesia hi 12:03
12:03 Kulag joined
dalek Heuristic branch merge: pushed 25 commits to parrot/whiteknight/imcc_tag by Whiteknight 12:04
whiteknight hello Eclesia
12:04 SHODAN joined
dalek rrot: f68edf1 | NotFound++ | / (4 files):
Merge branch 'NotFound/nci_as_string' into nci_as_string_ready
 12:07
12:09 ambs joined 12:44 JimmyZ joined 13:01 PacoLinux_ joined 13:07 Eclesia left
dalek rrot/whiteknight/imcc_tag: 00bd560 | Whiteknight++ | / (4 files):
rename subs_by_flag -> subs_by_tag, to be more synchronous with the :tag syntax
 13:22
13:32 PacoLinux_ joined 13:37 JimmyZ joined 13:50 kurahaupo joined
dalek nxed: 4638dd9 | Whiteknight++ | winxedst1.winxed:
Add in a SimpleReturnStatement which is like ReturnStatement but parses only a simple, single return value. Use this to cleanup the new lambda syntax with implicit return, and make it work more like a normal expression:
 14:04
nxed: b4cbf9c | Whiteknight++ | / (20 files):
Merge branch 'master' of github.com:Whiteknight/winxed
nxed: 88f8f69 | Whiteknight++ | winxedst1.winxed:
Add prefix-* as a function lookup operator, similar to 'using' but an expression. *Foo.Bar.baz(), etc
whiteknight dafrito 14:08
: I'm already tired of merging your work. We need to get you a commit bit
dafrito whiteknight, haha, I'm sorry 14:10
dalek rrot/dafrito_doc_fixes: 022e217 | (Aaron Faanes)++ | tools/docs/make_html_docs.pl:
make_html_docs: moved deglobbing code into separate function
rrot/dafrito_doc_fixes: ee7c4e3 | (Aaron Faanes)++ | / (2 files):
make_html_docs: resources are now copied to $target_dir
rrot/dafrito_doc_fixes: 1a0ab88 | (Aaron Faanes)++ | lib/Parrot/Docs/PodToHtml.pm:
PodToHtml: generate a title from the filename if one isn't given

We depend on a title being present when we list it in index files, otherwise the file shows up as the empy string. This generation code isn't meant to be perfect; it just provides a more useful default than
  'untitled' or ''.
whiteknight :) it's a good thing to be sorry about
dalek rrot/dafrito_doc_fixes: c9b3ea4 | (Aaron Faanes)++ | docs/index/pct_tutorial.json:
Removed underscore from 'PCT_Tutorial' title
rrot/dafrito_doc_fixes: 6780a31 | (Aaron Faanes)++ | docs/project/release_manager_guide.pod:
release_manager_guide: decapitalize title

The pod2html generation doesn't recognize all-caps heads as titles, so this document disappeared from the index page, and appeared as untitled everywhere else. Plus, the other Parrot guides aren't capitalized either, so it's also a bit more consistent.
rrot/dafrito_doc_fixes: b95189d | (Aaron Faanes)++ | examples/languages/squaak/doc/tutorial_episode_1.pod:
Renamed ep1 to exclude 'PCT Tutorial'

This already included in the breadcrumb and other links that refer to this tutorial, so I figure it can go.
rrot/dafrito_doc_fixes: 867336d | (Aaron Faanes)++ | / (4 files):
pct_tut - ep2: add image, reworded surrounding paragraphs for clarity

Minor rephrasing, just so the image flows better with the surrounding content.
whiteknight dafrito: In your next commit, add an entry for yourself in CREDITS
so you get proper attribution
dafrito whiteknight, I didn't anticipate more doc fixes so soon, but I wanted to get the image stuff in. If I had known, it would've just been one pull request
whiteknight, will do :)
whiteknight no big deal. I'm only joking. We like pull requests :) 14:12
I pulled this one into a branch, so the perl guys can test out the pod2html stuff
I'm not a perl guy, so my eyes go all cross-eyed
msg kid51 when you get a spare moment can you take a look at the pod2html changes in dafrito_doc_fixes? Reviewing that is above my head. 14:14
aloha OK. I'll deliver the message.
14:59 JimmyZ joined 15:34 SHODAN joined
dalek kudo/nom: b3a247b | Coke++ | t/spectest.data:
passed some tests, update failure modes
 15:47
15:54 PacoLinux_ joined 15:57 woosley joined
benabik o/ 16:01
16:07 whiteknight joined, preflex joined 16:08 lucian_ joined 16:09 lucian_ joined
dukeleto ~~ 16:15
dalek p: 1f94461 | jonathan++ | src/ModuleLoader.pm:
Start to re-work module loading a bit in preparation for changing install approach.
 16:17
p: 7392f50 | jonathan++ | tools/build/Makefile.in:
Sketch out how make install should probably look once he changes all work.
p: c82c723 | jonathan++ | tools/build/Makefile.in:
Need NQP_LANG_DIR defined, of course.
p: 2ae55b1 | jonathan++ | tools/build/Makefile.in:
PAST library still needs to go in Parrot library directory.
p: 314b2df | jonathan++ | src/ModuleLoader.pm:
Remove debugging output.
p: 2bd6964 | jonathan++ | src/ModuleLoader.pm:
Unbust build after make install has been run. Essentially, the updated module loader dropped any --library far too eagerly - we use it for the bootstrapping rounds, so it needs careful attention.
p: 06b6cfc | jonathan++ | src/stage0/ (7 files):
Update bootstrap with updated module laoder; all seems well.
kudo/nom: 9bec8df | jonathan++ | tools/build/Makefile.in:
Start getting the install target more in shape - certainly not finished yet, and relies on NQP updates.
 16:20
kudo/nom: b4c471b | jonathan++ | tools/build/NQP_REVISION:
Get NQP installation and module loading improvements. With this, we now have a 'make install' that installs a Rakudo that will start up, though the setting and module installation is still to do. Nuking your install directory is recommended.
Heuristic branch merge: pushed 74 commits to parrot/whiteknight/tt_1910 by Whiteknight 16:28
Heuristic branch merge: pushed 67 commits to parrot/whiteknight/frontend_parrot2 by Whiteknight 16:29
cotto ~~ 16:40
16:40 kid51 joined
dukeleto is TreeUnit complete vaporware ? trac.parrot.org/parrot/wiki/TreeUnit 16:43
dalek kudo/nom: 66e0e4e | kboga++ | src/core/Match.pm:
add Numeric method for Match objects
 16:44
kudo/nom: 6d7af58 | (Carl Mäsak)++ | src/core/Match.pm:
Merge pull request #34 from kboga/match-numeric

Match numeric
TT #2173 created by dukeleto++: parrot_debugger --help coredumps 16:45
TT #2173: trac.parrot.org/parrot/ticket/2173
16:45 SHODAN joined
dalek rrot/nqp_pct: 9302f38 | benabik++ | compilers/pct/src/PCT/HLLCompiler.pir:
Tabs -> spaces in PCT::HLLCompiler
 16:56
kid51 dafrito ping 16:57
whiteknight ping
dafrito kid51, pong 16:59
kid51 whiteknight asked me to review parts of dafrito_doc_fixes branch.
How do you want me to transmit review? email? nopaste? parrot-dev? 17:00
dafrito kid51, unknown what whiteknight preferred; as for me, email or parrot-dev is most convenient 17:02
I'm not too familiar with perl, so my modifications to the script might be suspect 17:03
and I modified bits of your excellent PCT tutorial 17:04
kid51 email sent; have to leave, be back tonight 17:10
dukeleto msg kid51 commenting on the github pull request is the preferred review method 17:15
aloha OK. I'll deliver the message.
dukeleto dafrito: what else are you hacking on now? 17:16
dafrito dukeleto, I'm applying the changes from his review 17:17
dukeleto dafrito: where is the review? 17:18
dafrito which is stuff in PodToHtml and the make_html_docs script - he emailed it to me and whiteknight 17:19
want me to c/p it to the pull request?
dukeleto, here it is: files.dafrito.com/dafrito_doc_fixes.review.txt 17:20
dalek kudo/nom: 033e420 | pmichaud++ | src/core/metaops.pm:
Initial version of hyper metaop. Mostly works -- doesn't support hyperop on hashes yet.
 17:23
dukeleto dalek: i disagree with his last review comment. I would leave the use File::Basename import alone 17:36
dafrito: ^^^
whiteknight dukeleto: I already pulled the request, into the branch
dukeleto dafrito: i think if you just add a tiny bit of docs for the canonicalize function, it is ready to be pulled in 17:37
whiteknight: i find that pulling pull requests into a branch makes things confusing. Then the tools/dev/merge_pull_request.pl script can't be used
whiteknight Having a branch from a non-contributor is more confusing than any branch made by a normal contributor? 17:38
dukeleto whiteknight: now we have an open pull request ( github.com/parrot/parrot/pull/146 ) with no mention of which branch you put it on
whiteknight: it is confusing to have open pull requests that are in a branch but no mention of it 17:39
whiteknight oh, the pull request is still open? I thought it would close
I'll wrap that up
dukeleto whiteknight++
whiteknight: in the future, i think having the review comments on the actual pull request is better, so all parrot contributors can see them 17:40
whiteknight: instead of kid51 emailing it
whiteknight I think I would prefer something more standard and unified. When we need a branch reviewed normally, we don't open a pull request for it 17:41
merging a feature set into master should be done a similar way no matter who is writing it
I mean, pull requests are nice, but they're hardly standard 17:42
dukeleto whiteknight: yeah, my opinion is that our current "method" of reviewing branches is pretty erratic and non-standard. I am of the opinion that we should use pull requests 17:43
cotto whiteknight, standard to whom?
whiteknight cotto: Standard, as in its the same process for all merge reviews
dukeleto pull requests allow all parrot developers to comment on something and organizes all those comments directly on the code they are about 17:44
instead of having a branch here, and email there, an irc conversation there, which are all disjoint and hard to search/read/understand
cotto I'd like to see us standardize on pull requests, though it'd need discussion at a #ps
dukeleto cotto: +1 to that 17:45
whiteknight for instance, I sent out an email today about reviewing the whiteknight/imcc_tag, and that review is clearly not going to happen through a pull request
17:45 ambs joined
whiteknight so if we're going to do pull requests, the standard place to be doing development would be in forks, not branches 17:46
cotto whiteknight, not necessarily. You can send a pull request for a branch. 17:47
whiteknight oh wait, I just saw that feature 17:48
okay, let me do
cotto which is great. Going from branches to forks would be a non-starter.
(exclusively)
whiteknight I've thought about doing more of my development in a fork, to avoid the need to prefix all my branches with whiteknight/
dukeleto whiteknight: i don't think that is necessary 17:49
whiteknight: you don't need to prefix branches with your nick, it is just a convention, which we can change if you think that is necessary
whiteknight: for instance, the m0-* branches don't have a nick/ prefix, because no single dev "owns" those branches 17:50
whiteknight: the way i see it, username/foo says "talk to username before hacking on this branch"
whiteknight: feel free to not use the username/ prefix
whiteknight bleh, we do need some kind of organization. We have like 70 branches right now 17:52
some of which really do need to be culled
dukeleto whiteknight: yes 17:54
whiteknight having more people do at least early development in forks would help decrease this strain
not that it's a huge amount of strain, but searching branches on github is obnoxious 17:55
dukeleto whiteknight: some are historical branches that will never be merged. I have thought previously that we could create a parrot-museum repo, which contains those historical branches, and then we can remove them from parrot.git
whiteknight I like that idea, in theory
dukeleto whiteknight: the first step in doing that is identifying branches we never intend to merge. That info isn't written down anywhere
whiteknight Anything that hasn't been touched in a year or longer would seem like good candidates 17:56
dukeleto whiteknight: but a good rule of thumb is: if it is older than 6 months old, it has very little chance of being merged, unless it is a trivial doc change that was forgotten or something like that
cotto dukeleto, are the smoke-me branches deletable?
dukeleto cotto: yep
cotto two down 17:58
dalek Heuristic branch merge: pushed 1500 commits to parrot/whiteknight/eh_subclass by Whiteknight 18:00
whiteknight I'm getting all the branches I intend to work on updated to master 18:01
18:01 PacoLinux_ joined
cotto whiteknight++ 18:02
github++'s branch list will make this much easier
dukeleto also, everyone should know about git branch --no-merged 18:03
it shows branches which are not merged to HEAD, so if you are on master, it shows branches not merged into master
cotto dukeleto, what does that do?
dukeleto git branch -r --no-merged shows remote branches not merged into master
without -r, it only shows local branches not merged into master 18:04
dalek rrot: 95160c0 | dukeleto++ | docs/project/git_workflow.pod:
[doc] How to find unmerged branches
 18:07
18:22 woosley left
dafrito dukeleto, should I reissue my pull request for my revised branch? 18:26
I guess anyone can answer that, actually ;)
18:27 darbelo joined 18:36 mj41 joined
whiteknight dafrito: sure, that would be easiest, I think 18:40
dafrito whiteknight, done, thanks :) 18:51
whiteknight dafrito++ 18:56
dukeleto revies whiteknight's pull request 19:19
reviews, even
whiteknight first of many to come
dalek rrot/whiteknight/tt_1910: 796e991 | Whiteknight++ | / (7 files):
Move remaining functions out of embed.c. move packfile-related functions to src/packfile/api.c. Move disassembly-related functions into a new disassemble.c
rrot/whiteknight/tt_1910: 1cb5265 | Whiteknight++ | / (2 files):
Remove unused, empty embed.* files
rrot/whiteknight/tt_1910: c989e15 | Whiteknight++ | / (42 files):
Remove embed.h (and all traces of it) and embed.c. Get things building again
whiteknight I don't want it pulled yet, I mostly just want review 19:20
and I can do the pulling myself, obviously, once it's been reviewed
dukeleto whiteknight: forgive me if some of my pull request questions are dumb. I am merely a novice when it comes to IMCC stuff 19:26
whiteknight it's okay. I'm going to answer them as soon as firefox un-craps itself and loads the page
that's a technical term
I *really* wish there were a way to tell github to ignore compilers/imcc/imcparser.c and compilers/imcc/imclexer.c in diffs 19:29
or any generated file, really
lucian whiteknight: i think the solution is to just not put them under version control
whiteknight lucian: I'm not entirely against that approach, but it would add flex and bison as prereqs for all parrot developers and anybody building it from source 19:30
lucian and if it's convenient to have them there, they could be added back in as git submodules
whiteknight and that's onerous on windows, etc
dukeleto whiteknight: i recently upgraded to Firefox 5 and I was amazed at the speed improvement and hated myself for waiting so long 19:33
whiteknight: i use a ton of add-ons and they all still work in FF5
lucian dukeleto: sadly, not on arm. or maybe i have an old ff?
dukeleto i think there may be a way to tell github to ignore diffs of certain files 19:34
lucian oh yeah. i have 3.6 ...
dukeleto lucian: 3.6 is a slug
lucian dukeleto: yeah, but it's what maverick comes with
and no ppas for arm
dukeleto lucian: what "arm" machine do you have? 19:35
lucian dukeleto: efika mx netbook
cotto dukeleto, any thoughts on github.com/parrot/parrot/compare/m...gci_tt1199 ? It looks like one of the gci tasks that fell through the cracks. 19:36
dukeleto whiteknight: ok, i am done adding dumb questions to your pull request 19:37
cotto: i vaguely remember something about making it optional/having a flag for that and having some documentation for it 19:38
lucian dukeleto: Freescale i.MX515 (ARM Cortex-A8 800MHz) www.genesi-usa.com/products/smartbook
dalek rrot/dafrito_doc_fixes: d577fbb | (Aaron Faanes)++ | examples/languages/squaak/doc/tutorial_episode_4.pod:
pct_tut - ep4: added a few newlines
 19:40
rrot/dafrito_doc_fixes: 81f4bd8 | (Aaron Faanes)++ | lib/Parrot/Docs/PodToHtml.pm:
PodToHtml: Documented the title-generation code

A real-world example of this code in action would have been the commit 6780a31e8e5 where "RELEASE MANAGER GUIDE" was not recognized.
rrot/dafrito_doc_fixes: a822e17 | (Aaron Faanes)++ | tools/docs/make_html_docs.pl:
make_html_docs: move both functions beneath exec'd code
rrot/dafrito_doc_fixes: e0ba9b3 | (Aaron Faanes)++ | tools/docs/make_html_docs.pl:
make_html_docs: Lots more doc, explained JSON syntax/process
rrot/dafrito_doc_fixes: b13e39d | (Aaron Faanes)++ | CREDITS:
Add dafrito to CREDITS
rrot/dafrito_doc_fixes: 87c40ab | dukeleto++ | / (4 files):
Merge pull request #148 from dafrito/doc_fixes

Revised doc fixes
dukeleto good lord
lucian: compiling from source is always fun ... :) 19:41
lucian dukeleto: sure, except when it takes forever :)
even parrot takes very long to build here 19:42
dukeleto incoming
lucian: yeah, i can imagine
dalek rrot: a822e17 | dafrito++ | tools/docs/make_html_docs.pl:
make_html_docs: move both functions beneath exec'd code
rrot: e0ba9b3 | dafrito++ | tools/docs/make_html_docs.pl:
make_html_docs: Lots more doc, explained JSON syntax/process
rrot: b13e39d | dafrito++ | CREDITS:
Add dafrito to CREDITS
rrot: 87c40ab | dukeleto++ | / (4 files):
Merge pull request #148 from dafrito/doc_fixes

Revised doc fixes
rrot: c059a67 | dukeleto++ | / (11 files):
Merge branch 'dafrito_doc_fixes'
dukeleto dafrito: keep the good commits comin' :) 19:43
whiteknight dafrito++
cotto whiteknight, what'd be the implications of reusing the old syntax once :init and :load behave the same as :tag("init") and :tag("load")? 19:44
whiteknight cotto: internally they will be the same, eventually, so I guess it doesn't matter to me if we continue to call them ":init" and ":load" 19:45
the important part is cleaning up the fugly logic with the sub pmc flag bits
dukeleto whiteknight++ # defuglification 19:46
whiteknight I'm going to change my job from "product manager" to "master defuglifyer"
or, defuglification team leader
dukeleto whiteknight: i approve 19:50
cotto whiteknight, I like the idea of reusing the existing syntax and typing less. 19:58
dalek kudo/nom: f1de2a8 | jonathan++ | src/Perl6/ModuleLoader.pm:
Start to flesh out module loading a bit; make it pay attention to @*INC at least, and even failing that (due to no setting loaded yet) at least check installed locations.
 20:00
kudo/nom: e37f879 | jonathan++ | tools/build/Makefile.in:
Install CORE.setting.pbc, so we now at least find this when running from an installed version. Not quite there yet - we struggle with loading the module loader.
kudo/nom: 1119188 | jonathan++ | src/Perl6/SymbolTable.pm:
Make sure we can locate the Perl 6 module loader from the installation.
cotto That's just preference though. Cleaning up the guts is the important part.
kudo/nom: e48d487 | jonathan++ | src/Perl6/ModuleLoader.pm:
Quick cheat for loading NQP::Metamodel in the setting; will un-cheat it in forthcoming modules work.
kudo/nom: d70d16a | jonathan++ | NOMMAP.markdown:
nom is now installable; update nommap. Again, nuking your current install directory is recommended if you didn't already do so with the NQP upgrade.
nxed: da32bbb | NotFound++ | winxedst1.winxed:
if something looks like a method call but can't be resolved at compile time
 20:04
whiteknight cotto: You can't think about it in terms of characters typed. Eventually, nobody will be writing PIR code anymore 20:24
cotto whiteknight, I'll be throwing a party. 20:25
It'll have a cake that doesn't have PIR written on it.
for the time being, there'll be a lot of hand-written and generated PIR that uses tags, and I'd like it to be as readable as possible 20:26
dukeleto cotto: so where do we stand with respect to Mole ?
cotto dukeleto, nothing more than is in github.com/cotto/mole 20:27
dukeleto cotto: i hadn't even seen that repo yet
cotto dukeleto, it's just a conversion of the gist I'd been using. 20:28
dukeleto cotto: i like it in repo form. are you still maitaining an m0 gist? I feel like it would be more visible if it was in one of the m0 branches
cotto dukeleto, what do you mean "m0 gist"? My todo list is still in gist form. 20:29
aloha, m0 todo?
aloha cotto: m0 todo is gist.github.com/1019986
dukeleto cotto: yeah, that is what I mean. For instance, I can only comment on that gist, not edit it. But perhaps that is what you want 20:30
cotto: maybe that should be a document in the m0-spec branch?
cotto dukeleto, I'll make it into a repo 20:31
cotto wishes for a "promote gist to full repo" button
dukeleto cotto: sure. As long as it is easy for parrot devs to help update it, unless you mean it to be a personal todo list
cotto: ooh, that would be shiny
cotto: i know i haven't been hacking on m0 lately, but I have definitely been thinking about it
cotto dukeleto, it's currently personal, but there's no reason for it to stay that way 20:32
20:32 awwaiid joined
dukeleto cotto: i am very heavily considering writing an abstract for an M0 talk at that VMIL workshop 20:33
cotto: seemingly, m0 is exactly the kind of stuff that workshop is about
cotto: except it is all a bunch of theoreticians and we are actually slamming our feet on the virtual metal
cotto: mostly, i want to talk about m0 there to learn things that are useful for the evolution of m0. Hopefully i will give a talk and then someone will say "oh you should read paper such-and-such that says x-and-y" 20:35
cotto: and perhaps get a few other smart folks involved in actually building something instead of just talking about it
cotto dukeleto, I'm very much hoping to come back with a pile of awesome papers to read through.
dukeleto, that too
dukeleto cotto: are you going to submit something? 20:36
cotto: also, would you consider putting the mole.git repo under the parrot org? I think that will encourage more people to be involved. It's up to you, of course.
cotto: also, we may need some kind of Mole logo that involved a mole attacking a Go gopher 20:37
s/involved/involves/
cotto dukeleto, I'm trying to find the button to create a new parrot org repo.
dukeleto, I'm not sure how I'd form a talk for that audience. 20:38
dukeleto++
20:39 mj41 joined
dukeleto cotto: go to your Github dashboard 20:39
cotto: switch over to the "parrot" context at the upper right
cotto: then click on the "create a new repo" button 20:40
cotto: "New Repository" button, rather
cotto dukeleto, mole is transferred to parrot
dukeleto wooooot
20:40 contingencyplan joined
cotto dukeleto, m0 todo list is now under the parrot org 20:42
aloha, no m0 todo is github.com/parrot/M0-todo 20:43
aloha cotto: Okay.
cotto aloha, m0 todo
aloha, m0 todo?
aloha cotto: m0 todo is github.com/parrot/M0-todo
tadzik hrm, I'm unable to install parrot. I ran Configure.pl with --prefix=./install, and now ./parrot gives me ./parrot: error while loading shared libraries: libparrot.so.3.6.0: cannot open shared object file: No such file or directory 20:50
dukeleto tadzik: i always give --prefix a full path
tadzik: i am not sure it works with relative paths
cotto dukeleto, if it doesn't, we should make it fail earlier 20:51
dukeleto tadzik: also, it would be ./install/parrot
cotto: yes, but I am not sure if that is the problem
tadzik okay
NotFound I usually use use /home/me/runparrot
dukeleto tadzik: this is the script I use to compile a new parrot github.com/leto/Util/blob/master/bin/new_parrot 20:52
tadzik okay, absolute path works, thanks 20:53
cotto tadzik, can you file a ticket?
20:54 darbelo joined
tadzik cotto: sure 20:54
maybe I can fix a ticket
NotFound Even better. 20:55
cotto tadzik++ 20:56
tadzik wouldn't that be just expanding the path properly in Configure.pl? 20:57
cotto aloha, no m0 todo is github.com/parrot/m0_todo
aloha cotto: Okay.
NotFound I've bought a book about java. It was time, the only one I had was "Core Java" (C) 1996 Sun Microsystems, Inc. 20:58
20:58 soh_cah_toa joined
cotto soh_cah_toa, ohai. 20:58
NotFound Maybe it's a valuable collector item.
soh_cah_toa cotto: hey
cotto NotFound, sounds like a good source of lulz
soh_cah_toa, it's nice to see an optimistic blog post from you. 20:59
soh_cah_toa yeah, i know. finally
cotto none too soon either 21:00
soh_cah_toa so was i close about pc and interp->code->base.data? what do those to values represent? my guess was that the latter was the current offset into the bytecode segment but i don't know about pc 21:02
tadzik eh, who knows something about Parrot's Configure.pl system? 21:05
dukeleto tadzik: i might 21:08
soh_cah_toa: pc is the program counter, i.e. the current value of the index into the bytecode 21:09
soh_cah_toa it can point to any place/segment in the bytecode? not necessarily an actual opcode? 21:10
cotto soh_cah_toa, *pc is the offset of the currently-executing instruction based on the current op map
tadzik dukeleto: what is the best place to stick the relative path expansion? I could do it in process_args() or _initial_pass(), but maybe there's a better place for that
soh_cah_toa offset from the beginning of the packfile? 21:11
cotto *ps will generally be a small integer between 0 and 50 or so, depending on how many different ops are mapped
*pc
soh_cah_toa well, actually pc is usually a really big number
cotto *pc isn't though
soh_cah_toa about 9 digits long
cotto pc is a memory address
soh_cah_toa ok
cotto *pc is what's in it 21:12
soh_cah_toa well yeah
and then what about interp->code->base.data?
dukeleto tadzik: what currently happens when you pass in a non-absolute path ? does it put stuff in the wrong place? blow up? do nothing at all?
tadzik dukeleto: it installs it well, but it cannot find the libparrot.so.3.6.0 21:13
(the installed parrot)
cotto soh_cah_toa, that's a pointer to the start of the ops within the bytecode segment 21:14
soh_cah_toa ok 21:15
cotto soh_cah_toa, what's your plan between now and the pencils down date in a couple weeks?
and do you want me to help you figure it out? 21:16
soh_cah_toa i don't really have one
yeah, that'd be nice
cotto soh_cah_toa, did you see trac.parrot.org/parrot/wiki/HBDBPlanning ?
dukeleto tadzik: i would create a separate function which checks if $prefix starts with a / , and if not, prepends $PWD to it. But that will only work on unixy systems 21:17
tadzik oh, true
soh_cah_toa i'll look now
tadzik well, that was my guess too, I was just looking for a good place to put it in
but yeah, it'd probably fail for windowses
dukeleto tadzik: also, make a branch for this, and then ask kid51++ to review. He is the person who understands Configure.pl the best
tadzik okay
so, _initial_pass is the place then? 21:18
cotto soh_cah_toa, I'm editing atm, so hold off if you want to make changes 21:19
21:21 darbelo_ joined
dukeleto tadzik: do whatever you think is best and push it to a branch. Not really sure. 21:21
tadzik dukeleto: it's just gist.github.com/1129758 testing it now 21:22
NotFound I don't like the idea of risking my --prefix to be silently replaced. I think it will be better to fail with a clear error message. 21:23
tadzik well, it's the same prefix 21:24
NotFound Same as what?
tadzik same as supplied 21:25
it it doesn't start with a /, it's the same as prefixed with ./, which is $PWD/ 21:26
s/it/if/
NotFound Is not the same. This conversation started because it failed. 21:27
If you make it not fail for the wrong reasons, I hardly see an improvement.
dalek tracwiki: v4 | cotto++ | HBDBPlanning
tracwiki: start breaking timeline down into discrete features
tracwiki: trac.parrot.org/parrot/wiki/HBDBPla...ction=diff
cotto soh_cah_toa, there's the first step. I've tried to break everything you mentioned down into a bunch of features. Could you look at the last few items and add those to the feature list? 21:29
soh_cah_toa, I wasn't sure what you meant by them.
NotFound And we'll need platform dependent variants of that checks, because of a misfeature.
dalek le: 403d881 | dukeleto++ | / (3 files):
Add a Mole readme
 21:30
NotFound If someone wants a Configure assistant/wizard/whatever please wiite it as an idependant program and invoke plain Configure from it. 21:32
soh_cah_toa cotto: what last few items?
cotto soh_cah_toa, refresh the page. I'm referring to all the items at the bottom of the page. 21:33
dukeleto tadzik: perhaps we should just die at Configure time if a non-absolute path is passed in. But even *deciding* what is an absolute path in a cross-platform way is not trivial, which is why this bug probably exists
soh_cah_toa ah, there. it wasn't going before
cotto soh_cah_toa, also, I'm done editing.
dukeleto tadzik: in any case, getting kid51++'s opinion will be valuable
cotto (for now)
tadzik from my viewpoint, if Configure silently fails with a relative path, that's a brokeness. If it worked, that'd be just fine. If it just cried that it's a relative path, I'd get mad for it not to correct it itself
just my 1€ 21:34
dukeleto cotto: please read through the new mole readme and make sure I am not bullshitting
cotto soh_cah_toa, also make sure all the features make sense to you, and edit them if they don't
dukeleto, ok
dukeleto tadzik: crying on relative paths is at least better than silently failing. I agree with you that it should know how to deal with relative paths
NotFound Configure is not a final user tool that should be friendly. We should balance its friendliness against other aspects.
dukeleto tadzik: but for instance, if you use ~ in --prefix, that will fail too. It is a long, dark, smelly yak hole. 21:35
tadzik true
dukeleto tadzik: we do need to explicitly state what --prefix expects and what it doesn't
cotto dukeleto++ 21:36
soh_cah_toa cotto: well, i was just gonna mention that. i think most of this is still probably possible but i'm really gonna need your help
cotto dukeleto, looks good
soh_cah_toa, that's why I'm here
soh_cah_toa, let me know when you're done with the list 21:37
tadzik > perl Configure.pl --prefix=install/parrot --optimize
Relative path given to --prefix, please pass an absolute path
cotto tadzik, will that also work correctly on windows?
tadzik++ btw
tadzik for windows I should probably check for ^\\\\ rather than ^/, dunno 21:38
cotto tadzik, make sure it gets some windows love before it gets merged
NotFound --prefix=D:\\\\whatever
tadzik okay, it's trickier on windows
cotto but +1 when that happens
NotFound --prefix=//somenetshare/parrot 21:39
tadzik pushing to a branch
heh, I just ran 'rm -rf ./~', was scared for a moment :)
darbelo_ tadzik: How about --prefix=~/some/dir/ ? 21:41
dalek rrot/tadzik/whine-on-relative-prefix: 6a21cee | tadzik++ | lib/Parrot/Configure/Options.pm:
Cry when Configure.pl is given a relative path. Probably works for Unixes only
tadzik darbelo_: that'd break
dukeleto darbelo_: ~ is not supported
darbelo_ It should be noted in the docs, people might expect it to work. 21:42
cotto why shouldn't it work?
NotFound ??? We should document any funny character that someone may think it will be treated in some special way? 21:43
dukeleto darbelo_: i expected it to work, but it didn't
dalek tracwiki: v5 | cotto++ | HBDBPlanning
tracwiki: trac.parrot.org/parrot/wiki/HBDBPla...ction=diff
cotto --prefix=%appdata%/parrot
darbelo_ ~/ is a valid, non-relative path on unixes. 21:44
21:44 Psyche^ joined
dukeleto cotto: "shouldn't" wasn't used. I would like for it to work, but when I said something about it, chromatic grumbled about supporting shell expansions across operating systems and no one else seemed to care about it at the time 21:44
tadzik glob would expand that
NotFound Guys, I think that teaching people how his shell works is not our job.
dukeleto darbelo_: yes, in a shell. But configure.pl doesn't do shell expansions.
NotFound Supporting shell expansions is the shell job. 21:45
dukeleto Aren't we glad that we don't support VMS?
tadzik msg kid51 could you take a look at tadzik/whine-on-relative-prefix in some spare time? kthx 21:46
aloha OK. I'll deliver the message.
tadzik aloha: thanks
darbelo_ dukeleto, NotFound: I'm agreeing, I just think a small note to the effects of 'We don't do no shell expansions' might be warranted.
NotFound I don't think we should document what we don't do.
cotto If there's an easy way someone wants to find, I'd like that. If not, a warning is fine. 21:47
tadzik I think it's this sort of problem that has already been solved a thousand of times
NotFound The goal usually is to document what we do.
dukeleto darbelo_: i agree
NotFound: sure. But making things user-friendly sometimes means saying "currently, this is not supported"
NotFound tadzik: yes, and most of the times wrongly.
dukeleto We don't need to say "we currently don't support PDP11's" but it would be nice to say we don't support things that some people might expect. 21:48
NotFound It will be a very long list.
dukeleto NotFound: we only add to the list when it bites somebody. Such as tadzik wondering why relative --prefix paths don't work. 21:49
NotFound Sounds like a FAQ, then.
tadzik and it happens to be a known issue, of which the insiders know about
NotFound I don't object to have a FAQ about the configure and build process. 21:50
cotto soh_cah_toa, you still there? 21:51
soh_cah_toa cotto: yeah
cotto: i'm done editing. i'll brb though 21:52
dalek kudo/nom: 0c336ba | Coke++ | t/spectest.data:
run more spectests, track failure modes
 21:53
cotto soh_cah_toa, the next step is to split up that list. I can think of a number of categories (though it looks like you've started already)
1) completed w/ tests 2) completed w/o tests 3) dependent on imcc cleanups 4) not dependent on imcc cleanups (possible to implement before pencils down) 5) not dependent on imcc cleanups (not possible to complete before pencils down)
soh_cah_toa, I'd make 5 empty lists for those categories and move all features into one of those lists. 21:54
soh_cah_toa, from there, we can figure out a plan that'll be the best use of your remaining GSoC time. 21:55
dalek tracwiki: v6 | soh_cah_toa++ | HBDBPlanning 21:59
tracwiki: trac.parrot.org/parrot/wiki/HBDBPla...ction=diff
tracwiki: v7 | cotto++ | HBDBPlanning
tracwiki: trac.parrot.org/parrot/wiki/HBDBPla...ction=diff
kudo/nom: 397cf71 | tadzik++ | tools/build/Makefile.in:
Install Pod/To/Text.pm along with Test.pm
 22:00
soh_cah_toa cotto: ok 22:09
22:20 contingencyplan joined
cotto soh_cah_toa, looks good. Now let's figure out what you can get done during GSoC. Tested features are much more valuable than untested features so if you're having trouble deciding, add more tests. 22:30
dalek tracwiki: v8 | soh_cah_toa++ | HBDBPlanning
tracwiki: Started dividing features into separate groups.
tracwiki: trac.parrot.org/parrot/wiki/HBDBPla...ction=diff
cotto Documentation is important too. 22:31
soh_cah_toa, how long do you think it'll take to write tests for the features that are implemented but not yet tested? 22:32
whiteknight soh_cah_toa: ping 22:35
cotto soh_cah_toa, my recommended goal for the end of gsoc would be to add tests for all implemented features and to add a couple of the non-imcc-dependent features like function breakpoints, printing registers and possibly register watchpoints. 22:36
22:37 PacoLinux_ joined
cotto soh_cah_toa, I need to go do some errands. I'll be back later this evening. In the meantime, please form what you think you can accomplish into a schedule on the HBDBPlanning wiki page. 22:42
22:46 PacoLinux__ joined
dalek kudo/nom: 6d7cf62 | tadzik++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Fix Bool.get_bool vtable mapping, jnthn++
 22:49
rrot: 1f0d63c | jonathan++ | compilers/pct/src/PAST/Compiler.pir:
Avoid deep-cloning symtable in PAST::Compiler.
 22:50
soh_cah_toa sorry, i was eating dinner 22:56
whiteknight: pong
tadzik dinner, on 1AM? :P 22:57
soh_cah_toa :)
whiteknight soh_cah_toa: I might not have much more time tonight, but what time I do have tonight and tomorrow is all yours 23:08
soh_cah_toa: so tell me what you need me to do, then get the heck out of my way
soh_cah_toa yay :) 23:09
hmmm...
23:09 kid51 joined
soh_cah_toa whiteknight: well, what would be the best way to test for current annotations in effect? if (interp->code->annotations)? 23:10
whiteknight let me look 23:11
soh_cah_toa ok
whiteknight src/packfile/api.c:PackFile_Annotations_lookup
that function probably will be renamed, but that's what it is for now
kid51 msg tadzik Assuming we want to forbid relative paths for 'prefix' (and I don't have an authoritative opinion on that), here's a patch to your branch which you might want to consider. 23:12
aloha OK. I'll deliver the message.
soh_cah_toa yeah, i know. pretty ugly
that's what i used for the backtrace command. just making sure
tadzik I'm here
nopaste "kid51" at 192.168.1.3 pasted "patch to tadzik's branch about prefix" (54 lines) at nopaste.snit.ch/68289
kid51 patch uses prior art, but also adds a regression test 23:13
tadzik kid51: I was told to consult the move with you, whether and how to handle the relative path case (it's broken now)
kid51: the patch makes sense to me, might pushing that?
kid51 Sure. 23:14
I myself have always used an absolute path, so I never had occasion to see what happened with a relative path.
tadzik it gave me a bit of headscratching today 23:15
kid51 I think this is a case where it would be good to know what happens on Windows.
tadzik yes
kid51 See perldoc File::Spec for documentation of file_name_is_absolute (there are caveats)
soh_cah_toa whiteknight: now suppose i find an annotation for line 3. is there anywhere in the debug segment that contains the actual text of that line? if not, how else can i look that up?
tadzik This does not consult the local filesystem on Unix, Win32, OS/2, or Mac OS (Classic). 23:16
whiteknight soh_cah_toa: the text of that line in the original HLL?
23:16 PacoLinux_ joined
soh_cah_toa whiteknight: yeah 23:16
whiteknight no, I don't think that information exists anywhere, after being compiled
soh_cah_toa agh... 23:17
whiteknight unless the HLL explicitly stored that data somewhere, which I don't think any do
dalek rrot/tadzik/whine-on-relative-prefix: 56ea77d | jkeenan++ | / (2 files):
Let's try using a File::Spec function for testing for absoluteness. Add a regression test for invalid value to '--prefix'.
whiteknight soh_cah_toa: Just print out the pir source for that annotation
soh_cah_toa: we might need to build you a better function to return list of all PIR lines with the same annotation
soh_cah_toa yeah 23:18
i would kind of like any below the hll level to be transparent to the user unless explicitly requested 23:20
*anything
whiteknight What we could try to do is get HLLs to have a "source" annotation with the text of the original line of code 23:24
that certainly doesn't exist right now, but could be added
soh_cah_toa that would be badass
kid51 soh_cah_toa: Were all my codingstd cleanups in your branch safe? 23:25
whiteknight what does the -c arg to Parrot do? 23:26
soh_cah_toa kid51: yeah, there were a few merge conflicts when i merged my work on vacation but i fixed them
whiteknight: it looks like it means that the file is pbc. if you specify it w/ a .pir file, it throws an exception 23:31
whiteknight: it actually seems kind of unnecessary
dalek rrot/whiteknight/frontend_parrot2: 9a0516c | Whiteknight++ | frontend/parrot2/ (2 files):
Start changing the way we handle arguments. Split arguments into two arrays, one for system-related args and one for program-related args. Pass both arrays to prt0.pir, and start parsing some args from there (-o, -c, -r, -E)
 23:33
kid51 looks at whiteknight/imcc_tag branch and thinks: IMCC is really in a different universe from the rest of Parrot
whiteknight has to go buy his kid some icecream, will be back
kid51 branch PASS make test and make nocritic_codetest
soh_cah_toa kid51: indeed it is 23:34
kid51 All those ... numbers!
soh_cah_toa ha! i know. the code itself is not very readable either 23:35
whiteknight: when you get back, does the Sub PMC provide some way of retrieving the arguments passed to a subroutine? their type and/or value? 23:40
dalek p: ed093d3 | jonathan++ | tools/build/PARROT_REVISION:
Bump PARROT_REVISION to get PAST::Compiler tweak.
 23:47
p: 265a34e | jonathan++ | src/pmc/sixmodelobject.pmc:
Throw an exception if the clone vtable is called on a 6model object - it doesn't support it in any sane way (yet) and the default does insane things.
23:58 PacoLinux__ 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!