AltME groups: search

Can we change the font size etc in a table ?

You would compile a low-level REBOL dialect into functions that could 
be called from REBOL. In R3 this could even be a user-defined function 
type. However, the syntax for this dialect could resemble a subset 
of the REBOL DO dialect if you are careful.

BrainH: it scares me a bit - dialecting was supposed to be one of 
REBOL's holy grails. Where have we improved performance of REBOL 
specifically? Or in other words - were dialects here because they 
gained us some speed? I think not. 


As for DELECT, I think that with advent of parse improvements, it 
will not be used much, if used at all. What do you think?

The security model is a work in process - if you don't understand 
it fully yet, that just means you get it :)

Geomol, the difference I'm pointing out is the following: suppose 
you have an array of unicode code points. each element in the array 
is an integer that represents a character. you can "encode" it to 
UTF-8. there is no magic, for each integer you have a corresponding 
sequence of bytes.

Now, if your array was representing a url, you could encode it to 
UTF-8 using the % encoding as well to stay in the ascii subset. This 
is encoding, but still, it will not solve your @ problem. each @ 
in the array of integers will become an @ (which is an ascii char) 
in the final string.

You can do it automatically only if you keep your fields separate, 
like in an object. so if you have [user: "[user-:-domain]" host: "somehost" 
...] you can have a function that automatically turns that into the 
correct url string.

Maybe we got unicode encoding end escape encoding confused.


As I see it, given correct rules, auto converting of user input to 
correct url can be achieved. I made this function to illustrate, 
what I mean (it's not optimized, but should be easy to read):

encode-url: func [input /local url components host] [
	components: parse input "@"
	host: back tail components

	url: clear ""
	append url components/1
	components: next components

	forall components [
		either components = host [
			append url "@"
			append url components/1
		][
			append url "%40"
			append url components/1
		]
	]
	url
]


I can use it both with and without specifying %40 for the first @ 
in the url:

>> encode-url "ftp://[name-:-home-:-net]:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"
>> encode-url "ftp://name%40home.net:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"


It will give correct result in both cases (I use strings, but of 
course it should be url! datatype in REBOL). Now comes unicode. Given 
precise rules, how that should happen, I see no problem with encoding 
this in e.g. UTF-8.


So I think, it's possible to do this correctly. But maybe it's better 
to keep it simple and not do such auto convertions. In any case, 
the behaviour needs to be well documented, so users can figure out, 
how to create a valid url. I had same problem as Pekr years ago, 
and I missed documentation of that.

I think it is good to have a flexible encoding method, but it should 
not be invoked automatically.

On the new R3 GUI document: I think the new guides and layers concept 
will work much better, but of course it depends on the implementation. 
I've asked a range of questions in Chat to get some more information.

No. AT would be overridden as soon as RETURN was used, so AT was 
only useful per face. Guides are generally a great idea if used correctly.

They can be set manually, which solves a problem that was present 
since the old VID3, namely to have proper reference positions in 
the layout, usable by multiple panels. Even if it's not possible 
to share guides between panels, we can get good use of this.

Generally they provide much more control over the layout. Whether 
guides are implemented correctly is a different issue.

functor: func [

   "Defines a user function with all set-words collected into a persistent 
   object (self)."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    init [block!] "Initialization block of the persistent object"
    body [block!] "The body block of the function"
][

    make function! reduce [copy/deep spec bind/set/copy body make object! 
    init]
]


We decided to not use the term "static locals" since it would be 
confusing to people not familiar with C languages.

Dynamic. Local variable capture is half the point of the function, 
so making the set-words in the body persistent too is a must.

So a functor, with no variables initialized would basically not be 
a functor. You could evolve a functor with many static variables 
gradually towards a normal function with no static variables.

Ladislav, the reason we are asking about how people use %user.r is 
so that we make sure that alternate facilities exist to do what people 
did with %user.r, but safely. The old behavior of %user.r will be 
going away in R3 for security reasons. However, we have your uses 
covered by our plans:
- Preferences will be handled by the new %user.r
-You can include your must-use functions in a module.

making the set-words in the body persistent is a must

 - let me disagree with this. I think, that the INIT block is a must, 
 since the function cannot initialize the static variables as noted 
 above. OTOH, every variable not initialized during the function creation 
 time should be automatically dynamic, since it does not make much 
 sense to have it uninitialized when using it as static

FUNCT sounds perfectly logical and usable as is, but I really cannot 
imagine the usage of a persistent value that cannot be initialized 
at function creation time

Actually, we are going to make a DEFAULT function, but that is one-value-at-a-time 
until DO/next works.

FUNCT and FUNCTOR are for defining handlers, though FUNCT is also 
used a lot in mezzanine code. The user would only specify the body 
block.

when I used a static local variable, I always initialized it at the 
function creation time using my Lfunc. I am sure I wouldn't touch 
a function with static locals not having proper initialization.

We can initialize them to NONE if you like, but having them be unset 
was deemed more valuable from a debugging standpoint.

So far FUNCTOR hasn't really been used, so now is the time to change 
it if we are going to do so. The variable capture is a must though, 
since it will be used where the spec can't be specified by the user.

BBL, have a meeting :)

