AltME groups: search

Can someone enlighten me: Will we have the Wiki and Carl's R3 docs 
side-by-side? Isn't that a double effort? I don't get it.

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

Thanks for your comments Brian, Steeve and Geomol

Geomol, refinement support sounds like a good idea, but it was left 
out on purpose because /c would work but /c/d would not. It is better 
to get people out of the habit now than it is to have to explain 
why /c/d doesn't work, over and over again.

There is a plan to add this as an option to REPLACE as well, and 
that is a modifier.

Robert, the R3 docs are a manual, while the wiki is community-generated 
articles and such. Not the same thing.

Brian, makes sense with the refinement and ls. :-)

Steeve, one of the problems with multiple value replace is that there 
are basically two ways to do it:

- One value/replacement pair at a time (like your FOREACH loop above).

- In order using either an inner loop of FIND/match calls, or PARSE 
rules and alternation.

Neither of those are very efficient, but the PARSE rules tends to 
be more so, at the expense of building the rules. REWORD uses the 
compiled PARSE rules method. Most of its overhead is working around 
bugs in map! or going away with new REBOL features. If we do an inplace 
replacement, we'll have the same overhead. The only solution is to 
optimize the runtime, or hand-write the PARSE rules.

I've basically decided to bite the bullet and optimize the runtime. 
The feature requests and bug reports that came from implementing 
REWORD will be much more valuable than REWORD itself. That's why 
I wrote it :)

bah, to be here and in Rebdev is good enough for me

Docs/Wiki: I know the difference. How much content is overlapping? 
I see a problem if we maintain two lanes of documentation regarding 
concepts etc.


It's again the fragmentation problem that makes it so hard to get 
R2 details collected and structured.


IMO the Wiki is one of the best things that happend to Rebol. Finally 
most information in one place.

I made it in SVG. I can't remember how I did the R, but I think I 
took an Arial Bold and made some adjustments.

There is also an r256 and r128, if you want to compare sizes.

I don't think so. Carl just said, we plan to go with an old script 
and change colors in that.

I have some questions regarding timestamps on files.  They look like 
they are all GMT and don't take into account what time zone you are 
in.

To my way of thinking, they probably should default to what the system 
is doing.
For example:
Create any file TEST.r in your what-dir
>> GET QUERY %TEST.r

== [%TEST.r 7329 13-Mar-2009/20:26:42.429 file]		<-- notice the timestamp 
is not CST where I created this at 3pm, not 8pm

If you look at the file through Windows Explorer, you will see it 
is dated at the local time, not GMT.

Do I need to subtract 5 hours (DST) or 6 hours, depending upon my 
timezone and if we are on Daylight saving time?
Do we have some refinements or another way to handle that?

WTF .... while sitting in a pub, having my 3rd good Czech beer, I 
plugged my USB pen in, started R3 and run Demo. I looked at what 
it does so many times, but never looked at the source. While VID 
3.4 contains only basic styles, when looking at various panels, I 
always thought - the code for this screen has to be some 5 pages 
long. WTFonce again - 10 - 15 lines of code with such a functionality? 
Awesome .... I think I will become even more REBOL fanatic ;-) ... 
Cheers :-)

... but really, looking at SharePoint portal sources last week, and 
now into VID source, is quite a difference. I think that most of 
the systems out there, especially the big glory web and JS - are 
just - crap.

It seems reasonable, especially since the host code can add SSL if 
it likes anyways. Ask in R3 chat and you can get an official answer.

ssl:// updated and working 100% correctly. My vote too!

----  Cross-posting from DevBase -----

window: view [t: text ""]


window is set to a gob which is useless to me.  t is totally lost 
and I can't modify it.  What to do?!?

Yep, I remember I came across this before, and I didn't like this 
behaviour either.

It makes debugging and learning the system more difficult.

I'm not sure it does. It's not meant to be poked and hacked like 
VID can be. You go through proper channels, because the proper channels 
are actually there now. :-) Also the built in debugging functions 
can provide a lot of information.

not meant to be poked and hacked
 ===> yeah right !   :-)

Anton, the style actors, reactors SET-FACE, GET-FACE, SET-FACET and 
GET-FACET are there to affect the given face in the way it is intended 
to be, encapsulating the functionality in the right places, so no 
hacking is needed. You just create a new style with altered functionality, 
if you need it.

(It's obvious to me, anyway. I haven't done that much except a few 
experiments and reading here and there.)

