AltME groups: search

For these who don't want to read and just download it now... http://www.rebol.net/wiki/R3_Releases

For those of you who don't want to read the release notes and warnings, 
don't bother downloading R3 - it's too different for you :)

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

I'm not versed in the Wiki and in fact I don't like the design myself 
but that is just me.

If you don't read the docs and chat, it doesn't take long to notice 
the WHY? function :)

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

I don't know if the IOS developer server is still up as I haven't 
been on it in years.  But  if it is maybe someone can grab the dictionary 
script from there unless someone else already has it and then we 
can just populate it with documentations and examples.  If someone 
has it they can send it to me.

Nice trick that works in R2 and R3: If you put
    rebol []

before the code you would otherwise paste in the console and include 
that header in the copy, you can
    do clipboard://
to do the code :)

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

Here's my %user.r function:

explore: func [

    "Open directory in the file manager (shell shortcut function)."

    'path [file! word! path! string! unset!] "Accepts %file, :variables, 
    and just words (as dirs)"
] [
    path: case [
        unset? :path [to-local-file what-dir]
        file? path [to-local-file path]
        string? path [path]
        true [to-local-file to-file path]
    ]

    call ajoin [{"} get-env "SystemRoot" {\explorer.exe" } mold path]
]

CALL is less capable (and less buggy) in R3, but CASE is more capable 
:)

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

'do and 'print are valid actions usable in the dialect.

check the content of the guie/actions object to know all the authorized 
actions.
>> first guie/actions

== [self do browse run launch view alert close halt quit set of attach 
submit reset clear focus scroll print dump moved signal]

eh? you launch demo, go few items down in text-list, select text-view, 
and it crashes to console with:

Cannot parse the GUI dialect at: 'set ts read-string %main.r

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!

Luis, I would not expect year and half demo to work, it's still alpha 
and some things are changing

...year and half OLD...

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.

Anyone able to send messages to rebdev? They do not appear in my 
chat and I have duplicates of headings and messages in some places.

delete rebdev related files in your directory and let it resync?

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.

Pekr, about the other worlds being dead: It seems it's going according 
to Carls plan with killing both worlds in favor of Rebdev, so I kinda 
hope it stays that way. I hate jumping back and forth between chat 
systems.

Henrik - new RebDev chat (and more) systems gets under your skin. 
I start to like the system, otoh, as usual, when thinking in more 
abstract way, I think that we are creating certain app type, but 
so far I can't see it being base of something like Atlissimo. Altme 
+, maybe, but not something which was supposed to replace Altme + 
IOS. It is interesting, how we don't push the coolest system we had 
(IOS) further. 


With IOS, you had secure communication framework, along with app 
handlers, which allowed you to deploy anything. In IOS, something 
like RebDev (or its particular features), would be just - one of 
many possible apps, complete with separated usergroup areas, if we 
wished for ....

kib2: that fooled me first, but type "load-gui" and you have the 
GUI system available to you.

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 hate the new chat system.  I understand it completely but 
find it cumbersome to use and difficult in reading.

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.

Paul, that is the plan. The old monolithic REBOL will go away once 
the module system is up and running. There are already functions 
flagged for moving into non-default modules - especially ones that 
have limited use or too much overhead.


But remember that we add these mezzanines so that we can use them, 
and many are just cleaned-up versions of code that is used in the 
GUI, the other mezzanines, the intrinsics, etc. We are trying to 
keep things as efficient as possible so that the code that is loaded 
by default is minimal. Still, you will have to realize that REBOL 
is partly written in REBOL so you can't get rid of everything.

Some of the new code is there to get rid of common bugs in code that 
all REBOL programmers write, or to make efficient versions of functions 
that are done over and over again, poorly. Other functions are being 
written to figure out where R3 needs some improvement, though they 
will be usefl on their own (like REWORD).

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.

