World: r3wp

Maxim, yes !

does replacing this:

dest to-image layout [origin 0x0 image (im) (size)]

by this:

dest to-image layout [origin 0x0 image im size]

do anything?

Yes, in the first case, the words IM and SIZE are sure to be evaluated 
outside the layout dialect, whereas in the second case, there is 
a fear that they might be interpreted as dialect words. They could 
be interpreted as dialect words if you added an IM style earlier 
and forgot about it, or the layout dialect was extended with an IM 
word and you didn't notice. In your little example, I see no difference, 
except that the first example could survive changes to the layout 
dialect better. I don't think the layout dialect will change much 
(in View 2.x  versions anyway).  I've been tending to write variables 
in parens, so I need to worry less about the possibility of misinterpretation.

Hmm. If I do this several times then memory is quickly exhausted:

view layout [area mold system]

I observe this slowing down and GROW-FACETS is slowly molding larger 
and larger.

repeat n 1000 [layout [area (s: mold get in svv 'grow-facets)] print 
[n length? s]]

Only now I noticed:
>> -2147483647  + -2147483648
** Math Error: Math or number overflow
** Near: -2147483647 + -2147483648
>> -2147483648  + -2147483648
== 0

I think the second one should also produce an overflow error, since 
a correct result is too large for an integer!

#3520 seems to work OK now (rebol/version == 1.3.2.3.1), so we should 
mark it as solved, shouldn't we?

aha, the add issue above is already in RAMBO as #3839 (by Jaime)

view layout [area mold system]

the text would include this  area the  next time, then include a 
text  which inlcudes the lastlast text and so on?

regarding #3520 once again:

to integer! -2147483647.9 ; == -2147483648
to integer! -2147483648 ; == -2147483648
to integer! -2147483648.1
** Math Error: Math or number overflow
** Near: to integer! -2147483648.1

sorry, to integer! -2147483647.9 ; == -2147483647

ladislav: yes, please mark it as built. (i think we could mark it 
as tested too, if everyone agrees)

and, Gabriele, what do you think about the to integer! -2147483648.1 
issue? (it may be related!)

...if I evaluate an expression supposed to yield -2147483648.0 but 
obtain a "slightly different" result, then the conversion may still 
not be possible due to the fact, that the overflow is a bit "premature" 
in this case, because -2147483648.1 actually *can* be converted to 
-2147483648 without any overflow

but because it cannot stored in a loaded block, should we allow it 
anyways?

do not understand your question

can you be more verbose?

hum... I didnt' think -2147483648  was a valid int value... sorry.

but it seems to be.

aha, now it makes sense to me

>> -2147483648  + -2147483648
== 0

this is a bad bug!

I understand the complement and the reason why this is returned (cause 
I've done C before...) but ask any novice and he'll just say this 
is nonsense!

it was marked as "medium" importance, I rised it to "high". It does 
not make sense when all other cases are caught.

-2147483648.1: i guess this should be fixed too.

I created a new RAMBO ticket

yes the internal type switch really is annoying, especially when 
you are parsing blocks and types are assigned specific values.

or rather specific meanings.

today I found small bug - well, did not know it is a bug, Cyphre 
just confirmed it - pre 2.7 Rebol versions require callback!, whereas 
2.7 version accepts only callback, but not callback! - the bug was 
probably introduced with string change for 2.7 ....

I have already posted it to Rambo.

just looking at it - it looks, that you inadvertently used the same 
line twice, should I edit it for you?

ah, my fault..please remove the #"!" in the second case, thanks ;)

done

#4227

Is there a bug in the ftp protocol?  I tried opening a different 
port viz 4559, but it still opens up on port 21.

Well, there is _at least_ one bug in the FTP protocol.  I haven't 
run into the one you are talking about, but I think I did solve the 
one that I was having a problem with (425 response from the server 
causing Rebol to wait infinitely).

opening a ftp port using the scheme: 'ftp and port: 4559 still opens 
up port 21 according to trace/net

Going to rambo this ...

Bo, I didn't see a rambo ticket for your bug, or the fix posted.

I'm still testing my fix.

perhaps you could fix mine at the same time :)

Graham - is that correct to open other than 21 port? Maybe so, but 
I never saw that ...

Yes, I've installed Hylafax which uses a modifed ftp protocol on 
port 4559.

I used 
read ftp://user:[pass-:-host]:22
and
read ftp://user:[pass-:-host]:4567
in fresh instances
and it worked

That's interesting .. it works that way, but not using [ scheme: 
'ftp port: 4559 host: 192.168.1.252 user: "user" pass: "password 
]

>> read ftp://Graham:[password-:-192-:-168-:-1-:-252]:4559
URL Parse: Graham password 192.168.1.252 4559 none none
Net-log: ["Opening" "tcp" "for" "FTP"]
Net-log: [none ["220" "230"]]

Net-log: {220 localhost.localdomain server (HylaFAX (tm) Version 
4.2.1) ready.}

which is working, but trying this ..


>> port: open [ scheme: 'ftp port: 4559 host: 192.168.1.252 user: 
"Graham" pass: "password" ]
Net-log: ["Opening" "tcp" "for" "ftp"]
Net-log: [none ["220" "230"]]
Net-log: "220 Microsoft FTP Service"
Net-log: [["USER" port/user] "331"]
Net-log: "331 Password required for Graham."
Net-log: [["PASS" port/pass] "230"]

doesn't because the MS ftp server at port 21 is answering instead

ah... graham, now i see the problem... it's port-id, not port!

port-id: 4559