World: r3wp

Unfortunately i do not understand, what you do with your actors.

http://itmmetelko.com/blog/2009/04/12/playing-with-making-an-actor-like-distributed-system-in-rebol/
 ... I am thinking that I won't change it all and make usage more 
ugly becase right now I don't even know If I will ever need to have 
100000 actors running..  so for now I will continue using object 
and try to make it elegant without worying about this

(again , it hot distorted) ... I am thinking that I won't change 
it all and make usage more ugly becase right now I don't even know 
If I will ever need to have 100000 actors running..  so for now I 
will continue using object and try to make it elegant without worying 
about this

hot = got

I need to see more how this is used before I start optimising, I 
thought I can make some optimisation without complicating it all 
up and make it less elegant to use and extend

hi janko,

have you seen the erlang concept of concurrent distributed programming? 
http://erlang.org/doc/getting_started/part_frame.html
perhaps you can find there some additional ideas.
A robust and complete p2p component in rebol would be fantastic.

TomBon ... yes , erlangs actors are the inspiration for this, although 
I don't have plan to mimic them entirelly .. actors/processes there 
are main building blocks of app in erlang, you can have many thousands 
of them , spawn them all the time etc..  here so far my goal is more 
to use them for distributted computing part, communication between 
various processes/computers ( I have servers that need to talk to 
bots etc.. and back)

Do I understand that you want to send actors a message and they should 
act upon the elements of an objects of the sending process?

no no,... upthere I was trying to make actors lighter... each actor 
is a object now , and each carries around code in it's methods so 
it's not as lightweight as it could be.. but this is more of a theoretical 
probem for now.. as I said I am more interested in them for distributted 
programming so I maybe won't be spawning and having 100 000 actors 
around like in erlang for ecample

I will post new version with some updates in few days, it will have 
some similar pattern matching/deconstruction for messages, remote 
actor spawning too, actors could remove themselves, and hopefully 
some solution for addressing actors more elegantly by then

interesting project janko, will follow your updates.

thanks Tom, I hope something ok will come out of it :)

if we would need really lighweight actors they would have to be made 
with blocks so that they would hold just data , .. rebol creates 
1.000.000 blocks with key and empty string in 4 sec and 70MB, but 
it is question if this is really needed, with objects you can very 
nicely as normal objects extend them into new types of actors

for this small overhead you buy objects which are much better and 
flexible.

