AltME groups: search

Back again.  Thank you Andreas,


I had realized that FILE! was used for both directory and files, 
but I didn't realize that REQUEST-DIR was NOT sending it back as 
a directory, but as a file (without trailing slash).  I was able 
to confirm by adding a print of WHAT-DIR and INP-DIR and compare, 
as per your comments.

I did not know about DIRIZE


Using READ DIRIZE INP-DIR does fix the problem -- though I wonder 
if REQUEST-DIR should return it with a trailing slash?

Thanks again to all!

I understand your view Max, but that's not what I asked. It doesn't 
work the way you want today, but maybe there's a way to provide a 
solution that is better than what we have now. I'd love to see your 
custom version, so we can compare its results. And I'm asking about 
SPLIT-AT for a reason, separate from SPLIT-PATH. I'd love to get 
everyone's thoughts.


The funny thing is how much we can all care about the details of 
this func we (at least I) use a lot, and yet which none of us seem 
to like all that much. I think it points out that the normal case 
is the most important, where there is both a path and a file component. 
And maybe now is the time that we can make it just a little bit better, 
a little more consistent.

colin, perhaps it would fit with a deployment scenario. compare installing 
visual studio in 40 minutes to just clicking an .exe file from a 
network share to install your rebol/services enabled source management 
client plus integrated texteditor in four seconds.

Is this a bug?

1)  I read a directory on our ftp server and return a set of files 
of which  02 EN AR final.pdf is one of them

2)  I then copy a URL address that returns a 404 indicating it couldn't 
find the file in question ie.  http://www.cpcpension.com/files/2002EN AR final.pdf

3)  I do a  split-paths to-url on the contents of the clipboard:// 
that contains item in step 2)

4)  I compare the file names for equality either using "=" or equal? 
and both return false
5)  I check the type of each file, they are both 'file' types

6)  I check the length of each file, the one from step 1) returns 
20, step 2) returns 26


So, somewhere it is changing the   representation of a space into 
the actual string " ".
Any ideas?
6)

This needs 'foreach-file from rebol.org

>> include %foreach-file.r
>> out: copy [] ff: func [file][repend out [file modified? file]]
>> foreach-file %./ :ff

== [%./!/basics_wide_desktop_computer_system.xml.ttx 21-Jun-2006/16:05+1:00 
%./!/basi
cs_wide_hard_disk_drive.xml.ttx 21-Jun-2006/8:...
>> sort/skip/compare out 2 2

== [%./ft/wavs/balloon.wav 23-Aug-2001/13:00+1:00 %./ft/wavs/down.wav 
23-Aug-2001/13:
00+1:00 %./ft/wavs/error.wav 23-Aug-2001/13:00...

I get whats happening now.  If i compare buffer and file I see the 
clipped text:

>> probe file
== "index.html"

>> probe buffer
{GET /a.html HTTP/1.1
Host: localhost

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/531.21.8 
(KHTML, like Gecko) Version/4.0.4 Safar
i/531.21.10

Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Connection: keep-alive
Address: 127.0.0.1}

>>probe parse buffer ["get" ["http" | "/ " | copy file to " "]]
== false

>> probe file
== "/a.html"
 
Should I have been able to see the results instead of  == false?

how does syllable desktop compare as a multi-user file server?

Chris: from what I see, it does not. Either the file has to be transfered 
and saved on the server with unix-style line enders or -q has to 
be there to make it work for me. Time will tell. Unfortunately I 
don't have a linux machine to download and compare.... Can you say 
"Heisenberg Uncertainty Principle"? :-) Anway, what works, works. 
I'll post more on this subject when I actually get back to programming. 
thanks.

It seems the problem is after the PORT command.

It  define the port used to receive or send the file data (depending 
the command you issue).

Use Wireshark to have a look to what Total commander do regarding 
its PORT command.
So we can compare with the Rebol commands.


I guess the router firewall block the one Rebol use, but Total commander 
do it in an over way.

By "for comparison purposes", I mean don't change the file date, 
just subtract the diff between you and UTC to get the adjusted file 
date in memory and then compare against the adjusted file date from 
the server.

Three problems with them:


1) The widget engine is a hefty 12MB or so download (for widgets 
that are nothing other than HTML+CSS+Javascript+Images bundled in 
a zip file with a magic extension)

2) The download/installation process tries repeatedly to high-jack 
your browser preferences

3) The widgets look pretty ordinary compared to the OS X dashboard 
equivalents (go here, http://www.apple.com/downloads/dashboard/and 
compare the respective dictionary/thesaurus offerings)

Look and compare Windows XP to Windows Vista - have you looked e.g. 
at file requestor? It is FUNDAMENTALLY diffeent, more like different 
OS to different OS ....

The browser as the launch platform for applications has always been 
an interesting idea. The fundamental problem of the sheer complexity 
of it can be solved with R3. If done right, it can completely wipe 
the floor with browsers and AJAX. I think the problem is that we 
haven't been speaking in a language that people can understand, such 
as "browser", "web2.0" and "webserver", but instead "dialects", "VID", 
"Viewtop" and "X Internet" and people go "huh?".

Some things I believe are needed to do this right:


