AltME groups: search

I like the project and I appreciate the effiorts of Carl and the 
community and I take it as is. It is a gift of a genius which has 
spent a lot of money during the years and which surely doesn't have 
other golden treasures to give to project.

I am not so pessimistic. REBOL in 2010 will be a nice programming 
language. It will be our role to develop the connections to the outer 
world like the community did with REBOL 2.

I think that's true ... because there's a fundamental language advantage 
that can not be overcome no matter what the competition does.

I said a long time ago that computer languages don't age like the 
software technologies built upon them. still think I'm right. :-)

I am not sure I overestimate it that much. There is several layers 
to my statement. As for the technology and its quality, I can agree 
- REBOL is nice technology. But - from the marketing/adoption side, 
you have some open windows available. The first one was during the 
momentum of REBOL being new. We wasted it greatly. I can see another 
widnow being open, for some year or max two years back - RIA. I do 
remember when I first tried Adobe Air - it was a joke. Attempt at 
non system UI, and they repeated some mistakes of ours. Now we can 
see articles about Flash/Flex, Silverlight, Curl, etc., but no REBOL. 
In 2010 that market will be well established. Mobile players will 
choose their technologies and they will not be able to look back.

It is really important to get R3 out the door in 2008.

I find it interesting that there is so much focus on comparing REBOL 
to Flash/Silverlight. REBOL does far more than both of them together 
do. In the long run, I think REBOL can become more relevant than 
Flash or Silverlight, as they are narrowly focused technologies that 
at some point will become outdated and replaced by other technologies 
that do a better job in the same narrow field. REBOL has no such 
limitation.

It may well be a missed opportunity for Rebol as a front end, but 
frankly I'd rather see R3 done right than speculatively rush it to 
market.  I see greater opportunities in the future for a feature 
complete, mature R3.


Even if R3 were the perfect combination of front and back end, RT 
does not have the leverage of Adobe or MS to establish R3 in the 
way you suggest.  The future of Rebol as I see it is in the grassroots, 
and for that, R3 must be all that it can be.

On the other hand, RT should be pushing for the spectrum of Rebol 
products - Base/Core/View to be included on every OS distribution. 
 Imagine if that had been pursued a few years back: .r would truly 
be write once, run anywhere...

I said it already many times and now there is a new opportunity, 
quicktime browser plugin is today much more popular thanks to iTunes, 
it is installed in more than 80% of personal computers. quicktime 
once had a wired scripting language (qscript), Live stage Pro was 
the only editor for that. Now apple just announced they are working 
on Quicktime X, they will either drop scripting completely or they 
will put something new in. That new scripting in the quicktime plugin 
SHOULD BE REBOL !! it is a win-win solution. rebol would have access 
to  about 200 media formats, apple will offer the best language for 
scripting medias, and not limited to that. See, apple really has 
no interest in seeing flash ported to the iPhone, because the sell 
iPhones games on their iTunes store, and many other reason. Also 
in the last year apple has enhanced javascript ability to control 
quicktime movies in the browser. I have no idea about waht agreement 
apple and RT should come to, but I'm sure nobody can argument against 
this theory! Long life rebol! 8-)

If you want to see REBOL expand then build APPS and distribute them 
with a BSD license.   If REBOL isn't "everywhere" then it isn't just 
Carl's fault - it is ours also.

I guarantee you, that .mov is pretty much ignored by Windows users, 
and very often found being obtrusive. It is recognised by those favoring 
Mac platform, but not otherwise. Yes, REBOL as a system language 
of anything would be benefical, but that will not easily happen imo 
...

Petr, Apple actually succeeded in making the MOV format a standard: 
the MP4 format is indeed MOV with some restrictions. Notice that 
MOV and AVI are both IFF clones (AVI just has the length in reverse 
order, indeed it's called RIFF, while MOV swaps chunck type and length). 
The way they are being used is another matter :)

There is a dearth of visible activity

I agree that quicktime for windows does not at all show a fair picture 
of what quicktime is capable of.

Petr, I hated QT on windows too (or Itunes etc.). And, I hate the 
fact that MOV are often very hard to handle with open source software 
(eg. the DV videos produced by iMovie could not be processed on linux, 
but this was a couple years ago). But, I don't think it's the format 
at fault here. mplayer for eg. can easily play any MOV (as well as 
FLV, AVI, MKV, etc.), and VLC too, and they are both open source, 
so in principle there are no obstacles.

So it would seem that we're almost back in business after some time 
in the quiet. Carl has been talking about vast simplification of 
how people can do networking. A bit in the same way as when you send 
data with a webbrowser from a form, you don't mess around with ports, 
but simple HTML code to do that. There will be more information about 
this later.

