• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 2801 end: 2867]

world-name: r3wp

Group: Parse ... Discussion of PARSE dialect [web-public]
Yes... Ladislav reminds me some basic math! God, I felt so stupid 
about this associativity bug! 

The reason why I developped parse-expression.r is because I need 
it to build an companion app for one of the best math book: Calculus 
3d edition from Smith & Minton! For now, I have developped a rebol 
library to transform any vid face into a function plotter, and parse-expression.r 
allows me to use human readable expression in the gui instead of 
guru rebol code :)
Group: #Boron ... Open Source REBOL Clone [web-public]
No it doesn't because there are some extensions and some minor changes 
desired. Extensions include math for 3D, gui thru Qt, and others.
i think all you should need to do for that on windows is fire up 
cmake gui and select the boron directory
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public]
No, and work on it has barely started. We will have a public development 
release of the new R3 GUI first.
BrianH: how can you write your own client to R3 Chat? Can you actually 
use its command set? I mean - create a gui, and "send" command like 
"n", "lm", etc. to console in the background?
OK, now that we have 2.7.7 released (even though there is more work 
to do, i.e. platforms and the SDK), it is time to look ahead to 2.7.8 
- which is scheduled for release in one month on February 1. The 
primary goal of this release is to migrate to REBOL's new development 
infrastructure. This means:

- Migrating the RAMBO database to a new CureCode project and retiring 

- Using Carl's generation code for the manual to regenerate the R2 
manual, so we can start to get to work updating it.

- Porting the chat client to R2 using the new functions and building 
a CHAT function into R2 similar to the R3 version.

The R2 chat client might be limited to the ASCII character set, though 
support for the Latin-1 character set might be possible. Still text 
mode for now, though if anyone wants to write a GUI client (Henrik?) 
we can put it on the official RT reb site accessible from the View 
desktop. The server is accessed through a simple RPC protocol and 
is designed to be easily scriptable.

It turns out that Carl already rewrote the installer for 2.7.something, 
but it was turned off because of a couple minor bugs that we were 
able to fix in 2.7.7. With any luck, only minor fixes to the registry 
usage will be needed and we'll be good to go.

As for the rest, it's up to you. Graham seems to have a good tweak 
to the http protocol, and others may want to contribute their fixes.
Steeve, how's the R2 chat gui going?
Actually, the GUI can get started before the API is - the semantic 
model of DevBase is pretty well set already.
Agree. The project can be separated in two task.
- Working on a gui

- Refine the current chat app to extract a bunch of usefull functions 
(app API).

Idealy it should be 2 separated apps, so that we could write different 
GUIs for the same app.
The same will likely be the case for future releases too, at least 
in the areas where R2 and R3 are comparable (not GUI, database, ports, 
/Library, etc.). Well see though.
it's used for commit/rollback objects in my GUI
it's used for commit/rollback objects in my GUI
The new. You've been in GUI doc hell, and not noticed it.
The gui is not important
is there the possibility of getting R3 AGG Richtext dialect backported 
to R2 - it would make a huge difference for gui development and text 
What would you call a REBOL binary that comes with GUI capabilities 
on Windows?
On Linux, there's two versions of REBOL immediately available: /Core 
and /View. /Core is a REBOL binary w/o GUI capabilities, /View is 
a REBOL binary with GUI capabilities (and beyond that, it comes bundled 
with a self-installer and the Viewtop app).
Since a stable GUI based release of R3 is far off still, I agree 
that R2 should be updated
And hope the design of View will be refreshed as what has been bone 
by Carl in march !
Cool design !
Just change design... there was button, after btn with different 

