Parrot 2.9.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | remove deprecations | volunteer for embedding or Lorito teams |
Set by moderator on 26 October 2010.
00:15 kurahaupo left 00:43 plobsing joined 00:54 lucian_ left 01:03 whiteknight joined 01:20 tcurtis left 01:22 patspam left, tcurtis joined
dalek rrot: r49742 | plobsing++ | branches/gsoc_nci (2 files):
add string nci argument translation and simplify nci.mark()
 01:27
rrot: r49743 | plobsing++ | branches/gsoc_nci/src/multidispatch.c:
constant PMCs are wrong, double wrong, and dead wrong
kid51 tcurtis ping 01:36
tcurtis kid51: pong 01:37
kid51 Apart from lack of tuits, what keeps gsoc_past_optimization from being merged into trunk?
dukeleto: Have you had a chance to look at the gcc_defines branch in relation to the rtems ticket? 01:39
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:43
kid51 Were you able to write a test for that bug? 01:44
i.e., a test that will pass when the bug is fixed?
01:56 davidfetter left 01:57 Kulag left, Kulag joined
dalek rrot: r49744 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
add a numval nci argument translation entry
 01:58
kid51 msg dukeleto Seeking feedback on TT #1840 and #1516. 02:02
aloha OK. I'll deliver the message.
02:03 whiteknight left 02:05 jhelwig left 02:11 tcurtis left, stilgar left 02:26 tcurtis joined, tcurtis left 02:30 kid51 left 02:48 tcurtis joined
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 03:09 tcurtis joined 03:11 mikehh left 03:29 tcurtis left
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
sorear cotto: ping 05:21
cotto sorear, pong 05:25
sorear I am starting to think in terms of multiple implementations of Lorito 05:26
cotto We expect to have several before all is said and done. 05:27
atrodo said that it wasn't all that hard to implement his Lorito prototype and that he enjoyed it. 05:28
well, is enjoying it
I saw some commits recently
sorear I just realized that the C# layer of Niecza looks very much like a Lorito prototype
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.
sorear it implements an abstracted API which I can port to a bytecode interpreter, LLVM, or Java without too much difficulty
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
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.
you mean niecza?
sorear yes 05:32
cotto What's worth stealing from it for Lorito, iyho? 05:33
sorear What is Lorito's state of the art? 05:34
cotto The best implementation is one that serves primarily as a prototype to flesh out the spec. 05:35
sorear I think the basic vision is possibly worth stealing 05:36
ie, 'Lorito' is a VM in and of itself
'Lorito' presents a somewhat-consistant API and a smallish set of features
cotto yes
also yes
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
sorear It might be worth letting things like sizeof(int) leak through.
You could in theory use Lorito without Parrot, althoguh you'd be sacrificing a lot of functionality
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.
very yes
well, Lorito plus the parts of Parrot we can't reimplement in a Lorito overlay language 05:39
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
and the rest of the compiler pervasively used .NET libraries
but I've reimagined it a bit lately - NAM has wrappers over I/O functions, sorting, etc
and I've narrowed the CLR type system down to a set of about 20 types 05:42
int, str, num, obj, etc
the biggest difference is that NAM is a tree code with a Lisp-like semantic structure 05:43
not a three-operand code
cotto NAM?
sorear Niecza Abstract Machine, the thing which I think I accidentally reinvented Lorito on 05:44
cotto ah
sorear also I haven't been shy about letting NAM know what it needs to support 05:45
it has native support for Perl 6 containers
and a dozen specialized ops to support the regex system
cotto was looking at diakopter's niecza, not yours 05:46
That makes more sense. 05:47
sorear diakopter has a niecza now?
changing the name was the first thing I did after the fork
cotto github.com/diakopter/niecza 05:48
Ah. It's a fork of yours.
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?
sorear Rakudo doesn't have a regex engine of its own; it reuses the nqp-rx regex system 05:49
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
and NQP-rx, up until last week or so, had a commitment to not use custom C code
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
but I guess he hasn't had time yet
(the commitment was broken for jnthn++'s new implementation of the Object and Class PMCs)
cotto wonders about implementing a Lorito prototype in Perl 5 with the goal of reimplementing in C once the spec is solid enough. 05:53
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:55
str: A simple string. Maps to: CLR System.String, Parrot str 05:56
strbuf: A mutable string. Maps to: CLR System.Text.StringBuilder, Parrot pmc
...
var: A reference to a Perl 6 container. Maps to: CLR Niecza.Variable, Parrot pmc 05:57
fvarlist: An unboxed Parcel, maps to: CLR Niecza.Variable[], Parrot pmc
the full list is in src/CLRTypes.pm
the NAM-on-Parrot backend is in late design stage; not much code yet 05:58
the CLR requires a detailed (just saying 'ref' isn't good enough) type for each object
cotto It sounds like you'll be a good person to have helping with Lorito. 06:02
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:04
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:05
cotto plobsing, translating Lorito into snippets of C which can then be compiled into a standalone executable is still part of the plan 06:06
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.
cotto In my mind, that's how we'll eventually solve the bootstrapping problem.
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)
sorear the static translator can generate native calls no problem
sorear contemplates retooling NAM into a LoritoPrototype
cotto That's a very important point to allow interop between Lorito components and parrot guts written in C.
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
the static translator can statically generate them
the dynamic translator will use libffi et al, or fail if unavailable
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:11
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*
er
*statically*
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
cotto plobsing, does your question boil down to "If Parrot is implemented primarily in lorito, how do we call gettimeofday()?"
plobsing yes. or more importantly, how do we call Parrot_gc_invoke() (assuming gc is implented in C) 06:14
sorear Thank you. 06:16
I get it now - The regex bits, etc, are just library bindings
NAM will treat library calls syntactally as opcode set extensions 06:17
there will be a directive that binds (gettimeofday) to gettimeofday(), etc
so I *can* pull the Perl 6 specific bits out, and I *can* retool NAM into a loritoprototype
shouldn't take me more than two weeks
and it's stuff I'm planning to do anyway
one thorn remains - calling conventions 06:18
right now NAM assumes that every code object receives some positional arguments and some named arguments, all in object form
cotto Lorito will use fixed 3-args ops. 06:19
sorear How many args will callsub take? 06:20
And what kind of args?
dalek rrot: r49745 | plobsing++ | branches/gsoc_nci (2 files):
avoid rebuilding the pcc cif every call
 06:21
plobsing invokecc in parrot is almost in 3-arg form already 06:22
sorear How many arguments will the sub receive? 06:23
plobsing the third arg is simply flattened into a vararg
(vararg ops turned out not to be such a great idea)
invokecc sub, flags, args
sorear In current Parrot, every sub receives 0 or more positional pmc arguments, and 0 or more named pmc arguments
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.
plobsing IIUC, lorito is a semantically similar VM with different underpinnings. Using that logic, PCC capabilities shouldn't change much. 06:25
pcc *implementation* could change drastically though
cotto PCC capabilities shouldn't change at all due to Lorito. 06:26
plobsing which means the answer is yes to lorito being the same in terms of sub args 06:27
cotto I think we agree. 06:28
btw, if either of you understand CPS well enough to see how it'd work with goto, I'd appreciate a primer. 06:29
sorear Does anyone have the link handy for why Parrot uses registers? 06:31
plobsing there's a reasonably good explanation somewhere in www.sidhe.org/~dan/blog/archives/ 06:32
cotto I remember reading something about that when I was first trying to learn about Parrot.
plobsing as with anything else architectural in parrot dating back far enough 06:33
06:33 fperrad joined
cotto www.sidhe.org/~dan/blog/archives/000189.html 06:33
sorear thanks. 06:37
cotto np
Tene plobsing: what is the 'flags' argument to invokecc? 06:39
plobsing indicates the meaning of each element of the args agregate 06:41
was it a named or positional argument? 06:42
was it slurpy?
Tene plobsing: I expected that to be wrapped in a callargs PMC oslt.
Hmm.
plobsing also, what register family is it from?
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:43
Tene I've been out of it that I wouldn't be surprised to be misinformed or misremembering. 06:45
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:46
cotto The Lorito reimplementations will be a great opportunity for new people to learn how core systems like PCC work. 06:53
sorear OK, I have one more issue 06:54
cotto I'm all ears.
sorear here's a sample NAM fragment: (say (string_append (s "Hello ") (s "world")))
the NAM to C# compiler generates: Console.WriteLine(string.Append(@"Hello ", @"world"))
if I had the input in Lorito 3-arg form, 06:55
string_append TEMP, "Hello ", "world"
say TEMP
cotto something like that
sorear how would the translator know that TEMP can stay on the stack?
cotto What stack? 06:56
sorear The CLR evaluation stack.
Like it or not, not all my targets are register machines. 06:57
plobsing you could get that information from a register allocator
cotto I see what you're getting at.
sorear I could use a register allocator, yes 07:00
but it seems silly to throw away the information when at least two of the backends (CLR, Java) will need it
plobsing I'm not sure theres a good way to maintain that kind of information in a register bytecode 07:09
sorear How much has the surface syntax of lasm been nailed down? 07:40
cotto not much 07:41
the prototype implementations fill in the gaps differently
sorear ok. I think I have enough to start. 07:45
cotto sorear++ 07:53
cotto sleeps 07:57
08:03 jsut_ joined 08:07 jsut left 08:11 fperrad_ joined 08:14 tadzik joined, fperrad left, fperrad_ is now known as fperrad
tadzik g'morning 08:14
08:44 fperrad_ joined 08:46 muixirt joined 08:48 fperrad left, fperrad_ is now known as fperrad
muixirt hi fperrad 08:50
fperrad: the ecmascript compiler doesn't build (error:imcc:loadlib directive could not find library `js_group') 08:51
fperrad: do you have any advice?
08:59 tadzik left
fperrad muixirt, in js.pir, remove the line with .loadlib 'js_group' 09:17
this line was never useful, but before .loadlib fails silently
muixirt fperrad: I tried that and got different errors 09:18
fixed missing ops and ecmascript builds now 09:20
fperrad: now I get test errors (Can't locate Parrot/Test.pm) 09:27
has there been a 'List' pmc? 09:40
fperrad muixirt, tests use Perl5, so try : 09:41
$ perl -I your_good_path t/harness
muixirt perl is invoked: perl -I/home/klaus/build/exe/lib/parrot/2.9.1/tools/lib t/harness
and that lib contains Parrot/Test.pm 09:42
fperrad muixirt, ecmascript seems really broken, so let start with simple test, for example : 09:50
$ parrot js.pbc t/01-literals.t
muixirt Null PMC access in type() 09:51
hence the question with pmc 'List'
the maintainer seems to be long gone 09:53
seen tewk 09:54
aloha Sorry, I haven't seen tewk.
nopaste "muixirt" at 192.168.1.3 pasted "ecmascript testing problems (fperrad)" (7 lines) at nopaste.snit.ch/25065 09:55
muixirt js.pir:83 $P0 = new 'List' <-- there is this 'List' coming from? 09:57
fperrad in Parrot, no List PMC
in js.pir, List is defined as an PIR extension of the ResizablePMCArray PMC
muixirt "At some point, this should be refactored/reused." seems to be good advice :-) 09:59
fperrad muixirt, you try to remove List (it is just sugar for NQP), and use ResizablePMCArray 10:08
but instead of 10:09
$past.unshift(...) # method call
inline PIR works well
pir::unshift($past, ...) # PIR opcode
10:09 contingencyplan left, contingencyplan joined 10:14 contingencyplan left 10:52 lucian joined 11:49 M_o_C joined 11:55 cognominal left 12:00 mikehh joined 12:08 muixirt left 12:19 fperrad_ joined 12:21 kid51 joined 12:23 fperrad left, fperrad_ is now known as fperrad 12:49 whiteknight joined 13:38 patspam joined 14:02 whiteknight left 14:03 fperrad_ joined 14:06 fperrad left, fperrad_ is now known as fperrad 14:40 jan left
dalek rrot: r49746 | nwellnhof++ | branches/string_checks:
More thorough checks of string contents
 14:54
