AltME groups: search

I can even imagine unit conversion table, so that we could get even 
USD + EUR result .... and if expression would contain some non transferrable 
units, e.g. USD + kg, then error would be raised ...

Write that down somewhere (other than only here). When the DocBase 
go public, there could be a place there for new ideas and suggestions.

or we just could state, that $ is simply a unit char. And rename 
datatype from money! to unit! :-)

yes, as i said, i think only # $ and % are "special" for the parser, 
so that you have to pick there. carl picked # for a lot of things 
because $ and % carry meaning.

kg#123 and kg$123 sound equal to me. It is just that the datatype 
is called money! Dunno if english unit! term would be more descriptive/general 
...

#123 is an issue so kg#123 would mean that you always have to specify 
a unit... and a space by mistake becomes a subtle bug.

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....

I don't agree to that argument though. Even core will change, protocols, 
schemes are different, and btw - what about missing hash? I remember 
using hash, but I never used money! IMO money! is the least used 
datatype in REBOL :-)

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.

Gabriele: Why not leave money! just as it is for compatibility for 
the people who want to use it and introduce a Fixed! type. (I didn't 
call it BCD because apparently it isn't). The following behaviour 
(modelled on IBM 360) would be ideal:

>>fixed-dec: 1.98F2
== 1.98
>>type? fixed-dec
== fixed!
>>print fixed-dec
== 1.98
>> probe fixed-dec
== 1.98F2
>>2F2 / 3F2
== 0.66
>>2F2 / 3F2 + 0.005F3
== 0.67

why "standard" BCD aproach was not adopted? Is it binary represented 
or not? I mean - can we be sure that some weird rounding will not 
happen, and that the number stays allways the same?

petr: because this the current money! format is faster and takes 
less space (you can't pack 26 bcd digits in a rebol value otherwise)

And I fear one things - it will all be cooked behind the scenes, 
and we will be presented with result. So far we were told to trust 
what the group comes up with, but I really wonder, what that group 
of 20 or so testers is doing, if docs contain things like using "-" 
char for "no value to change" meaning, instead of none :-)

I read every VID related doc more than 5 times, and I am only slowly 
starting to get the idea behind it :-) So I wonder - is new VID conceptually 
so complicated, or there is still not enough docs to get the idea? 
:-) There are already things I like a lot, but there are also some 
worries, although those migh show as minor. Maybe some better explanation 
(more docs) will help the situation ...

The trouble is, that just because we are not let in in the early 
state of development, we might miss the influence on what the new 
VID will all be about ....


Do you really, really want that? The only thing you'll get is "design 
by commitee" and slowing things down.

whereas nowadays we get "no comment" and similar results ...

you asked at one point how much the docs correspond to the state 
of VID, and I think they are revealing probably 60-70% of what is 
there now.

From my pov, I can already see some things, which are a bit disappointing. 
I represent userbase as any other potential user. And I can already 
imagine typical answer - "you can create your own GUI after all" 
:-)

btw - looking at RebGUI docs, and thinking about VID2, I found out, 
that I like keywords very much (effect, font-size .... , on-click 
etc. in RebGUI). I hope that concept lives and is not replaced by 
awful with/options aproach, which burns you deep inside VID internals 
...

rename on-get-value to on-get-default .... When I first saw the two 
- on-get, and on-get-value, I could not find out, what on-get-value 
could be about. Just recently I read doc explaining it in one simple 
sentence. But - I dont want to read docs and I still want to be intuitively 
able to understand the meaning, if possible. And "default" immediatelly 
caught my eye. If you don't believe me, just run "source switch" 
and look what we already use in rebol :-)

Currently reading docs (and I know they are supposed to change) is 
like reading a facts ... there is function xy, which does that. But 
the question of novice is - but why?

