AltME groups: search

The effort to make R2 work properly in 64bit >> releasing R3 and 
adding things like native ODBC to the open host code.

Essentially, R2 is supported and gets some fixes, but not a rewrite.

I am going to try and start it ...

no good .. I've lost the password so can't access it anymore.  And 
it won't generate a new password for me.

And it uses SSL :(

Graham, is it possible that Firebird 64bit doesn't come with 32bit 
connection libraries? Unless there is some IPC or TCP layer between 
the client libs and the server, possible if the client and server 
are on the same system, then it is possible that the x64 version 
may not be connectable from 32bit apps.

There is a 32bit library I think in a Firebird wow64 directory, and 
using this and a dsnless connection, I can connect to the database.

Is it in a Firebird wow64 directory, or the Windows wow64 directory? 
It seems to me like the 32bit ODBC drivers aren't installed, registered 
with ODBC. Check the ODBC configurator, look at the drivers list 
and see if the 32bit drivers are listed there.

And is it listed in the ODBC drivers list?

Given that he has released the openbsd version and who uses openbsd 
here??

OpenSolaris seems to be suppported by Oracle and a large community

Yeah there is a Rebol/Core 2.5.0.5.2 and a Rebol/View 1.2.1.5.2 for 
BeOS R5. I tried the one with View on the latest nightly build of 
Haiku yesterday, didn't work though, some error message about the 
Media Server Addon IIRC. Could be because I used the GCC4 hybrid 
iso, don't know how far they are with that stuff yet, I haven't followed 
the mailing list for a few months. A R3 port in a few years would 
be good enough for me, Haiku is still in alpha so it's probably a 
good idea to wait a bit more. From what I heard they now have a few 
people working on it full time (paid) thanks to a lot of donations, 
so there is a lot of stuff going on with the Haiku code base right 
now :)

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

MonetDB looks nice, and it has ODBC drivers for a start. Column store 
is good for analytics.

And you can use unixodbc on Linux (but can you use it from R2 on 
Linux?).

To answer your question, my guess would be time and money. R2 native 
enhancements that RT doesn't need itself need to be funded nowadays.

graham I am using a 'prototype multi cli connector' for different 
databases.

(currently mysql/postgresql/monetdb/sqlite. more are in progress) 
I will provide you

with a source link in a couple of days if you like. I would never 
ever use odbc, it's to unstable

and makes always problems when the db load is highest. but ok I also 
don't like synthetical 

benchmarks or theoretical feature lists. real life experiences are 
best...

like this?
the cli connector is using the cli component nearly all major
databases delivering. the connection is made via rebols 

call/wait/info/output/error and a simple parse after, for the resultset.
I am using this prototype mainly for a q & d connect

to mysql/postgresql/monetdb/sqlite. on my list are also connectors 
for

firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and 
cassandra.
pros:

1. very fast for single requests
2. no rewrite of code needed if a new version or protocol is out
3. easy 'data migration' between the db's

4. adding new db's are a matter of hours only (see the cli spec thats 
all)
5. fast prototyping and testing for new db's

6. robust, never had any trouble with cli's even with bigger resultsets

7. should be perfect also for traditional cgi (the process starting 
overhead is minimal, execpt you name is facebook)

8. very small footprint (~120 lines for connecting to 4 db's, could 
be the half)

with a nice tcp-server component like rebservice the 
cli multi connector could be very usefull as a c/s connector.
I made a test with 2.000 concurrent calls (simple select) 
on a 4 gig quadcore. the cpu was only close to 50%, a good value.

cons:


1. slow if you have very much serial inserts (unless you shape them 
into one sql query)
2. need to start a cli process for every request
3. needs a tcp server for non-local connections
4. some more, but who cares ;-)

with a solution to keep the cli open from rebservice,

these cons could disappear and the speed diff overhead to a memory 
based lib
could be marginal.

is CLI connector done in REBOL? Or does it call some external command-line 
cross-db access tool and REBOL just parses the data?

pekr, can't confirm this (under linux where I am using this connector). 

a standard hot wildcard query (select * from db limit 1000) takes 
in average 320 ms 

with cli and 560 ms with docs cool mysql driver which I am using 
daily. 

I think it looks different if you compare e.g cli against sqlite, 
connected via native 

lib access but all connectors working via tcp shouldn't be faster 
then cli I guess. 
but please don't nail me with these numbers.

this cli connector is currently a prototype idea with some nice potential 
at this

moment nothing more, at least it works very smooth for migration 
tasks.

the best is if you make your own tests and see if its usefull for 
your demands.

one addition: increasing/decreasing the resultset makes the difference 
much bigger 

in both directions. selecting 5000 records: cli/620 ms and scheme/3340 
ms
but selecting 10 records: cli/316 ms and scheme/35 ms.

so looks like the payload for starting the cli process is around 
300 ms.

as mentioned before, a concept holding the cli stable alive could 
save this payload.

the cli is currently using the original utilities from the db manufacturer 
to ensure max. performance and robustness. 

there are already many switches to modify out & input. for example 
take a look here for the monetdb switches:

http://monetdb.cwi.nl/XQuery/Documentation/The-Mapi-Client-Utility.html#The-Mapi-Client-Utility

Something along the lines of the xml-odbc server that Easysoft sells 
.. but native and not odbc.

This waits for incoming xml requests and sends data back

Your work sounds very cool Tomas. I'm sure Graham will give it a 
good test and report back. You may have a lot of people interested.

BTW, I made a couple of tiny changes to prot smtp, pop, and send 
to allow them to work with SSL.  Should these also make it into 2.7.8 
??

Gmail and hotmail

and pop3 http://compkarori.no-ip.biz:8090/@api/deki/files/560/=prot-spop.r

I've got a demo script somewhere that logs in to hotmail/gmail and 
downloads all new messages and strips out the attachments

It might be a good idea to have the standard pop:// protocol do the 
STLS negotiation, and have pops:// do POP3S like Gmail.

We can add RFC2595 TLS negotiation to the regular pop:// and imap:// 
protocols later.

Well, it depends on priorities. These changes are mezzanine, and 
just extensions at that, backwards-compatible. Carl doesn't have 
to be involved with mezzanine R2 changes - that's my job.

and probably, the algorythms, once understood can be readily retro-fitted 
to R3.

And my major priorities that have been keeping me away from my computer 
for the last few months are near their end.

I'll be on next week, but this is the first time in two weeks that 
I've been able to spend more than a few minutes at home and I'm taking 
a break.

Or use SORT and see which one comes first :)

SORT embodies different logic to the GREATER?, LESSER? (etc) when 
it comes to implementing ordering. And that can sometimes be useful, 
or at least, usable.

Do you really want > and < to return none if they run into a ambiguous 
situation? Right now all of those functions return true or false.

: )   Ok, I see! And that's where SORT 10x10 11x11 came from ;-)

Just a simple issue!  .... I have an image and I want to see if I 
need to enlarge it or not to fit into my box

And don't overlook OUTSIDE? p1 p2

Are you suggesting a default sort order for pair here?

pairs can be used in more ways than any one of us will come up with 
and will have different premises as to what sort means. let it error 
right away so we know we have to be more specific in our code

I don't remember exactly, but COMPARE should be a little bit faster 
and has the advantage of being to able to return NONE if desired

I was on graham's side, but I've changed ideas since I've been using 
pairs for so may purposes that its really hard to find a default. 
  especially one which doesn't require different meanings for none 
and false.

Implementing a useless default has the advantage of being the Salomonical 
solution. That way, noone has to complain if one of to sensible options 
gets implemented and you need the other, unimplemented one.

I'll try and remember that when I learn German :)

We switch between R2 and R3 work. The last week has been focused 
on R3. A week-or-so ago I made a few tweaks to R2/Forward for 2.7.8, 
including a backported fix from R3, and Carl put together a plan 
and implemented a lot of his portion of the plan. I expect that soon 
after the R3 a98 release, we'll have a R2 2.7.8 release. And 2.7.8 
looks like it will be the first really stable release in the whole 
2.7.x series, something to really look forward to.

because myfile is of type file!, and so extension is also file!

Back on pair comparisons, MIN and MAX don't return one of the given 
pair values (not sure if someone else mentioned that).

>> max 10x11 9x12
== 10x12

And back in the Core group - we're trying to keep this group on its 
topic of R2 releases. We don't want to lose such discussions in the 
middle of discussions of semantics. The only reason this group was 
created is because some of the people working on the development 
of R2 don't want to use chat yet. This group is *only* a replacement 
for the R2-Beta world.

using MIN on offsets and MAX on size you get the enclosing box


when you use MAX on offsets and MIN on size you get the intersection 
of both boxes

funny thing is, that the former code is exactly as long as the latter 
one, does not need the additional variable, and it is faster

...and I find it more readable

But it's easy enough to create a safe INDEX? function. I think Gabriele 
calls his INDEX?? and I borrowed it from him.

its also possible that with the AGG fixes done or pending, we might 
get a 2.7.8 beta which has current mezz code and the bigger native 
changes pushed to a 2.7.9 release... but I'm just throwing a guess 
in the air.

However, I am not dissatisflied. I apreciate the amount of work done 
and every release is a gift to the community. Long life to Carl !

is there the possibility of getting R3 AGG Richtext dialect backported 
to R2 - it would make a huge difference for gui development and text 
rendering?

I have come across a strange problem with View 2.7.7 on Mac OS X. 
If I load a library, run a function from the library and then put 
the machine into sleep mode, Rebol crashes with a Floating Point 
Exception when the machine wakes up. Here is ahte console session:

>> mylib: load/library %Code/Pascal/libtestlib.dylib
>> add1: make routine! [a[int] return: [int]] mylib "myfunc" 
>> add1 12
== 13
>> Floating point exception


I compiled and tested the library under Windows, put the machine 
to sleep, no problem when it woke up. (I was running Windows as a 
Virtual Box VM).

Any suggestions?

I've never previously experienced a problem when waking my Mac.


I only encounter the problem with the test library I have written 
in Free Pascal, I couldn't reproduce it with a C library with the 
same functionality.


It could be the Pascal written library, I'll do some tests on Windows 
(not VM) and Liunx when I get a little more time.


I'm a little suspicious of View 2.7.7 because when I tried Jaime 
Vargas's Callback test it crashed with a bus error.

I could be wrong here, but I think "flood" is from the "old draw", 
and I don't remember if it was supported when R2 moved to AGG for 
draw.

I just seem to remember a discussion about flood when R2 moved to 
AGG, but I don't remember the details. in general though should shold 
be able to achieve the same effect without using flood, and it is 
probably going to be faster.

and doing pixel by pixel detection in rebol is so slow as to make 
it unworkable

ICarii: see the first sentence in the doc page you refer to: "Describes 
the original draw dialect - for historic reference..."
So yes, FLOOD was only in 1.2 View (pre AGG DRAW) .

Gabriele is correct, it was not implemented when we got the AA gfx. 
Geomol did nice and not so slow flood-fill in RPaint IIRC.

If you really think it is valuable to have FLOOD back and show Carl 
some good small enough routine that could be used he might add it 
as he is currently 'open' for smaller R2 Draw improvements.

sounds good - im looking into a 'Quickfill' implementation at the 
moment which can do pattern, flood and bordered fill.  Once its working 
properly ill post to View or similar

I have found that the problem with OS X View 2.7.7 crashing on wakeup 
was caused by a problem with the dylib. The root of a problem is 
a conflict between the linker on Snow Leopard and Free Pascal (the 
problem didn't exist on Lepoard).


I have a workaround which is to statically link the pascal code into 
a C "wrapper" dylib.

And have you actually reviewed the htt protocol changes I made yet??

Yes, and later this week I would like to ask you some questions.

At this rate, HTTP and the rest of the protocols will be patched 
in the next release. All of the R2/Forward changes have been submitted 
already, months ago.

ICarii, what I did, was studying DPaint filling the screen, and then 
figured out, how to do it. It's a scanline filling algorithm. In 
short, it goes like:


- Search left and right for other colors from the point clicked on 
screen. That defines the first scanline.

- Look at lines above and below starting from the end-points of the 
first line. This defines 4 new points to look at.

- Again search left and right for other colors. Make sure, the whole 
area between the end-points are searched.
- Put it all in some list, and continue, until the list is empty.

A good way to test it, is making a lot of vertical lines on the screen 
with spaces in between, and not drawing them all the way to the border 
of the image. Then fill from some point at the center of the screen 
and see, how the filling is being split up into many separate fillings.

ah - i went with a push/pop stack and a 4 point scan

http://www.rebol.com/priorities.html


says 2.7.8 is "(Status: delayed, pending sufficient user-base response 
and contributions related to installation)"


Who can progress the installer?  That looks like it is holding this 
up ...

Yes, for file associations and the View desktop. R2 View, like AltME, 
is designed for Win9x behavior right now. It doesn't work well with 
Win2k and above.

Any plan to remove it from R2? It can be loadable from web by a function. 
Not a big issue ofcourse, we just won't need for those public, desktop 
etc. folders anymore and gain some kilobytes.

Work will be moving ahead soon on the R2 installer. Please post any 
information you have about installation issues in modern Windows 
versions (or links to sites with such), or about equivalent file 
location issues for other supported platforms. This will affect placement 
of the program, user-specific placement of the viewtop files, and 
(on Windows) file associations. Windows needs 4 installation profiles 
- let's hope that things can stay simpler on other platforms.

