AltME groups: search

Yeah. We really gave that and every other detail of the behavior 
of FUNCT a great deal of thought. If only we had given that much 
thought to the name: FUNCT is sort of the default name - Carl made 
a blog about it, and then the discussion never went anywhere, so 
we stuck with the initial name because it was better than the other 
suggestions.

I find the typo quality of FUNX to be a downside now. It is harder 
to type FUNCT by accident when trying to type FUNC.

If you're a touch typist, x and c use different fingers ... so it 
doesn't matter if they're adjaxent or not

but it has such a pluralist sound to it :)

x implies a break ... from past behaviours

I am only partially to blame. I think, even then, I expressed concern 
about the beauty of the word funct. That said, I don't think funx, 
funq, or lfunc are any better. I believe a number of people were 
there and really tried to find a good name.

It really is getting a bit late to bring this up now. FUNCT is already 
in R2 as well, and is in most R3 code that has been written so far.

funct: :funx  ;-)


then just do a big search/replace on files with funct in them... 
can be automated in a few lines...

In response to an earlier comment by Maxim, not being a german-speaker 
I am not reminded of body parts. However, FUNCT reminds me of "perfunctory", 
which is an ugly-sounding name in English.

getting a bit late
 != "too late"

Back-porting alpha functionality is always a tough call. I would 
prefer it if the existence of back-ported R3 functionality would 
not harm the flexibility we have while R3 is still in alpha.

Yup, everyone here, right now Max. ;-)  Give me a better option and 
I'm there.

yes in this case, the functionality doesn't change, only a word label, 
its a much less tedious process.

Unfortunately, we don't seem to be able to come up with a better 
name anyway :)

We need that 5-second rule for editing AltME messages. I do that 
a lot myslf.

Another example is renaming SINGLE? to LAST? - a good idea, but likely 
to be done as adding the name LAST?, not removing the name SINGLE?.

and there were a number of reports, including one from Carl, to say 
that 2.7.7 sdk was broken

R3 is alpha .. it seems to me a little odd to expect R2 users to 
have to look at R3 documentation for R2 functionality

It can be fixed, but I don't have the time to work on extra docs 
at the moment. I wrote a lot of documentation in the R2/Forward source, 
and it has the advantage of being tied to the specific version of 
the code that it refers to.

I am talking about a user, one we want, who downloads view 2.7.7 
from RT's website.  He naturally wants to find documentation for 
some of the new functions.  So, it seems that you're suggesting that 
it's okay to make them sign up to devbase just to get the docs

No, I was saying that 2.7.8 would include a DevBase client, but plans 
changed.

On one hand is the fact, that we have lots of code using this.


On the other hand is the fact, that it is a beginner's gotcha being 
incompatible with the help string of the VALUE? function, as well 
as with the behaviour of the interpreter in other, quite similar, 
cases.

The gotcha is not whether a variable is "defined", but whether it 
has been set.

Nevertheless, if we have a comprehensive documentation mentioning 
this, we can easily use either, since for every experienced user 
it is easy to remember that "unused refinement arguments" are set 
implicitly to #[none]

I am strongly in favor of optional function arguments being none 
by default. When combined with type tests that prohibit the none! 
type, it allows you to easily use data flow analysis to handle the 
control flow of the different options. You have to realize that none 
is a non-value too. The main difference between none! and unset! 
is that unset! is usually chosen when a non-value is an error, and 
none! is chosen when it is less likely to be an error. And for function 
arguments, not choosing an option is normal behavior.

Ladislav, I don't have to "remember" that optional arguments are 
#[none] by default: Most of my code absolutely depends on it. Handling 
unset values is a big hassle, on purpose. I don't want to go through 
that hassle for a normal situation, just for exceptional situations. 
We are supposed to use unset! to trigger errors.

when rebol encounters (loads) a word with never encountered before, 
its automatically added to the globals and its is set to unset!  


so just the fact that you've actually put the word in a script, even 
if its never explicitely been explicitely managed by code yet, will 
force the value to be unset!

