AltME groups: search

That could perhaps be useful. Generally there has been some level 
of index concurrency control with multiple series missing in R2, 
like being able to do a FORALL on multiple series simultaneously. 
I can't remember if R3 solves any of that, because it's been discussed 
quite a long time ago.

FIND/all and FIND/first could save tons of time - exponential time.

created ticket #1292, addresses a few problems date!  handling of 
time.

actually... doing more tests.... I realize that the time is added 
to the date directly, not counting current time... which is actually 
proper, since I'm doing a set... not an addition.

Unfortunately, I don't have time to read back over the older messages 
(and there are many), but... I have an idea:

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)

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.

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.

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

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

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.

but having some kind of default for read/write could be usefull, 
instead of having to add a refinement all the time, and force a script 
to expect a specific encoding.

carl T___T i read your documentation and post and all when i get 
some  free time to do it..

nope... Apple doesn't want you to use flash in the browser... it 
kills their app market  :-(   
for example:

  bejeweled, one of the most successfull flash games ever, is available 
  as an app... they wouldn't want you to just play in on the net.. 


This is my only real Anger generating aspect of the iphone.   but 
this is true of just about every digital device out there... the 
provider wants to make money out of their appliances, so they control 
as much of what you can do on it, so they get a few cents every time.

its a relatively new preoccupation, because the internet forces people 
from all around the world to exchange data in real time...

Precision delta time measurements - http://www.rebol.net/r3blogs/0289.html

I haven't got time to dig in deeper right now, but remember, there 
are many MOD functions:
MOD, REMAINDER, MODULO, //
Other?

I think people are still thinking of R3 based on the situation with 
R2. With R2 if something wasn't "delivered by RT", you couldn't do 
it at all in some (lower-level) cases. This is simply not true with 
R3. R3 is not a black box, and SSL in particular would be easy to 
retrofit even if the base distribution doesn't include it. Plus, 
the pace of development of R3 is pretty fast, and any release that 
doesn't have the feature you want could be followed pretty quickly 
with a release that includes it. The only limitation is time, effort, 
and money (to buy the other two). If people don't contribute, it 
doesn't get done, period. If you want the feature, add it yourself 
or pay someone to write it. Adding it yourself will be easy in this 
case - we'll see about how easy the other method will be.

Not looking recently enough. However, your approach is counterproductive 
here. Asking for "RT" to provide this feature is not appropriate 
for a community project. What you should be asking for is contributions. 
RT's time is finite, and we have to triage features based on their 
feasibility, not just how "important" they are. The increasing proportion 
of R3 that is or will be open source is a testament to that. Every 
part of R3 that is open source is *our* responsibility, not just 
RT's.

People can say that a feature is important, but in a community project, 
in the community-created portion of that project, the way you express 
the importance of a feature is with time, effort, or the money to 
buy time and effort. As you have done with HTTP. If the community 
thinks that SSL in an important feature to have, then get to work. 
Complaining only has limited usefulness.

I also tested, that it takes equal amount of cpu time to do this 
in C, where a and b are of type double:

fmod (a, b)

or

a - floor (a / b) * b

Same can be said for integers, where we would use % in C.

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

If we think about the needing for money and time a company and a 
family needs (talking about Carl's Family and RT) I am really suprised 
to see how much work has been spent over REBOL. Sometime I even ask 
myself  how it could be possible ? Has Carl some hidden treasure 
? Has he found a way to split himself so we have 2 Carl and not one 
? :-)

Changes to high resolution time in R3 - http://www.rebol.net/r3blogs/0293.html

The type test in the argument list might be taking a little time. 
Try John's with the type spec. I'm curious to see what the difference 
is.

Most languages are going through the revamp nowadays, due to the 
Unicode and concurrency crisis, and the extent of the changes attempted 
varies from language to language.


Python 3 is on the more minimal end of the spectrum: Only Unicode 
changes, not paying attention to concurrency at all, focus on backwards 
compatibiity, no significant syntaxtic changes (the standards for 
syntax among Python devs is low), minor cleanups to its libraries. 
And it took them 3 years to do it :(


Perl 6 is on the more extreme end of the spectrum: Major changes 
in everything, including syntax, several complete system structure 
revamps going on at once, major semantics changes (not sure about 
the concurrency). Perl had an entire history of not being designed 
at all, so they had a lot of crap to get rid of. Which they replaced 
with much more new stuff (Perl doesn't know how to say No). 10+ years 
into the project, with no end in sight.


R3 started closer to the minimal end of the spectrum because we hadn't 
really been keeping track of how far behind we had gotten - not far 
behind the others, far behind our potential. As the scope of the 
changes needed became more apparent, the project rapidly went way 
towards the Perl 6 end of the spectrum. However, we had to do a couple 
restarts along the way. The current round has only been going for 
2 years, but gone way past the level of changes in Python 3, and 
has approached the level of change in Perl 6.

We had some advantages though:

- REBOL has been more designed than those others, over the years. 
That means that we are redesigining rather than designing.

- R3's primary designer is mainly into operating systems, so R3 is 
built like an OS, which makes more ambitious changes possible.

- We decided that R2 will be continue to be maintained as a separate 
project, so we don't need to stay backwards compatible.

- REBOL's design process knows how to say No, so we aren't falling 
into the Perl 6 trap.


All of these are why we have been able to accomplish so much in such 
a short time, with so little resources. It's taking a lot of time 
and effort to get the community to realize that R3 is a community 
project, so we've had to make the best use of the resources available, 
even when it meant taking some time off from developing to build 
the infrastruuctre for community development. This process work has 
paid off dramatically, so much so that comparing pace of development 
more than a year ago to that nowadays is completely irrelevant :)

Not everyone realizes that Carl has spent a long time building a 
very strong lever.... might not be pretty... but its damn straight 
;-)


now he's about to give us a chance at holding that lever as a group 
and leverage all the work.  He's been putting all the effort to putting 
the pivot of the lever (the fulcrum) as close to one end as possible... 
so R3 will be very strong and allow to do much more heavy lifting 
than R2 ever could.


now we just have to paint the lever and make it all shiny (gui) put 
a nice handle on it (the host) and even add a few more handles to 
it (threads).


most of that... we can do as as group with a few helping hands working 
together  :-)