Mostly when I think about presentations or some docs, I try to imagine, 
what might typical user need to understand the issue. And also - 
what I needed to know, to finally get it too. that is just my suggestion. 
And that is why I liked R2 View engine doc from August 2005. Awesome 
work. I hope we can adapt to it ....

E.g. - let's look into some VID reference Introduction. Some may 
find it vague, and saying nothing:


By their nature, graphical user interfaces (GUI) are more descriptive 
than they are functional. In REBOL, the Visual Interface Dialect 
(VID) provides an efficient method of describing GUIs. VID is implemented 
as a layer that rides on top of the REBOL/View graphical compositing 
system. VID provides shortcut expressions that are automatically 
translated into View objects and functions. You can seamlessly combine 
VID and View code and data for great power and flexibility.


Whereas for me, it s real jewel, as it introduces me into concept 
of relation of View and VID.

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?

Henrik - for you I might be nitpicking, but from my pov, it is just 
you, who is missinterpreting meaning of my requests. And that is 
maybe the difference between good developer (you) and mostly IT manager 
(me). I follow different patterns ...

I think the whole situation is cause by you commenting on things 
that are not done. Perhaps it's a good idea to close the docs even 
further down now, so you can't see them anymore, so we'll at least 
have the piece and quiet required to finish them.

Henrik - and I find you latest remark very arrogant.

And I want Alpha group to be extended by Alpha+ group, which could 
work on other things which might be needed sooner or later. There 
is lots of work on other fronts too. You would have not to think 
about how to write docs if others would write the docs, can't you 
see it? But then you would have to stop playing elite ....

and Pekr: VID3 kicks ass. :-)

amacleod - there aparently is more things that are complete - you 
saw the mention docs are some 30% behind? And have you ever been 
in process of writing docs? I mean - in the team? Do you think that 
ppl only wait for the work to be 100% finished? Some concepts HAVE 
to be already in place. I prefer to rewrite/restylize docs instead 
of writing them in a hurry ...

and as for VID3 kicking ass - I hope so, as I like my little fights 
with Bobik between VID and PythonCard, so I really hope I have some 
new fresh blood in my veins for my new round of evening tea talks 
;-)

indeed it kicks ass. a very small example:

view [progress slider attach]


slider is attached to progress and will adjust it's length automatically.

and you get automatic resizing thrown in for free

ok, so talk with brian first. then let me know and i'll talk with 
carl.

Brian - I exactly understand what you mean. The bad thing is, that 
when you feel you have something to say to the design itself, you 
can't, or you don't want to, to not spoil the chefs. But - I will 
write docs only to desing I have 100% trust into. So far I have some 
worries. Those are more philosophical ones. E.g. worst part I read 
so far was 'tight command, which imo has bad influence on how VID 
code "feels". So - at first run, I will try to read most past discussions 
and try to understand new design philosophy. There surely are differences 
to VID2, mostly that styles seem to be organised in groups (columns). 
I can't e.g. see VID2 keywords like 'at, 'across, 'below, 'return, 
etc. - so, how I said - I first need to study the design. Then I 
will have some questions. 


I will ask those questions to Gabriele privately, to not flood the 
group, and because he is master designer. I think that guys managed 
to create strange atmosphere here. Since when is the design a closed 
effort to those who are interested in the design process? I don't 
remember it happening even with View 1.0 - ally mailing list. Everybody 
interested could reply at least on mailing list - no wait and see 
mode. That is exactly why I asked for the design docs first, althought 
I understand Gabriele's point of rather coding first. But the aproach 
of "watch, but don't spoil" excludes others from the design.


So once again - if I find new design unpleasant to use, difficult 
to use and explain in the docs, I may also departure from the effort.

Petr, well, there must be one designer. since we already had like 
7 years of feedback on the design of vid, i'm not really sure much 
more is necessary, but we're always listening for comments. your 
problem is that you always make assumptions and then complain based 
on your assumptions. please stick to facts. the fact is, that i've 
been in the rebol community since 1999, and I have implemented many 
VID apps. I read the ML, I read here every day, I read reboltalk.com, 
I read every ticket in RAMBO. i'm not really sure you know what vid 
should be that much better than me or anyone else here.

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 
...

