AltME groups: search

hmm, but LNS is also a transport in itself. It at least can work 
upon http and cgi ...

All of these are transport layers, even Uniserve (which works on 
TCP). As long as things are simple at a given layer we're fine.

Pekr, you're welcome to use the fms applications at rockfactory.us 
for any virtual conferences you want to set up, if that'll help at 
all ... that is, until we get a full REBOL video conference solution 
:)

My response to a query aboit REBOL3 on REBOLtalk would not make a 
marketing person happy:
-- year old alpha
-- no obvious contact details for those wanting to get involved.
Could someone better connected do a better job, please?

http://www.reboltalk.com/forum/index.php/topic,1827.msg4644.html#msg4644

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

Petr -- But there needs to be some evidence that the project is still 
alive and deliverying.
A one-year old public alpha is not that.

You will surely agree, that so far, supporting C code is mostly a 
joke ...

re R3 /library. I talked about it with Carl one year ago. He was 
not sure /library component will be added as-is. Instead, he thought 
about making it a plug-in. But - plug-ins are done from some 80%? 
They also need 'modules, whicha re not finised too. But - we could 
do some preparation work.

I think, that having really good /library component could bring us 
many more wrapped external libraries - call it a deployment. Currently, 
we are missing on most of outer library stuff, and we are living 
in rebol-only world.

yess. doing a C/C++ importer is possible.  especially for dll stuff 
which is autodocumenting in many cases.

but my .dll question was the opposite.... using rebol.dll within 
a C application... are there any docs about doing this yet?  compiling 
your own interpreter, linking in your stuff on the C/C++ side of 
things is probably easier.  than trying to tie them up from the rebol 
side of things...

Maxim, no docs on .dll yet. The current alpha is a single .exe.

I am slowly working towards elixirOS and that is a C version of elixir 
with rebol being the conscious brain, driving subconscious C datatypes 
and binary code...

not ready yet, but just wanting to see where things are now, so I 
can place my time and efforts properly.   Already started to look 
at OpenGL a bit and started doing C++ again.

If you set it up, I will participate :-)   I have done library stuff 
a few times, even fixing ladislav's memcopy hacks once. 


 right now, I am faced with an signed/unsigned issue related to 16 
 bit values needed for a lib call... I honestly can't say from the 
 library docs, if the negative 32bit value in rebol's integer will 
 stay negative once converted to 16bits... for example. 

 this kind of information is Crucial for stability.

also, for lib usage a GC-independant alloc() dealloc() equivalent 
would be VERY usefull.  something we can manually free, in order 
to work with large dataset we really don't want the GC to grab.  
for example, using image magic, I can work with 10GB image files. 
 composing 100 of those images into another.  I can't let rebol's 
GC play around with such specific needs... this is just one example, 
but there are others.


sometimes handling stuff manually is easier than hoping an automatic 
system will do so properly.  in R2, images are never freed, for example, 
so for a task which rebol would be the ultimate image manipulator, 
I can't use it cause the third image I load from disk craps out rebol, 
since it grows beyond 1.5GB of RAM.

one question - isn't there any cute, cross-platform C compiler, which 
would not add more than 30KB to REBOL.exe, and could be included 
as a variant of rebcode? :-)

nope...  its all working within the GC ... from the library docs: 
"For example, if a REBOL word that was defined as a struct! is reused 
to make another struct!, the memory used by the first struct! becomes 
unreferenced. Any unreferenced struct! values may be reclaimed by 
the REBOL garbage collector, even though the memory is owned by an 
external function."

