AltME groups: search

this week I'll begin writing a lot more about the concepts...
, which means it'll probably be ready in a couple of months. :-)

A little funny for those familiar with Jesse's diets : )

but does a panel be transparent  ?

enjoy folks  (more to come later that's only a 2 day work yes lot 
more things are to be done what  works the keyboard arrow left and 
right the backspace )

ouai  that's a little bug but hum I don't see it slow  really ....

...... 286 OMG !!! that's a museum piece ...

but but but buuuuuuuuuuuut buuuuuuuuuuuuuuuuuuuuut buuuuuuuuuuuuut 
that's a work in progress to bring join and hope to this world  ;P

even if you print the script and smoke it after that will not bring 
you a join ... (I think ... not sure ...)

your application is running around 3  times slower than on my computer 
(I dream of a quad core phenom  based computer ...)

one more week without news and I send a navy seal squad to Sasanrath 
Ranch to figure out  ...

no ... Carl asked a few questions about carets and then hid again.

I reaaaaaaaaaaaally appreciate if carl find us a better way to deal 
with selections (I remember when I developed MDP-GUI  that to add 
the flag around a selected bounch of text that was all a pain  in 
my poor brain...)

for vid what I like the most in most ofen case is not to have to 
write 1000  lines to display a button and what I hate is to have 
to write 10000  when i want to do exotic faces   ^^

yes  .... but that's a pitty because it's really open and powerfull

i need to implement so more things to get a complete multi line rte 
that's giving me a head hach

and more i need to find a good equation to remplace the damn switch 
for cursor motion

remove don't work the way it should be too ... that force me to do 
a foreach loop and that's slowing the delet process

example: >> a: [[a][b][c]] remove a [b]
== [b]
>> probe a
[[b] [c]]
== [[b] [c]]

but way [a] is gone and why [b] is still here ....

remove a [b] == remove process done [b] have been removed from the 
list a. Have a nice day shadwolf  you know you really rock  !!!  
probe a  == the list a contains [[a][c]] have a good day shadwolf 
you still rock you know i love you .... That's would be  the best 
^^

ok i made a quick patch for the bug graham noticed to me ( the right 
arrow not going  on the right side of the last char) you can find 
the new version here  http://shadwolf.free.fr/RTE-line-Shad-03.r

