AltME groups: search

Lynx scales, though. :-) And it sounds it can be implemented in VID3 
:-)

Syllable app. We don't have FF and are not sure we want it

Anyway, I would to see V3 create windows that can scroll easily with 
text and graphics as browser  windows do

Yes, FF's Gecko engine is unwieldy and they're currently decreasing 
portability. WebKit is much easier to embed

The need to render simple HTML & PDF within the app is the reason 
I have not used R2 on internal projects. I've had to move on to web 
apps and I'm using more Python now than Rebol. The screenshot on 
Henrik's blog is very, very good! Web apps, for good or bad, are 
here and now and "rich" web app frameworks  are  actively being developed. 
Rebol faces a lot of competition in this area. The R3  potential 
is amazing and whilst I have my own priorites for new features, I 
look forward to trying out the beta when it's released. Can I just 
say thanks to all of the developers for their hard work so far.

And if we need full html support, well then, I suggest khtml webkit, 
as Mozilla is known of being difficult to wrap (unless situation 
changed from two years ago. They are supposed to have minimo or something 
like that for mobile devices)

Having REBOL in JAVA would get rebol onto most mobile devices and 
nearly everywhere. OTOH - JAVA on mobile devices is restricted, not 
consistent across the platforms - just ask Cyphre for his experience. 
So, maybe, and I repeat - maybe - it will be easier to port REBOL 
to most platforms, rather than to do REBOL-in-JAVA project.

But we have to decide on priorities. As for me, I prefer finished 
R3 with plug-ins, and then web browser plugin. I think we can break-thru 
with REBOL itself. Those kind of integrations can come later.

My main interest is in building stand alone applications so I have 
less requirement for .net and java

I suspect not .. if the language is cool enough, hackers will use 
it .. and it will then eventually find its way there

I think REBOL should work with COBOL, and should be ported to mainframes 
;)

I mean after one buys a couple of sdks and /pro versions .. there's 
no real need to purchase any more.

More optimized datatypes, tighter code and GOBs.

and if you're running a non-gui app .. any difference?

I just started an R3 console. Everytime R3 starts, it displays a 
splashscreen with rich text, a picture and two buttons in it. When 
I close it, stats returns 1276368 bytes.

I should do some rich text tests and show you that.

it probably would. there would be great value in a single text editor 
style with toolbar and things.

of course it would be nice to be able to cut and paste some rich 
text html and have it come out the same in a rich text box

and simple things like right click on a text box brings up copy/paste 
support

daveC, no, it's too complex and not very well written, but Gabriele 
and I will take the features one by one and reimplement the most 
important ones. LIST-VIEW takes up almost as much source code as 
the entire of VID3.

it will be essential, so yes, it will be made. there is a simple 
text list now that has multiple resizable columns, very small (and 
ugly in appearance) and fairly fast.

LIST-VIEW is also very monolithic. the filtering and search functions 
don't really belong there. we need to separate that to make it more 
flexible for cases where you only need filtering or searching but 
not display.

and then R3 LIST-VIEW would just display whatever is fed to it. that's 
a smarter way to do it.

and it won't matter much when GOBs are so much more memory efficient.

I imagine we'd use a sort index like now and just point to the different 
lines in the data block as the list view is rendered.

but nothing is written yet. Gabriele probably has much better ideas 
than me on how to do it fast and efficiently. :-)

But I refuse to obtain long data list from SQL query and to reorder 
it just to get it displayed.

I don't remember correctly, but when we were presented IBM Business 
Warehouse (BW) system, it did exactly that. It created kind of virtual 
SQL server, you could have views, queries, etc., and underlying engine 
had connectors to other dbs. From the BW user pov, the user talked 
to just one SQL server, the virtual one ...

there should be two styles anyway - text-list, and grid ....

There was a grid cotrol for VB, TrueGrid from Apex Software; it had 
a callback mode, where it requested data dynamically (like LIST) 
and fired update events if the user edited something. The only data 
it need to duplicate, IIRC, was for the set of displayed rows.

the one we used, did dynamic caching. I mean - only the visible window 
was drawn, nothing which was supposed to be clipped. So in some way, 
it was dynamic too. It kind of kept "virtual data window" upon your 
data-set, and according where you moved, it moved too. This aproach 
allowed to display million of records. Of course, that was DBF era, 
not SQL one. But even SQL has cursors ...

