[<<][staapl][>>][..]
Sat Feb 21 12:58:05 CET 2009

require

The problem is that I don't remember how it works..  Let's go over it
again.

A "#lang planet zwizwa/staapl/pic18" will associate the forth reader
and expand the current file to a module form.  Let's add some debug
print to that.

The problem seems to be that files in the pic18/ directory are not in
the load path when we invoke the forth langauge as a module bye
requiring it.

First problem to fix: a "load" that occurs in a required .f module
should resolve relative to the location of that .f module.

I'm confused.. Let's try to get the minimal things to work first:

OK.  I've added another form in parser-tx.ss / require-tx

 (syntax-case code (planet staapl)
    ((_ planet module . code+) (next `(require (planet ,(p #'module))) #'code+))
    ((_ staapl module . code+) (next `(require (planet ,(p #'module) ("zwizwa" "staapl.plt"))) #'code+))
    ((_ module . code+)        (next `(require ,(p #'module))) #'code+)
    ))

This way "require staapl <staapl-file>" will work.

Let's see if this can be propagated all the way..  The idea is to have
some application that loads as a module.  This requires all
"parameters" to be defined.. (This is really getting a bit messy..)

Ok. so there's an example that can be loaded like this:
  mzscheme -p zwizwa/staapl/pic18/mod-example
or:
  (require (planet zwizwa/staapl/pic18/mod-example))

(I used an .ss extension to be able to use shorthand syntax.)

What does this give you?

After also requireing the support code (require (planet
zwizwa/staapl/pic18)) this gives you access to the compiled code:
(all-bin)


So.. This enables us to track down undefined symbols.  However,
compare these two:

tom@zzz:~/staapl/staapl/pic18$ mzc -k test.ss
mzc v4.1.0.3 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
"test.ss":
  making "/data/safe/tom/darcs/brood-5/staapl/pic18/test.ss"
  making "/home/tom/staapl/staapl/forth/module-reader.ss"
  making "/home/tom/staapl/staapl/pic18/lang/reader.ss"
  making "/home/tom/staapl/staapl/pic18/lang.ss"
compile: unbound identifier in module in: macro/device-descriptor

tom@zzz:/tmp$ cat broem.ss
#lang racket/base
broem
tom@zzz:/tmp$ mzc -k broem.ss
mzc v4.1.0.3 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
"broem.ss":
  making "/tmp/broem.ss"
broem.ss:2:0: compile: unbound identifier in module in: broem

 === context ===
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:117:0: compile-zo*
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:201:0: compile-zo
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:235:2: do-check
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:281:4
for-loop

The source location information seems to get lost somewhere..  I have
no clue why..  Too many layers.

The problem seems to be in load-tx.  I guess in file->forth-syntax.
Nope.. All is ok there..

Looks like I found it:  in dispatch-element in rpn-tx.ss, after
mapping the symbol there seems to be no source info.  The mapper for
purrr is defined in coma/macro-tx.ss

This seems to trace back to ns-prefixed in scat/ns-tx.ss which traces
back to prefix in tools/stx.ss

YES! That's it. Fixed by adding 3rd argument to ->syntax:

(define (prefix . names)
  (let ((orig-stx (car (reverse names)))) ;; use original name info
    (->syntax orig-stx   ;; lexical context
              (string->symbol
               (apply string-append
                      (map
                       (lambda (x) (format "~a" (->datum x)))
                     names)))
              orig-stx   ;; source info
              )))


aint this pretty:


-*- mode: compilation; default-directory: "~/staapl/staapl/pic18/" -*-
Compilation started at Sat Feb 21 16:01:34

cd ~/staapl/staapl/pic18 && mzc -k test.ss
mzc v4.1.0.3 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
"test.ss":
  making "/data/safe/tom/darcs/brood-5/staapl/pic18/test.ss"
  making "/home/tom/staapl/staapl/pic18/lang.ss"
usb.f:207:4: compile: unbound identifier in module in: macro/device-descriptor

 === context ===
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:117:0: compile-zo*
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:201:0: compile-zo
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:235:2: do-check
/usr/local/plt-zwizwa/lib/plt/collects/compiler/cm.ss:281:4
for-loop


Compilation exited abnormally with code 1 at Sat Feb 21 16:01:36


Now, is it possible to somehow make the dynamic scripts in app/ behave
as if they were static modules?  This means "load" should know the
path even if it's required..

Now, if you add this it works:

#lang planet zwizwa/staapl/pic18
path /home/tom/staapl/staapl/pic18

The idea is: somwhere in the expansion of the module the path should
be added.

Ok.. simplified it to "path staapl pic18".  Is it possible (or
desirable) to do this automatically?

Next step: do the same in staaplc: instead of loading the file into a
namespace, do a toplevel "require".  Let's leave this for later.
There's some restructuring and simplification necessary to make this
the default application development approach.



[Reply][About]
[<<][staapl][>>][..]