hum but it's fast on my computer and that's a pre-alpha double dash 
++ X 2008 version  (that's way there is the probes) If I go enough 
far in the process obviously I will do a clean share. That's just 
to show  wich direction it takes and puts some animation here while 
we are pending for news from R3 ^^. I plan even to declinate it to 
wrok with rebGUI and do a synntaxe colored widget wich could be used 
for an IDE for example

I will think in a better data scheme too because the way it's designed 
it's not to handle big text amount anyway ...

on my previous intent i was handeling the text as a subdivision of 
same way formated strings of char  and that was a pain then to get 
a precise text cursor motion and to insert new chars into an already 
existing and formated string

a way to reduce the data scheme will be to hum encode them into a 
fixed size string for example a12black for arial black 12 pt char 
 instead of storing for each char the corresponding values as splited 
 thing

and i need to find a good way to handle multiline fonctionalities

It would helpful if there were some community driven projects for 
designing R3 protocols. This is something that Carl doesn't need 
to be involved in until final inspection to see if it can be added 
as standard to R3. Although it's been said by Carl that he would 
change the TCP ports a bit as they were found to be too simple, I 
don't think it would be much of a hindrance to work on simpler protocols.


I wouldn't mind seeing out of the box support for LDAP, if it can 
be done in 4-5 kb of code. I know DICT is being worked on.

The full feature set of LDAP is quite complicated, but I think a 
basic interface would already help a lot

Having a play with REBOL3, and after modifying the sliding cat example 
to display data entry areas

instead in the scroll-panel,  I find that I cannot move to the 'next' 
field either by using TAB or CR 

What the 'secret' keystroke required ???

;; ===============================
rebol ["field-scroller.r"]
view [
    h1 "Modified Scrolling (SCROLL-PANEL and SCROLLER)"
    group 2 [
    
        tight bottom right    ; stick the panel to the scrollers
        scroll-panel 150x200 [
        
        datain: group 2 [
        	 label "fld 1 "  area  fld1:
        	 label "fld 2 "  area  fld2: 
        	 label "fld 11 " area  fld1: 
        	 label "fld 21 " area  fld2: 
        	 label "fld 12 " area  fld1: 
        	 label "fld 22 " area  fld2: 
        	 label "fld 13 " area  fld1: 
        	 label "fld 23 " area  fld2: 
        	 label "fld 14 " area  fld1: 
        	 label "fld 24 " area  fld2: 
     			]
         ]
        tight only bottom right
        scroller 20x200
        attach                ; attach scroller and scroll-panel
       tight only top right
        scroller 150x20

        attach -3             ; attach with scroll-panel            
    ]
 
]
;;=================================================

Henrik, LDAP is the lightweight reincarnation of X.500 (or X.400, 
I forget all the labels), a really heavyweight directory specification 
from the height of industrial age centralised organisations

But you're touching on a fundamental problem there. It's impossible 
to explain to people what lightweight is, because everyone thinks 
they're it

I mentioned LDAP because I naively thought it meant "a table of names 
and addresses", which I thought it can't be that hard to make. :-)

I think this is why LDAP is still a missing protocol for REBOL

It's funny though. When I think of something like a name directory, 
I wouldn't build such a complex system that fits everyone and everything, 
which makes it hard to support. I guess it comes with being used 
to working with REBOL for a long time, where I usually cook up custom 
solutions for each problem.

LDAP is really a database, for which you can define your own schema. 
The complexity is closer to a relational database than a basic Internet 
protocol

It does have a performance advantage, because it scales fairly well

REBOL will need LDAP if it wants to play in the Grid.  Web 3.0?  
Skip it for LCG maybe. Official VDT development tools for the Grid 
are still pretty limited; C, C++. Python, Java, Tcl; not many others. 
 We could play in this arena I think., but it'll require a fair amount 
ot back-filling to get to spec.  But will the grid ever hit consumer 
level?  I think so ... but maybe not.

I think also that whatever is made, should be documented in a cookbook 
recipe.

We'll need access to Berkeley DB too, (if the Grid stays in the current 
shape it is) so a good reason to link to libdb for RIF.


For LDAP, I think the protocol should be in a REBOL scheme.  But 
as stated, it's not a small task.


And for the Grid, we'll need certificate handlers, and encryption 
ports will work nicely for that.  With those three pieces, I think 
we'd be ready to introduce ourselves to the CERN LCG and VDT people 
 (Assuming they didn't shoot down the idea off hand due to not Open 
Source)  In which case we'd have to live outside the inner grid and 
float about the consumer grid.  No science apps would need apply, 
but the consumer grid could be a lucrative next step.  Maybe.

not a small task means we need to divide it into many small steps

There was some BDB driver in the past did by Jeff Kreis, but - we 
should refuse any driver with other than SQL .... I am a bit exagerrating 
- but why such arcane DB?

SQL is a lot worse, even, so that doesn't sound like a good idea

humwhat is the meaning of have yet again a half almost but not quite 
the same LDAPsupport i thought that was the problem within rebol 
?  we start things and never end them

Not to let it leak out too too much; I'm becoming a fan of BDB.  
It's used by OpenCOBOL.  BDB offers up access to ISAM, VSAM, lots. 
 RIF could be based on BDB.  I wouldn't want to RIF out of a SQL 
database.  Records, fields and keys.  He-man.


Kaj; you posted on the other world; but yeah, CERN's Grid is LDAP, 
BDB.  I don't care enough to risk life and limb or anything, but 
it would be nice if the scientist inventors got to see their work 
hit the consumer market somewhat pure of form and not splintered, 
at least once.  They won't.  That's what scientists get for giving 
their shit away I guess.  Morons.  :)


