AltME groups: search

Oh, you meant a c-string!, not a string!, so it's even easier, just 
use: alloc-bytes size

My first impressions on your proposition:


1) arr[i] is a useless syntactic addition as we already have indexed 
accesses: arr/i


2) #7 and #8 are going way too far from the Red/System application 
domain, it's basically  a series abstraction. Red internal API already 
provides series (the internal API is not yet completed nor formalized 
though), so this is both unneeded and overlapping with Red standard 
library.


What you might not realize is that you already have array-like capabilities 
with Red/System pointers (including structs and c-strings). If you 
want automatic memory management in Red/System, you won't have it, 
low-level programming requires a manual management of memory for 
accuracy and avoiding unnecessary burdens.


The only array-like part that Red/System is really missing right 
now is the literal array-like declarations, which can be achieved 
without a new formal array! type. As I said earlier, adding a array! 
type would only add bound-checking abilities (which is a nice feature 
to have) and provide you with #5 as a side-effect (not very useful 
anyway, as array would be fixed-size).

>> do/args %rsc.r "%bridges/java/JNIdemo.reds -o %bridges/java/JNIdemo"

-= Red/System Compiler =-
Compiling bridges/java/JNIdemo.reds ...

...compilation time:     114 ms
...linking time:         4 ms
...output file size:     6656 bytes
...output file name:     bridges/java/JNIdemo.exe

Hi Doc, I was messing around with the PE.

