AltME groups: search

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...

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

I just think get-face and set-face are not complete, e.g. AFAIK they 
only work properly on textfields, radio and checkboxes

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

The problem is that #3445 is marked as build, and it's not !!!

Should I submit RAMBO ticket? Rebol.com website refers to View 1.3.1 
and mentions Windows 9x, which is not true. Dunno who and why decided 
that we should cut-off Win95 machines, but it happened. And as I 
will not use old 1.2.1 with all those differences anymore (yes, I 
am that one who prefers adjusts old stuff to new versions), we cut 
off some xy percentage of potential customers. I will have to check 
if Win98SE are affected by that too ... anyway - my point is, that 
such missleading info should be removed from website ...

RAMBO is for technical issues, and not policy issues.

could you read twice, please? ;-) IIRC, rambo is also about reporting 
inconsistencies in documentation etc., and if I am not alone who's 
one of Win95 machines does not accept View 1.3 and website tells 
so, then I regard it being incorrect.

;== none  (on Rebol/View versions 1.2.108.3.1 thru 1.2.110.3.1,  
and versions 1.2.113.31 thru 1.3.1.3.1d)

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.

Just send as many messages as you can from other computers and sooner 
than later it will crash .

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

ok i've dowloaded REBOL/Core 2.5.53.3.1 ALPHA VERSION (Aug 17 2004/22:43:09) 
(note both, this 2.5.53 and the last 1.3.1.3.1 are win x86 versions 
running on XP SP1) and works okay ! what wrong here ?

Gabriele - isn't 'request-date somewhat unfinished?Try 'help request-date 
and look how is /offset described, what it says it accepts (any type) 
and what it really allows to accept (pair) ... Maybe this could be 
improved ...

besides that I wonder, if e.g. request-date as an example, works 
with locale element? I think not ... REBOL locale support is really 
terrible - nonexistant, and I wonder why, if system/locale/months 
is available ...

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.

it will most likely be implemented, but we'll have to wait and see 
if it will be exactly that implementation.

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

Romano, yes I think to be consistent, it would be better that RETURN 
should exit the while loop and return from the function, and BREAK/RETURN 
should only break from the while loop.  That way we don't have to 
think when we can and cannot use RETURN.

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

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 ...

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 :-)

but if you can code c, i would do all the os-coding in c then, and 
use rebol-structs only for pasing between rebol and my c. gives os-includes 
without any pain, much easier.

I don't even know what do I mean. The only thing I know is that I 
find wrapping libraries not all that comfort and I would like to 
ask those having experience with Python,Perl or any other language, 
if they have some easier way of how to do that or not ...

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 ;)

Maybe the trouble is really in me and not being able to properly 
do datatype conversion and all those structure wrappings etc.

yes i know what you mean i put = in rebol and : in C also i get lots 
of sintax error mising semicolon.... wrapers stink

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).

if you try to mimic c-structures. if you create c from rebol-structes, 
it acceptable. maybe does not really check parameter-types, IIRC. 
but not sure, i rarely need rebol<->c and more rarely make that error.

Is this wine or real windows too?
>> to-money 0.09
== $9.00
wrong with everything with leading zeros.
does not happen on linux.
to-money 1.09 works ok.

Does money string-based conversion and sees windows 9.0000000e-02?
1.09 looks like 1.09000000e+00, so fraction-part is behind ".".

oh, I just submited bug with the forall and just now found that the 
same bug was already submited

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

RAMBO 3939: In response to your question, I propose an alternative. 
Instead of changing to-dec and to-int to handle decimal and integer 
(respectively) source values correctly (slowing down the common case), 
add as-dec and as-int opcodes that act as assignments when given 
source values already of the corresponding type, letting those opcodes 
have the overhead when you can't be sure the source is of the opposite 
type. Also, change to-int to assign 0 instead of 1 for invalid source 
values, to be consistent with to-dec assigning 0.0 then.

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?

You need edit permissions, and that applies to ALL tickets, not just 
yours, AFAIK. So I guess the answer is no.

