AltME groups: search

what I normally do is click on the relevant tcp lines, and the right 
click, and then choose "follow tcp stream" so that I only get the 
relevant data.

Ill post log from total commander in a minute and then try to spot 
the difference...

there it is.... difference is:

in total cmd:
on Request: STOR ik104test.zip
ftp > mgemanagement [ACK] Seq=80 Ack=35 Win=16500 Len=0
Response: 150 Accepted data connection

and in rebol
response is

 290 7.903130    194.9.94.127          192.168.2.108         TCP  
     ftp > spiral-admin [ACK] Seq=613 Ack=111 Win=16500 Len=0
30 seconds pause

1279 37.655879   192.168.2.108         194.9.94.127          TCP 
     spiral-admin > ftp [FIN, ACK] Seq=111 Ack=613 Win=15888 Len=0 
   149 4.247163    194.9.94.127          192.168.2.108         TCP

I think we several times suggested to set system/schemes/ftp/passive: 
true, and IIRC Vladimir claimed that it made no change for him ....

I tried again... now it is "ca-idms" instead of "gtrack-ne" and Seq=604 
instead of 603....
I have no fu...ing... idea what this is...
If there is anyone outthere who knows what this could be... ?

One thing is clear - you have to have allowed connection tracking 
in your firewall, and ftp communication is being done by using so 
called "related" connections ...

I got response from Pheenet tech support... It tokk couple of emails 
... me sending network drawing, log files and such stuff...

Finally they said they never expirienced anything like it in their 
practice... Well at least I know Im not idiot... :)
Only latest firmware could help...

They were very kind and sent me newest firmware... (its not even 
available online :)
AND IT WORKS!

So.... Rebol is still cool... It was not rebol mistake... it was 
router firmware... :)
Thanks to everyone who tried to help :)

Yes. We can but it requires a lot of work, and then your second questions 
makes you wonder.

What is it about Rails that makes Ruby a good fit?

We are building Quilt on Rebol, and it seems to be going very well. 
 But we have nothing to compare to.

BTW, such framework is being built, and it is called Quilt. The backend 
engine behind QTask. I can wait to get my hands on it.

Jaime - ok, I correct myself - to what you said by "rebol sending 
me to loopholes" and calling it a productivity issue, from that point 
you are probably more than right ...

by my comment regarding "hype", I really mean something ppl should 
be carefull about - that most ppl I meet, even in corporate environment, 
talk about hypes. And maybe "hype" is not the correct word, maybe 
it is about "trends"? They even don't know what ajax is in particular, 
yet they tell their boss, they will use new tool for their job - 
ajax, and their boss said - hmm, I read something about it - it has 
to be cool and we will support it ;-)

in fact, I am one of two "right hands" (it is a saying in czech language) 
for our CTO. And the reason is, that I provide him with opinions 
not tied to any products of my liking. Our Delhi group, would do 
everything in Delphi, our Lotus Notes group, would do everything 
in Lotus Notes, the same goes for VB and SAP folks, and of course, 
jokingly, I would do everything in Rebol. But - things need some 
level of understanding of current/historical situation in the company.

that said - last time my rebol friend Bobik, who did nice apps in 
Rebol already, needed suggestion regarding the project in the company 
he works for, it was me, who suggested him not to use rebol, but 
go with php, apache, and it was becaue it was much better fit for 
their company in their situation. And if someone will ask about fast 
web development, I have already one friend I suggested him to look 
into Ruby on Rails ....

... and it is imo the same reason and experience, why I suggested 
you to look into Mikrotik routerOS some time ago, and would be probably 
valid, if you would not have coded your own system ....

Graham - actually I thought about "porting" Rails to rebol and calling 
it "rebol on trails" :-) But last time looking at rails api, it is 
already large jog done. OTOH we would only clone API that already 
exists ... dunno ....  because whole web 2.0 mess is here, to be 
finally able to do what REBOL/View can do, just using browser ...

maybe a 'bridge' for REBOL-Ruby.


allowing Ruby to call or access REBOL 'objects' directly and vice 
versa.

Now we know Flash and Ruby try to go outside the browser, so I wonder 
how usefull Rails will be in such a territory. I still think, that 
IOS like "platform" for app delivery, is still unmatched. Dunno what 
Altissimo is supposed to mean, but having rebol services or uniserve/beer 
whatever based framework for app distribution, like it was planned 
with Morpheus or even Altme, would be a win ....