Added section: [.rsrc  [-   #{00000000000000000004000000000000}]] 
in compiler (this should be just empty .rsrc, and trying to build 
it in PE.r using:

oh/rsrc-addr:			section-addr? job '.rsrc
oh/rsrc-size:			length? job/sections/.rsrc/2


but the address is pointing into wrong position (512B less). You 
probably don't know without some deeper examination, what may be 
the reason, do you?

Btw. there should be:
    .rsrc				#{40000040}	;-- [read initialized]

at this line: https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L119
(the section name starts with a dot).

So far adding the rswr section modifies these values:   [ entry-point-addr 
code-base data-base ] which should be same as without rsrc in my 
tests, and not increasing init-data-size.

Line 369: it's for getting the memory pointer for last section, but 
it seems it's lacking an offset for skipping that last section size.

Ok, so the main problem will be, that oh/headers-size = 1024, but 
the pointer to code as a first section is 512. Now I must find why.

I've reduced the size of the package, now hello.apk weights just 
153KB.

Thanks for the compliment Doc, not really sure what you mean exactly 
by making it more like Red/System and less C: use more descriptive 
names? I will take a closer look at some ed/System examples out there.

Thanks Kaj for finding those and for the tips, the size of MM makes 
it the same in effect in this case, but it has to be <= then. Program 
not crashing, I was lucky then! off-by-one errors? My index goes 
from 1 up, where in C it is from 0 up, I had to debug this to make 
sure elements were swapped in the same way as in the original program. 
That is also why I declare KKP and LLP to as to save from adding 
1 to KK and LL over and over again. 


Knuth's algorythm was the first one I found, and I knew already of 
its existence, so it made sense to use what you have. Sure my Red/System 
code is not optimised.


Going to work on it now and tomorrow, and later I take on the Twister. 
It is a good exercise!

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

One bug need to mention:

After doing mod operation, I use the result as index to access the 
array,it's OK in C, but will cause strange behavior in Red/System. 
Because mod will produce 0 and Red/System use 1-base array.
n: c + state-half-size % state-size
Then I modified the code as below to solve this issue:
n: c - 1 + state-half-size % state-size + 1

Now in Red/System, we can't pass a function as parameter to Red/System 
FUNC,
but we can pass it to external C FUNC, right?


cmp-func!: alias function! [left [byte-ptr!] rihgt [byte-ptr!] return: 
[integer!]] 
quick-sort: func [
	base	 [byte-ptr!]
	n		 [integer!]
	size	 [integer!]
	cmp-func [cmp-func!]	
][
	; can't use cmp-func in this function
]

Added a parameter to make read-file-binary return the file size

And or adding lines where you print information to the console

print [" before call to read-file-binary, size of size1: " size1 
lf]

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

The calculation is okay.

Code:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + (as integer! green) + (as integer! 
blue)

print [greyscale lf]

OUTPUT:
-= Red/System Compiler =- 
Compiling /Users/peter/VMShare/Code/Red-System/test.reds ...
Script: "Red/System IA-32 code emitter" (none)
Script: "Red/System Mach-O format emitter" (none)

...compilation time:     122 ms
...linking time:         10 ms
...output file size:     16384 bytes
...output file name:     builds/test
260

Oops, here's the proper code and correct answer:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + ((as integer! green) / 3) + 
((as integer! blue) / 3)

print [greyscale lf]

OUTPUT
...compilation time:     133 ms
...linking time:         13 ms
...output file size:     16384 bytes
...output file name:     builds/test
140

My Red/System script (through some technical wizardry) can now process 
10 seconds of video from an HD source at 30fps and isolate motion 
areas of a particular size in a fraction of a second on a 700MHz 
Raspberry Pi.

In the above example, dirs.txt is a text file of size 524 bytes.

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).

Yes, the ARM instruction set is optimised for speed at the expense 
of size

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

Bo, your make-c-string leaks memory. read-file will allocate memory 
of the size to fit the file contents

Kaj, you said that 'read-file in Red/System automatically defines 
a large enough memory space for the file.  How about 'read-file-binary? 
 That one has a 'size parameter.  How can one determine how big to 
make that 'size parameter before reading the file?

You don't make it any size. It works the same as read-file and the 
READ function in REBOL: it allocates the storage for you

In the case of read-string you get a c-string!, so you can get the 
size with LENGTH?. For read-file-binary that's not possible, so you 
pass a pointer to an integer! to be informed about the read size

gets() requires you to allocate a buffer of adequate size. Empty 
c-string! literals ("") will statically allocate an empty string, 
unsuitable for use with gets(), resulting in buffer overflows ('boo 
is allocated just after 'foo). Try rather: 

foo:  allocate 100
boo: allocate 100


This will dynamically allocate 100 bytes for each c-string!. You 
need to ensure that gets() won't overflow those buffers (which in 
practice is impossible, so one should just avoid using gets() in 
production code).

Red/System: Could it be that if you 
#define MAX-SIZE 100
my-array: as int-ptr! allocate MAX-SIZE * size? integer!
then using  
my-array/MAX-SIZE 
gives a compilation error??
*** Compilation Error: undefined pointer index variable

i: MAX-SIZE

In contrast to libraries like Qt and wxWidgets, FLTK uses a more 
lightweight design and restricts itself to GUI functionality. Because 
of this, the library is very small (the FLTK "Hello World" program 
is around 100 KiB), and is usually statically linked. It also avoids 
complicated macros and separate code preprocessors, and does not 
use the following advanced C++ features: templates, exceptions, RTTI 
or, for FLTK 1.x, namespaces. Combined with the modest size of the 
package, this leads to a relatively short learning curve for new 
users.[citation needed]


These advantages come with corresponding disadvantages. FLTK offers 
fewer widgets than most GUI toolkits and, because of its use of non-native 
widgets, does not have native look-and-feel on any platform.

RPI would be size and weight advantage. Hide it under a table. Hard 
to do with a 10 year old desktop for the same price.

Geomol, some notest regarding alpha channel:

The alpha values seems to be left out.

I'ts not left out..that's only the way "mold" of image! datatype 
works. So I the image have "fully transparent" alphachannel it is 
just not shown by mold to make the output more readable.

But it seems, the alpha channel is separate from RGB values.

The alphachannel is always present in the image! datatype (ie. internally 
it's always 4 components = 32bit bitmap). Again it's just the way 
"molding" of the datatype displays the content.


AFAIK You can construct the image! with alphachannel in various ways 
for example:

separated alpha:

>> i: make image! [2x2 #{0102030405060708009A0B0C} #{11121314}]
== make image! [2x2 #{
0102030405060708009A0B0C
} #{
11121314
}]

same example but the RGBA compoments together:

>> i: to image! #{0102031104050612070809130A0B0C14}
== make image! [4x1 #{
0102030405060708090A0B0C
} #{
11121314
}]

>> i/size: 2x2
== 2x2

>> i
== make image! [2x2 #{
0102030405060708090A0B0C
} #{
11121314
}]

>>

Same way you can get the values in different form:

>> i/rgb
== #{0102030405060708090A0B0C}

>> i/alpha
== #{11121314}

>> to binary! i
== #{0102031104050612070809130A0B0C14}