i mean, that the app programmers only specifies what he *means*, 
not what the UI should look like. "I want to get a string from the 
user". "I want to get the name and birth date from the user, and 
show the age". how this looks depends on 1) the look defined by the 
gfx designer (which can be the programmer himself, if he is able 
to do that too) 2) user preferences, to the point that an advanced 
user should be able to edit the UI.

Use CSS 2.1 styles on widgets. Create widgets ("classes") in VID-the-sequel 
and render them to Rebol or XHTML + Javascript. That way you can 
mobilize the entire web community to get a UI that renders both to 
a RIA and to the web.

Maarten - but does CSS allow you to define how your style behaves? 
Or is it plain and ordinary - hilite here, hilite there?

Petr, CSS doesn't control behaviour, and nor should it.  At it's 
most complex, it has different rules for different states -- a:hover, 
a:visited, input:focus -- which is how I'd like a style system to 
work.

Gab, you're wrong. CSS is for styling of box models "containers" 
in application terms. Disable CSS on your favourite web-app and see 
what happens....

Chris: my point exactly. VID should map to the DOM with CSS and use 
REBOL instead of Javascript (or alongw ith....)

if box model means padding and margins, then the style system supports 
something similar. if it's what you can do with DIVs, then I strongly 
oppose it.

Chris, I would abandon VID3 immediately and use RebGUI if it were 
ever to behave like a web "application". Designing application user 
interfaces with HTML and CSS is a complete nightmare.

We need VID3, we need plug-in, and we need to try to break-thru.

Petr, I can't say I disagree with much Henrik put on his blog -- 
I have been advocating something similar for some time. It sounds 
consistent with the intent behind CSS, thus I'm curious exactly what 
aspect of CSS Gabriele and perhaps Henrik take issue with.  imo, 
the concept of a visual language that is hierarchial and context-specific 
is sound.  The actual implementation of CSS is kindof ugly..

Look at it another way -- if you are building a web application, 
you hire a designer to work on the interface.  The designer may adjust 
some of your HTML templates, but most all the work can be done with 
a style sheet.  That's it.  They don't need to go tinkering in your 
application code, they just need to know the elements of the interface 
and the range of states of those elements.  They code the CSS, bundle 
the images, then they're done and you can slot it into your interface 
without modification.

Where I have designed VID interfaces, I (or someone else) have had 
to implement my designs in lower level code, and still there are 
portions beyond my control.  And a change in the visual may change 
the functionality of the application..

Chris - I know, I remember your position. Was it REBOL2 or REBOL1 
world we were discussing that? VID 1.3 time. I too, asked Henrik/Gabriele 
about CSS. Because it would be cool, if we would be close to standards. 
Not because of standards themselves, but because of easy of deployment. 
But, as far as I understand the situation - Gabriele understands 
CSS, and so far, VID3 seems more flexible. If it would be upon to 
him, he would even more separate (completly) app logic and user interface.

GUI & functions: The only way I think we really can let GUI people 
work on it wihtout disturbing the code is to use a event model. So 
a GUI widget just sends an event to some rebol internal event-handler 
& dispatcher and this calls the app code.

And to make it even more "self-contained" we could use:
	...
	save-contact: button "Save"
	...


And the GUI system would send a message of the form [save-contact 
left-click] or [save-contact right-click] etc.

I hope I'm not infringing on a copyright but this quote from the 
commentary of the Halloween I document 

http://catb.org/~esr/halloween/halloween1.htmlexplains that phenomenon 
quite nicely.

<q>

The difference here is, in every release cycle Microsoft always listens 
to its most ignorant customers. This is the key to dumbing down each 
release cycle of software for further assaulting the non-PC population. 
Linux and OS/2 developers, OTOH, tend to listen to their smartest 
customers. This necessarily limits the initial appeal of the operating 
system, while enhancing its long-term benefits. Perhaps only a monopolist 
like Microsoft could get away with selling worse products each generation 
-- products focused so narrowly on the least-technical member of 
the consumer base that they necessarily sacrifice technical excellence. 
Linux and OS/2 tend to appeal to the customer who knows greatness 
when he or she sees it.The good that Microsoft does in bringing computers 
to the non-users is outdone by the curse they bring upon the experienced 
users, because their monopoly position tends to force everyone toward 
the lowest-common-denominator, not just the new users.
</q>

