AltME groups: search

Today in the morning I watched Carl's presentation and it seems to 
me that this time Carl was not so concrete as last year, mainly a 
general ideas were presented and "what would be cool to achieve" 
without actually defining how to achieve that?

with regards to QTask speed.., from my experience..it really depends 
on time of day and who logs on.


it gets slows once the QTask developers starts working...but apart 
from that, it can be 'breezy'.

Reichart mentions that there are plans to speed things up. Specific 
details, I will leave it up to him to share.

i can only seed three at a time, so just let me know what you are 
downloading then :)

Gabriele:I am dling the Barons and Ashley but when i try to dl Roberts 
I get:error(10:14am) couldn't listen-(10048,addressalready in use') 
  I know you said only 3 at a time but I am only dling 2 ?

yeksoon - mostly whole EU, e.g. to do electronic invoicing, needs 
qualitified (not even commercial) certificates produced by some reliable 
Certification Authority. What is more, such certificates do expire 
in one year. For such invoices to be valid, you need kind of "long-term 
archive", you need simply to re-sign them. So you typically go and 
use so called time-stamps (kind of certificates), provided by CA 
once again ....

We are one of the first companies here in CZ, who try to fully solve 
electronic invoicing. In order to not need a paper, our law (and 
many EU countries too), simply require usage of certificates. It 
has nothing to do with how secure your transfer is. Simply once financial 
institute clerk comes to our company, he wants to see original invoices. 
And so far, it is paper. And if it is e.g. PDF, it has to be signed, 
as the person will ask - how can I be sure, it comes from company 
XY? He can - he can check e-signature and time-stamps signatures 
and he can be sure, that 1) the invoice comes from company (identity) 
XY and that it was not later modified, or the e-signatures would 
be invalid ...

Colin - I don't know which the codec is but they play well with Quick 
time Player.

time to make a devcon2006 group?

But there is going to be a price for this one liner. Either in load 
time, security, size, and others.

My story is about the same as BrianH's. Really wanted an Amiga, read 
up on it a lot. By the time I could afford one (busboys don't make 
a lot of money) the Amiga was obviously done for.

But - 1.3 project was about concrete implementation ... we wer loosing 
time with things like arguing over button's border thickness etc., 
not starting with bigger picture. But - for new View, there was promissed 
to be SMALL group (so small, that it fits Carl's idea of closed team 
working on new stuff), which will create bigger picture.

I repeatedly asked here, if such group works in other altme Worlds, 
etc., and was assured, that once there is a time, it will be formed. 
And I could also see, that guys as Henrik, Anton, would very much 
appreciate being in such group.

without that nagging bad taste in your mouth every time you try to 
do something where you realise you have to "again" reimplement half 
of what you are working on before even starting.

I hope I can get the liquid net working in time for the release, 
otherwise it will be its first update.

Gabriele, I only think there is a matter of miscommunication. Some 
time ago I joined a private GUI design group in here, which was called 
the official one for R3. I can't remember who started it, but a lot 
of people, including Pekr, joined up. So I started working on concepts 
for integrating an animation system into VID. I think people are 
a little upset, because it felt like RT were going behind our backs 
and wanted to pull R3 GUI in your own very different direction and 
disregard the work we did.

Being a REBOLer from a lot of years being not a guru, especially 
in the GUI area and having suggested REBOL to other programmers I 
wish to share with you my pov that, maybe, can explain the situation. 
The lack of documentation and the initial easyness of VID is a deterrent 
for programmers to adopt REBOL. In the last week I asked Anton for 
help with some VID and styles and he wanted feedback from me. He 
did a few things (an analog clock style and some adjustments to his 
scroll-tables) but make up his and my mind about some design details 
is still not over as need, POVs and uses of the same style can be 
very differents with two people involved (with one being the programmer 
and the other a little user like me). Imagine an as small as you 
wish group and try to figure out the time it needs to decide design. 
Put this together with the pressure of not taking too much time to 
release R3 before July and I think it should be clear why Carl has 
to stop asking opinions (after 2 years) and put more time on coding