The advantage to the current chat is the messages in it, not the 
UI. Those messages are still going to be there when the GUI client 
is in use, and we needed something in place to get the information 
out there and managed (AltMe wasn't good enough at management). However, 
you have once again figred ot the plan: Carl intends to run, not 
walk, away from using console for chat.

As for the project management, with the limited number of developers 
the self-organizing model has been working so far. We will manage 
to organize more developers when we get more developers. Which the 
release has not brought us yet - only users and testers (both appreciated).

We need help. There is only so much Carl and Henrik can do, and I 
am busy with work right now so I can do even less. I have seen people 
putting in bug tickets for changes to the wiki - when they could 
easily make these changes themselves. It's frustrating.

You need to ignore the UI of chat for now, because the important 
problem being worked on now is getting the source file database integrated 
so developers can see that source you were requesting. Then we will 
have more developers (in theory) and we can get the GUI working well 
enough to write the GUI chat client you also requested. Which shouldn't 
be that hard - all of the tough stuff is either handled by the chat 
infrastructure (which is mostly there now) or the GUI infrastructure.

I sort of agree, but most of the core bugs were discovered and fixed 
during the course of writing the "addons" like the GUI or non-core 
mezzanine functions. Most of the core language enhancements came 
from the GUI work too. I expect the work on higher-level port schemes 
will help debug the low-level port code. You need to write the high-level 
stuff to help refine the low-level stuff.

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.

most of the core bugs were discovered and fixed during the course 
of writing the 

addons" like the GUI or non-core mezzanine functions" yes, I fully 
agree with this and understand that higher level code tests and helps 
design (reiterate) the low level that it's build upon...

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

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

Please post any bugs you find in CureCode. There are some changes 
in the way READ and WRITE work though.

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 #¨ /¨

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, we need a function that both checks that file exists, and it's 
a directory?

Even info?/type is incompatible. ´directory for R2 and ´dir for R3

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

Wine is beta software still .... and AFAIK, the decimal bug is still 
present wrt R2.

Look, I´m not interested in a philosophical discussion. We waited 
three years to test R3 and now we´re asked to report bugs ASAP. What´s 
the point of fighting it?

Kaj - you are just angry, that is all. Gee, so ppl complain, that 
there is no thing to test, and once there is an ALPHA, we hear things 
like "Isn't the point of REBOL to be usable?". And I thought, that 
you are SW developer. Beucase as such, how can you post any such 
sentence to Alpha SW?

Besides that - who said, that bugs are not being fixed? Just go to 
release page and see what bugs were fixed for what particular release. 
We are finally getting there, but not there. Post your finding to 
CureCode, mark it, and let's see how critical it is or if it could 
be fixed with some higher priority. What is point here?

uh, on Vista and R2 I get:

>> dir? %work
== true
>> dir? %work/
== true
>> file? %work
== true
>> file? %work/
== true


Is that correct? :-) There is a work directory on my system, so how 
is that "file? %work/ reports true?

Kaj, I understand it's very frustrating only to be able to do limited 
testing. Being on OSX, I have to waste a lot of resources running 
WinXP in VMWare to test R3. I think it's a good idea to keep some 
talks going with the Wine people to make sure and verify that it's 
a Wine bug rather than an R3 bug. This is in order to keep Wine out 
of Carl's hair, so to speak, so he can continue development of R3 
as rapidly as possible. I deeply respect the daunting task it is 
to emulate the Windows API and I would not like to be in their shoes.

Switching from AltME to RebDev chat has been very hard for me and 
since I am not a core developer I will be in read only mode until 
the GUI version will be released.

However I am not negative about how things are going. We finally 
have a pubblic alpha. an upgrade mechanism, an internal chat system. 
GUI is going to be developed and also documentation reviewed.

Yes Paul I know but it is not complete and Henrik will be back to 
work on it in march.

I suppose both Carl and Henrik ar working on it while Cyphre will 
be back soon to fix some lower level issues.

