AltME groups: search

kaj ... it's called a temporary measure ...

pending someone eg Oldes, writing a BBS.

While a lot of the criticism here is justified, it's not in this 
case, because it makes perfect sense in the current course of development

Imagine that you know how to drive teams. You are doing it on daily 
basis. Last month, my team finished SAP R3 upgrade - 30 ppl involved. 
Without a glitch. I feel how to move forward, but I also feel being 
unheard. But - I talked to Carl almost on daily basis few months 
ago. The thing is, he agrees to many of my points, it is just we 
somehow can't find the way of how to make things work faster in practice.

You're also not doing social software in a loosely connected community, 
you're doing line-of-business softtware in command-and-control organisation

how does it differ? Innovation lays in the design process. I am not 
saying a word for how guys decide about the design. But then, when 
you are supposed to release, the processes are really identical - 
relese, communication, team management, etc. Or am I really wrong 
here?

I think you'll be able to read that in management books. It's a complex 
matter

What is the problem with such a chat being web public? I am not trying 
to hide anything ...

There are relevant discussions, but that is not the criteria for 
a web public group. You need to consider everything written here 
to be advertising copy, not just arguments amongst ourselves. This 
is not the place for negativity and defeatism.

And yes, I am fully aware of what a web-public forum is.

We have places for these discussions - this is a productive group. 
Never mind, that is the last I'll talk about this subject here. No 
more meta-discussions, back to the real work :)

I am not a physicist, Graham, I am a programmer. There is little 
force and infinite distance involved in my work.

Well said, Brian. There's also a point in our work where it becomes 
too innovative for outsiders to understand

All those mini-polls he hold .. never a decision is made.

He pretends to engage in the community.  But that is all it is .. 
a pretense while he carries on his own agenda.

No, you are practising a different profession

Yes, I am in a profession where we practice transparency, and evidence 
based methods.

The current issue is a forum to make R3 communication more transparent, 
yet you are railing against it

I strongly support a forum... I just don't support a forum which 
doesn't exist in any form.

And what when it does in a few weeks?

The other issue is that at the current stage of development, R3 needs 
apps. We need network apps to test the network infrastructure, GUI 
apps to test that, the list goes on. We don't need these to do a 
development release of R3, but we need to do a development release 
of R3 to get these apps made. You didn't think that Carl was going 
to delay the R3 release to write a forum, did you?

Carl is a guy who won't drink wine unless he grows it himself.  Period.

Graham, Carl is not making wine here, he is making a tool. You need 
to use a tool during the development process in order to be sure 
your tool works.

Then why did we have such a huge discussion about a good one?

So, we see a release today?

Go back to the alpha world and read. Remember that this is a US holiday 
weekend.

I have already had to skip a night of sleep because of the holiday 
overhead, and even then haven't had time to do any REBOL work. You 
are picking the wrong time of year to get impatient.

*smile* no fear here, they would find I'm old and thick skinned, 
a scary combination!

you could be disapointed, they are a little pervert

On issues that need a group, those questions are posted around here 
anyway.

OK, I got a quick job: I need to make a one-month calendar in VID3.4 
complete with day names and dates. I just need the algorithm to generate 
the necessary VID block. It must be coded in R3.

The input is a specific date and the output is the month that date 
sits in. It's OK if we can get more features in, such as week numbers.

ive done a draw based one of  these for R2.. should be simple to 
modify it for R3

yes, a bit like that. I will need it to output a VID3.4 block or 
at least allow me to generate it easily from that function.

should be simple enough - there are only a few text changes in R3 
Draw/AGG

I do not want a DRAW block.

Each valid date is going to be a real clickable button. It's all 
VID.

ill rewrite it as a standalone function that outputs a block with 
the values

Is that the latest?  I thought there was a bunch of port work since 
then?

Why do you think we have been arguing for a newer public release??

Carl has promised a new release in "a few hours" in his latest blog.

I think it is worth remembering that it is an alpha version not a 
beta. It is still likely to change a lot before a beta is released.

Personally, I''m doubtful of the value of a new release at this stage 
other than a tangible display of progress. From all that has been 
told in public, this release will have lots of unfinished code and 
no doubts lots of loose ends.

Peter - half a piece of cake is better than none if you're ( intellectually 
) starving.

Actually, Paul brings up the value of a release at this point: We 
need R3 apps for development to continue at this stage. We are at 
a point where we need people to write stuff that uses what we have 
so far so we can shake out the bugs. To do that, we need to get what 
we have in the hands of more people.

I would if he were talking about DevBase (and did), but I think you 
are overestimating just how long it will take to write. We aren't 
talking about a web forum here, it is clear from the blog that he 
is talking about a R3 GUI client. He can knock that out in no time.

We could write a server using the methods and code of DevBase - it 
wouldn't even have to run on R3 at first.

DevBase uses the database of AltME to store its data, has a working 
R/S interface, runs just fine. Change the data model and you would 
have a forum server. Servers are really very similar.

It doesn't even have to have a web interface at first, and then we 
could write one on Cheyenne.

I think I'd like to a BBS based in the cloud eventually.

Now how to force a client update each time you change some functionality?

My vidwiki client downloaded a new layout for each page ....

You would only need to download a changed version. This looks like 
a good job for a REBOL browser reblet.

