AltME groups: search

I have a fixed version of %json.r. Do you want it Graham? I'll also 
send it to Douglas Crockford to post on JSON.org.


Thanks for catching that. The naive escaping has been there all along.

it works! thanks a lot. But it is not documented in core.pdf

>> secure b
** Script Error: Invalid argument: b
** Near: secure b
b was treated as a word like 'allow   'ask ,
so use :b instead, to get its value

the feature of rebol that function can accept a word without evaluating 
it even if it's an action word makes rebol more nice to look at but 
at cases as this it can cause confusion

it's a little less nice looking but it would be more uniform and 
logical .. the way of "least surprise"


because now when you write your own functions liek map-each you don't 
know or make it look like foreach with or make all custom functions 
not accept active words which makes your code more systematic and 
easyer to understand , but then your function is not in style with 
rebol's foreach forall ..etc

my vote would be to not have the option to to do >> foreach item 
block [ pring item ] .. it would make a language more uniform , although 
a little less cool :)

it's just a "vote". I don't expect them to change the language

Yeah, we're trying to keep this group on topic. We haven't written 
a DevBase chat client for R2 yet, so the development discussions 
of R2 releases are often in this group. Some people don't like to 
use chat, even if not using it limits the extent to which they can 
participate in R2 development (they can't submit changes directly, 
for instance).

No :)


We need a place, page, website, (i.e. the original purpose of REBOLCentral) 
where a new person can come, and in a really nice layout EVERYTHING 
REBOL is there.

It points a person to everything else.


The Library,  the blogs, the knoweldge of this place, a REBOL "ReadMeFirst.txt" 
if you will.

Might have them already though - going to check my archives. A list 
of the old platform numbers would be nice too.

Graham, thanks a lot! rebol-old is 2.3.0, rebolnew is 2.5.0 and rebol101 
is 2.5.5. all /core for solaris sparc (10.1)

Heh, very nice! All of those binaries run as-is on a Sun Fire T1000 
:)

Confirming, HTTPS should work (after doing a net-install call) on 
Core 2.7.7.4.2?

There was an end-of-line problem in the SDK, when using HTTPS with 
a generic proxy. Packets were sent with just LF, where the definition 
(RFC 2616) say, CRLF should be used. It could be fixed in the SDK 
by editing prot-http.r. I haven't checked, if this is fixed in later 
versions (incl. View/2.7.7), so it's a potential problem.

Gregg, I'll check with Carl about whether there can be a Core with 
SSL in future R2 releases. Hopefully the difference in event model 
in View isn't integrated into the SSL code. Geomol, I'll put that 
on the list to check.

There's a rebcmd with ssl that is part of rebol/command of course 
... I was guessing Carl was keeping it that way.

Found a random bug in 2.7.6 with AS-STRING...

I submitted my http patches for 2.7.7 ... and they have yet to be 
reviewed.  Suspect it's a waste of our time.

Sorry, Graham, I've been busy helping a sick friend. Back at it now.

Micha, does Windows Server 2008 have a connection quota feature? 
Perhaps per-user?

Windows XP has connection quotas, but it's a fixed setting. Still, 
I'll check it here on one of my XP boxes.

That looks like LOAD/library %x11, something you would see on a Unix/Linux 
compatible script. IIRC Edgar wrote that for Qtask, which runs on 
Linux.

amazing with so many different versions for a little bit of image 
processing...

Welcome to the wonders of cross-platform code. There isn't a native 
version for Mac either: It uses X11.

That would be in keeping with the work load at Qtask, as I recall. 
He's a busy guy.

I think I'll just call the CLI version... don't need anything other 
than smooth downscaling and a few other bits.

a clean installation and call "convert" is enough to give access 
under windows, so that's good enough for me.

I use CONVERT quite a bit, and it works well for me.

The problem with ImageMagick was that the API was a moving target. 

So the script I submitted worked only for that specific version of 
ImageMagick.

Since Qtask is not currently using ImageMagick now, I don't know 
when I can get back to work on it again.

I suggest to do what Gregg is suggesting at this time.

I'm building a simple dialect around it. I'm not sure I can make 
it 1:1 capable with CONVERT, but at least you would then be able 
to pass a standard REBOL block directly to CONVERT.

Example:


process [path %/z load %image.jpg blur 3x6 negate resize 50x50 save 
%image2.jpg]

I've thought about doing that as well Henrik, but by needs ended 
up being very static. I have also considered a test app that you 
could use to preview the result and then copy the command line, life 
effect-lab and font-lab.

yes, Gregg, I agree. Mine is diverting now towards what I really 
need it for: namely for adding auto-generated images to docs, so 
only some very specific functionality is used. I'll be adding a few 
more features today and then I'll publish it, but I'm not sure how 
much value it has to others than me.

Yes, a big part of my motivation to write a dialect is that the CLI 
format is nto very human friendly.

My goal of looking at the API was to avoid the startup overhead when 
using CALL. While I wouldn't mind things being faster, we call it 
*a lot* and it works great. The upside of using the CLI is that you 
don't have to worry about a single instance being your bottleneck, 
and it's scalable.

Does anyone have a second opinion on my last comment here? http://www.rebol.com/cgi-bin/blog.r?view=0466#comments

... I am trying to vote to finally really finish R3 and release a 
beta .... the wait is terrible .... ;-)

Add is a complete verb :)  That is why INC and DEC weren't chosen 
at first: REBOL naming standards for built-in functions abhor acronyms 
(ironic) and abbreviations, for the most part (FUNC and FUNCT are 
exceptions). That's why we break out the thesaurus when we want to 
come up with a shorter name, most of the time.