However we are in the middle of a big change. Once the new messaging 
system and the GUI will be complete the whole speed of REBOL3 will 
shift up again.

I think Carl is very excited about things right now and motivated 
towards getting R3 fixed, stable, enhanced, and released.

Expect a 2 months where everyone involved will work in the cavern 
with Carl and then we will finally have something to start with seriously.

March is fine for me.  About that time I really expect my project 
to be in a mature state via 2.7.6 and can then hopefully begin porting 
at that time.

By now, we could only try to test REBOL3 and report bugs in CureCode. 
It is still a big thing.

For discussion with the development team we need to use the chat 
system as everything else (AltME) seems abandoned.

My project still have everything they need in REBOL2. SQLLite, REBGUI 
and REBOL Itself.
When things will be mature I'll start to port my projects to R3.

Kaj, please report bugs in CureCode. And here if you like, but the 
important place to report them is in CureCode. If you have problems 
making an account on CureCode say so here or in the !CureCode group. 
Please mention that you are running on WINE in the bug, in case your 
bug is WINE-specific. We have no problems with supporting REBOL properly 
on WINE, but at least I can't test it since I am running Windows.

It is easy to report bugs in CureCode, and they get reviewed, tested, 
discussed and eventually fixed. It is much easier to report bugs 
in CureCode than it is to do so here. Please don't complain about 
the need to report bugs - that is what alpha means.

However, native support for R3 on Linux and other WINE platforms 
will continue to be a higher priority than WINE support.

An include function is really unlikely because of binding issues, 
unless that function only returns a module reference and doesn't 
rebind the calling context with its exports. Binding order matters 
in REBOL.

It would probably be good to have FILEIZE, EXISTS-FILE? and EXISTS-DIR? 
functions in R3, with compatible backports to R2.

Done. Here is the R3 and R2 FILEIZE:

fileize: func [
	{Returns a copy of the path turned into a non-directory.}
	path [file! string! url!]
][
	path: copy path
	if #"/" = last path [clear back tail path]
	path
]

Here is the R3 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	'dir = select attempt [query target] 'type
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	'file = select attempt [query target] 'type
]

Here is the R2 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	found? all [
		target: attempt [info? target]
		'directory = get in target 'type
	]
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	found? all [
		target: attempt [info? target]
		'file = get in target 'type
	]
]

Brian, what is the replacement for get-modes in R3?  I'm want to 
see if I can now set creation and modification dates on directories 
yet.  (see if it is now fixed in R3).  I had to scrap a project before 
because of this.

GET-MODES and SET-MODES aren't in R3 yet.

I have just taken a look at the DEMO and it is really amazing. Things 
are done in few lines of code. I feel the power.

I start to lose control where to post what. How do I:

- diplay latest # of messages content? We have L #, but not LM #
-  how do I display particular message, and all its replies?

Chat system feels good. But if we do add concepts like reply to particular 
message, and system is no more flat, we are not able to easily handle 
it without GUI anymore. Some commands are changed in quick pace, 
some changes don't make sense to me.

As long as the (hopefully useful) messages are being generated, and 
the source files come, chat is doing its job. We can pretty later.

Pekr: "why do we need special exists functions"


Those functions tell us whether the file exists *and* is of the ttype 
we need it to be. Files and directories are used differently. You 
use those functions to make sure that things are what you need them 
to be, so your code will be safer (or at least not crash).


Pekr: "Gee, I hate all those read-* - they are proof there is something 
wrong"


You are correct, that is exactly why the READ-* functions are there. 
They are temporary, until we get the Unicode conversions model finalized. 
Good catch.

BrianH: I always apreciate your good work and the work of the whole 
team.

BrianH: You could look at how Factor did "modules" they call it vocabularies 
(and "functions" are words).. I am saying because you said "..... 
Binding order matters in REBOL."

