AltME groups: search

Izkata has found a way to speed up your bug 1,000% :-)

The /part refinement of copy requires a number! series! or port! 
value.  But it seems that it should be able to accept a NONE value 
as well.

linux-1.3: nameclash: /link wants ~/.rebol as file. /view now wants 
a directory there. I guess we have to rename, ~/rebol.d ?

At least until a /link-1.3 is out.

Linux 1.3 Beta -> I need to give an extra do-events for view actions 
to make a face...

Linux 1.3 Beta -> Startup Problems FIXED !! For the OLD rebol there 
is always a .rebol file in the home directory that is why rebol report 
the problem above.

You can test if the install works by executing ./rebview --reinstall 
after moving the ~/.rebol file. desktop is now starting!

Rebolinth : thanks a lot

Linux 1.3 Beta -> The digital Clock example from Carl Stops working 
after a resize, it just disapears from the screen..Feature or Flaw?

Linux 1.3 Beta -> http://www.rebol.com/view/tools/icon-maker.rDoes 
not what it tells it should..resizeing seems a problem and the image 
is not displayed correctly.. compared to the MS-Windows version 1.3

Linux 1.3 Beta -> Something is realy from with the terminal adjustement 
during view/console and after stopping view. The Console gets messed 
up like it has the wrong TermInfo values?  During a call/shell execution 
from the view/console also the console from Rebol/view is mixing 
up the call/shell "vi" ????????

well eventualy you should not do a "probe system" in beta 1.3 ;-)

Linux 1.3 Beta -> problem with Offset inside a face where a unview 
- view changes the offset of the parent-face to a different offset. 
IM not sure if this is a feature in 1.3 but in 1.2 its not happening, 
the code below demonstrates the behaviour.. Click the window and 
the window will always move by face/offset/y
direction to a new position..
myface: make face [
    offset: 100x100
    size: 400x400
    feel: make feel [
        engage: func [face action event] [
            if action = 'down [ unview myface   view myface  ]
        ]
    ]
]
view myface

Linux 1.3 Beta -> Looks like the ENGAGE is aways 1x1 pixel wrong... 
a 0x0 is out of the X window while a 1x1 is exactly inside the X 
window, this could be a X window manager problem though...(Im using 
Blackbox)

Linux 1.3 Beta -> When running this script and pressing the window 
im getting the following error ->
view make face [
    offset: 100x100
    size: 300x100
    edge: none
    pane: reduce [
        make face [
            offset: 0x0
            size: 300x100
            color: water
            edge: none
            text: "Modified Font Object Settings"
            font: make font [
                name: "times"
                size: 20
                style: 'bold
                color: white
                align: 'center
                valign: 'middle
                space: 4x4
                shadow: 2x2
            ]
        ]
    ]
]



--- ERROR --- although its not a displayed event i think that it 
still should not dropout..

** Script Error: Invalid path value: dirty?
** Where: evt-func
** Near: if all [
    system/view/focal-face 
    event/type = 'down 

    not within? event/offset win-offset? system/view/focal-face system/view/focal-face/size 
    system/view/focal-face/dirty?
] [
    fac: system/view/focal-face 
    unfocus 
    if flag-face? fac on-unfocus [
        do-face fac none 
        fac/dirty?: none
    ]
] 
event
>>

I want a suggestion, but otoh I don't give you much chances of how 
to change my mind, as some things are simply wrong with new-computer-View-initial 
behavior ...

So - if most ppl agree, that starting desktop and trying to connect 
to internet directly is good thing (with auto proxy detection it 
could be, without it it simply is not), then I want -i and --noinstall 
to skip Desktop launch phase - and that is what I am about to submit 
as a request, or as a bug report ...

if this does not work, then it's a bug. otherwise, it's your wish, 
which may or may not taken into consideration.

but i'm not completely sure i understand your case. if you want to 
just launch a script, you should 1) launch the script like above, 
2) use the sdk to encap it so that you just have an exe. if you launch 
rebol by itself, it's obvious to me that it starts the desktop unless 
you have specified otherwise (user prefs).

i think this is just a bug in the desktop startup code.

it should not start the desktop if you provide a script in the command 
line.

There is a problem with the issue! type. It doesn't accept the slash 
character as the example in the rebol core manual says.

