AltME groups: search

Windows... the OS doesn't allow sub 15ms timing. using standard window 
events... its hard-coded in the event engine.

but really, its not a big deal what is used as long as the r3 API 
doesn't change from one OS to the other.

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

I think he means he prefers to use Syllable as his desktop OS

On the other hand, from the names as it is now, it's easy to see, 
what version is for which OS.

ah yes.. its not just region its also the os that's the problem.

I think its a message from the OS being logged by Altme.

Restoring my website at a new location.
So far just uploaded COMLib-anton
http://rolls.anton.id.au/rebol/os/windows/COMLib/index.html

OpenGL really is on every serious OS in any case, and the standard 
is very well supported, so that if you target a minimal version of 
OpenGL, your app will be pretty much the same on every OS...

I am talking Elixir OS here  :-)

I've got impression, that OGL is slowly dying, and feature lacking, 
in comparison to DirectX?


I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. 
Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API).

From http://www.opengl.org/

The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major 
update in twelve months to the most widely adopted 2D and 3D graphics 
API (application programming interface) for personal computers and 
workstations.

It seems, OpenGL is growing.

true type and the ttf lib are pretty much on all OS nowadays... its 
just a question of having the right to distribute a font with your 
apps... which in theory is the same issue with flash I would guess.

I expect Extension to be a (cool) addition to REBOL, not a replacement 
for the /Library component. Even if limited, /Library is a very useful 
and working feature of R2. /Library allows to interface with most 
of OS API without having to code in C. This is a productivity advantage.

I always thought that it was easier to write REBOL code than C code. 
Extension would require a C compiler that will generate an additional 
DLL (times the number of OS to support...). I looks to me more like 
a regression compared to R2 if /Library get trashed in R3 (unless 
someone provides a similar interfacing system). 


SWIG is huge compared to /Library. Having to provide the C header 
files is not always convenient compared to just declaring a routine! 
from online API documentations (like e.g. MSDN). I would prefer to 
keep having /Library in R3 for fast and handy OS interfacing, and 
the ability to build my own Extensions for cases where it's not enough.

There are some /Library enhancement proposals from Ladislav in wiki, 
which might make it worthwile to have. If improved, you raise number 
of libraries you can wrap, and as Doc says - very easy to use for 
occassional linkage to the OS API functions here or there ...

yes... the DLL will trigger code based on how its hooked into the 
OS.... so if you used multimedia timers, they will trigger when you 
ask them to.  if we have callbacks, then Rebol code can be run as 
a consequence of that trigger.


tcp sockets use triggers to tell you when connection, data, etc occurs... 
you could very well use C sockets directly by opening a lib and calling 
its funcs... I don't know if the fact that the rebol task already 
opens up a tcp socket lib would cause some interference, its quite 
possible that it would work.


DB drivers often use callbacks for the "response" aspect of DB requests 
since most well designed DB interfaces should be async.


Events & callbacks simply allow applications to live in the wait... 
and be asynchronous in nature.  its the "better" model since it means 
the task is never busy waiting.  There is a large effort in the linux 
world to make every app behave "properly" in this regard, and its 
a good thing... if every app is silently waiting on triggers, the 
whole system has a significant boost in responsiveness.

the OpenGL,  GLut lib, for example, has its own windowing system. 
 so any application can VERY easily create OpenGL apps which respond 
to keyboard mouse and window events.  its ported on all OS, so your 
code runs just about the same everywhere.


If R3 had callbacks, my OGL GLass engine will be ported to all platforms 
without any extra effort.


GLut might not have all the fancy events (I haven't gone over it 
in detail) but its a good basis to develop, being so easy to use.

for video, I'm not sure... it would have to use callbacks, cause 
the synchronisations and refresh stuff is so complicated.  But maybe 
we could be able to open up ActiveX or other supported OS controls 
which can render directly within window rasters, as long as the host 
code knows how to link them into their windows.

its a complete hardware abstraction, so the exact same code will 
run under any hardware/OS implementation.

jocko,  yes and no.   ;-)  


Glass is going to be rebol code only, but its going to be based on 
rebogl, the OpenGL extension I am currently working on (as I write 
this).  Rebogl its going to be an evolutionary process, starting 
with simple high-level pre-defined primitives and colors and then 
will get more and more customisable (deformers, animation, textures, 
programmable shaders, etc).


