AltME groups: search

a friend of mine is asking whether it will compile under Ultrix

There's a patch for the generated M2 template in that Builder definition, 
but it's only needed for Syllable. It works with Linux, but isn't 
needed there

Is there a test suite of scripts that you run to confirm Rebol and 
orca produce the same final results (both logic, numeric, and visual)?

ie. 

 do [ 1.2.3 + 5.0] ;; note the later number is a decimal! not a tuple.

I downloaded the windows binary and brought up a console only.

It looks a long way off. Easy to make something that looks a bit 
like REBOL. Hard to make something that is REBOL.

This seems to be a response to a perception that there are some problems 
with Rebol that can not wait for RT to fix in RT's timeframe.

I know it's cool to work on rebcode etc.. but for those developing 
basic applications, there are some show stoppers that just bring 
things to a halt.

and that #$!%!! detect face bug is a real pain. Gab raised its priority 
to critical, but I'm really prevented from making much progress until 
it's fixed *and* in the SDK. 
 /endquote

carl, maybe people need to see a task list? one where they could 
easily say "hey, I can do that, I'm skilled in this area"

A way for visible way for developers to influence RT's currrent focus 
would be really good.

When I hear things coming to a "halt" due to REBOL bugs, I look at 
things like AltME and QTask that are running on really old version 
of REBOL that had a lot more bugs... and they seem to work pretty 
well.

AltMe does crash once in a while but it actually crashes less frequently 
than any other IM I use and it provides a whole lot more in functionality.

I only see it once a month or so.

R is research. Rebcode is an example. We do those to push a bit, 
because we know they require a lot of thought, plus user testing 
and feedback.

B is bug fixing. That's a special mode.

Altme is buggy.

  Graham...........on that I have to call BS!  AltME has less bugs 
  in it that almost any multifunctional application I know of.  It 
  should get a bloody award.

So, it is not perfect and this is not a contest about who has less 
bugs, but how can the supporting technology response quickly to address 
the problems that an end-user application has.

Reichart, this was in response to Carl saying effectively that Altme 
was bug free .. saying that some developers were able to work past 
perceived bugs.  This was not a criticism of Altme per se.. but to 
refute that assertion.

Any one wishing to monitor the advancement of orca on a daily basis 
can suscribe to this RSS feed.

http://trac.geekisp.com/orca/timeline?milestone=on&ticket=on&changeset=on&wiki=on&max=50&daysback=90&format=rss

Strange it works here with my RSS reader (not a browser based one). 
You can find a direct link at the bottom of this page http://trac.geekisp.com/orca/timeline

I don't think I will be working on mezz for a while there is a lot 
to do in Orca.

BTW, Everybody is invited to contribute to Orca's development effort. 
Initially if you have a patch email it to me, and we will reviewed. 
Once the core team are comfortable with the quality of the contributions 
the author will be given repository access.

Finished support of tuples for all operator actions.

XOR OR and AND have slightly different behavior than REBOL when arguments 
are a tuple and a number. ie:

O> 1.2.1 xor 2015.345 ;== 222.221.222
R> 1.2.1 xor 2015.345 ;== 255.255.255


Which behaviour the community prefers? I believe orca's implementation 
is more correct, but we can change it.

Does anyone use such feature bitwise ops between tuples and numbers?

It's great to find out about this project. It would help a lot if 
any of you know the developers of the two previous related projects 
(sievertsen.de - freebell.sf.net) and (softinnov.org - dockimbel 
- r#) and get them to contribute to Orca. It looks like orca is very 
close to getting some momentum !

Carl has a point though.  Orca needs to be BETTER than Rebol, or 
at least as good.

Jaime thanks for asking...But there's not a simple answer.

The point I am about to make applies to any proposed variant in ORCA 
vs REBOL.


The problem with changing fundamental behaviour is that it makes 
it hard to port applications: think a few years ahead when ORCA is 
a fully operational REBOL clone, and (as an example) (unlike REBOL) 
runs on PDAs. I'd like to use ORCA so I can run an application in 
a PDA; but I want to use REBOL for all my other platforms. And I 
don't want to have to pick through code and/or support two source 
versions because of avoidable differences in behaviour.


On the other hand, an ORCA-only application might benefit from the 
"more correct" implementations of basic operations.


One possible way to square that circle is to have a set compatibility 
flag:
    system/orca/xor: false  ;; gets me REBOL XOR behaviour

I just have to wrap that in an 'attempt and I can keep a common source 
that will run under either.


[I appreciate that there may be performance issues doing it that 
way -- may be better to have compatibly options specified in an orca.r 
file that is only processed at start-up....I'll leave the details 
to the people doing the design]

Sunanda. I fully agree, and the reason for my asking. I will wait 
for a bit more input before deciding which route. An solution is 
to create rebol-compat mezz. That way you get the best of both worlds.

With only a penalty in performace for backward compatibility, specially 
when it is about correctness.

I hope there is a lot of cross-pollination.

... well, but I am not a designer, nor I am in situaion having lots 
of REBOL apps to redesign ...

<<A solution is to create rebol-compat mezz>>

I've suggested to RT a couple of times that REBOL needs a compatibility 
mode for behaviour changes  between its versions.

That would give Carl the freedom to change things (like reverse vs 
head reverse) while guaranteeing (more-or-less) that applications 
continue to work unchanged on newer versions of REBOL.

Perhaps the ORCA crew and RT could exchange ideas on such a mode 
so we don't end up with incompatible compatibility modes.

Sunanda, <<A solution is to create rebol-compat mezz>> we have decided 
to provide a compiler flag for backwards compatibility; so you just 
need to recompile to obtain previous behaviour.  We may investigate 
mode switching in the future, but we don't want to carry the bloat.

So, Orca can now has a full parse implementation?

I'll have to try to carve out a bunch of time. I've never compiled 
anything on my Z. Sounds like fun though.

Compiling in the sharp zaurus requires an GNU environment, and probably 
a boots trap m2->Makefile.

license question: would there be problems in running BSD or proprietary 
licensed scripts on a GPL based Orca?

A GPL word processor does not write GPL documents

If a GPL word processor printed out the source of the GPL word processor 
?

There's a separate group for discussing the niceties of licensing 
:)