Now back to VID and syntax. It is now for you Gabriele, you surely 
will understand my reasoning. I don't mind if you don't agree with 
me. We are here not to necessarily have identical opinions ....

Let's say I am very average rebol coder, and that I also had one 
person, which I taught REBOL, VID specifically. I saw various VID 
code in the past, some was pretty and self explanatory, some was 
more messy. I e.g. liked simplicity in most of IOS reblets. The ugliest 
design in VID2 is a list for me. Thru all those years, I catched 
several ppl, to not really get it. It is kind of "usage pattern", 
and if it repeats, then we should think, if the aproach is best for 
the user. E.g. list style assumed cnt word in its block, and it was 
really confusing.

When teaching VID, my basic understanding was, that Bobik generally 
liked it very much, unless he had to touch its internals. The last 
escape was 'with. Creating new style was mostly a show stopper. What 
I and even him really liked, were facets. It is like the last easy 
chance of how to move upon the surface (VID), without the need to 
go under (View).

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 ....

To better understand my very general concern, not concrete complaint. 
Let's talk simply command usage, e.g. zip:

zip.exe what -a param1 -b param2 param3 -c param 4 
zip.exe/a/b/c what param1 param2 param3 param4


As you can see, in REBOL there is much more emphasis put onto user 
remembering the order of the paramteres, whereas in the first example, 
user simply takes desired parameter, and in THAT context, specifies 
the parameter value. It is shorter path, and user does not need to 
follow long patterns.


VID, in relation to above exple, might or might not be similar. We've 
got facets, which too, allow immediate context modification of particular 
parameter. For me facets are one of the strongest aspects of VID 
semantics and how it relates to lower layers.

Then we've got keywords for VID, which I like less. They are somewhere 
in your VID code, and mostly are as switches - 'at, 'pad, 'tab, 'across, 
'below, 'return. They are more difficult to follow, because they 
somehow "fly" in your code, and you have to look for them, to know 
actual state, when writing your code.


And now to styles - I don't like too much, if something outside my 
style, influences my style. So, how self-explanatory is "tight right 
off left 50% top 100%"? There are few possibilites, well, yes, based 
upon my assumptions:


1) the design, from my pov, is not right, and 'tight should be a 
facet to the style. We reach philosophical difference of object.show() 
or rebolish show object (or more objects).

2) 'tight does not affect real/internal margin of particular style, 
it stretches spacers used in group column model

3) the name is not self explanatory. Even first sentence description 
talks about margins. So why not 'margin or 'set-margin, which would 
be much more obvious at first sight ...

And you see, those issues might look as absolutly minor, for most 
of guys here. I am not language purist. I don't care much how you 
cook VID inside, but how will VID level code attract the eye of newcomers. 
We want to have millions of them, right?

Those aspects are nearly psychological, but judging upon my experience, 
when trying new stuff, I mostly follow following pattern - see screenshots, 
download product, install, try to run it with some examples, look 
at sources. Only if I am interested at first sight, I consult docs. 
I think that might be pattern of most newcomers .... if VID code 
will be obvious, they will stay and go eventually deeper. There is 
why I care so much for the "surface" of the things ....

petr: when i talk about "assumptions" you make - you make statements 
that sometimes have nothing to do with the current code or with what 
we plan in the future. you make them just by looking at some doc 
or something i or henrik said and then you "connect the dots" in 
your own way assuming that something is going to work in some way, 
or be limited and so on. most of the times, it's just the docs that 
are missing or the implementation that is not final.

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.

*I* don't think VID3 is going to be broken. I know that Pekr complains 
and docs can be spotty. That is the nature of the universe.