I am still not sure how the Glass engine will evolve, but there is 
a good chance that it will be based on the scene graph technology 
I am working on for the Scream game engine.  This has the benefit 
that Glass can be used to build the interfaces within the games themselves. 
 But it most definitely won't require you to load a complete  (and 
inherently complex) 3d world manager, just to build a window with 
a form.  if possible, I'd like to have window masks, so that the 
3D forms can actually live like 3d models direclty on the desktop... 
so some of the nice 3d feature isn't wrapped within an OS window 
border.

I'm in with 100USD for the os x version of /library if that is usefull 
for porting Che

It's not difficult to start; that's just a matter of doing the research 
on dynamic library loading and mocking up some code. And once extensions 
(not the host kit) are available on OS X, then the code can be tweaked 
and compiled.

You can start by going through R3 chat and helping Carl with his 
difficulties with porting the host kit and extensions to OS X.

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

Apple has two slightly incompatible ARM platforms for the iPhone 
OS alone. Even though they're both ARM, they still go Universal.

for windows, the calling conventions used by the OS seem to be pretty 
standardized and simple.  which is nice.  So far it seems to be a 
bit more sprawled for linux.


first release of the /library extension will be 32 bit only, but 
when we have a 64 bit REBOL it will be pretty easy to adapt... in 
fact, MS/intel did their homework for 64bit, it seems, and there 
is only ONE calling convention for that platform.

Oh yeah ..let's get an Os/2 build too !

( the current version of Os/2 is ecomworkstation  and is positioned 
as a secure enterprise client environemnt )

Apart from Win, OS-X, Linux, BSD, the next most important platform 
is really imo an ARM plus Android.

There's no unloading, but it's possible, however, very low on the 
todo list considering that most extensions are long-lived.  The locked 
DLL G refers to above is because the code segments are loaded. (That's 
more of an OS implementation issue, a poor one IMO.)

Graham, if it's a task (OS thread), then no, it's not blocked and 
has its own stack.

I'd build a device model for the tasks, this way it would be async. 
 just don't inlude stupid OS based limitatios like in python, where 
