AltME groups: search

doing an OS (file content) search in the altme directory usually 
is easier and faster too.

Welcome to an OS with two clipboards :(

I think they're each interpreting text according to their own native 
character set. Windows in UTF-16, OS X and Linux probably in UTF-8. 
AltME doesn't compensate

Yes, AltME simply ignores character encoding.It simply regurgitates 
the text it receives from the client. I believe that REBOL/View uses 
the default codepage under Windows(not utf-16) and MacRoman under 
OS/X. I suspect it uses ISO-8859-1 under Linux but am not sure.

Ashley that overcomes the 'newline" issue with pasting OS X text 
(\n newlines) into AltME which uses MacRoman (\r newlines) but I 
don't think that it overcomes the charcter encoding issues.

can't anyone shake that area and put rebol in it ....  something 
like a rebol os-commerce all strong and mighty in 200Ko ... Ok you 
can go to 2Mo last limit... lol

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

You can use debug/* logging functions, but they will only log in 
%trace.log file. Writing directly to a log file from RSP script is 
unsafe (unless you take great care about concurrent accesses). So, 
if you want to have custom logs from RSP scripts, you should use 
the OS syslog service for a really realiable solution. The debug/* 
log functions use their own solution for serializing disk writes, 
they are passing data to Cheyenne main process that does the writings 
to disk.

It could be possible to extend debug object to handle an /info refinement 
that would log to an %info.log file, but that would put some burden 
on Cheyenne main process when in production. I thought about writing 
an OS logging service wrapper, but never found the time for that. 
I usually do all my writings from webapps into databases that are 
able to handle concurrent accesses reliably (so, not sqlite).

Altme is a slow UI? Just don't make me laugh, those who claim so. 
Have you tried Azureus? That's Java. Altme just runs ok. We all know, 
that the UI is not OS compatible, so there are things to be desired. 
And altme server can run for months without a restart.

Doc: I've solved "Cheyenne cannot be installed as a service on Windows 
2003 Server" problem.

service.dll requires msvcr71.dll to run, if not present Cheyenne 
crashes with "** Access Error: Cannot open service.dll as library" 
error.

msvcr71.dll file should be present in same folder with service.dll 
or better it should be in %windir%\system32 (or the correct path 
if 64bit OS)
I think we should note this dependency somewhere on the web site.

my use for this is to replace VID, for Elixir OS.  which is a fully 
3 dimensional interface design.

Although I can only guess, I think the issue lies in that the actual 
os calls being used do not provide greater precision.


In R3 there are other means to get the time which do provide much 
greater precision, so its strange that they do not also apply to 
now/precise.

even in R2, when you look at an event! object, the timing counter 
within is much more precise than now/precise...  which is why I can 
use mouse move events to check time elapsed much more precisely than 
the mediocre 'time event generating, OS timer which /view is using.

Script: "Time-block" (31-May-2010/11:01:46+2:00)

 Warning: clock tick too short, the result is the loop body execution 
 time!
== 2.09338521400778E-6

Rebol 2.7.5 on Mac OS X 10.64 bit

Isn't it OS-dependent? BSD&OSX value seems to be about 2E-6, while 
Linux is around 2E-5 .

This entry at Wikipedia seems to suggest that is it OS dependent 
- http://en.wikipedia.org/wiki/System_time#Operating_systems

What initially surprised me was that there did not appear to be a 
significant difference bewteen OS X (native) and XP(VM) with  time-block[now/precise] 
0,05

That certainly doesn't suggest that OS X system calls are faster 
than Windows ones.

I was less surprised that XP(VM) performed time-block [ ] 0,05 about 
1.6 times faster than under OS X (Native) as I suspect that Carl 
is more likely to have better  optimised Rebol on Windows than other 
systems.

I have a huge graphical application written in R2 (Canvas RPaint, 
close to 13'000 lines of code), that I can't get released because 
of host problems and differences in REBOL between OSs. I do much 
of my development under OS X, and I have lots of utilities and applications 
written in R2, that suffer from problems in REBOL/View, that I might 
be able to solve, if the host code was released. I have tried to 
look into the graphical part of R3, but I can't see, how I'm able 
to convert my code to R3.


(I'm sorry to say so, but R3 to me looks like a hobby project, not 
a serious business projekt.)

It's interesting, that the difference is large when running under 
OS X, and just a few percent when running Windows.

I ran the calculation test under Windows/XP using VirtualBox. It 
took 5.009 seconds compared to 5.575825 seconds run natively under 
Mac OS X.

I also ran the calculation test with R2 under Windows/XP using Virtual 
Box it took 4.368 seconds.


As native R2 on Mac OS X is faster than Windows R2 running under 
emulation, it looks as though the issue is the that the code is yet 
to be optimised.

I remember writing a program many years ago on my Amiga, that would 
change the input to what I choosed using a simple lookup table. I 
used it to write fast in e.g. IRC, where I would make a table with 
the 3 first letters of many english words. When I wrote 3 letters 
and pressed space, it would write the full word. Could be used to 
change things like !did to didn't. The good thing with the Amiga 
was, I connected to the console device (or what it was called), so 
the program worked everwhere with all other programs using the OS. 
Could also be used to e.g. program fast using shortcuts for command 
words.

llvm is a compiler.  its not an OS service.

mesa3D is using it in their driver engine to convert graphic calls 
to any GPU instructions... on the fly.  implementing a driver becomes 
just a question of providing LLVM instruction maps... although not 
trivial... still much simpler than having to go from HW to OS in 
a single driver  ;-D

Cyphre has reported compiling on code::blocks (don't know what OS)

Guys, there's a trouble with OS-X or so it seems. Any experienced 
OS-X coder to help? Message from Carl on R3 Chat:


I must set OS X on the back burner... I've wasted far too much time 
on it.

There are three choices on it:
1. find a tool that does what 
I need
2. make a tool that does what I need
3. join all the sources 
into one large .c compile

Note that gcc -fvisibility=hidden does 
not work, nor does __private_extern__ wor
k either.

I've got to 
get on with other projects now. So, if you happen to find the soluti
on, 
let me know. (PS, yes, using GCC > 4.0.)

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

Offered by:
	TomBon
Task:

 R3 - Bindings for libcurl - the multiprotocol file transfer library
	http://curl.haxx.se/libcurl/

	C - API  -> http://curl.haxx.se/libcurl/c/allfuncs.html


  libcurl is a free and easy-to-use client-side URL transfer library, 

 supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, 

 LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET 

 and TFTP. libcurl supports SSL certificates, HTTP POST, HTTP PUT, 

 FTP uploading, HTTP form based upload, proxies, cookies, user+password 

 authentication (Basic, Digest, NTLM, Negotiate, Kerberos), file transfer 
	resume, http proxy tunneling and more!


 libcurl is highly portable, it builds and works identically on numerous 
 platforms, 

 including Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, 
 AIX, Tru64, Linux, 

 UnixWare, HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, 
 OpenVMS, RISC OS, 
	Novell NetWare, DOS and more... 

Amount:
	$150
Valid until:
	01.11.2010
Terms:
	PayPal

I think that is the role of the host.  people with experience in 
OS specific console code should adapt their host code to use it.

Anway, we can go the custom route on the console.  But, we'll need 
help with that on Linux (whatever desktop) and OS X, etc.

M: ran into holiday schedule on OS X libs.

I guess there needs to be a formal limit to what RT does and what 
community should do. It can't be expected that RT would maintain 
console support on an obscure OS. OTOH you might expect HTTP to work 
as a result of RT work or someone close to RT.

And one maintainer per OS platform.

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.

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

so the bootp is for a rebol os ?

having played with customizing the extension kit by merging some 
of the extension code into (on my own)... and building a generic 
call-back system for R3, I can see how it was a bit of a pain when 
Carl extracted View out of the core and put into an extension.  its 
not a trivial task and there are one or two things missing which 
where probably added to the last host kit and extension package to 
fill the gaps.


for one thing, Carl must have had to unify the source files and possibly 
re-organise a bit of the includes.  this is the kind of work that 
is tricky, painfull and extremely bug prone... with ZERO gratification. 
 it just craps out over and over, until you resolve all the dependencies, 
bugs, missing links and figure out how to re-organize code until 
the make tree "works".  


if it where just one OS/compiler it wouldn't be that bad for such 
a fluent C coder like Carl, but having to support ALL of them in 
a consistent way is very painfull and usually laborious.

I was trying to download Rebol3 on Mac OS X today and I was not able 
to. Is there an updated alpha for R3?

Time ago I have written about porting REBOL3 to the .NET platform 
and Java VM.

The reason ? There is a big universe of libraries and frameworks 
immediately usable that would bring many developers to the REBOL 
platform.

Considering .NET and JAVA VM as alternate OS to develop REBOL3 for 
would be a big step forward to me.

So, as for .NET - you mostly talk Windows. And there is no standalone 
.NET system - it is just layer upon OS, being it Windows, or Linux 
(Mono). And we have R3 for those two OSes awailable. So - why to 
slow-down REBOL, coding it in pure .NET, instead of doing integration 
work?

I noticed, in Carl's prepared implementation plan, that there is 
item stating: Boot directly into R3 (min OS)

A97 released for Windows and OS-X with over 40 fixes. Can't be reached 
by 'upgrade function though, probably due to website changes. You 
can find it here: http://www.rebol.com/r3/downloads.html

I hope there's going to be an a97 release for OS X Intel ...

Right. Case-sensitive filesystems aren't portable to the main client 
OS'es, or even all server OS'es.

I tried the chat then demo trick under linux and Rebol crashed with 
a segmentation fault. Normally, the demo gives a script error. I 
also tried on Mac OS X but that was okay - the demo gave a script 
error.

We should do a poll of what OS everyone is using.  Seems to me odd 
to release two OSX builds and no Linux

i was reading doc about moblin now meegoo os and i was stunned to 
learn all their gui where based uppon QT  &and ...

and rebol would be the perfect match  for a light weight extensive 
os like meegoo more the  time pass and more the oportunities to make 
rebol find it's way out are wasted  one after other

not sure how easy it will be in linux, but on windows, exe and dlls 
actually are the same thing.  the os, just doesn't run main() on 
a dll.

I think not necessarily. R2 supported proxies (at least some proxies) 
too. There was an idea to have networking protocols use OS specific 
layers. That would still be imo a possibility.

but yes brianh you got the point when you relay on hardware then 
you have to choose what technology you support i know rebol main 
target is to be hardware / OS / driver abstracted .. but then you 
have a toy language anyone laught about that  can't bring anyway 
the same thing on every OS computer a part some very basic features 
like networking, encryption etc...

maybe a good comparation is my netbook ...  ok on my netbook i have 
3 os i have mister windows 7 starter edition  wich use so much mu 
cpu that the bettery life is cut by 2

very strange.. I guess it's because of OS, hardware etc.
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:15.048
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:11.11
for 10.000.000 times.

whether people are running a 64 bit OS is a different matter

http://www.zdnet.com/blog/btl/android-poised-to-be-no-2-smartphone-os-worldwide/37976?tag=nl.e589


Android jumps from 1.8% market share to 17% ahead of Apple.  Someone 
got a spare Android phone for Carl/?

However, it makes more sense to target the OS most used by developers

the codebase is really rather small. src/os/, the hostkit "core", 
has ~9k lines (wc -l).

I'm not sure it's particularly large. It seems that just interfacing 
is very difficult:


The difficulty is not inherent in the design requirements... it's 
because stdio methods are very old (as old as modern computing) and 
have been messed with (inside the OS) for such a long time.

Thanks. Found this: http://anton.wildit.net.au/rebol/os/windows/COMLib/

Have we had REBOL 3 for 64-bit OS yet?

I ran out of memory using R3 because of a huge map!. I was doing 
a Chinese social-network-graph analysis. If R3 supports 64-bit OS, 
I will have the 64-bit HW, 64-bit OS, and 8 GB RAM  ready. Too much 
data to analysize, too less memory.

Actually, Sharp phone using our Tapas OS (which is based on Android) 
is shipping in China. (http://www.udeek.com/archives/628) I hope 
that R3 with View can be port to android soon.

https://github.com/carls/R3A110/blob/master/src/os/posix/dev-file.c#L357

usually it will depend on disk fragmentation.  I'm not sure all OS 
allow you to force a contiguous disk area. 

on any OSes which allow it, it could be a good suggestion for R3.

Are you doing those measurements in a fresh console each time? Remember, 
process allocation from the OS matters too.

Particularly on OSX (or Windows 7/Vista), since the OS itself uses 
a lot of RAM.

On my system it had to allocate virtual memory for the process from 
the OS, and swap memory in RAM to the VM so it would have room to 
allocate the map in the working RAM. It took as long as I would have 
expected it to take given that circumstance.

The OS and other apps are also resident. Anything over 512MB would 
push things on a 2GB system running OSX.. I wish my main system was 
running - it has 4GB, which is plenty even on Win7.

A considerable part of that is needed by the OS for its kernel space. 
2 GB is a bit low for that limit on the main OSes, but it makes you 
think that there's a sort of limit like that in R3

On pre-Vista server versions of Windows you used to be able to change 
the balance to 1GB OS, 3GB apps, as an install opton. This is likely 
done dynamically now.

for example I would prefere a webplugin rebol/view  for only firefox 
but available on all OS... Maybe basing rebol VM on non hardware 
related  langagues would allow to speed up things ...

I only tried to poke about the Linux port state. It's good to know 
there are at least two peopel who are willing to work on it. The 
Amiga port could behelpful but I still think you would need to write 
the majority of os specific stuff like, window + event handling, 
networking etc. from scratch.

...hard part about the window/event handling stuff is isolating the 
parts of the hostkit code this affects....


This is easy already...you have to create equivalents of the files 
in src\os\win32...the rest is non-OS specific code.

...we want mostly are the FreeType patches

 - I have published the Freetype support changes in the RMA version 
 of the hostkit so you should be able to just use simple define switch 
 to use freetype in the Linux(or any other OS that have FT2 lib avilable)

So...if you go thru the 5 files in src\os\win32 dir and make equivalents 
for Linux you are mostly done.

Cyphre, thanks for the FreeType code. It's a while ago that I looked 
at the src/os/ files, but they seemed fairly large and complicated. 
I won't have time to start that project until at least after ReBorCon

pity we can't have Rebol OS running on this cheap hardware

A111, 27 Feb Linux PPC, 5 Mar Amiga OS 4 and there has supposedly 
been a Linux ARM build for a while

NTLM is a hard to support, even using OS API. Making my NTLM implementation 
work in all cases would probably take days (or even weeks) of research, 
tests and debugging.

Not at the OS level. We can only define permissions within REBOL 
itself, not permissions when it isn't running. And REBOL doesn't 
have any facility for user-specific permissions.

Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.

And I don't really trust .bashrc for that reason, though there might 
be some OS protection for that file of which I'm not aware.

Depends on where you put %user.r and your OS capabilities, I guess.

(And still assuming you have eliminated all other similar security 
leaks from your regular OS usage.)

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

I get some errors (under OS X):

>> bind 'body o
** Script error: body is not in the specified context
>> bind [body] o 
== [body]
>> f 1
** Script error: a has no value

My f, body and o are defined this way:

>> f: func [v] body: [v + a] 
>> o: context [a: 1]

Some memory management systems segregate the values by the size, 
with objects of similar sizes allocated from the same space, to cut 
down on fragmentation. Large enough objects are sometimes allocated 
on their own, in a seperate chunk of memory allocated from the OS. 
I haven't seen any indications that REBOL's memory management does 
this though.

There is some doc here:

http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-19


As I read it, I would need to write an extension to access external 
APIs like standard OS libraries.

And Intel seems to be closing MeeGo down too :-( Meego, as a mobile 
OS, was not tied to JAVA, like Android is. You could run Python, 
PHP - it would be probably a good target for R3 without much effort 
...

I was just trying to state, that we are not lucky in the mobile area, 
as to support iOS, Android, WP, all require special aproach, not 
just "normal" OS port ....

No, I just think, that as a platform (OS), it might find its niche 
market, not necessarily dying. Then WebOS might be in worse condition. 
Samsung has BADA, so they don't need it, and I am not sure anyone 
else will buy it ... We will see - it seems that in mobile market, 
there are just following player - iOS, Android, WP7, then BB (QNX), 
Bada (Samsung), Symbian (Nokia)

Under OS X:
Using R2:
>> time [n: 1000000 while [0 < n: n - 1][]]
== 0:00:00.219887
Using R3:
>> dt [n: 1000'000 while [0 < n: n - 1][]] 
== 0:00:00.339793

The package you mention has files with a different extension, .rlp. 
Apparently the package needs to be  cooked on a strange OS different 
than Windows. (Gabriele: It currently requires GNU Make, however, 
those crazy people  still using Windows could rewrite remake.r to 
do all the work).

Alright 2010 is almost over now. Why don't we set something up virtually 
and "just do it"?  I just had a Teamviewer http://www.teamviewer.com/download/index.aspx?os=windows
session with some people from Singapore and Taiwan from California 
and it worked flawlessly. You guys sound like you are all doing some 
very interesting things.

I agree as well... mostly peope would like to use /library instead 
of extensions to do simple things like:
kernel32.dll: load/library %kernel32.dll
set 'MoveFile make routine! [
		"Moves file using OS"
    lpExistingFileName  [string!]
    lpNewFileName [string!]
] kernel32.dll "MoveFileA"

We don't want to download MS sources from MSDN to parse headers and 
integrate everything what's in kernel32.dll. Of course it may be 
cool in some cases, but we should keep it simple where possible.