OK, if Carl wants to make a release now, then it will be without 
my skin (untested, not merged), so enjoy the colors. :-)

Has he made a general release???

I don't think so, but he did say "a few hours".

iicari, I have a working solution from DideC now.Thanks for helping.

generic calendar module for R2 / R3 use can be found at http://rebol.mustard.co.nz/calendar.r
- this assumes a minimal amount of data necessary to build a monthly 
calendar with optional first-day-of-weeks (rather than REBOLs default 
Monday..)

Now, there is in fact a part of the R3 GUI I want to release for 
testing and that is the color conversion functions.

My webserver is now running again (temporarily on a laptop)

One step forward -- a demo/teaser for the REbtalk forum:
http://www.rebol.net/r3blogs/0157.html

Doesn't look like a way to choose unread threads

Now what is that once again? It once again looks as missorganised 
effort. Give me a break, please. This one is really not going to 
be better than Atlme, far from that. I thought, that when we were 
talking about REBOL forum, we were not talking REBOL based GUI?

Hopefully someone will quickly write a browser client

Well, at least we found a couple of bugs that need to be fixed anyway, 
so the effort wasn't entirely wasted.

Please post the source ... so we can write a Rebol plugin client

Carl makes R3 usable the only way you can... create a test application 
that has enough real world charateristics to be representative of 
real life work being done in R3.

Look closer, you see:
- server
- async web network client 
- GUI
- local and remote data storage

 and so on.

Nothing as goof as a real user

No, but you could come up with any app. This plan to use it as a 
basis for the discussion is pretty much FLAWED. If used, it will 
distract us from altme, as well as it WILL NOT cover what the group 
was asking for - having the web forum.

I don't think this can be used for a web forum (with heavy trafic), 
but it's useful to find out what needs to be changed in the R3 design. 
That's the reason why Carl limit's access to releases. He does not 
want to confuse too many people as the design changes too fast. I 
guess, I'm not in the same group as Henrik.

So, we still lack a forum for the new users

Carl is seeking a solution to HIS communication needs. Not the USERS' 
communication needs. It seems to be a common pattern: That he starts 
developing something himself, because his needs are misunderstood.

Henrik - wake me up, when after 3 months or half a year we found 
ourselves with another unfinished system, semi functional ...

Oldes - OK, you might be correct - for the andvanced users. As a 
"how to" 10KB of code might be too large :-)

If it's a test bed ... then don't call it a developers forum.

We talk too much even without BBS:) I'm rather going into a cave;-)

If it's a developer's forum ... it's grossly underpowered

Henrik - somehow some screenshots show GUI being a bit distracting, 
not nicely placed elements ...

Syntax highlighting must be done with a plugin

I understand - from Carl's posting yesterday, it seemed he was talking 
about releasing a newer alpha in 'a few hours'

working a bit on date styles.

view [year-calendar 2008]

gives: http://rebol.hmkdesign.dk/files/r3/gui/153.png

Looks good Henrik.  I don't care much for the  orange.  Maybe a yellow 
would be nicer.  So square-ish - maybe round the corners on the month 
panes.

Paul, yes, colors are experimental right now and definitely not final. 
rounded corners are a little harder to do.

Pekr, a slider is not used to represent data. It is used to adjust 
data. And it's already used in at least two places.

CharlesW, there are some differences, like unicode, but go ahead 
and get a good feel for it.

One of our .net programmers showed me something kinda cool yesterday. 
They were "child" windows of a main window that would align together 
if you brought one within a certain proximity to the other. From 
that point the top bar from either window moves both. Of course it's 
not as cool as having draggable screens like we did in '86 but...

just one question about R3:

to convert a 32 bits integer to a binary serie i currently use that 
trick:
>>my-int: 150
>>debase/base skip tail to-hex my-int -8 16

it's quite inelegant and memory consuming (especially the to-hex 
function)
we need a more speed and compact function in R3.
I know another one trick using struct! but it's slow too.

To convert binaries to integers we don"t have such problem, cause 
[to integer! my-binary] works well and is short.

I agree that R3 should provide a better way to achieve that.

Btw, you can also use a struct! value to convert integer to binary.

for info, to convert an integer to a binary with struct! , we do.
>>str: make struct! [int [integer!]] [0]
then
>>str/int: 150
>> third s 
== #{XXXXXXXX}
which is the integer in little endian format

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

The style list is only there to describe the styles as they exist 
and are defined in the system: As a single flat list. The 'parent 
value is the only thing to make it into a tree. A tag block would 
help us group it however we want. I don't think there will be problems 
describing the styles in the documentation in a clear fashion.

Not at this time, no. I think that will be left up to a 3rd party 
to do such a thing.

I wish the teasing would stop or at least be backed by a well thought 
out and valid date.

Graham, it's currently useless due to HTTP bugs. So it was a pretty 
good thing to work on.

Oh yeah ... I used a web client!  :)

well, I did express my opinion that we needed a BBS ...

Just two questions - 1) what it the space at the bottom grid? A layout 
bug? Or just wrongly set container size? 2) Will there be anything 
done to font rendering? Some letters look rather blurry. Is it a 
bug, or just we are not still using more advanced font rendering 
techniques? I thought that moving to AGG will solve it for us ...

I will explain the construction in a minute. Need to run an errand...

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.