Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today” | Accepted GSoC Students announced! | GSoC student information emails coming out soon
Set by moderator on 26 April 2011.
00:00 lucian left
whiteknight I really need to talk to jnthn about that soon 00:02
tcurtis is slightly amused by how fervently DeRemer disclaims the practical importance of fully general LALR(k) parsing in his dissertation.
whiteknight tcurtis: link? 00:03
tcurtis whiteknight: computer-refuge.org/bitsavers/pdf/m...TR-065.pdf
whiteknight oh wow. Hah. I love reading papers this old 00:04
some of the best papers I ever read were from Dijkstra
tcurtis whiteknight: In Chapter 3 and 4 he develops parsing techniques for LR(0) and SLR(k) parsers, and in Chapter 5 he generalizes to LALR(k) and general LR(k) (I think). 00:05
whiteknight okay, cool
so this is definitely something I want to read
I need to pull out my dragon book too, methinks
sorear in a lot of real world cases languages are designed by people who understand parsing technology
you need a LALR(1) parser if you want to parse a language designed by a yacc user 00:06
whiteknight LALR(1) parsers have a lot of benefits
not the least of which is quick failure
that is something easily overlooked 00:09
tcurtis: oh, it's 219 pages. Will take me some time to read 00:10
I am excited about the prospect of LALR on Parrot 00:16
I was the one who suggested the topic in the first place
all we need now is a good tokenizing library for the frontend 00:17
00:28 ShaneC left
tcurtis needs to come up with a name for his GSoC project. 00:35
whiteknight "tyler's awesome freaking lalr thingy" 00:36
taflalrt
bubaflub could be LinewALkeR 00:39
i guess wholesaler would work as well
whiteknight pyacc 00:57
pison
anyway, I've had enough bad ideas for one night. I'm going to bed
later
00:57 whiteknight left 01:55 crankin joined
crankin clear 02:00
02:00 crankin left 02:01 crankin joined 02:03 crankin left 02:04 crankin joined
crankin Is this channel dead? 02:05
02:05 crankin left
bubaflub nope 02:18
02:41 JimmyZ joined
soh_cah_toa agh! i just spent all day building an rpm .spec file for parrot only to find that there already is one! 02:59
03:00 JimmyZ left 03:17 hudnix left 03:27 soh_cah_toa left
dukeleto ~~ 03:49
cotto I hereby dub whiteknight++ as our magical blogging robot. 03:53
dukeleto msg whiteknight your new name, as decided by cotto++, is "The Magic Blogging Robot". We'll help you change your legal name. 03:54
aloha OK. I'll deliver the message.
04:01 Andy joined
Andy What is in src/call/*.c? 04:01
I'm trying to find where those funcs get called 04:02
cotto calling conventions 04:03
04:07 tcurtis left
dukeleto Andy: search for _pcc 04:07
04:07 tcurtis joined
dukeleto is having an M0 mindmeld with cotto++ 04:07
Andy Perhaps some of the functions in src/call/*.c need not be flagged as exported then? 04:08
Im' trying to find what it was that looked like it wasn't getting used outside of src/call/* 04:09
dukeleto Andy: hmmm. some probably, but not all.
Andy: in theory, some people might access them. In practice, they mostly only get used by parrot internals 04:10
04:11 woosley joined
dalek rrot: d2145a3 | petdance++ | / (2 files):
consting pointer arguments, and removing unnecessary intermediate variables
 05:11
Andy Yes, that's right, I found still more places to const.
I thought I'd found them all.
But no 05:12
dalek rrot/m0-spec: 90c8f75 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
add a note about the 3rd arg to print_s being arbitrary
 05:20
rrot/tt1931-nci-parameters-deprecation: 2830c24 | plobsing++ | src/platform/generic/dl.c:
manage NULL dlsym handles properly

A NULL handle actually means RTLD_DEFAULT on most platforms (notably linux), and this has become the expected behaviour. This change formalizes the practice.		 05:35
rrot/m0-spec: 3f31f13 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Consistently use the opcode name set_var

Also, the order of arguments to set_var were made more intuitive for mere mortals.		 05:39
05:45 woosley left
dalek rrot/tt1931-nci-parameters-deprecation: 1c272ab | plobsing++ | config/auto/opengl.pm:
dissable building opengl bindings if the thunk generator is going to crash and burn
 05:47
rrot/tt1931-nci-parameters-deprecation: dc68cb0 | plobsing++ | / (33 files):
Merge branch 'master' into tt1931-nci-parameters-deprecation
rrot/m0-prototype: b6630d3 | dukeleto++ | t/m0/hello.m0:
Add an actual example M0 file that will be interpreted

This M0 code will be used as the first test for parsing M0 source code, generating the relevant bytecode and then running that bytecode.		 05:55
05:57 cotto left, cotto joined
dalek rrot/m0-prototype: 3a11657 | dukeleto++ | t/m0/hello.m0:
Add enlightening comments to our M0 source code
 06:02
rrot: c9da673 | petdance++ | src/call/pcc.c:
fixed headerization of is_invokable
 06:03
rrot: 06bb92c | petdance++ | src/ (2 files):
headerizing previously unheaderized functions
06:06 Andy left 06:09 bubaflub left
dalek rrot/m0-spec: a6d7840 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
spell out M0 execution, define "chunk"
 06:21
rrot/m0-spec: a12576c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add mostly-empty section spelling out what we need from control flow
dukeleto seen cgaertner 06:44
aloha cgaertner was last seen in #parrot 28 days 16 hours ago saying "btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that...".
dukeleto seen cgaertner_
aloha Sorry, I haven't seen cgaertner_.
06:50 theory left 07:12 mtk left 07:18 mtk joined
dalek rrot/m0-prototype: b75c140 | dukeleto++ | .gitignore:
Ignore vim swap files in any subdirectory
 08:03
rrot/m0-prototype: 8520c66 | dukeleto++ | / (3 files):
Beginning of an M0 assembler in Perl 5

After having an M0 mindmeld with cotto++, we decided that the dynop implementation of M0 has served us well, but development should not continue further. It greatly helped us define the M0 spec, but the current impedance mismatch of having to use M0 from PIR is now blocking us from completing the spec.
This is an M0 prototype that we plan on throwing away, but which will help us improve the spec further. There will be an assembler, which eats M0 source code and spews out bytecode as binary data, and then an M0 interpreter which actually executes the bytecode.
This prototype aims to have a structure much like our final M0 implementation, but implemented in Perl 5 for maximum whipupitude.
Also, the tests from this implementation will serve as the "M0 spec tests" and will be quite useful for any implementation of M0.
08:19 mj41 joined 08:37 fperrad joined 08:47 autark left 08:51 jjore left 08:52 jjore joined 09:35 autark joined 10:22 jrt4__ left 10:44 whiteknight joined 10:45 lucian joined
lucian whiteknight: sorry i left abruptly last night. my isp disconnected me and i didn't bother to fix it 10:59
11:27 lucian_ joined 11:30 lucian left
whiteknight lucian_: no worries. ISPs are the worst 11:41
now it's my turn to leave abruptly, I have to go pick up the kid. I'll be back later 11:42
11:42 whiteknight left 11:45 lucian_ is now known as lucian 11:57 Patterner left, Psyche^ joined 11:58 Psyche^ is now known as Patterner
dalek rrot/jit_prototype: ea1641f | bacek++ | compilers/opsc/Rules.mak:
Add opsc build dependency on LLMV
 12:27
rrot/jit_prototype: 6610a93 | bacek++ | / (3 files):
[llvm] Extract defined types from LLMVModule and expose it via bindings
rrot/jit_prototype: b029c56 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
[llvm] Add more methods to LLVM::Type
rrot/jit_prototype: 5127ff6 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Initial cut of extracting of underlying struct type from llvm bitcode. Now we can generate proper accessor for something like 'interp->ctx'
rrot/jit_prototype: 4d2e471 | bacek++ | compilers/opsc/ (4 files):
Add handcrafted structs definitions for future use in 'keyed' access
 12:40
12:45 JimmyZ joined
dalek rrot/jit_prototype: c6b2f49 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
Finish 'proper' handling of struct access
 12:48
12:49 lucian left 12:50 lucian joined 13:04 benabik left 13:09 benabik joined 13:25 hudnix joined 13:28 whiteknight joined
whiteknight good morning again, #parrot 13:34
lucian waves 13:37
whiteknight hello lucian
lucian i've just realised that a semispace gc can be trivially parallel
anyway, i should get back to the dissertation
whiteknight :) 13:40
that's quite a fun realizating
realization
13:41 woosley joined
whiteknight I am going to fix Parrot-Instrument if it kills me 13:45
13:53 kid51 joined 14:02 birdwindupbird joined 14:12 sjn joined
whiteknight of course, at this rate it's very possible that I die first 14:37
14:39 kid51 left
lucian ok, DOM sucks. bigtime 14:46
whiteknight plobsing: ping 14:56
14:57 JimmyZ left 14:58 mtk left 15:05 mtk joined
plobsing whiteknight: pong 15:11
whiteknight plobsing: I'm still debugging Parrot-Instrument. 15:12
plobsing: the parent interp creates a child interp and the two call methods on each other
when I come back from a sequence of methods, the interp->code has some changes. The number of ops has changed, op_func_table and op_info_table too
are those kinds of changes acceptable? 15:13
plobsing not within the same sub
but in general, those things do change a lot
whiteknight okay. I'm in an NCI method, which calls a method in the child interp, which in turn causes recursive calls to the parent interp
so inside that NCI method, I shouldn't be seeing changes to the oplibs? 15:14
plobsing um, I'm not sure where the switch_to_cs() happens
within an NCI those don't really matter 15:15
whiteknight when I return from the NCI and go back to the runloop, it executes a weird op and has weirdness 15:16
that is, it executes a load_language op, which appears nowhere in the test program
and load_language is not the next op in the top-level sub
so somewhere either the bytecode is changing from under us, or the way we interpret it is changing
plobsing or we're failing to switch code segments on the return 15:18
whiteknight interp->ctx was being changed, but I restored it and still have the problem
interp->code and interp->current_pf are the same before and after the call
plobsing yeah, neither of those really matter much
whiteknight although the contents of interp->code that I mentioned were different
plobsing that is, current_pf and ctx. they shouldn't really be playing in to this problem 15:19
you can set data watchpoints in gdb. that might be informative 15:20
whiteknight At first I was worried that interp->ctx changing would change the pc when we got back up to the runloop. It doesn't
I've set up a few of them. There are a hell of a lot of recursive calls though 15:21
so when I get back to the runloop, is it a problem that interp->code->op_func_table and interp->code->op_info_table are completely different values? 15:24
plobsing well, yes. that's how we interpret bytecode 15:25
whiteknight that's what I figured 15:30
so should I try to save and restore those fields, or should I try to figure out where they are being modified?
15:31 kid51 joined
plobsing I'd say you should try to figure out who is responsible for resetting those fields after a call and find out why they are not being reset 15:31
whiteknight okay 15:33
15:34 Coke__ left, Coke joined
jnthn__ When we create a fake executable, does it do anything to preserve the PBC name that it's the fake executable for? 15:45
Alternatively, is there a way to get the name of the PBC we're currently running? 15:46
15:52 woosley left 16:08 theory joined 16:25 dodathome joined
dalek p: 105839b | jonathan++ | src/ (2 files):
Resolve issue #9 reported by masak++ that meant that use nqp; was not possible. Actually fixes the root issue which is that if you try to load a module that is the actual program that is running - even if it's in a compilation managed by that program.
 16:31
16:58 cotto left 17:11 ambs joined 17:12 mj41 left 17:22 cotto joined 17:34 plobsing left 17:38 kid51 left
dukeleto ~~ 17:39
cotto hio dukeleto
I'm in the haskell building just about to blog 17:40
17:42 Coke left
cotto dukeleto, where are you at? 17:42
17:42 Coke joined
dukeleto cotto: sweet. I will be hanging in the OpenStreeMap session. Very informative. 17:43
cotto ok
blogg'd 17:44
dukeleto cotto++ 17:45
cotto and dukeleto++ for getting some tests written
dukeleto cotto: link for blog? 17:46
cotto: i don't see it on the parrot aggregator yet
cotto dukeleto, reparrot.blogspot.com/2011/05/m0vin...rward.html 17:47
dukeleto reads 17:48
cotto Yay. I have a reader! 17:52
blog.bacek.com/2011/05/crazy-jit-pr...ction.html 17:54
17:57 bubaflub joined
dukeleto bubaflub: 'sup 18:08
bubaflub morning dukeleto 18:09
18:10 varta joined
dukeleto varta: welcome 18:14
bubaflub: done with skool yet?
bubaflub dukeleto: not yet - almost.
dukeleto can't keep all the GSoC student schedule in his head, yet.
bubaflub dukeleto: 2 weeks and i'll be done
tadzik I'm jealous :( 18:18
cotto bacek++ for figuring out how to unblock ops parsing 18:22
18:25 birdwindupbird left 18:29 SHODAN joined 18:32 Coke left, Coke joined 18:35 davidfetter left 18:49 particle joined, Andy joined 18:52 particle1 left 18:58 jrt4__ joined
whiteknight cotto does not blog nearly enough! 19:04
cotto whiteknight, it's to cancel you out 19:05
whiteknight I'll gladly cut back if it opens more reparrot
cotto ;)
dukeleto whiteknight: i read all your concurrency blog posts. I can haz cookie?
whiteknight dukeleto: I didn't even read them all! I have cookies, will send
dukeleto whiteknight: i agree with pretty much all of it. Let's ship it.
whiteknight: we need to fill out the M0 spec with respect to concurrency stuff 19:06
cotto yup. That's one of three remaining known holes.
dukeleto whiteknight: do you forsee M0 needing concurrency opcodes? What do they look like?
whiteknight okay, that's part of the reason why I wanted to put those posts out there in the first place
dukeleto whiteknight: i assume we may need a few, but don't quite know what they look like
whiteknight dukeleto: that's just the thing, I suspect 99% of the concurrency stuff I talked about can be implemented in terms of PMCs and methods 19:07
The only opcode I really think we need is "share" to share read-only data between threads
and really, that opcode will be mostly a convenience over PMC methods and vtables 19:08
cotto whiteknight, what do you view the mechanism for message passing looking like? 19:10
19:10 soh_cah_toa joined
dukeleto whiteknight: M0 doesn't know what a PMC is 19:10
cotto ctrl-z
whiteknight cotto: from the PIR level, I suggest a method call on the thread: thread.send_message(msg)
dukeleto: whatever mechanism is used to instantiate "things" and do "stuff" on them is what threading requires 19:11
dukeleto: whatever PIR methods turn into in M0 world is what we need
I do assume objects and methods will still be possible, in some fashion
dalek p/ctmo: 4679b68 | jonathan++ | src/core/NQPMu.pm:
Fix a type-o. Detected by in-progress typename handling work.
 19:12
p/ctmo: 556b715 | jonathan++ | src/NQP/ (2 files):
Resolve typename at compile time.
p/ctmo: 3564e72 | jonathan++ | src/NQP/Actions.pm:
Add parrot v-table overrides through the compile time meta-object.
p/ctmo: f993bf4 | jonathan++ | src/ (2 files):
Attach multi signatures during normal fixup stage, not as special loadinits. Should cut startup time a little. Also resolves the multi-method regression introduced earlier in this branch.
dukeleto whiteknight: M0 basically indexes into blobs of memory
whiteknight: it may be that no concurrency M0 ops are needed
whiteknight dukeleto: I don't really care what the mechanism is. At some level, we have methods, right? 19:13
cotto It'll be a hard sell otherwise.
whiteknight dukeleto: As for M0 ops, I don't suspect we need anything special
dukeleto whiteknight: at the lowest level, what does message passing look like?
whiteknight We will need a wrapper API for threads (not for greenthreads), but that should be able to be called in the same way other API calls look like
dukeleto: passing a message looks like thread.mailbox.push(share(msg)) 19:14
the thread mailbox will just be a queue like RPA
share creates a new proxy object
so thread.mailbox.push(new ShareProxy(msg)) 19:15
or maybe thread.mailbox.push(new ShareProxy(thread, this_thread, msg))
but nothing special or complicated. Attribute lookups, method calls, object instantiation
cotto Does there need to be something preventing data from being shared between threads apart from convention? 19:16
i.e. poking into another object's guts is possible, but is a Bad Idea apart from via message passing
dukeleto whiteknight: can't sharing just be the default? what happens if we assume everything is shared by default? 19:17
whiteknight dukeleto: depends what you mean by "sharing". Read-only sharing poses no real problems whatsoever 19:18
read-write sharing creates the potential for data corruption, so we need to have STM and/or locks and other nonsense
dukeleto whiteknight: sure. so read-only sharing is default. So you are talking about "sharing" in the "you can write to this" sense ?
whiteknight: ah, ok. So sharing is for read-write
whiteknight dukeleto: in my system, "sharing" means read-only proxies and using messages to perform cross-thread updates 19:19
you can't write directly to another threads data
you can read it, because there's no reason to restrict that
dukeleto whiteknight: and I am not sure we even need an op for "share", since it really boils down to accessing memory and looking up the metadata about if that data is writable by the current thread/task
whiteknight: does that make sense?
whiteknight dukeleto: What the "share" opcode does in my imagination is to create a read-only proxy, and sends the proxy to the new thread in place of the original data 19:20
the proxy allows direct reads, but uses messages to send updates
19:20 bubaflub left
whiteknight so all "share" does is create that proxy 19:20
dukeleto whiteknight: sure, but "share" can be written in M0, M0 does not need an opcode to represent it. methinks, anyway.
whiteknight right, share is a PIR-level op. 19:21
basically, it's a combination of hll-map-lookup and new
so nothing fancy
at the M0 level, I think we do not need any special concurrency-related ops
dukeleto whiteknight: sweet. This is good. The spec is much closer to complete than we thought.
whiteknight that is, assuming we can call arbitrary API functions written in C
dukeleto whiteknight: M0 has FFI, so yes. 19:22
whiteknight so, we all win. I'll get the champagne
dukeleto whiteknight: awesome. I am going to get some fresh air to brood upon these matters.
whiteknight okay, please do
I'm glad to be finally talking about concurrency in a real way 19:23
dukeleto is excited
dukeleto goes
19:35 mj41 joined
benabik A little late to the conversation, but if we want to do proper locking we'll need an atomic test-and-set or similar op. 19:37
19:37 cotto left
jnthn__ Wasn't there some paper that said that you can build all concurrency stuff out of atomic compare and swap? 19:38
er, concurrency control mechanisms, I mean. :)
19:39 ambs left
benabik jnthn__: I think so. It's been a while since my OS classes, but IIRC you need a single check-and-alter op for something like 95% of concurrency control. Intel went with Test-and-set, but I think test and swap is a little more versitile. 19:40
whiteknight for locking, we might want something like that yes. But then again, we only need locking if we allow cross-thread data writing
19:40 Coke left
jnthn__ whiteknight: You can build a LOAD of lock-free data structures out of CAS. 19:42
whiteknight true
jnthn__ does those now and then 19:43
whiteknight a CAS op might be useful
any M0 op is going to be atomic as far as we are concerned, because tasks only switch between ops, and messages are just tasks
benabik Even if PIR doesn't cross the threads, M0 might end up needing to do coordination across threads like that to support things like the mailboxes. 19:44
whiteknight mailboxes are the one issue I've been glossing over
mailboxes need to be thread-safe
but if we follow message passing as the one and only communication mechanism, nothing else needs it
19:45 Coke joined 19:49 bubaflub joined 19:51 mikehh left 19:54 Coke left 19:55 Coke joined 19:56 bluescreen left, bluescreen joined
benabik Probably better to have a nice CAS op for M0, even if mailboxes are the only official usage of it exposed to anyone above. 19:57
whiteknight like I said, all M0 ops will be essentially atomic, so we can have whatever we want 19:58
CAS is as good a choice as any
19:58 ambs joined
sorear CAS2! *ducks* 20:05
20:06 Andy left, ShaneC joined
whiteknight msg plobsing if you have a spare moment, could you take a quick look at parrot-instrument src/dynpmc/instrumentruncore.pmc:runcore_optable_fixup? I think that's the source of (some of) our problems. Commenting it out reclaims several tests 20:07
aloha OK. I'll deliver the message.
lucian whiteknight: uh, you might not need to care about the thread-safety of the mailboxes 20:08
there are ready-made implementations, from signals to ampq
whiteknight that's fine too. We could easily create a PMC wrapper over an existing implementation 20:09
I'm consciously glossing over those kinds of details
20:17 Coke left, Coke joined 20:19 autark left 20:21 autark joined
whiteknight I think I just plain don't understand how oplibs work 20:22
clearly I don't understand it well enough to figure out why some of this crap is failing 20:23
part of me is starting to wonder if it's worth the effort to save parrot-instrument at all. All the changes to oplibs and packfiles between then and now have it broken pretty badly
20:26 Coke left, Coke joined 20:29 plobsing joined 20:31 dodathome left 20:32 fperrad left, perlite_ joined 20:33 Coke left, Coke joined 20:36 perlite left, perlite_ is now known as perlite
dalek p/ctmo: eed9b67 | jonathan++ | src/stage0/ (6 files):
Update the bootstrap with the various branch changes so far.
 20:44
p/ctmo: c74cce8 | jonathan++ | src/ (2 files):
Refactor to generate the prefixes list during the actions stage rather than using the one built in the regex compiler. This means it can be added through the compile-time meta-objects.
p/ctmo: 519ef59 | jonathan++ | src/stage0/ (6 files):
Update bootstrap.
p/ctmo: b6e14db | jonathan++ | src/PAST/Compiler-Regex.pir:
Remove now-unused prefix routine code-gen from the regex compiler.
20:45 Coke left, Coke joined 20:51 lucian_ joined 20:54 lucian left
dukeleto ~~ 20:55
20:57 Coke left, Coke joined
dalek p/ctmo: 811d9a5 | jonathan++ | src/NQP/ (2 files):
Eliminate a mention of $*PACKAGE-SETUP, which it's now time to start finally killing.
 20:58
21:11 SHODAN left 21:17 cotto joined 21:18 ambs left
dalek p/ctmo: 1a16b84 | jonathan++ | src/ (2 files):
Stub in initial bits towards role building refactor, which removes another usage of $*PACKAGE-SETUP. Finishing that is main task left in this branch.
 21:18
p/ctmo: f30806d | jonathan++ | src/ (2 files):
Switch .^compose to compile time meta-object. Darn...breaks multi-methods. :/
p/ctmo: 707bae5 | jonathan++ | src/NQP/ (2 files):
Remove last remaining usages of $*PACKAGE-SETUP.
21:46 cotto left 21:56 mj41 left 22:46 mtk left 22:53 plobsing_ joined, mtk joined 22:57 plobsing left 23:11 davidfetter joined
soh_cah_toa hey guys, i'm having some serious trouble trying to install winxed. anyone wanna try and take a look at this? 23:17
nopaste "soh_cah_toa" at 192.168.1.3 pasted "Problems With Winxed Installation" (40 lines) at nopaste.snit.ch/43085
plobsing_ looks like something is trying to allocate a silly amount of memory 23:21
92M is a rather large allocation 23:22
soh_cah_toa yeah, but i haven't a clue what or why
plobsing_ do you have gdb on hand? 23:23
soh_cah_toa of course
why, stacktrace maybe? 23:25
plobsing_ that's the first place to start
break on panic_failed_allocation 23:26
soh_cah_toa should i do 'gdb parrot winxedrun.pbc --stage=1 -c -o winxedst2.pir winxedst1.winxed'? b/c when i do, gdb complains that winxedrun.pbc is an unrecognized file format 23:31
benabik I think it's gdb --args parrot ...
sorear plobsing_: 92MB is not a silly allocation if it comes from compact_pool 23:32
soh_cah_toa i just loaded it w/ 'file' after already in gdb
actually that worked 23:33
i spoke too soon
anyway, i can't 'break panic_failed_allocation' b/c it says its undefined
plobsing_ you'll need to run it once so gdb loads the shared lib where the function resides 23:39
soh_cah_toa yup, there we go 23:40
alright, i'm at panic_failed_allocation
plobsing_ bt will give you a backtrace 23:41
nopaste "soh_cah_toa" at 192.168.1.3 pasted "Backtrace at panic_failed_allocation()" (65 lines) at nopaste.snit.ch/43086 23:43
plobsing_ sorear: looks like you called it 23:44
sorear: how much memory do you have on that system?
er soh_cah_toa: ^^^^ 23:45
soh_cah_toa it's a vm. i gave it 1024 megs
plobsing_ ulimit?
23:45 lucian joined
soh_cah_toa unlimited 23:45
23:46 mikehh joined
plobsing_ what does the memory usage climb to? 23:47
soh_cah_toa how do i get that? 23:48
23:49 lucian_ left
plobsing_ when you are at the breakpoint in gdb, run 'ps aux' in another terminal. 23:51
%MEM, VSZ, and RSS are all somewhat meaningful 23:52
soh_cah_toa alright, h/o
%MEM: 63.7 VSZ: 1034084 RSS: 653348 23:55
soh_cah_toa will be right back 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!