AltME groups: search

Added a widgets overview to the examples

I'm about to define names for them. :-) They were the most practical 
way to construct a dialect that results in proper settings for filling 
or fixating a box cell

Ok, I see now what they are used for. :-) Are the extra brackets 
around some button titles a special convention you're using?

Normally a button needs more than one parameter, so it would always 
have brackets. But here they're only used as examples, so they only 
have a display text and the brackets can be left out

I left them in for a while to make the separation with the optionally 
following layout parameters clearer, but in the latest version I 
reconsidered

RFC3629 has a (non-normative) ABNF, if I remember correctly.

It would still be a good idea to review the Unicode standard to determine 
which of the characters should be treated as spaces, but that would 
still be a problem for R3 because all of the delimiters it currently 
supports are one byte in UTF-8 for efficiency. If other delimiters 
are supported, R3's parser will be much slower.

After having a quick glance at it, at least for utf8 it's quite basic 
and does not take any of the above overlong combinations into account.

The policy on overlong combinations was set by R3, where there isn't 
as much need to flag them. Overlong combinations are a problem in 
UTF-8 for code that works on the binary encoding directly, instead 
of translating to Unicode first. The only function in R3 that operates 
that way is TRANSCODE, so as long as it doesn't choke on overlong 
combinations there is no problem with them being allowed. It might 
be good to add a /strict option to INVALID-UTF? though to make it 
check for them.

Kaj, I love what you are doing. Just curious if you looked at QT, 
it seems to be avail on more platforms - phone wise- which is a major 
plus...
Is it more difficult to impliment?

I never liked either GTK or Qt. The reason I'm binding one anyway 
is that we want native platform user interfaces for Red. Linux and 
BSD don't have a native interface, but if you have to appoint one, 
you have to appoint two: GTK and Qt

Basically, to bind a C++ library, you have to write two bindings: 
one from C++ to C, and then one from C to your target language. This 
is because only C++ knows what C++ objects mean, and C++ claims that 
its object classes are a program's interface

So you can write a binding from Red/System to a C library purely 
in Red/System, while a C++ binding would also require writing an 
extra bridge in C++. Even after this initial hurdle, apart from the 
maintenance, a remaining problem would be that the C++ bridge needs 
a traditional development environment, so the wonderful abitlity 
of Red to crosscompile to anything would be negated for a large part. 
Basically the same problem that REBOL 3 extensions have

For generic libraries, binding tools exist, such as SWIG and SIP. 
Unfortunately, they don't solve the problem but only assist a little, 
and the result is very bloated

Since a few years, Qt and KDE use a new tool: Smoke. It's more automated, 
so it looks like it can generate a C interface without writing C++ 
yourself. However, the cross-compilation problem still exists. Because 
the tool is so generic, the bindings it generates are also quite 
bloated and probably otherwise inefficient. In any case, it's just 
the first step for a Red binding, because I put abstraction layers 
over my bindings that are much more REBOL like

I'm not planning to fragment the effort by doing a Qt binding as 
well, but I did evaluate it, and the decision could change if I would 
be funded for it

:-) Fortunately, you can build an entire economy on it, because every 
solution creates a new problem...

Added a logic! element to the dialect for GTK windows to support 
their ability to be non-resizable

Any chance of doing a youtube video on a demo?

That would be a nice opportunity for someone to contribute :-)

It discusses 0MQ and shows SDL and GTK, but it's a primitive Hello 
World example when the GTK binding was only a week old, and callbacks 
in Red weren't fixed yet

BTW, do you plan to make a small documentation on the GTK+ binding 
API and/or a dedicated web page?

Part 8 has a discussion of the PeterPaint SDL example on Syllable 
Desktop, but the video is very bad during the demo:

If someone following Red progress would have time to write a small 
doc on the GTK+ binding API, I think that would really help.

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

Implemented INFO style, as a non-editable GTK line entry widget

I understand the frustration...If it could be added in 2-3 days, 
I would add it now, but a complete support would require much more 
time. I will try next week to make a more accurate evaluation of 
all the additions and changes required in Red/System compiler for 
supporting float numbers.

And that can't be done by linking to a math library?

Ah... I thought he was making a statement :)

Anyone have experience using Vincent Ecuyer's "rewbzip.r" from the 
script library? 

I'm having trouble unzipping a very large db file (150+ megs). It 
works for smaller zips...anyone know if there is a limit on file 
size?

Implemented all the needed GTK constructs and a convenience function 
for actually extracting the text content from an AREA widget

Implemented a dialect shortcut in most layout styles by adding a 
bare string element, to make the label directive optional

The end of Daylight Savings Time gave me an hour extra today, so 
I wrote a web browser:

So now we can run REBOL code in Topaz executed inside a Red/System 
driven web browser. ;-)

Kaj, this may be a dumb question but what OS are you using?

Wow, this is the sort of stuff to showcase Red with, "A browser in 
only 21Kb, a ... in only ...". Fantastic progress guys.

GTK's, and other IDEs', idea has always been that Glade, and now 
a newer interface builder, makes it easier, but combining a generated 
XML interface definition manually with some code language doesn't 
compare to Red/System

You can't reuse a function name in Red/System. `printf`and `free` 
are already defined in the runtime source code (%red-system/runtime/). 
If you provide alternative names (not used by the runtime) for those 
imported functions, it will work correctly.

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

A shorter, but less efficient path, could be to use TCP sockets (or 
a lib like ZeroMQ) to setup a communication channel with the generic 
Java bridge.

I finally find some time to read Red/System doc, and I have a novice 
question - what is basically the difference of cdecl or stdcall? 
Respectively - when wrapping API stuff, how do I know which one to 
use? I expect this area is for more skilled C developers, than occassional 
interface users?

In 13.6.2: isn't there a typo?

show-args 123 -p hello

it would output:

count: 4
1: test-logic2
2: 123
3: -p
4: hello

I would expect 1: being a "show-args"

13.6.2: yes, it's a typo.

small typos:

Similary, it is also possible to modify the c-string's bytes
  .... "similarly"
alias names should end with a exclamation mark
  .....  "an exclamation"
The stdcall attribut is also accepted
  ....  "attribute"


But - those are really small typos, you can probably spend your valuable 
time elsewhere :-)

Thanks for reporting them. I will fix them now, that's just a couple 
minute work.

btw: why was 'declare word used instead of 'make? Will there be 'make 
in a RED level, so you wanted to keep the difference?

`make` implies a dynamic creation (at run-time), while these are 
static value declarations (at compile-time). There was a debate about 
that on the Red ML, see the thread for more info.

BTW, there's no memory manager at Red/System level, so that you can't 
"make" a value, you can only declare it at compile-time. If you need 
dynamic values at run-time, you will need to use malloc/free wrappers 
provided by the Red/System runtime library.

The NDK compiles C/C++ to fat binaries native code, not Dalvik. The 
native code interfaces with Dlvik code through JNI standard ABI. 
If you make Red compile to the JNI calling conventions, to will be 
much easier than rigging up a TCP control interface.

Using a JNI interface is my plan, but it requires to be able to generate 
Red/System shared libraries. I was mentioning the TCP option, as 
it could be done right now.

If you are making a native compiler for Android, integrating with 
the NDK is the best way to go. Unless what you are making is a compiler 
that runs *on* Android devices, which would be great; then you would 
make the libraries for that compiler integrate with the NDK.

Most Android phones run 2.2 or below, so that good is a bit limited.

I would personally appreciate it if you supported 2.2, as that is 
the last version that my phone model currently has been upgraded 
to. It would be a good idea to look up the stats for which percentages 
of Android phones are running which versions. I haven't seen a 1.5 
phone in over a year, but my gf's phone won't be upgraded past 1.6 
(I need to get her a new phone).

We did a lot of research into the NDK for the R3 project. I was really 
interested in how an Android host program would be structured, how 
the Android application model would map to the R3 model. Hint: Android 
doesn't really have applications at all.

In a lot of ways, Android reminds me of the Oberon System. You don't 
install apps, you install system services, that for some of the types 
of services provide a UI, and for other types of services provide 
an API or task execution model.

There are a lot of people still waiting for their manufacturers to 
provide upgrades from 2.1 to 2.2, so 2.1 support is a good idea. 
The main thing added in 2.2 was the Dalvik JIT compiler, and that 
doesn't really affect native code that much. The NDK docs have a 
pretty good changelog that tells you what was added in each version.

I could go 2.3 with a custom ROM but I would loose HTC Sense UI.

I will stick with ARMv5 until we rewritte Red/System in Red and add 
a code optimizer. Such optimizer will be able to generate v6 and 
v7 specific code when required.

Never mind about what I said about ARM6. Apparently some devices 
were ARM6 but claiming to be ARM7. Progressive support for ARM6 and 
maybe even ARM7 might be a good idea to add to the ARM5 binaries.

Not supporting phones was part of what killed rebols momentum, imo. 
Being the first alternative is hugely more valuable position than 
being a late coming alternative.

I think nothing bad of you :-) For me, it is easy - you can't compare 
PC world, which I would assign 3+ years of lifecycle easily, with 
mobile world. In mobile world, I would say it is 2- lifecycle, or 
even shorter. If each day 300K of Android phones is activated, then 
I would pretty much decide to start supporting the almost latest 
models, which is - 2.3. Even my girlfriend HTC Wildfire S, which 
was published on 15.2.2011, is 2.3 version. Before Doc finishes the 
product, it will be old, and unsupported phone by its vendor. Of 
course, it depends upon the featureset you are going to support - 
if supporting pre 2.3 is a no brainer, why not. But - if 2.3 contains 
some real anhancements you want to utilise,then based upon the above 
usagedata, forget at least pre 2.2 ...