For more I'd suggest you read the image! datatype docs here: http://www.rebol.com/docs/image.html

AFAIK The docs were written for R2 but should hold pretty much also 
for R3.

And *test* your backups! Did a medium-size system for a big bank. 
Ran great for 3+ years, they changed the network, glitched something, 
went to the backup and found that the archive software was set to 
remove all blank space (e.g. nulls) from files. Every backup for 
3 years had "compressed" the DB files in a way that made them useless.

You could reduce the name column size and give more space for chatting

Causes may include clicking before the resync has completed.

But it also seems to be related to the size of the world -- I've 
been getting the recycle bug in the last few days, so possibly Rebol3 
is getting too large.

Settings - [Font  Size]

[1] Grouping of calendar events so you can filter select which type 
or with whom, specific calendar events are shared with, for display.
[2] Weekview in the calendar to fit more events pr. day

[3] Events from calendar formatted as a chronological TODO or activity 
list

[4] Export the calendar as HTML (it's a real problem if you have 
many events per day and can only see a small amount of them)

[5] Dynamic width of the user/group list to the left. Many group 
titles are chopped off.
[6] Filter search in the Users and Groups list

[7] Bigger/adjustable text area size in checklist entries, so it 
would be more suitable to store makedoc2 formatted documents in them 
(instant document repository!)

[8] Export checklists in makedoc2 format for integration in other 
makedoc2 docs

[9] Checklists as a column view. It would mean for Checklists: Spreadsheets 
that Checklists are in the left column and Spreadsheets are in the 
right column. You can select other checklists immediately without 
having to go back to the top and select a new one.

[10] Generally resizable windows everywhere. Small text areas are 
annoying!

:-)

(1) Allowing translation (external language file with program strings)
(2) Ability to mark all messages as read
(3) Font size settings
(4) Users rights (limited guest account would be a good step)

1. Ability to adjust fonts/size

2. Tabbed world browsing. One Altme window showing multiple worlds 
tabbed, rather than an app running for each world.

3. Optional, Show as icon on task bar when running. rather than taskbar 
list. (like winamp options)

Yeah, I'm REALLY anti FTP.  It took us writing our own FTP Client 
to realize, FTP is simply not worth supporting, the people who originated 
it were kids, that did not know what they were doing.  We waste too 
much time, as has everyone that has written FTP client or Server 
software.


Basically, the standard should be rewritten such that every command 
that a normal DOS would use are available, even the simple stuff 
like getting the size of the volume the data is being stored on, 
and remaining space.


But also there needs to be systems in place for check-summing files 
in usable chunks, and also for doing metrics from both sides so that 
better predictions can be made about the time it will take to synch.

It goes on and on, just throw FTP away…


Build an x-internet interface to something new, and build it correctly 
to be global not local.


For example, every block (some unit of bytes) of a given file should 
be able to exist in multiple places (on the web, not just on a server), 
etc.

Let's solve everything in one place once and for all.

the main problem I think with this kind of hierarchical and dynamical 
size struct is to be anought performant and close to the original 
to save code writing  time and tu enhance the loading performances 
in such tasks. Actually you need to parse and readapt each data from 
the binary dump file to rebol based   things. And that's an heavy 
task


This can be usefull for all langages that allow binary dump file 
read/wirte like C, VB and many others.