I have, and the actors provide everything you need and you can be 
as elaborate as you need to be, process any events anywhere you like. 
There are even specific functions to override actors, in case you 
need to make a small addition to a big actor, when creating a derivative 
style. You can also create new actors. This is not much different 
from what VID3 had, except it's easier to program.

No, it doesn't (?)  The gob is usually returned by VIEW and molded 
by the console..

Go to the style code and add the print there.

I want to get to 't because I'm trying to hack together a GUI for 
DevBase because the console client is painful to use and I thought 
this might be a good way to introduce myself to some of the internal 
workings of the new GUI.  I want to redefine "say" in the chat.r 
to update ''t with the text it would normally print.


To have changed what VIEW returns such that I can't actually get 
to the face produced is unbelievably confusing.  There must be a 
good reason for it though, what is it? 


You do realize that if I have no way creating a pointer to a face 
then I can't use get-face, set-face, etc. on it don't you???

I need a solution to a problem and that solution very well may be 
a paradigm shift on my side.  I just need to know how to interact 
with the GUI from outside the GUI code OR I need an explanation of 
why the ability to do has been removed in the latest release of R3's 
GUI.

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

I posted my reaction to rebdev chat too. I am missing some aproach 
to easily traverse gui:


- there is bog/pane, but not face/pane. There is face/faces e.g. 
for panel style. If it is the same concept, why name it differently?
- there is no face/parent-face to traverse backwards

- face/gob contains just one gob. It also seems to me, that it is 
not even a pointer to the gob, but not sure. Not sure if it would 
be usefull, but currently face can't be built from multiple unrelated 
gobs. You have to have one gob, and other ones in gob/pane

Hmm, but as you show, there is some way. But it is strange. Docs 
say, that gob/data point to face. So what is "face" actually here? 
Some special Window face? Ah, I might understand and I pointed out 
already the discrepancy. While for gobs, we use /pane, as we all 
know it from VID2, but the same concept for faces is /faces .... 
While the name is clear, I vote to rename it to /pane, to make it 
apparent it is the same thing ...

Eh...  I got distracted and quit playing with the RebDev client but 
I've been making good progress on the text editor I'm writing. =D

I post here what I posted elsewhere. I refuse to use RebDev - another 
non-web UI for "supporting development".  With nice features, no 
serious back end (imagine real user amounts like, a few thousands 
using this...) and no UI. And to have to move yet AGAIN....

Maarten, a few thousand? Not likely to happen right now and as Carl 
said, he would add features as needed, and there's no need to support 
a few thousand users right now. Right now the next step is a proper 
GUI.

Ammon, it sounds simply to me that some features for setting window 
titles, etc. are either missing or undocumented. I'm pretty sure 
you're not meant to use obscure paths to access features, but to 
use SET-FACE, GET-FACE, SET-FACET and GET-FACET. These features are 
much more powerful in the R3 GUI than the ones in VID.

And if they're missing, it doesn't take long to add them, so instead 
of "getting annoyed as hell", ask nicely on rebdev and Carl will 
probably find some time to add them. :-)

Maarten - I did agree with your POV and told Carl, that RebDev kills 
Altme. But - his reply made sense to me. We should not see it as 
a threat to Altme/web (yet), so let's suppose current RebDev is nothing 
more than CVS with ability to chat to whatever topic or file ...

... and - it was declared from the very beginning, that GUI is much 
needed here, and it will be surely done ...

It's nice that people completely forget the backend, the reason Carl 
built Devbase in the first place, and why he wouldn't look at other 
options. :-)

I was against new system, but I am satisfied with Carl's explanation 
of his POV. He needed streamlined channels for chat, bugs, CVS, filesharing. 
New system, in comparison to AltME, gives us:

- threaded discussions
- ranking
- tagging
- threaded discussions
- message/topic moving
- versioning system
- document management. Docs posted anywhere to any message.
- console version


So far, the big minus is - no GUI client. But - that might be over 
in few months ... So - if we think of RebDev as nothing more than 
RT's supporting infrastructure, I am OK with it. It is just that 
for fast dev related chat, e.g. nowadays GUI related, it can't reach 
Altme comfort and speed in not more than 20%. Threading is very confusing 
now ...

are any of you having troubles with dynamically creating code and 
binding it as objects and stuff like that?  (In R3)

I just wanted to mention that when I run the gui demo and click the 
"text view" test it causes an error on my vista machine.

yes, I've not noticed the problem before. Now that I look at it, 
it seems to be constantly about 2 chars too narrow and a tad too 
short in height.

exact = test with different font sizes and string lengths to see 
if the error is constant.

the error is constant, i tried several font and several para