Umm, I didn't mean to shut down the conversation with the MS bashing. 
 Wasn't really the point.  The point is that the trend in Desktop 
is to dumb things down, and that seems to have slipped into the web 
application domain as well.  Not our trend I hope.  The hard part 
being the balance between usability and developer bliss and sense 
of self-respect.  :)

Gabriele, you have my support on the UI separation. I agree it's 
important and think it's good news you got it through. Your original 
design document on it was brilliant

It must be an effect of the throw-away coding model and the focus 
on individual developers. It doesn't scale to responsibility delegation 
in the way Chris says

I'll +1 on Kaj's remarks.  I'd like to see Gabriele be allowed to 
apply some genius to VID3 then drag the rest (most) of us up to where 
we should be.  Chris and Henrik and Robert and Maarten et al will 
then produce all the cool code we've come to expect, but from a higher 
view point and perhaps from a slightly different slant than we are 
used to. imho.  And I do hope that VID3 work will be as shareable 
as the best of the library functions, umm, we don't really have yet. 
 :)

There is potential for R3 to have access to last console expression 
results.  Any suggested names?

>> 2 + 3
== 5
>> 3 * result  ; where result is some new REBOL function.
== 15


I'm a forther so I suggested  .  (dot), but Carl hinted he has been 
waiting for the perfect use of that symbol.  Is this it?  Looking 
for a good name for last-console-result.  Of course my example is 
trvial, it'd be more useful for longer expression and save on a  
temp:  while working the console.  For me, I'd prefer something short, 
easy to type (avoiding shift if possible) and having some meaning. 
 That may exclude . as dot is really forther common speak and would 
be meaningless to many.  I want to push for this feature as I'm continually 
up arrowing and adding temp: to test expressions.

the use of . means we could use .. for second last, and ... for third 
last ad infinitum :)

Hmmm,  I'd love a 'get-stack and 'restore-stack. Who needs continuations....

(and serializable)

All good ideas gentlemen.  For the way I work (lazy and forgetful) 
I'd prefer not to have to type system/console/last-result if we can 
convice Carl to make it nice and short like  recent  or  answer  
or ans or just  or anything along the six or less character typing 
range.  Plus if there is no shift-key involved, that'd be a bonus 
(meaning if we pick a symbol to suggest, I'd prefer backtick over 
tilde)

Kinda joking, but not,  last-evaluated-expression  lee  Has a sheltered 
feel to it and is a wine-makers word.  And then we could pay homage 
to The Bare Naked Ladies and call R3, Gordon.  :)

But I'll stop joking...this will be a very handy feature and doesn't 
deserve me clownin' around.  These are all good ideas.  And I think 
the fact of showing interest may move it closer to reality in R3. 
 Right now it is just a suggestion that got the nod of being possible.

Izkata I agree about readability.  A symbol may suffer abusive 'coding' 
practice if it ends up being last-expression and not just last-console-expression 
and then people do use the feature in scripts.

And then we can pick at the stack like forth

:)  My concern for readability would be avoiding REBOL code starting 
to look like perl, where you have to decipher while reading.  Coded 
code is fine for things like C, J and R but REBOL has a very nice 
quality of being grok'ed at a glance.  Losing that would be sad. 
 ICarii said it best already ... let's not go there.  So I'd almost 
