World: r3wp

portS

get in get in system 'ports 'serial

hmmn, system/ports/serial: [ttyc0 ttyc1] is not enough to prevent 
the problem

neither does system/ports/serial: [ttys0 ttys1]

Anyone got a way of operating on each element of a series except 
the last ?

Or, doing something different to the last element.

>> s: [1 2 3 4]
== [1 2 3 4]

>> forall s [either tail? next s [print ["Last item is" s/1]] [print 
s/1]]
1
2
3
Last item is 4

eFishAnt, a wild guess: what about rebooting the OS after you've 
made the link to ttyc0? Maybe some internal list of devices is made, 
when the OS boots?

Thanks .. I was using a while block, but yours is shorter.

eFishAnt, you have replaced the block at system/ports/serial. Try 
replacing just the first word in the original block with 'ttyc0. 
 Just a wild guess.

I just tried hex-editing rebol.exe in Rebol/View 1.3.2.3.1 here on 
windows. I found "com1" and changed it to "COM1". Then when I started 
again system/ports/serial == [COM1 com2]

I've discovered that the GC seems to accelerate as it processes more 
and more of the same data... A 10 million allocated, linked and initalised 
liquid node test is proving this once more, so my guess is that Carl 
put some kind of heuristic detection or what have not, which adapts 
the sizes of the values in the allocation and GC, based on recurring 
tasks.

right now every time it creates 100000 new nodes, my loop's speed 
steadily increases by about 0.065 %

and the memory foot print of my application stays the same at ~  
300 MB

I manually call a recycle at the end of each iteration. so 300MB 
is what is needed to have 100000 nodes in memory without any GC.

so many nodes, what for? :-) What is node in liquid terms anyway?

I am stress testing the library.

it must support 100 million allocated and linked nodes for me to 
be happy.

imagine a double edged directed graph node.

it seems to me, you are building compositing engine, aren't you? 
And if so, yours will be redundant to View one ... will not it be 
slow? Or is liquid kind of being complementary addition to View engine?

pekr always seing behind smoke and glass  ;-)

It must use part of the View system in order to show something in 
a window (faces) and to get events.

glass is a compositing engine, which might grow out of view IF R3 
promises are fullfiled.

but glass also allows your "processors" to be linked to the engine 
dynamically...

so using the same interface definition, you can have two totally 
different displays.

2d/3d , color/b&W, etc

Anton, Geomol, thanks...will try those on my next visit.

Good luck.

I was going to ask what is a good hex editor to download into ubunto...but 
then I figured out I should just use a REBOL hex editor...if I need 
to to change I can just change it myself.

BTW, your virtual face demo rocks, Anton.  I contorted the face so 
hard, it nearly cracked my CRT!   ;-)

Thanks. :) I had to contort my forehead for a few days to get that 
to work.

That could cause wrinkles.  Hmmn, I searched the library and don't 
see the hex editors...trying to remember where they came from.  I 
think at least one was pretty decent.

eFish - wasn't it in terms of competition? Try ViewTop then, and 
rebol.com competition section ...

http://www.tgd-consulting.de/Download.html

thanks, Pekr

Am I the only one who thinks that 64bytes for an empty block is a 
lot or ram?

doing stress testing, of liquid and inderctly REBOL, I have measured 
that allocating 1million blocks takes up exactly 64MB of ram and 
each block I add to the context adds exactly 64MB.

each block adds exactly 64 bytes...do you mean?

yes.

seems like an empty block should only take 2 bytes...but then that 
is just the ASCII representation...binaries are bigger than their 
source code...I would expect some list links pointing, some datatype 
info...dunno.  Maybe try a small program like REBOL[] probe empty: 
[] and inspect the RAM of it.

hehe, your the embeded hw expert  ;-)  probing RAM directly.. man 
haven't done that since I've used amiga!

would be a good extension of a hex-editor...to just load a memory 
address and peek around and look at things...have REBOL inspect itself.

.... and hackers hack in :-)

if I understand it correctly, we should get it with debug hooks ... 
powerfull debugger would help ...

I don't have a Lauterbach debugger for x86 ... only for ARM, PPC, 
XSCALE, and some other MCUs...or that WOULD be cool.

I am starting to understand the challenges "big" app developpers 
encounter when trying to solve complex data models.

I think I will have to design a cluster engine for liquid quite rapidly 
for some of my projects.

for very structured data, when space is a premium, and if it is packed 
tight, you could always do it through a dynamic linked library.

yeah, I intend to recode code liquid as a c module eventually, and 
probably use that natively in python and make a dll for it in rebol.

but waiting R3 for that... I'd like to allow liquids to be datatypes.