We need a refresh of the design of R2, to make it younger... The 
screenshoots of R3 GUI by Carl are cool.
A good look will be possible for R3 to do. It's simply a waste of 
time for R2 and you can't produce anything that resembles Aqua anyway 
in R2. In R3 that is possible. But focusing on look alone is a big 
mistake, which too many developers using GUI systems are suffering 
Not yet, as R3 is a bit of a moving target. Most R2 code will run 
in R3 if it doesn't use any GUI or port code. Part of the migration 
strategy has been the R2/Forward stuff, which allows you to write 
code in a more R3-like way in R2. Plus, we are backporting some of 
the native enhancements that are additive rather than changing, like 
SELECT on objects.
Group: ReBorCon 2011 ... REBOL & Boron Conference [web-public]
just an embeddable core into other environments, or will some GUI 
be possible later too? Also - will concepts like 'parse be available? 
networking (and other) ports?
@Pekr parse network ports, yes. GUI later
Hi guys, I've spent a great time at the conference (and after also) 
with the people present. A big thank to Bas and Kaj for organizing 
this event, it was really nice meeting you all (pity that Robert 
couldn't been there to present RMA's GUI). The Boron's OpenGL demo 
was impressive (Star Trek's Enterprise ship), I'm looking forward 
to see the dialect used for that.

 I'm currently preparing the slides I've presented to put them online. 
 Should be done in the next hour.
BrianH - from end user's perspective, you might not be right - missing 
pop, smtp, ftp, sqlite, mysql, postgress in official distro, just 
to name the few, GUI's not useable yet too, hence ppl keep tied to 
R2 ....
I suppose we could have. There's an assumption in there that it is 
about REBOL development, so Carl must be there. But when Robert offered 
R3 GUI talks, it was about REBOL development
Group: Core ... Discuss core issues [web-public]
Consistency between OS platforms. On platforms other than Windows, 
/Core doesn't need X or any other kind of GUI, and so doesn't require 
the libraries (good for headless servers). When there is no GUI, 
there is no clipboard. The Windows version of R2 just inherited this.
SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.
The former situation (the information about the "culprit file" is 
stored in the error) looks as follows, currently:

performing localization
** User Error: INCLUDE
** Near: do last-error: make error! spec

The trouble is, that the present error-forming code does not show 
all the attributes. If you examine the error on your own, you get:

print mold disarm last-error

make object! [
    code: 802
    type: 'user
    id: 'message
    arg1: 'syntax
    arg2: %gui/include.r
    arg3: [
        id: missing
        arg1: "end-of-block"
        arg2: "["
        arg3: none
        near: "(line 949) ]"
    near: [do last-error: make error! spec]
    where: none

, which shows all the data as "stored" in the error, which is referred 
(for convenience) by the LAST-ERROR variable
Group: !REBOL3 Proposals ... For discussion of feature proposals [web-public]
it's not just GUI code that would benefit, DB code often needs to 
apply this on the result set. 

buffer: unique buffer" is a common idiom, which can be problematic 
with very large datasets" - that is exactly where I was trying to 
explain it was just a superstition - buffer: unique buffer is as 
memory hungry as you can get any Deduplicate is just pretentding 
it does not happen, when, in fact, that is not true
Group: Red ... Red language group [web-public]
If View sources are available under BSD, I will be glad to have it 
as one of the possible libraries for making GUI apps.
The audience... sigh. They were friends, but there was only one programmer, 
formerly C++ and now Python. I asked him beforehand how long he thought 
his equivalent Python program would be. He didn't seem to be much 
into GUI programming, but he maintained it would be only ten lines...
The GUI constructors are written to be flexible, so rather than crash, 
they work as best as they can while issuing warnings when they encounter 
The reason I chose GTK is that it's written in C, which makes it 
natural to bind to Red/System. Almost all other open source GUI toolkits, 
including Qt, are written in C++, which is much more problematic 
to bind
So I chose GTK to support as the "native" GUI for Linux and BSD. 
It can also run on several other platforms until we have native support 
for those
That's a pity, because Jaromil requested slider and file selector 
widgets from me. When he has those, he can start using Red for a 
GUI for his Tomb security tool
Being able to make GUI apps on Android requires at least two more 
- have Red/System linker be able to generate shared libraries

- build a generic Java bridge to be able to instanciate java objects, 
invoke methods and receive events
Are "native" Android GUI apps posible? I mean - e.g. GTK based ones. 
Or if View would be ported - it uses own methods to draw stuff, no? 
Although windowing is native, so probably some link to JAVA still 
required. Pity MeeGo did not become popular instead (pure Linux based 
Does the NDK provide access to all the GUI framework?
I do think that in practice, REBOL has usually been a Windows-only 
technology. Especially because its biggest draw is the easy GUI, 
and this is not (R3) or not well (R2) supported on anything but Windows. 
And because it still pretends to be cross-platform, there are even 
serious deployment problems on Windows
The default target on Windows for Red/System apps is MSDOS (console 
mode). When Red will be there, I guess we'll switch the default target 
to Windows (GUI mode).
People immediately came up with the standard question of "Why yet 
another language?", but when I showed the GUI dialect and compared 
it to conventional development, they recognised that something special 
was offered
But it only runs in command-line mode for now, a Java bridge will 
be required to produce GUI apps on Android.
is it possible to get guide for new bees and info on the IDE.... 
from reading it looks like the GUI will be gtk+
Sorry, no IDE available yet. For the GUI, gtk+ support is quite advanced, 
I might use it for the IDE if I run out of time to implement my own 
And if there's a plan for a GUI
I would hope Red adopts one of the existing GUI solutions.
Newbies info: well, from all the presentations slides, you can see 
that Red is meant to be a "general purpose" programming language, 
so making any list of possible applications would be restrictive 
and probably also premature as Red is not yet implemented.

GUI is certainly a feature to have, but I wouldn't make it part of 
the "core" language, rather handle it as library. One remark about 
future Red GUI support, there will probably be several GUI frameworks 
available (we already have GTK+, I'll add a native one, and someone 
could contribute a View clone), I'll try to put a common VID-like 
dialect on top of them, so we can quickly switch from one to another 
with minimal changes needed.
You can also add HTML5 to the list of future GUI frameworks. ;-)
Also, there are several good high-level widget sets on top of HTML5 
that we could use as back-ends for client-side GUI, like Extjs and 
REBOL-like languages are especially good at code generation, so we'll 
use that ability to abstract as many GUI API and frameworks as possible.
Evgeniy Philippov:
Dockimbel: Re: native GUI - will this be X gui or you plan to write 
a native code for every card driver? ;)
BTW, we could also make the View face/gobs hierarchy a common layer 
on top of all those GUI frameworks, if the overhead is not too high.
Evgeniy: you're sounding like you're volunteering for writing the 
X back-end, thanks, that would be nice! ;-))