What are the memory management enhancement proposed ? We all saw 
how it was difficulte to manage the mémory in previous rebol. For 
small data content that not a big issue but as soon you start to 
play with grafical content the mémory stack is amazing ( for example 
this code http://shadwolf.free.fr/berlinClock.ziptakes 10Mo  when 
running and in my opinion that from far 9M mega wasted ...). Can 
it be a way to make the recycle function more efficient to trap all 
non in use data

next thing is the VID2 event system in same code we can see the rate 
face feel function don't allow the  event handling for the other 
face the Quit button for example.  (still in same code). Those things 
are trivial and i don't imagine to have to search hours and hours 
a way to solve them.

last thing is the "extension" modules  I would like to know how  
it's planned to handle them  when u add an external DLL to rebol 
VM your goal is not to have to rewrite a brigde code for each of 
your DLL you want to work with and you don't want too your rebol 
application code to be over complexified in regard to the regular 
rebol code wich use shaped  dialects. I know that's not easy thing 
to do ....

I want to be able to use any DLL in a rebolist way  to resume that's 
maybe an utopy but dreams allows

I believe efficient memory use is going to be a major focus.

Memory management: R2 gets a bad rap for this because Windows doesn't 
report the working set seperately, so the numbers it reports are 
a little inflated with page file memory. Nonetheless, R3 should be 
better with memory.

I think the graphics engine is much more memory efficient in R3. 
A single GOB takes up 64 bytes of memory where a FACE in R2 takes 
up much more memory.

of course a face and a GOB is not directly comparable, but just run 
the 1000cows.r demo to see the difference :-)

VID is at a higher level than gobs, but Graham has a good point. 
All we know is that it will be good code, because Carl is doing it 
:)

although I'm not really that worried. if VID3.4 will be very different 
and inferior to VID3, it's important to have Gabriele finishing VID3 
to have a viable alternative as soon as possible for proper GUI development.

For example in VID it's very hard to build a well-functioning popup 
menu due to some restrictions on panels, clipping your content and 
you can't put things outside the window. in VID3.4 it should be simple 
to make a popup.

I had proposed a system to abstract input from the GUI a while ago, 
but it was mostly ignored. it's probably not that easy to implement.

but what it would do, would be to let you use very different devices 
for regular input, such as a Wii controller. there would be no changes 
to the UI itself. if you need additional graphical controls like 
an on screen keyboard, it would be part of the abstraction rather 
than a part of your GUI.

Or, is it just a gleam in your eye?

but I think it makes sense. I've studied the problem a bit. Everyone 
else makes special cases out of it, rather than a generic system 
for strange input devices. I had hoped that VID3 could be the first 
GUI ever to do this. It would mean that you can write a GUI and a 
handicapped person or a person using handwriting recognition would 
be able to use it without modifications.

you just write in a text box

ok, it's different from PocketPC or Palm, then. At least the version 
I used had a separate text box for input.

I don't think we'll be seeing anything very soon. From observation, 
in the past Carl has been active in DocBase before new releases.

He hasn't updated DocBase for over a month.


I think we can only start looking forward to a new release  after 
Carl has started to update DocBase again..

Yes - internally complicated, strangely layered, not easy for average 
programmer to extend/add new stuff, maybe a lack of good docs, maybe 
a mixture of everything mentioned.

Carl mentioned that he liked the dialect and didn't want to change 
what it would be capable of, but that was before the announcement 
of the new networking scheme, which apparently is somehow integrated 
with VID3.4. There is for example a SEND command in the new dialect, 
so I guess he wants to make it extremely simple to build networking 
code into a GUI. I just hope he does it right. :-)

Nature abhors a vacuum

I mentioned to him that the communication is big problem in my opinion. 
Those silent periods do really a bad damage. I can't imagine any 
bigger company taking RT seriously. You either have private life 
and ranch, or you treat your company profesionally ...

I'm not sure it really causes damage. The end outcome of his work 
will be the same and luring people with tidbits might just be a timewaster.I 
get the feeling he does not want to reveal more details before the 
design is more solid. It's one of those things that during the design 
process might turn 180 degrees and become something else, because 
most good ideas don't come to you until some time late in the design 
process.

I get the feeling that rebol users are a shrinking community

The problem is really a lack of directions, something like "I would 
really like you to work on the test scheme now".

It's never a one-way thing for programming languages. When there 
is stuff to talk about, activity always bounces back.

Petr: first wait. no need to make a duplicate, i expect Carl's to 
be good, i'm just worried about his "bob the artist" idea (that doesn't 
really work, the only way is to create a visual tool), but i may 
just be understanding this wrong.