Thanks Brian, I'll try to look up the discussions regarding DELMIT 
tonight if I have some time.

Back to my question (a long time ago :-) May I assume that the behaviour 
I wrote about in my question is a bug? A probe works, but anyhow 
the window won't move anymore.

Gabriele, be sure to post the correct url parsing code here or in 
R3 chat. We will be sure to get it integrated into R3. Or you could 
integrate it yourself if you like. If there need to be specific changes 
to the url syntax as accepted by TRANSCODE, please note them here 
or in CureCode. Proper url handling is important, and now is the 
time to fix it.

I have been thinking that urls should stay percent-encoded until 
they are decoded by DECODE-URL, so that percent-encoded characters 
won't be mistaken for syntax characters. (I don't claim this is my 
idea - I think you said it earlier, and I remember that.)


Is this approach a good one? Have you thought of any gotchas or downsides 
to this? Will this require that urls have an associated decoded version 
that would be stored as well as the character version? Do you think 
we could get away with TRANSCODE enforcing the initial rules, then 
not checking again until it comes time for DECODE-URL to be called 
(on OPEN, for instance)?

Well, I need to calm down ... I am out of this place for some time 
....

Pekr, I did this interface some time ago. It is based on a previous 
implementation from J.F. Theis, and is implemented as a TCP-IP server. 
I will certainely make out of it an extension for R3, but it can 
be already be used either with R2 or R3 as soon as you are able to 
send TCP-IP commands. See http://colineau.societeg.com/rebol/r2win151.html
. Unfortunately, it seems that the host site is down right now. If 
the shutdown persists, I will put it  in some other place.