that will not take much time, and Gabriele might feel safe, that 
his implementation or proposal adresses most of wishes ...

I fear that noone will understand deep DF thoughts, and that novices 
extending GUI might feel once again lost, like they were when looking 
at VID internals for the first time :-)

allowing me to use a gui and open it up in OpenGL, activeX, if I 
have the need/resources/time to provide it.  I mean to be able to 
extend the whole engine so I can skin it without needing to rebuild 
100% of the gadgets, etc... many of the things we spoke at the devcon, 
but more too.

FYI;  The informal Bob's Rules of Order time limit runs out on the 
REBOL User group

proposal tomorrow.  I think there is some consensus, and reading 
this it really looks

like a formalized Executive Summary would be beneficial to everybody. 
 Even if it

never gets read at RT, it'll let the community vent steam and brainstorm. 
 Expect 

an Agenda for the formation of a formal group on Saturday.  First 
meeting here on

Sunday-Monday-Tuesday.  I've tagged Bob's rule at 72 hours of 'floor' 
time,
(unless voted on and changed) after the organization forms.

no code first - i don't design from thin air. i need to write code 
to design. i don't care if it's thrown away, i do that all the time.

my point earlier was I'd like R3 to have time to actually try out 
different approaches, have them working code, let the community try 
out, maybe even create different propositions and take the time to 
use and have fun.

there is not team, there was no team. Team needs rules. To set rules 
you have to adhere. If you break the rules, you should be dismissed 
from team after some time. If ppl do adhere to rules, team has its 
sense ...

liquid took a long to mature, but the main reason was that I'm doing 
it on my pass time.

It seems to me that the main concern is that some programmers have 
been working on projects for several years that they cannot finish 
unless they are allowed to hook more directly into the guts of view. 
They are concerned that all the time they have put into their projects 
might go down the tube. Does that sum up what you guys are saying?

4 - 6 months ago I asked in one blog reaction, Carl to blog about 
the plan towards View itself. IIRC it was supposed to come, and that's 
it. Some things were not decided even at the time of devcon (e.g. 
if draw dialect will merge with effect one). View kernel development 
seems to be implemented with no certain vision - we just know we 
wanted richtext, and view being less resource hungry and faster in 
blitting :-)

the difference I think is in how information flow to and back.  proximity 
removes the need for a lot of structure, yet it also has some drawbacks. 
 distance doesn't allow much to happen without structure and time.

Its possible next time, we should start with a more "specific" topic, 
so it doesn't stray to far... I think the main issue here was that 
there was no real direction at its outset.. it was mainly... ok, 
tell me anything... and it just flowed that way.


now that its out, its done.  we should now concentrate on specifics. 
  :-)

next time, it should start with:  "what do you guys thinkg about 
XXXXX"  then you will get real insight.

next time, it should start with:  "what do you guys thinkg about 
XXXXX"  then you will get real insight.

I know you guys care.  which is why I took the time to write out 
the collection of points... you know it takes time to summarise such 
a discussion  ;-)

I would like to be a part of the early access group, but not for 
VID. My GUI experience is founded in quite different environments 
and my input about GUIs would be more along the lines of API cleanup 
and other low-level stuff. For the major design issues, I defer to 
Carl, Gabriele, Cyphre and the other capable people here - I trust 
your judgement.


I would like to help with some of the other parts of REBOL 3 though. 
My main interests are in language design, interoperability issues 
and platform integration, particularly Windows platforms and derivatives 
since that's what I need to use most of the time.

yes, where would probably depend on the application. note that when 
i say long term in that doc i mean 1-2 years, so there's plenty of 
time to discuss that stuff.