the thread which creates a thread, has no way of forcefull closing 
it.  so if a tread hangs.  your whole app can hang with it.  :-(

the way I see it, when a thread is launched, it should Copy the whole 
environment and become completely independent.  data exchange between 
tasks is done explicitely, and no GC allocated data should be able 
to cross thread boundaries.  obviously using external libs you may 
have some fun, but then its OS allocated and not managed by the core, 
so its your call.

As for callbacks - I surely don't understand the issue properly, 
but in overall - we are a messaging language. We should aim for message 
passing based kernel, as Amiga was, and as QNX is. Let's use events, 
ports for IPC, when appropriate ...


As for tasks - my understanding is, that Carl still plans on threads 
internally. Didn't BrianH said yesterday, that in modern/future multicore 
architectures OS tasks are better way to go?

Max - we should "copy" Amiga/QNX, and not a Python - simply put - 
REBOL uses its own OS-like advanced mechanisms - ports, devices. 
Codecs are turning back to ports too. And as for tasks and IPC, we 
should not just wrap OS, but use the REBOL way of doing things once 
again ....

this is NOT os way, its an api over a thread model which doesnt require 
the programer to know about tasks and deal with messaging, IPC, bla 
bla.


in the vast majority of cases, threads don't need to be persistent, 
and is in fact a burden to have to manage.

using OS threads is the only way we can use multiple hardware threads 
in the same application.  otherwise, they will be completely different 
processes, and that makes a BIG difference in memory consumption, 
especially on GUI Oses which open up a lot of libs on startup.

Max - I was not talking about your proposal, that sounds OK. I was 
just referring to your Python example, where it seems to be just 
simple OS wrapper ....

Each app choses its own IPC when the OS doesn't have one standard. 
 No single IPC method will be usefull.   


for REBOL itself, I do think that we should provide a construct which 
will be similar or exactly the same as what will be build for thread 
messaging.

Gregg... you're suggesting stdio pipes, right?  I'm not sure of the 
quality of their support over all platforms, but perhaps it's possible. 
 Of course, there are no easy alternatives.  IOS had IPC, and it 
was implemented differently for each OS model.  I was going to reuse 
most of that code for R3.  But, it does use sockets for posix, but 
I think they work well.

Pekr I think in port event model the only what is neccessary is open 
events to OS events (what possibly is already done, but we don't 
know how to use it), not only GUI events. Than you can use local 
pipes (managed by OS including event signalling). Question is if 
multi machines IPC would go this way. Anyway all this is solved in 
QNX (signalling abstraction local/external). Question if they use 
sockets for this.

Pavel, I pulled out my old QNX manual and it lists Messages, Ports, 
and Exeptions as their three IPC mechanisms. Messages can be sent 
on "virtual circuits" which have a node ID in addition to the task 
ID to send to; no implementation details given. Ports were like named 
pipes it seems, with 16 being numbered and reserved by the OS.

this is what carl will be adding to the next host-kit.... 


//------------------
//-    #RXV_xxx
//
// REBOL EXTENSION GET Macros
//
// provide direct RXIARG access macros
// with these macros, the single argument should be an RXIARG *
//

// this is usefull when the RXIARG is NOT being used from an argument 
frame

// but as a single value, like when we use RL_Get_Field() or RL_Get_Value()
//
// if the argument is dynamically allocated, ex:
//    RXIARG arg = OS_MAKE(sizeof(RXIARG)); 
// then use the macros like so:
//     RXV_WORD(*(arg));
//------------------
#define RXV_INT64(a)		(a.int64)
#define RXV_INT32(a)		(i32)(a.int64)
#define RXV_INTEGER(a)	(a.int64) // maps to RXT_INTEGER
#define RXV_DEC64(a)		(a.dec64)
#define RXV_DECIMAL(a)	(a.dec64) // maps to RXT_DECIMAL
#define RXV_LOGIC(a)		(a.int32a)
#define RXV_CHAR(a)		(a.int32a)
#define RXV_TIME(a)		(a.int64)
#define RXV_DATE(a)		(a.int32a)
#define RXV_WORD(a)		(a.int32a)
#define RXV_PAIR(a)		(a.pair)
#define RXV_TUPLE(a)		(a.bytes)
#define RXV_SERIES(a)		(a.series)
#define RXV_BLOCK(a)		(a.series)
#define RXV_INDEX(a)		(a.index)
#define RXV_OBJECT(a)	(a.addr)
#define RXV_MODULE(a)	(a.addr)
#define RXV_HANDLE(a)	(a.addr)
#define RXV_IMAGE(a)		(a.image)
#define RXV_GOB(a)		(a.addr)

but the true thing is windows XP have  10  years now it's more than 
deprecated OS. If the font probleme on R2 cant't be solved ok i'm 
ready to wait other year to get a R3 draw/font relation working perfectly 
everywhere. The lessons of area-tc are:

linux is the most configurable and modular OS existing ...

The OS detects the multitouch event and sends it View

For example, the primary multitouch I miss in VID on OS X is 2-finger 
scroll, but it can be packaged as a scroll event, so should map. 
 (The issues we face will also be faced by all web browsers, so we're 
in good company.)

Many recent operating systems support multitouch, including Mac OS 
X, Windows 7, Windows Vista, Windows XP Tablet PC Edition and Ubuntu 
(since version 7.10), Google's Android, Palm's webOS and Xandros. 
Application frameworks such as MT4j (Multi-touch for Java) and PyMT, 
a Python module that supports multitouch, have also been developed.

could you have gui for other os (linux and osx) now ?

I think the OS_Wait() function in Host kit could give us some answer. 
I'll try to recompile with some debug info....

BTW, the relevant code is host-device.c, line 406 and below.

*/	REBINT OS_Wait(REBCNT millisec, REBCNT res)
/*
**		Check if devices need attention, and if not, then wait.
**		The wait can be interrupted by a GUI event, otherwise
**		the timeout will wake it.

Specifically:
	// Nothing, so wait for period of time
	delta = (REBCNT)OS_Delta_Time(base, 0)/1000 + res;
	if (delta >= millisec) return 0;
	millisec -= delta;  // account for time lost above
	req.length = millisec;

in R2, the console is a window that is controled by the application. 
 in R3, for now, the console is controled by the OS.


Windows does not allow an application to be either a windows app 
or a console app.

pekr, if we have 10 GUI frameworks its a good thing.   each one adapted 
to different needs.


its also a good way to attrack new developpers.  look, this language 
has several complete GUI layers.

I'd even like someone to build a native OS GUI extension.   some 
people *require* that for their work.


RT has one it advocates directly, but any others are a boon to the 
language.

Persistent GUI state will allow an application to save its state, 
be suspended or shut down, and be restored later, all automatically 
in response to system events. Windows 7, Androis and iPhone OS 4.0 
all have facilities for triggering this kind of event in applications 
in response to power management or (for Windows 7) reboots. This 
will make it possible for us to write REBOL apps that will resume 
after an intentional shutdown by the system.

Robert - I have further questions towards "skinning", inspired by 
short chat to Rebolek .... what if different platform treat fifferently 
style behavioral aspects? I mean - drop-down under OS-X might behave 
differently from drop-down under Windows. So - it is not about having 
different color here or there. It is not about having different metrics 
to style. But it might also involve different reaction to events. 
I think that can't be solved by just "skinning". We would have to 
have differenct, platform specific stylesheets, loaded upon launch 
of the script ...

also now that Microsoft seem to be releasing a new mobile OS per 
week...

the single DLL can't imo work. It just contains language interpreter 
plus api structures on the surface imo. It means e.g. all networking 
code (simply code that does something), or OS dependant functions, 
will be in the host kit, hence I am not sure the DLL itself is much 
usefull separately ...

VID shouldn't be affected. The host-kit change with the low-level 
part: VID | VIew | Rebol Core | AGG | OS. We need to implement all 
DRAW commands yet.

for an imperatively driven system like the R3 system, you might want 
to look at how Amiga OS's BOOPSI system managed this.  its relatively 
easy to code and allows for a much more robust data interchange between 
controls.

So, this uses OS native font infrastructure.

If AGG (or R2) was relying on the OS font rendering, the behavior 
shadwolf decribed could be caused by Cleartype. If Cleartype is turned 
on, but the REBOL renderer isn't rendering with compatible antialiasing, 
fonts would look bad.

I guess you can as the key events will give you that nuicode chars 
you are typing (if your OS supports unicode) but this was not tested 
yet. I'll try it today.

And this bug is OS version specific... hard to hunt down.

Henrik - it still has to be seen ... I require all keyboard navigation 
being OS compatible - can't wait to stress test tabbing, tree-view, 
etc. :-)

this this mean that 25 years late, they actually allow the OS & apps 
to be installed in any language? like every other decent OS out there?

Area style report:


1) hilite some few chars, then you click elsewhere in the text, or 
just move the caret using arrows - the text stays hilited, whereas 
default OS behaviour is, that the hilite is discarded. The question 
is, if we are targeting for REBOL specific behaviour, e.g. allowing 
to move caret, and have multi-hilte areas? I think not.


2) hilite autoscroll works chaotically. Sometimes it scrolls the 
area, sometime it does not. Dragging the mouse outside the window 
does not work at all.


3) scroll by mouse-wheel. When I reach the "bottom" of the area, 
I loose my focus, and scrolling back up does not work


4) moving up/down by arrow. It seems that in OS native widget (Notepad), 
the caret position is counted by the follow-the-leftmost-tex-length 
rule. So if I e.g. go via an empty line, caret should stay at the 
beginning of line for all other rows.

5) cut and paste into Notepad discards newlines


6) cut and paste from Notepad inserts text in hilited form - random 
behaviour here, ot it needs more observation ...


7) hilited text should be deleled by hitting delete, backspace, or 
by typing any character

8) when hiliting the text by mouse, scroller gets reset to 100%

Is that enough bug-reporting for the starter? :-)

one pretty rare feature on illumination software creator is the hability 
to create applications for HAiku OS desktop (fork projet from beOS)

its to program a completely new OS design which was tought of 15 
years before terms like "the cloud" became buzzwords.  In this system, 
there is no concept of cloud as a difference in your day to day work 
and play.


in elixir, you are not on or in *a* cloud, the idea is that everything 
we relate to *is* a cloud.  from the button which you click on (which 
is part of the application's cloud) to the current definition of 
servers that process services.  in fact, in elixir, the button state 
of your application can become input data for ANY other node. be 
it in the app, or within a single integer variable sitting in a process 
queue on a server... its the same interface to link them than to 
create a new thread.  there are basically no differences.

ssolie - IIRC Cyphre reported here, that he has FreeType support 
done for A110, he just has to release it. That should help platforms 
like OS-X, Linux, Amiga IIRC .

ssolie: the problemyou have is that OS_GOB_To_Image() is not implemented 
in A109...You need A110 to get that functionality working.

ssolie: well, the OS_GOB_To_Image() is even not yet in 'official' 
A110. I can provide you the changes so you can merge it to your A109 
if you want.

Hmm, so OS-X behaves differently. Now what we do? Do we simulate 
each platform differently?

I expect it being possible. The question is - do we want rebol app 
to behave in OS native way, or just the same thru all platforms? 
I am for the former ....

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

I think we should categorize typical differences, such as:


- whether certain buttons are activated on mouse-down or mouse-up.

- whether a button action is activated when dragging out of a button 
and releasing.
- whether default follows tab focus.
- etc.


Then these could possibly be implemented in styles and abstracted 
away from the style as a behavioral profile for a specific OS.

But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch

I have zero experience with Android but from what I read here I can 
guess what is needed:

-R3 should be ported as native Java plugin including the agg (in 
C/C++)

-we should write Andriod OS compatible Java based application wrapper 
which will include basic app event loop, window+framebuffer management, 
networking+file IO (?)

-this Java wrapper will be able to open window, detect all the OS 
events etc. and pass it to the Rebol plugin

just reading up on syllable... neat looking os

Maxim, this is the hostlib, i.e. the OS_* functions, not the extension 
stuff.

you are missing os_to_local_path and os_to_rebol_path

it allows you to hook up alternate graphics drawing within AGG or 
directly on the window which view opens.  though you still have to 
map all that nasty OS specific windowing event stuff first.  keep 
in mind that you might be able to do stuff like a datatype viewer 
right into the view engine  :-)

in the host-kit/src there is an os folder... that is where all the 
OS/platform-specific things are supposed to be.

#ifdef where necessary, and separate files in the os/*/ trees where 
sensible.

Andreas: the code base is a mix of both single source and multi-source 
tree.


I will not allow source files to become unreadable with every other 
line being #ifdef for a different OS. Those are not maintainable.

A: The OS/dirs are for code that is really quite different.  Merging 
into a single source does not help keep it in sync, because most 
coders only modify the platform of their choice. They can just as 
easily diff.

So the Amiga is first from non mainstream OSes. Which one do we choose 
next? Any mobile OS takers here? :-)

