r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

PeterWood
18-Jan-2007
[6766x3]
Ladislav: -16:00 to +15:45 is more than enough according to Wikipedia


Because the earliest and latest time zones are 26 hours apart, any 
given calendar date exists at some point on the globe for 50 hours. 
For example, April 11 begins in time zone UTC+14 at 10:00 UTC April 
10, and ends in time zone UTC-12 at 12:00 UTC April 12.

Full story at http://en.wikipedia.org/wiki/Timezones
And a list of all the current (and a few old ones) at http://en.wikipedia.org/wiki/UTC%2B0
UTC-0:25 was used in Ireland as Dublin Mean Time. In 1916 the time 
was changed to GMT. (Thankfully!)
Ladislav
18-Jan-2007
[6769]
:-D
Oldes
19-Jan-2007
[6770]
I have a question, I have this code:

>> b: "1234str" ri: func[b /local i][i: copy/part b 4 b: skip b 4 
i] probe ri b probe b
1234
1234str
Why the b string is not "str" ?
Cyphre
19-Jan-2007
[6771]
Here is the explanation:
>> a: "1234"
== "1234"
>> b: a
== "1234"
>> b: skip b 2
== "34"
>> a
== "1234"
>> b
== "34"
>>
Ladislav
19-Jan-2007
[6772x3]
...because the index attribute of REBOL series is not volatile.
Cyphre - I doubt this explains it
correction : the index attribute of REBOL any-blocks and any-strings 
is not volatile
Oldes
19-Jan-2007
[6775]
Ok, so how should I write the code, which will eat the 4 chars and 
change the position if I don't want to return the new b from the 
function
Ladislav
19-Jan-2007
[6776]
as I said: you cannot change the index of a series, so the only possibility 
is to share the variable
Cyphre
19-Jan-2007
[6777]
Ladislav, I though the 'b in function 'ri is different from the 'b 
in global context so that's why the index differs.
Ladislav
19-Jan-2007
[6778]
actually the error lies in the fact, that many users think, that 
SKIP changes the index of a series. It actually doesn't:

b: "1234"
index? skip b 2 ; == 3
index? b ; == 1
Oldes
19-Jan-2007
[6779]
but than it's quite useless... I wanted to do a function read-integer 
buffer and etc. and make it universal:( 

I know, I can set buffer as global variable (or in the context) and 
do just read-integer etc.
Ladislav
19-Jan-2007
[6780x3]
you don't have to, the following works too:
ri: func [b [word!] /local i] [i: copy/part get b 4 set b skip get 
b 4 i]
b: "1234str" probe ri 'b
Oldes
19-Jan-2007
[6783]
yes, that's it, thanks:-)
Ladislav
19-Jan-2007
[6784]
sorry, Cyphre, it looks that my explanation is exactly the same as 
yours :-)
Oldes
19-Jan-2007
[6785x2]
anyway, it looks, it would be better to use some version with the 
buffer as variable in the context:(
isn't it too many operations to just get a string?
read-str: func[b [word!] /local s nb][
	s: none
	nb: get b
	error? try [
		i: index? nb
		s: copy/part nb i: (index? find nb #{00}) - i
		set b skip nb (i + 1)
	]
	s
]
PeterWood
19-Jan-2007
[6787x2]
If by '"eat " you mean permanently remove then :

b: remove/part b 4
As a function:

>> b: "1234str"
== "1234str"
>> ri: func[b] [b: remove/part b 4]
>> probe ri b
str
== "str"
>> probe head b
str
Oldes
19-Jan-2007
[6789]
rather not to remove, just skip:-)
Anton
19-Jan-2007
[6790]
Oldes, you don't need to 
	s: none

S is a local and locals are automatically set to NONE for you. (Unless 
you are using a very old rebol.)
Oldes
19-Jan-2007
[6791]
that's true:-)
Anton
19-Jan-2007
[6792x3]
This is how I would do it.
read-str: func[buf [word!] /local result pos][
	if pos: find get buf #{00} [
		result: copy/part get buf pos
		set buf next pos
	]
	result
]
>> my-string: #{11221122003344334400}
== #{11221122003344334400}
>> print mold read-str 'my-string
#{11221122}
>> print mold my-string
#{3344334400}
>> print mold read-str 'my-string
#{33443344}
>> print mold my-string
#{}
Oldes
19-Jan-2007
[6795]
That looks much more better, thanks:-)
Ladislav
20-Jan-2007
[6796]
add 0.0.1 0.0.255 ; == 0.0.255 looks rather surprising to me. any 
opinions?
Volker
20-Jan-2007
[6797]
makes  sense when used with colors
Ladislav
20-Jan-2007
[6798]
aha, thanks
Volker
20-Jan-2007
[6799x2]
>> 10.10.10 * 1.5
== 15.15.15
>> green
== 0.255.0
>> green / 2
== 0.127.0
>> green * 0.3
== 0.76.0
tuple * float works :)
xavier
20-Jan-2007
[6801x2]
it also work in this way :
 divide 0.15.0 2
== 0.7.0
this kind of stuff could be very interesting in imagery ... thanks 
for you reflexion
Bo
20-Jan-2007
[6803x5]
I have an interesting problem with FTP.  I'm using FileZilla on my 
server and I get the following entry in the log file:
(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> 150 Opening data 
channel for directory list

(000032) 1/20/2007 9:16:58 AM - lechnowsky (*IP*)> 425 Can't open 
data connection
(000032) 1/20/2007 9:56:52 AM - lechnowsky (*IP*)> disconnected
During that same period, Rebol's trace/net states the following:

Net-log: ["LIST" ["150" "125"]]
Net-log: '"150 Opening data channel for directory list."
Rebol, never returns from that.  It seems to be a bug in Rebol's 
FTP handler as it doesn't ever time out and continue, it just locks 
up.  I have to press "Escape" to get out of it.  I've left it for 
up to 12 hours and it still doesn't return.
Any ideas?
Henrik
20-Jan-2007
[6808]
are you using the latest version 1.3.2 of rebol? I think there are 
some serious patches to FTP somewhere, but I can't remember if they 
made it official.
Bo
20-Jan-2007
[6809]
I'm using the SDK and I'm including sdk-2-6-2/source/prot.r which 
should have the FTP protocol in it.  Does anyone know if there is 
a newer version of prot.r other than sdk-2-6-2?
Graham
20-Jan-2007
[6810x3]
that's the latest
I presume that the problem is just with the one server?
I think all of Romano's patches http://www.rebol.it/~romano/ftp-patch.r
were incorporated already.
Bo
20-Jan-2007
[6813x3]
Well, I haven't tried it with a different FTP server, but it definitely 
appears the problem is on the Rebol side.
I've considered installing WarFTPd or something, but this is a production 
server and I don't want to mess anything up by having two FTPd's 
installed simultaneously.
I'm not even sure it is an FTP issue.  The timeout should be triggered 
by Rebol's networking kernel, shouldn't it?