If I try to make a MacOSX program in Cocoa, I'm actually pretty restricted 
in what I can do in terms of UI guidelines. I have to follow their 
menu system and structure. I have to follow their windowing system 
behaviour. I have to have an icon in the dock and I can do certain 
specific things with the icon. If I choose to, I can even let MacOSX 
handle loading and saving of data and preferences for me and handle 
the aspect of multiple documents for me.

I could probably code my own stuff, but since Apple have spent years 
designing these UI elements and guidelines, I see no reason to do 
that, since it provides a high amount of consistency. It's actually 
pretty hard to make something that looks shoddy or amateurish, unless 
you start drawing up your own graphics elements and ignore existing 
guidelines, which would be a huge waste of time. MacOSX is exactly 
being touted as being a fast environment to develop in, because many 
of the tough design decisions have already been made.

Many years ago, before Rebol, I designed a language called MIDAS 
(Machine Independent Demonstration and Animation System). Unlike 
most acronyms, this really was exactly what the language was for.


It had a lot in common with Rebol, and worked on lists of words or 
data.


Its goal was simple, to work backward from what we know all systems 
need in order to demonstrate and present UI and animations (video). 
 We were reinventing the wheel, every time we made something.


I knew for example that there had to be a screen, although some systems 
might be Bitmaps, some might be bitplanes (the Amiga), and some where 
character maps (C64).  That the system might or might not have double 
buffering, etc


The idea was to have the language work backwards from the goal, and 
to have code that would force all the media assets to conform.

So for example, you have an image, and you want to show it.

Show image.jpg

I designed this as P-code, but the point is the same.


You would then execute the program MIDAS on the code in the first 
pass.  It would ask you questions about parts of the code.  The image 
here would be in question.  So an images process batch would be created 
for each image.  Allow the image to be processed from the original, 
or built by hand (in the case of the C64 which only had a few colours 
per 8x8 square).


The reason I'm explaining all of this is that the Menu system you 
describe is the same issue.  Most menuing systems are the same, or 
close enough.  The worst case is some special handling, for shortcuts, 
or for allowing items to be checked inside the Menu (the Amiga had 
this, I loved it!).

But the code should look effectively the same.

Instead of arguing, I propose we spend our time doing something productive, 
like reversing caret-to-offset and fixing that long-standing issue.

anton, isn't this a simple matter of a search/replace in the global 
source tree of rebol 3? if there is a time to make a deal out of 
it, it should be now.

I agree with Anton on changing names. In fact, I have totally changed 
my mind about renaming REBOL or any parts of it. The reason is that 
it would make obsolete all the documentation, etc. It would be like 
throwing all that work away, and would cause terrible confusion. 
I was perhaps the most strongly in favor of a name change, but after 
thinking about it more deeply I've decided I was wrong. Also, I think 
that REBOL has been around long enough that a fairly long number 
of programmers have at least heard of it. And now that R3 is coming 
out, it is very likely that a lot of people will start to give it 
more attention. So this is not the time for change.

but this is one word in R3... there are no docs yet on it. I would 
assume that the naming and design phase of R3 is not yet entirely 
complete. so if there is a time to rename things, this is the best 
time to do it.

I just wonder - some time ago, someone wanted the ability to "store" 
cenrtain rendering node,  could it be done with gobs, if they are 
separate?

both. Gremlins are the cuter ones (if defined by movies).

About gob, i imagine one speaks with customers about the gui and 
uses gob all the time. Sounds not that nice..

i think the people in the movie would not agree with "funny", but 
maybe i don't remember the movie very well. it's been a long time 
;)

Maybe the name fits. Working at that low level with c all the time^^

I just wonder ... dll is just cross platform library, right? And 
if I understand it correctly, then in that dll there are mainly structs 
defined, which you have to fill-in, no? IIRC something like that 
was said in blog regarding getting OS time. So I wonder - is linking 
dll to your app sufficient to run rebol code? Or you would have to 
port also platform specific things?