So how would a user, when specifying a handler, which becomes the 
functor body, specify that a given variable is to be static, and 
that another variable is to be dynamic?

If FUNCTOR scans the given body block and treats all variables the 
same, then that control is lost by the user. Are we happy to lose 
that control?

Maybe FUNCTOR should have the initialization block like Ladislav 
suggests, and a more specific "handler-func" function be created 
for the specific handler use Brian is talking about?

if you are asking me, then the static variables may be captured from 
the INIT block, all other from the body, but it looks, that BrianH 
intended to have all variables static in a Functor, except for the 
variables from the SPEC block

(.... maybe not such a good idea..)

One thing to remember is that these function-building functions will 
be called a lot, so fast-and-simple is better than complex.

FUNCT works well, but is too slow and has too much overhead. We already 
had to make one error go away to remove the screen for spec words 
overhead (see bug#717), but it still has the overhead of a temporary 
object which we haven't removed yet (see bug#544).


If you had FUNCTOR work the way you say, you would have to somehow 
distinguish words in the persistant object (as specified with init) 
from words that should be made into locals, which would add back 
the same overhead that the change referred to in bug#717 got rid 
of, as REBOL code. This would make FUNCTOR have much less performance 
than the equivalent code: CONTEXT [var1: 'blah ... SET 'func1 FUNC 
[...] [...]]

In general we are trying to deal with the problem in R2 where many 
functions were optimized away in high-performance code, so they end 
up being a waste of space. Many former mezzanines are now native, 
and many others are changed to make their overall usage more efficient. 
It's a balance.

Currently,  i have a crash  when i start the chat with r3-a48 under 
Vista.
Obviously, i can't see what is the bug, 

And when i try with the previous version i got  (a42)
i got this error: 
--- Note: checking for new messages

*** RebDev Error: server connection failed, is server down? (server-failed)
** Script error: cause-error-here has no value

** Where: error if unless request-serve if check-msgs check-new make 
context do
catch applier do try chat
** Near: error result


We have no way to return in a safe situation and can't guess what 
is the bug indeed.


Is Carl aware of that problem, i didn't see anything related to a 
crash of a48 when starting the chat ?

i have a very bad connection currently, could it be related to some 
network errors bad managed by the http scheme ?

but a crash, geez....

The HTTP scheme needs a lot of work at the moment - it's a work in 
process. What is there already works great, but it's incomplete.

yep but there is more than just a missing part in the error handling, 
it's crashing rebol, it's bad...

hey guys, have we a clever way to extract same variables with different 
values in 2 different objects ?
In one word: the difference.
I mean, without doing a nasty loop

Please, don't say to me, the only hope is to do a foreach loop.

you write VALUES-OF, but do you mean a block of words that are different?

now that we have FOREACH on objects, it could be a good time to ask 
on the blog or in chat.

even with UNIQUE, i got a stupid result.

>> obj2: make obj1: context [a: b: none] [a: 1]
== make object! [
    a: 1
    b: none
]

>> unique/skip append body-of obj1 body-of obj2 2
== [
    a: none
    b: none
    b: none
]

what's wrong with all thess bugous functions ?

Not my opinion concerning some bugs i found. 

I think they have a lower priority than those, I or other poeple, 
have posted currently.

I want my previous request corrected at first, then i'll come with 
new ones with lower priority.
If you don't agree with that, then find the bugs yourself

Not posting bugs to curecode is a good way to betray the continuing 
development of R3.

And I basically strongly disagree with this method, because a non-posted 
bug report will eventually be forgotten by the person who found the 
bug until years later when it turns up again for a different person. 
It serves no purpose for anyone, not posting the report, including 
the would-be reporter.

If i see a better aknowledge of the priority of some bugs in curecode, 
then i will change my mind.

Priority is not a parameter in the REPORTING of bugs. It is a paramenter 
in FIXING the bugs. I don't see how software development could work, 
if everyone posted bugs based on perceived priority on whether they 
would be fixed. Carl expects us to do alot of the work with finding 
bugs. When they will be fixed is up to him.

further...

Take the implementation of modules and protect stuffs, I agree it 
may be (maybe) deeply modify the core and it's why it's must be done 
now, accordingly Carl and BrianH.
But for a user concern, it has a very low priority.

It's only of interest for those who want to create new commercial 
applications with R3, in few years....

But we will not develop new applications, if some important things 
that were  working in R2 are not working anymore in R3.
It's what i call high priority, NO REGRESSION allowed.

But for a user concern, it has a very low priority.

 Correct. And you are not an R3 user. You are testing R3 alpha software. 
 Which is why it's essential to report bugs to Curecode.

Steeve, I can guarantee that if bugs are not reported they won't 
be fixed at all. It is completely inappropriate to compare the R2 
project to the R3 project. Bugs weren't getting fixed in the proprietary, 
release-rarely R2, but they *are* getting fixed quite regularly in 
the semi-community, release-often R3 project.


We are in alpha, and still in the design phase with much of the core 
of R3. We only have so many people actively contributing to R3, only 
so much capacity. And you might recall how much we have been insisting 
that people not use R3 in production yet, that it is not ready. This 
means that the main product that is setting the priorities of what 
gets fixed or implemented is R3 itself. And that product is still 
being built.

No regression allowed

 - are you kidding? Large quantities of R3 are brand new code. It 
 isn't regressing, it just hasn't caught up yet.


And don't assume that the code will work the same in R3 as in R2 
- we aren't even trying to be compatible with R2 except where appropriate. 
We're fixing design shortcomings in R2, not just bugs, and that means 
incompatibilities sometimes. Compatibility with R2 is considered 
a nice thing to do, but not as high a priority as doing things right, 
adapting REBOL to handle the needs of today and tomorrow.


And speaking of priorities, they are not absolute. We set priorities 
relative to what we are working on now and what we will need next. 
Once those things are done, we bump the priorities of the next things 
on the list.


We recognize that vectors are important, but they are not as important 
as security and modularity *right now*. We needed modules settled 
now because the plugin model depends on them, because it would help 
us design the security model, and because the GUI and mezzanine code 
needs organization to be further developed.


We need the plugin model because it affects the host interface design, 
and the host interface needs a redesign before we can release the 
host code. We need to release the host code so that more people can 
fix bugs like that OS X bug PeterWood mentioned.


Things are going to get fixed, but most fixes require other things 
to get done first. We are focusing now on the bottlenecks, the bugs 
or waiting improvements that are blocking the most. Right now the 
highest priorities are those that are blocking people from contributing 
to R3, because the resource we have the least of is people that are 
willing to help.

The two biggest things blocking contributions:

1. We need to release the host code so people can fix platform-specific 
bugs.

2. The GUI infrastructure is just not in good enough shape to handle 
contributions, at least from a code organization standpoint.


There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
and in some cases we really need those people's help (ironically 
enough, not always for GUI work). For that and many other reasons, 
the GUI is a huge priority in the short term.