Or BlackBerry (our company is unifying on BB in few weeks) ... but 
I don't know about BB OS much .... unless they make switch to QNX, 
it probably does not make sense, who knows ...

The BlackPad isn't even out yet, and people are only speculating 
that the new OS will be ported to the BB phones. I think you can 
afford to take your time :)

They only use the QNX kernel, not the full OS.

Yes, but not for the full OS. BB just needs the low-level stuff. 
They are providing their own user space.

Note that -b base is not useful for you (it's for me) because schemes 
are not yet init'd.  It's a bit like booting an OS without the file 
system.

not if the includes are grabbed from a network resource, such as 
when running your R3 in a VM inside another OS and the source is 
stored in that other OS.

I mean... didn't I use an OS that fit on a 512kb rom just 10 years 
ago... seems like a lifetime ago.

this aproach is like 'hey, you need the whole OS for my app, I don't 
care what you are using"

rebol in and of itself already does most of the low-level OS stuff... 
just two days ago... I used R2 as a delete function in order to polish 
a windows GCC script.  this strikes me as a similar situation where 
rebol could be used to probably replace a sizeable portion of the 
msys stuff... though it might not be as fast and optimised... that 
I do concede.

REBOL uses so little of the OS libs, we could almost have our own 
libs to replace them.  Exceptions are the TCP stack and stdio/filesystem.

Also, it should be noted, that although most developers often use 
the most recent versions of their OS, most "normal users" do  not.


Or, said another way: I have friends who run businesses that just 
support very old operating systems for very large companies... e.g. 
ATT as an example.

The goal of the current R3 build automation method is to save my 
time.


Currently, the platform table is only ~10 lines of REBOL, so it is 
difficult to beat using any other method.  And, even with the detection 
approach you mention, you need still tables.


However, that being said, if you want to create and test such a detection-based 
method and confirm it works over a range of OSes I would be happy 
to use it!  It must handle Linux, Syllable, BSD, OS X, Solaris, Windows, 
AmigaOS, Haiku, QNX, and various others, and also work for systems 
ten years old or more.

I'm open to any idea like this... as long as it saves *me* time.

Right now, the manual configuration doesn't take much time, because 
we're building only /core and /libr3... and for posix model.  Once 
more features are added, like graphics and sound, or specific OS 
support (e.g. like what Solie is doing) then we'll need to revisit 
it.