AltME groups: search

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

I have big long cutting knifes in my kitchen ! Who wants one ? It 
can help you finding who is right or wrong in a more funny (gore) 
manner ;-)

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

Carl: "most of the scheme structure has been solid and unchanged 
for more than a year. The main disruption was Unicode, but that's 
been done for a while too. I think we should pick a few very simple 
protocols, maybe one like Finger, and j ust show how they are done... 
as an example."

No Didec to work as you wish, rebdev client as to be rewritten completly, 
it's not a minor change.

Steeve, there isn't much code in the RebDev client, by design it 
wouldn't be much work to completely rewrite it. Everything at that 
scale is a minor change - that is the nature of the scale.

Steeve: there are opinions, and there are facts. It is a fact that 
you can't be faster / more efficient than the OS. It is your opinion 
that you want to be less efficient.

Yes it's cool, it's something i try to do with Virtual blocks (blocks 
which are synchronised with files). it"s a tiny scheme (script size 
less than 5 kb).
It doesn't allow sorted blocks currently but it could be.

We have not the same defintion of efficience. 

The efficience of an application is a grid which contains several 
criteria. 

When you choose an implementation. All these criteria can't  have 
the best value together

Hiding this complexity by saying i'm efficient, and you are not, 
without saying you choose to lower some criteria, only reveals one 
thing, you're pretentious.

Can anyone give a range of time where rebol 3 will be released? If 
not, can I just be notified by email when it is?? I'm sick of logging 
onto rebol.com and checking the blogs. I've been doing this for at 
least a year and I'm sick of it.

sick of it

  seems a bit extreme.... there are other good reasons to check in 
  here.


But that aside, how about simply setting up an RSS feded off Carl's 
blog, and set it to pull once a month or so?

Nicolas - your message is a little bit hars, so here's answer you 
deserve - don't come back until 2010 :-)

I personally take visiting blogs as a good sport, and am always glad 
that there is another blog posted, another piece of info available. 
You now have "what's next" kind of summary on rebol.com available, 
so how can you be sick of something, which CLEARLY states facts?

Nicolas, the best you can do is just wait a few months and see what 
happens.

I know of a killer app for REBOLers. A few lines really: one BIG 
RED BUTTON that launches on startup of your PC and turns GREEN the 
day R3 is released.

I think I know what is wrong: Carl is thinking near the speed of 
light, thus time slows down for him, so while it takes two months 
to get the next R3 release to the public, it only takes a day for 
him. :-)

Steeve: again, that is your opinion here. The OS will always be more 
efficient at handling syncronization between memory and file, be 
it a swap file, or using mmap() and so on. So if your reason is "saving 
memory", then you are wrong here, because any real OS will do better 
than you. Then of course there's Windows, but that's a different 
story...

Okay, I get abuse, a good answer - "check again in 2 months", and 
banter. Pekr, "soon enough"? - what does that mean? and when I get 
it, it'll be an alpha? Now, I don't want to agravate anyone. But 
I'm tired of having absolutely no idea when rebol 3 will be out, 
and out of beta. An acceptable answer to me would be something like 
6 months give or take a year. If that kind of assurance can't be 
given then I'd like a bit of honesty. It's nice to be able to plan 
things.

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

Nicolas, you could do what I did: Instead of waiting, help. If you 
passively wait you get back exactly what you put into it. All of 
that eagerness was wasted energy that could have been applied to 
helping get R3 out, or writing documentation, or even discussing 
semantics here. Complaints are a waste of time that could instead 
have been spent volunteering.

If you were so eager to use R3, why don't I know what you want to 
use R3 *for*? We could have added that use case to those being considered 
in the design. Even that could have helped a little - not to get 
R3 out the door faster, but to make it better when it does.

It is easier to add the VCS parts of DevBase to RebDev chat and rename 
RebDev to DevBase (the current plan) than it would be to get DevBase 
into a usable state. I know - I am the lead programmer of DevBase.


What we really need to do to is get the project to the point where 
we can release it to the developing public without it turning into 
a disaster and the project dying. We needed a way to enable and organize 
development discussions, completely integrated with DevBase, to help 
people cooperate instead of hinder the project. We have that now.