I'm on linux and haven't been using View 2.7.7.4.2 because it crashes 
too easily with DRAW, so I'm still using 2.7.6.4.2.

(I'm assuming that will be fixed pretty quickly, however.) The biggest 
annoyance for me is the lack of DRAW text rendering.

It's been so long since I used the installer I can't remember any 
of the issues with it!

it is clunky and awkward, true.

I prefer it always runs as standalone console, even at first time. 
If user wants then he/she can INSTALL or starts DESKTOP.

So I can send rebol.exe to anyone and tell him just drag & drop that 
script file onto that exe file.

I just want rebviewpro.exe to be available as well as rebol.exe. 


 the installer is a nuisance, why should /view require one while /core 
 doesn't?


I'd much rather have no install and have a mezz or native command 
I run in the console that does an "install"

Hate to break it to you, but the desktop is actually used by some 
and either needs installation or portable app mode. Console-only 
no-install mode, two install modes depending on permissions, and 
portable app mode, that's the 4 modes.

its a nuisance because its not required.  the desktop is fine for 
end-users.   I'm not one of them, and it gets in the way when I deploy 
my pplications at clients.

really, there should be two executables.  One which does all of that 
fancy stuff, and another which just doesn't do anything.  no install, 
no security.

two intepreters using the same extension

 - you mean rebview and rebcmdview? Core doesn't set or require an 
 extension.

but cmd and normal too.

hey, if the executable can reliably read rebol.r, then that's cool. 
 its also MUCH simpler for networked install, since you can lock 
down the permission on rebol.r so that every one launches the same 
way.   if we really need user.r... then just provide its path within 
rebol.r and load it from there.

ok I think my main grievance is that the "installer" is within the 
rebol.exe  it has to be a separate executable which does the information 
gathering, copies and creates all the files.  but launching rebol.exe 
should never again ask for installation.


if that is how you are thinking about it then, I don't mind installation.

The "copying files to some location" is the least difficult part 
of an installer. The tricky part is determining exacty *where* to 
put stuff. Fortunately, most of that is ahead-of-time research about 
where to look in the registry and environment for settings, where 
to put them, etc. And that varies depending on the Windows version 
because the really good tricks weren't adopted until later.

yes I know all about that, and its really fucked up in vista/7.  
for an application not being able to write in its install path is 
ridiculous.

much better to store files in 3 different places, forget about them 
and fill up the disk, with the user totally unable to know where 
to and how to cleanup his disks.

We need to have a way to have the program not install and not bring 
up the desktop without command line parameters, from the same executable 
that will under different circumstances offer to install. It's one 
of the modes I mentioned.

oh and did you know that in vista (and possibly windows 7)  the names 
for windows paths are translated in the explorer but remain english 
in the file structure?


such that you can actually have the same folder twice within an explorer 
view  :-)   yep, great engineering.

I first started complaining about the installer in 2000. Some of 
my recommendations have been implemented, but not all. And 2 more 
standard installation profiles have been added since then.

folder aliasing is new vista, and its a very stupid idea.  using 
the same path you end up at one file for read another for write? 
 wtf!

Folder aliasing is there to make up for silly people who still write 
apps that try to write to their application path without sufficient 
rights. If people had paid attention to the rules in 2000, we wouldn't 
have this mess now - Windows apps would be acting like Linux or Mac 
apps, and putting their files where they should be.

I agree, as long as the rebol.r *enables* has final control and nothing 
requires to be stored in registry, its all good.


obviously, windows will want some stuff in the registry for its own 
management, but rebol should not peek there to try and determine 
anything.

if it really has to.. put that registry peeking in the rebol.r

installation would simply be the act of running rebol.exe without 
a rebol.r file and generating a default rebol.r file in your current 
setup.

And the installer would need to peek in the registry, since that's 
where locations are stored.

There are group policy settings that can make it so that programs 
can only be run from certain directories, and security settings to 
make it so only administrators can write to those directories. And 
the only reason that they have to do things so drastically is because 
of developers like you who insist on writing Win9x apps and trying 
to run them on Win2k+. Apps like AltME.

Yes, it's screwed up, but the screw-up is because permissions are 
user-based rather than app-based. This problem is shared by Linux, 
OS X, and most other Unix-serived OSes.

It's a common mistake in OS design, and in some cases one that is 
mandated by law (DOD rules).

but when I say forced, I don't mean spread up all around the disk 
and forgotten on uninstalled, untraceable deep paths, masked by the 
explorer, and even translated on top of it.