I would personally have gone underground with VID3. I understand 
why Carl works the way he does. Sometimes it's a lot harder to code 
from other people's directions/criticisms than your own, if it depends 
on turning your entire code base upside down to fulfill a small requirement. 
It just takes longer to finish things.

Having a critical voice is very important

Otherwise one is developing in a vacuum of feedback

hey, petr, i said i agree with you about this part, i'm just saying 
that being open takes a lot more work.

Would it not lead to a better result though?

graham, not always. however, it has other advantages. if the host 
code was released, i could have worked on a linux or mac port, or 
helped fix the gfx bugs since richard is busy. if i can't compile 
myself, then i can't help in any way.

graham: to make an example Carl made to me, imagine you are painting. 
would it be better to be alone, or with a crowd behind you commenting 
at every brush stroke?

If you open up a design process even to highly qualified people, 
you are already on the first step towards design by commitee, which 
is entirely against REBOL's design philosophy. If the people are 
less qualified, it's the second step and you can end up trying to 
handle more noise than getting actual code done and the project will 
then truly move at a snail's pace.

I'm sitting in that position in my job projects, which has caused 
about two full years of delay, because I'm forced to write crap code 
to meet some silly deadlines. That code then later needs to be rewritten 
to meet my own personal quality requirements when no one else is 
looking at me or judging my work before it's done.

I'm sure Gabriele has a complete picture of VID3 in his head and 
it does no good to trample around on that picture, before he gets 
the chance to complete the work. I'm also certain that Carl has tried 
both things and going underground simply works best.

Ever noticed that most good movies has one script writer and that 
the script writer is also the director? And that most bad movies 
have 5-6 different script writers and a different director?

Every few days I release a new iteration of my software.

Graham you are probably not in a situation where you need to start 
on a new project or build a program from scratch. Do you read messages 
and take notes on day 5 of project development after the design requirements 
are settled?

Henrik .. I did a GUI mock up and the released the mock up.  Then 
I took suggestions after that :)

no, but that was only a day

your design process is very short. it's very different for a system 
like VID3. the rest is implementation, which is more trivial.

The design process for LIST-VIEW was very short. It took a few days 
to build the first version. After that it was more an issue of getting 
features put on top of other features and spending time on bug fixing. 
There was very little actual design after the first version.

There is SilverLight, MoonLight, Flash, we planned FireSide, SideLight, 
or something like that - but that is more for a product name, than 
to call some subsystem ...

flash in a pan :)

so, we have a product that is capable of creating flash like graphics 
and better.

The tough thing to appreciate is that VID is a general-purpose entry/mid-level 
dialect.  R2/VID has been in the wild for 6yrs(?) now and we have 
certainly gone through periods of isolating key weaknesses, but we 
all have a tendency to have had starry-eyed visions for what VID 
should be.  The practical gets mixed in with the possibility when 
it's time for action.


I think the community would be better served with a strong VID alternative 
(not as a slight to RebGUI which does very well acheiving its stated 
aims) not bound by Carl's constraints for the entry level language, 
and open (as in open) source with very clear aims.  It has to be 
independent and perhaps needs to span R2 and R3, at least initially. 
 We have the capabilities, resources and talent to do it, but instead 
try to hammer these ideas into VID.


This isn't intended to be a rallying cry -- it's just my assessment 
based on observation and involvement.  Such an undertaking would 
have inevitable difficulty overcoming the differing visions of interested 
parties.  Conversely, it's within us to create an enduring, enviable 
framework...

The iterative way of developing with lots of feedback, nowadays described 
in Extreme and Agile Programming, is very suitable for user applications 
and solves a lot of problems there

REBOL is clearly systems software, a middleware layer that aims to 
bridge between lower level systems and frameworks for basing user 
applications on

well the mear problemfor comunication is the monolitic way to think 
.... 1 guy working = stability of the way to work but fluctuant communication. 
And teh problem  can be there is not much to communicate about too 
. several guys working = code harder to stabilise but more easy to 
communicate each time you have a new thing done or a new idea popping

that remembers me how we started rebGUI with rebol community ashley 
and me. First ashley and me  were working on MakeDoc and MakeDoc 
Pro dialect to VID renderer we emulate each other alot and from this 
exange born the constatation that common VID face set was not adapated 
to usual GUI  or big amount of face handling. And from that constatation 
Ashley proposed to make rebGUI  wich we presented as a major enhancement 
to VID layer keeping the main idea alive "KEEP IT SIMPLE". Ashley 
proposed the community to share idea or suggestion and on every single 
widget the community proposed we got a discution and code proposition 
to achieve this goal.