I am not sure if this can help, but you can get objects with references 
instead of copies, when you modify them after creation.
maybe like this
>> template: make object! [
[     a: 1
[     b: 3
[     c:  "times"
[    ]
>>
>> obj1: make template [
[     a: 2
[     b: 4
[     c: none
[     f: does [print [ a c b "gives" a * b] ]
[    ]
>>
>> obj1/c: template/c
== "times"
>>
>> obj1/f
2 times 4 gives 8

here c is just a reference, not a copy
>>

It is not 'everytime' wise to look for the smallest possible. funcionality 
is the key here in my opinion.

sqlab .. you are a real object magician :) ... not sure either if 
this can help me right now but good to know for this

On 19-Feb-2009 in this group I said that Tiny C Compiler (TCC) had 
problems. Well, I tried again using the latest version from git repository 
and successfully created a shared object library which can be accessed 
by Rebol. So, Vladimir's tunel.r code, which I ported to C, can now 
be compiled using TCC (as well as GCC). This is good because TCC 
is much smaller (and faster) than GCC and can hopefully be integrated 
in nice, small cross-platform packages.

Nice anton, I hope we'll see your work soon...

Is that the answer to rebcode in R3?

I doubt that, unless it is available to all the platforms. Also - 
Anton - how "big" it is in terms of KBs it would add to REBOL executable? 
Is it under 100KB? :-) Because if not, Carl might not consider it 
:-) But who knows, R3 is going to have plug-ins, so it might be as 
kind of  external "rebcode" engine. The first thing I woudl probably 
do is I would consider ASM/JIT, Blit/JIT addition (not sure it is 
cross-plaform either though)

I wonder what would be the option? REBOL would found out there is 
a "rebcode" in it, it would be a C code, and then your app would 
have to compile and link it in order for being able to execute it? 
Could there be a precompiled (or compile at first run) option? Because 
if not, then it would be slow, no?

Well, the TCC binary here is 129ko. I don't think Carl will be adding 
it to the Rebol executable, anyway.

The trick, I think, is to have a simple set of instructions to install 
TCC ready to use with Rebol.

After that, I suppose it could grow into a plugin.

The plugin model should be compatible with a wide variety of licenses, 
so there may be better candidates for this kind of thing. Most of 
the other languages in REBOL's class are working on LLVM, CIL and 
JVM backends, but those are all pretty large. Perhaps libjit now 
that it is LGPL - that would be a plugin-compatible license, I expect.

I got to Cyclone from the tcc website.. does anyone have an oppinion 
on this ? http://cyclone.thelanguage.org/it seems interesting to 
me

There are several "safe C" languages out there. Cyclone looks interesting, 
but hasn't been updated since 2006.

I'm interested to see who gets there first: The languages that try 
to graft safety and high-level features onto C (Cyclone, Vala, ...) 
or the efforts to speed up languages that already have the safety 
and high-level features.

Any chance to see your current work or how you configurate TCC for 
Rebol , Anton ?

BrianH, yes interesting question... ocaml is closing in to c if you 
want FP, Java speed-wise also but has a bigger ram usage and startup 
times I guess. but it's also hard to say "what is the high level" 
that we want. Is it Java like, is it dynamic langs, is it FP

Steeve, try this:

do-thru http://anton.wildit.net.au/rebol/os/nix/draw-tunnel/demo-draw-tunnel.r

(Actually, you need to read this file first, and follow Usage instructions 
to install TCC first. Then you can do-thru as above..)

(I didn't figure out how to bundle TCC standalone yet.. just a few 
experiments, so that's why you need to install TCC to the system.)

Hmm, Anton, i can't figure where is your source of draw-tunnel.c
Can you give a direct link, please ?

If you tried DO-THRU above, then it should be the most recent file 
in your public cache.
But anyway, here is a direct link.
http://anton.wildit.net.au/rebol/os/nix/draw-tunnel/draw-tunnel.c

Anton - what form is TCC in? Few dlls? Executable? You could probably 
create "new REBOL" using SDK - simply bundle it into new exe with 
all stuff you need (IIRC SDK allows loading internal binary stuff). 
Or pack it into one file, give it plugin suffix :-) Then normally 
read and decompress it, then load it :-)

Basically one executable, some linker files, some include files. 
The include files are where the feature creep starts.. How many standard 
C header files do I include?

1. What method would you recomend for printing invoices ?

    I promised my sister, I will make small aplication for invoices till 
    the end of this week :)

    I guess best way would be making HTML or PDF file and then leting 
    systm deal with actual printing ?

    Or making a face looking just like the needed document (like print 
    preview) and then printing that picture ?

2. Is there a way to scale face ? like zoom in and out ?

Use dockimbel's windows printer driver

Where can it be found?

You can find it here : http://softinnov.org/dl/printer.zip

This driver is best suited for direct printing, i.e., when you don't 
need to generate a document. Invoices are document that need to be 
saved and transmitted, so I would recommend generating PDF files 
in such case.

Doc, are you using DRAW to generate the output?

Yes, a subset of Draw dialect

ok

The PDF example in the archive is generated by using a free virtual 
PDF printer like Bullzip's one (http://www.bullzip.com).

Do you think it would be possible to translate a VID layout to your 
dialect? I have a method for that for direct postscript generation 
using Geomol's postscript dialect. This could be useful for a unified 
printing system, as I'm building a printing front end for my own 
apps.

Btw, it's not a Windows only driver, it works equally well on all 
OS using the CUPS printing system (like Linux, OS X, ...)

I see.

As I said, "my dialect" is a Draw subset, so if you can convert View 
faces to Draw dialect, you could print VID windows.