Although is may seem like a hinderance, at least we don't have to 
deal with REBOL the Microsoft edition being different than REBOL 
the Sun edition, being different than REBOLzilla.

Why dont to say what is for, this disscussion is like arguing between 
it is better a car or its engine,  sometimes you want to have comfort 
for rather complicated things let use SQL, sometimes you need only 
quick key-value store, let use kay-value DB (like BDB).

RIF should be a kind of key-value right?

I know nothing. The only thing I know that SQLite is the tinniest 
and still rather functionally sufficient (complex) piece of DB code 
since the slice bread, cross platform. I hope we will make it a plug-in 
at least. But - I still want RIF. RIF as some standard aproach, upon 
which we can build RebolDB engine - then I don't hesitate to use 
one, because it will be lean and mean, and standard ....

BT: BDB is incompatible across versions, so that whenever you install 
something that uses it it needs to install its own version; it is 
bigger than things like sqlite which are much more powerful; and 
if you need a real thing just use postgres or mysql. BDB is just 
infinite bloat...

If we combine RIF, R/S and REBOL itself, we can get CouchDB in half 
a meg.

Gabriele; True and a good point.   (I miss RMS on the Vax).  I have 
faith that RIF will come, and RIF will rock.

Re BDB;  Found this on the cuil.com main page of a rebol search, 
by fluke of timing more than anything.

http://www.cs.unm.edu/%7Ewhip/   Jeff Kreis' libdb interface.  Works 
great with 2.7.6 and the freed load/library.  I just had to tweak 
Jeff's libdb.c to use my setup and to get around that pesky incompatibilty 
that I blame on Gabriele now  :)

the discution on the R3 blog about text-options allowed me to enhance 
my RTE line so with a dedicace to graham here is the new version. 
http://shadwolf.free.fr/RTE-line-Shad-06.r^^

I've worked extensively for many months with a printing system for 
R2 and it works, but only in conjunction with Ghostscript. It's not 
possible to print directly to a postscript printer unless you want 
to adapt your output to each single printer to work around hardware 
bugs.

I've just built a direct printing library for R2, Windows only. It's 
a wrapper on Win32 Print API, so it supports all printers. It support 
a subset of Draw dialect as input. I was needing it to print reports 
for the project I'm currently working on. It still needs some additionnal 
work to be released publicly (like adding a port scheme layer for 
more intuitive usage).

Currently I use the postscript dialect and do a preview with draw, 
but because of the difficulties of rotations, and translations, anything 
that involves those screws up the screen preview.

Well, as my lib use Draw dialect, you can have preview support almost 
for free ;-). Scaling is supported by my lib, it even has a auto-scaling 
default mode to workaround different printer's hardware margins.

I was thinking about adding also a few other import filters for makedoc, 
pdf-maker dialect and View layouts, so something like this should 
be possible : write printer:// layout [...]