Volker compilation of rebol is due to context free grammars. If you 
take this restriction you could probably have a bootstrap of rebol. 
But you can not compile just any rebol program. So this is a problem.

We are talking about bootstrapping. There is no need to compile every 
program. Its only needed to have a subset to build the interpreter. 
And that one must be able to generate machine-code.

Thats what forth does with meta-compilers and squeak does with slang. 
Ugly, so a pretty good motive to do most in meazzines :)

For inspiration, Wright looked to the 

demo scene," a group of (mostly European) coders who specialized 
in doing a whole lot with a little bit of code. Their procedural 
programming methods were able to, for example, fit an entire 3D game 
in 64K, using mathematics to generate textures and music, etc. "I 
just found this incredibly exciting," Wright confesses, describing 
the kinds of work that he saw come out of the demo scene."


So here's what he did: he recruited an elite strike team of coders 
(who, if you were to believe his slideshow, dressed like ninjas) 
and put them in a 

hidden facility" to experiment with new ways of giving the user powerful 
tools and generating tons of dynamic content without armies of content 
creators. Best of all, he fired up a demo and showed his audience 
the results... "

this is almost a REBOL like way to create games :-)

Volker you are right. But I was thinking on Rebol bootstrapping itself 
and offering incremental compilation too. Just like Dylan or CL. 
Here is an excerpt from wikipedia. "Common Lisp has been designed 
to be implemented by incremental compilers. Standard declarations 
to optimize compilation (such as function inlining) are proposed 
in the language specification. Most Common Lisp implementations compile 
functions to native machine code. Others compile to bytecode, which 
reduces speed but eases binary-code portability. The misconception 
that Lisp is a purely-interpreted language is most likely due to 
the fact that Common Lisp environments provide an interactive prompt 
and that functions are compiled one-by-one, in an incremental way."

Unfortunately this is not easily accomplish with rebol, unless you 
throw away the CFG and with this you loss dialecting flexibility.

I thought about that a bit. IMHO it is not that impossible. But may 
need new core-features.
The idea is that argument-lists rarely change.

Rebol lets us inspect the last values a function used. So from the 
source i cant be sure 'append is really that global 'append. But 
after the function has run, i can look what the last append was, 
and see that it got two arguments. And then i can "insert parens" 
and process it like lisp.

Needs a profile-run, or would work really well with a jit. And the 
interpreter needs to stay in the background for very hart blocks.

Jaime - from my limited understanding - you would like to see rebol 
kind of grammar to be defined and used as a wrapper running upon 
another environment?

Henrik - imo with more media friendly features and rebol overal extensibility 
(as was promissed earlier for rebol), we could see Rebol being a 
tool for some nice demos ....

How about this, a single piece of code to handle any web form.. just 
add a new field to the html and you're all set... don't need to alter 
the DB or the serverside processing.

and TBL, although I think he's lost himself somewhere about 60,000 
feet

Terry, Rails already do that. It is called Migrations, a kind of 
versioned schema, and yes you just add a field and everything works.

Volker, compiling Rebol is not impossible, it is just very difficult 
exponentially difficult because " the order evaluation" for the a 
function call can change at any time. Depending on how the words 
in the body are defined. This is the CFG feature and problem.

Ah. But the point is not that you code in Rebol, the point is that 
if you implement a DIALECT that has different semantics and shares 
the value types! of rebol then you can compile such dialect.

And in lisp arg1 none of the args causes evauluation while in rebol 
the may.

And in rebol we have none when looking at sourcecode.

But actually, when a function runs, its "compilation-units" are always 
the same. Meanswhen a function is run, the lisp-parens can be inserted 
by reflection. (except of strange hacks)

Basically the eval form of lisp is fixed, it is part of syntax, and 
it is (func args ...)

And in rebol it is [func arg arg2 block-of-variable-args]

What if i enforce that, by keeping track and checking somehow? Do 
you have an example wherre that would hurt?

So you will make executing slower, because now the interpreter needs 
to keep track of the whole tree to see which values changed and which 
are a violation of contract.

That is what rewrite rules and rebcode accomplish.

IMHO its main advantage is in creating code and readability. Not 
in kind of self-modifying code.which you do when you turn calls in 
arguments by changing the  arglist-len.

varargs are not the reason for not having a compilable language. 
Both Lisp and C support varargs, and both are compilable languages. 
The culprit is CFG.