cert parsing - how much time would have that been? one day? two days? 
if you save a month by using rebol, then what's the problem with 
two days?

otherwise, if you don't save time, just go with delphi - what's the 
problem? we can't possibly do everything for everyone.

Ah, so you talk all the time, if something should be part of "standard" 
rebol or not? Well, that is misunderstanding. I don't require something 
to be included. I am ok with extensions, libraries.

having more time, i'd just study the binary file format and parse 
it myself. i don't see any show-stopper.

What I am talking all the time about is - how to build trust in distributed 
environment. Some of us will need to produce scripts with lowered 
security. If I see a requestor asking me for lowering security, I 
will not run the app, unless I can be sure, that it comes from Gabriele 
for e.g., and that if Gabriele ruins my HD data, I can visit DevCon 
next year and ask for refundation :-))

yes, it is half a time between the first and second developer's release 
- so, guys, give us unlucky some spoilers :-)

we need someone willing to play with schemes and mainly test http 
and so on. anyone? you need some free time and possibly some understanding 
of http so that you can give better feedback ;)

ditto.  but time is thin

I suggest DocKimbel, he is supposed to work on Cheyenne full time, 
so he might be interested to test especially http :-)

and as for July, I will be just few days at work, then vacation, 
most of it off-line (rock festival for few days, High Tatras from 
21.7., but that time, it should be already a public beta release 
....)

I think that View is part of the release .... not much was said about 
VID prototype. Last time I asked it was not done yet ...

currently the GC outputs every time it GCs, but I don't know if that 
will become a debug functionality as it's just being printed unconditionally 
on the console right now.

My biggest fear is when R3 comes out... it will have so many new 
things, areas to cover, projects that will be made possible. It's 
seriously going to require at least 50 people to cover it all, and 
it will take a long time to cover it all and I think R3 will be vastly 
under utilized for the first 1-2 years, possibly longer, if people 
won't join up to fight for the cause.

It's amazing to think that this little nucleus that is R3 will make 
all that possible. I keep thinking that if PHP is a firecracker, 
Python is a handgrenade, Ruby is a box of dynamite, R3 will be a 
nuclear bomb.

Even R2 is not very well utilized yet. Now if Geomol was a full time 
paid developer, he could probably give us a full postscript engine, 
for example.

Kaj, thanks for the offer. Currently I am pressed for time, finishing 
some strategies in my new job. We can get back to it in few weeks 
....

Geomol, yes, people are working very hard. I wouldn't consider the 
delays as anything to worry about if the dates were not published. 
There are no setbacks or things that have failed or strong disagreements 
or detours into "ohh, shiny!" land. :-) It just needs to take the 
time it needs to be finished.

Henrik - is there a concept of window in new VID? As I said - I would 
like to have one. We should decide upon what will view/new do. I 
am not sure I want it to open new OS level window. That will make 
plug-in apps suck big time. I would welcome the choice - for desktop 
apps let it be e.g. OS window, for plug-in, VID windowing ....

oh, well, next time i'll forbid people from posting screenshots. 
:)

oh, well, next time i'll forbid people from posting screenshots. 
:-)

 <-- OK, that's it, I won't say anymore about R3 until after beta 
 :-)

it can't be in two panes at the same time.

i share your pain, i use wine all the time, and there is actually 
one bug in r3 on wine that forces me to start the other pc with windows 
sometimes.

also about docs... i plan to be available here full time for a couple 
days after release, to answer all questions and provide some kind 
of support.

Brian - so you still think that R2 release is going to happen? Well, 
maybe it will, but so far my opinion lasts - there will be no R2 
release - there is no time for it, and it steals time from R3 issues, 
and R3 is next-gen for us. My suggestion is to concentrate upon R3 
already.

pekr, I'm just saying that the developers don't need to answer questions 
for things that are already planned. "what about this?" "what about 
that?" "why is X feature not there?", etc. Rather spend time finishing 
VID3 than talk about how to finish VID3. :-)