Once we have some sane documentation of the Windows printing model 
(read: the code you've written so far) it shouldn't be too hard. 
Not off-topis, btw: We can adapt your code to R3 and it might serve 
as the germination of a REBOL printing model.

I don't think so, as the library API is considered to be a good candidate 
for a complete redo as the Plugin API.

That doesn't mean we can't get started on designing a good printing 
dialect.

You did. R3 plugins are to be a cross between a REBOL module and 
a library wrapper, and can be dynamically loaded like modules.

So, do you mean that with R3 to access a DLL I have to build (in 
REBOL and/or C) a plugin, then dynamically load the plugin and then 
the plugin will load the DLL ?

It's not that different from writing a script wrapper for a DLL now, 
just easier and more powerful (in theory).

I expect that most useful wrappers will be a mix of both.

Well, in R2, you always have the option of writting a small wrapper 
DLL in C to interface with a complex API, if it's not possible to 
make a direct wrapper with only REBOL code.

Aside from knowing that they will be based on modules, no work has 
been done or published on plugins. Since even the module API is a 
work in progress, that means that all we have is discussions (unless 
Carl has been working on it in his current coding session, not as 
unlikely as you may think).

Some info from Carl from the past:


The DLL access is very complicated code that is specific to every 
CPU and OS.The DLL access is very complicated code that is specific 
to every CPU and OS.

The problem with plugin is not the code itself, but the security 
of it.

If we can set security aside for a while, we can certainly have the 
method for it.
I think it is probably ok for 3.0 to make this statement:

If you want to use plugins, you can -- but, you will want to only 
use those from trusted sources. Do not execute unknown plugins from 
the web.

the complex part of the security model is some method of digital 
signing.

We could use a simple hash method, but the problem is with public/private 
certification.

What makes it complicated is that we must port the R2 encryption 
code to R3.
That project could take a few weeks.

does because I can get a virus surfing the web i will stop surfing 
the web ? does because i can get virus through the maili will stop 
using email services ?

after if you really want to bring a 100 %  plug security you have 
to make the plugins centralised done only by RT and with some asymetirc 
key control system to ensure no one have modified the DLL  betwin 
RT repository and the customer compurter

now in day to damge your computer you just need to log it to internet 
without firewall and anti-virus no even need to do anything your 
computer will be infected straight by a tons of worms

digital signing is not the problem the problemis to whom rebol will 
ask a 100 %  trustable footprint patern ?

if RTmakesavailable  a signature bank for trusted pluging and when 
rebol runs a load-plug command this function send the name of the 
plug +  actual signature and compare it to what is stored in RT's 
bank but this mean offline using of plugs will be impossible

Hum I proposed long along when I was complaining about load/dll unfriendly 
shape to make a ported library repository wich you can find the standard 
libraries and the bridge to use them . the repository could be acknoleged 
by RT who will grant the lib is tested and safe download it and distribute 
is widely

now it depends of how do we considere the rebol sharings. what about 
those who want to build custom "plugins" based on official other 
libs but with only in it what htey need and not the whole thing (like 
SDK allows you to customise the VMrebol version you are going to 
share with your application...) Like rebolinforms the user when a 
rebol script is accessing external data it will be first  an information 
about the fact the script is about to load a plugin   and ask for 
user to continue or cancel. And if the user says yes then the answer 
is stored by rebol (in registry for example) so in next run the user 
is not bothered anymore. If the user is plugin to internet then rebol 
could check on the offical repository if the plug is safe or not 
this will give the user  an ensurance that the plug is safe.

once again load/DLL  exists for a long time but we can't says that's 
a widely used feature. Most because doing a bridge .R is painfull

audio converts to text and send it to the curent text field as if 
it was a normal keyboard input ?

Windows Speech Recognition must look at the context to see if the 
region with focus is a text field.

There's no way Windows can figure out what's in View windows. If 
WSR needs really just a native text field, a solution could be to 
make a true, but not visible, native text field (CreateWindow( ) 
API), give it the focus each time a VID field has the focus, then 
get the input data on events received from the system:// port.

Henrik, you mention the rebol3 browser quite a bit. Just what is 
it? Perhaps you have written about it previously.

He has stated that he wants REBOL's GUI to be more declarative, with 
structural and presentation cleanly seperated, and network access 
and services fully integrated. Sort of like HTML/CSS/HTTP done right: 
A REBOL browser. That is what he has been working on these last few 
months, what we have all been waiting for.

This is why Carl's work lately has been worth waiting for. I mean, 
if it was just a GUI framework that would be silly, right? :)

The idea of the REBOL browser is to replace the Viewtop paradigm 
with a webbrowser paradigm, because people will relate to that much 
more. You have a standard browser-like window. You enter a URL and 
get a "page" or a script run from that location displayed in the 
window. I mentioned earlier that I felt Carl was trying to restart 
webbrowsing. Carl's situation right now is probably right where Tim 
Berners-Lee was back in the early 90's as he was finishing Mosaic 
1.0. Carl will just be starting in 2008 with 2012-type web technologies, 
rather than 1994.