And we *really* need to release the host code, or platform-specific 
bug-fixes and enhancements won't happen.

There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
  

I'm suprised that so many people are happy to work with a non-gui 
client.  If one asks for volunteers to spend their time, and create 
a retro environment for them to work ... you're not going to get 
the optimal result.

Steeve, in may experience the Curecode reporting system is far more 
effective than RAMBO.

There is clearly a lot f effort (thanks, Brian!) put into analysing, 
categorising, prioritising and fixing issues raised via Cuecode.


Not everything, of course I've added issues that have languished 
a long time, and some that have been dismissed. But they are outweighed 
by the ones that have been fixed in a few days.

It may be a lottery, but it is winnable :-)

Don't take it personally if something sounds ridiculous to me - I 
don't consider my opinion to be common.


We needed the infrastructure in place for collaborative development. 
What we were using before (AltMe, DevBase 2, traditional revision 
control systems) had failed us - we couldn't scale past about 5 developers 
before the process fell apart. That's why the R3-GUI AltMe world 
was created.


Even in text mode, R3 chat and DevBase 3 have been a huge success, 
as the many releases of R3 in the last few months have shown. We 
needed contributions to get R3 to the point where it is now.

Should write a book about it.

Pekr: "Steeve - your attitude is the same what DocKimbel showed here 
some two weeks ago. I thought that I am talking to adult ppl, and 
I really don't understand such childish behaviour". 