ex: 
>> ['!!!!!!!!]
>> probe copy/part ( sort first system/words ) 10
[! !!!!!!!! != !== * ** + ++ - --]


so you see, even using it as a lit-word, its already in the system 
words, so asking for an /any, will always return true.

Hi Chris, how a /any refinement to value shall influence the behaviour?

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

Chris, we have another function already: DEFAULT. It converts none 
or unset to a default value. This deals with the most common case 
of what to do when you have uninitialized values. The other cases 
are handled by ASSERT/type or conditional functions, though conditional 
functions won't work without extra help if we make optional function 
args unset by default (the extra help being UNSET?, VALUE? or get-words 
and op tricks, the hassle I was talking about earlier).

I have a host-kit, that allows multline commands.

I am thinking, if it makes sense to extend it to mulitiline strings.
How far is the console mode for R3?

And is going to try a 64 bit build since the Solaris pc provided 
by TomC is 64 bit ( .. umm... aren't all PCs 64 bit ?? )

so Carl is doing a C64 build?

he would have to build a REBOL using BASIC hehehe

whether people are running a 64 bit OS is a different matter

I'm happy to see a Solaris build being attempted.

Looks like if you want a build, you have to supply Carl with the 
hardware

http://www.zdnet.com/blog/btl/android-poised-to-be-no-2-smartphone-os-worldwide/37976?tag=nl.e589


Android jumps from 1.8% market share to 17% ahead of Apple.  Someone 
got a spare Android phone for Carl/?

I have an Android phone (or will once I get the data transfered from 
my old phone). It is not much effort for Carl to make a new r3lib 
build - it's not platform-specific code. Then people with phones 
can decide for themselves whether or not they are important.

Henrik, Android is Linux-based, but Android apps are Java-based. 
So it's a matter of making a host lib that is compatible with their 
native lib API.

I'm reading that Android doesn't actually use a JVM, but a Dalvik 
VM. Interesting.

See http://www.tbray.org/ongoing/When/201x/2010/07/28/Ruby-and-Python-on-Android
for a good high-level discussion of scripting language support on 
Android.

I'll buy Carl the hardware, if he'll make a port to Android.  iPhone, 
Blackberry, Windows Phone, too.

so you'll buy a broken phone for Carl?

Apple has recently relaxed the restrictions on interpreters, on a 
case-by-case basis. Most of REBOL would probably need to be excluded 
from iPhone builds (networking support, for instance). And it would 
be difficult to write cross-platform apps without them being rejected. 
But you could make a iPhone-specific version of R3, and it might 
be approved. Host kit apps only though, no scripts.

Here's an interesting subject: What value does R3 have as a library 
in another app with its own GUI and networking?

would you be able to run a web server on the phone?

Likely not a web server, especially if it has any dynamic code.

Ah, the REBOL data model and the processing of its syntax. Yes, that 
would be a value.

I've often thought (and may even have suggested, though I'm normally 
so shy :-), that promoting REBOL as a data format would be a good 
thing.

it would be very nice if we had a C library able to load rebol data 
into a simple C struct format.

I don't have developer skills to offer much help, but I'd offer a 
bounty if anyone's interested...

hehe nick has a pet slave  ;-)

I still have that phone, but I just carry a Windows 7 netbook everywhere 
I go, and a tiny clamshell phone - that setup is much more powerful 
and practical.

I know, Nick. I was the one who asked for that build in the first 
place. Unfortunately, that is why it doesn't support onscreen keyboards 
well: The original build was for a netbook.

I would love to be able to render postscript in a view face/gob

Pekr: technical possibility? yes. native code? yes. use android api? 
see the link I posted above; SL4A could be a start.

the thing is, how we can get REBOL on such platforms. Compile REBOL 
app into something else or having REBOL in JAVA e.g., sucks imo - 
lot's of work. I can see the only way to be a native port, but then 
- connecting to APIs might be technically difficult.

The only platform that I know of that would prohibit native REBOL 
is Win7 (don't know about BB). However, some platforms (especially 
iPhone) won't allow the full REBOL experience including the GUI. 
Most GUI layouts would need rethinking for the small screen anyways, 
and using native tookkits matters much more on phones (memory, consistency), 
so that's not as big a deal. It does mean that we need to pay more 
attention to embedded profiles of the host kit.