I agree that the CLI client for RebDev sucks, and that we need a 
GUI client. We don't need it *now* though: RebDev already works better 
than AltME for our purposes, and we can do the GUI after the public 
release. The messages we write now will still be there later, ready 
to be read in the GUI client if you want to wait for that.


We absolutely do *not* want chat in CureCode - comments in CureCode 
are *documentation*, not chat.


Because we went the route we did R3 is nearly ready for release to 
the developing public (as an alpha). If we had done as you suggested 
we would not be so close to release. Keep in mind that what you are 
suggesting we do is what we were doing before, and it failed badly. 
That is why we are doing what we are doing now, which is succeeding.

We are at a point in the development of R3 where we need the help 
of the rest of the REBOL community. This is why I think complaints 
from people impatient for R3's release are silly: Noone needs this 
release more that the people who are already working on R3. We will 
be releasing soon because we need to asap. The only delays to release 
now are practical ones, and not many, and we are focusing exclusively 
on fixing those problems right now (sorry Steeve, we'll get to the 
concerns you have been expressing recently, after release).

You might have noticed the creation of the GUI world, even though 
we already had an alpha world, and the tiny number of people who 
were invited to the GUI world, especially at first. For that matter 
remember the creation of the alpha world in the first place. These 
events happened because AltME failed as a medium for development 
discussions.


AltME lacks the moderation and organization facilities of RebDev. 
If there are more than several people in a world communications break 
down. One troll and the process grinds to a halt. If AltME was good 
enough, R3 development discussions would be happening *here*, instead 
of talk about religion and politics.

I would like to type in the wiki search field a command such as "what" 
and get extensive help on that function.  That possible?

Or put a new search field in just for commands.

The wiki should be updated with a newer version of wikimedia - we 
didn't write it.

We have a similar function in R3 for errors already: WHY?

I didn't here until the development team pretty much moved to other 
mediums and this then became a playground.

How do I define a utype?

A1: You wait until we have that feature. A2: Not yet, not ever in 
a compatible way.

perhaps we should prevent people to not enter in some headings because 
it must remain a lot of blood on the walls when I fought with Brian

Yeah was looking at the chat but it is a bit cumbersome.  The web 
version looks more useful for reading.

We need a new R3 dictionary with samples like the one we had back 
on IOS.

What's wrong with following? (except the fact that we can't user 
/ as a start of path datatype, which complicates the request)

>> parse [/ /R3/GUI] [word! path!]
== false
>> parse [/ /R3/GUI] [word! path!]

No GUI yet, as I'm still busy with something else. I need to do a 
serious code audit before it's included. Many things are still up 
in the air.

Pekr definately a bug it looks like as any-type! doesn't work either:

>> parse [/ /R3/Blah/] [any-type! path!]
== false

You can submit it yourself. It was matched as a word!, so I can see 
no problem with that :-)

matched as a word?

How are you seeing it as a match for word?

Paul, it returns false, because they are two separate refinements.

>> parse [/b/a] [2 any-type!]
== true

only if the leading char is not a /.

whoops, only if the leading char IS a /.

i just tried to download the new r3alpha.

my NOD32-antivirus guard identified it as a variant of Win32/Adware.Antivirus2008

>> ? evoke
USAGE:
        EVOKE chant

DESCRIPTION:
        Special guru meditations. (Not for beginners.)
        EVOKE is a native value.