Are you sure you were thinking about me? I just re-read my old 2 
posts about money! datatype, I don't see what's childish in reporting 
a bug in RAMBO and warning about that?

You mean money! uses floating point in R2? If it's true, I don't 
see the point in having a money! datatype?

But it should be useful in R3:


The money datatype now uses a coded decimal representation, allowing 
accurate number representation up to 26 decimal digits in length. 
Due to its accuracy, this datatype is useful for financial, banking, 
commercial, transactional, and even some types of scientific applications.

My only problem is that you have to use the money datatype to use 
this number format. It could be useful in other places. But I think 
we've had this discussion before.

If you do a ? datatype!, in R3 you get:


money!          datatype! high precision decimals with denomination 
(opt)

So you may wonder as a beginner why the description is like that.

I guess Ladilsav can answer your question about the ease of back-porting 
to R2 but I would guess that it's c code which means it is likely 
to be a long time before it would get back-ported.

If R3 still uses 128bits slots for values, it shouldn't change memory 
usage from a user POV?

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.

While we're talking about memory management, will it be possible 
to add in R3, a mean to adjust or tune GC behaviour by exposing some 
of the internal parameters? The goal is being able to adapt the tradeoff 
between speed and memory usage in various situations. For example 
: being able to set a max amount of memory for a REBOL session.

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.
Can you be more precise Brian ?
How long are the new slots ?