Should I post a report ?

Yes please. These may not be "errors" in and of themselves, but such 
inconsistencies have a ripple effect as you've identified that make 
REBOL harder to use / understand (especially when compounded with 
other inconsistencies). BTW, the other inconsistency I've noted in 
the past in this area is the use of "face action" versus "face act" 
versus "f a" in some places. It would be nice (if not already so) 
if this was sorted out.

Ok, posted it. But on consideration of the issue of abbreviated argument 
names, I don't feel strongly enough that it's so bad. In some cases 
it looks justified to abbreviate FACE to F, like when there are a 
gazillion references to the face. In some cases, the arguments are 
only used once each so there's not much advantage in abbreviating 
them (but they are anyway).

Doesn't do that on windows -- so definitely a cross-platform problem.

The interpreter stops respondin and start consuming a lot of cpu 
cycles.

whoa - doesn't let go of the memory, though. I ended up getting a 
Virtual Memory warning from Windows after doing that a few times. 
Memory consumption went down as soon as I quit the Rebol console.

RT is re-prioritizing things as they go, because the community will 
get excited about certain things, so it's good go consider putting 
a little time in on those. Other tasks have larger implications and 
take a lot of time to design and code. The /direct issue is a good 
example because they don't want to break file handling code (which 
is used in *many* scripts), nor do they want to just dump in a quick 
change and make matters worse in the long run.

What about a new refinement /stream and keeping /direct for backward-compatibility? 
And the old protocols are source, one could add an option to enable 
them. Would then be a small change to get scripts running again, 
until the bigger one of some rewriting is done.

So, understanding you correctly , there was a time when open/direct 
worked?  I need this to get access to large files without the system 
trying to load it completely into memory/buffering it. Without this 
option there is no way for me to use REBOL for my problem. I don't 
understand where the compatibility problem should be. Open/direct 
is defined to get non buffered access to ports. Was this different 
in the past?  As you say there are scritps where this feature is 
used, so there must be a version where this worked or was it used 
with the wrong behaviour ?. If so, i understand why there is a discussion 
to change the behaviour. But then the definition of open/direct should 
be changed and a new refinement be implemented which gives you the 
possibility to take advantage of non buffered port access. 


I know the community needs new features, not only for marketing purposes, 
but often enough i really don't understand how a priority is set. 
I know, it is not my business to decide such things. I am only a 
person interested in REBOLS future.

I was just amazed the open/direct didn' t return anything in View 
1.3.1 not even an error. Thanks to this hint. I Think i try one of 
these to keep up development, hoping there will be a fix or new solution 
in one of next releases. Perhaps it will be in the near future ;-)

I hope so too. It's a good bet it will work the same way in future 
versions, when it will be added again.

also, it's not that /direct does not work; it does, always has, in 
that it does not buffer. the problem is that it does not allow seeking, 
i.e. it only allows sequential access. so you can open a 2GB file, 
as long as you read it sequentially.

Btw, would it help to have a native dll for file-access until rebol 
is smarter? should not be that hard.

Or, is it a specific Windows bug?

is there a list of fixes/additions somewhere? Or can I query RAMBO 
somehow to show me what tickets were done for certain version?

Bug #3873 isn't a bug. REBOL does nesting of { and } when strings 
are specified with {}, and ignores { and } when strings are specified 
with "". The ^ is unnecessary in "{^}" because the } doesn't need 
escaping. The ^ is a syntax error in {{^}} because the } would already 
be escaped by the first { inside the string (the second overall), 
so escaping it again means that the string is never finished, as 
there must be one unescaped } after every unescaped { because of 
nesting. In both cases you either shouldn't put the ^ ( "{}" or {{}} 
), or should escape the ^ if you want it in the resulting string 
( "{^^}" or {{^^}} ). Sorry if that was a little confusing - I'm 
sure someone else can explain it better.

with all respect on I completely disagree.

1) I am not able to understand, why {^{} is a syntax error

2) I completely disagree, that Rebol should check pairs of {} inside 
a string - I do want to be able to handle strings with arbitrary 
contents

Hi Ladislav, about 1) I completely agree ...

>> {^{}
{    }
** Syntax Error: Invalid string -- }
** Near: (line 2) }
>> {^}}
== "}"
>>