14:57 davidfetter joined 14:58 JimmyZ joined
dalek rrot: r49747 | nwellnhof++ | branches/string_checks (9 files):
[str] Merge some ASCII and Latin1 functions
 15:10
rrot: r49748 | nwellnhof++ | branches/string_checks (27 files):
[str] Encoding cleanup

ASCII encoding and filled with binary data. This commit fixes hopefully all of these cases and adds checks for ASCII data in Parrot_str_new_init and STRING_iter_set_and_advance. This commit also adds the "b" flag to FileHandle.open as a shortcut to open a file in binary mode.
rrot: r49749 | nwellnhof++ | branches/string_checks (4 files):
[str] UTF-8 checks
rrot: r49750 | nwellnhof++ | branches/string_checks (11 files):
[str] Rewrite UTF-16 encoding to work without ICU
rrot: r49751 | nwellnhof++ | branches/string_checks (6 files):
[str] Add checks for UCS-2 and UCS-4
rrot: r49752 | nwellnhof++ | branches/string_checks (16 files):
[str] Remove unneeded STRING_validate
rrot: r49753 | nwellnhof++ | branches/string_checks/src/string (2 files):
[str] Throw exception on some binary string ops
kid51 msg nwellnhof Is the string_checks branch tied to any particular Trac ticket? 15:17
aloha OK. I'll deliver the message.
dalek rrot: r49754 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
logically separate dynamic call to Parrot_pcc_fill_params_from_c_args
 15:26
