AltME groups: search

Max, I'm sorry I don't see any degrading 'ringing effect' when looking 
at your example. Even while looking at scaled screenshot the AA of 
the edges of circles looks perfectly symetric to me(did horizontal 
flip comparisons). I'm using average LCD display and also my eyes 
are getting older every day so I still might missing something.

AFAIK AGG is not using any 'compensation' code. It simply computes 
the covers of every pixel cell using 256 levels and ofcourse uses 
subpixel AA(try to translate by fractions of pixel..). So the AA 
result is still very high-quality(though there are very few special 
cases limitations of the used alogrithm). If you compare it to current 
FSAA abilities of gfx cards 256 levels is still way more than what 
the current  super/multisampling offers.

you could try looking visually at a few gradient tests just to understand 
what is happening, you might find a pattern.

I made ATAN2 while ago, I try to find it.

searching for strings will be slower... probably much slower... just 
try it out with some data  :-D

I think, that it is quite natural. You should probably generate some 
random data having (approximately) similar properties as what you 
intend to process and try some variant approaches to really find 
out, which one is best for the task. Do you know, that it is possible 
to index just a specific record field, i.e. you don't need to make 
a hash containing all the data from the database?

my suggestion is to try it on hashes

This is another example of trying to make the interpreter second-guess 
the user and try to do they they "mean to do". That inevitably ends 
up in disaster. I don't want REBOL to do what I "mean to do", I want 
it to do what I *say* to do. I want its behavior to be utterly predictable 
given the same input (except deliberate indeterminacy functions like 
RANDOM). If it isn't then it's not as useful to programmers.

One thing you shouldn't do with a programming language is assume 
that the programmer doesn't know what they want to do, so you try 
to second-guess them. That is always the worst approach because the 
programmer will always end up having to work around your guesses 
so that they can do what they actually want to do, *which only they 
can know for sure*.


It's a bad sign when the language designer talks about guessing what 
the programmer wants to do. It is much better to make a consistent, 
sensible default, then provide alternate behavior as explicitly chosen 
options. It is incredibly presumptuous for you to say that the programmer 
"didn't really want to do that", and then do something else. It is 
much better to make the behavior consistent *and documented* then 
assume the programmer *knows* what they want to do and has told you 
so.


It is not the job of a programming language or library to do what 
the programmer "wants" to do. It is the job of the programmer to 
determine what they want to do, and the job of the tool to do what 
the programmer *says* to do. And if the programmer makes a mistake, 
the tool should be as helpful as it can by throwing errors where 
it is unequivocally wrong, giving enough information to the programmer 
so they can figure out whether where they went wrong, and to behave 
consistently and predictably. Because (short of bugs) the tool is 
never at fault if it does what it's told to do. It might not be the 
right tool for the job though, but that means another tool should 
be used.

:Why 

cripple" all these contexts so, that Bind has to do unsolicited work?" 
- The behavior of BIND is documented, so it is presumptuous of you 
to say that its behavior is "unsolicited" when it is behaving as 
it is documented to behave. It is much better to use the word "unwanted" 
here. It is clear that *you* don't want BIND to do the 'self unhiding 
trick, and if there's no way to turn that off then it is a problem 
for you, as a user of the programming language. So there should be 
an option, and maybe your preferred behavior should be the default.


However, you as a language designer (this is a different you, btw) 
has to consider what other users want to do, and that won't necessarily 
be consistent with what you (as a user) would want to do. So you 
(the designer) make tradeoffs, balance concerns, look for the most 
common behavior, make sensible choices, and try not to mess up. And 
then finalize the behavior in a tool that only does what it's told 
to do, and document that tool's behavior (at least on the surface). 
Then you (as a user) can know that the tool is going to respond the 
way it is documented to do when you tell it to do something - for 
a tool, this is what it means to do what it is supposed to do :)

Ah, but you were also assuming that BIND doesn't do or depend on 
the 'self trick. Try the function with BIND/self.

The situation where the user of BIND doesn't know whether to use 
/self or not, is a case of a non-programmer trying to program. REBOL 
doesn't try to solve that problem.

Ok, so let me try to recap this huge discussion. In R2 we had context! 
and object! as two separate types, although context! was hidden from 
users and only accessible by converting it to object! - conversion 
which was broken because it did not create 'self that object! requires. 
So, instead of fixing this by making context! accessible, it was 
decided to remove context! altogether and add 'self to all contexts, 
and add a bunch of exception refinements to BIND to work around all 
the problems that come out of that?

Steeve: I understand your example, no problem about it, but try to 
adapt it to my  (non-existant yet :-) possible R3 cell phone implementation, 
which will use 32 bit integers (not sure if it would ever happen). 
Then, if you want your code being cross platform, your code complicates, 
no?

>>(skip to-binary 1022 6) or #{8000}
==#{8324}