//-------------------------------------------------------------
//- Load
//- Loads an MD2 model from file
//-------------------------------------------------------------
bool CMd2::Load(const char * szFilename)
{
	unsigned char * ucpBuffer = 0;
	unsigned char * ucpPtr = 0;
	unsigned char * ucpTmpPtr = 0; 
	int iFileSize = 0;
	FILE * f;
	
	if(!(f = fopen(szFilename, "rb")))
	{
		APP->Log(COLOR_RED, "Could not open MD2 file %s", szFilename);
		return false;
	}

	//check file size and read it all into the buffer
	int iStart = ftell(f);
	fseek(f, 0, SEEK_END);
	int iEnd = ftell(f);
	fseek(f, 0, SEEK_SET);
	iFileSize = iEnd - iStart;

	//Allocate memory for whole file
	ucpBuffer = new unsigned char[iFileSize];
	ucpPtr = ucpBuffer;

	if(!ucpBuffer)
	{

  APP->Log(COLOR_RED, "Could not allocate memory for %s", szFilename);
		return false;
	}

	//Load file into buffer
	if(fread(ucpBuffer, 1, iFileSize, f) != (unsigned)iFileSize)
	{
		APP->Log(COLOR_RED, "Could not read from %s", szFilename);
		delete [] ucpBuffer;
		return false;
	}

	//close the file, we don't need it anymore
	fclose(f);

	//get the header
	memcpy(&m_Head, ucpPtr, sizeof(SMD2Header));

	//make sure it is a valid MD2 file before we get going
	if(m_Head.m_iMagicNum != 844121161 || m_Head.m_iVersion != 8)
	{
		APP->Log(COLOR_RED, "%s is not a valid MD2 file", szFilename);
		delete [] ucpBuffer;
		return false;
	}
	
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetFrames;

	//read the frames
	m_pFrames = new SMD2Frame[m_Head.m_iNumFrames];
	
	for(int i = 0; i < m_Head.m_iNumFrames; i++)
	{
		float fScale[3];
		float fTrans[3];
		m_pFrames[i].m_pVerts = new SMD2Vert[m_Head.m_iNumVertices];
		//expand the verices
		memcpy(fScale, ucpTmpPtr, 12);
		memcpy(fTrans, ucpTmpPtr + 12, 12);
		memcpy(m_pFrames[i].m_caName, ucpTmpPtr + 24, 16);
		ucpTmpPtr += 40;
		for(int j = 0; j < m_Head.m_iNumVertices; j++)
		{

   //swap y and z coords to convert to the proper orientation on screen

   m_pFrames[i].m_pVerts[j].m_fVert[0] = ucpTmpPtr[0] * fScale[0] + 
   fTrans[0];

   m_pFrames[i].m_pVerts[j].m_fVert[1] = ucpTmpPtr[2] * fScale[2] + 
   fTrans[2];

   m_pFrames[i].m_pVerts[j].m_fVert[2] = ucpTmpPtr[1] * fScale[1] + 
   fTrans[1];
			m_pFrames[i].m_pVerts[j].m_ucReserved = ucpTmpPtr[3];
			ucpTmpPtr += 4;
		}
		
	}

	//Read in the triangles
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetTriangles;
	m_pTriangles = new SMD2Tri[m_Head.m_iNumTriangles];
	memcpy(m_pTriangles, ucpTmpPtr, 12 * m_Head.m_iNumTriangles);

	//Read the U/V texture coords
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetTexCoords;
	m_pTexCoords = new SMD2TexCoord[m_Head.m_iNumTexCoords];
	
	short * sTexCoords = new short[m_Head.m_iNumTexCoords * 2];
	memcpy(sTexCoords, ucpTmpPtr, 4 * m_Head.m_iNumTexCoords);

	for(i = 0; i < m_Head.m_iNumTexCoords; i++)
	{

  m_pTexCoords[i].m_fTex[0] = (float)sTexCoords[2*i] / m_Head.m_iSkinWidthPx;

  m_pTexCoords[i].m_fTex[1] = (float)sTexCoords[2*i+1] / m_Head.m_iSkinHeightPx;
	}
	
	delete [] sTexCoords;

	//Read the skin filenames
	ucpTmpPtr = ucpPtr;
	ucpTmpPtr += m_Head.m_iOffsetSkins;
	m_pSkins = new SMD2Skin[m_Head.m_iNumSkins];
	
	//Load textures
	for(i = 0; i < m_Head.m_iNumSkins; i++)
	{
		memcpy(m_pSkins[i].m_caSkin, ucpTmpPtr, 64);
		//hack off the leading parts and just get the filename
		char * szEnd = strrchr(m_pSkins[i].m_caSkin, '/');
		
		if(szEnd)
		{
			szEnd++;
			strcpy(m_pSkins[i].m_caSkin, szEnd);
		}

		m_pSkins[i].m_Image.Load(m_pSkins[i].m_caSkin);
		ucpTmpPtr += 64;
	}
		
	delete [] ucpBuffer;
	return true;
}

well now i know better how to handle REBOL -> C and C-> REBOL the 
idéal thing could be a convert-reb-to-c multi type, multi size native! 
function in Command and in REbol/view Pro (I think it will be added 
to core any way than accessible if you have the licence.key file)

Just trimmed about 100 people from the Library membership list....
http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-view-users.r