- Browser form factor. People are used to browsers, not Viewtops. 
What's always the first thing a complete newbie computer user uses, 
when wanting to do anything on the internet? A webbrowser. I don't 
want a desktop inside my desktop. There are tens of solutions for 
such things and they are almost all forgotten. Carl is doing the 
REBOL browser. When you fire up R3, you will get what looks like 
a webbrowser and acts like one. The concept has to work equally well 
for people like us, as well as 5-year-olds and 95-year-olds.


- Do apps that are similar to webapps, like GMail. That's a quick 
way to compare. Don't you think a 50k GMail look-a-like inside a 
REBOL browser running at native speeds would be _slightly_ impressive? 
Remember to say that you can serve 5 times more users with the same 
bandwidth. REBOL can help make raw numbers look better without much 
effort. Google would have to use it as a content platform. They have 
no other choice. :-) Chrome? What's that?


- Plugins suddenly are very flexible. You don't have plugins as in 
Firefox, but helper scripts that can enhance/change your browsing 
experience. 15k full screen document reader that prettifies plain 
text files? Sure thing. Blog posts presented in that would be much 
nicer to read. Out goes the PDF reader.


- Do apps that are completely out of the league of AJAX, such as 
multithreaded P2P systems. In fact, why not build P2P capabilities 
right in? Have different instances of the browser allow users to 
connect and chat, when they are visiting the same "Rebsite". It's 
sort of like going into a physical store and chatting with the other 
customers and you decide to exchange business cards. Initial contact 
without needing email. Do the same thing with chat support for an 
article that you bought at that  "rebsite". Current websites are 
almost completely anonymous. You don't feel you are entering a live 
community. Coded in REBOL/Services.


- Webpages are now REBOL scripts. In R3, scripts can be closed and 
encrypted, so you can't read the source and you can sell scripts 
and have them signed. The best you can do right now is some kind 
of code obfuscation.

- Windows, MacOSX and Linux version.


- "A webbrowser that directly supports OpenGL without obscure/limited 
3rd party plugins." Say that again in your head.


- It's very important that the public get to see that creating REBOL 
scripts for the browser is very similar to creating plain HTML pages. 
REBOL scripts can be served off a plain webserver. All the infrastructure 
is already there. Or how about serving scripts from the browser itself? 
AltME can both be a client and a server. It's that P2P thing again.

- Browser would run wherever R3 runs.


- Market it as Web 4.0. Market it as a direct competition to current 
webbrowsing.


- Browser would be a 500-600 kb downloadable exe that starts immediately 
without installation. From deciding to get it, to be using it to 
browse "Rebpages", it should not take more than 30-45 seconds.

- We need AltME in that browser (Altissimo?) as well as QTask.

For developers:


- It's easy to create an HTML file in notepad and display it in your 
favourite browser. It's going to be equally easy to create a REBOL 
script in notepad and see it running in your REBOL browser. A 5-year-old 
who has just learned to type, should be able to create a script and 
display it.

- One language for everything.


- Everything is free. You can start out with notepad. The barrier 
for creating content is about as low as it can get.


- You wanna code slow web 2.0 apps or fast web 4.0 apps? Hard choice, 
I know.

If I want to keep local versions to compare to I keep them in another 
directory, then compare to the changes made by others. I only need 
to do this when I am working on the same file that others are working 
on, usually a sign that there is too much in the file (it needs to 
be broken up), or that I need to do a better job of talking to the 
other person.

Pekr: no problem. Cheyenne is one of the application that would benefit 
the most from threads.


IPC between processes can't compare to shared memory between threads. 
With processes, you need to serialize values, transfer them (multiple 
memory copies or worth using a disk file), then LOAD them back. With 
shared memory, you just pass a memory reference to the value and 
you ensure (using a sync mechanism) that no concurrent writes occur 
on that value. It's at least a magnitude faster and uses so much 
less memory.

Good reasons, and I agree, the best way to do this.
We nee da universal XML export import with ID compare.  



In other words, CureCode needs to be able to export itself as XML 
(Easy).
It needs to import XML (Easy)


It needs to import XML and update the old XML keying on some ID value. 
 Not so easy.


Once done, building things like RSS feeds with just the top 10 recent 
changes becomes easy.


Also, then we can sync Qtask and CureCode.  There are a lot of cool 
side effects though…


-	We have an integrated file share, so you can link to screen shots.
-	Qtask has the ability to have conversation about each issue.
-	You can throw your issues onto a calendar view.


I know this is not your concern right now, but this is the direction 
we are going in, and need to learn how to best allow this type of 
integration.  Much as you have made one thing to test another, we 
have the same problem constantly.

Each day I get an rsp error in the head.rsp file:
** Script Error : Invalid argument: 2 
	** Where: rsp-script 
	** Near:  [foreach [id prj] head sort/skip/compare skip]

I am running Cheyenne and Curecode on a server at home and then have 
another PC as my normal workstation. So each day when I go to Curecode, 
it throws this error. All I have to do to fix it is to go to the 
server, refresh the curecode page from there and it works on the 
remote machine again. 
Anyone else seen this and have a fix?

The R3 process needs to be able to save the %user.r file with the 
current user's permissions in order to allow the user to save their 
preferences. And we don't have a safe place to store the checksum 
of that file to compare against, without also making that checksum 
writeable by the user. That means that the checksum security can't 
be used for %user.r.

prefix? and suffix? just return true if a series starts with the 
same items in the same order as the second one.  
the second argument is the prefix to compare

so you can easily do:

unless suffix? file-name %.png [append file-name %.png]