i don't think so, the margin and origin are too low to explain the 
gap

i tried with a margin of 2x2 and an origin of 2x2, but what is missing 
is 30-50 pixels

hmmmm.... seems you're right. By removing origin and margin, i got 
the correct size.
Arghhhh, it was not a bug actually

Forget the bug Henrik, thanks for your help.

A good evolution would have size-text taking in account origin and 
margin

no problem and yes, that could be a good idea.

Heh, Steeve.  You are working on a rich text editor too, huh? 


Are you using a single face, gob and draw, faces and gobs, just gobs 
or something entirely different?

Theoretically you could build a complement set in R2 and just copy 
the bitset to your R3 script but I think that will cause you some 
problems with unicode, which, as I understand it, is why complement 
has been removed in R3.

geez...
drop and off don't work in rich-text

Drop and Off?  What are you talking about?

and ? 
How do you handle imbricated styles in the same line of text ?
Like:

 gob/text: [ bold "this is bold" italic "this is it talic and bold" 
 off "this is bold" ]

Especially if the line is wrapped

yeah, for what you are doing Drop and Off definitely have to work!

posted question to rebdev, how far are we with March dev plan, in 
order to sync sources with Cyphre once again and let him fix few 
things.

one gob per char, i don't ever try it. It will be slow and memory 
consumming

That's how I did my editor replacement in R2. But then I started 
wondering how to do my own flowing and I decided multiple gobs per 
line is the way to go. Needs some clever way of indexing lines and 
caching gobs so small near-constant number of gobs are produced and 
reused per window of text.

and the length of the block appears to be key here. at 4019 I never 
see a crash but once you go over 4020 REBOL becomes unstable.

but it's much more memory overhead, cause your blocks and temp strings 
are expanded at each add

many many temporary strings are created and fill the memory

I was going to put this on CureCode but when I go to the Add Ticket 
link it tells me to pick a project.  Project?  What Project and how 
do I pick it?

I need to pass command line options in and be able to inspect them 
in system/options/args in user.r.

we've talked about functions like NFOREACH before, regarding multiple 
blocks of different lengths, and it makes me think there is a need 
for handling numbers, where each digit is handled as a separate base.

It's tiresome to build counters and I feel there must be some common 
ground, som built in base counter could cover.

but this would not be normal number handling in that math isn't involved, 
only INC and DEC and some indicator of which digit is currently changing.

right now, I'm rebuilding the MAKE-TICKS function for the R3 GUI 
as I need more flexibility, and it would be greatly simplified and 
easier to understand with something like this.

Consider if we had a COUNTER! datatype. The counter would create 
a series of integers, each holding a separate base. The trick to 
COUNTER! is that it is a structure that holds more information than 
just the numbers, but also states, in the same way that a block holds 
an index or whether a port! is open or closed.

First the bad things:


- It can be complex and there are many things to consider. Many functions 
would be affected.

Now the good:


- This takes all the thinking out of building trivial counters and 
could greatly simplify it.
- It could be used as an any-base converter.
- No new functions to add specifically for it.

It should be possible to:

- Specify as many numbers per counter as we like.

- Each number would be within the limits of positive integers and 
each number would act as an integer! type.

- Extract information about which digit is currently counting or 
which number was last changed.
- Extract base information.
- Perform basic math (add/subtract).
- Perform base conversion for the entire counter.
- Perform base conversion between a counter and an integer.

A counter would hold four pieces of information:

- The base for each number
- The numbers themselves
- The last changed number as a one-based integer index

- The last numbers that were reset at last count as a block of one-based 
integer indexes

The nature of a counter:

- It would be a number!.
- It would not be a series!.

Specifying a counter:

- The above four pieces would be specified in order
- Each piece is separated by an exclamation mark
- Possible to skip pieces by leaving the field empty

- Syntax: !<base definition>!<number>!<last changed number>!<last 
reset numbers>
- Counter base alone: !12.14.16
- Counter base with number: !12.14.16!0.0.0

- Counter base with number and last changed number: !12.14.16!0.0.0!3

- Counter base with number and last changed number and last reset 
indexes: !12.14.16!0.0.0!3![2 1]
- Number without base: !!0.0.0

There's more, but it's a little much to write. :-)

I'm changing my mind on not needing math and it not being a series. 
Sorry, if that seemed confusing.

no, it simply makes a shape block with tick lines for sliders, gradient 
bars and the rgb spectrum viewer. it will be used in more places 
than it currently is in use.