ARGUMENTS:

        chant -- Single or block of words ('? to list) (word! block! integer!)

perhaps a single guaranteed way to provoke crashes to see how they 
are handled on different platforms.

I like that. This could eb a cult hit. Somebody quits your app, evoke 
crash. Wish for evoke 'reboot-os!!!

That doesn't need a rebol [] header, and is probably a good candidate 
for your %user.r.

hi,  i am very to play with R3 but  i don't find a way to do a round 
of a amount or decimal with a scale example i would like to 1/3 in 
a interest amount with 8 decimal . how a can do this with R3  ?  
the simplest way or the better way ?  thank of you all

It's a known bug

sorry, I misread. (I read too fast these days) There is indeed a 
bug which causes certain roundings to be incorrect with the ROUND 
function, but it should not occur with the above example.

Is there a reason why help displays infos about ports not in the 
same way as for objects ?
There seems just two minor changes needed
 
in dump-obj
>>    obj [object! port!]
instead of     
 <<   obj [object!]

and in help

>>        print either any [object? value  port? value] [print "" 
dump-obj value] [mold :value]
instead of 

<<       print either object? value [print "" dump-obj value] [mold 
:value]

Like Oldes, I have a do-clip func in %user.r, along with a cc func 
to copy, vv to paste, and cdr to "change-dir to-rebol-file". Handy 
stuff.

Ah...I didn't know you could load the gui.  Thanks.  And the button 
action isn't in a block because you're executing the block with 'do. 
 I guess it's not that big of a deal, but it's annoying to me that 
view[button "test" print "test"] is also valid

the demos will of course have to be made correctly. gui-demo.r is 
only a launcher.

Another crash in the demo program: on the "Read HTTP" screen, "Run 
script from net" fails with a "File not found" error.

Thanks Sunanda! :-)   I had been trying both with and without 'layout 
with the same result.  Looks like I skipped a line in the documentation 
somewhere.  I will go try it now!

Is there  a list of all the widgets available for R3 ?

Graham, I think you can get a list from within the R3 alpha as discussed 
here: http://www.rebol.net/wiki/GUI_Example_-_View_all_styles

So only a very few styles so far then

In fact the list may be so large, we have to group them. Carl and 
I have discussed a tagging system, that lets you know which styles 
are meant to be used for you (end-users) or which ones are meant 
to be used for skinners to create new styles.

http://rebol.hmkdesign.dk/files/r3/docs/style-list.html
http://rebol.hmkdesign.dk/files/r3/docs/style-tree.html


Not a complete list. Some will disappear again, but it's what I have 
here.

I'm really surprised by the small number of people reporting bugsabout 
the R3 Alpha. Where is the feedback from all those people pressing 
for a public alpha?

.... hopefully it is an interim state, a preparation for GUI client. 
New chat system starts to turn being interesting - threaded discussions, 
user ranking, tagging, searches, secure, movement of msgs/headings 
(reorganisation), recently files sharing is being worked on. The 
long term plan is to replace Altme ... with better Altme :-)

Peter, we also have to remember that most immediate bugs are probably 
found and that the database has already been up for 18 months, so 
maybe bug reports will go up eventually, but hopefully not. :-) I 
would rather see a way to give positive feedback. That is probably 
a better indicator for the number of active users of R3.

PeterWood: Hi. As a new user I would like to report any problem, 
but for the moment I just saw one bug that as already been reported.

yes, but with MS console crap, it is really a pain to use the chat, 
as you can't increase number of columns. I hope some primitive GUI 
comes soon ...

kib2, if there were a way to give positive feedback about things 
you really like in R3, would you do it?

Pekr, I have only very limited experience with IOS from about 5 years 
ago, but I liked the aspect of miniapps with it. Perhaps this is 
why Carl is so fixated on mini-apps or reblets. I certainly hope 
we'll be able to build a new IOS for R3.

As far as I've seen, there's currently no way to run a GUI script 
with R3 alpha. Am I wrong ?

kib2: about the GUI system, it is very far from done, so don't be 
too disappointed. Also we have a private bug list for the GUI alone.

Henrik: I can easily understand that, but you've done a wonderful 
job, really.

Primary issues with the GUI:


- Layout resizing can result in too much horizontal stretching and 
too little vertical stretching.
- Style list is very incomplete.
- Keyboard navigation is very sparse.
- No rich text editing.
- Skin will become more esthetically pleasing later.

- Some nasty bugs in the low level graphics engine, not yet solved.

What is not likely to change:


- The design of the system feels very solid. Every time a change 
or addition is made, it's 5-10 lines of code.
- Style creation process, so feel free to make your own styles.

