World: r3wp

589 Crashes on my Vista imediatelly ...

A93 released

c: so the modules in rebol will works like the external libraries 
in c langagues or java ? require "thismodule" and then it works? 
but then how i'm sure the modules i need are loaded when i script?

one of the good point in rebol was anything was available anytime 
and you didn't had to care about what module is load in your context 
or not...  that was a good thing at least for people like that starts 
projet  with a bare skeleton and then feed the skeleton to make it 
grow

for example many where my projects in rebol starting without net 
or compression layer or VID those where added after hand in the flow 
of my ideas ... and needs ...

C: what are your plans for VID ? did you take some ideas comming 
from area-tc ?

hum i think i'm not posting in the right group

Carl: thank you for the parse rebuilding i didn't understoud what 
was going on with that topic, but since  parse is the foundation 
part of rebol it's nice to have if enhance and evolved once in a 
while.

how i'm sure the modules i need are loaded when i script?
 - Use the Needs header.

Nice - using R3 with an editor under Win - http://www.rebol.net/r3blogs/0284.html

Anyone with C-level knowledge being able to help here? If we don't 
resolve it, then it will stay like it is ... http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments

Result of following ticket outcome does not make sense to me, as 
most of the time user is interested in local time. It is imo confusing:

http://curecode.org/rebol3/ticket.rsp?id=1294

Times are stored internally in dates as UTC, not local time. This 
helps deal with time zone changing, such as daylight savings time.

yeah, I understand the logic... but thinking about practical usage... 
having /hour return utc times... doesn't really seem like something 
I'd use very often.

/utc is a very good idea though.

for example, writing a clock program, I'd rather just have now/hour 
to lookup than having to fiddle around with time zones.

I find that working in UTC and then converting to local on display 
is most useful, especially with server apps.

Maxim, we are talking about refinements to date values, not to the 
NOW function.

aaahhh yeah... right.  humm...

And you can get the regular time with d/time

or NOW/time

its a bit akward though... cause setting time and hour won't give 
the same results... and getting hour for a date within midnight your 
time and the UTC will cross dates and make it so that if you get 
the /hour and the /day... they actually don't match  ' :-/

I am absolutly agains it. It will confuse hell of a user. If you 
have 28-Oct-2009/20:38:01+1:00, I expect /hour to return WYSIWYG 
value. If I need the UTC time (how often actually?), I can apply 
addition of time zone ...

Carl just have choosed what is imo easier for him to implement ;-)

the /utc time is VERY usefull... I've had to deal with this in cgi 
and its not fun at all to have to manage it manually... but the discrepancy 
between /hour and /time  and the fact that the window where /hour 
and /day don't match makes this a non-trivial problem, and actually 
makes the date! type inconsitent.

Make your complaints in the ticket comments :)

I just spent two hours today googling for possible console solution, 
posted some remarks, and now I can find in CC tickets, that Carl 
is refusing to use function I proposed :-(  .... I fear we will not 
get proper console ...

I will ...  with  a nice recipe for disaster as an example  hehehe 
   ;-)

Carl wanted us to set-up new wish ticket, if we think it is wrong 
...

might as well go all the way ....

date/iso8601

Maybe Cygwin could be a use as a console for REBOL under Windows? 
Libraries like this could be used then:
http://www.astro.caltech.edu/~mcs/tecla/index.html


I can't imagine a serious developer would be ok with the default 
Win console and no history and such.

Max - have you added your ticket? I can see it as a serious problem, 
so if you don't post it, I'll do ....

Geomol, the default Windows console has history, both in terms of 
a screen buffer and command line history.

Can't the problem with the console be posted to stackoverflow? There 
might be a few Windows experts out there willing to help

maybe Carl would be too proud to let part of the implementation of 
REBOL be influenced by a stackoverflow answer :-)

Why not to look into Python, Perl, Ruby etc. sources?

we reallly need to get 'SUM into R3... its just  soooooo slow to 
sum values in a block using rebol iteration.

as in
>> SUM [ 1 2 3 4]
== 10

same for block oriented 'MIN and 'MAX

(*** As natives***)

>> MIN-OF  [ 1 2 3 4]
== 1

>> MAX-OF  [ 1 2 3 4] 
== 4

pekr, add the ticket, this way Carl will realise I'm not the only 
one with some reserves as to current implementation of new date!/hour 
accessor

Geomol, the default Windows console has history, both in terms of 
a screen buffer and command line history


Yes, I just noticed that today, when I tried under Windows. What 
exactly is the problem? The pasting of text into the console could 
be better, I think.

Max - Carl objected a bit to my ticket, so please ad your comment 
there at least :-) http://curecode.org/rebol3/ticket.rsp?id=1308&cursor=1

done.

R3 produces an syntax error, when loading Umlaut in strings, but 
shows the correct string in the error message.
e.g

>> load %test
** Syntax error: invalid "string" -- "{ö}"
** Where: transcode either if load
** Near: (line 1) {ö}


I know, the problem has to do with the unicode extensions of R3, 
but it should be at least configurable, if R3 works with unicode 
by default..

hmm, interesting. R3 scripts should be UTF-8 by default, but dunno 
if it should, or should not work ...

see why I'm not using R3 yet  ;-)

that's a little problem ...

Showing the correct character in a string might be a console font 
thing. Is %test encoded in UTF-8?

The syntax scanner has been accumulating a set of changes that need 
fixing. I would guess that Carl wants to do them all at once, since 
fixing the scanner is apparently not an easy task. It might be hand-made.