these should both be OK.


About 2) I agree partly ... if rebols parser counts pairs of {} I 
don't need to escape them, as long as I only have paired braces in 
a string. So that may be a nice feature ...

Ladislav, I agree that since ^} is usable, so should be ^{. Counting 
of braces can be quite awkward without this. This should be submitted 
to RAMBO.


In any case, this behavior doesn't affect the ability to work with 
strings or limit the characters that they can contain. This only 
affects how strings are specified in REBOL source code. Once they 
are parsed by load, it doesn't matter where any ^ is in their contents. 
Try reading (READ native) data with arbitrary ^, { and } from a file 
and there will be no escaping performed. A load (LOAD native) of 
that same file will check REBOL data syntax and do any escaping it 
can.

OK, I submitted it as a special case.

What I wanted to say is, that this property works against the possibility 
to specify a string containing some possible sequences of characters. 
The fact, that such strings can be read from file doesn't suffice 
as an argument, that Rebol can handle any string - Rebol cannot handle 
some strings using the escape convention defined in the Rebol/Core 
User's Guide.

do you test that from console? because console has some limitations. 
if i do in a script
  probe {^{}
that works. in console this works too:
!>load "{^^{}"  
== "{"

see #3873, #3872 . console simplifies a bit.

Ladislav, as I said, you make a good point that I agree with. I find 
it more than annoying that {} nesting without being able to escape 
{ is awkward, often requiring joins with the string "{". They should 
definitely escape {. The REBOL User's Guide doesn't say how escaping 
works, really. I was left with the impression that ^ would always 
escape the next character and any special treatment thereof, but 
unless the next character (or characters for ^(00) style escaping) 
fits the subset that is handled by the current REBOL version, the 
^ is stripped and ignored. At this point the { character is the only 
one that I've found that has special treatment that isn't disabled, 
but I haven't done an exhaustive search.

Console has to to do this:
!>[
[    1
[    2
[    ]
== [1 
    2
]

So it cant use the default 'load. So either it was implemented a 
bit lazy, and/or compatible based on some old version. The early 
rebols had really problems with such bracket-things.

#3898 shows what I too reported as a critical - total annoyance of 
how View "works" in behind the firewall environment. I am glad I 
am not alone. Either rebol proxe detection code should be made smart 
(and I posted analysis how), or it should not try to connect to internet 
at all, gee! If it at least would be possible to shut the task down, 
but it isn't ;-)

0 seems to be a buggy increment value....Worth reporting:
for i 99 99 0[prin "dejavu"]


Graham: for can execute zero times if the end condition is already 
true -- even with a zero incr:
for i 99 -99 0[prin "dejavu"]

>> About
REBOL/Command 2.5.55.3.1 8-Nov-2004 Core 2.6.0
Copyright 2000-2004 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> ? datatype!
   ...
   number!         datatype! number!
   ...
>> ? number!
No information on number! (word has no value)


This doesn't seem very consistant.  I'd love to have the help function 
return a list of datatypes within a specific seudo-type such as all 
datatypes included in the Number! type.

While playing with this REBOL I got a "** CRASH (should not happen)" 
 and spewed a bunch of garbage on the console.  Unfortunately I haven't 
been able to reproduce this.  I did get a screenshot of the console, 
 however, if you're interested...

Ah.  I did have a ImageMagik library loaded when this crash occured 
but I hadn't used any of its functions.

get-face on a field with hide returns asterisks instead of the text.

Is that a "bug" ?

I've seen this before and it's probably because password fields store 
data a bit differently than normal text fields.

Gabriele had a patch somewhere to set-face, I think

I'd better download and test the latest view before I submit a report.

repetedly getting this with core 2.6 for os x, the code does a buffered 
ftp copy, is it known issue? should I investigate more what part 
of code is doing this?
** CRASH (Should not happen) - Invalid string width 20 : type 41

Graham: get-face on hidden fields is a know bug : http://www.rebol.net/cgi-bin/rambo.r?id=3445&

This looks like a bug to me:

Are there any news about  #3869 CRASH (Should not happen)  - Invalid 
string width 16 : type 41 ?


A few weeks ago I got the same error randomly with the new beta command 
version.


I was now able to boil it down and it seems to be a general problem 
in all new versions.

Anton: it is not a bug for me.

Perhaps an error would be a better behaviour.

i got version REBOL/View 1.3.1.3.1 30-Aug-2005 Core 2.6.0 and my 
async ports are not working, open has no refinement called async 
a bad build ? somthing missing ? help

ah, now I tested it, RebGUI works with system locale - besides that, 
the week starts by monday ;-) btw - could RebGUI code be reused in 
official rebol distro? e.g. as far as request-date is concerned, 
or even request-dir, it is of a much more quality than rebol's built-in 
ones  ....

It use locales and can start on monday or sunday, show today with 
red circle, has today button at bottom, and can be initialise with 
a date shown with a red square.

Im really worried about this alpha thing, personaly i belive rebol 
is a great tool and i use it all the time, 

i know there is the time factor in development, but i belive there's 
no priority and the policy about TODO's 

it's crazy, on one side, services, view and graphics, sound formats, 
and on the other, multitasking, async ports, 

OSX support, and so many, many others... all taking place at the 
same time... 

We don't know what's first on the list, rebol changes as fast as 
developers type their code, 

(i dont  mean it in a bad whay, but still worries me) so todays 100 
lines may be tomorrows 10 

and so on ... why to spend time writing code on some issue will never 
leave alpha state, or even workst, be droped down 

some code will loose compatibility with newer versions and refuse 
to work, 

some other cobe, may become obsolete and old as soon we put it on 
the market, i think rebol has loose the KISS strategy. 

i know we love our 600K amazing tool, but don't be fool, this 600K 
don't mean is an easy and standarized 

development tool it's more like an other thing... ok it still is 
a cool tool, bla bla, but we must know 

there's a line conducting rebol upgrades, not just the crazy 600Kilobytes 
limit, 

it would not mind to my even if it whas 600 megas at this point this 
limit has loose the sence to be. 

i think here ideas come and go to fast, development has, in the last 
years, been embeed with the fashion of some lenguages, 

leave out the top then fight, we dont need it, just make it simple, 
i know rebol will reach maturity only if a srtight line traces his 
development

please note that i know rebol is been maintened by a small goup of 
developers, and with a small budget,i know a LOT of 

work has been done now and in the past, the reach today rebol state 
of development, and there's too many thing to do to make us all happy

You are not alone waiting for what comes, because while View 1.3 
was nice example of how things could/should work, nothing public 
happened since then and it is not a good sign. That is why I suggest 
to wait one more week - but to be honest - for me it will be deciding 
point if I start to take REBOL more seriously or not, because I don't 
want last devcon promisses to happen once again - none of the promissed 
stuff was actually delivered ...

may be here thing are getting to big for such a small goup of people 
and budget, rebol development need's to take place in another context 
that's somthing we all know

Anton, the first block of while it is not the body of loop, it has 
a special meaning, for example it must eval to an any! value:
>> while [][]
** Script Error: Block did not return a value
** Near: while [] []

I see many solutions:
 while [return true] [] could be considered like
	- while [true] [] 
	- an error!
	- return from while with a value (like break/return value)
	- return from the outer function (your proposal)

Anton: I support your proposition too. Carl once corrected a similar 
issue with BREAK from WHILE condition block.

ax: make struct! [fnc [callback!]]none
ax/fnc <---- this hangs up rebol with a GPF error.

that damm article,  yes i've read it too many times maybe... ok what 
about this  

a: make struct! [x [integer!] y [integer!] z [struct! [ xy [integer!] 
yx [integer!]]]] none 
length? third a 

== 12 <--- it has 4 integers thats 16 not 12 !  what about 0141.html 
now ????

xy is a pointer to a struct, nt the struct itself.. sadyl we lack 
nested structs.

yes it's a pointer to the struct, a workaround my be done because 
you can know how many intems are including the nested one's, and 
as far i can see rebol assigns 4 bytes for all datatypes meaning 
strings and nested structures ar also pointers

you can use size: (length? second a) * 4
it may fail :-)

yes, all pointers. workaround for amll structs is: z [integer!] z1 
[integer!] ; in the main stuct. for other things you can try binaries 
and deal with offsets. or write a wrapper in c.

yes that's execly what im doing ;-) i send a number to C it read 
n data from the pointer and then passes to rebol as a string the 
i use Romanos's wraper to cast that into a structure; but i get ocational 
crashes when reading fron a crazy pointer :-) i consider this a hack, 
but still may work ...

attention: pointers in structs are considered strings. they are copied 
back *until* a 0 is found.

yes thats why im sending the amount of bytes to read back to the 
C wraper still it gave me a haed hache lol

so you trying to say, that if there is struct inside a struct, you 
don't use it, you just provide it with "flat" binary, and then you 
compose things back in rebol level? Why is that better than using 
structs in structs?

well realy the thing is... did you remember that windows sometimes 
adresses structures in window messages like lparam or wparam, so 
i get the nasty number, and i've to buil a structure back from this 
*pointer*,..... because i do drugs :-)

well, you cant see what we do, because we crawling under the cars 
engine here ;)
but yes, you are right.

its because rebol has no inner structs. when you declare them, it 
actually allocates a pointer there.

thats fine with own code. but os expects real inner struct, so we 
have to workaround to allocate the right space.

coding in C stinks .... I don't wanna carry C compiler with myself, 
unless included in Rebol ;-) Librry interface should be enhanced 
then. What about trying to post a wish into RAMBO?

some years ago i've used a realy cool compiler rapidq the bastard 
dident have the posibility to pass structures back that time i used 
this kind of workaround

c-compiler costs me ~4mb if it is a big one. and a good interface 
needs processing includes. basically that *is* a c-compiler included 
in rebol then ;)

No, the problem is rebol has a good c-interface and a pretty good 
with some meta-programming. (to avoid this double-declaration in 
rebol and c). but it has a terrible os-interface (by lack of full 
c-structs and includes). if you accet that and interface onyl to 
your code, its wonderfull (as wonderfull as c can be).

c has a verry strong type checking thats cool for some cross over 
plattaform but wen it comes to rebol interface you get mad ...

is a conversion-error, $1 is greater than to-money 0.09 .

if you call from a browser it will redirect you to the following 
url: https://acesso.uol.com.br/login.html?dest=CONTENT&url=http://www1.folha.uol.com.br/fsp/opiniao/fz1010200501.htm&COD_PRODUTO=7

RFC 2616
10.3.8 307 Temporary Redirect


   The requested resource resides temporarily under a different URI.

   Since the redirection MAY be altered on occasion, the client SHOULD

   continue to use the Request-URI for future requests.  This response

   is only cacheable if indicated by a Cache-Control or Expires header
   field.

   The temporary URI SHOULD be given by the Location field in the

   response. Unless the request method was HEAD, the entity of the

   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s) , since many pre-HTTP/1.1 user agents do not

   understand the 307 status. Therefore, the note SHOULD contain the

   information necessary for a user to repeat the original request on
   the new URI.


   If the 307 status code is received in response to a request other

   than GET or HEAD, the user agent MUST NOT automatically redirect 
   the

   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

Gabriele, regarding 
http://www.rebol.net/cgi-bin/rambo.r?id=3918&

I found my patches still cause visual artefacts in certain circumstances, 
so this report should be cancelled.
Sorry about that.

(It does demonstrate, at least, how to iterate PROGRESS style in 
a usable way, but I'll better publish that elsewhere.)

when you try to read the redirected url.. it sends back a forbidden 
message.. it is common with the 307 that returns back also a 401 
message

I think that http scheme should behave as a browser in all aspects.. 
you know..  the http scheme is not complete to simulate all the browser 
functions.. :-( I mean, cookies, redirections etc

You would have thought RT's automated tests would have trapped such 
a change.

Gabriele: I submitted a "Read beyond network port" crash ticket. 
(see Recycle bug group discussion)

dont have access to rambo could someone submit an error in the word 
brower for me.  in the find box a down arrow errors with: ** Script 
Error: index? expected series argument
 of type: series port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first

This is a known and already corrected bug. The new version has not 
been uploaded yet, waiting for other changes pending.

For that matter, I just submitted another rebcode proposal to RAMBO, 
and then noticed some code in the fix section that I wanted to change. 
The submitted code still works, but I would still like to clean it 
up a little. If I had an account on RAMBO, would I be able to fix 
my own submissions?