Anton, the --do bug is known, cross-platform (not just Linux), and 
part of a half-dozen bugs that can be fixed by rewriting one function. 
It's the next R3 thing on my todo list, when I get the chance. I'm 
swamped with work at the moment.

Henrik, I advise not spending the energy lobbying for the new datatype. 
Just implement the "counter" algorithm as optimally as you can and 
move on.

Anywhere you want to count with varying base on multiple numbers 
and act on it. I've run into this numerous times.

I haven't gotten that far yet.  I recently had to rewrite my parser 
from the ground up, mostly due to the fact that NOT isn't implemented 
yet and I want to be able to handle unicode without too much trouble. 
 I think I'm going to have to handle a lot events like text selection 
by passing them through the text faces to the main scrollable area 
and let it handle them.  I expect I'll be rewriting the highlighting 
from the ground up.

Instead of having to add a lot of refinements and refinement handling 
to related functions you can just put them together into an object 
and as each of the functions are called they are setting values that 
are local to the collection of functions and each of those values 
modify the behavior as if you were using refinements and passing 
in more values.  It's kind of an inference engine.

Again, what a big word. I do that too to have a more readable, and 
compact code. 

I don't like to pass thousand of parameters. But nothing is related 
to a state machine to my mind

But whatever.  I have what I need and as long as parse is behaving 
as Carl intended then, whatever...

Then, it's not related, the parent is not associated with the ANY 
rule. So that, the ANY rule can failed and the parent will be executed 
each time

I changed my mind, i uses the default caret and highlight behavior, 
much simple.

ill dig out my radial menu thingy and update it for r3 and test it 
for speed.. have a old version at http://rebol.mustard.co.nz/readial.tar.gz

though I suspect it's not working ... I only see shapes and no text

yeah colour testing is fast and maps nicely to functions

im waiting for Carl/Cypher to fix some of the view holes.. and also 
for modules and timers and threads :P

view is currently swiss cheese and the underlying Core has some large 
gaps that really need addressing before GUI sees the light of day.. 
IMHO..

of course.. zooming and SVG night be another method :)

Hmm, isn't jus alpha transparency enough? Why to do any shape detection? 
We just need the ability to define level, which will let events to 
go to underlying faces, just like Amiga DE did it. And if you look 
at Cyphre's irregular window shape, you will see, that it simply 
is not rectangular, or is it?

do http://www.rebol.cz/~cyphre/trans-gui.r

Cyphre can't do nothing yet, as Carl did some changes to the code, 
and Cyphre's version of R3/View is not compatible anymore. Of course, 
rebin isolation should help, and in month or two, we get there - 
modules are bing worked on right now, plug-ins and rebin are next 
one. Then some source-codes get released finally. In the meantime, 
Carl also updates docs - very important ...

by deeper and since the number of font is limited the basic thing 
i need would be to get a something like "get-char-size char font-name 
font-size"

that will get a basic 32-126 charset of requested font, size and 
style and return the metrics for you under R3.

One question towards linux and os-x builds - is it only a Core build, 
or View is included too?

OSX is core only, and I think Linux too.

The best (most-precise) way to deal with this issue, is to calculate 
width char by char, by using the above func, and when you go past 
the width of your box,  you use size-text on the whole line, up to 
that char... but this IS slow.  If doing a multi-line text system, 
you should use font/size anyways for the height.

Guys, there is some missunderstandings since a while.

Size-text is not usable on draw gobs, only on text gobs (that what 
we call rich-text gobs).

A multi-line text system should handle several text gobs (one per 
line).
It's the most simple and fastest system (it's what i do).

So that we don't need to calculate the size or the position of each 
chars in the line. 
And we don't need to manage a text wrapping mechanism.

... well, except for technical nonsense, the person writing style 
was close to Carl's one. And the mention of Wildman suggests, it 
is some community member or lurking Amiga fanboy knowing what the 
Wildman was supposed to be about :-)

The style may be close to Carl's but the spelling and grammar certainly 
aren't up to Carl's standard. He would never normally write so bady 
as "Why not write codec to load source code written in other language 
than Rebol".

Still it could be Carl trying to disguise his writing :-)

Two new alphas today - release early, release often :)

As of alpha 42 we now can load jpg, bmp, png and gif. The beginnings 
of the general codec architecture are there in the form of ENCODE, 
DECODE and ENCODING? functions. Oh, and LOAD has been rewritten again, 
with LOAD/next and multi-LOAD capabilities that go beyond R2.

Virus found skintrim in rebol29904031.zip and rebhost.exe

I had another similiar incident recently with FBSL that AVG had caught 
as well and had to report it in their forum but they fixed it fast.