When I am adapring code from languages with C-like integer syntax 
I resolve the constants to regular integers ahead of time and then 
put the original syntax in comments. Works great, no conversion overhead 
at runtime. You should try it.

There is a lots of possible usage to raw TCP .... this is for those, 
who like to try stuff in console. They will stop right after opening 
the port .... OK, I will ask Carl ... because - If all is needed 
is for me to define at least simple TCP awake, then why is it not 
included by default then? Or we can have some handler storage, from 
which you could choose just one ...

Yes, I know. And I tried to help myself with binary. Suggestion to 
use integers, and shifting, might be accurate, but I am not here 
to crash my brain with operations I can't easily understand. So I 
try to find a convenient way. And what is convenient for me? To look 
into sources and to see, what is happening:

>> a: to-binary 1022
== #{00000000000003FE}

>> b: pad-bin #{8000}
== #{0000000000008000}

>> a or b
== #{00000000000083FE}


... you see? I could imediatelly check, that OR was correct. And 
if I would be mistaken, or needed to perform shift, I can even use 
bitmap form, to see, what is happening:

>> 2#{0000001111111110}
== #{03FE}


So - no, I will not use integers. And I don't have to, if my model 
fits what I am doing right now ... I still think that it can't fail 
me, and all those "you can't know what #{8000} means" are just theory 
for me right now :-)

brian, api builders might be smart, but end-users might not (within 
a specific field of programming), and its not their place to have 
to try and resolve much of that.


if your api works, then it shouldn't cause side-effects break... 
using accessors or not.


accessors are for users of APIs which have a lot to manage which 
isn't going to be delt by the user anyways.  

my two cents.

Currently I use 'resolve a lot, to swap contexts so that I can use 
a light syntax in every functions because they are all bound to the 
same context.

I try to eradicate paths the most I can, It's uggly and slower than 
swapping contexts at some points.

with the A98 release I will be porting liquid over to R3 for sure 
(at least I'll try and see how it goes).

Also, very few REBOLers try to migrate large apps written in a class-based 
OOP style, instead preferring to use REBOL semantics and only emulating 
classes where appropriate. REBOL is not an OOP language, by design; 
it is optimized for a different semantic model. You can structure 
large-scale applications based on non-OOP models if you like. You 
can't easily convert them to class-based languages though. I don't 
envy your task.

did you try  'SPEC-OF  ?


I am currently clueless as to R3 gobs, but its another test you might 
do while you're at it.

Try comparing without the FIRST, just put x: gobs in there, or better 
yet leave the code block empty.

ah, ok (re limitiation), I just tried joining two binaries and it 
worked. Did not try with integer value ...

no, it crashes, why don't you try it yourself? ;-)

I did try it myself; I was the one who reported #1603. I've used 
a98 for many hours now with no crashes. What platform are you running 
on, on which OS?

ok, I give it a try

>> upgrade
Fetching upgrade check ...

Script: "REBOL 3.0 Version Upgrade" Version: 1.0.1 Date: 7-Apr-2009
Checking for updates...

R3 current version: 2.100.99.4.2 
It was released on: 8-May-2010/0:13:33 

Your version is current.

** Script error: invalid argument: %/home/ramcla/Téléchargements/
** Where: change-dir all either applier do try upgrade
** Near: change-dir dir

Or, if you insist, that it is impossible to have such an operator, 
you should at least try to specify it "thoroughly enough" for me 
to be able to know what are your requirements. (that is what BrianH 
was curious about too)

you could then just apply the algorithm to the C side and let R3 
parse only a small portion of the script at a time.   That's how 
I'd try it.

All protocols are async unless you do special trickery to try and 
make them look sync

Well, I guess I can just recreate the subport and try it that way, 
but I would like to know why ....

There is a solution using RENAME, at least I think that a version 
using RENAME works, did you try it?

try to talk asynchronous processing with a guy doing java threads 
programing all day long that's interesting ...

It's not something I have any immediate need for, but it looks like 
an interesting project to try

if i can if i have access to the whole source code, but i will try 
...  most of the time i need to see the big picture to get ideas 
on how to proceed ... a mono C# clone intent have been tryed 4 years 
ago it was spirit then sudently the author disapeared and that's 
it ...

The only reason C# and the .NET platform has any traction at all 
is because C# is better than Java at the exact same things that Java 
is used for. And then the .NET runtime is better than the Java runtime 
for not only what people try to use the Java runtime for, but what 
the Java runtime is designed for. It's the libraries that fall short.

i will try so :)

@sqlab: try to bigger value.

If conversion functions aren't done by the time I finish the module 
system revamp, and I have the time, I'll try implementing the model 
suggested in the comments of that blog. Not the struct! type though, 
that would be terrible for conversions.

