AltME groups: search

yes, the transformation to string and to block back and forth looks 
a bit messy

RT did something similar when they switched from R1 to R2. They switched 
from a Scheme-like engine to a Forth-like engine and most code was 
able to run without changes.

How many rebols have written language localization routines?

I'm toggling back and forth between external heaps and in-code strings
I've got a RebGUI widget...


lang-text {en "This is the english" fr "C'est francais" it "Don't 
know any italian"}

meaning a translator will have to get dirty in code edits (or send 
to coder) or use

text (lang "SomekindaKey")

where lang is some func that having read some file, selects the string 
key by lang type...
lang-type being buried somewhere in locale*


How often is a REBOL translator a non-programmer?  I find external 
text to be a pain when
coding.  But...it lets non-coders help with translations.


In particular, I only have about 10 or so screens that could be translated. 
 Ashley's

builtin localization nicely handles all the GUI stuff.  I'm leaning 
toward in-code strings.

Yeah, I toggle back and forth, but they'll be static this time.  
:)

Yep agree.  It's a blurred line now-a-days.  While I was watching 
a group of C++ programmers p#$$ away some 30 million dollars my poor 
little Tcl/Tk prototype just made them mad.  "Not engineered if it's 
scripted!!!"  :)  Oh well, the original Forth system is still in 
production and corporate will try to replace it with a engineered 
solution...usually started with CASE tool cloud diagrams.

Forth does it the pick way to avoid using logic

REBOL?  Odd?  :)  It's one of the few languages I've been exposed 
to where the deeper issues seep in over time and by osmosis; and 
can't really be hastened by intense study (at least for me). Study 
and research do help...it's just that REBOL comes with seemingly 
random and totally cool eureka moments.  Skill with the Forth block 
editor and anything Icon are other time and osmosis environments; 
in my experience.  Most computing is almost boring in comparison.

I recommend FUNC over FUNCTION because having "/local" written makes 
it clearer and explicit what the locals are, and is shorter when 
there are no locals. Compare:

When there are no locals, func wins, because less characters to type.
	func []
	function [][]

When there are locals, same number of characters written, but func 
more clearly specifies the locals.
	func [/local]
	function [][]

Additionally, when you are modifying your func spec back and forth 
so that there is a need, or no longer a need, for locals, then func 
wins by less typing needed.

Brian (fork); :)  Check out rebol.org - pager.r for an attempt I 
made at keeping track of source line numbers. Again, some REBOL scripts 
are built without newlines.  Best to keep index? values.  imho.  
It's what I use for the word cross referencer I'm working on  (forth 
style locate and tour)

let me put it another way Steeve, I will not be reading more than 
16 bytes per request (because I don't need any more than that) and 
it isn't a 16  bytes segment that is next to another 16 byte segment 
really I'm moving back and forth all over the file to get 16 byte 
segments each time.

With forth, you could at least tell by the words in the dictionary 
where things had gone sour

Ubuntu 9.04; rebcore (2.7.6) can     devmem: open/read/binary %/dev/mem
rebview hangs.


Do I need to care?   I don't need View for this little informational 
gathering app, but ...


We are planning for an embedded system BIOS tweak so we can label 
an Asset Tag in the SMBIOS;  REBOL won the race getting the information 
decoded for everyone to see; beat Python development by a few minutes 
(in a highly uncompetitive sharing information back and forth development 
"race")

Yes. I think of this aspect as combing the best elements from Forth 
and Lisp/Logo in a natural way. That is, lists (blocks) are the foundation, 
and you build up a vocabulary to do what you want. It also encourages 
us to structure and doc things a little more, compared to Forth; 
but you have the freedom to express things any way you want. It's 
a very different view from Python, where (my opinion), the goal is 
to make all programs look the same, no matter what the problem domain 
is.

Your Forth focus is showing :)

Brian, even if the Rebol's VM  is not a true stack machine. It has 
a data stack, so that, the POP function could be emulated in some 
way.

A forth kernel, is nothing else than that. To simulate a stack machine 
on a processor that is not designed that way initially.
However, your response suggests that the cost would be high.

I've been using list-view with mysql-protocol for a while but the 
method I use to move data back and forth between mysql data and the 
list-view is not very elegant. Are there any examples of how object 
lists..mysql views work with list-view?

Oh, I like the feeling when I can say "Oh, that's how it works." 
And then there's anamonitor. I can't tell you how many times I've 
gone back and forth with that tool. :-)