Pekr, the top Android phones are the ones people already own, not 
the ones they haven't bought yet. And most of the ones they already 
own (in my country) are bought with 2-year contracts, not qualifying 
for a hardware upgrade until after that, and aren't able to be upgraded 
very much in software because that would compete with new phone purchases. 
It's good to see 2.2 adoption so high though. I am stuck on 2.2, 
btw.

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

Though to be fair, most of the deployment problems on Windows (for 
R2) come from it using the registry in a Win9x style.

We're getting a little off-topic here though. Go Red!

It's a choice we can reconsider once Red/System will be rewritten 
in Red. But we'll probably end up choosing the same option, because 
of the overheads of deviating from the format C libs and OS API expect. 
Anyway, it should be an interesting debate. :-)

Sure, but the biggest issue is having to deal with a length header 
when passing to (and returning from) an external function.

Tamas sent me a link today about a nice little SSL/TLS library (http://polarssl.org). 
The bad thing is that it's GPL, but the license extends to FOSS License 
Exception: http://polarssl.org/license_exception


As I understand it, it would be possible to use it for Red but every 
future Red binary publicly distributed would have to come with also 
the PolarSSL source code and a copy of the GPL library. I think that 
burden would be too high for future Red corporate users. What do 
you think?

Hm, yeah, I'm not sure. I guess, I had zlib in my mind, which PuTTY 
also do a reimplementation of. I'm not too much into SSH and SSL. 
PuTTY also have code for SFTP, if that helps in any way to make a 
SSL implementation.

Too bad, it's such a load to implement some security. :/

Would it make more sense to implement such protocols in REBOL, which 
may be easily portable to Red? (Instead of doing a C implementation.)

I think it would be doable to implement SSL/SSH in REBOL, but it's 
a big task (at least for SSL).

Much GPL software that is relevant has that exception, so it's a 
limited problem

From a technical standpoint, Jaromil has advised me that GNU TLS 
is of higher quality. It is LGPL, so it's acceptable as long as you 
agree to provide the source code to GNU TLS only, as with many other 
libraries

It would be great to eventually implement many libraries in Red, 
but this is a gargantuan task, and security code is very specialised 
and critical

Apparently, PuTTY has its own BSD SSL implementation, so that's interesting. 
But it's not structured as a library, but entirely integrated in 
the other protocols, seems somewhat limited and lacking in portability. 
The only way to use it would be to rip out the source code and make 
a portable library out of it, or reimplement it in Red

Kaj, can you see, if it's a SSL implementation or just SSH? Or is 
SSL there by automatic, when making SSH implementations?

SFTP is basically nothing more than a set of specific commands sent 
over SSH.

There is a "telnet.c" in the PuTTY sources.

I have just bricked my Sheevaplug by doing a simple "apt-get upgrade"...:-(

So I need to find a suitable ARM emulator now to be able to finish 
the ARM port...

Seem to be several howtos on how to unbrick a sheevaplug

I will see if I can setup QEMU to emulate an ARM and install a suitable 
Linux image over it.

Yes it can, but the procedure is long and complicated. It also requires 
a USB stick that will be recognized by the sheeva.

I've been working on a GoboLinux upgrade for the past days after 
nuking my installation, and there are all sorts of problems

Kaj: you got a message here: https://gist.github.com/1326101

I've uploaded a zipped copy of mine: http://sidl.fr/tmp/libgio-2.0-0.zip

Although it may just have been followed up by a newer version

GTK-widgets.exe has encountered a problem and needs to close.  We 
are sorry for the inconvenience.

Are you starting it from a command prompt? If you do, do you get 
any extra output?

Works if you stick a fixed block in that hbox block ... well at least 
at the beginning

Back in a few hours ... Friday mid-night approaching.

That's only a very coarse library version that has stayed the same 
for a long time. What package version did you install?

MikeL: I've pushed a fix in Red's master branch for the issue with 
gtk-widgets.exe, it now works fine on Win7 (should be ok on XP too).

Agreed. I tried to combine a GTK with a ZMQ.... I start to get collisions 
on #includes.      Is there an #include/check option that I didnot 
see in Section 10  http://static.red-lang.org/red-system-specs-light.html#section-10.2

Harking back to the discussion of Red strings, it might interest 
you to know that the SMS character set uses the 0 position for the 
@ character. Just one of many character sets that won't work with 
C strings. C string support is good for Red/System apps that have 
to access C string library functions, but is a bit too limiting for 
Red itself.

Interesting, but I guess that a specific data encoding would be more 
appropriate than plain REBOL or C? Something like the Golf dialect 
(wrote by hostilefork?).

I was mostly interested in code sharing over text messages, but something 
like AltME or a code editor on my phone would be invaluable. A code 
editor that can send code snippets over SMS or other sharing services 
sounds interesting. I only mention this in this group because Red 
looks like it will end up on my phone before R3, barring a miracle.

Do you want to make a QNX port as well?

It was a bug occurring only in rare cases, I'm glad I had the occasion 
to spot it.