AltME groups: search

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

No it doesn't because there are some extensions and some minor changes 
desired. Extensions include math for 3D, gui thru Qt, and others.

http://anton.wildit.net.au/rebol/gui/self-hider-btn.r

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 
RAMBO.

- 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 
rendering?

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 !
http://www.rebol.com/r3/docs/gui/guide.html

Just change design... there was button, after btn with different 
design.

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 
under.

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.

I would like to get back to Oldes' quesiton - is unloading extension/module/gui 
or other elements technically impossible?

Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?

Taken from RMAsset Twitter: "We plan to release a new R3-GUI version 
next Friday." Any significant changes about tobe expected, in comparison 
to latest release?

ok, thanks ... Ithought that R3 GUI is suited for that task, but 
that would be probably a preliminary assumption :-)

That time is better invested in allowing people to work on specific 
things, like the automated testing system for the R3 GUI, rather 
than specialize ourselves into a corner this early.

With our R3-GUI test-system available now, we could really need some 
help in creating test-cases. The more the better. We want to build-up 
a huge test-suite for GUI tests that we run on "every commit" to 
keep quality high and identify breaking changes.

The more help to build test-cases and submit them to us, the faster 
we will be in pushing R3-GUI forward.

I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3


Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...

Cyphre - is there any chance Carl is going to be available to do 
some low-level fixes? It kind of crashes very often, but of course, 
with one specific use-case, so "normal GUI usage" (whatever that 
means) could be without any problems ...

great release ;-) thank you. perhaps ask carl to do somethink for 
gui on linux

As for the possible "look & feel" of the GUI, I personally like HTC 
Sense, and Linux Mint - combination of light greay and green. IIRC 
Ashley created some more lightweight look for his GUI too later in 
the process ...


http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23

http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/
http://www.linuxmint.com/screenshots.php

Take it just as a note :-)

So, I see no one is really interested in this R3 GUI stuff... I'm 
wondering a bit but anyway... I think doing public releases might 
not be worth the effort.

Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?

Robert: you are wrong.  As Pekr said many of us are waiting and busy 
with something else. I downloaded all the RMA R3 stuff, tested all 
GUI examples (found some crash problems btw) I really would like 
to help/write a tree style, but I'm not a good Rebol coder I'm afraid.
So please keep up the work.

Robert -- an R3 GUI just isn't one of my priorities just now.


While  there is no likely target date for a beta release of R3, all 
my REBOL development is on R2.


I was happy to help debug R3 alphas while that project had some momentum, 
and I may be again in the future, But right now, I just do not have 
the time for what I have to consider to be speculative projects.

I hope you do get the help and feedback you need.

I will be more actively interested when I start having to write code 
that requires any GUI at all, but what I'm working on right now doesn't 
even need a web interface. All batch and server stuff, and almost 
all the REBOL stuff is R3. This can't last forever, so I will eventually 
need a GUI. I am working on ODBC though.

Well, that contradicts a bit expectation, that RMA's GUI is RT's 
officially endorsed GUI to be bundled with R3. OTOH there are no 
official R3 releases anyway, so ....

I understand that you are focusing resources as much as possible, 
otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept 
changes during last year. Anyone eventually willing to give it a 
try once time permits will think twice, as recent public release 
could be pretty much outdated in few weeks, API wise, etc. There 
should imo be a way, that upon some request or bunch of requests, 
public release is done e.g once in few months?

That are not the same excuses. For core, the excuses are, that Carl 
is not developing. For R3 GUI, the excuses are that we *are* developing.

hmm, that makes R3 GUI a private, mostly a closed effort. The only 
question which remains now is - once R3 development is re-established, 
is R3 GUI becoming part of official distribution, or not? What's 
Carl's take on that? :-)

That would depend if Carl approves it, and AFAIK he has not looked 
at any of the changes yet. However, it won't affect the development 
of the R3 GUI, whether he approves it or not. It will still be made.

ah, so it might be just a separate package,like RebGUI is to VID 
... yes, that's possible too ... we just did not want to have many 
GUIs available. But R3 GUI is in limbo anyway, so ....

So the GUI we can see in screenshots is modified RebGUI? Looks decent 
enough. Similar skin would be nice tohave for R3 too ....

So the GUI we can see in screenshots is modified RebGUI?
 - yes

jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.

Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?

I'll get to that when I start porting View to the Syllable GUI, but 
that project is still a bit in the future

If RM want more people to join the GUI development, they should sync 
the host-kit with Carl.

advanced WRT to the graphics & GUI stuff.

Rebol strings are stored either as ANSI (one byte) or wide char (double 
byte). Of course the rich-text module is currently doing the conversion 
for every rendered ANSI string in realtime. Any sophisticated rich-text 
caching is not yet implemented. (note: this has nothing to do with 
font glyph cache which works well) But even though the cache of large 
text block is missing the performance is still very usable for normal 
GUI cases so the priority to spend time on the line-cache is not 
too high at the moment.

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

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

The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.

but not only GLASS, we have the same wory in any GUI engine

several tens of megabytes to just display a simple GUI pisses me 
off

re DEDUPLICATE ... 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.

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

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 
errors

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

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 
library.

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 
jQueryUI.

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.

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 ...

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 
REBOL2?

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 
line:
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? 
:-)
A: [KWATZ!]