like to restrict the new feature to last-console-expression just 
so we don't go overboard with short-cut expressions in scripts.  
Thinking along those lines, perhaps system/console/last-result would 
be fine.  Developers could add .: or `: or ~: to personalize for 
console work.  Then again, system/console/last-result wouldn't want 
to be set for evey expression.  Just when needed, so it'd have to 
be an action, not a data set.


Ingo;  Wow.  As I was typing...you were echoing the same thoughts.

Well, REBOL is all block/series based .... and series is a "queue" 
of values. I would like to have stack of values (block of values), 
series, which we can pick-up from, sort, move, remove - no ackward 
one only value!

Petr; A lot of this comes down to what is going to cost the REBOL 
evaluator.  I don't know, but have a feeling that a lot of intermediate 
results are discarded.  Could be wrong.  But if so, I wouldn't push 
for anything that will slow down current execution speed.  If the 
values are there on a stack today, great.  But II'd guess that only 
the last may easily (and zero cost to current run-time) accessible. 
 And with some fancy expressions, what goes on the stack in what 
order may be optimized differently than reading code left to right. 
 I'll ask while pointing out the interest that has been shown here 
by the group.  If coders want a pickable list of expressions today 
we have reduce and friends.  I'm more aiming to get at the last result 
from the console as I'm always forgetting to put a var: in front 
of test code, especially code tthat returns an object! that I'd like 
to probe.

I'd suggest sticking with system/console/last and then set up your 
own %user.r shortcuts around that -- everything in its place...

Ditto, and I'd like to limit the number of "console-only" words we 
add to the global context.

Kaj;  :)

The request for this feature has become more formal.  Mr. Hawley 
put in the ticket.  He has an excellent grasp of upcoming security 
and threading issues and worded the request accordingly.  The request 
went   in as system/console/last.  That could change and it's still 
only a request; but there it is.

Then can't you just compound the two lines and save a carriage return 
as well ;-)

Just wondering if there is any point in having a result stack we 
can push results onto and then use?  Is that faster than using local 
variables?

there must be a penalty in creating variables in terms of memory 
allocation, and deallocation

you can always store it manually i guess and process the draw block..

Or, are we going to have to run our own timers and count the time 
ourselves?

I used Bo's cron script some time ago and that seemed to work ... 
I'm just interested in knowing how the timer events will work.

Forinstance, my Cerebrus anti-spam script regularly ran out of resources 
and crashed after a week or so, so I was wanting to reboot it once 
a day as it were to prevent that happening.

I really don't undersant why there is so many people crying... I 
have Uniserve runing for several months without problems, parsing 
about 50 pages two times per day to provide culture informations 
in the city I live, I use Rebol to build PHP sites, Flash apps, as 
a proxy server as, a clasic system console and for so many every 
day scripting and I really cannot imagine I would use something else 
than Rebol for such a job. And if you still think that you cannot 
do anything in R2 and have to wait for R3 to start, you can take 
a look for other technology. With computer languages it's same like 
with normal languages - the more languages you know, the better you 
are.

Our community was always passionate, but not big enough. Each nice 
and good project was mostly a one-man show. Then - those more skilled 
rebollers got rebol related jobs. That is very nice, but also has 
some side-effects. Those ppl nearly vanished from public radar. Where's 
Doc, Cyphre, Ladislav, Gabriele, Voker, Anton? Well, Gabriele could 
be probably excluded from the group, as he is active even on ml.

And yes, awaiting new release has always the same effect. Ppl are 
holding breath, as they think new thingy is about to be released 
next day :-) Once there is new release however, I believe ppl will 
come from their holes and we will hopefully see nice activity once 
again.

If anything was to be communicated more than my suggestion to keep 
quiet, I would have liked to see very, very conservative schedules. 
Carl is always overly optimistic which is causing all this ruccus 
and damages the believability of RT.

No the syntax is basically the same. There are no radical changes 
to syntax, but in the details, some things behave a little differently, 
some things are allowed and some are forbidden, but you only notice 
that after a while. If you use R2, you'll be able to use R3 immediately. 
The differences lies in the behavior of functions, dialects, etc.

Excellent Henrik. That's what I needed to know. Most of my issues 
are not that R2 doesn't do something or another; they have to do 
with knowledge and experience. Thanks.

I usually use the word browser. It holds the newest and the most 
information.

think and suppose make for lousy answers.

I don't know yet much about the porting process, but so far it looks 
like a "fill in the blanks" process, where you need to provide functionality 
for events, timers, threads, etc. That and the documentation for 
whatever OS runs on the PS3. If Linux can run on it, R3 should work 
fine.

FlashPlayer has same or bigger memory footprint and is on pdas so 
why not R3

I want to be able to organize files as source, includes, docs and 
such. then I want the ability to create preprocessor files and encapped 
binaries with one click.

Some serious memory usage here in Ladislav's spelling corrector which 
is also in RebGUI

Script: "Spelling Corrector" (none)
loading and initializing(500kb dictionary)...

{somue spelin wordz tu tepst. Fur szore azd seren yaars aga, our 
fatheers brougt fourth on this lans a new natiun.}
some 10605095
spell 25275846
words 25615457
to 25928767
test 25275846
fur 25415461
swore 25755072
and 26071006
seen 26410617
years 26750228
ago 27066162
our 27205777
father 33781190
brought 34123425
fourth 34263040
on 34402655
this 34542270
lane 34860828
a 35000443
new 35140058
nation 27291974

0:00:04.717

I ran it on about 200 words that came from an ocr attempt and it 
crashed with an out of memory error.

For those not being on r3-alpha world. R3 development was "resumed". 
Not that it was halted, but I hade private chat with Carl for few 
days, and we got into agreement into how to proceed. I wonder, if 
I am working as an marketing RT guy already? :-) Well, it was nice 
and realistic chat. We identified, that priorities have to be sorted. 
And I suggested Carl to blog about it. Developers were polled for 
the priorities, and we found out, that there are mostly two groups:


- one that prefers View/VID plus schemes being done, so that ppl 
can continue with their app development

- and the other group, who would like to have surrounding infrastructure 
implemented. You probably will not be surprised I belong to this 
group :-) 


As for infrastructure, I simply asked Carl, if we get any improvement 
to dll component, and he admitted, that that might be task for us, 
using plug-in API - simply a cleaner and abstracted aproach. But 
- in order for plug-ins to work, we need modules. So - the next focus 
is to get module system working. It is a logical step imo.


RT working on modules does not mean VID should be halted. VID (whole 
View) will be most probably fully open source, so it is more of a 
community aproach. Ah, and we were scared a bit by consideration 
of dropping of R3. Due to architecture changes for R3, Rebcode might 
not be so fast as in R2, but developers said their NOOOOOO, so I 
hope Rebcode will come too in some form :-)


Ah, and as developers complained a bit about rebol console, Carl 
said well then, as you wish, and uploaded C source code for stdio 
device into DevBase.


Guys, my belief is, that things will start to move faster and faster 
with DevBase and cooperation.


Disclaimer: none of above is direct quote from my talks with Carl. 
It is just my understanding of current situation ....

And someone please update rebolweek :-)

Nice collection of updates. That way, reading rebolweek, it keeps 
good image of REBOL, it feels like there is some sign of life with 
REBOL, and that is always good.

Recovering from a none is easier and more efficient than recovering 
from an error. Series bounds are just an implementation detail anyways, 
when you have series that can autoexpand.

It's hard in hash! as well, but I agree. There is some missing infrastructure 
around the map! type as well, like iteration and searching.

no, it is just some kind of slow-down period. Activities around R3 
should be renewed as we speak, it seems Gabriele and Cyphre will 
be back on R3 full-time soon. There is also draft of release strategy. 
It seems RT decided (upon suggestions) to divide R3 release, so we 
should see Core like R3 alpha in one month, View will come later 
(2 - 3 months)

That's what I, and we, asked here a few months ago. There are still 
promises being made

Ok, currently the latest build provides support for modules, but 
some tests need to be done on that. There are also some discussions 
on how to do proper testing. We're not good testers. Now Carl is 
working on unicode and how R3 should support it. There is also talks 
about a document which provides the real roadmap to R3, but I don't 
think it's done.

I'm still not sure what you mean by "be in DevBase". The source code 
for R3 DLL is closed and won't be put in DevBase. Only the open parts, 
the mezzanines, the port code, device code, all that is already in 
devbase.

I wonder if DevBase could carry even binary files? E.g. rebol.dll 
and host.exe?

Parts of R3 being in DevBase is useless if there is no dev release 
to work with. Such a dev release was promised for last month, and 
then early this month. Is it still going to happen?

Kaj - yes, it is going to happen. In fact - I had some private chat 
with Carl, trying to explain him, that we should do something concrete. 
That is why I pushed for core-like release sooner, than full View 
release later, while initially most other users were against my proposition. 
Carl decided, that it will be that way. The plan was set, and now 
Carl is heading towards the core-like initial alpha release.

You waited for 18 months already? Is one more month for Core like 
R3 so much more? And 2 - 3 months for solid View replacement?

I start to understand Henrik - work with R2, and once R3 is here, 
it is here.