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

World: r3wp

[!REBOL3-OLD1]

Carl
26-Oct-2009
[19178x5]
My belief has been that we are now in 2009, so binary should be fine.
Most websites don't mess up binary transfers.
Note that the header would remain clear text, UTF-8.
Pekr: I'll be back in a while to check for your reply.  I want to 
be sure that I can post my notes where they should be.  Perhaps we 
need some new group chats?
BBL
Steeve
26-Oct-2009
[19183x2]
C: I don't uderstand, 
All the modules will be transfered ? Not included in the VM ?

I thought your last post was refering to included compressed modules 
(but not loaded at the boot time)
Sh*t, he quits...
Pekr
26-Oct-2009
[19185]
Uf, new group, if you prefer, or look into !REBOL3 priorities, if 
it fits ....
Carl
26-Oct-2009
[19186x2]
S: I'm not sure what you mean. Here's the story:


There are some modules, like CGI, that do not need to be initialized 
unless needed. Those would be "bundled" into the exe, but would not 
init unless they are required.  That way, no extra space (or boot 
time) is needed for them when not used.
In addition, there are modules like Chat that are not bundled. Those 
are compressed modules, that download on demand.
Steeve
26-Oct-2009
[19188]
yep i know that, i was refering to the "bundled" ones when asking 
about compression format.
Carl
26-Oct-2009
[19189x2]
The bundled ones are currently COMPRESS MOLD/flat source. But, someday 
that will change to REBIN.
Or, should I say, compressed REBIN.
Steeve
26-Oct-2009
[19191]
ok, it's what i wanted to know
BrianH
26-Oct-2009
[19192]
The decompression would have to happen at the same point either way.
Pekr
27-Oct-2009
[19193x3]
How to further isolate following hard-crash?

limit: ["123"] parse "123" [limit]
chat
posted as #1301
5 Crash reports in last 2 days :-)
Henrik
27-Oct-2009
[19196]
about 1301: it simply hangs here. no crash.
Pekr
27-Oct-2009
[19197x3]
under Windows? Well, then I need to extend the report - crashes here 
under Vista ...
tried at least 10 times, with fresh console ...
I also am trying to simulate other crash. When there is slow network 
connection, and e.g. downloading new R3 fails, and then I Call 'chat, 
R3 crashes too ... it happened to me several times, but I can't reproduce 
it now ...
sqlab
27-Oct-2009
[19200x2]
P: With your example I get an REBOL System Error #1206: assertion 
failed 
at other lines under XP
And I opened old tickets again, that are still happening.
Pekr
27-Oct-2009
[19202]
which tickets?
sqlab
27-Oct-2009
[19203]
#0001276 and  #0000589
Pekr
27-Oct-2009
[19204]
589 Crashes on my Vista imediatelly ...
Henrik
27-Oct-2009
[19205]
A93 released
shadwolf
27-Oct-2009
[19206x5]
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.
BrianH
28-Oct-2009
[19211]
how i'm sure the modules i need are loaded when i script?
 - Use the Needs header.
Pekr
28-Oct-2009
[19212x3]
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
BrianH
28-Oct-2009
[19215]
Times are stored internally in dates as UTC, not local time. This 
helps deal with time zone changing, such as daylight savings time.
Maxim
28-Oct-2009
[19216x3]
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.
BrianH
28-Oct-2009
[19219x2]
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.
Maxim
28-Oct-2009
[19221]
aaahhh yeah... right.  humm...
BrianH
28-Oct-2009
[19222x2]
And you can get the regular time with d/time
or NOW/time
Maxim
28-Oct-2009
[19224]
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  ' :-/
Pekr
28-Oct-2009
[19225x2]
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 ;-)
Maxim
28-Oct-2009
[19227]
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.