yess I did, but in this case, the goal is to do interactive AGG manipulation 
of one image at a time and stamp it on a layered composition.  by 
the time I load the third image (from a digital camera at 7.1 MPixel), 
rebol crashes  :-(

(well maybe more than 7.1MPixel. but anyways... the fact that REBOL's 
memory footprint grows everytime I do load on a .png... and never 
shrinks... means it will eventually crash, whatever I do  :-/

I have a script that invariably dies doing png stuff.

Maxim, does it also happen if you load it into a pre-allocated binary 
and clear it when you're done?

Maxim, no forget my question (takes too long for me to come up with 
a solution, and I must get back to work).

when I was doing my app, I was able to break rebol just with a make 
image! and some use of it in a function... but right now... can't 
remember the exact pattern I was using... calling make image! 10000x10000 
twice is currently behaving correctly, growing to 800mb and shrinking 
back to 400mb

it was probably related to using the image in view or AGG specifically, 
or maybe specifically to using a png format image.

image magic rendered the equivalent of 100GB of image data for 1h30 
at 100% CPU usage (and only a few hundred MB or RAM) and didn't fail... 
so I was very impressed by it, in any case

if I ever get back to that project (which is related to a visual 
arts project) I'll investigate further, but in any case, I'd try 
first within R3.  I imagine that its better to debug them there within 
the gobs, if there is still an issue related to this... which I expect 
not to be the case anymore, since most if not all of this was rewritten.

I'm having a memor issue too.

I have an app that uses a scroll panel that I fill with text and 
images (a "page"). Each time I change the panel data (the "page") 
the memory footprint increases. But If I reload a "page" that was 
previously displayed memory size  does not change.

I can see if the memory holding the "page" does not clear properly 
but how does it know that the "page" is already in memory?
I'm holding the composed data in a block - 
	page: copy [ composed page data ] 
and I clear it befrore rebuilding it - 
	page: copy [ ]

as long as you have a single word pointing to data, it stays in ram. 
 so if you re-link it within the face without changing it, all its 
doing is basically a window refresh.

I'm changing the content (text and images) of the page each time 
I "show" it in the scroll panel. And each time I "show" a new "page" 
memory use increases but if I re-"show" a page that was previously 
viewed memory use does not change significantly.

I am not very experienced in how making bindings in various scripting 
languages work but I have fiddled around this a little... python 
by itself doesn't do anything automatic I think - and to my knowledge 
python isn't the best example of easy binding to c libs, but there 
are comunity provided tools that help you generate the interface 
code etc...  most people I saw used SWIG (which works for a lot of 
languages) http://swig.sourceforge.net/.. but the chat was that 
if you use that tool you geet quite a bloated code for interface.

If you want to look for languages that provide very elegant way of 
making bindings you should to my knowledge look at Lua (lua started 
with this) , lua provides simple to understand stack approach. Then 
there is haxe which provides even more elegant way to do this . Both 
languages also enable to embed the VM/interpreter into C++ app. I 
have used both to do both and it was very simple as I am not a power 
low level programmer

The most elegant binding I have seen so far was done by Factor .. 
there you don't even have to "code" in a classical sense, you just 
define the interface and that's it ... as I said I am not very experienced 
in all this (I hacked factor's sqlite binding and to add another 
c function inthere I just added 1 line.)

this is a link to nekovm's FFI , pretty simple to use http://nekovm.org/doc/ffi

Rebdev only R3?  Or can a R2 client be written?

Does anyone know if REBOL3 will include REBCODE functionality?  If 
not, then it would be cool if we could DO rebcode from a REBOL3 script 
somehow.  Such as DO %rebcode.bin to give us the functions of REBCODE 
to use in our scripts.

There is no rebcode in R3 as it would be a different challenge to 
put it in there than in R2. R2 also offered certain tricks that are 
not possible in R3, which would make rebcode run slower in R3. BrianH 
has explained this a few times (but I can never remember the exact 
explanation :-)).

Would be nice to just pass the arguments to a rebcode module and 
have it pass them back.  Even giving rebcode networking features 
might enable that.

Henrik, do you know if Carl  would be up to building a rebcode based 
2.7.6?

That's a special build. Also rebcode was never really finished as 
there are security issues with it.

I would use it if it were a separate process that I could access 
via networking port just to get to the computational  advantages.

it's a full REBOL/View build, so it should work

I think that TCP/IP is pure async and HTTP also, but functions like 
READ would work in a synchronous manner.

On another note, a new R3 internal release was made a few hours ago 
with all of BrianH's changes submitted to DevBase. Yay!

Petr (from Ports):
http://www.rebol.net/wiki/Port_Implementation
http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples(a good one ....)

http://www.rebol.net/r3blogs/0127.html"Pruning down Read and Write"
http://www.rebol.net/r3blogs/0128.html"Skip and Seek on ports"

http://www.rebol.net/r3blogs/0129.html- async http transfer using 
tcp

http://www.rebol.net/r3blogs/0130.html"More about port layers" (continuation 
of Pruning down Read and Write article)

Just discovered today in R2: LOAD/header has two errors.

- LOAD/header of a directory should fail with a syntax error, but 
doesn't.

- LOAD/header "rebol []" or the script equivalent should return the 
header object in a block, but instead returns it straight.

The /header option is being checked at a lower priority than it should 
be. Fixed in R3 today though.

LOAD is a mezzanine in R3. You have no idea how cool this is :)

Re; LOAD; well yeah ... TRANSCODE can be used to support junk! now. 
 ;)  You'll love it Brian, really.  You can have your grandma asking 
you questions about deep deep PARSE problems as she dances around 
the console analyzing her grocery list, while you point out that 
the total is actually wrong due to a lexical problem with some of 
the money! values.  Then, 4 months later, she'll teach you something 
that her new perspective and point of view made possible as she unveils 
the world's greatest home management software ... like evv-a.   :)