I think of memory in terms of number of elements (which i can affect) 
rather than element size (which I can't). I don't think of RAM size 
except for at a overall process level.

He mentioned the real sizes at some point (in a blog I think), but 
I don't remember the exact numbers.

Same with exposing COLLECT-WORDS so it can be used instead of BIND/set 
into a temporary object.

The BIND/copy overhead is still there, but being able to use FOREACH 
on map!, object!, module!, port! and error! means that you don't 
have to generate a block! copy of those types in order to work on 
them. Plus you don't need the EITHER or CASE to screen for those 
cases.

Uhm, was not my request, it would be more usefull to be able to use 
FOREACH as an ACTOR in a scheme.

Yeah, I didn't request that either. Did you file a CureCode ticket 
for FOREACH on ports? I recall some overly general ticket you filed 
that was requested to be broken up iinto individual tickets, but 
not the individual tickets.

You might be a little late here - port! has been added to the any-object! 
typeset (I can't say for sure). You gotta file tickets if you want 
to get things done.

At least on a native level. On a mezzanine level you can do it yourself, 
as long as it's a good idea :)

It's not a type, it's a collection of types (typeset!). In this case 
a collection of the types that act like objects.

i'm aware of that, don't do a disgression

I'm not sure, but i just think there is a difference in the way of 
treating the argument any-object! and object!
In the first case the port is populated like an object.
In the second, the function is usable as an actor for schemes.
It's really different use cases, I hope i'm wrong here.

If you want FOREACH to work on ports in a certain way, you need to 
write a ticket for that. Mentioning it here won't accomplish anything, 
as Carl almost never sees the stuff we write here.

Um, no it wouldn't. It would just allow error!, task! and module! 
to be copied too (which would be a bad idea).

hi


as far as I know it is possible to convert binary to decimal in R3. 
Is there already a reverse conversion?

bah, you can store a fixed point decimal, what the need to store 
money ?

A lot of stuff doesn't work for money! yet - we have a stack of deferred 
tickets for money!, not as many as for vector! though.

What !!! Some mezzanines are lower ?
it's a joke right ? ahah

(i forgot that LOAD was a mezzanine now)

file storing in a compact format

to-binary on decimal is actually the only method how to obtain the 
precise representation of a decimal. For money! mold suffices

If Rebin store slot values, it will not be compact, same memory overhead.

To binary! furnish a more compact way to store data, with a speed 
issue indeed

actually it would be a true reversal mold

so if i take another example, i could do a save in rebin format of 
the screen gob, then reload it and being in the same state i was 
when i saved it ?

it would be a new way to make screenshots

is that not a too powerfull feature for  humanity ?

it was actually Geomol on 8-Apr, who too refused to submit bugs, 
as those might not be corrected anyway


Pekr, I don't refuce to submit bugs! I have submitted bugs after 
we discussed it here. I just see little point in submitting bugs. 
And I have the practical problem with finding time to submit all 
the bugs, I could. But I do something, I consider even better than 
submitting bugs in the current situation. I have done some development 
lately, that test the REBOL scanner deeply. I have collected all 
my findings in a document, that I'll give to R3 developers, when 
I'm finish. The scanner is just one part of REBOL though.

If you want to really test the scanner, test TRANSCODE. There is 
already one bug ticket in for a change in TRANSCODE's behavior, and 
I know of another bug that is worth reporting. If we find more bugs 
that we can fix, that would be great.

I just see little point in submitting bugs.


If you are talking about bugs in stuff that is mostly designed but 
not fully implemented (like money!, or maybe vector!) then they are 
worth reporting if they haven't been reported already - just don't 
expect an immediate fix, since we may not be working on those yet.


If you are talking about bugs in stuff that is still being designed 
(like the GUI) then reporting problems in R3 chat is better. 


If you are talking about bugs in stuff that hasn't been designed 
yet but may have a placeholder (like task! or utype!) then don't 
bother.

If you are talking about bugs in what we are working on (there's 
a roadmap) or requests for new behavior then report them asap :)

Do you mean double-quotes? A hyphen is this: -

Just downloaded R3-a49 release and Gui Demo is working ( text view 
isn't ) but I can't get simple window to show :(

Examples from http://www.rebol.net/wiki/GUI_Examplesare not working.... 
:(
I get missing this missing that... :(


I just want to show simple text in a window, or a button... am I 
asking to much ? :)

Brian: do you have proof that value slots are bigger in R3? I'm not 
aware of it being compiled for 64bit system (thus, no 64bit pointers), 
and there's more than enough space in 16 bytes to hold a 64bit integer!

Well I downloaded r3-a49 and started it. Typed Demo, and only when 
I press View-text error happens... other parts are working fine...
Could be that missing load-gui is a problem :) oopss

and a show screen before the do-events, indeed

Gabriele, all I have is a memory of Carl saying so, and that memory 
is likely 1.5+ years old, from back in the early days of R3 (2007).

My God... path notation (with parents) is faster than PICK  to get 
a value from a serie with a calculated index, even in the current 
R2.

t/(x) faster than pick t x


I was always thinking  the reverse since a while (true in older R2 
release).
How may this happen to me, i'm fooled...

Geez... i have to rewite a bunch of scripts beacause of that