Latest report: Nothing big has happened in a couple of days. Carl 
is buried in some work and bugfixing. I'm building the new requester 
system with the new way to parse dialects. 267 bug reports listed. 
Cyphre has talked about speed optimizations that will be made to 
the graphics system. Pekr is talking. A lot. :-) Gabriele is also 
busy coding.


There are many requests on ports for OSX and Linux as this Windows-only 
thing is getting rather old. Geomol has shown interest in the OSX 
port. Brian Tiffin has shown interest in the Linux port. Both, I'm 
sure, could use some help at some point, if anyone is interested. 
:-)

I'll just wait for the Linux port, and then R3/Core will probably 
compile right away on Syllable, thank you very much :-)

Henrik, does this mean that it is going to _much_ harder to port 
R3 than previous versions?  I realize it will be harder as there 
is likely more system dependant code than in the past?  I also realize 
there is going to more dependence on the community to kick-in for 
various platform ports.  I agree however that the linux and OSX versions 
should come after the windows, but the plugin needs to be within 
this calendar year.  [Unless R3 is going to be so good without it 
that the X-internet that was invisioned years ago will be more possible]

I thought one of the reasons behind the R3 re-write was to make it 
much easier to port Rebol to different platforms. I believe there 
is a complete segregation of 'core' and 'platform dependent code'.

Brock; To add to what Peter said, it might be hard to say whether 
a port will be much harder, but there will be a far greater potential 
for getting more people involved.  So we are faced with the unknown 
of whether random masses can produce more than a select few; in term 
of better, stronger, faster.  Will opening the OS specific side free 
RT to focus on the core technology or saddle them with testing,  
filtering the various ports and spending all day answering developer 
questions?  Soon to be seen.  I'd hedge on the former and look forward 
to a tide of momentum.

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.

Unix has a rather big separation between heavy-weight processes and 
light-weight threads. Threads may only be implemented in userspace. 
On Amiga/BeOS/Syllable, threads are light-weight and are based on 
kernel tasks

So, would you guys welcome to particiapate? Note: I have no mandate 
to promise you any such thing, I am just investigating possibilities 
of how to help others to get in and eventually help ....

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 ;-)

And it will resize appropriately?

2007, and still going ga-ga over buttons.

Terry, there is more work done, than just buttons. Python has tonnes 
of developers, yet they plan 1 year or more for 3.0 to appear. I 
read some of their plans, and even if they change many things and 
break compatibility, it all sounds like cosmetic changes in comparison 
to R2 vs R3 ....

Just a note for those who might be curious. From Carl today:

Just a note of interest...
I've built the first version of R3 for Linux and OSX.
Console only, with file and dir I/O.
They pass most of the non-graphics tests.

John (Geomol) will be working on the OSX features in the days ahead.


.... just to let you know, that other platforms are not forgotten 
....

Never satisfied, Terry? ;-) 40+ was exagerrated too - various Linux 
flavors are just one OS. And remember, with R3 - who wants to port, 
can. REBOL.dll, the only closed part, is platform agnostic code, 
so in order for RT to port, all they need to do (theoretically), 
is to recompile .....

As for me, I initially expected only Windows version of R3. But due 
to certain popularity of OS-X and Linux fans here, other ports are 
already happening. What is wrong with that?

I'll be backporting the Alpha release history on the calendar here 
for the curious.  I'm working backwards and info will go in in spurts.

yes, from now on, it at least seems, that we can post new info here, 
non ML, on rebolweek. And if I understand it correctly, Carl will 
open-up some plans - he want to add another ppl into various areas 
- code, testing, docs, website and marketing, etc.

New Blog Article: R3 now on Linux and OSX
http://www.rebol.net/r3blogs/0102.html

Oww.. oke... what I was refering to was (from the last Blog ..."But, 
now that's been said, if you have the expertise and knowledge to 
contribute to the project, and you really enjoy fine-tuned engines, 
please do not hesitate to contact Gabriele or myself."

There is a new algorithm for empty parse to avoid the some end infinite 
loop...afaik, and I know little. :)