Orca is on the DVD of the current issue 82 of Linux Format magazine 
- more or less. A binary copy is included in the Syllable 0.6.1 that's 
on it

Since there are currently no binary releases for Orca, compiling 
it is somewhat difficult, and I do it regularly anyway for Syllable 
and Linux, I decided to provide one. Orca is included in Syllable, 
and a binary package for Linux is now here:

Well, not my package, unless you install a Linux emulator

Ok, I've left, so that should free a spot.

I still have to give a name and password

Just a nickname

Did you use the link above? I just tested in a pristine browser and 
it only asked me for a nickname.

Better register as a full user.

We wanted a more interactive channel. I have a public IRC channel 
on freenode setup too.

Are you able perhaps to provide a machine for use as a server ? We 
could install something ourselves.

it would be nice if AltME could carry a gateway to an HTML chat for 
a single group

It's probably just as much burden to install altme as it is to log 
in to a website.

We could write the code to reflect the altme chat to a website if 
necessary. It's accepting chat from the web as well which starts 
to make it a bit of a larger task.

But I don't think we need a web gateway do we ?

how does rebol.net get its chat lists? is it a separate script that 
digs through the archives stored on one machine?

I think so. I think Reichart set up a custom script just for Rebol3 
world, and hasn't generalised it into a release version of AltME 
yet.

I'm not sure that debian linux is enough, even if it's a big part 
of them

But maybe it will be a couple of years before a developer comes along 
who is not covered by these platforms.

We have a plain IRC channel ready in freenode. Join the Orca channel.

I'll check out the IRC. We can't expand with a four person limit. 
That's crazy.

I would like to steer orca back towards full compatibility (or close) 
to rebol (core 2.6.x  at least).  Currently orca has diverged somewhat. 
(It does have a compatibility flag, but I don't know how far ranging 
it is.)  Does anyone here have any objections to this course of action 
?

nope. Personally I'd prefer a straight Rebol clone probably with 
added bits.

Jamie, Henrik, if there are bad ops or stupid parts in R2, be sure 
to mention them to those creating R3. Either RT will fix the problems 
or explain why they aren't problems. In the long run, it would be 
a good thing if Orca and REBOL were to be more compatible.

I just don't see the use of being compatible. I actually see it like 
a wast of time. 100% compatibility means importing the gotchas, the 
bugs, and the problems in certain designs. Like the port system.

Yet my goal is to abandon Rebol, not have a backup tool. If I build 
a tool I want to use it for my own benefit. Not become tied to following 
an external spec.

Again. I taking this as a hobby. I will still pitch in if others 
want to make Orca into a real clone. Any how I still learn something 
which is my goal.

Maybe. But thats a lot of work. When one could just doing something 
new and cool.

It depends of what is the objective. If the objective is to support 
an older code base then compatibility is a must.

Jaime, this is a deep difference and we need to settle it.  I agree 
it's more exciting being able to experiment and choose new behaviours 
for a language, but I think it's more responsible to support the 
language that we have. We can't just keep jumping from language to 
language. The real hard work is to perfect an existing language.

Will you agree to a real clone ? Then we can move forward without 
forking.

Sometimes you have to take a big step back to consider the issues.

Rebol exists, and works for most people given what they are trying 
to do.

The cool thing about an open source version is that when someone 
comes across a problem they can fix just that problem (thus offering 
it back to the community).  In theory this could be done in such 
a way that that section of Rebol runs on Orca (for example), while 
the rest runs on standard Rebol.


O Rebol can "choose" to fix these issues (since they would be self 
documenting).
O Orca can branch from the Rebol sheme.
O New features can come into existence by committee.
O Open source die-hards will step up to Rebol

O Some companies are anti-open-source.  Rebol then becomes their 
savior, and thus becomes closed version of itself.

This actually seems like a win/win to me.