From the poing of view of the compiler developer he can't make any 
assumption on how to compila a rebol expression, while in C and Lisp 
he knows that the forms are fixed.

Both enforce parens. its not the varargs which make problems, its 
the number of expressions. The compiler must know where the expression 
starts and ends.

He can not make assumptions from the sourcecode. But he can when 
the function has run and supports some ways of reflections.

And this function has fixed arity.

Jaime, just had a look at 'migrations' and it's not the same at all.. 
 here's the pseudo code just to change the db with rails..

    * Step 1: Create a migration with script/generate migration WhatImChanging
    * Step 2: Modify your generated migration file in db/migrate
    * Step 3: Run rake migrate

    * Step 4: Revel in the fact that your database is converted to the 
    newest schema!


With Framewerks you never alter the DB.. it's a black box where data 
goes in and out.

with Framewerks, you could copy a form from any web page, change 
the 'action' of the submit button.. and it will work perfectly.  
Rails cannot do that.

So rails DOES require the DB schema to be modified AND the server-side 
processing to be modified as well.

And not only does it need to be modified.. the syntax to do so is 
archaic.

Terry you are right, but you don't need to drop the table to alter 
it. The have add_column and remove_column methods within others.

And finally I can't really be fair to framewerks becuase I have not 
play with it or see its code, and how it handles and/or store information.

Volker here is another example,



anyF: does [f g h
]

f: func[x][print "f third" 2 * x]

g: func[y][print "g second" y + 1
]
h: func[][print "h first" 1]


anyF ;; == f(g(h()))

;; 

now lets change 


g: does [print "g second" 5

]

anyF ;; == produces something like f(g()) h()


  anyF is compilable only if the order of evalutation 
doesn't change 
  at runtime. 

Rebol permits for the order of evalution to be determined 
  
by the context in which anyF is run, and the interpreter is 
smart 
  enough to GC the unconsumed values.


   This is a feature of Rebol because with the same expression 
you 
   can have two very different meanings, the disambiguation 
of the 
   grammar is provided by the context (or environment). 
This allow 
   Rebol to support easy Dialecting. That is each 
DSL may need specific 
   evaluation orders, aka semantics, 
while they share the same code 
   expression. In this case [f g h].



In the example above two different branches of the AST three 
were 
followed. But by just looking at [f g h] is impossible
to know which 
branch will be taken. 


  Other compilable languages enforce the order of evaluation by 
using 
  specific syntax forms to determine what is an expression. 
 Lisp 
  uses  parens, while  C semicolons and others markers.

 


So in order to make anyF compilable we need to  enforce the 
order 
of evaluation.  One possibilty  is to use Rebol parens.



anyF: does [(f) (g) (h)] ] *** see note


  The cost is evaluation speed for the interpreter, and now 
we are 
  back at using parens at each step. Which is what 
lisp uses. Should 
  we go back to 1967?


  The alternative of JIT is possible, but  it requires hinting and 
  
a sofisticated runtime environment. The translation of Rebol 
code 
  to some an  internal VM like rebcode  is simpler and maybe 
sufficient, 
  otherwise extending rebol via DLLs  is the way to 
get closer to 
  the metal. However, I don't see an easy path 
to having a Metacircular 
  Rebol. If you do, I hope you write
 a Rebol compiler and share it 
  with us ;-)

*Note:  For the first set of definitions of f, g, h and anyF the 

block [(f) (g) (h)] is not enough to enforce the order of 
evaluation 
(f(g(h))). That is h first, g second, f third, 
with each function 
applying to the result returned by the 
previous one.



anyF: has [r][
   
	 r: h
   
	 r: g r
   
	 f r

]


  Does the trick
.  However the original definition  was shorter and 
  prettier, even though ambiguous.

I always code with parens in mind. I understand that rebol can do 
this f g h - things, but i cant imagine code where i change the length 
of the argument-list and both versions have  usefull meaning. (except 
of shortening the list and relying on the "nop"-effect for the other 
args, but even that is risky.

Does it mean we can use Flash IDE tools to do animations, save them 
as curves and then possibly render it using AGG 2.4 in View? :-)

.... and as View does not allow for media integration (I have heard 
it can change), so no avi, flash, etc. integrated, you can't use 
3rd party technologies with View stand-alone apps ...