if it will be like I imagined, it's going to be one heck of a tech 
demo.

But we can already do one: Just 'do a complex VID script in the R2 
console, such as Devbase and see how fast it loads. Now do the same 
thing in AJAX.

I think for wide adoption the browser window needs to fit inside 
an ordinary browser window as well. If it works somewhat the same 
way as the native rebol browser (lacking certain rebol browser features), 
you have a pretty good demo of what it would be.

Take that with a grain of salt though - I use REBOL for server-side 
stuff most of the time.

well, sure, but I imagine there would be a degree of control of how 
you want it to layout, either in a GUI oriented fashion or a document 
oriented fashion.

Yup. There is a lot to learn there, and the number one lesson is 
this: they did it with what was there already, no plugins. If we 
want REBOL in web browsers, we are going to have to look somewhere 
other than Google for inspiration. Still, some of their recent behavior 
has some clues. Look at Gears - they are clearly recognizing that 
networks aren't reliable or fast enough to count on consistency. 
That's why they are promoting local storage.

In general, languages like Erlang handle unreliable networks with 
redundancy, and it can do that because it is a functional language 
with no assignment. The state needed to answer a question is passed 
with the question. That way you can ask the same question multiple 
times and get the same answer every time.

Google is never going to be finished - it is turning into a rather 
complex product. No, it is a company or a platform, not a product.

All google employees are asked to work on a personal project 20% 
of the time they work there. That means 1 day a week.

Qtask is also the largest scale project REBOL has. There is a good 
bet that PITL innovations will be coming to REBOL from Qtask.

information does not escape from a black hole except as hawking radiation

Chord: the real testing got stalled, I hope to return to it. I managed 
to express it in terms of a few functions. So if you can define those 
in REBOL (I did them using Rugby), and my implementation works... 
you can rebuild from the top down.

I want to pull a couple threads together for comment - the REBOL 
browser concept and the cloud/services parts such as S3.  I think 
there is great potential in delivering an environment that can bring 
rich network applications to the desktop but that support development 
without the limitations of the web browser/html/ajax technologies. 
 It can be less of a "browser" and more of a UI to services platform 
in my view.  Trying to shoehorn it into a web browser just because 
it is common is a mistake I think.

At the same time I do worry that a grand plan such as a REBOL browser 
is putting the cart before the horse, R3 as the base needs to be 
done and delivering on its functionality promises first.

Rod, I wouldn't  worry about a Rebol browser taking priority over 
the base technology. There is no mention of a Rebol browser in Carl's 
blog,  the  Rebol 3 blog or Docbase.  If  there is such a thing it 
is only being discussed in private which suggests that it is only 
at the "idea" stage.


In fact , I get the feeling that when people talk about the Rebol 
browser, thay are actually talking about the replacement for VID 
in Rebol3.

I think that people are calling the VID replacement a Rebol browser...I 
don't think they are referring to an HMTL/CSS browser written in 
Rebol or even a browser plugin.

Anyway, Graham is absolutely correct.

To me it appears as if (and BrianH has stated this too), that the 
REBOL browser has presented Carl with a range of low-level issues 
that need to be fixed before he can move on. He's attacking the issues 
at both high and low level, by exposing R3 to real-world application 
development and seeing where R3 falls through. Some new functions 
in R3 are indeed made because of requirements from real-world R3 
standard libraries like VID3, such as DELECT.

He probably views it as much more expensive to correct R3 afterwards, 
and I think VID3.4 has profound changes in R3 just like Unicode had, 
so it's very important to get that right.

It was the lack of easy acess to S3 that caused me to finally bail 
from Rebol.  And it's still getting discussed..in PHP you can drop 
in a S3 class and be up and running in 5 minutes.

Face it, a language with no community is no language. And by community, 
I mean > 10000 daily users.

The shame is, Rebol is a great language.  Personally, I blame the 
license... the world changed, and failing to change with it is obscurity 
doom.