Carl, how possible is it to get UNBIND ported to R2 as a native for 
2.7.8? It's the only thing missing from R2/Forward so far.

Since there are mezzanines for them already, it's not a problem (though 
the ASSERT mezzanine still sucks). Same with MAP-EACH.

The real user-visible improvement would come from adding the set-word 
feature to FOREACH. And maybe REMOVE-EACH, but that isn't as big 
a user win.

You could do that with a temp object and RESOLVE as is, if need be.

You have a GUI?

ok, I've got to go find some food... but will return in a while to 
do a trial build with most of this done.


BTW, still missing the fixes Graham made to HTTP. He mentioned it 
the other day.

(I thought I added his fixes a few years ago... but perhaps they 
were removed due to a problem, not sure.)

If I had one more wish for a native, it would be ASSERT.

Carl "BTW, still missing the fixes Graham made to HTTP. He mentioned 
it the other day ..."


Yes, I keep saying where they are and you keep asking .. so I have 
to track you down to tell you lol.  

Wouldn't it be easier if registered chat users could add to a comment 
page for every page on rebol.com ??  Then nothing would be lost.

Oh, I thought you meant here. And Doc writes a web server and networking 
protocols, Maarten has written a HTTP client (at least), and Gabriele 
has written other networking stuff. They're active.

APPLY fixed. Though I am hoping the mezzanine will be replaced with 
a native :)

A whole bunch of VID documents have been uploaded and updated:

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

so I gather there is a separate build script for R3 docs.

I think I'd rather see a 64 bit release of R2 than a R3 release now.

is there any solution or idea for multiple feeding a running console 
app
started via call/wait/input/output ?
have tried a pass a open port but no luck. the console needs more
than one command to work properly. the ideal solution would be to

hold the console app permanently open, feed it via write-io or (something
like this) and parse the output. any hint?

Because Windows 2008 server is a 64 bit platform and I can't read 
the registry anymore

I think it's part of the virtualization stuff that 2008 does to make 
the 32 bit app think it is running under a 32bit os.

So you have a fix?

Looks like just a flag change. In theory, easy. In practice, someone 
will need to test it.

I setup a Windows 2008 server on Amazon.  Setup Firebird 64 bit and 
a DSN.  Then tried to connect using ODBC.  Failed.

So, any possibility of a 64 bit release of R2?

I'm not yet to the point of agreeing that this is a registry problem.

Easy enough to check if you have a 64 bit windows available

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

There's a pile of boxes here, one being Win64 but has not been booted 
in five years, min.

Still, 15 mins seems like a long time.

An invalid pass crack should take ever-increasing authentication 
times... so a 15 min password gen time seems silly.

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

If I had to guess, I'd say it's a version issue.

There are not any registry calls in the ODBC port.  But, it's always 
been a little-bit version sensitive.

Don't have Access.  I'm running this on a Windows 2008 virtual server 
on Ec2.

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.

I'm not too concerned about this in view of this work round, but 
I would like a way rebol to access the 64 bit registry if it's just 
a flag setting ...

Just have to rewrite my installer to switch to creating a dsnless 
connection if it detects running on 64 bit windows

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.

It would depend on the platform. For instance, the WinCE version 
was for a hardware platform that noone uses anymore.

ZFS seems to be a useful thing to have .. given the number of times 
I need to recover things!

OpenSolaris seems to be suppported by Oracle and a large community

It's a little soon to see if it will be supported by Oracle, but 
it's a cool platform.

Still, suggest it. It's more likely for platforms that can be put 
in a VM for testing, for free (no cost).

I found that OpenSolaris is awfully slow even when compared to slow 
Linux distributions like Ubuntu but that may be just my computer 
since OpenSolaris doesn't support that much hardware. Booting it 
took 10 minutes already but the whole system felt very sluggish. 
Some of the features it has are really nice though. The ZFS video 
where some guy used a big hammer to destroy running harddrives to 
show off ZFS handling it without any problems was cool :) What I 
would like to see Rebol run on is Haiku, especially since you develop 
native apps for it with C++ which usually is quite horrible although 
I have to say that the BeOS api makes C++ programming quite a bit 
less horrible.

Haiku support is likely to happen with R3, but we'll have to see 
with R2. Was there a previous BeOS port of R2?

If so we'd need a new minor platform number for Haiku with the new 
GCC compiler.

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 :)

We'll keep you in mind as being a possible Haiku tester :)

Yay, do I get a t-shirt? :) Or at least a button "ask me about Haiku 
R3".

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.

There is apparently a TCP interface, so drivers could be written 
that would take advantage of its strengths better than ODBC would.

Which reminds me, what's stopping RT from supporting unixodbc?  I 
think Carl said there was a proliferation of odbc methods for Linux, 
but as far as I can tell they've now standardized on unixodbc

I had a quick search for the TCP/IP interface docs .. couldn't find 
any yet

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.

call without /wait in a loop

the test I made was against a real big table with 50+ mio records. 
no problem at all.

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.

If this works out, it might be cool to write it as a port scheme 
so that we can just replace the 'open

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

there are 3 extension which would be very cool. 

1. tcp server for easy remote request  without the need for the cli 
on the client side (e.g. rebservice)  

2. a smart sql-syntax mapper for interactive migration (you can't 
read e.g. a mysql dump directly into postgresql) 

3. a stable cli alive holder to eliminate the startup payload for 
the request.

Interbase have a developer release that is multicore aware.  I'd 
be interested to test this once you do the first release.  The developer 
release is same as the commercial one but stops receiving new connections 
after 48 hours.

if you like firebird you should also take a look to frontbase. running 
well with windows if you prefer, similar small footprint concept, 
but all in. replication, clustering, embedding etc.
there is also a streamline cli (sql92).

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.