Gabriele, every time you mention a document or code that was posted 
somewhere two years ago, without providing a link, or stating which 
AltME world the file is in (with file name/path preferably), then 
it comes across as useless complaining. If you want something done, 
say so. If you want to say that you *already did something*, prove 
it. Show me. Complaints about a time before the restart of the R3 
project aren't relevant to the current project. Live in the now :)

Carl is furiously at work putting time on the host.  a lot of unglorified 
but required time.

Gabriele, is it possible to dispatch multiple request to wiki TCP 
examples "pong" server listening on single port? It should be possible 
but for me second request is without response until the first still 
open. Your HTTP scheme is too much complicated to me as lecture reading 
:). I've tried to transform rebol.org webserver to R3, I've got response, 
but seems to me useles to serve one and one only connection at time 
when the port is asynchronous by nature. Any hint?

I decided to use REBOL to develop our system a couple of months ago, 
and everyone was against me. Now the system was done, they were surprised 
at how quickly I did this using a scripting language. They considered 
this development process a good example of the productivity of scripting 
language. They want me to talk about it in front of 400+ employees 
in the tech department. But I am too afraid to say REBOL out loud 
in front of people now. I will call REBOL "a dynamic language" in 
the tech convention. I just cannot call it REBOL. Last time I did 
this, everyone was question me.

REBOL 3 beta is coming out soon. If we want REBOL to have a new name. 
This is the right time.

I'm against changing the name for several reasons:


- The name is established. It takes years to re-establish a new name 
to gain new momentum. Carl's company name needs to change as well.

- You need to relate REBOL 2 with <new-language-name>. This requires 
effort and you'll have to waste a long time explaining this fact.

- There are already too many *-script languages out there, which 
makes AltScript less distinctive. So, is it a Javascript or Applescript 
derivative or what?

Downsides to REBOL:


- The name is overused, which is why there are people against the 
name.
- Pronounciation problem.
- Pointy-haired boss problem (REBOL? REBEL? Hackertool.)
- REBOL is sometimes confused as a COBOL or ALGOL derivative.

- Had REBOL been named AltScript in the beginning, there may not 
have been a problem, but also no distinction.

Suggestions:


- Tone down the use of the name. Use the name as for a technology 
engine, rather than something end-users will confront, like DirectX 
or OpenGL.

From time to time the topic "renaming REBOL" rises up. It is because 
we have nothing to do apart waiting for the Genius :-)

Cyphre, onmy computer  with your mandelbrot-int.r script i get :

rebol 2 VM 2.7.6.31 : 0:00:03.904
rebol 3 (2.100.95a): REBOL Elapsed 0:00:04.354   


my computer in intel core i5  750 , 4Go DDR3 1333MHz Gygabyte P55UD3 
 

so maybe you should upgrade  ( and i'm sur where i lost most of the 
time where in the consol exists)

(oh and i had a 3D game running on the computer at same time...)

and some time i havec blue screens of death when the "preview" hability 
of windows explorer file manager activates on some media files ...

in result the new system is slow and messy some time the current 
song on air is not documented ... thru the radio's website

and the ID3 will be on the song start so this would require to listen 
the stream for some time and parse it

I just don't get why REBOL is changing the LF to CRLF, but I was 
not doing network coding for a very long time.

no.. I don't have much time now.. I don't think it's warning. I can 
try to sniff real winamp communitacion later. Also we are really 
off topic here

thank you very much for your time oldes

However, it does mean that the trust model of R3's module system 
is different than that of Slim. In particular, you are supposed to 
be able to tell everything you need to know about a module from its 
loaded source, or from its header if there is no source available. 
If you don't trust the module, or if it would trounce the other modules 
you are loading, don't use it.


The R3 module system is designed for competent programmers who need 
to organize their code, but don't want to be bogged down in the beaurocratic 
overhead of maintaining import graphs in a multitasking environment. 
There is enough flexibility to help you structure your application 
as you see fit, and very little management overhead at design, development 
or run time. And it's statically determinable so a preprocessor can 
turn it all into one script with nested modules if need be.

R3 module exports import either one of two ways:

- Unnamed modules (mixins) import into the context of whatever module/script 
asked for them, redoing every time as if they were there