That is the same in Factor, position matters, and the way they did 
is that it adds value as are able to use short general words because 
position defines from which vocab it will be called -- so you avoid 
need to define long words >>addTwoVectors<< .. and you also avoud 
>> module.word 12 + module2.word2 "asd"<<

this is fictional factor example.. not real code and modules:

because + is defined in math plus will use it's + to add two numbers 
and because we put USE: vectors the + in vec-plus will add 2 vectors 
... this is in the same vocab / source code file.. I think they also 
have UNUSE now but I am not sure

( they have USING: for "including" multiple vocabs at once and USE: 
for one)

I am sort of factor traitor :( ... I was doing a very important project 
for me in it and told everyone that I am doing it etc... got relatively 
far, but then by "accident" discovered that there are many practical 
reasons to switch that project to Rebol, so I abandoned factor :/

it's a forth + lisp + haskell sort of language .. it's stack and 
image based

The particular binding order effect that matters in REBOL is that 
"outer" and "inner" scopes are faked with the binding order. Any 
attempts to revise the "inherited" contexts that the code is supposed 
to have, after the code has started running, is unpredictable at 
best and crashworthy at worst - a bad idea in any case. This means 
that if you want to import words from other modules into your code, 
you should do it *before* your code starts running. This means import 
headers, not import funcctions.

kib2 : nothing was really missing in factor ... I live from my coding 
so I have to choose the tools where I think I will fasters with least 
problems and best solve what I need... this was a web-app that needed 
to run on desktop to (so all apache+ XX + mysql) fell of and it gave 
me a reason to make it with factor.

>>>basically I tried cheyenne and rebol for web-apps just by accident 
... one saturday I was ready to work on that project in factor whole 
day and then some hard bug in factor server prevented me from working, 
so because I was in a working mode I started playing with doing some 
other simple idea in ruby on rails (I haven't tried it yet before 
- I don't like frameworks in general) .. after I hit some magic of 
RoR I stopped and then tried cheyenne RSP .. and I made a basis of 
a working app in that afternoon ..  when I tested and saw it also 
performs I was hooked..<<<

in short: Factor is very interesting language but I was amazed at 
how productive I was with rebol + rsp, I need PDF: factor has some 
deprecated bindings to c lib for generating pdf-s, rebol has a dialect 
for that, I need to run in on a desktop standalone: factor can run 
standalone but is more heavyweight, cheyenne server starts and shows 
icon in tray "before I even click it" , I need a tray icon too for 
my app, I found example of it already and it works, in factor something 
like this doesn't exist yet ..

and bottom line is the language , rebol nicely scales al the vay 
from newbie (imagine VB coder) up to advanced user with introspection 
code is data and all , factor is a little more scarry to start with

Janko: the pdf and postscript dialects in Rebol have impressed me 
a lot. Maybe it's possible to build something like LaTeX in Rebol.

( + if I will need gui for desktop server, rebol has lighweight software 
rendered gui, factor also has a gui but on windows it's opengl based 
which is not really practical for a gui.. even casual games on windows 
try to use DX7 renderer for maximum compatibitily and avoid opengl 
beacause of driver issues)

google talk video from slava pestov is very interesting and shows 
you factor in an hour

Kib2, the model is too weird for most people to make work well, and 
the benefits don't outweigh the weirdness (unlike Erlang).

(just btw.. factor is compiled, slava also posted a lot of info about 
how he compiles and optimizes the code etc ..  this is his talk I 
mentioned: http://www.youtube.com/watch?v=f_0QlhYlS8g)

BrianH: there're not weird; people have to think differently from 
what they know (C,Python,Lisp, Haskell,etc.), and I can see some 
benefits : shorter code, CLOS system (in Factor).

People *don't* have to think differently, and most *can't*. This 
also applies to REBOL, I'm afraid :(

BrianH: in this case, don't call them programmers. A programmer is 
curious, and likes to think differently by nature!

Talk to professional Java or Oracle developers and then see if you 
can claim programmers are curious :(