everything takes its time :-) I'm just of the opinion that soon, 
an army of developers will be needed to take advantage of R3 to bring 
it to its full potential.

So I'm still back to planning for say an Invoicing application for 
a site boss.  That will be R2 code base for quite some time, no?

Why aren't guys like Geomol already in? I mean - I don't want to 
be there, I was in 3 months testing period in my new job and had 
no time to test etc., but Geomol seems to be actively developing. 
I think such ppl could be there in the next wave ;-)

Pekr, yes I'm rebolling quite a lot these days! :-) The BASIC dialect 
is done in my spare time. At work I'm doing a COBOL formatter in 
REBOL as we speak.

I am far from being off base, because I know what I am talking about, 
and I also understand your point. The examle with "democracy" was 
just that - example. It is quite some time when I saw some ironic 
or sarcastic comments here.

(Not talking to Reichardt specifically, but to those who could give 
some updates from time to time ... )

No, there are some things still missing. I'm not even sure that a 
port can be warranted as the system is very different, so it would 
take shorter time to rewrite it. I have long wanted to rewrite it 
to separate list operations from the display more.

we're doing both subsystems and the styles at the same time. neither 
are finished at this point.

- Carl managed two releases today, the last one added a request-file.

- I've been working on some very thorough 64-bit decimal testing, 
and I found a couple of bugs. Better to find them now than after 
a public release.

- I made a little program to help getting a view on the alpha situation. 
(tests, bugs, etc.)

- I just had a talk with Carl, and he has some more to say about 
testing. He has a test script, that was used for VID2, that he wants 
to get running under R3. It should make it easier for all the testers 
to get more done faster. Testing this is big project, but there is 
progress all the time. Just 4 updates to the bug tracker yesterday, 
but more than 20 updates the day before. (Both new reports and solving/testing 
old bugs.)

Some more output from the R3 console:

>> length? system/words
== 1296

>> ? system/datatypes

SYSTEM/DATATYPES is a block of value: [end! unset! none! logic! integer! 
decimal

! percent! money! char! pair! tuple! time! date! string! binary! 
file! email! ur

l! tag! issue! bitset! unicode! vector! image! block! paren! path! 
set-path! get

-path! lit-path! dictionary! datatype! typeset! word! set-word! get-word! 
lit-wo

rd! refinement! native! action! routine! rebcode! op! closure! function! 
frame!

object! module! error! task! port! gob! event! handle! struct! library! 
utype!]

>> ? system/view/event-types
SYSTEM/VIEW/EVENT-TYPES is a block of value: [

    ignore interrupt device custom error init open close connect accept 
    read write wrote lookup ready done time show hide offset resize active 
    inactive minimize maximize restore move down up alt-down alt-up aux-down 
    aux-up key key-up scroll-line scroll-page drop-file
]

A little update from Alpha testing. Since last time, this happened:

- POWER can now handle negative number and exponent

- Some bugs fixed regarding: money!, path, VID crash, change/part, 
read, function and closure recursion crash, compose/deep
- New dictionary! datatype (replacing hash!)
- A lot is going on in the graphics, VID and DRAW groups
- Ongoing work to get the test methods to perfection

We're now on Alpha 49.

Carl asks about better name for dictionary!, which is a bit long. 
I think there is only one alternative, if we want the name to be 
on pair with other languages - dict! ... the thing is, that we don't 
use abbreviations in REBOL most of the time, but we have func too, 
so why not dict! ?

some time ago we thought about allowing other chars for money. Or 
something like USD$123.123 ... the question is, if there is some 
better char to be used for amount of various units?

yes, if BCD in general would be usefull for other things than money 
and bank apps meaning, then it could be the right time to do so. 
I was inspired by dictionary! to map! rename, so it seems the team 
is open to ideas in that regard....

Petr; I use money! all the time with the contruction accounting scripts. 
 Bosses love it, until I have to pummel them for using commas in 