A lot of them were drive-by signups by spammers to get their URL 
a link ("Hi I'm Mandy, click my link for photos") And most of *those* 
must have an IQ hovering aound their waist size because they'd failed 
to click the profile option to make their URL visible to other Library 
members.


So the membership list (claiming 200+ members) is more relevant than 
it was before.


But the automated expiry script may have caught some genuine members. 
If your userid has gone and you want it back, please drop me a private 
message.

pow!  all fixed  :-)  just need to let slim  build the new release 
from all the included files and we are set !  I will also be doing 
just a little bit of cleanup within GLayout to reduce the size of 
the final single-file app...

as usuall, type the following in a rebol console to open up the tool.

do http://www.rebol.org/library/public/repack.r


also note that I put a lot of effort in optimizing the file's final 
size, including a lot of hacking out, removing comments, compressing, 
etc... its now a much smaller download.

We are glad to announce that a newer version of the rebol.org package 
downloader is now available for people using REBOL|view 1.3.2

as usuall, type the following in a rebol console to open up the tool. 
it now adapts to version automatically
<pre>do http://www.rebol.org/library/public/repack.r</pre>

also note that I put a lot of effort in optimizing the file's final 
size, including a lot of hacking out, removing comments, compressing, 
etc... its now a much smaller download.
This version uses a slick 
new version of GLayout which has gfx largely based on Henrik's tests 
which he supplied a few weeks ago...

Gabriel -- Thanks....A word list sounds a good way to go.
***

Jean-Francois -- a hover-over on kewords is certainly do-able and 
could look fun for the first couple of minutes on colorised scripts. 
Though it has drawbacks:
** it'd just about double the size of the page

** I think I'd be serious annoyed by it after 30 seconds -- though 
that may just be me

** lots of hidden-by-css styles (that's the way I'd do it, usng some 
of Eric Meyer's clevernesses) could create confusion for anyone using 
an elderly web browser or screen reader.


A good step in the right direction would be better styles for the 
code as we display it now.....So anyone experimenting with that is 
doing us all a great service ... Amd it would pave the way by creating 
a better foundation for higher cleverness.

I thought it might be version related, but one of the VID versions 
I have exhibit the problem:
** Script Error: Cannot use multiply on none! value
** Where: edit-text
** Near: 2 * face/edge/size

http://www.rebol.org/cgi-bin/cgiwrap/rebol/discussion.r?script=calendar.r

Looks like this line is the problem:

        dp-area: area (dp-info/size - 4x0) ivory ivory edge [size: none] 
        with [show?: false ff: day: time: none]

Change to:

        dp-area: area (dp-info/size - 4x0) ivory ivory edge [size: 0x0] with 
        [show?: false ff: day: time: none]

sunanda:  I have a feature proposal for you  :-)


it would be nice to be able to supply a single picture to link with 
the scripts. this image (jpg, png, gif) would have hefty size limitation 
and I think only one image per script should be enough, but having 
this alongside the various listings of the application and within 
searches, new scripts, etc would be really cool.


sometimes, if you see a thumbnail (ui grab, console example, logo, 
output gfx, whatever), it will help raise people's curiosity.  this 
could probably benefit quite a few scripts, which are possibly overlooked.


having a simple search filter of scripts with pics, could also help 
people to quickly find usefull things at a glance.


what do you think?  it could start out really simple, and slowly 
thumbnails could creep into various listings of scripts.

yes, in the script description above the start of the script, under 
the :


     [View in color]   [View discussion [1 post]]    [License]   [Download 
     script]    [History]  [Other scripts by: moliad]



menu... just a list of uploaded images with a one line caption when 
you click on it, showing the full image. obviously, you should impose 
strinct size limits, enforcing proper compression.  and potentially 
a maximum size.

>> help new-line
USAGE:
    NEW-LINE block value /all /skip size

DESCRIPTION:
     Sets or clears the new-line marker within a block.
     NEW-LINE is a native value.

ARGUMENTS:
     block -- Position in block to change marker (Type: block)
     value -- Set TRUE for newline. (Type: any)

REFINEMENTS:
     /all -- Set/clear marker to end of block

     /skip -- Set/clear marker periodically to the end of the block
         size -- (Type: integer)
>> a: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> new-line a true
== [
    1 2 3 4 5 6 7 8 9 10
]
>> new-line a false
== [1 2 3 4 5 6 7 8 9 10]
>> new-line/skip a true 2
== [
    1 2
    3 4
    5 6
    7 8
    9 10
]