Peter, agreed, there are a bunch of related TRY and unwind bugs that 
need fixing. It's not blocking me as much as the PROTECT bugs, but 
it's there.

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

And is going to try a 64 bit build since the Solaris pc provided 
by TomC is 64 bit ( .. umm... aren't all PCs 64 bit ?? )

I try to keep away as long as possible.

please try a directory

ok I'll try to figure out the Architecture from the code (its a pretty 
big codebase... a bit daunting, I admit)

Carl, or anyone else who remembers - I don't recall what is holding 
things up in terms of making the source available so that people 
can try their hand at a client for R3 chat

I believe that the build that was posted didn't have the draw stuff 
in - on my own build, I get this error when I try the demo after 
loading your r3-gui script:

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
>>
>> demo
Fetching demo...

Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none
Fetching GUI...
GUI Version: 0.2.1
(Developer test GUI theme)
** Script error: expected command! not font

** Where: size-text font-char-size? make make-text-style parse fontize 
do do either load-gui case catch either either applier do try demo
** Near: size-text gob

did you try with the second load line uncommented?

ok, your compile also crashes  on my system... strange!


we need others to test this.... please, if you have a running r3 
A107 try it out so I make as precise a ticket as I can.


if it doesn't crash, download the file and try to add a few (or many) 
draw commands to it so see if it fails at some point.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

I like the fact that you are modularizing LOAD... I did try to modify 
it before and well... I thought you where brave of even getting it 
to work at that point  :-)

And as for 'mods. This is why you try to define mezz+ packages? So 
that help will be e.g. in mezz+? So 'mods is now old /base?

well, we can, but its severely limits debugging and frankly there 
is a way to do .   any context should have the possibility of having 
a private/public flag on it... its that simple. whenever you try 
to reflect a private context, it returns unset! (unbound) values.

I've got this unexpected R3 behaviour (it's the core of the LDS issue 
mentioned in [Testing and Tools]

    f: func [] [error? try [return 1] return 2]
    f
    == 2   ;; r3 does this....despite no error
    == 1   ;; r2 does this...as expected

Any ideas, thanks!

Now you have to circumvent it, at the cost of having longer code. 
I suppose, that the not simplified code is more like:


f: func [] [error? try [do-something return 1] return 2], which can 
be transformed to:

f: func [] [return either error? try [do-something] [1] [2]]

I think he'll try to peddle is "rare" Amiga items...   ;-)

Ok, ... can try it out

I think that the error codes are checked now. Fix all your tests 
that try to make errors with codes not in system/catalog/errors.

You should add some tests to verify that error code checking. I suggest 
TRY/except as a way to format the tests.

['error = try/except [make error! [type: 'foo id: 'bar]] ['error]]

try/except [make error! [type: 'foo id: 'bar]] [true]

That would slow down decompression quite a bit. It looks like a /zlib 
option would be a good idea, to tell it when to try that method.

Carl requested some info on it, I tried to help with some lookup, 
not much ppl commented. I don't remember the blog article, but I 
might try to find it ...

Would you be so kind and try http://bolka.at/2010/rebol3/r3-a107-20100913.exe
instead?

Pekr, did you try the custom-built A107 binary I linked to above?

not yet, let me try ...

you can try to attach to the console of the parent process, but carl 
seems to have tried that and it is now disabled for some reason.

The A109 did not focus on host-kit, but on other things... so not 
sure it works. I can give you a copy to try if you want.

yeah, it would be nice, I'll try to update the Custom Gob Rendering 
API to it.

so... give it a try, but no promises on this one, not tested

Pekr, Andreas, ChristianE and anyon who is interested...I published 
win console R3core version that should show correctly ut8 characters. 
IF you can try to dsiplay your native language chars just download 
it from here: http://cyphre.mysteria.cz/tests/r3-core-a107-console.zip
and let me know if it works for you.

Note that this version doesn't work well with STDIN/OUT redirection 
yet. I didn't want to waste time on this part yet until the normal 
console STDIN/OUT works well.

So divergence is more accurate than deviation in this case. (I'll 
try to keep the spelling under control.)

R3 win console: Thanks for everyone who tested. So it looks it works 
for you, cool. Note that the character output should be correct but 
the default console font doesn't support all the chars. You might 
try to use Lucida Console font in the console properties which should 
give you more(but not all) valid characters or get some other unicode 
capable console font from the net...

OTOH if your app is of 'GUI' type and you execute it from CLI (for 
example cmd.exe console) the CLI automatically detaches your exe 
from the console so the cmd.exe propmpt is able accept next commands. 
This is also problem because even if you try to re-attach your GUI 
app back to the console from which it was started, the console is 
shared in paralel with the CLI process and your app. So in the best 
way you'll see two interleaved input lines...one fro rebol commands 
and one for DOS commands.