Flash can render Flash? Never thought about using it in such an easy 
and direct way :-)

... and for new Rebol (but Cyphre or Carl could confirm), IIRC someone 
said, even compositing engine will be replaced, just dunno if by 
the one in AGG ...

not sure .... dunno how AGG is integrated, maybe AGG compositing 
is not used at all? Difficult to say ... but I expect radical redesign 
of View - at least we can be sure there is new event system placed 
inside, hopefully libevent .... so I expect even some compositing 
system changes and also face concept redesign ....

Volker, parentese fails in this case. The 
body of f didn't change 
as matter of fac t
it runs and produces as result 6. But the
parentese 
func fail to produce an expression 
for it. 



ctx-tuneme2: context [
    
	append: func [arg1] [arg1] 
    
	add: func[][none]
   
	 f: func [] [append 7 append add 5 6]

]



ctx-tuneme2/f ";run it once" 

probe parentese second get in ctx-tuneme2 'f


  ** Script Error: get expected word argument of type: any-word object 
  none

** Where: parentese-once

** Near: arglist: first get first code

So ctx-tuneme and ctx-tuneme2 has the exact same body for F..  However 
they perform different evaluations, one compiles another not. This 
is the problem. Now you can keep tuning parentese, but I bet it is 
always possible to find a way to break it.  The larger the body of 
F, the more posibilities for evaluation exists.

No, that is a problem with an intentionally limited quick POC.
But i had to blink twice. :)

It currently expectes that all expressions start with a word. Now 
tuneme2 is  [(append 7) (append add) 5 6].
And it fails. As it should with this limited subset. 
Found it after adding a probe,
      arglist: first get probe first code 
which gave 5 on last run.

I do think  i can match rebol completely (means a rebol with small 
additions/restrictions).

Its as tricky as to compile, say 'c. There are lots of exceptions, 
but in the end it is possible.

Handling standalone values is one of the first thoughts of course. 
then there are operators and refinements. Then deciding if something 
is rebol-code or not (that needs an extension. 'do must flag it processed 
the block. So that parse-rules etc can be detected as data and the 
parens inside are detected as "run by do". Surely more small things, 
but should be doable.

I like the bontago here. http://www.digipen.edu/main/Award_Winning_Games

To our physics: Is it possible to build a little physics-engine for 
such things, and how about collision-detection? The 3d from the contest 
could be sufficient for a small version of this.

I love the system requirements: 16 MB RAM and a 386.

the system can build itself, including the kernel, common drivers, 
and all servers (112 compilations and 11 links) in less than 6 seconds 
on a 2.2-GHz Athlon processor.
   Yeah! I'm starting to get interested.

hmm, I read some doc when I was looking into liboop and libevent 
etc., somewhere on those sites, but each of groups tasks vs threads 
had some valid points ....

Pekr, the article is not so much about which concurrency model is 
good or bad. The paper contentionis  that the emphasis on developing 
general-purpose languages that support concurrency is misplaced. 
Lee believes that a better approach is to develop what he calls "coordination 
languages", which focus on arranging sequential components written 
in conventional languages into some concurrent configuration (I suppose 
that piping in a Unix shell could be considered a limited coordination 
language). For concurrent programming to become mainstream, we must 
discard threads as a programming model. Nondeterminism should be 
judiciously and carefully introduced where needed, and it should 
be explicit in programs.

so if Carl brings us task! based upon threads, and we don't need 
to care about threads related headaches in rebol level, then even 
threads are ok for us, right?

In C threads you do this buy using Locks and Semaphores.

In Erlang you use msg queues and process-id.

msg-queues would be on pair with rebol imo ... we already have event 
queue, we have blocks and their accessor functions ....

hopefully Carl knows threads headaches (I do remember his long time 
ago post to ml :-) .... and will do it the right way ...

Jaime, you said "In Erlang you use msg queues and process-id. But 
msg-queues have some drawbacks." I was addressing that.

And then things may break, and distribution helps against that. If 
the decisions can be made smart. http://www.sics.se/~joe/tutorials/robust_server/robust_server.html

Gabriel. I agree with that statement. So vanilla threads are a problem, 
and adding concurrency to language need to be done with care. How 
is R3 going to handle tasking?

petr: who says unicode will be in the first alpha? :) i think we 
should have it however incomplete. there are many things that need 
discussion (see the r3 blog), and it's much easier to discuss when 
you can try the new features.