big money! and with construction projects it doesn't take long to 
get to a monkey.

pekr, I think you are nitpicking way too much right now. We don't 
have the time to make pretty well-organized docs right now. Your 
input will be much more appropriate when R3 goes into beta, when 
docs are opened up and we have time to deal with this, OK?

Pekr, we _will_ be getting back to these things you mention. it's 
just not the right time yet. There is plenty of progress, but still 
plenty to do in terms of code, where we can't just write docs out 
of thin air.

There is so many other things. But we need to input. In fact - I 
don't agree with www.rebol.com world release, unless RT finds time 
to discuss other things. Because - I want R3 to be successfull, so 
I would prefer to prepare on other fronts, as I said  ....

i agree with you actually, but do you really have the time to write 
them? if so, i'm sure Carl would welcome you. :)

(btw i started doing easy-vid3 using easy-vid text as reference to 
make it "similar" in how it reads etc. but i don't have enough time.)

re free time. Not sure about the free time, but I don't want to sound 
like allibist. I might try. However - not in the case if you think 
that it is my method of how to get R3, as it is not the case :-)

My opinion just is, that whole design process could be two staged. 
E.g. ppl here could get access to transcript from alpha group chats. 
Ppl could also talk about it on ML. And why you think someone here 
on on ML could not raise some valid input? :-) It would be then on 
Gabriele or anyone else to use that input from userbase, or not, 
depending on "free" time to read it. So much for the organisation 
...

What I speak about here is mostly feelings. But sometimes how we 
feel about the code for the first time also might mean, that we either 
stick with the tool, or we leave it. If I can see few lines of VID 
code and not being able to understand what it does, unless there 
are comments or the need to go to the docs, then it is not good for 
the tool. It should be mostly obvious at first sight ....

Petr: let's assume that each person here did provide some input. 
there are 244 users here. reading all that would take a huge amount 
of time, and most of the feedback would make no sense unless you 
guys have actually used the system. you know, things are not going 
to be set in stone when beta is released, if we get valid input, 
we're going to listen to it. but, first, we solve the most obvious 
problems, and with a small group it's much easier to do so! you seem 
to underestimate the "management" work that is necessary whenever 
you have a bigger group. we don't have a person dedicated to support 
only - it's mostly me doing it, and i must handle three altme worlds 
at a time - if they were all big like this one, i wouldn't have any 
time for any coding.

There was a time, just when VID3 discussions had started last year 
that it was proposed to make VID3 way more scalable and powerful 
at a slight cost in ease of use. It certainly is way more powerful 
now. I can't see any dead ends or impossibilities where I'm sitting, 
like you can with R2 VID, but the ease of use never went away. It's 
a lot easier to use than R2 VID. I'm also betting that implementing 
new features will be a breeze compared to the wrestling you had to 
do for R2 VID.

graham, there are way too many dependencies on R3 to backport R3 
VID to R2. It would probably also take as long time to port it as 
it has taken to write it.

Building two operating systems also tends to take a fair amount of 
time, so I'm not clamouring for more work

Brock, it's mostly a time issue right now. Still a lot of loose ends. 
I have no idea of the porting process as it's not documented yet, 
and I don't expect to be doing the porting. I do expect that as soon 
the process is properly documented, anyone with experience in C-programming, 
will be able to do a port.

The terminology that exists today wasn't used at the time. It's vague 
whether you should call Amiga a microkernel, or it's tasking multi-threading, 
but it basically was

Hi Pekr, I'd love to get my hands on an R3 alpha ... and I maybe 
would even have the time to play with it, but at the moment I don't 
feel like I'd have the resources to do some serieous testing. 

So, on the plus side, you don't have to expect a flood of error reports 
from my part ;-)

Gab, do you think Rebol could support one of those online real time 
multi-player sites with chat like Yahoogames?  Perhaps using LNS 
?

maybe time for a status update on Carl blog? 8-)