Ok, A110 is out, but I'm going to be away for 2 days. I'll try to 
check-in to see if there are any questions here.

Is the safe R3 way to execute a script to use:
   do load %script-name
rather than R2's way:
   do %script-name
?


The reason I ask is the different behaviours I see here (I'd expect 
them both to print a 1)....
    n: 1 try [do %test-script.r ] print n
    n: 1 try [do load %test-script.r ] print n

....where test-script.r is these two lines:
    rebol []
    0 / 0

I'll try to get in touch with Carl over this.

and, being at it, yet another annoyance of exactly the same kind 
is:

o: make object! [me: 'o]
error? try [bind 'self o] ; == true
bind [self] o; == [self]

, i.e. again, one can bind as wished, so the "feature" is just meant 
to be annoying, not useful

Extend is a mezz, so that much be slower.

And I always try to avoid GC overheads due to excessive  usage of 
'reduce


Thats why I think bind/new is more capable especially, this form:
>set bin/new 'b obj 2
instead of:
>>bind/new 'b obj obj/b: 2

It is not a myth that REBOL is fast. It can sometimes be misunderstood 
though, because people who are familiar with other languages will 
try to write code in the style of those other languages and expect 
it to be fast. REBOL code written in REBOL style for tasks that REBOL 
is suited for can be very fast.

It goes the other way too: If you try to write REBOL-like code in 
most other languages then you will run into a wall. For most you 
will need to reimplement most of the natives before you can start, 
if it is possible to do REBOL-like code at all (often not with parsers). 
And when you do manage to get that code running it is often slower 
than REBOL code because of the optimization its natives have gone 
through.

rebol.net is up again, at the moment. In case it is done when you 
try to follow the "copy semantics" link, Yahoo has a copy cached.

Why do you bother to try to help Tutorial translate a non-working 
code example?

Try CLEAR instead of REMOVE.

Jerry, you might want to try the above and see if the wait occurs 
on the 21 millionth item.

This page suggests that the 

internals" of R3 does have NaN defined" - how does the text suggest 
it? I, as a coauthor will try to correct the text, if it does.

Maybe you can try
to-decimal #{ ... 16 digits ... }

If that still works, you can use it to test, what you get, when you 
construct numbers like NaNs. To see how REBOL3 handle it.

Ladislav - it was exagerration on my part :-), but I just try to 
explain, that we have imo more important things to care about :-) 
No offense here ....

I should try if extension could speed up such a conversions.

Yup. Works great until you try to use "value" in a sentence, because 
of English's ambiguity :(

I mean... I can do:
>> if error? err: try [1 / 0][probe err false]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== false


but what if I would like to form the error message to look like if 
the error is really evaluated:

>> do err
** Math error: attempt to divide by zero
** Where: / try
** Near: / 0

Oldes - you can try to grab them out of here, but not sure how easy 
that will be:
   probe system/catalog/errors

So far I have this:
my-attempt: funct[code /local val][
	either error? set/any 'val try code [
		val: to-object val 
		do bind [
			print rejoin [

    "!! " val/type  " error: " reduce system/catalog/errors/(val/type)/(val/id) 
    #"^/"
				"!! Where: " val/where #"^/"
				;"!! Near: " val/near  #"^/"
			]
		] val
		false
	][
		:val
	]
] 

my-attempt [debase #ff]
my-attempt [1 / 0]

but not perfect... the Near and Where info is modified :-/

I was using this function in R2:
parse-error:  func[
    error [object!]
    /local type id arg1 arg2 arg3 where err-desc
][
    type: error/type
    id: error/id
    where: mold get/any in error 'where
    either any [
        unset? get/any in error 'arg1
        unset? get/any in error 'arg2
        unset? get/any in error 'arg3
    ][
        arg1: arg2: arg3: "(missing value)"
    ][
        arg1: error/arg1
        arg2: error/arg2
        arg3: error/arg3
    ]
    err-desc: system/error/:type
    rejoin [
        "** " err-desc/type ": "
        reduce either block? err-desc/:id [
            bind system/error/:type/:id 'arg1
        ][
            err-desc/:id
        ]
        newline
        "** Where: " where
        newline
        "** Near: " mold error/near
    ]
]

>> f: does [1 / 0]
>> if error? err: try [f][print parse-error disarm err]
** Math Error: Attempt to divide by zero
** Where: f
** Near: [1 / 0]

In R3 the WHERE and NEAR report is different

You are right... simple FORM err works:

>> error? err: try [1 / 0]
== true

>> form err
== {** Math error: attempt to divide by zero
** Where: / try
** Near: / 0
}

Kaj, you should find a way to fire all the <copy/part ... > you're 
doing.
I would try to reuse the same buffer with something like:
>> append/part clear buff ...

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.

I'll try to see if Carl can come in here to solve the issue.

Try Core or View.

You should try it, it's not bad.