The native GUI I have in mind for Red is a SWT-like one, but as light 
as possible (SWT has some really heavy widgets). So, yes back-ends 
for Win32, X, Cocoa and Android are planned. The Cocoa and Android 
back-ends would need obj-c and java bridges.
Since we either do a Lua GUI or perhaps can adopt Red ;-) and do 
the GUI there, I think there will be some choices.
Oh, I forgot to mention Flash also as a possible back-end for GUI, 
if Oldes makes the AVM2 port for Red/System some day. ;-)
I would personally want a View clone with a GUI dialect on top. The 
R3 GUI could be appropriate.
Makes sense to re-use as much of the R3 GUi work as possible
So, Red/GUI is complete and awaiting RED
( though I have this nagging suspicion a dialected GUI trades ease 
of use for sophistication and flexibility )
That will be the real challenge, define a GUI dialect good enough 
to cover the common parts and backend-specific extensions for been 
able to fully use backend-specific features.
Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though
Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though
But some functions  work although defined the same way. There might 
be some more functionality happenening under the hood, and who knows, 
that the code tries to return. OTOH the specs are clear enough - 
if it is supposed to return integer, then integer is simply an integer. 
And dialog windows work - I e.g. got dialoc saying "LED screen not 
found", so the GUI is inside the dlls ...
Group: World ... For discussion of World language [web-public]
Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.

Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.

Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.

Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.

Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.

Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.

Q: Are there datatype and function comparisons between World and 

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
decimal!: :real!
, so REBOL scripts using that will run.

Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.

Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
2801 / 286712345...25262728[29]