>> help checksum
USAGE:

    CHECKSUM data /tcp /secure /hash size /method word /key key-value

DESCRIPTION:
     Returns a CRC or other type of checksum.
     CHECKSUM is a native value.

ARGUMENTS:
     data -- Data to checksum (Type: any-string)

REFINEMENTS:
     /tcp -- Returns an Internet TCP 16-bit checksum.
     /secure -- Returns a cryptographically secure checksum.
     /hash -- Returns a hash value
         size -- Size of the hash table (Type: integer)
     /method -- Method to use
         word -- Method: SHA1 MD5 (Type: word)
     /key -- Returns keyed HMAC value
         key-value -- Key to use (Type: any-string)

because it is clean 5.0.18 install and second, the field size is 
41 bytes, starting with asterisk ...

BurningShadow just changed the live CD from 7-Zip to RAR for the 
size, but that's up to him. The main Syllable project recently changed 
application packages from GZip to Zip. The compression is worse, 
but this allows us to include extended file attributes, so that's 
a completely different consideration

I run hoary on two Ubuntu machines. no problems except the font size

I installed Warty. Is the font size in /View a problem on Hoary?

ok, DPI setting for the ubuntu box is 96 DPI. maybe AltME has an 
"anti-garbling" feature of headlines by turning down the font size 
while everything else is bigger

No, font-size-problems. before the default was to large, and some 
things like h1 did not work.

Is there any specific need to make View 1.3.50 running under Linux:
- It runs right while clicking the icon
- it fails to run from a terminal:
	./rebol
	** User Error: REBOL: Cannot connect to X server
	** Near: size-text self

fnt1: make face/font [
	name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
	size: 32
]
fnt2: make face/font [

 name: "/usr/share/fonts/truetype/freefont/FreeSansBoldOblique.ttf"
	size: 64
]

view layout [
	origin 0
	box snow 400x100 effect [
		draw [
			pen black
			font fnt1
			text anti-aliased 0x0 "Rebol Rulez!"
			pen blue yellow
			fill-pen red
			line-pattern 10 10
			line-width 2
			font fnt2
			text vectorial 0x30 "Rebol Rulez!"
		]
	]
]

oke.. with 32 and 64 in size ?

Its strange.. I should not be needing to run a fontserver..My desktop 
is already anti-aliased with fonts and so it the rest..But rebol 
still does not display it... mmm It does load the font though..(also 
when i look with an Strace during the execute rebol does read the 
font..) it simply does not display it ..yet! ;-)

>> probe fnt1

make object! [
    name: "/usr/X11R6/lib/X11/fonts/TTF/VeraMono.ttf"
    style: none
    size: 32
    color: 0.0.0
    offset: 2x2
    space: 0x0
    align: 'center
    valign: 'center
    shadow: none
]

just tried it with:
fnt1: make face/font [

 name: "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf"
	size: 32
]
fnt2: make face/font [

 name: "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBI.ttf"
	size: 64
]

Hello everyone..
I have a CGI problem/question.


I have a Win-apache-rebol server that isn't propagting the cgi info 
properly..
Upon posting.. the query-string is empty.
I am not sure what I am missing..

Details:

page1.rcgi
========================
#!c:\rebol\rebol.exe -cs
rebol []
print "content-type: text/html^/"
print "<html><body>"
print "  <form action='page2.rcgi' method='POST'>"

print "    <input type='text' name='var01' size='16' value='test'>"
print "    <input type='submit' name='go' value='Lookup'>"
print "  </form>"
print "</body></html>"


page2.rcgi
========================
#!c:\rebol\rebol.exe -cs
REBOL [ ]
print "content-type: text/html^/"
print "<html><body>"
print mold system/options/cgi
print "<hr>"
print "</body></html>"



if I .. ( decode-cgi system/options/cgi/query-string ), my vars are 
all undefined.

Also, looking at the 'print mold system/options/cgi' shows   query-string=""

if I change page1 form-action to ... "action='page2.rcgi?x=123"

then the query-string on page2 gets populated with x=123 and the 
value 123 gets assigned to 'x'
when I 'decode-cgi'.

However, my form fields NEVER get populated.
Does anyone have any advice?

John.