But what Im actualy missing in the global Blogs on R3 is a statement 
on the functional behaviors on R3 function? I assume they globaly 
stay the same and no big impact is to be expected, besides new functions...

Rebolinth, the main difference between functions in R2 and R3 is 
that the values assigned to the local variables in an R3 functions 
are freed after the function returns, while that is not the case 
in R2. Oh, and they're faster.

If I misunderstood you and you were asking about the behavior of 
particular functions, you'll have to ask about them individually. 
Many are changing from mezzanine to native, others are changing from 
native to mezzanine or a hybrid of the two. Many are going to be 
able to do more.

Small R3 update:


We can do modal popup windows now and fully borderless windows. This 
should help in building a real popup menu that isn't limited to the 
size of the main window, like in R2.

I'm building VID3 tests so we can find bugs in the layout engine.

Alpha 81 was released yesterday.

332 bug reports in the tracker.

Soft font shadows are cool. :-)

Just curious if anyone has any info on tables in vid3. They were 
pretty poor in R2 but I think they are a key element for many apps. 
I took a quick look at "turbogrid" mentioned in the Tech News forum 
and its crap. it's Ajax based.  A list-view based app in a plug in 
would blow it away.

About plug-in...I need to change my mindset about it. I always avoided 
thinking: "Nobody wants t have to download a plug in o use your site. 
But I find myself needing to do it all the time and some of these 
new technologies like silverlight, require a download of some sort. 
 Rebol plugin downloads so fast it really is a minor annoyance. WE 
just need it on more platforms and browsers.

My take on graphical tables;  R2 had a beautiful base for this with 
list and supply.  Downside was that the documentation was so limited 
and late comming that no one could comes to grips and we all mostly 
ignored it.  We lost out on the ability to build on the shoulders 
of giants as using list and supply pretty much meant learning by 
expermentation, coding from first principles and not from tool kits 
and cookbooks.  Hopefully the power gems of R3 and VID3 will not 
suffer the same fate.

btiffin, I agree. Clear and complete documentation is essential. 
Few people will take the time to study source code. No matter how 
great a language is, it is useless unless people can easily use it 
to do what they need to do.  An inferior language that is documented 
well is very likely going to attract more users than a great language 
that no one can figure out how to use.  Core is fairly well documented 
I think, but I have never been able to get past problems in View. 
 I'm really hoping that the docs for REBOL3 will fully explain View 
and give lots of examples, especially showing how to interface view 
with databases, etc.  But writing good docs is very difficult, because 
the creators of the language know it so well that it is difficult 
for them to put themselves into a beginners shoes.  It is easy for 
them to assume that the beginner already understands things that 
, in fact, he doesn't understand at all. Anyway, I have high hopes 
for R3.  And I can do more with R2 than I ever dreamed possible, 
so I really can't complain at all.  That doesn't lower my hopes for 
better view docs though. That is the way we humans are: the more 
we get the more we want.  :>)  They call that being spoiled.

uh, filesystem? IIRC RT was talking about RIF - rebol idexed files, 
so kind of file with header, for custom db and other purposes. That 
is all I remember ....

Kaj, there is a lot of work being done. A lot needs to be finished 
before R3 can be useful for anything that R2 can't do outside benchmarking 
and a few demos. I wouldn't start planning thing until the first 
beta comes out.

Sure, I'm familiar with how it works in big projects. The point is 
that the only ones who can give try to give meaningful estimates 
are the ones doing the projects, and we all know what dates were 
promised over time

Of course not. I think the problem is that people expect R3 to be 
done in a hurry, since we already have R2, so what's the big hold 
up? (and personally I think the beta date of 1st August caused more 
negative talk and damage than I think Carl expected.)

I don't need a perfect R3. I just need to make some forms and other 
simple things, but I don't want to have to redo them a few months 
later