Native code is not allowed on WP7 - you must write for Silverlight 
or XBL (both .NET). This isn't a license restriction though, it's 
technological. .NET code becomes native before it is executed though, 
and GNU has a C compiler for .NET, so it's not so bad. WP7 has an 
app store but they have seen the fallout from Apple's restrictions 
so their store is much less restrictive.

The pricniple behind VID - simple dialected GUI layouts - is REBOL's 
strength. The actual implementation would not be as much of a strength 
on a memory-constrained system with a native GUI toolkit and strict 
UI design rules. However, you can make a simple cross-platform layout 
dialect for phone UIs that tells the native toolkit what to do, and 
then make platform-specific implementations for the various native 
toolkits. Dialecting is REBOL's greatest strength.

a lot of VID's dialect can be used to describe the layout even on 
native GUI toolkits.

Exactly! You would need to redo your layout anyways for the small 
screen (unless the layout dialect is *really* properly strict about 
not allowing sizes, offsets and real colors in its layouts, the way 
the R3 GUI is supposed to be), but the layout dialect itself could 
be very compatible and you could reuse a lot of code.

1. host-kit release: It's still Carl's job and responsebility to 
release official host-kits. We (RM-Asset team) won't do this.


2. host-kit support: Yes, we spend time to work on the host-kit source-code. 
And yes, we concentrate on these things we need for our upcoming 
projects. All this will flow into the host-kit and be available to 
you. And, I'm sponsoring this effort. Our goal is to help to get 
the host-kit to a stable state ASAP.

3. rebol3 gui: We are working on getting VID to a state that it can 
be used for app development. For this we did a complete new resizing 
system, changed the styles etc. This is not yet ready for release 
because to much flux in the design and code. We will release it either 
in form of the official VID via Carl or as our own VID fork, if Carl 
decides that the official VID should look differently.

No decision taken yet and I hope that we don't need to fork VID.

4. styles: We need a bunch of styles for our apps. We will create 
them all if necessary because we need a stable style set that is 
enterprise & bullet proof. Most likely I can't make use of hobby-styles 
in commercial apps. There is a bunch of other requirements to full-fill.


And yes, we will release these too. But, we set the priorities, we 
fix the bugs we think are critical, we work on the features we need. 
I listen to you, we think about it, but decisions are made on a pure: 
Urgent & necessary for business context.

5. Extensions: We will create a bunch of R3 extensions we need. Some 
will be quite special, some more generic. For these we use a mix 
from open-source libs, commercial frameworks etc. Which bings up 
the nice licensing issue stuff if things should be released.


As I hate licensing issues at all, and it's a big time killer, my 
rule is quite simple: RM Asset will have all necessary licenses we 
need, if I can release stuff we think about it. If not, than not. 
Sorry. I don't have time to get all this sorted out to provide a 
perfect-R3-framework to everyone.

6. collaboration: We are absolutly open to it. We support the community 
with everything that's possible. But, our main focus will not be 
to become the community runners. We have our own priorities and we 
stick to them. Next, we focus on getting things done.


If the community talks about a specific topic, no problem, if people 
code something, no problem. If we need something different, we will 
do it with or without the community.

7. financing / sponsoring: To be able to do it, one needs to have 
something to spend. And yes, making money form projects is the goal 
for us. This gives the freedom to spend money on non-project relasted 
R3 stuff we do. This is the sponsoring and investment we do into 
R3. As long as I can finance the sponsoring parts I will do it.


Again, I follow the golen rule: The one owning the gold makes the 
rules.


Meaning, I set the priorities to the things we need or which complete 
some aspects etc. But it won't be a community driven process.

android is linux based ... i have one on my acer laptop that's a 
short linux ...

Thanks Robert. I like the fact that a goal is the use of R3 to build 
commercial apps. That means things like accelerator keys and other 
features have a better chance of being seen as important.

I have a XML file and want to handle it by tags like a nested block. 
Are there are any tricks? Or do I need to use PARSE / FIND etc.

