Rebol & printers

server

and you

that will

the

and

-- Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f Sponsor: Aderisci a un gruppo d'acquisto: pagherai di meno quello che desideri Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=245&d=20-2

Start from this: http://www.google.com/search?hl=en&q=lpd+windows+printer+daemon Mario

Here's the line of thought I was pursuing in connection with UHURU (which I had to lay on the shelf due to time pressures from a "black hole" project at work; I still hope to be able to resume the effort and put it into decent shape at some point...) SIMPLE "INCLUDE" CAPABILITY You can have a file something like this dinky sample: 8<----------counter.r---------- REBOL [] make object! [ current_counter: 0 reset: func [] [current_counter: 0] with: func [n] [current_counter: current_counter + n] ] 8<----------------------------- and then tell the interpreter (at the console)

at which point you've "instantiated" the object in your own variable:

== 0

== 1

== 2

== 19 Of course, good design dictates that only mutually-relevant methods and attributes be collected together in a single object. Using this as the basis, the idea was to have a layer that could keep up with a collection of directories containing such source files (and could keep them and their documentation up to date etc..., but that is a different conversation). That layer could expose an interface something like my-counter: UHURU/import %counter.r to accomplish this single-object version. The interesting thing is you can also do things like this in a script: foo: func [... /local tally ...] [ tally: UHURU/import %counter.r ;;... ;;... do stuff that uses TALLY within FOO ;;... tally: none ;; destroy the ref to the object ] In this case (assuming that no other references are created to TALLY's value) the memory for that object can now be GCed, thus leaving in memory only the things that are in use elsewhere. The next step, of course, is to extend the interface to manage that create/destroy cycle for you. (The notation below is only for illustration during this thread! One of the most significant design issues IMHO is packaging and naming the interface capabilities appropriately, and I haven't done that work...) With that next level of extension, one could write something like this: foo: func [...] [ UHURU/scope tally %counter.r [ ;;... ;;... do stuff with TALLY ;;... ] ;; at the end of the controlled block, TALLY is ;; cleared, making its former content garbage ] FANCY "IMPORT list FROM file" CAPABILITY Now let's imagine another (equally trivial/hypothetical) file: 8<----------accumulators.r---------- REBOL [] [ "by-sum" make object! [ the_sum: 0 reset: func [] [the_sum: 0] with: func [n] [the_sum: the_sum + n] ] "by-and" make object! [ the_conjunction: true reset: func [] [the_conjunction: true] with: func [p] [the_conjunction: the_conjunction and p] ] "by-product" make object! [ the_product: 1 reset: func [] [the_product: 1] with: func [n] [the_product: the_product * n] ] ] 8<---------------------------------- Without belaboring the details, the idea is to be able to say something like: UHURU/import [adder multiplier] %accumulators.r ["by-sum" "by-product"] and get only the components you wanted. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;