Parrot 4.2.0 "Ornithopter" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 10 April 2012.
00:22 eternaleye_ joined 00:23 alester joined, perlite joined
dalek sella: 1fdae0c | Whiteknight++ | src/ (4 files):
[Xml] A few TODO notes
 00:26
sella: 0bd8471 | Whiteknight++ | src/date/ (3 files):
[Date] Remove Date.to_total_seconds() method. It was wrong algorithmically and the result would easily overflow on a 32-bit machine. Add .day_of_year method and a new mechanism to get a TimeSpan
sella: 8fd5499 | Whiteknight++ | / (2 files):
[Date] Add two more tests for Date.diff(), showcasing the new method
sella: c941570 | Whiteknight++ | src/date/Date.winxed:
[Date] Document an assumption about years and add in a sanity check.
sella: 3a80daf | Whiteknight++ | src/unstable/ (2 files):
[Parse] Rewrite parse_remainder. Don't go over the remaining string character by character. We can read it directly out of the string to save time
sella: aa93173 | Whiteknight++ | src/ (5 files):
[Template] Rework the way we do template recursion. Template.Node.Master now has a .to_winxed_master routine which adds the code to the builder and returns the name of the generated sub. Assume winxed.compile() returns a PackfileView
01:45 moritz_ joined 01:46 nine joined 01:48 sri joined 01:53 ingy joined 01:57 slavorg joined 01:59 perlite joined 03:45 benabik joined
benabik Parrot on Mars: news.discovery.com/space/is-this-a-...20411.html 05:53
tadzik "too accurate for chance". Yeah :) 05:57
nice
benabik And scientific proof of the Ballmer curve: medicaldaily.com/news/20120411/9496...-study.htm 05:59
benabik should be asleep.
tadzik no, keep linking :) 06:00
07:13 brrt joined 07:18 he_ joined, dngor_ joined 07:34 fperrad joined 07:40 lucian joined 08:22 lucian joined 08:26 _mayank joined 10:17 bacek joined 11:21 JimmyZ joined 11:26 JimmyZ joined 12:05 benabik joined
benabik o/ #parrot 12:08
JimmyZ \\o
12:24 brrt joined 12:45 whiteknight joined 12:49 hercynium joined
whiteknight good morning, #parrot 12:50
JimmyZ good morning whiteknight 12:51
benabik o/ whiteknight
whiteknight good morning JimmyZ, benabik. How are you two doing today? 13:00
benabik Caffeinated. ::=))
whiteknight: How're you? 13:01
13:06 PacoAir joined 13:07 contingencyplan joined
whiteknight benabik: I got a really awesome optimization-related ticket in my queue this morning, so I'm happy about that 13:13
benabik Optimizations can be fun. Is it "make blah faster" or "making blah faster broke things"? 13:14
whiteknight They've got this data importer that's chewing up over 2 gigs of ram and crashing trying to import an old set of customer order records
benabik That's LTA
moritz buy more RAM :-) 13:15
atrodo Buy less customers
whiteknight all those are good ideas
benabik I decided to track down a git bug this morning only to find that Junio rewound next for the next release and the bugs don't exist anymore. Which is good, I guess.
whiteknight The algorithm here is looking like it's O(n^2) at least, reading in a list of all orders, then reading in a list of all existing orders and comparing keys 13:16
benabik Maybe I'll update my notes on PACT. Have slightly different ideas of the layers now than I originally did.
whiteknight then reading in a list of all customer records and comparing keys on the orders
benabik: really? I would love to hear your current thoughts
moritz whiteknight: that sounds like a hash would be helpful :-) 13:17
benabik whiteknight: Mostly flattening. Origionally had a PAST -> POST -> Packfile, now I think PAST -> CFG -> Packfile makes more sense. To some extent this is because my idea of Packfile is lower, and also I think the difference between the PAST and POST layers is really just abstraction and that can be handled by a transformation within the same layer.
moritz the old "clubbing somebody to death with an Uzi" thing 13:18
whiteknight moritz: exactly. I'm also going to null out data after it's done being used and manually trigger GC to kill it
benabik whiteknight: Hopefully that will actually kill it. On one of my co-ops massive memory usage was tracked down to one guy who kept a list of every message his component saw. 13:19
whiteknight benabik: yeah, reading in a list of Order objects where all we really need to keep is a list of their IDs is wasteful and forces GC to mark those objects and keep them around 13:20
and the original developer insisted on using an ORM that automatically loads more data than we need, instead of just using a SELECT id FROM orders query, that would have returned far less 13:21
benabik :-(
JimmyZ where is PACT repo? 13:24
benabik github.com/parrot/PACT
It currently contains a random set of my ramblings, most of a disassembler, and the beginnings of a Packfile layer. 13:26
JimmyZ oh, I thought github.com/benabik/PACT
benabik I didn't actually start the repository. :-D I put up a gist that someone else (whiteknight, IIRC) turned into a repository to shame me into doing more with it. 13:27
whiteknight benabik: and it shamed you into an entire GSOC proposal
benabik (Or that's how it turned out at least, even if it wasn't his intention.)
whiteknight: Yeah, well.
13:31 bluescreen joined
benabik We should put some thought into making REPLs easy. I think we can manually fudge the lexical environment, but it would be nice if we could restore and entire context with new code. It would require the compile half of the REPL to keep around information about register usage, obviously. 13:35
Although I suppose that could cause an issue if the new line required more registers than the old... I don't think register space is resizable...
(Random thought of the day)
moritz well, at some point you have to think about what a new REPL line means 13:37
if it goes into the same scope as the previous line, then most languages don't allow redeclarations of symbols
if it goes into an inner scope, then one must flatten the scopes (if possible) to avoid memory leakage
benabik Playing with lexpads would probably make that simpler than trying to cart around registers. Just deciding that the "normal" REPL uses all lexical variables is much simpler. 13:38
PerlJam The R, P, and L parts are all easy though :) 13:42
benabik moritz: That's a good point. I think least surprise says we should treat it as an inner scope and figure out how to flatten. 13:44
moritz that's what NQP and rakudo do
though currently it's a bit broken wrt natively typed variables 13:45
benabik Well, we do have natively typed lexicals now, don't we? 13:47
moritz yes. The REPL code just doesn't handle them properly 13:53
13:56 JimmyZ joined 13:58 JimmyZ_ joined 14:17 mdupont joined 14:36 jashwanth joined 14:41 jashwanth joined
whiteknight opbots 14:43
can somebody +o slavorg? 14:44
benabik Seem not to have op.
tadzik opbots 14:45
whiteknight much better, tadzik++
benabik preflex? 14:46
whiteknight benabik: it's like a reflex, but before something happens
benabik whiteknight: Yes, but why was it given voice?
Seems to be a bot. Never noticed it before. 14:47
whiteknight benabik: I don't know why it's +v. and not +o. We don't hear from preflex much
benabik Looks like most of the bots are +v 14:48
tadzik <obligatory joke about bacek and masak> 14:50
moritz patchbot and bugbot?
15:24 davidfetter joined 15:29 dngor joined
dalek kudo/nom: 200926b | moritz++ | src/core/traits.pm:
.HOW.WHAT is the same as just .HOW. Simplify
 15:31