I would like to extract a set of elements like: Everything between 
<TAG> ... </TAG>

What I mean is, do you want to convert the XML to a block and then 
access it like this?

  data/tag

Just use PARSE then. I have a solution for the block approach, but 
just use PARSE when I need to extract data in more stream-oriented 
ways.

Give me a minute though, I might have something...

This was used with small pieces of XML, rather than entire documents, 
but might be a starting point for you.


xml-get-field: func [input name /local xml-field= data other-name] 
[
	xml-field=: compose/deep [ 
		some [

   (rejoin ["<" name ">"]) copy data to (rejoin ["</" name ">"]) to 
   end
			| skip ;(to paren! [prin '.])
		]
	]
	either parse input xml-field= [data] [none]
]

I've used Gavin's XML-object.r in a couple of projects. Not tried 
it under R3 though:
   http://www.rebol.org/view-script.r?script=xml-object.r

; Another flavour of Rebol XML:
do http://www.ross-gill.com/r/r3xml.r
doc: load-xml/dom location
foreach tag doc/get-by-tag <a> [
	probe tag/flatten
	probe tag/text
	probe tag/get #href
]

I proposed a change to how path notation works on TAG! to return 
name value blocks for attributes.

ie. anyone with a rank of 50 or higher

Added it as a codec so you can access it:

>> ml: decode 'markup read http://www.rebol.com
>> foreach tag ml [probe tag]
<!doctype html>
^/
<html>
<head>
^/
<meta name="generator" content="REBOL WIP Wiki"/>
^/
<meta name="date" content="10-Aug-2010/12:18:33-7:00"/>
^/
<meta name="rebol-version" content="2.100.97.4.2"/>
^/

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>

It's a simple way to traverse over tags.

Don't know. DECODE doesn't look like a port to me. Maybe on the lower 
level this is done via a port like mechanism.

Yes, that's the missing part I made a proposal for to Carl.

r3xml is an R3 port of AltXML, a Rebolised version of XML DOM: http://bit.ly/XMLandREBOL

2.100.99.3.1  the use of  function  at  with negative index simply 
returns the whole series - which reminds me to ask why   at   with 
index 0 doe not return the series atfter the last item i.e. place 
you at the end of the series?  The docs for  at   specify behavior 
for a negative index      "Using a negative index N, you can go N 
values backwards in a series:"   PS   I have relocated to Fredericton, 
NB, Canada.  Lovely, green and interesting.

I don't know how much of a pain this would be, but I would like to 
consider overloading of words such as empty?


It would like to see if there were an 'empty? actor if noun is an 
object ...and use that.

Graham: if you really have to write empty? vidfield/text thousands 
of times, it would probably be worth adding it as a keyboard shortcut 
in your text editor.

Peter .. vidfield was meant to mean any object which has a field 
attribute

that is a public user/pass combination

there are two login forms. after the browser popup, a web form appears 
here asking you to log in with your R3 chat credentials

I am probably a bot, as it looks

Am just getting started with Rebol; haven't spent some development 
time with TCL. Would like some direction on where to start: V2 or 
V3 (with the understanding that V3 has yet to achieve commerical 
level release).


Simply looking for the best way to get my head around it without 
the need to unlearn a whole bunch.

Is there a way to open the Word Browser without the viewtop?

IMO focus should be now on bug-fixing and closing open tickets. There 
is still some smaller things to do on the AGG side. And than get 
a V1.0 out of the door. Because I don't see any cause to not make 
an offical V1 release of R3 anymore. It's mostly ready for prime 
time.

until R3 supports threads, I don't think we should consider it beta. 
 this is too big a hole in 2010 for it to be sidestepped and ignored.

adding threads *could* have far reaching implications in many little 
areas of R3.  I woudn't want to start a big project and then realize 
that its broken after a thread enabled release.

with async callbacks, we can even implement device supporting libs 
now. so the callback is a BIG step forward.


congrats to Carl to pulling this one off without disrupting anything 
in the extension/host-kit API.

I just wonder, why Carl regards it being a preliminary release, and 
that the concept has yet to be proven - is there any other way than 
using events? :-)