I don't need a perfect R3. I just need to make some forms... 

 <-- For that you need VID3 to be complete and the view system as 
 well. You need skins and you need a functioning event system. You 
 need keyboard input and a proper way to direct form text data to 
 objects or file storage. Furthermore since you don't want to change 
 it, we have to have the layout dialect in feature freeze, which it 
 isn't. It's currently undergoing design review, before we add more 
 features. Not simple. :-)

Gabriele said something to that effect when Carl opened development 
and the beta promises were still in effect

It's far too late for that. The promises started almost two years 
ago, as an extension of much earlier promises. You shouldn't be the 
one to field this criticism, but I am putting my reputation on the 
line for this in a number of places, and I hate to be pushed around

I can understand your situation and it's an unfortunate thing. The 
only thing I can say that might help, is that there have been suggestions 
about a plan to extend the alpha to the users in this world, so experienced 
REBOLers can take a look at it and "kick the tires", so to speak.


The problem with doing that is that it creates talk. Lots of talk. 
"why is this there? why does this function do that? I don't like 
this!" We have had a TON of discussions over the design of VID3 on 
how to do this and that, and we're not done with that yet. It's very 
time consuming to do that, when one man (Gabriele) wants to sit quietly 
and work out the design on his own until it's ready. It's just faster 
that way in the long run. Every time a new guy comes in, 500 questions 
need to be answered and it's usually the same 500 questions as the 
last new guy. :-)


Ideally, no questions should be asked until after about a week of 
use and start testing it right away. If there is a problem or a bug, 
consult the bug tracker or the documentation database, look at the 
discussions and the design documents and keep out of particularly 
Carl's, Gabriele's and Cyphre's hair until they crawl out from their 
holes on their own.

I'm in a big project myself, and there's no way you can ignore these 
issues. You have to deal with them as best you can. The world isn't 
perfect, and neither will R3 ever be

RT is making it impossible to plan REBOL development. And if you 
can't plan it, you can't use it

You're not amused, because you made a plan around what Carl said 
(and again, I think he really shouldn't have said). I agree it's 
not funny, and it may put your reputation on the line, but use it 
as an experience in when to plan around an alpha product the next 
time, no matter what the manufacturer says.

This is not the point. I deal with shifting schedules every day, 
and if necessary, I produce running estimates as best I can. I just 
want RT to start doing the same

All my scheduling is worthless if it includes an RT component, and 
I will be blamed for false promises made by RT

Since we're still in the alpha state, it'll probably be ignored. 
RT has no time to talk about R3 right now, so as a countermeasure, 
I and a few others do that.

Yes, and as I said, you should not be the one to field this criticism, 
but my intention is that my deep concerns are relayed to RT

I was won over some six years ago. My issue is with planning, and 
not just for myself, but everyone who needs to be able to plan REBOL 
projects

I guess I'm more "fortunate". All my projects are R2 only and there 
is probably 2-3 years of work left if I would have the time and money 
to pursue them all. For me there are many things left to do with 
R2 that will be useful for R3 later, such as native Windows printing.

I can take a more relaxed view and pick whatever I want for my first 
R3 project.

And no graphical interfaces, of course, because that would make you 
use some half cross-platform C/C++ toolkit with huge bindings

wait, 1st august was not "beta", it was "getting the alpha to a wider 
audience". it has been suggested that it would have been bad to do 
so, so in the end it wasn't done. the dates were not unrealisting, 
they were based on the idea of releasing "early". that idea was later 
on opposed and so it wasn't done. also, the august date was based 
on the fact that me and cyphre had to be away from r3 development 
for august and september, and so we thought it was better to release 
rather than delay two months.

It was fine with me if it had been an alpha release, but it's several 
months later and we have nothing

Yeah, I adjusted too, but there is no adjusting to this, because 
there is still nothing and no meaningful date