sure the most of the work was lets say the assembly and diffusion 
part of rebgui was still done by 1 guy Ashley wich have the main 
vision of the project and was our guarant to get end edged library 
usable by any one but many were the  contributors and that leads 
to a really dynamic work i remember on the very beggining of the 
project a new version of rebgui was available every 2 weeks.

REbGUI is working on top of VID not remplacing it and remplacing 
VID is yet another step of difficulties. As I said befor the only 
way to remplace VID would be to make a DLL and then a bridge to make 
the "user code" able to use it and that means a more complexe way 
to share your sofware

but that rebirth the ask i done about the "external modules" handling 
if we see rebol as a full opened virtual machine with an easy way 
to handle module then network, vid data etc are just modules and 
anyone can take them work on them enhance them or correct them share 
is news and rebol recentralise the works to make an official  release

this way rebol is hum thought more a module manager and a mean idea 
of was software programming is than a monolitic virtual machine wich 
I call the BIG black box able to do anything but with a big mistery 
regarding how the thing are internally done.

there is 2 ways to see a window and it's content the first 1 is the 
all made container the window is a set of default widget a tittle 
a status bar etc.... or you see it as a transparent rectangular area 
where you put other common widget . Maybe the true power of VID2 
 and by extention the true power of the rebol dialecting would be 
to think the window as a transparent rectangular area and then have 
2 kind of super widget able to get user input and deal with event 
able  to render draw AGG instruction and this widget will be the 
base for a design of all the widget

I have done alone in less than a day serveral things that in other 
language would have took me weeks  with several other guys

yeah .... Pekr you are right .... and that's not a new issue I remember 
it took like 1 year to get rebol 1.3  VM  but  if we look closely 
rebol is not only built for windows and that's pretty complexifying 
the rebol developement process ...  since all REBOL VMs have to produce 
the same on all platerform from 1 single code you have to lower the 
specifications and possibility  the ground ones wich will feet to 
some less designed OS .....

and third we say ok we can put all in rebol therefor we design or 
think a way to easy extend it keeping for the extentions the rebol 
coding way

and third we say ok we can not  put all in rebol therefor we design 
or think a way to easy extend it keeping for the extentions the rebol 
coding way

Shadwolf:


- development has to be vital. There is IMO noone contracted right 
now. Gabriele, Cyphre, simply noone. Cyphre has not fixed deep View 
bugs for some 4 months or something like that

- there is nothing complicated about cross-platform nature of R3, 
as right now, kernel is imo not under development

- according to available info, VID should be the focus now. And maybe 
it is the focus. But it is not communicated. I hate those periods 
and they do happen once in something like 2 years, last one was probably 
during the rebservices period, which were not finished btw anyway. 
So - the blogging about Vista being broken or California fires is 
good, but look at frequency of R3 blogs. If it will not change, I 
recommend to remove personal blog from REBOL.NET, as it gives overal 
impression of RT breeding wine, instead of coding. Not that I have 
anything against personal life or wine :-), but can you imagine some 
system integrator, potential investor or tech.company willing to 
use R3 in their cell phone would look at REBOL.NET blogs? It seems 
to scream for - "... but where's the development happening"? And 
once again - all is about communication imo. If VID3 is in some stage, 
one blog per week would not hurt - whatever - principle explanation, 
simple glimpse of code, a screenshot, whatever ....

there used to be a running joke in my workplace that whatever startup 
company i got excited about was doomed to failure.  Be Inc. with 
BeOS (focus shift), Constellation 3D with their Flourescent Multilayer 
Disks (FMD) (factory bombed in start of Palestinian intifada), and 
now Rebol?


Each of the technologies was/is paradigm shifting in their field 
but through mismanagement, mishaps and miscommunication something 
along the way seems to get lost and the excitement they originally 
engendered fades from the public eye. 


If, in the case of Rebol3, it simply is too much work for one person 
- then perhaps now would be the time to open such areas as View development 
(the underlying system) and advertise to the 'World' "Come, see what 
you can do!".


Personally, I'd love to see Cyphre's work with View taken that one 
step further and translated into OpenGL and all that entails.  Not 
everyone today is looking to use Rebol only on their embedded devices 
;)

The biggest block to finishing DevBase was that my time to work on 
it went away for a few months. That should be changing soon.

The main block to View being opened is not DevBase, it is that the 
core design of View isn't done yet. REBOL has a lead designer - we 
don't do design by committee. The rest of us refine the design and 
make really cool stuff based on the foundations, but the lead architect 
is still Carl.