15:27 nwellnhof joined
nwellnhof kid51: no, string_checks isn't tied to a ticket. 15:28
15:28 dngor left, dngor joined
kid51 nwellnhof Do you think you could post a description of what it's about? 15:32
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.
Would this be relevant for either TT #1778 or TT #1808? 15:36
nwellnhof No, it's independent of those tickets. 15:37
dalek rrot: r49755 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
in stead of keeping track of when we don't advance in PCC wrt NCI, keep separate iterators for each
 15:41
rrot: r49756 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
dead variables and simplify memory free
15:43 jan joined
dalek rrot: r49757 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
simplify, eliminate memory leak in pass by reference types
 16:13
rrot: r49758 | plobsing++ | branches/gsoc_nci/src/pmc/nci.pmc:
cosmetic changes to nci argument decode
 16:28
rrot: r49759 | plobsing++ | branches/gsoc_nci/config/gen/libffi/nci-ffi.pmc.in:
copy nci.pmc into config files (will survive reconfig)
16:32 tadzik joined
tadzik hello 16:33
JimmyZ hi 16:35
cotto ~~ 16:36
tadzik oh, cotto. I'd like to help implementing Lorito, heard that you're the one to ask for further guidance 16:38
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:41
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:42
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.)
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?
cotto tadzik, do you have an area of focus or are you doing general CS? 16:46
JimmyZ nothing, just my respects to tadzik :) 16:47
tadzik cotto: well, I like programming :) I came here from a Perl 6 world too
and I'd like to do some Programming, not just Glueing Libraries Together
cotto You'll have plenty of opportunity then. 16:48
tadzik That's what I'm aiming at
and Lorito didn't look so Black-Magical like GC or Threading 16:49
cotto No. It should be as unmagical as possible.
dukeleto, ping 16:54
17:06 JimmyZ left 17:21 AzureSto_ left 17:23 AzureStone joined 17:27 raek left 17:32 patspam left 17:35 cognominal joined 17:48 nwellnhof left 17:56 theory joined 17:57 M_o_C left 18:00 plobsing left 18:02 PacoLinux left 18:05 PacoLinux joined 18:08 chromatic joined 18:19 tadzik left 18:27 contingencyplan joined 18:31 PacoLinux left 18:34 plobsing joined 18:36 tadzik joined 18:54 tadzik left 19:14 kid51 left 19:28 PacoLinux joined 19:39 tadzik joined
dukeleto ~~ 19:42
kid51: pong 19:43
kid51: i don't understand why you are making "check the definedness of __rtems__" so complicated. It is 3 lines of code. 20:05
20:14 mikehh left 20:17 Limbic_Region joined 20:19 mikehh joined 20:21 jsut joined 20:26 jsut_ left
cotto ~~ 20:50
21:02 AzureStone left, AzureStone joined 21:07 perlite_ left 21:09 perlite joined
cotto chromatic, I have to take off but I've added some more questions to trac.parrot.org/parrot/wiki/LoritoD...nQuestions . Your thoughts would be appreciated. 21:15
chromatic Will do. 21:32
21:38 Andy joined
sorear is it just me or has trac.parrot.org gotten slightly less unusable 22:17
bacek_at_work ~~ 22:23
22:31 patspam joined 22:40 fperrad left 22:43 tadzik left
bacek_at_work chromatic, we are doing lookups in LinkedLists only during tracing C stack. 22:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!