Sorry BH, I meant junk!  and a version of REBOL that loads any value 
any time any place by anybody.

And do dis' meant toward grandma.  I would have guessed she had IQ, 
many times it is a family trait.  ;)

Write it yourself. Use a user-defined junk! string type, and your 
own LOAD to work with it. It's easy (for experts). I've rewritten 
LOAD several times in the last week, twice today :)

You don't want LOAD to be relaxed by default - that would be a debugging 
nightmare. I think that an optional user-provided fallback function 
would be a better choice. I'll look into retrofitting LOAD with one 
once we get LOAD/next working.

You certainly don't want a junk! type by default.

And re debugging, no I don't think so.  touching junk! would throw, 
and throw hot perhaps.  But it could float around in a block happily 
waiting to be analyzed or triggered.


Dang, another promise broken in under a minute.   One thing, REBOL 
can sure induce passion!   Now, there is a name for a datatype!

for people learning the language and for many short scripts... the 
able is a simple no-brainer, which just works.

The debugging problem is that the locality of the error is lost. 
By allowing invalid data to be loaded, you put a timebomb in your 
data to be triggered at some later time, by code that doesn't see 
it coming. You want errors in your scripts to be triggered as soon 
as possible, and as close to the source of the error as possible, 
or you'll never find it.

Errors are the best friend a proigrammer can have.

That's why I think fallback processing is a better solution.

and having to create a callback for it would also have been much 
harder than just not doing anything with it.

and giving a dead-simple way to ignore or trap it is in line with 
rebol's kiss philosophy IMHO.  


but I do think that for serious *parsing* and dialecting, your proposal 
is much better.

just a thing, as far i know, "comma" are used no where in rebol values 
(except in replacement of points) why are they not handled by load 
as a separator like tab or blank

there could be a /separator refinement also!  btw.

For a fallback option, I'm thinking a function argument which takes 
one parameter (the input at the point of failure), or perhaps one 
of a set of words that denote standard handling strategies (like 
'skip).

Prohibiting commas was a deliberate design choice, one I agree with. 
REBOL is not C or English.

You can't see a tab or newline (not really).

block: [a,b,c,d,e,f]; should be allowed with comma as blank separator

but when loading from a string yes.

what we are saying is that there should then be a function called 
"impoert

Brian we know historicaly that the prohibition is a wrong way ;-)

probably Carl during his childhood was hurted by a comma so that 
he can't see them now

a simple CSV file, for example.

People underestimate how much thought went into the REBOL syntax. 
REBOL was carefully and deliberately designed for quick programming. 
One of the most important choices was to not use commas and periods, 
because it is tricky to tell them apart or see them when reading 
a lot of code. They are not used in numbers either, because they 
are ambiguous in internationally visible code.

brian, allowing a relaxed mode alllows me to be quick. as opposed 
to try and manually redo what rebol does already.  using the actual 
commas within code IS evil, don't get me wrong.

Unfortunately a lot of the syntax choices were based on the US keyboard 
(hence the [ and ]).

but parens imply an expression... not containment... so I do feel 
that the use of ( ) is not very a very good choice for rebol, where 
both are intrinsically different in rebol.

Brian ( ) are used a lot in human languages ;-)