but why, when the core design for View isnt done yet is Carl even 
thinking on working on VID?  Surely we need a View before VID is 
even feasible?

I always looked at REBOL as a general programming language, but it 
seems that's no more a goal to reach (if it has ever been in RT's 
plans). I know that it has been marketed as a "messaging language", 
but I thought that  it would evolve more as a pure programming language. 
Maybe I have a wrong POV on REBOL from the beggining. I always looked 
at VID/View being a good addition to the language, but not a vital 
one. Now that such high-level features have become top priority, 
I wonder if Core3.0, with all the features we're waiting for since 
years, will be completed and stable before 2010...I'm not sure that 
I'll wait that much.

I'm a bit impatient myself Doc.  I think they should not worry about 
VID for release but worry about what VID will be built off of - hence 
VIEW instead and they can always release VID as a module later if 
needed.

I always looked at REBOL as a data structure manipulation library 
with language implementation tools built in. Also, it bundles some 
useful languages with it. My only significant View app has been DevBase 
- aside from that I have just used it for code generation, batch 
processes and server side stuff.

I've stopped working on the products built with REBOL I was planning 
to release. The future of REBOL as a standalone programming language, 
has become too uncertain for me. I'm working only on Cheyenne and 
MySQL driver, because I use them daily, but I don't think that I 
will invest more time and energy than that on REBOL. I've already 
started searching for alternative solutions, including resume working 
on a clone or a derivated of REBOL. In the past, I've stopped working 
on a clone because, the release of the plugin interface for REBOL 
was supposed to be imminent. That was 3 years ago.

Well, REBOL has influenced me quite a lot too. I don't want to get 
back to an inferior tool, but I don't want to use a closed-source 
programming language anymore (unless it is backed by a *big* software 
company).

Hum alternative to rebol is a n old idea but since today no one went 
in this process as far carl did. If we really want to wirte our own 
REBOL-Like VM  that means the same thing than for REBOL main dev 
 in fact .... ORGANISATION people who will work each day some hours 
on the project. REmember guys the pyramids in Egypt or in mexico 
have been done stone by stone past 3000  years and they are still 
up today. This to point the fact we all have side things to and starting 
from scratch  the writing of a REBOL clone implicate a true implication 
and not from only 1 guy.

I LOVE REBOL  that a fact but rebol is a hum how to say that without 
hurting Carl .... not achieved. Carl start things and never finish 
them and that ends to an incomplete picture and the fact that rebol 
is considere as a cool toy but not as a professional thing.

Software has never being a major business for Commodore AFAIK.

Doc didn't you have like a R# or some type of project a while back?

maybe a good way to motivate Carl is doing such a project to show 
we really care and maybe in the process we will get  some fun idea 
and new things that will amaze Carl and give him the taste and ennergy 
to focus on rebol VM  enhancing and finishing

Dockimbel, my theory is that if it was made under a large company 
like Apple or Commodore, Carl may not have been able to take it with 
him due to contractual obligations. He could also be forced to abandon 
it, due to budget cuts or being an uninteresting project to various 
clueless bosses.

RT is not governed by clueless bosses who have no idea what REBOL 
really represents (most people I talk to, don't really know what 
REBOL represents or what it really is) and since it's one man's vision, 
it's a lot harder to kill. Only his own lack of motivation would 
kill REBOL. His motivation from the last time he talked on the r3-alpha 
world, was far from lacking.

Shadwolf: If pyramids were designed by committee, I don't think they 
would last so long. I believe that the more complex the design is, 
the less people it requires to be well done. For a programming language 
that don't rely on written specifications, it's a one man's work, 
at least for the kernel part.

I've been trying to move DevBase to a multi-project model.

Maybe that is what is needed - a new open source REBOL clone that 
is going the way of R3?

Paul, I don't think it's a good idea. one of the reasons I use REBOL 
is because there are no competing clones that are not entirely compatible.

Dock at same time we have rebol as example ... And any way i don't 
pretend to be as clever as Carl but if I can help in anyway in the 
process and at least by doing communication and documentation you 
will find me  that's a fact  ^^

Paul: yes I'm the author of R#, which was more a research project 
on alternate ways of implementing REBOL evaluation and memory management 
than a serious attempt to make the open-source clone of REBOL.

Anyway the rebol clone can only be a dynamiser for our overbored 
community (muhahahaahaha no i'm not drunk !!! I promise !! )

I would love to see a community driven project for creating full 
SSH, HTTPS, SFTP access for R3. Carl doesn't need to supervise that.

REBOL  is a way to think computing like other language having same 
language with several way to use it  is just a good thing