hehe, they want internet to become OS .... and PC OSes to become 
just - commodities - non-important in its own, just a layer for internet 
networked apps :-)

Regarding multitasking and REBOL, how far is it possible to go using 
communication between tasks over the TCP protocol? I've implemented 
multi-user locking this way with a relational database in REBOL, 
and it works quite well. I haven't done stress-test, so I have no 
real measurement, how effective it is, and what the performance is 
compared to other inter-task communication methods. I'm working on 
an OpenGL implementation, where OpenGL commands are sent from a REBOL 
task to an OpenGL server task (written in C), which will execute 
the OpenGL commands, so I'm about to get more experience in this. 
Both tasks will run on the same computer, but can easily be on different 
computers, of course.


Anyone with more experience in task communication using TCP? Where 
is the limit?

hmm, I am not sure I like it ... you open a port and firewall jumps 
in

Geomol - I remember some material re linux and using tcp for IPC 
and someone said it is quite expensive - communication wise (headers, 
ack)

John...cool.  Build an X-Windows like layer between Rebol and OpenGL.

but Reichart tends to have lunch with lots of those top guys, so 
why not. IIRC BeOS got 50mil injection from Intel .... and Intel 
did not want any share or so - they just wanted to support good technology

I'm developing a byte-code style for OpenGL commands, so little communication 
is needed. Only 1 byte for the command (gl, glu and glut commands 
are fewer than 256), and 4 bytes for most parameters. So many commands 
are fewer than 10 bytes of communication. It may not be fast enough 
for games, but I hope, it's fast enough to make tools and fast OpenGL 
prototyping (trying out ideas).

hum Geomol, is it possible to start a new group for this?  I'd like 
to support your endeavor with testing and I think this can become 
a big thread!

Pekr, good hint. But i guess to calls to send a byte are two packets 
too. And then there was some flag too IIRC. Somebody remember?

Maybe Jaime means: If you do everything that way, including the os? 
But, there would be no  such thing as a file, there would be a file-server, 
eg a third task. Which gets request and can sort them out.

what a crap - I stop buying Creative stuff. If some company can't 
innovate, they should shut-up and leave the scene. How can anyone 
with good brain condition patent such a thing as sorting based upon 
ID3 tag content?

But what you wrote is similar too
either 1 = random 2[ write%file "Hello"][write %file "world"]

What a task does depends upon what a task gets. I imagine a task 
in erlang as a little engine, which gets things of various kinds, 
wires them together when it has one of each kind and passes them 
further. And that "further" can not be deterministic with real hardware. 
Think of an out-of-order-cpu, a little delay in a memory-fetch and 
the command is processed by another pipeline. And that is without 
routing around crashed things. I prefer to have a full featured language 
to calculate the new route, not something restricted.

Jaime, I just don't think rebol should manage files. but, you can 
do coordination, just using message ports. and you can write a dialect 
over that.

if a thread has to wait for another, then you're just wasting time 
and creating problems with threads.

Gabriele - so we will ge threads, which will be simplified for rebol 
users/coders, and some kind of messsage queues?

Prepending i understood it and ask for theothers: What isa tuple-space? 
:)

you cannot address the block; you can only get the blocks matching 
a pattern, and publish other blocks.

if you want to log events a and b, and they can happen with watever 
order, you want to log them in whatever order. if they can only happen 
in a given order, there is no parallelism.

Just thinking loud about tuple-space: Could xpath and threads go 
hand in hand?

Anton, Yes I read the last line and I agree with it. The question 
is what should Rebol do to takle the concept of concurrency and do 
it properly, like Erlang, Termite, or Mozart/Oz.

Volker, I was ilustrating that just using the function TASK is not 
enough. You need a way to prune non-determinism. The example I posted 
ilustrate the problem. Your example has the same problem than mine, 
because TASK it doesn't introduce an order of execution. The fact 
that your example is coded sequentially doesn't mean that the computation 
will be carried in that order and produce the same result always. 
Your example only introduces notatation to pass messages between 
tasks.

Gabriele, using threading only computation  with no overlaps is limiting 
concurrency to one problem space. If that is the case then why add 
TASKs to Rebol, when we have already processes.  The only advantage 
will be memory use, and context switching time, but not extra gains.

processes are heavyweight and we don't have fast ipc across rebol 
processes.

imho the only reason for task! is because it is lightweight and because 
communication is very fast.