On RAMBO 3942 in the fix code, in the either statement please change 
the test to empty? labels and swap the code blocks, thanks. It'll 
work the same but will be cleaner. Like this:
        either empty? labels [rule: opcode-rule] [
            label-rule: make block! length? labels

            foreach [key val] labels [insert insert tail label-rule to-lit-word 
            key '|]
            clear back tail label-rule

            label-fixup-rule: [there: label-rule (there/1: 2 + select labels 
            there/1)]

            label-error-rule: [label-rule (error/with here "Cannot use label 
            here:")]
            rule: fixup-rule
        ]

actually, it's possible that 3939 will be implemented. to-dec and 
to-int are unlikely to be used in loops, so their speed is not necessarily 
an issue.

looks like Carl's changing to-int and to-dec instead.

Integer operations:
- conversions between integers and binary and back
- bswap opcode for endian conversion

- picki and pokei, like pick and poke but for bytewise access to 
integers

- perhaps allow tuples to be treated like integers for opcode purposes, 
or to-tup/to-int for conversions between them
Word operations:
- set indirect for things like forall, 'a parameters, other uses

- for objects/contexts:  bind ["Bind a variable to a context" word! 
word!]
Struct operations:
- sets ["Set a field value of a struct" word! word! word!]
- gets ["Get a field value of a struct" word! word! word!]
- copys/changes or picks/pokes (see other group for details)

There was also some mention of a lack of orthogonality with get/set 
and copy/change (see group for details), but that may not be as important.

(note: not yet released)
-bswap already there
-tuples and pair access available (pick/poke)
-indirect words already there (setw/getw)
-change will probably take a lenght

Well yes, they could be used for that, but there are other cases 
where integers are used to store packed byte values in binary data, 
and these operations can be translated to single machine instructions 
instead of the 3+ required by their arithmetic equivalents. Carl 
will of course use his own judgement.

And integers are specificly used as part of the parse rule:
>> parse [5][5]
== false

event/key bugs with View 1.3.60 and 1.3.61

Thru seems closer semantics to skip. "To" seems to check before move 
and after move.  Which is wrong behaviour or expectations - I don't 
know.

Anton: It's same here. Function keys give strange results too. F1-console 
F2-listen F3-tcp F4-udp and so on.

then you are good. I feel older and older, that I don't sometimes 
remember, what I wanted to remember :-)

I noticed Rebol/View 1.3.60 and 1.3.61 seem to have a problem making 
routine!s with a callback! arg in them. Anybody else ?

When can we expect 1.3.2 and when 1.4 ?

if i would, you'd then quote me on that. :P and anyway, only Carl 
could possibly tell you a date.

Hello, we have got a couple of useful changes and improvements. OTOH, 
I don't know, if Jaime sees it as fit for a new release.

A little wish, but I'm unsure if  it's a reasonable idea:


WISH: Include the mezz function 'do-events in ALL rebol products, 
 of course with the exception of  rebol/base


that could made sense since all new products will include rebservices.

and would made the services-code written by the users more compatible 
between all rebol versions.

I thought that [ probe system ] hanging rebol got fixed.  I was playing 
with the new 'bind? function and discovered that a word that was 
unbound was returning the system object at which point Taskmanager 
claimed that REBOL was only using about 14MB RAM but killing the 
REBOL process freed up 400MB.  Try this:

use [this][
    that: does [this]
    this: does [print 'this]
]
probe bind? this
probe bind? 'this

1. click in the field and press Enter
2. press "change" button
3. click in the field and press Enter again.
In both cases, VALUE = "hello".

The reason is because ctx-text/edit-text calls the action block, 
but passes face/DATA  (not face/TEXT).

TEXT and DATA are related only at INIT and are not maintained by 
the access functions.

Is this a bug ?

I was making a field validator function, and it was hard to understand 
why VALUE wasn't always equal to face/text.

RAMBO it !
Accessors where made a bit to quicky OMO.

field are special case due to password input, and the accessors does 
not managed this well OMO.

Maybe looking to it and proposing correction into RAMBO would help.

It was discussed many times, and you are not the only one who think 
like this.

it shouldn't do so

 - that would require rewriting REBOL from scratch, and the result 
 would most likely be incompatible with the current REBOL.

Once a word is loaded, its in system/words and cant be aliaced anymore 
(HTH)

(Not me.)
Paul, go to a fresh console and type
>> hello
and press Enter.
Now you can see it was added to system/words:
>> last first system/words
== hello
So it is now unavailable to be used as an alias.
>> alias 'print "hello"
** Script Error: Alias word is already in use: hello
** Near: alias 'print "hello"

Apparently REBOL doesn't like set-paren!s  http://www.rebol.net/cgi-bin/rambo.r
 This is a really ugly bug that needs fixed ASAP, kills the interpreter 
no questions asked and no information given.

I just found a file that I can READ but not OPEN a port to. This 
bug can be seen on old and new versions of Core 
and View:
>> read %"/j/anton/mp3s/more/test-copy.mp3"

== {ID3^C^@^@^@^@^F^NTMED^@^@^@^D^@^@^@DIGTLEN^@^@^@^G^@^@^@472006TCON^@^@^@^E^@^@^@miscTRCK^@^@^@^B^@^@^@5TALB^@^@^@^\^@^@^@Psych
o...
>> port: open %"/j/anton/mp3s/more/test-copy.mp3"
** Access Error: Cannot open /j/anton/mp3s/more/test-copy.mp3
** Near: port: open %/j/anton/mp3s/more/test-copy.mp3
>> port: open/binary %"/j/anton/mp3s/more/test-copy.mp3"
** Access Error: Cannot open /j/anton/mp3s/more/test-copy.mp3
** Near: port: open/binary %/j/anton/mp3s/more/test-copy.mp3
>> read/binary %"/j/anton/mp3s/more/test-copy.mp3"
== #{
4944330300000000060E544D454400000004000000444947544C454E00000007
00000034373230303654434F4E000000050000006D6973635452434B0000...

I'm on WinXP. I just copied the file to a different volume and it 
can be read there.

There is a bug that is currently plaguing us though and its going 
to be difficult to corner but needs to be found.  On some systems 
then:

>> form 1.0
== "1.0"

Others:

>> form 1.0
== "1"

Actually, the latest beta acts the same on both Linux and Windows 
and uses the "1.0" form which is wrong.  Form  should return "1" 
where Mold should return "1.0"

As near as I can tell the newest version that forms decimals properly 
is 2.5.6 for windows and  2.1.1 for Linux.  I don't have access to 
a 2.5.6 version for Linux but on Windows 2.5.6 forms correctly and 
2.5.7 and every version newer that I have tested has formed decimals 
incorrectly.

Why though?  We have Mold that gives us the REBOL version and the 
name implies that it is giving us the "pretty" version of the value.

I am sure the above url is not supposed to have "icons/" in it,
and it should also have a final slash, like this:

	http://www.rebol.com/view/desktop/


The reason it hasn't shown itself is because it appears in this ANY 
block:


 any [user-prefs/desktop-url http://www.rebol.com/view/icons/desktop] 

and user-prefs is set up correctly elsewhere:

	>> user-prefs/desktop-url
	== http://www.rebol.com/view/desktop/

Will, might be better to submit a new rambo ticket to ask to remove 
the old one. Then it's not forgotten, and you know the people actually 
capable of closing the ticket will have to review it.

This situation happened to me several times when I first started. 
I would report bugs that were my caused by my own custom user.r. 
It makes you unsure and paranoid about your bug reports, so slows 
you down and maybe stops you making the bug report.

You're welcome :)

So I keep my user.r small, and if by chance it should ever be overwritten 
by a new installation of rebol in the same directory, then I haven't 
lost too much.

I posted two new tickets concerning UDP to RAMBO:
- "no-wait UDP ports and blocking COPY"
- "no-wait UDP ports and READ-IO"
I see the blocking problem as critical

nice! So we make networking layer better and better. Maybe then Gabriele 
will be able to get his Chord to work properly, as it uses UDP too?

mold-packet calls compand-packet always, and thus insert pair! .

I believe the new/unreviewed submissions have a temporary sequence 
number and it is negative.

Once the submission been checked manually and found not to be spam, 
it'll get a more permanent sequence number.

>> q: query http://www.rebol.com/index.html
== none
>> read http://www.rebol.com/
== {<html>
<head>

<META NAME="Description" CONTENT="Lightweight distributed computing, 
collaboration, and programming systems for t...

>> q: query http://www.rebol.com/asdfsa.r

** User Error: Error.  Target url: http://www.rebol.com/asdfsa.r
could not be retrieved.  Server response: HTTP/1.0
404 Not Found
** Near: q: query http://www.rebol.com/asdfsa.r
>> read http://www.rebol.com/
== ""

*but* also fixes it :)

>> q: query http://www.rebol.com/index.html
== none
>> read http://www.rebol.com/
== {<html>
<head>

<META NAME="Description" CONTENT="Lightweight distributed computing, 
collaboration, and programming systems for t...

My solution: I used SAVE and SAVE/ALL, and LOAD.

The reason I wanted to use SAVE/ALL is to save none! in a serialised 
way. So I used SAVE/ALL in one place for that, and in another place 
I used SAVE and just made sure I wasn't saving none values, so it 
wasn't a problem.

LOAD and LOAD/ALL are the same when there are multiple values in 
the block, but different when there is only one value.

LOAD and LOAD/ALL are the same when there are multiple values in 
the block, but different when there is only one value.


Exactly, and I think that is intentional, although weird and probably 
deserving some discussion.

I first thought that mold and mold/all would be the mirrored functions 
of load and load/all, but that's not the case?

I would say SAVE should mirror WRITE MOLD, and LOAD should be orthogonal 
to that.

(Or at least, that's what you kind of expect.) (and same for SAVE/ALL, 
MOLD/ALL, LOAD/ALL.)

load/all is very useful if you are loading a block of values from 
a file, eg.

	1 2 3 "Bob"


and you don't want to code for the case where the file only has one 
value in it. For example, with a file containing a single value in 
it I get:

>> load %a.txt
== 1
>> load/all %a.txt
== [1]


but in all other cases (zero or more than one value), I always get 
a block. I asked about this ages ago and the answer at the time was 
that beginners expected to be able to "load" a value without worrying 
about unwanted block creation (and those who wanted it would use 
load/all).

Yes, it all seemed to make sense at the time SAVE/ALL and LOAD/ALL 
were implemented. I remember the discussions about it. But trying 
to get a consistent method for saving/loading my data the other night 
proved very confusing. I spent a couple of hours testing different 
cases and I still haven't finished thinking about the issue.

Yes, that's what I had in mind. One way of saving and loading, where 
I can always expect the data in a particular format.

note: save/all and load/all are unrelated, and they were added at 
different times.

also, if you are using load/all, you will need mold/only/all on the 
example above. the /all in mold is unrelated to the /all in load 
and means that all values are serialized.

Ah that's very interesting !  I had the strong impression load/all 
and save/all were supposed to be orthogonal, even though I had read 
the function help for each one.

Maybe it is my failing ? Am I so stubborn to continue to try to make 
something work the way I imagined it, instead of considering that 
  maybe it just won't work that way, and to look around for the (what 
should have been) obvious alternatives ?

Hi, i just posted a new bug on rambo: When calling 'request-file 
and clicking on Cancel, the value returned is %none instead of none 
--> makes more complicated to test the returned value. I tested under 
Windows XP

Well, you are right, from the console, it is ok, but try from a script... 
I have %none and file! as as result

Is this repeatable, and clear enough for rambo?

Anyone had problems with 'switch and datatype! I've reduced the problem 
down to:

t: func [v] [
	select [
		#[datatype! integer!]	["A"]
		#[datatype! decimal!]	["B"]
		#[datatype! block!]	["C"]
	] type? v
]

>> t 1
== ["A"]
>> t 1.0
== ["B"]
>> t []
== decimal!

Unless there's an obvious explanation, I'll RAMBO it.

Why don't I get back FALSE in the 2nd and 3rd case?

For me any and all should never return false. That's my opinion.