- Named modules import into the user context. only loading once per 
user context and then shared within it.

That last bit is the part that is affected by multitasking, since 
each task gets its own user context. Modules can manage word overriding 
explicitly in their init code, or the module/script that loads the 
modules needed by the application can manage it manually. There are 
no implicit overrides: If a word would override a already-loaded 
word, it doesn't unless you tell it to.

yep, once your IDE is setup it should compile as-is.  it did for 
me, the first time tried.

Paul, if you've got any questions, I've played around A LOT with 
the install instructions, since I now have a solutions with 3 projects 
and inter project dependencies...


its the first time I really use visual C, so it wasn't obvious to 
begin with, but I do understand most of it now.  it took me a few 
hours to get this new setup working with the host, the extensions, 
my OpenGL extension and the callback thing.

I've replaced all the paths by using the various $(...)  macros.

It is true that there are always new features that it takes a little 
time to understand the usefulness.
I'm caught regularly.

Even if I had noticed the existence of QUOTE, I saw no interest until 
the Ladislav's example.

In my machine this happen at the same point each time single client, 
but originally I've found this when I run 2 simultaneous clients 
with different large files (my was 50 and 100 MB)

The difference is that #1399 breaks even if single client is running, 
I've observed that filetransfer goes parallel even for some time 
(but not finish) when two clients was run. So the difference was 
mutual block happen after some time. (Henrik you are quicker in typing")

Henrik, I started server first, originally I've set the wait to 60 
in server to be able to start client without hassle. Only what I've 
changed else in server was make-dir to not to create temp directory 
each time the server is started. But give me some time to try it 
in other machine.

you can detach and reattach at any time.

And in the meanwhile, R3 is usable for some purposes now. More so 
with some bug fixes. It will be time to go beta soon.

btw - some time ago someone stated here, that current https scheme 
is done "old school". Was that you? Isn't now the right time to define 
the better way (if any) to aproach schemes and networking? :-)

Steeve .. don't waste your time on a r2 chat .. there's no traffic 
on there.  Spend your time on schemes :)

Ladislav has done one too. Time for a FSM battle?