Good example of short simple goodie that will twist one´s mind if 
one has not used to things like lisp, sheme and forth.. It took me 
a moment to realize what's the point in this one. but I think I got 
it..
 
 a: func [x] [print x] 
 b: func [] [a: 42]
 a b


As found from http://www.rebol.com/docs/changes.htmlat section 3.8

@Christian E. Thanks for the examples! In the first one, it just 
dawned on me that perhaps Rebol is a stack-based language - a bit 
like Forth et al. Didn't you just put "5" on the stack, then the 
"apply func" simply pops the the stack for its parameters?

@Brian So Rebol is not a stack-based language like Forth, or concatenative 
languages, like Joy, Cat etc?

REBOL is more like an interpreted Lisp, with a Forth-like direct 
binding model.

Yeah, generally math is faster than using logic.  And old Forth trick.

You will reinvent FORTH if you continue :)

Also I think the forth dialect examples would also be quite good

Also, where is the forth dialect - not coming up on Google...

forth is a language ...  which also specialises in creating domain 
specific languages

Ah - I see what you mean. Thought that you meant that someone has 
implemented a Forth like dialect in Rebo.

Any of you gurus feels a need for a multi-level-sort-table ?
I  need one and hopefully I'm not alone ! 


I have a lot of data with a lot of same values in some columns, no 
simple sort will do what I need.

For right now a simple hard coded: first by Col1, than by Col2 and 
so forth will do.
A more elegant and flexible [sort-definition] can follow later.
Cheers

No, it basically a harddrive with a rectangular magnetic plate, and 
instead of one head it has millions sitting in an array in another 
plate above the magnetic plate, placed on a very thin lubricant. 
the thing is that the heads can move up to 250 micrometers back and 
forth above the plate using a piezo actuator. Everything is tightly 
packed together with no loose parts.


There isn't much motion and the frequency of the motion is only about 
800 - 1000 Hz. However the head arrangement allows for massive parallelization 
of read and write ops. Currently only 64 heads can be accessed simultaneously, 
but I suspect this number will go way up. If the drive is idle, no 
power is used as nothing is moving. Due to the low frequency of motion, 
there can be a latency of about 0.5 ms, but the read/write speeds 
far exceed that of SSD. I suspect this frequency is used to avoid 
thermal and power problems.


The difference here from SSD is no need for specialized file systems, 
current manufacturing methods can be used and it uses even less power 
than SSD. It can also freely be scaled and adapted to 1.8", 2.5" 
and 3.5" drives, from what I can see. The durability for writeops 
on the same sector would be same or better than a harddrive.

1. "You know that our resources are scarce. There are very few REBOL 
experts and they are all working."


If an expert can't help by delivering C code, which is needed, I 
guess, then it's better, if that expert use his code elsewhere. (See 
e.g. Gabriele's last post in "!REBOL3".)


2. "You know that R3's source model will deliver the much needed 
flexibility in extensions, hosts and open source code."


We still wait to see these things. Do you expect people to wait forever? 
I can understand, many use their REBOL knowledge and try to create 
something similar themselves, because they're tired of waiting. If 
there were alternatives, people didn't have to wait, but could move 
back and forth between languages. That's happening with many other 
languages.


3. "You know that R3 development is moving forward at a steady pace."


And it can continue to do that, even if there were competition. Actually 
competition might speed some things up.


4. "You know there is a clause to put R3 in other people's hands, 
if RT bows under."

No, I didn't know that.


5. "You know that the R3 design proces relies heavily on one single 
reference."


Yes, and that put REBOL developers in what situation? With alternatives 
and competition, how would the situation look? I don't think, it 
needs to be a worse situation than the present one with alternatives.


6. "You know that RT can't work any one bit faster if a different 
developer with similar goals comes in to compete."

No, I didn't know that. Also if the alternative were open source?


7. "You know that dividing REBOL in separate implementations will 
kill one of its main advantages"


So there can be only one? We have R1, R2 and possible R3 in the future. 
R3 seems to be not very backward compatible, when it comes out. What 
if there came an alternative, that was more compatible with R2, than 
what R3 will be? That can't be bad for all our present code written 
in R2.


I'm sorry, if I offended you, I didn't mean to. I like change. And 
I like good design.

ORCA was quite REBOL compatible. There was an intermediate project 
Thune that was much more Forth like and not compatible. Boron has 
prefix syntax again but is less compatible than ORCA

That would have to be determined.  I say it's worth a shot.  It can't 
be any less 

effective than what we have today.  None of us can dicate to RT, 
just hope and
wish and dream, and maybe report (back and forth)  :)

Henrik;  What?  Never mattered?  BooHiss  :)  It's one of the greatest 
things to hit the computing field...like ever.  Popularity be damned. 
 It still matters.  Like the other great discoveries.  Forth, SNOBOL, 
Lisp.  GNU/Linux.

And then we can pick at the stack like forth

I was kidding of course about readability - don't want Rebol to become 
write only like Forth :)

<aside and joking>

Anyone that is getting tired of waiting for R3.  Do what I did; get 
out of the computing field for 5 or 6 years, do some manual labour. 
 And then on return, regret missing out on all the nifty developments 
and racing to play catch up.
</joking aside>

P.S.  I do regret not following REBOL development from the day shortly 
after Graham made his (to me) famous 2nd millennium post to comp.lang.forth 
till some 18 months ago.  I always feel just that little bit left 
out as I learn things that many of my REBOL heroes have grown, to 
what I see as, "been there, done that".  I want to get there and 
do that too!

Pekr, about the other worlds being dead: It seems it's going according 
to Carls plan with killing both worlds in favor of Rebdev, so I kinda 
hope it stays that way. I hate jumping back and forth between chat 
systems.

it's a forth + lisp + haskell sort of language .. it's stack and 
image based

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

Forth is so named because in 1968 "[t]he file holding the interpreter 
was labeled FOURTH, for 4th (next) generation software Ñ but the 
IBM 1130 operating system restricted file names to 5 characters."
:-)

it is said he played an "active" role in vista's development.  and 
its rumored that most of the catastrophy behind vista is directly 
related to the high-level decisions he made back and forth on everything. 
 just like it was in the good old days of windows... where every 
version would go back and forth on features, concepts and naming. 
 


obviously he didn't code anything, but decisions passed through his 
desk, and Bill is part of the old "evil" MS school and still thinks 
that way.  windows 7 was a project start from scratch, with a totally 
different mindset, closer to the user's concerns than trying to dominate 
the industry and competition.  it was out much quicker, much better, 
and addresses just about all of what vista did wrong, as most users 
are saying.  its also FASTER than its predecessor (rather than slower). 
 which is really at the opposite spectrum of vista.

Idea comming from a forth kernel i've done

i would just use the router and the bodyParser middle wares from 
it, so it does the json parsing back n forth and the restful url 
parsing

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

That's ok, but in profressionnal world even if the main project is 
R3, R2 is the main product. And you need to see bug fixes, supports 
and so forth.

You need compatibility with Windows7, new version of Linux and MacOSX.
And what about Windows Phone ?

The extensions docs say that dealing with handles is undocumented 
...  but if it's just an integer, can we just pass that back and 
forth between rebol and the extension?

It's funny, I go back and forth a lot on my own designs in regard 
to object vs block.

Pekr, you need traversal code to move back and forth relatively in 
the tree.

Guys, let's relax. Everyone can comment of course and people going 
through the code and comment help us. And it's OK if there are different 
POVs. As you can see even within the RMA team we discuss things back 
and forth and have different POVs. Which IMO is absolutly essential 
to come up with a good solution.

Could someone tel me where I can find out the REBOL3 VM specification 
, because I am very interesting for that , I am trying designing 
a  Forth CPU with FPGA , I hope it can run REBOL3 well also!

It shouldn't be to hard to use 2.7.8 in our setup and switch back 
and forth between both. We can take a look at it tomorrow.

more like list navigation, where one may move back and forth one 
item at a time, but never past the last item.

Fork: it makes sense as well, because for instance, Brian and I go 
back and forth on revisions related to load, modules, start, etc.

my father would be a happy user probably, since he is using rebol/view 
now to write interfaces for those pic controllers he was programming 
in flash forth. however, im not sure if we can beat the interactivity 
of a forth system on such a resource constrained device...

Q: Does World compile into bytecodes (a la java) or machine languages?

A: Into bytecodes for the virtual machine. Each VM instruction is 
32 bytes (256 bits) including data and register pointers.

Q: Can you do operators with more or less than 2 arguments?

A: Not yet. I've considered post-fix operators (1 argument), and 
it shouldn't be too hard to implement. To motivate me, I would like 
to figure out some really good examples. With more arguments, I can 
only think of the ternary operator ("THE ternary operator"). I'm 
not sure, World needs that.

Q: Is range! a series! type?

A: No, range! is a component datatype. It has two components just 
like pair!.

Q: What platforms are supported?

A: For now Mac OS X (64 bit), Linux (32 bit) and Windows (Win32). 
The code is very portable. It took me a few hours to port to Linux 
from OS X and just a few days to Windows.

Q: What platforms do you plan to support in the future?

A: It would be cool to see World on all thinkable platforms. I personally 
don't have time to support all. World is not a hobby project, and 
I'm open for business opportunities to support other platforms. The 
host depending code is open source. I mainly think 64-bit.


Q: I'm a little sorry to see the R2-style port model instead of the 
R3 style. Are all ports direct at least?

A: Yes, ports are direct (no buffering). The ports and networking 
are some of the most recent implemented. More work is needed in this 
area. I would like to keep it simple and fast, yet flexible so we're 
all happy.


Q: What in the world is going on with the World Programming Language? 
This looks like something that must have been under wraps for a long 
time. What's getting released?

A: I didn't speak up about this, until I was sure, there were no 
show-stoppers. The open alpha of World/Cortex is being released as 
executables for Mac OS X, Linux and Windows (Win32), as are the platform 
dependent sources and initial documentation. World implement 74 natives 
and more than 40 datatypes. The Cortex extension (cortex.w) implement 
100 or so mezzanine functions and some definitions. The REBOL extension 
(or REBOL dialect in rebol.w) implement close to 50 mezzanine functions 
(not all functionality) and some definitions.

Q: Did you do some speed benchmark? (R3 vs R2 vc World) ?
A: Yes:

(All tests under OS X using R2 v. 2.7.7.2.5 and R3 v. 2.100.111.2.5)

- A mandelbrot routine (heavy calculations using complex! arithmetic) 
is 6-7 times faster in World than code doing the same without complex! 
in R2 and 11-12 times faster than R3. If using same code, it's 2.5 
times faster in World than R2 and 4.2 times faster than R3.
- A simple WHILE loop like:
n: 1000000 while [0 < n: n - 1] []

is 1.8 times faster in World than in R2 and 2.8 times faster than 
in R3.

- I tested networking in two ways. One sending one byte back and 
forth between client and server task 100'000 times using PICK to 
get it, and another sending 1k bytes back and forth 10'000 times 
using COPY/PART to get it from the port. Both were around 3 times 
faster in World than in R2. (I didn't test this in R3.)

- I tested calling "clock" and "tanh" routines in the libc library. 
I called those routines 1'000'000 times in a loop and subtracted 
the time of the same loop without calling. Calling "clock" is 2.4 
times faster in World than in R2. Calling "tanh" (with argument 1.0) 
is 5.9 times faster in World than in R2. (I didn't test this in R3.)


(Some functions are mezzanines in World, which are natives in REBOL, 
so they'll in most cases be slower in World.)

When we tried something similar to the LOAD/on-kwatz trick in R3 
(named LOAD/on-error there) it turned out to slow down LOAD so much 
that it made it unusable - something about switching back and forth 
between native and interpreter execution schemes. The alternative 
of having a kwatz! type returned had the effect of changing a load-time 
check for syntax errors in the source code into a runtime check for 
invalid values, but only if you are expecting such things and testing 
for them explicitly. Under normal circumstances a kwatz-accepting 
loader would often result in code that would run slightly wrong but 
not trigger an error to help you figure out why. This is why you 
should make sure that your regular code loader triggers errors by 
default when it encounters unexpected syntax. An option to be more 
forgiving would be helpful when loading dialects that explicitly 
support particular kinds of extended syntax - and thus are expecting 
kwatz! - or for loading user data for analysis.

I fear, that implementing unicode! datatype will mean, all series 
functions will have to deal with it separately, like LENGTH?, NEXT, 
SKIP, etc. Would it be an idea to make a unicode! datatype just to 
pass data back and forth and be able to view it somehow, but without 
support for all the series function?

Janko: Compiled to a byte-code VM, it looks like a similar embedding 
model. The advantages of bytecode VMs are that they can be tuned 
to be faster for low-level operations that can match the VM author's 
needs, though most are optimized for C-like code, simple math and 
loop evaluation. The embedding model makes it so that you can embed 
in a C-language program (lowest-common-denominator) without affecting 
the language itself much, though the actual interface is slow enough 
that efficient code tries to avoid going back and forth across that 
barrier. Disadvantages are that higher-level operations tend to be 
slower than the lower-level operations that have bytecodes associated 
with them.

AFAICT  it's part of the datatype... since a space will go back and 
forth when you go to/from URL! and other types like string

(in R2 at least):
>> to-url "gogo://a.com/space here"
== gogo://a.com/space here
>> to-string gogo://a.com/space here
== "gogo://a.com/space here"