What is likely to change:


- The layout engine gets new features now and then to simplify the 
dialect.
- Popups, dialogs.

Pekr, I want to do a code audit, but I'm thinking now whether I should 
do that in the open to speed things up a little. I'm not sure.

I hope that the mezzanines are pulled from the main distribution 
and made as a separate module.  I don't care for the mezz stacking 
and it only contributed to bloating.  I would rather build my own 
mezzanines for purposes or be able to choose from a module containing 
predefined ones.

Brian, I'm critical of how Carl and the dev team are handling things 
at this point.  At least from my perspective this project is being 
managed poorly.  The rollout to the new developers to test and provide 
feedback is not being equipped with a "hit the ground running" gameplan. 
 In order for anyone to know what a function is they must source 
it and they have no access to examples.  Sure we can eventually figure 
out how the code works but that comes at a cost to each of the new 
contributors in time and energy when this could have been facilitated 
by others of the reb dev team.  Regarding, the mezz functions, I'm 
glad to here they won't be built inside the main bin and includes 
as modules.  That is good news.  Regarding, chat, Carl needs to run, 
not walk, away from using console for chat.  The more that console 
chat is used the more concerned I get a feeling that R3 is a mirror 
of that same level of usability which is not a good impresion.

I hope so Brian,  I don't want to be discouraging to others about 
R3 based on these observations because I know that objectively its 
a critical analysis in the midst of its evolution which is never 
a guage of what will be the final product.

I found two bugs, one issue and a potential language enhancement, 
all about the map! type, all during the writing of one function (REWORD) 
that many people may not use - it might be one of those functions 
put in a module that isn't loaded by default. Still, time well spent 
if it makes map! better for all of us.

but I still take decision to make chat in CLI first and not focus 
on GUI etc too quickly very highly. Because having a good core on 
which gui (or many gui-s) and all things are built seems 100x more 
important than having *something to show* .. a nice gui on a patched 
core... I appreciate the priorities and focus, and this tells me 
that I can rely on R3 being good.

You caught onto a good principle there, Janko. We are really focused 
on the core now with chat. Admittedly, it is the core of chat rather 
than the core of R3 but the principle is the same: We need the communications 
infrastructure there so we can communicate now, and that will make 
it easier to make it pretty later :)

It´s written in a simple style, yet I had to make a series of tweaks

I encountered several bugs and I had to write a series of wrappers 
for READ and WRITE to arrive at functions that act compatible between 
R2 and R3

Eventually, when I built a number of OpenOffice XML files that take 
three seconds on R2, it took twenty seconds

In R2, dir? tests the file node to see if it´s a directory or just 
a file. However, in R3, dir? works like file? and only tests whether 
the value ends with a #¨ /¨

Are you a brain doctor?

.... it is a mezzanine, you need to port throw-on-error to be compatible 
...

but it does test correctly for existing directories. it's a little 
ambiguous, but testing also for EXISTS? could help

it seems it will do this:

- it tests FALSE for an existing file
- it tests FALSE for an existing file and adding a /

- it tests TRUE for a non-existing dir with an ending / <-- bogus?
- it tests TRUE for an existing dir with an ending /
- it tests TRUE for an existing dir without an ending /

the bogus one would be eliminated with an EXISTS?. still it's a simpler 
way to test for non-existing dirs, say in preferences files for paths 
and some basic syntax checking.

so, I think there should be a function for that, but having it in 
DIR? may be ambiguous.

I'm adding a ticket, just to be sure.

So, we need a function that both checks that file exists, and it's 
a directory?

so... there should not be a need to port the R2 one, just ask like 
this:

all [
	exists? file
	dir? file
]

That shouldn't hurt the R2 version.

probably related to ports being different in R3. I'll make a ticket.

The exists? check is insufficient, because it will return true if 
a regular file exists but the value is written in dir form with a 
trailing /

It´s a regular file

I've tried without a root dir now and I get the same result as I 
pasted above.

True, but Wine is not a very stable platform. It might be a Wine 
problem.

Wine is past 1.0 since a year or so

a little over dramatic ...