[

, "]", "/" and "-" were chosen because they can be typed on a US 
English keyboard without using the shift key. The fact that you can 
program in REBOL without using the shift key most of the time speeds 
up your typing of REBOL code (though not the name REBOL).

I'll just make a remark about "invalid" data.  If the lexical stashed 
those in foreign! it would no longer be "invalid", it would become 
the REBOL foreign! datatype!   You can't add email! url!   but they 
are sitll loadable values.   And again, professionals are NOT who 
I want to assist here.  It's the casual home user.   Allow 1000 casual 
users, 30 might become rebols, 1 might become a valued member of 
REBOL3 that we learn something from or develops Video Altme.   We 
add to the pile.

a comma would be lexically foreign!

I was typing in English, not REBOL. There's a difference.

brian, I think everyone is just talking about a standardized, way 
to load human-readable data.  we know its not REBOL data.

If can tell someone that he can use his "CURRENT" data directly within 
rebol, there is a chance he'll actually try it out..

I think we should have a function called 'ASSIMILATE.

For that matter, every option added to a function is an option that 
needs to be checked at runtime. That has overhead too.

If you want to make a grandma language, good for you. I say language 
instead of dialect because changing the syntax changes the langage 
- dialects use thee same data syntax, that is where they get their 
speed.

Do you not see the simplicity of foreign! data?   No speed problems, 
the lexical gets to a point where it would throw and it stashes a 
foreign!, keeps on truckin'.

Here's the current source for LOAD:

load: func [
	{Loads a file, URL, or string.}
	source [file! url! string! any-block! binary!]

 /header  {Includes REBOL header object if present. Preempts /all.}

;	/next    {Load the next value only. Return block with value and 
new position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data tmp
][
	; Note: Avoid use of ALL func, because of /all option
	if any-block? :source [return :source]

	data: case [
		string? source [to-binary source]
		binary? source [source]
		; Check for special media load cases: (temporary code)
		find [%.jpg %.jpeg %.jpe] suffix? source [
			return load-jpeg read/binary source
		]

  url? source [read source] ; can this possibly return not binary! 
  ?
		file? source [read source] ; binary! or block of file!
	]

 ; At this point, data is binary!, a block of file!, or something 
 weird.

	if binary? :data [
		unless find [0 8] tmp: utf? data [
			cause-error 'script 'no-decode ajoin ['UTF tmp]
		]

		; Only load script data:
		if any [header not all] [ ; Note: refinement /all
			if tmp: script? data [data: tmp]
		]
	]

	unless block? :data [data: to block! :data] ; reduce overhead

 ; data is a block! here, unless something really weird is going on
	tmp: none
	
	; Is there a REBOL script header:
	if any [header not all] [ ; /header preempts /all
		tmp: unless any [

   ;not any [file? source url? source] ; removed: hdr in string is same
			unset? first data ; because <> doesn't work with unset!
			'rebol <> first data
			not block? second data
		][ ; Process header:
			attempt [construct/with second data system/standard/script]
		]
		; tmp is header object or none here
		case [
			tmp [
				remove data
				either header [change data tmp][remove data]
				tmp: tmp/type = 'module ; tmp true if module
			]
			header [cause-error 'syntax 'no-header data]
		]
	]
	; tmp is true if module, false or none if not

 ; data is a block!, with possible header object in first position

	; Bind to current global context if not a module:
	unless any [
		unbound
		tmp ; not a module
	][
		bind/new data system/contexts/current
	]

 ; data is a block! here, unless something really weird is going on

	; If appropriate and possible, return singular data value:
	unless any [ ; avoid use of ALL
		all
		header ; This fixes a design flaw in R2's LOAD
		;not block? :data ; can this ever happen?
		empty? data ; R2 compatibility
		not tail? next data
	][data: first data]
	; If /all or /header, data is a block here

	:data
]

hell, I even have a "I LOVE BUSH" day every year... I'm 1/365 republican 
!

See, that is what we need! A separate function.

Ok, I'd gladly accept a separate function, but ship it with REBOL 
for grandma and the professors of the world.  Don't make them hunt 
it down and DO it as a special case.    But to be honest, I'd still 
prefer a foreign! datatype! and advertise REBOL as a human readable 
language.  Much power in that ad imho.

>>a: 1
>> t loop 1000000 [case [block? a [] integer? a []]] tt
0:00:00.534

>> t loop 1000000 [switch type?/word a  [block! [] integer! []]] 
tt
0:00:00.433

BT: It should at least be a separate function, but I suggest separate 
from the language too.  a) it's too much baggage, and b) the scope 
for recognising string patterns could better be handled in a more 
open way.

Too much baggage for the pros, yes.  Just right for a Professor of 
Geography or home user, imho.   Don't fear those that don't normally 
program, help them.  No?

Too much baggage for the language.  Perhaps it could be incorporated 
into a beginner's binary?  I understand the need, even for pros too...

I still don't see how a lexical foreign! would be that expensive. 
 Am I just not getting it?   Again, you cant   ADD email! url!  but 
they are valid types.  Make foreign! a valid type and then REBOL 
loads anything and series! operations can operate freely.

Adding a lexical foreign! means you add the overhead of checking 
for valid syntax to *all* REBOL code, not just LOAD. It removes your 
ability to trust that what comes out of LOAD is valid. That is a 
huge overhead to all REBOL code, and would be the source of most 
REBOL bugs in the future. It is a horrible thing to do to the community.

It becomes a new datatype! with the semantics of junk.

It can't throw an error, or you wouldn't be able to parse it to get 
anything ot of it. If it is another string type you'd have to check 
for it at every evaluation, because you aren't getting a nice error 
to escape out of yor code. It's either useless or a nightmare.

Yes, meaningless; but there would be less syntax errors.  And once 
in a block, cleaning could be done, but wouldn't have to be.  That 
would be up to the domain problem at hand.   I may never be convinced 
that having rules for what can be added would be that much different 
if REBOL were allowed to   make foreign!

so do [$10,000,000.00] throws, but   a: [$10,000,000.00] is accepted 
as foreign!