World: r3wp

as I explained to sunanda, while doing the OpenGL port I decided 
to build my C code analyzer/compiler/converter to make the process 
as complete and painless as possible...


but I've hit a wall and need a better unit testing engine to complete 
that and the OpenGL convertion.

so you're stuck ...?

What about Qt ?  Is that feasible?

I've used that before but its more pain than gain.

I'm not really stuck, i'm just building a highway instead of a small 
road... so it takes a bit more ground work.

but the result will be 3 tools instead of one... and about the same 
time to accomplish the end goal.

and then the ability to create complete C extensions for just about 
any C useable tools in a few minutes.

sounds like grandiose ideation !  :)

no its how every other platform does it.

using tools like SWIG.

I want to do it using REBOL end-to-end.

and since the C analyser has a programable emitter, you will be able 
to customize what it does.

What's the ETA for this?  Knowing that you start university this 
week ...

honestly I don't know, but its a funded project overall, so it is 
my current job.  which means it will happen for sure.


I would love to have some usefull OpenGL stuff working in february.

one reason I'm doing Sea (the C converter) is that for each new improvement 
of extensions, we will be able to update our tools with a single 
rebuild of the extension. for large libs this is going to be a big 
deal.

is the funding contingent on delivery ? :)

well, usually, you get paid to get things done.  but this is an ongoing 
project.  It also has other libraries I must import which I can't 
talk about right now, but which might be very interesting for the 
community.

As I said above I don't use imap, and am not familiar with the protocol. 
 All this does is login using auth=login and grabs the first mail 
in the Inbox
http://rebol.wik.is/Rebol3/Schemes/Imap4

I don't parse any of the message flags etc.

Ok, what do we need for imap?  ( although I suspect doing all these 
email schemes is a waste of time without ssl ) ...

for developing, stunnel will help with immediate ssl issues

ssl AFAIK is under the protocol, so even with an SSL module, the 
schema should not really change.

stunnel adds transparency ... I guess

anyone got a how to on using stunnel ?

The r2 imap protocol is pretty basic ... so I don't see that we need 
do more than that ....except perhaps allow users to pass custom commands 
to the server.

stunnel -cf -P '' -d sourceport -r targethost:targetport

thanks

-c is for client mode, i.e. so that stunnel will connect to a server

-f is so that stunnel stays in the foreground (and you see debug 
output)

-P '' is to avoid creating a pid file (dunno if that is necessary 
on win32 stunnels)
-d sourceport tells stunnel to listen on sourceport
-r targethost:targetport to forward data to this target

re imap: i don't think that much of anything is necessary for imap 
atm. once i'm satisfied with the pop protocol, adapting it to imap 
will be quick and easy

the more interesting questions would be about a satisfying user interface. 
mostly how to wrap imap folders nicely in something that feels natural 
in rebol

at present I think you have to specify the folder you want to open 
in the url for r2

Since FTP, andIMAP have folder structures, I propose that we use 
cd, ls, pwd etc for those schemes that support this.  This is no 
different to the lookup that is done by read, write, length? etc

Won't work without native changes to CHANGE-DIR, which calls the 
OS change directory function in the host code. In R3 the current 
directory is real on platforms that have a current directory (i.e. 
not WinCE), not faked like on R2.

Such changes to CHANGE-DIR could break R3 rather thoroughly.

Why?  All it does is check the port type first ...

and if it's not a file!, then check the scheme to see if there is 
an actor defined.

Um, no, ports aren';t supported at all, just file! types. You can't 
even use file:// urls.

well, still can't see that the issue is not insurmountable .. but 
we can define 'cd, 'pwd, 'ls, 'rm etc to what needs to be done.

You could redefine the file and dir schemes in the host code to a 
virtual file system. It would be easier to have the operating system 
mount the urls to the filesystem, at least on Windows, OS X and *nix.

The trick is that the file and dir schemes are defined to be relative 
to the OS current directory, so you can't separate the two.

It would break CALL too.

cd: func [ d [file! port!]
[
	either file? d [
		change-dir d
	][
		; look if supported cd method in actors, and execute it
	]
]

It doesn't matter, since the only thing about CD that matters is 
changing PWD, and PWD has to be the OS current directory for R3 to 
work. However, what "the OS current directory" means is defined in 
the host code.

rebol doesn't seem to have a concept of a currernt directory as in 
windows ... where you can keep a directory for each volume mounted

You are thinking R2. R3 does have a current directory.

The only thing about PWD that matters at all is relative filenames, 
and those are handled by native code, not mezzanine. But most of 
that native code is in the host since it's platform-specific.

Afaik, the R3 current directory is process-specific and is only one, 
not one per drive.

http://rebol.wik.is/Rebol3/Schemes/Imap4
Updated to version 0.0.2 
Logs into Imap server using cram-md5 if available
Switches to inbox
gets inbox status for unseen messages
Retrieves the first 3 messages

As Andreas notes, a write to the port inside the awake handler is 
fine .. but outside the handler, you have to do a wait on the port 
to do anything.

Also i found that without using a timeout value, it doesn't work 
for me 

So, I removed the 'read cmdport from write-cmdport function, and 
put the wait instead in the actor 'read ...

with a timeout