yes, but maybe it would be vital, if FINALLY RT would explain a bit 
a plan. We saw documents about more of community involvement, also 
about how some parts will be opened. But what we never saw were details 
to such a plan. R3 is coming. My understanding is, that is should 
make situation much better, as what does not belong to kernel, should 
be kicked off from Rebol, into module/plug-in, call it whatever ...

Pekr, AltME doesn't cover all linux platforms yet, so that would 
limit the audience a little bit.

R2 is not dead. I am still using it ! It will be very useful for 
some time to come. It will take a long while for R3 to stabilise 
to the point at which R2 is now.

I expected exactly such a reaction, just waited for it to pop up 
:-) I am talking about focus/orientation .... all the potential of 
RT goes to R3. Judge for yourself, if Orca should, and for how long, 
to focus on R2, respectively to add new features, before we know, 
what RT gives us ...

well, it's not like R2 will become utterly 100% useless, is it? There's 
a ton of value in R2 still.

Sounds good, but how about this case: 
	foreach v [1 2 3] [ ]
in rebol currently returns unset!
in orca returns 'v

It can be argued that this is a small useful improvement that doesn't 
interfere with rebol code. I would prefer, however, to change it 
back to the rebol way because there may be times (possibly very rare) 
when some code relies on this behaviour and is broken by the change. 
How do you see this case ?

Yep. There is already a compat flag.

Kaj, and anyone else new to the discussion, I'm trying to get a consensus 
on the future direction of Orca. It is a divergence from Rebol, as 
stated on these pages:
http://trac.geekisp.com/orca/wiki/OrcaProject
http://trac.geekisp.com/orca/wiki/OrcaBehavior

But I would like to steer it back to Rebol. Actually, since Orca 
needs a name change, it's probably better to fork and do a big name 
change, probably to something like OpenRebol or ORebol. What do people 
think about that ?

Still, in Ruby it would return 3. :-) Which I use a lot

At first start on Win XP. I got a warning from the firewall.
After I checked with process explorer

Does R3 (or R2) also cause your firewall to give a warning?

I suggest expanding the make routine! spec to the following:

	routine-name: make routine! [
		"routine description"
		[special attributes]
		library
		"routine-name"
		[
			argument1 [arg1-world-type] arg1-type
			"argument description"
			argument2 [arg2-world-type] arg2-type
			"argument description"
			...
		]
		return-type return-world-type
	]


, where the following fields are optional: Routine description (string!), 
Special attributes (block!), Argument name (word!) and Argument description 
(string!).


Then good documentation can be made with HELP. Argument names are 
not really needed, as routines are compiled code in a library, but 
names can make the docs easier to understand.

Actually I had it like that at first, but I found the reverse order 
to be easier to understand. (It can be just me.) Because then I read 
a simple routine spec as: routine is in library, named "routine-name", 
take argument with world type arg1-world-type, which is converted 
to arg1-type, returns return-type, which is converted to return-world-type. 
The sequence makes good sense to me.

And [arg1-world-type] is in a block, so I can allow more than one 
type in the future.

I do not remember clear, if all versions of R2 or R3 gave warnings 
at first start, but now they are in my exception list. And at least 
once I got suspicious of R2 too, as it initialized / loaded libraries 
not needed.


The curious thing is, that now I do not get a warning at start of 
world again. And I did not allow it, but choosed "ask again".

Is there a way to figure out, what directory a command launches from, 
which will work across platforms?

Yes and no. There are platform-specific ways. This gist of it:

- Linux: readlink("/proc/self/exe")
- OSX: _NSGetExecutablePath
- Win32: GetModuleFileNameW

(We recently discussed this issue in relation to R3 as well.)

To check for which platform, World is running on, system/version/platform 
can today be:

	"Mac OS X"
	"Linux"
	"Win32"


Is that suitable? Are there better suggestions? Is there a standard 
for this?

Maybe I should call it "Linux32" and hold the 64-bit versions clean... 
So there can be a future "Linux", which is 64-bit.

I think for scripts we want a small helper library with various predicate 
functions.

REBOL use this: version.revision.update.platform.variation
See: http://www.rebol.com/docs/version-numbers.html
I could add a system/version/variation at some point.

A helper lib sounds like a good idea, then I could make changes later.

Then you might consider having the platform be a word of just the 
platform name, but also include a platform-plus-hardware word in 
a different field. This would make specialty code that switches on 
the OS (for API stuff) or full platform (for selecting native code) 
much easier to write.

I see your point. It's not easy to find a good way, that is sure 
to cover all future possibilities.

Maybe platform could be, 'macosx, 'linux and 'windows and variation 
something like 'intel-32, 'intel-64, etc. Or do we need a third variable?

One of the common situations where you need to do platform-specific 
stuff is in loading prebuilt libraries, and those depend on the platform 
and processor variant. That means that selecting one requires selecting 
both, or all 3 if you have a seperate bits field. One SWITCH is better 
than 3.

SWITCH is a mezzaning in World (see cortex.w) and just uses FIND.

- The new routine spec is implemented.
- Compiling blocks should be fixed. I also added a test for this.

- system/version changed. Should be able to handle all future platforms/bits/processors/makers/etc.

- Added libs/version.w to help with deciding platform and version.
- Other fixes.

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]