kudo/nom: 05b1cb1 | moritz++ | src/core/Str.pm:
native infix:<xx> operator
benabik We have ops to manipulate the lexinfo tables now, right? (i.e. can create a new lexical scope without creating a new sub) 15:57
moritz I think mls++ did some work in that direction 16:11
benabik Awesome. I wasn't imagining it. mls++ indeed
17:01 PacoAir joined 17:19 _mayank joined, lucian joined 17:25 hercynium_ joined 17:27 hercynium__ joined
cotto ~~ 17:39
17:40 bluescreen joined 18:04 Justin joined
Justin good afternoon 18:04
whiteknight hello Justin 18:06
dukeleto ~~ 18:12
dalek kudo/nom: b229580 | moritz++ | src/core/Str.pm:
Revert "native infix:<xx> operator"

This reverts commit 05b1cb13190b324bd4c718c2ecdbddb15b8a6994. It was wrong (misspelled the operator name), and causes segfaults when the operator name is fixed		 18:17
18:19 preflex_ joined
benabik We really need to remember introspection when we add features. 19:04
If you try to get a lexical variable into the wrong type of register, it explodes. 19:06
And there's no way to find out what type it is. (other than trying repeatedly)
19:11 hercynium joined
cotto classy 19:12
benabik Aren't we though?
cotto who's our gsoc org admin? 19:37
benabik whiteknight, It hink.
cotto whiteknight?
wfm. 19:38
benabik what does "maps" do in a pmclass?
NQP has a class NQPLexPad that "maps LexPad". I've added a method to LexPad but can't seem to access it on a NQPLexPad.
cotto hmmm. not sure 19:39
benabik "Map the current PMC to a core PMC type for code declared in a particular 19:40
HLL. May only be used together with the C<hll> modifier."
cotto sounds like the C-level equivalent of hll_map
benabik Yeah. So it doesn't actually descend from it. Fun. 19:41
Why does interpinfo .INTERPUFNO_CURRENT_LEXPAD give me null? 19:58
find_lex works...
20:04 estrabd joined
benabik Oh. Because the _current_ sub doesn't have a lexpad. 20:04
`METHOD INTVAL type_of(STRING *name)` in a PMC should be called `$I0 = $P0.'type_of'($S0)`, right? 20:10
Disassembler to the rescue... 20:11
Okay, better question. Why is my METHOD INTVAL returning a LexInfo PMC? 20:15
wait... you don't use normal return from PMC methods, do you? 20:17
Don't you all love to listen to me deal with Parrot guts? 20:23
Hah, my method works now. Blah.
PerlJam benabik: you can babble all day as long as you're making progress on something ;-) 20:47
benabik PerlJam: I tend to ramble on while I search for answers just in case someone wants to pipe in with the answer. :-D
PerlJam benabik: btw, I hope your PACT proposal makes. (I'd also hope for 6model too, but you can't do both, so ... ) 20:50
dalek rrot: 0c99d32 | benabik++ | / (2 files):
LexPad: Add register_type method

This allows for the type of a lexical to be introspected before retrieval. This is useful because attempting to store the lexical in the wrong type of register throws an error.		 20:54
benabik And just in time. I have an appt. 20:55
21:14 PerlJam joined 21:24 perlite_ joined 22:00 plobsing joined 23:25 plobsing joined 23:36 whiteknight joined
whiteknight good evening, #parrot 23:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!