I asked for mu web service provider to add linux-gate.so.1 to the 
server he did not aprove that he did (actualy I did not get any answer 
yet), but today I found that my test script:

 #!/var/www/cgi-bin/rebview -cs

REBOL [Title: "CGI Basics"]

print ["Content-type: text/html" newline]

print "Heloooooo!!!"

works differently - I am getting following response:

** Near: size-text self

You can check: http://www.jk.serveris.lv/cgi-bin/test

What could it mean?

Anton, do you have any idea about ** Near: size-text self  with Linux 
and rebview for cgi?

hmm, size-text - it does sound like a native. IMO it is wrapper for 
OS level function, returning pixel size of particular text .... could 
that be a problem of some missing os library?

size-text: xwindows is client/server. the x-server , that is your 
local computer, which offers to aplications to display things to 
you. And it has some important informations locally, especially the 
fonts (and can cache images and such).

/view needs access to the fonts and so access to a running x-server. 
the x-libs are only an interface to connect to the server. (The xserver-libs 
could be used directly, but well, /view does not do that. Seems to 
be tricky.)
A incomplete sketch how to do it, with no attention to security:

So with /view you need a running x-server, one way to do that  headless 
is vnc.  Can also run on another machine. 

Then you need to tell  rebol where it is, there is an env-var $DISPLAY. 
Which must be set before rebol runs. Did not figure out how to configure 
that. Running a bash-script as cgi, set  $DISPLAY, call the real 
rebol-script should work. And there may be issues with authentification, 
x-windows does not like everyone to connect by default, or the other 
way around, its too easy to make it too open ("xhost + ip"). There 
are more secure ways, but looked more complicated and i never tried. 
All in all i would run such things on windows.

well, it's a no go for me. everything has to be bundled into a single 
lightweight package. I think it's a little absurd having to blow 
up the app by a factor of 2-5 in size, just to get pretty thumbnail 
generation for it. I hope a future version of DRAW will allow better 
downscaling.

Yes, more input-file fields is possible as well, just you may reach 
the upload size limit more easily. Most servers I used has maximum 
2MB per post, so if you want to upload 5 images with 1MB, you will 
not be able to post them at once.

One of my clients updates his site via some tool, which always seem 
to add some space between the lines. After some time, the page is 
instead of 400 rows something like 13K rows - the size goes from 
cca 25KB to 100KB. So I wrote a cgi script, which reads index.html 
and removes blank lines. Everything is OK, when I run the script 
from the console. But when I run it via a browser as a CGI script 
call, it can't write the file. Dunno why - cgi-script is being run 
using -cs switch, I even put secure none in there, cgi-script has 
the same own, grp set as index.html, but I can't write it ....

I have to admit, I'm awed by the size -- is this the least that it 
will take to get a reasonable XML implementation in Rebol?  And how 
to manipulate and store a SAX structure?

The size would make me apprehensive about dropping it casually into 
a project.

and besides that - look at other XML libraries ... compress your 
script and the size is ok :-)

But that'll add to the size. I like RebXML to take up minimal space.

About memory for block or object, If you mean in bytes internally 
in REBOL, I don't know. But you could save the block or object to 
a file and see a size that way. You can of course see the length 
of a serie with: length?

Got databases over 2Gb in size

Very nice looking ! May I criticise your knobs though ? They are 
a bit big. Before long, you won't have any room left ! :) I suggest 
make them half the size in width and height.

Thats the right size to refresh my knowledge :)

Try with :

interpolate: func [series1 series2 chunksize /local ts1 ts2 c][
	ts1: copy series1
	ts2: copy series2
	c: copy #{}
	forskip ts1 chunksize [
		insert/part tail c ts1 chunksize
		insert/part tail c at ts2 index? ts1 chunksize
	]
]


Why do you copy the 2 series? It's not required here, you're not 
modifying them.

You should also pre-allocate the 'c buffer : c: make binary! <max-size>.

IIRC some script in the library says there are more options, buffer-size 
and something. rebol can output nearly gzip, but read only a specific 
version.

rebol [
	type: 6
	file: %test.swf
	background: 0.0.0
	size: 260x185
]
doAction [getURL("http://box.lebeda.ws/~hmm/rswf/""_self") ]
showFrame
end

Yes, in specific commercial sector people expect the 'conservative' 
look&feel. But  this feature should be provided as an external solution 
mainy due the increase of binary size of Rebol in that case. I think 
sch module would be for about 2MB in size.