Also I think that adding those five characters "/word" to your (or 
Graham's who asked initialy) code takesmuch less time than this discussion.

An old time reboler like me still gets confused hence the question 
...

It's been hard to get enough spare time with a working brain. Too 
many emergencies lately that take up my time, mostly my sleep time.

that being the case, I can just write 32,000 bytes each time there 
is a wrote event

Robert I have this issue all the time ...

uedit has no brace matching issues.  it works very well with REBOL 
and its fast enough to match braces  on very large parts of code 
in real time.

I don't have time to explore further at the moment. I'l try to do 
so later if nobody else has.

I think I'll just stick with putting a time stamp on each request 
to foil the cache

?t= url-encode form now/time/precise

That first redirection is an authentication request from google so 
it looks like you might not have been logged in to gmail at the time. 
 I used your second suggestion and that seems to work fixing the 
caching issue.  Good work!

I use apache2-MPM as a reverse proxy in front of Cheyenne for the 
same reasons (static serving, ssl), works flawlessly, but now is 
time to move to nginx. Looking at MacPorts variants for nginx, there 
are many options that I see interestings:
root/trunk/build alpha% port variants nginx
nginx has the variants:
	dav: Add WebDAV support to server
	flv: Add FLV (Flash Video) streaming support to server
	mail: Add IMAP4/POP3 mail proxy support

 ssl: Add SSL (HTTPS) support to the server, and also to the mail 
 proxy if that is enabled
	status: Add /nginx_status support to the server

 perl5: Add perl support to the server directly within nginx and call 
 perl via SSI
	realip: Using nginx as a backend
	addition: Append text to pages
	substitution: Replace text in pages

 gzip_static: Avoids compressing the same file each time it is requested

 google_perftools: Enable Google Performance Tools profiling for workers

 upload: Enable Valery Kholodkov's upload module (http://grid.net.ru/nginx/upload.en.html)
	universal: Build for multiple architectures

Warning: the scheduler integration with Cheyenne is at beta stage, 
minimaly tested, so if you want to put it in production, take the 
time to test it well.

I wasn't able to install it even to lamp one time :)

If you want to handle 10 requests at the same time, Cheyenne will 
proxify your requests to background processes (taken from the existing 
preforked pool, additional processes are started if the pool is not 
enough).

I wanted to make it easier for CGI coders to switch from Cheyenne<=>Apache. 
Using your solution would force users to add/remove the shebang line 
each time you change server (like debugging locally on Cheyenne and 
putting in production on Apache).

That requires a virtual filesystem and deep patching Cheyenne to 
use it. I've tried to make one a few months ago, but hadn't enough 
time to finish it. It's a feature I need too (but low pri currently).

Btw, in order to forge emails to be sent, I've tried to rely on REBOL's 
builtin email support functions (big mistake!). You should know that 
they *are not* RFC compliant, the biggest issues being :


- emails produces by REBOL are using LF as EOL instead of CRLF (RFC 
2822). See http://cr.yp.to/docs/smtplf.html

- headers are not encoded for non ASCII-7bits characters (RFC 2047)


So, I've deeply patched the builtin code at runtime to workaround 
this, but, I should have better rewrote it all from scratch (that's 
what I intend to do when I'll have enough free time).

a second most of the time

I don't really understand your issue about RFC .. I send email to 
gmail all the time .. it never gets rejected

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

most rfcs of that time user crlf

I'd like to test first a more robust MTA. Going to sleep now. Thanks 
for the time you took for testing.

Thanks Graham - what should I do with the first run of Tortoise? 
I suppose I better don't do Check-out? Should I create a "working 
copy"? I don't remember how I did it for Rebgui, as I am long time 
issuing Update item from the context menu. I need to do first sync 
of Cheyenne now, and would not like to screw something on the server 
side :-)

It's for Cheyenne only usage. Sending email is often required in 
web applications, setting up and maintaining a third party MTA like 
sendmail is costly and complicated. Having a MTA built in Cheyenne 
will save everyone a lot of time and troubles.

but the reduced size advantage of the pdf is disadvantaged by the 
time it takes to recreate the PDF .. ie. saving it as a jpeg is faster.

It's a uniserve service with an rsp interfaces, works pretty well, 
if something takes more than 1 millisecond to execute, better cache 
and reuse 8)
interface is simple:

.cache 'pool-name 'variable-name 'valid-time-in-seconds [code to 
execute]
one refinement, /set , will force update cache

Because you need to "refresh" the .encap.fs cache file before encapping 
by running Cheyenne in source mode at least once. This procedure 
has to be done each time the SET-CACHE spec block in %cheyenne.r 
is changed.

I use session/id as a filename to store some temporary data between 
requests. But it seems either that session/id is not that renadom 
or that a session somehow survives a long time.

I'd use it to switch debug modes in real-time... and maybe even build 
a small view config/debug pane, if I detect a view version running 
cheyenne.

View debug panel: I thought about that too a while back, never had 
time to try that concept.

Pekr: that's in my todo list, I just need to find some free time 
to think more deeply about how to support such feature efficiently.


Btw, I have built a XMLC (XML Compiler) engine inspired by enhydra 
(http://www.enhydra.org/tech/xmlc/index.html) which should fit perfectly 
your needs. It's a working prototype but need some significant work 
to be integrated within Cheyenne, so it's low priority for now.

I agree, but its mainly on initial start where it bites you the most. 
 cause when you are doing development, you'll edit the config and 
re-start the server anyways to be sure its ok.  right now its easy 
to miss... and I've lost some time debugging issues which where simply 
caused by the config not having been updated according new options 
or changed resources.

I'd need a /time refinement returning what the date of the cache 
entry is for sure.  cause many cache conditions are time based in 
remark.

can be done easly, source is in your hand , do whatever you want 
with it, sorry I have no time this week and I see no use of timestamps 
in rsp usage, but if I get at least one more same request I will 
add it 8)

you give it a time to live and a block if its expired, the block 
get executed and cache updated