cotto

function u(){jQuery.getJSON('https://pledge.mayday.us/r/total', function(data) {updateTotal(data.totalCents);}); setTimeout(u,5000) }; u();

cotto

alias cg='valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes'
alias chromium='chromium-browser'
alias chromium_fkill='ps aux|grep flash|grep chromium|sed -e "s/cotto[ ]*//" -e "s/ .*//"|xargs kill'
alias clr='colordiff|less -r'
alias clr='colordiff|less -R'
alias d='dbus-send --session /net/sf/roxterm/Options net.sf.roxterm.Options.SetColourScheme string:$ROXTERM_ID string:Default'
alias ddt='dbfdump --table'
alias firefox_fkill='ps aux|grep flash|grep firefox|sed -e "s/cotto[ ]*//" -e "s/ .*//"|xargs kill'
alias gai="git add -i"
alias gall='git log --patience -p|colordiff -lr|less -R'

cotto

proposed Lorito roadmap

This roadmap proposes that Lorito be planned and implemented over the course of four stages.  The tasks within a 
stage should be more of less independent of each other, making division of labor easier for interested developers.

stage 0: prep
 * get an nqp-rx-based ops compiler ("opsc") generating similar C code to ops2c
 * check in generated C code for ops and PMCs for bootstrapping
 * define Lorito ops and semantics (ffi, arg format, binary format, registers, ops, syscalls, text format, etc)
 * implement some PMCs, ops and library bindings/PMCs in Lorito to demonstrate that Lorito is sufficiently powerful

cotto

New in 2.2.0
- Core changes
- API Changes
- Platforms
  + ICC and Sun cc support have been restored
- Tools
  + Makefiles now invoke the compiler directly rather than going through a Perl script
  + NCI thunks are now generated by PIR code

cotto

#Note: none of the classes are implemented.  This is just to figure out what kind of interface will be reasonable.

my $pir_code :=
'.sub main
  say "what"
.end';

my $prof := ProfTest;PirProfile.new($pir);

#Does the profile have a version string?

cotto

Index: compilers/opsc/src/Ops/Trans.pm
===================================================================
--- compilers/opsc/src/Ops/Trans.pm	(revision 46944)
+++ compilers/opsc/src/Ops/Trans.pm	(working copy)
@@ -44,7 +44,7 @@
 
 our %arg_maps := {};
 
-method access_arg($type, $num) { die('...'); }
+method access_arg($type, $dir, $num) { die('...'); }

cotto

Index: src/pmc/task.pmc
===================================================================
--- src/pmc/task.pmc    (revision 48096)
+++ src/pmc/task.pmc    (working copy)
@@ -110,6 +110,10 @@
 
 An interpreter in which to execute this task.
 
+=item C<data>
+

cotto

cotto@feather:/usr/src/partcl-old\ 0 $ cat proftest 
#!/bin/bash

echo "building..."
/usr/local/parrot-svn/bin/parrot --output=runtime/tcllib.pbc runtime/tcllib.pir
let tclconst_start=`pbc_dump runtime/tcllib.pbc |grep tclconst.pir -B1|grep OFFSET|sed -e 's/.*=> //' -e 's/,.*//'`
let tclconst_end="`pbc_dump runtime/tcllib.pbc |grep tclconst.pir -A4|grep OFFSET|sed -e 's/.*=> //' -e 's/,.*//'`-1"
let tclconst_class_init=`pbc_dump runtime/tcllib.pbc |grep "namespace => 'TclConst'" -B6|grep class_init -B 3|head -n1|sed -e 's/.*start_offs => //' -e 's/,.*//g'`
echo "tclconst range (debug segment): $tclconst_start -> $tclconst_end"
echo "TclConst;class_init starts at $tclconst_class_init"

cotto

This is a rough draft proposal for a timeline to migrate Parrot from our current svn repository over to parrot/parrot github.

Prereqs:
* nobody is strongly opposed to using github
* github plugin is complete and well tested
* workflow and branching/merging docs are updated
* make sure everyone who has committed anything recently has a commit bit on github


approximate timeline:

cotto

lorito braindump
MOP topics:
  What is a MOP?
    - a MOP is a programmatic interface for creating classes.
    - in our case, it's split into REPR (low-level representation) and HOW (other)
    - 
  What is our MOP?
    - It's based on jnthn's 6model work.  Go read up on that now.
    - his timeline is uncertain, but this is worth getting right
      - Rakudo needs it and he's capable.  We'll wait.