pekr, of course all these things are already available for OSX and 
have been for a long time. One thing that kind of surprised me is 
how many apps surpass Windows equivalents in quality, simply because 
the underlying foundation with Cocoa is incredibly strong. You can 
tap into a lot of amazing functions and the OS itself can do things 
where Windows would need third party software to do the same.

For example, look at Jaime's presentation from the REBOL conference. 
It was done in Keynote which is a presentation program made by Apple 
which makes Powerpoint look like a silly joke. It uses full 3D hardware 
acceleration and can apply pixel shader effects to the presentation 
through Core Image. By having a very strong set of video functions 
as well, presentations can be exported to a lot of different videoformats 
from DV to H264 or MPEG4, etc. in any size or framerate. You can 
also convert parts of it to a PDF document or a bitmap image. All 
this is possible, because OSX does this in Cocoa and is available 
at the developer's fingertips. This is also what made apps like iMovie 
possible, because they integrate into OSX.


Often the wrong question to ask is "Does program X exist for OSX?", 
because the programs are different and often of much higher quality. 
A lot of programs don't even have Windows equivalents. The community 
reminds me a bit of what bedroom programmers did during the old days 
of the Amiga, when they used the hardware and made beautiful demos. 
There are a lot of small, free apps available that do 2-3 things.

thanks for the info. The alternative I was considering was a shuttle 
barebone http://eu.shuttle.com/en/Desktopdefault.aspx/tabid-72/170_read-11083/
 which comes at about $300 more but it's at least 3 times the size 
of the Mac mini and probably noiser . The barebones do have a normal 
fan in addition to the CPU fan and that makes them noiser

Henrik: and don't forget HP on huuuuuuuuuuuuuuuuuuuuuuuuuuge drivers 
size (near 400MB for a printer driver! Go crazy)

I have a Samsung 213T (1600x1200), and like it very much. I do use 
the larger font size in AltME though. Not as big as the Dell, but 
there are good deals to be had on it.

one issue is size. do we distribute /pro/view to everyone, and make 
everyone download a bigger file? or do we have two different plugin, 
two different sizes?

this could easily be handled like a cache and user could impose size 
limits on individual and collective size of all sessions.

Could we enforce a minimum window size ? Think of the minimum window 
size we have here on WinXP. Never bothered me before.

Do you think a minimum window size would be good ?

For that matter, is it possible to specify the size of the client 
area relative to the page size, have it resize with the page, and 
have the REBOL layout inside handle the resize as if a View window 
had been resized by the user?

But a more elaborate benchmark may show closer results between these 
too. Size of files and OS have big impacts on the results.

revver: We do have a size restriction of 100MB per file

I've started on a hex-grid generator. Handles grain, background image, 
terrain and grid size so far.

So, let me help you help me (I have designed about 120 video games). 
  You need to break down your art as follows

 name, size, comments

For example

In looking at your image names, I can't map them to "purpose"

What are card and card1?


May I suggest  you rename things first, and a smart move is to put 
in place holder art that is the size you want to finally use.  Even 
if it just has the name of what will be there, ie "Gold" etc.

For the Icons at the top: Blue = Crystal Mines, Green = Forests, 
Red = Gold Mines.  These are your base resources that reproduce each 
turn.  They create stockpiles of Energy, Wood and Gold respectively. 
 These stockpiles are used to activate cards in your hand.


card.png is the 'hidden' or deck card face.  This is used to hide 
the computer's cards and the deck and discard piles.  card1.png is 
a sample of the format that the card images are in.  This can be 
used as a basis for creating new cards to the correct size.  (86x64 
pixel size with a 7x7 pixel offset into the card1.png template). 
  I have a card editor that can add in the card details to match 
their stats etc.


Regarding image names - ill compile a full list and place it on the 
website later today once i finalise the deck size :)

RebTower 0.0.4 released.  This version is playable :)
Quick notes:

left click a card to select it (it will enlarge in size) then either 
left click it again to replace it or right (Alt) click it to play 
it.

only cards that are alpha/0 (ie solid)  can be played unless you 
are discarding.
if all your cards are transparent you will have to discard.

the object of the game is to destroy your oponnents tower while keeping 
yours alive.


Yes, I know the debug info is still displaying - the final image 
cards are not ready yet :)