Camelia, the Perl 6 bug

IRC log for #parrot, 2010-10-31

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 kurahaupo left #parrot
00:43 plobsing joined #parrot
00:54 lucian_ left #parrot
01:03 whiteknight joined #parrot
01:20 tcurtis left #parrot
01:22 patspam left #parrot
01:22 tcurtis joined #parrot
01:27 dalek parrot: r49742 | plobsing++ | branches/gsoc_nci (2 files):
01:27 dalek parrot: add string nci argument translation and simplify nci.mark()
01:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49742/
01:27 dalek parrot: r49743 | plobsing++ | branches/gsoc_nci/src/multidispatch.c:
01:27 dalek parrot: constant PMCs are wrong, double wrong, and dead wrong
01:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49743/
01:36 kid51 tcurtis ping
01:37 tcurtis kid51: pong
01:37 kid51 Apart from lack of tuits, what keeps gsoc_past_optimization from being merged into trunk?
01:39 kid51 dukeleto:  Have you had a chance to look at the gcc_defines branch in relation to the rtems ticket?
01:43 tcurtis kid51: IIRC, there's some bug in PAST::Optimizer.run(:combine(1)) that doesn't show up in my tests but did when I used it on NQP. In addition, I'll need to move it back over to Parrot's build system and move it back into the branch (for a while, I was developing it as a separate module).
01:44 kid51 Were you able to write a test for that bug?
01:44 kid51 i.e., a test that will pass when the bug is fixed?
01:56 davidfetter left #parrot
01:57 Kulag left #parrot
01:57 Kulag joined #parrot
01:58 dalek parrot: r49744 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
01:58 dalek parrot: add a numval nci argument translation entry
01:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49744/
02:02 kid51 msg dukeleto Seeking feedback on TT #1840 and #1516.
02:02 aloha OK. I'll deliver the message.
02:03 whiteknight left #parrot
02:05 jhelwig left #parrot
02:11 tcurtis left #parrot
02:11 stilgar left #parrot
02:26 tcurtis joined #parrot
02:26 tcurtis left #parrot
02:30 kid51 left #parrot
02:48 tcurtis joined #parrot
02:49 tcurtis msg kid51 Unfortunately, not yet (writing a test for the bug). I haven't been able to diagnose what exactly went wrong.
02:49 aloha OK. I'll deliver the message.
02:57 tcurtis left #parrot
03:09 tcurtis joined #parrot
03:11 mikehh left #parrot
03:29 tcurtis left #parrot
03:31 cotto aloha, clock?
03:31 aloha cotto: cotto: LAX: Sat, 20:31 PDT / CHI: Sat, 22:31 CDT / NYC: Sat, 23:31 EDT / UTC: Sun, 03:31 UTC / LON: Sun, 03:31 GMT / BER: Sun, 04:31 CET / TOK: Sun, 12:31 JST / SYD: Sun, 14:31 EST
04:33 theory left #parrot
05:21 sorear cotto: ping
05:25 cotto sorear, pong
05:26 sorear I am starting to think in terms of multiple implementations of Lorito
05:27 cotto We expect to have several before all is said and done.
05:28 cotto atrodo said that it wasn't all that hard to implement his Lorito prototype and that he enjoyed it.
05:28 cotto well, is enjoying it
05:28 cotto I saw some commits recently
05:28 sorear I just realized that the C# layer of Niecza looks very much like a Lorito prototype
05:29 sorear it implements a very simple language, it supports CPS, higher-level features are built on top of it
05:29 cotto Something I've been wondering to myself is whether someone's already implemented Lorito, just under a different name.
05:29 sorear it implements an abstracted API which I can port to a bytecode interpreter, LLVM, or Java without too much difficulty
05:30 cotto I'll have to look at it.  It sounds shiny and potentially useful.
05:30 sorear How it works in my head is not quite how it's currently implemented
05:31 sorear I haven't finished shaving the abstraction yaks, and there isn't a disk format yet
05:31 * cotto can't see diakopter's name without thinking of a helicopter that makes a "dia-dia-dia" noise.
05:31 cotto you mean niecza?
05:32 sorear yes
05:33 cotto What's worth stealing from it for Lorito, iyho?
05:34 sorear What is Lorito's state of the art?
05:35 cotto The best implementation is one that serves primarily as a prototype to flesh out the spec.
05:36 sorear I think the basic vision is possibly worth stealing
05:36 sorear ie, 'Lorito' is a VM in and of itself
05:36 sorear 'Lorito' presents a somewhat-consistant API and a smallish set of features
05:36 cotto yes
05:36 cotto also yes
05:37 sorear 'Parrot' is a program built on top or 'Lorito' at the same time that it is a VM
05:37 cotto well, it should be very consistent
05:37 sorear It might be worth letting things like sizeof(int) leak through.
05:37 sorear You could in theory use Lorito without Parrot, althoguh you'd be sacrificing a lot of functionality
05:38 sorear and at the same time, porting Parrot to a new VM would require porting only Lorito
05:38 cotto Lorito will be a very minimalist VM, so you could do whatever you like with it.  Parrot will happen to use it extensively.
05:38 cotto very yes
05:39 cotto well, Lorito plus the parts of Parrot we can't reimplement in a Lorito overlay language
05:41 sorear a month ago, NAM was called CgOp and it thought of itself as an AST for constructing C# which used dynamic calling conventions and CPS
05:41 sorear and the rest of the compiler pervasively used .NET libraries
05:41 sorear but I've reimagined it a bit lately - NAM has wrappers over I/O functions, sorting, etc
05:42 sorear and I've narrowed the CLR type system down to a set of about 20 types
05:42 sorear int, str, num, obj, etc
05:43 sorear the biggest difference is that NAM is a tree code with a Lisp-like semantic structure
05:43 sorear not a three-operand code
05:43 cotto NAM?
05:44 sorear Niecza Abstract Machine, the thing which I think I accidentally reinvented Lorito on
05:44 cotto ah
05:45 sorear also I haven't been shy about letting NAM know what it needs to support
05:45 sorear it has native support for Perl 6 containers
05:45 sorear and a dozen specialized ops to support the regex system
05:46 * cotto was looking at diakopter's niecza, not yours
05:47 cotto That makes more sense.
05:47 sorear diakopter has a niecza now?
05:47 sorear changing the name was the first thing I did after the fork
05:48 cotto http://github.com/diakopter/niecza
05:48 cotto Ah.  It's a fork of yours.
05:48 plobsing sorear: a dozen special case regex ops? how easily could those be stolen by rakudo, turned into parrot dynops, and used to speed up it's regex engine?
05:49 sorear Rakudo doesn't have a regex engine of its own; it reuses the nqp-rx regex system
05:50 sorear this is expedient now and will eventually be essential (Perl 6 macros need to fuse their grammars with the Perl 6 grammar, which is at the NQP level)
05:50 sorear and NQP-rx, up until last week or so, had a commitment to not use custom C code
05:52 sorear pmichaud has stated in so many words that, now that nqp is using custom C, the parsing system could be sped up a fair amount
05:52 sorear but I guess he hasn't had time yet
05:52 sorear (the commitment was broken for jnthn++'s new implementation of the Object and Class PMCs)
05:53 * cotto wonders about implementing a Lorito prototype in Perl 5 with the goal of reimplementing in C once the spec is solid enough.
05:55 sorear there may be something to be learned from NAM's type system, though I'm not quite sure how it can be abstracted (to systems other than Perl 6) yet
05:56 sorear str: A simple string.  Maps to: CLR System.String, Parrot str
05:56 sorear strbuf: A mutable string.  Maps to: CLR System.Text.StringBuilder, Parrot pmc
05:56 sorear ...
05:57 sorear var: A reference to a Perl 6 container.  Maps to: CLR Niecza.Variable, Parrot pmc
05:57 sorear fvarlist: An unboxed Parcel, maps to: CLR Niecza.Variable[], Parrot pmc
05:57 sorear the full list is in src/CLRTypes.pm
05:58 sorear the NAM-on-Parrot backend is in late design stage; not much code yet
05:58 sorear the CLR requires a detailed (just saying 'ref' isn't good enough) type for each object
06:02 cotto It sounds like you'll be a good person to have helping with Lorito.
06:04 plobsing at one point, the some of the inner parts of core implemented in lorito were going to be translated to C and compiled at build time. is that still happening?
06:05 plobsing because, if that is happening, it might be good to make sure we can do that early. don't want to implement something we have to always interpret (slow) or jit (not always available)
06:06 cotto plobsing, translating Lorito into snippets of C which can then be compiled into a standalone executable is still part of the plan
06:07 cotto I don't think it will be an unreasonable amount of additional effort once we settle on what the VM looks like.
06:07 sorear plobsing: that's already part of the NAM plan.
06:07 cotto In my mind, that's how we'll eventually solve the bootstrapping problem.
06:08 sorear NAM right now is strictly a translator, but it's going to get some kind of "string eval" op
06:08 plobsing one sticky point I've been thinking about is how do we call native functions (and there will be some of those) without using ffi (because you can't rely on llvm, libjit, libffi, or even dlopen being present)
06:08 sorear the static translator can generate native calls no problem
06:08 * sorear contemplates retooling NAM into a LoritoPrototype
06:08 cotto That's a very important point to allow interop between Lorito components and parrot guts written in C.
06:09 plobsing sure you can generate native calls, but how do you specify the static call in loriot bytecode?
06:09 sorear using a libffi-ish signature
06:09 sorear the static translator can statically generate them
06:09 sorear the dynamic translator will use libffi et al, or fail if unavailable
06:11 plobsing fail if unavailable is epic fail for parrot's lorito. we depend on calling in to C bits, so libffi becomes a hard dependancy (bloat undesirable in embedded devices)
06:12 plobsing we need to have a Lorito->C translator translate staticly resolvable C calls statically
06:12 sorear we depend on calling in to C bits *dynamically*
06:12 sorear er
06:12 sorear *statically*
06:13 plobsing I think we're on the same page then.
06:13 sorear I don't think it's unreasonable to make C calls from runtime-compiled code fail in an embedded environment
06:13 cotto plobsing, does your question boil down to "If Parrot is implemented primarily in lorito, how do we call gettimeofday()?"
06:14 plobsing yes. or more importantly, how do we call Parrot_gc_invoke() (assuming gc is implented in C)
06:16 sorear Thank you.
06:16 sorear I get it now - The regex bits, etc, are just library bindings
06:17 sorear NAM will treat library calls syntactally as opcode set extensions
06:17 sorear there will be a directive that binds (gettimeofday) to gettimeofday(), etc
06:17 sorear so I *can* pull the Perl 6 specific bits out, and I *can* retool NAM into a loritoprototype
06:17 sorear shouldn't take me more than two weeks
06:17 sorear and it's stuff I'm planning to do anyway
06:18 sorear one thorn remains - calling conventions
06:18 sorear right now NAM assumes that every code object receives some positional arguments and some named arguments, all in object form
06:19 cotto Lorito will use fixed 3-args ops.
06:20 sorear How many args will callsub take?
06:20 sorear And what kind of args?
06:21 dalek parrot: r49745 | plobsing++ | branches/gsoc_nci (2 files):
06:21 dalek parrot: avoid rebuilding the pcc cif every call
06:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49745/
06:22 plobsing invokecc in parrot is almost in 3-arg form already
06:23 sorear How many arguments will the sub receive?
06:23 plobsing the third arg is simply flattened into a vararg
06:23 plobsing (vararg ops turned out not to be such a great idea)
06:23 plobsing invokecc sub, flags, args
06:23 sorear In current Parrot, every sub receives 0 or more positional pmc arguments, and 0 or more named pmc arguments
06:24 sorear Should Lorito be the same?
06:24 cotto Control flow will be via CPS build on top of goto.  I need to talk with chromatic and read up on how it'll work.
06:25 plobsing IIUC, lorito is a semantically similar VM with different underpinnings. Using that logic, PCC capabilities shouldn't change much.
06:25 plobsing pcc *implementation* could change drastically though
06:26 cotto PCC capabilities shouldn't change at all due to Lorito.
06:27 plobsing which means the answer is yes to lorito being the same in terms of sub args
06:28 cotto I think we agree.
06:29 cotto btw, if either of you understand CPS well enough to see how it'd work with goto, I'd appreciate a primer.
06:31 sorear Does anyone have the link handy for why Parrot uses registers?
06:32 plobsing there's a reasonably good explanation somewhere in http://www.sidhe.org/~dan/blog/archives/
06:32 cotto I remember reading something about that when I was first trying to learn about Parrot.
06:33 plobsing as with anything else architectural in parrot dating back far enough
06:33 fperrad joined #parrot
06:33 cotto http://www.sidhe.org/~dan/​blog/archives/000189.html
06:37 sorear thanks.
06:37 cotto np
06:39 Tene plobsing: what is the 'flags' argument to invokecc?
06:41 plobsing indicates the meaning of each element of the args agregate
06:42 plobsing was it a named or positional argument?
06:42 plobsing was it slurpy?
06:42 Tene plobsing: I expected that to be wrapped in a callargs PMC oslt.
06:42 Tene Hmm.
06:42 plobsing also, what register family is it from?
06:43 plobsing maybe it doesn't exist in the new pcc. that's just how we have things now. and it maps pretty closely to 3-arg form
06:45 Tene I've been out of it that I wouldn't be surprised to be misinformed or misremembering.
06:46 plobsing I'm not an expert in matters PCC. better to ask chromatic, whiteknight, etc for a definitive answer. this is just what I've picked up (and it seems to work).
06:53 cotto The Lorito reimplementations will be a great opportunity for new people to learn how core systems like PCC work.
06:54 sorear OK, I have one more issue
06:54 cotto I'm all ears.
06:54 sorear here's a sample NAM fragment: (say (string_append (s "Hello ") (s "world")))
06:54 sorear the NAM to C# compiler generates: Console.WriteLine(string.Append(@"Hello ", @"world"))
06:55 sorear if I had the input in Lorito 3-arg form,
06:55 sorear string_append TEMP, "Hello ", "world"
06:55 sorear say TEMP
06:55 cotto something like that
06:55 sorear how would the translator know that TEMP can stay on the stack?
06:56 cotto What stack?
06:56 sorear The CLR evaluation stack.
06:57 sorear Like it or not, not all my targets are register machines.
06:57 plobsing you could get that information from a register allocator
06:57 cotto I see what you're getting at.
07:00 sorear I could use a register allocator, yes
07:00 sorear but it seems silly to throw away the information when at least two of the backends (CLR, Java) will need it
07:09 plobsing I'm not sure theres a good way to maintain that kind of information in a register bytecode
07:40 sorear How much has the surface syntax of lasm been nailed down?
07:41 cotto not much
07:41 cotto the prototype implementations fill in the gaps differently
07:45 sorear ok.  I think I have enough to start.
07:53 cotto sorear++
07:57 * cotto sleeps
08:03 jsut_ joined #parrot
08:07 jsut left #parrot
08:11 fperrad_ joined #parrot
08:14 tadzik joined #parrot
08:14 fperrad left #parrot
08:14 fperrad_ is now known as fperrad
08:14 tadzik g'morning
08:44 fperrad_ joined #parrot
08:46 muixirt joined #parrot
08:48 fperrad left #parrot
08:48 fperrad_ is now known as fperrad
08:50 muixirt hi fperrad
08:51 muixirt fperrad: the ecmascript compiler doesn't build (error:imcc:loadlib directive could not find library `js_group')
08:51 muixirt fperrad: do you have any advice?
08:59 tadzik left #parrot
09:17 fperrad muixirt, in js.pir, remove the line with .loadlib 'js_group'
09:17 fperrad this line was never useful, but before .loadlib fails silently
09:18 muixirt fperrad: I tried that and got different errors
09:20 muixirt fixed missing ops and ecmascript builds now
09:27 muixirt fperrad: now I get test errors (Can't locate Parrot/Test.pm)
09:40 muixirt has there been a 'List' pmc?
09:41 fperrad muixirt, tests use Perl5, so try :
09:41 fperrad $ perl -I your_good_path t/harness
09:41 muixirt perl is invoked: perl -I/home/klaus/build/exe/lib/parrot/2.9.1/tools/lib t/harness
09:42 muixirt and that lib contains Parrot/Test.pm
09:50 fperrad muixirt, ecmascript seems really broken, so let start with simple test, for example :
09:50 fperrad $ parrot js.pbc t/01-literals.t
09:51 muixirt Null PMC access in type()
09:51 muixirt hence the question with pmc 'List'
09:53 muixirt the maintainer seems to be long gone
09:54 muixirt seen tewk
09:54 aloha Sorry, I haven't seen tewk.
09:55 nopaste "muixirt" at 192.168.1.3 pasted "ecmascript testing problems (fperrad)" (7 lines) at http://nopaste.snit.ch/25065
09:57 muixirt js.pir:83 $P0 = new 'List' <-- there is this 'List' coming from?
09:57 fperrad in Parrot, no List PMC
09:57 fperrad in js.pir, List is defined as an PIR extension of the ResizablePMCArray PMC
09:59 muixirt "At some point, this should be refactored/reused." seems to be good advice :-)
10:08 fperrad muixirt, you try to remove List (it is  just sugar for NQP), and use ResizablePMCArray
10:09 fperrad but instead of
10:09 fperrad $past.unshift(...)  # method call
10:09 fperrad inline PIR works well
10:09 fperrad pir::unshift($past, ...) # PIR opcode
10:09 contingencyplan left #parrot
10:09 contingencyplan joined #parrot
10:14 contingencyplan left #parrot
10:52 lucian joined #parrot
11:49 M_o_C joined #parrot
11:55 cognominal left #parrot
12:00 mikehh joined #parrot
12:08 muixirt left #parrot
12:19 fperrad_ joined #parrot
12:21 kid51 joined #parrot
12:23 fperrad left #parrot
12:23 fperrad_ is now known as fperrad
12:49 whiteknight joined #parrot
13:38 patspam joined #parrot
14:02 whiteknight left #parrot
14:03 fperrad_ joined #parrot
14:06 fperrad left #parrot
14:06 fperrad_ is now known as fperrad
14:40 jan left #parrot
14:54 dalek parrot: r49746 | nwellnhof++ | branches/string_checks:
14:54 dalek parrot: More thorough checks of string contents
14:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49746/
14:57 davidfetter joined #parrot
14:58 JimmyZ joined #parrot
15:10 dalek parrot: r49747 | nwellnhof++ | branches/string_checks (9 files):
15:10 dalek parrot: [str] Merge some ASCII and Latin1 functions
15:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49747/
15:10 dalek parrot: r49748 | nwellnhof++ | branches/string_checks (27 files):
15:10 dalek parrot: [str] Encoding cleanup
15:10 dalek parrot: There are several places where strings are created with the default
15:10 dalek parrot: ASCII encoding and filled with binary data. This commit fixes hopefully
15:10 dalek parrot: all of these cases and adds checks for ASCII data in Parrot_str_new_init
15:10 dalek parrot: and STRING_iter_set_and_advance.
15:10 dalek parrot: This commit also adds the "b" flag to FileHandle.open as a shortcut to
15:10 dalek parrot: open a file in binary mode.
15:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49748/
15:10 dalek parrot: r49749 | nwellnhof++ | branches/string_checks (4 files):
15:10 dalek parrot: [str] UTF-8 checks
15:10 dalek parrot: Don't allow overlong forms. Perform all checks during initial scan.
15:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49749/
15:11 dalek parrot: r49750 | nwellnhof++ | branches/string_checks (11 files):
15:11 dalek parrot: [str] Rewrite UTF-16 encoding to work without ICU
15:11 dalek parrot: Perform all checks during initial scan.
15:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49750/
15:11 dalek parrot: r49751 | nwellnhof++ | branches/string_checks (6 files):
15:11 dalek parrot: [str] Add checks for UCS-2 and UCS-4
15:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49751/
15:11 dalek parrot: r49752 | nwellnhof++ | branches/string_checks (16 files):
15:11 dalek parrot: [str] Remove unneeded STRING_validate
15:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49752/
15:11 dalek parrot: r49753 | nwellnhof++ | branches/string_checks/src/string (2 files):
15:11 dalek parrot: [str] Throw exception on some binary string ops
15:11 dalek parrot: Don't allow cclass and Unicode operations on binary strings.
15:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49753/
15:17 kid51 msg nwellnhof Is the string_checks branch tied to any particular Trac ticket?
15:17 aloha OK. I'll deliver the message.
15:26 dalek parrot: r49754 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
15:26 dalek parrot: logically separate dynamic call to Parrot_pcc_fill_params_from_c_args
15:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49754/
15:27 nwellnhof joined #parrot
15:28 nwellnhof kid51: no, string_checks isn't tied to a ticket.
15:28 dngor left #parrot
15:28 dngor joined #parrot
15:32 kid51 nwellnhof Do you think you could post a description of what it's about?
15:33 nwellnhof see my mail to parrot-dev.
15:33 kid51 Okay, I see it (It hadn't arrived when dalek started to report commits)  Thanks.
15:36 kid51 Would this be relevant for either TT #1778 or TT #1808?
15:37 nwellnhof No, it's independent of those tickets.
15:41 dalek parrot: r49755 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
15:41 dalek parrot: in stead of keeping track of when we don't advance in PCC wrt NCI, keep separate iterators for each
15:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49755/
15:41 dalek parrot: r49756 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
15:41 dalek parrot: dead variables and simplify memory free
15:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49756/
15:43 jan joined #parrot
16:13 dalek parrot: r49757 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
16:13 dalek parrot: simplify, eliminate memory leak in pass by reference types
16:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49757/
16:28 dalek parrot: r49758 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
16:28 dalek parrot: cosmetic changes to nci argument decode
16:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49758/
16:28 dalek parrot: r49759 | plobsing++ | branches/gsoc_nci/config/g​en/libffi/nci-ffi.pmc.in:
16:28 dalek parrot: copy nci.pmc into config files (will survive reconfig)
16:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49759/
16:32 tadzik joined #parrot
16:33 tadzik hello
16:35 JimmyZ hi
16:36 cotto ~~
16:38 tadzik oh, cotto. I'd like to help implementing Lorito, heard that you're the one to ask for further guidance
16:41 cotto tadzik, thanks for volunteering.  I'm reading through design questions that need to be answered.  Once I'm convinced that the questions are important, I'll put them on a wiki and ask for answers.
16:42 cotto Once a good subset of those are answered, I'll call a #ps-style meeting for any volunteers and we'll hash out the rest of the issues.
16:44 tadzik good
16:44 cotto tadzik, what's your background and what makes you want to help with Lorito?  (This isn't an interview.  I'd just like to know where you come from.)
16:45 tadzik cotto: I'm studying CS at Warsaw University of Technology, I'd like to help Parrot development, I know my way around in C, and after some discussion on parrot-dev and here on the channel I decided to go for Lorito
16:45 kid51 JimmyZ:  Hi! What's up?
16:46 cotto tadzik, do you have an area of focus or are you doing general CS?
16:47 JimmyZ nothing, just my respects to tadzik :)
16:47 tadzik cotto: well, I like programming :) I came here from a Perl 6 world too
16:47 tadzik and I'd like to do some Programming, not just Glueing Libraries Together
16:48 cotto You'll have plenty of opportunity then.
16:48 tadzik That's what I'm aiming at
16:49 tadzik and Lorito didn't look so Black-Magical like GC or Threading
16:49 cotto No.  It should be as unmagical as possible.
16:54 cotto dukeleto, ping
17:06 JimmyZ left #parrot
17:21 AzureSto_ left #parrot
17:23 AzureStone joined #parrot
17:27 raek left #parrot
17:32 patspam left #parrot
17:35 cognominal joined #parrot
17:48 nwellnhof left #parrot
17:56 theory joined #parrot
17:57 M_o_C left #parrot
18:00 plobsing left #parrot
18:02 PacoLinux left #parrot
18:05 PacoLinux joined #parrot
18:08 chromatic joined #parrot
18:19 tadzik left #parrot
18:27 contingencyplan joined #parrot
18:31 PacoLinux left #parrot
18:34 plobsing joined #parrot
18:36 tadzik joined #parrot
18:54 tadzik left #parrot
19:14 kid51 left #parrot
19:28 PacoLinux joined #parrot
19:39 tadzik joined #parrot
19:42 dukeleto ~~
19:43 dukeleto kid51: pong
20:05 dukeleto kid51: i don't understand why you are making "check the definedness of __rtems__" so complicated. It is 3 lines of code.
20:14 mikehh left #parrot
20:17 Limbic_Region joined #parrot
20:19 mikehh joined #parrot
20:21 jsut joined #parrot
20:26 jsut_ left #parrot
20:50 cotto ~~
21:02 AzureStone left #parrot
21:02 AzureStone joined #parrot
21:07 perlite_ left #parrot
21:09 perlite joined #parrot
21:15 cotto chromatic, I have to take off but I've added some more questions to http://trac.parrot.org/parro​t/wiki/LoritoDesignQuestions .  Your thoughts would be appreciated.
21:32 chromatic Will do.
21:38 Andy joined #parrot
22:17 sorear is it just me or has trac.parrot.org gotten slightly less unusable
22:23 bacek_at_work ~~
22:31 patspam joined #parrot
22:40 fperrad left #parrot
22:43 tadzik left #parrot
22:47 bacek_at_work chromatic, we are doing lookups in LinkedLists only during tracing C stack.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced