AltME groups: search

Anyone happen to have a copy of  the self modifying program I wrote 
in REBOL years ago?  The one tht displays itself, and then lets you 
modify itself?

No, I did not put it in the lib, although I think Greg may have done 
another version of what I wrote and submitted it.

John too played with it and did something as well.  It is not a big 
deal, I can rewrite it , was just hoping to have the original, I 
might still have it somewhere.

Reichart, I think I wrote one of those. (I think we were talking 
here, and I threw something together so that we could play with it.)

UTF-8 is a strict extention of ASCII, but ASCII is only defined between 
0 and 127. Characters 128+ are not ASCII, they are extensions, and 
their meaning depends on the codepage. The codepage of an 8-bit string 
is unknown, unless you specify it externally (or do a lot of statistical 
calculations). Strings or scripts with characters extended by a codepage 
will have to be translated by a codepage-to-utf-8 function or process 
specific to the particular codepage, ahead of time. Fortunately, 
such a process can be fast and even implemented in a byte-oriented 
language easily.

sounds very odd and interesting :-)

is it simple to reproduce and can it be reproduced reliably? normally 
bugs must be both before he will look at it.

Yes, and I will need some volunteers to do parts of the work. More 
will be posted here soon (vacancies); if you see anything you like 
message me privately.

I can volunteer to sit on the ml and reboltalk.com to monitor those 
lists, answer some questions, and eventually put those significant 
ones here (or to r3-alpha) for the consideration ... I like having 
Henrik around, as he has different pov on the things, so various 
angles could be covered ....

an interesting note from Carl just now: The graphics system as implemented 
in R3 produces a lot of garbage, which means there are still many 
optimizations that can be done. In a way, I'm thrilled to hear that, 
because it means that it will be even faster and less memory intensive 
than it is now, which is pretty darned quick. :-)

I do volunteer to help as well, can proof read documentation, run 
tests, and other miscellaneous tasks.  My only constraint is the 
help has to be in my off hours, can't conflict with my day job. *smile*

we will defnitely need both proof reading and general opinions on 
the documentation. it can always be improved.

I will surely come back on the vacancies. Right after alpha1 is out 
we'll need some people to step up and bootstrap the community

It's pretty simple really, as long as you realize that the closure 
function creates a value of the closure! type. The main difference 
between a closure! and a function! is that a closure! creates a context 
every time it is run and binds the words in its body to that context, 
like USE in REBOL 2. A function! just uses a special context instead 
with stack-local references, which goes away when the function! is 
done - there is no REBOL 2 equivalent to that, but a C function is 
close.

Paul, I'm not sure which of the arguments is supposed to be the alias 
and what is supposed to be aliased. Try
    myfunc: does [object/item]
or
    object/item: does [myfunc]
depending on which direction you meant.

ALIAS is really only meant for internationalization. Assignment is 
for value aliasing, and functions are values.

If it matters to you whether a key is in the map or not (regardless 
of its value), you should probably be using object! instead. With 
object! there is actually a difference between the key being there 
or not, and you can always expand an object with new fields if you 
need to in R3.

Anyone that is not a fan of the Win console.  Try Cygwin and install 
rxvt.   (No need for the X11, rxvt runs beautifully as a windows 
app).  It's not as featured as the REBOL 2 console, but it's a step 
up (and a little sideways) from the dos console.

I was thinking about the difference between a map and a normal object. 
It's easy to slip into a Perl/Python sort of mindset, where maps 
are often the most convenient way to describe data. It can be easy 
to forget the flexibility of Rebol datatypes.

If you don't like the way a datatype works, try another. At least 
we're not going the Perl route and adding operators. :)

rxvt quick tests;  stdio is not reliable (with the defaults - these 
are quick tests)  

$ ./rebhost.exe -q   >> call "ls"    works    >> call "less readme.html" 
  does not detect console.
$./rebhost.exe < small.r  does not work

so in short, not a good choice for redirection, but seems ok for 
the testing I've been doing.  Haven't tried running gnu readline 
with it yet to see if command line recall will work.  I've gotten 
too used to editing source and do'ing.

$ rlwrap rebhost.exe   gives nice command line recall within R3 under 
the rxvt console.  (Win98 currently.   It worked under Cygwin Vista 
too, but I've been away from my dual-boot Linux machines for a few 
months now and hadn't tried readline under '98).  Vista had an issue 
with the TERM needing to be set to cons25, but this box works ok 
with the default TERM=xterm setting and TERM=rxvt.   But as before, 
nothing beats   $ vi   and  >> do  :)

well, just downloaded PowerShell and it boots 3 - 5 secs on my Core2 
Duo, 2 GB RAM :-) It can't run executables or I don't know how - 
it seems that it extends commands for Windows admins, dunno how to 
launch externall app from that :-)

Petr;  It was the MS "Genuine Vista" info grab for the free download 
that led me to Cygwin.  :)  I dutifully registered both my copies 
of Vista, and what?  MS doesn't remember?  <swearword> 'em.  I never 
tried PowerShell.  Once I discovered rxvt I quit searching.  Kinda 
like REBOL.  My progamming language quest is over.  Now the (language) 
interest is only cursory and even though I try and check out something 
new just about everyday ... nothing competes.  Go REBOL Go!

Googling, I just found out, that Cygwin allows also some other consoles. 
Poderosa allows tabs, that might be interesting running multiple 
sessions and switching between them ...

BrianH - you should notice Carl privately about the need to accept 
latest submissions. Well, once done, do you think we are mostly ready 
for full R3 upload? I mean - all View and host C code?

Yeah. The security model doesn't scale right now. I have designed 
a new security model and am almost done implementing it.

All;  I'm the volunteer for the new VID 3 documentation.  (And don't 
really feel that worthy, but that can't be an excuse to make it complete, 
concise and a nice read ... anyway ...)  It's only just in initial 
draft still (my bad), but it's all to save Gabriele and the rest 
of the core team time so they can get to the important bits.  


If you have anything that needs clarification, discoveries, how-to, 
complaints, well anything; please drop a note to this group, the 
btiffin user chat or please feel free to update the discussions page 
from http://rebol.net/wiki/VID_User_Guideand we'll try and keep 
some of the flotsam and jetsom noise out of Carl, Gabriele, Richard 
and Henrik's way while they finalize the REBOL 3 VID.   (And being 
a wiki, feel free to update the actual doc for that matter; keeping 
in mind that consistent style and tone is also one of the goals.).

Thanks and cheers.

Brian, that is a huge bunch of work you have got in there already! 
 Will try and give a hand with the obvious things at least though 
I am less worthy than you by a good bit.

btiffin, I was playing a bit with VID3 today and had trouble with 
Options. I think it would be good to have a listing of the Options 
available for each Style. 

In particular, I was trying to control the lenght of a field, alas 
without success.

Jean: mainly because things are not complete yet. in the end, options 
will be more consistant across styles (and they will look a bit more 
like CSS when it comes to look options).

in any case, the size of a field can be set by providing a second 
string. ideally, that would be the "mask" string (that tells what 
chars are allowed and so on), but it's currently only used as an 
example to determine the size.

and yes, I meant REBOL/View :-) Core runs fine.

It seems to work on macs that were upgraded from Tiger without doing 
a clean install or an archive and install. Some library is being 
carried over from the Tiger install, I think.

Ah, I remember the issue now.  That is a pain, it does work fine 
for me in Leopard.  If you need more help tracking down what is different 
let me know, don't mind poking around for you.  I have both intel 
and ppc macs that are still on tiger that might help as well.

well, I've tried digging out the version numbers for libraries used 
on both Leopard machines that work and Leopard machines that don't 
work and the version numbers are the same.

I've been reading the R3 docs and I can't wait to start working on 
an IDE again.  Unfortunately I don't have enough time to really chase 
that again...  Yet!

I'm making one that resembles XCode, but it seems to me that when 
I need to arrange files and build files, it's simpler for me to just 
build a small dialect and handle it all inside a text editor

Hi ! what's about R3 and CGI ? Can we use the current alpha in CGI 
mode ?

I'm not 100% sure about CGI in general but there is no -c cli option.for 
2.99.4.  afaik the only options advertised as ready for prime-time 
are -q and one that controls quit/halt behaviour.  Expect someone 
more in the know to correct what I just said.  I'm not 100%.  (Or 
after a perusal, I may correct myself in a few minutes).

If anyone is interested, there is a task that needs to be done:


We want to list all functions in R3 vs. all functions in R2, so you 
can have a direct reference to compare each function between the 
two. This will help in listing those subtle changes that R3 has in 
functions and there will be many more subtle changes when unicode 
releases are done. This is only meant to be on a per-function basis 
and not for higher level ways to do things

I suggested thereby that we output the internal help of all functions 
in R2 and R3 in a two-column table with R2 to the left and R3 to 
the right. Similarly for all mezzanines, we would output the source 
code to each function in a separate two-column table of the same 
format.
When that is done, it needs to be formatted for DocBase.


If anyone is interested in doing that, just signal it in this group.

BTW: This should be a standard script that we can run again and again, 
so we can refresh the tables when a new release comes out.

I think the plan is to release a new alpha once the unicode changes 
are done so you can get to test it. We already have a Unicode version 
internally, but it contains only a few of the required changes. Carl 
reviewed the CHECKSUM and ENCLOAK functions yesterday and mentioned 
how CHECKSUM is now binary only. It won't work on strings directly 
anymore, because encoding issues would make it work incorrectly.

Geomol, thanks. It looks cool, but the performance and the architecture 
are not good. I am rewriting it.

Jerry, nice view into your programming history and how you turned 
to Rebol.

Jerry; "why just us"  imho one of the bigger reasons is that we, 
the faithful, communicate in the dark.   There is a buzz, but no 
one hears it.  There is no comp.lang.rebol for people to "bump into" 
for instance.   reboltalk.com gets a few (or less) posts a day, but 
imagine how it would look if the Altme trafic counted.


Sunanda has helped with aga (and RT before) with the web exports, 
but the rebol.org data is "old news" and doesn't allow a surfer a 
chance to take part.


We get excited (a good thing) when we see a REBOL mention on a site. 
 I'd like it if say schemers got excited to hear rebols discuss Arc 
(that would be a better thing).


So the power the Altme (a wonderful comm system) has us in a position 
of "Hoist by his own Petard"

In the next snippet out is a block! and I want it's contents to be 
displayed as the rows of the text-list:

I tried it with and without brackets around out

header
 and "out" as in all my former tries ;-)

Same for btiffin and Gregg; it outputs out as a literal string in 
the output row

You can copy it from here and use "do read clipboard://" to run it.

Are some parts of R3 already considered "final" (minus bugs, the 
need to reconsider, ...) just like "for the moment we believe there 
won't be any major changes"? 
And if yes, are these documented somewhere?

I am not sure. Some kernel parts for sure. Just recently we await 
release of Unicodised R3, which internally changed many things. Then 
Unicode will be kind of final :-) Modules and plug-ins should follow.

I was specifically thinking about network part, and wether it would 
be worth digging in deeper.

I would guess that until unicode & modules & tasks are given some 
soak time, many many things are up for change.  Nothing in the area 
of mezzanines would be stamped final yet (imho) as Mr. Hawley hasn't 
optimized away  each and every (while few) stray bit yet  :)  (plus 
DevBase has yet to roll large).   Umm, in details ... I'm pretty 
sure Carl has nailed down most (or all) of the conceptual layers 
and the interfaces won't change as much as internals might.

While we're at it ... I just tried 

>> echo %http-scheme.r 
>> probe System/schemes/http

and got a "Rebol system Error #1405: I/O error"
 Program aborted abnormally ....

... I forgot ... this is on linux through wine, so maybe it's not 
really rebols fault. I'm not sure about the current when and wheres 
of error reporting for us "outsiders" ;-)

it's not planned right now, unless someone steps in and does it, 
but it requires VID3 to be about done, before that can happen. The 
focus is currently on a scalable DRAW based user interface.

As for REBOL3 on .net ported on the DLR I think of having available 
all the libraries, classes, and object of the framework and from 
other languages.

This will bring much attention to REBOL, a wider odience, a vast 
amount of material avaiable, the opportunity to write bigger applications. 
It is a whole new word that opens. Also, REBOLERs using of the Microsoft 
platform will migrate to the "pure" REBOL when needed.
I  consider this step a winning move from every side of the view.

Things such as JRuby and IronPython are independent implementations, 
so you are free to reimplement REBOL in Java and .Net...

Brian, lets hope that REBOL Tech will have a project to port it on 
.NET using DLR. It would open to us a lot of doors. The whole microsoft 
.NET world is full of object and libraries which would be fantastic 
for us.

And, as written, even the pure REBOL would gain a consistent crowd 
of programmers enlarging by a magnitude its user base.

Somehow, I don't think porting to .NET and the DLR will be high on 
RT's priority list.

If you are talking about Windows, you have to assume that C/C++ libs 
are unstable too, and that you can't do anything without COM.

for me it is enough if "nearly all" C libs have been
more stable and faster than COM container I have ever
used. if you are happy with COM, use it! I prefer C/C++
lib's if possible. at least even TASM is unstable and slow 
if your design is poor but this is splitting hairs...

It depends on what RT's goal is, who has the time and skills to do 
things, and what's most important. I would like to  see time spent 
on an official systems for packaging, building, IPC, an IDE and other 
tools, a solid OSX build, etc., rather than a .NET/DLR port.

If RT's goal is to lure Windows programmers, particularly corporate 
ones, they need to support COM, .NET, and big DB connections (with 
good examples).

Reichart, having used and studied .NET extensively, I can concur 
that it sucks. It just sucks less than its competition.

REBOL is not its competition btw - Java and COM are.

And move away from the 1980's C API. :-)

Yep, some of their own dll's mixed old C with newer c++ and 16/32 
bit code which had to be thunked to work

One way to see it is to ask yourself, what you value most: earning 
money or doing something right. Sometimes it's possible to do it 
right AND earn a lot at the same time. Many years ago, I found out, 
that I enjoy most doing things right, so that's my priority one.

Try owning nothing and living through a Chicago winter :)

Geomol, remember the L'easy campaign a few years ago about owning 
nothing and renting everything?

I like that philosophy sort of, but it sucks for products I like 
and want to keep forever.

I suppose we're assuming material ownership here. I've converted 
my material goods into goodwill in the past years and feel pretty 
good now that it can't be taken away from me :-)

now things are moving. yesterday: select new skin after closing and 
opening window. today: switch between multiple skins on the fly in 
the same window. tomorrow: .... multiple skins simultaneously in 
the same window. :-)

the next R3 release will be unicode based. It will not be very compatible 
with R2 programs. A few scripts and one-liners will run.

REBOL 3 Datatypes and Typesets http://rebollovesjerry.blogspot.com/2008/03/blog-post_15.html

And I am actually reading Carl's blog to improve my English. It is 
a side effect for sure.

I wrote a lengthy post, hoping to start a constructive discussion 
on how we could increase Rebol's popularity and enbiggen (I know 
it's not a real word, but I didn't want to use "increase" twice in 
one sentense :P) it's userbase. I hope this is something more people 
are thinking about now that Rebol 3 is imminent. Please have a look 
at http://www.reboltalk.com/forum/index.php/topic,1513.0.html


(I'm not trying to draw people away from Altme, but I think there's 
a need for a good Rebol forum too! :))

from !Altme

Anyone that wants to take part in the testing that is required for 
REBOL3, drop a note here and we can synchronize what words are in 
need of a test case file.  Don't worry, there are many.   All we 
need to avoid is redundancy (well not really as more tests are infinitely 
 better than no tests.)   If you are keen to start, of the word dictionary; 
I'm in the A's.  :)  So if you start at D or E of F we probably won't 
collide.

Carl's preferred method are small focused tests.   and: [
    [equal? 1 and 1 1]

    [error? try [1.0 and 1.0]]   ; and is not expected to handle decimal!
]

etc... for the gament of 56 types by 68 actions that REBOL needs 
to handle for us.  The test case files usually focus on few actions 
with lots of various types. 


Note;  A lot of the tests can be based on R2.  The basic operators 
need to function at or beyond R2, so an R2 test that fails R3 is 
important.


I'll find out if the basic-test-engine.r script these case files 
are based on is for public consumption for those that want ot help 
out.  It really is a fair grunt of typing and thinking about edge 
cases (after all the baby step core cases)

Note; with the recent blog post; this basic-test-engine.r  may wel 
become part of the build-basic-test-engine-scripts.r reflective test 
generator.  As Carl points out; these are not better than human written. 
 They may cover more bases but still require a lot of attention to 
detail.   My interest in all this is mainly to keep Carl and RT away 
from the potato peeling work, freeing them for building new things. 
 :)

graham, that is in rich text then. i want access to metrix, text 
bounding box, and so on. hopefully we'll get that eventually.

and use it to read a value in a series somefunc 1

This was in response to a question from Jerry: And what is "the new 
behavior of function!" that you mentioned?
Cross-posted by request.

Jerry, R2 just had one kind of context (2 if you include the autoexpand 
context used by system/words). Functions, objects and USE all used 
this type of context, and words were bound to this kind of context. 
A function! in R2 is bound to one of these contexts, which gets reused 
when the function is called. When the function is called recursively, 
the value block of the context is pushed on a stack but the context 
is reused - this is the main reason R2 could never be thread-safe. 
The only difference that object! contexts have over function! or 
USE contexts is that the word 'self is added to them.


In R3, there is at least one more context type: stack-relative, which 
is used by the function! type. All of the words bound to a function! 
resolve their bindings relative to the context in the executing stack 
frame, rather than directly. When a function! starts it allocates 
a context on the stack; when it ends it deallocates the context. 
This means that the context of words bound to a function only exists 
when the function is running, so there is no point to referring to 
these words outside of the function. Although this slows down word 
references, it speeds up function! calls and reduces potential memory 
leaks due to word references in functions after they have returned. 
This slowdown in word references is the reason that R2-style rebcode 
doesn't make sense to add to R3 without some changes to its semantic 
model to make up for the difference.


A closure! in R3 is like a USE call in R2 (USE in R3 is implemented 
using closure!). The words are direct-bound to a context (so word 
references are faster), but it creates a new context and bind/copy's 
the code block at the beginning of each closure! call. There is still 
no point to bind a word to a closure's context when the closure isn't 
running, since the next time the closure runs it will create a new 
context, but it does make sense to use a context created by a closure 
call after the closure has returned since it is a regular context 
like a R2 USE context. In general, it is better to use function! 
unless you need to refer to the context after the closure! returns 
- mostly useful for generators, currying and other functional programming 
tricks.


In R3, object! contexts are like the R2 system/words context: they 
can expand, but not shrink; closure! and function! contexts can't 
expand though. There will be further changes to the way object! contexts 
work, and module! contexts will behave the same way.

I expanded the above article, making it easier to understand and 
with more information.
http://rebol.net/wiki/R2_vs._R3_Contexts

BrianH, thanks for that context information, very good to keep in 
mind in both R2 and R3.

I'm struggling a bit with the closure! specifics.  I have used closures 
in Ruby (though I'm not clear on the difference between a block using 
yield and a closure at this point) and part of what I thought made 
valuable was the connection to the context they were formed with 
that persists.  I'm probably getting this all wrong but what does 
"next time tthe closure runs it will create a new context" imply 
on that front?

If Ruby is as much like Smalltalk as I remember, a block is like 
an anonymous function, and functions in Ruby are more like closures 
in REBOL. There is nothing like yield in REBOL yet, though I don't 
know whether Ruby's yield is a cooperative multitasking thing or 
an Icon-style resumable return for generators.

I think Ruby's yield is both for cooperative multi-tasking and generators

I don't know Icon either and I'm not sure about the cooperative multi-tasking 
part for Ruby, only seen the generators use so far.

A tiny bit of status report:


- Working on ports now. It's a very straight forward system, if you've 
been reading the docs.

- Carl found a bug in the garbage collector that would speed up a 
loop test case from 35.2 seconds to 6.4 seconds.

- After a while of core unicode testing, graphics is finally going 
back in. The third test version of View with unicode is going to 
be released soon.
- Still no unicode support inside View graphics, though.
- 445 bug reports so far.

- HTTP protocol recently done (IMHO a very nice and super-clean implementation 
of http1.1 by Gabriele).

- Test case system temporarily put on hold. Ports are more interesting. 
:-)

- WAIT now switches between efficiency and accuracy. It's accurate 
but CPU intensive when selecting a WAIT lower than 1 ms, because 
in those cases it uses it's own routine for waiting, but it can be 
done much more accurately than the OS timer. When above 1 second, 
it uses the OS timer.

It would be really nice if Rebol 3 included some grid computing functionality 
out of the box. Something as simple to set up and get going as GridGain 
- http://www.gridgain.com.Or is it already very easy to achieve 
a master-worker kind of solution?

Henrik: Do the 56 datatypes include audio! and video! yet?

map! will be used for fast unique lists. And it's too soon for multimedia 
datatypes... I think audio/video will not be datatype at all, rather 
a scheme I guess.

Is there any way we can have a hybrid R2 with the new graphics system 
and the old core?

After all one starts with core and then builds view on top of it

it's more for networking ( async ) and LNS