View for CE or Zaurus revisited.
[1/13] from: tbrownell:l3technology at: 12-Feb-2003 14:08
Why oh why is there no Windows CE/view product?
And has anyone tried /view on a Zaurus yet?
TBrownell
[2/13] from: atruter:labyrinth:au at: 13-Feb-2003 16:40
> And has anyone tried /view on a Zaurus yet?
No, but I've got /view working on a two disk (1.4Mb) linux distro based on
Tiny-X w/o any issues. What kind of X11 support does the Zaurus provide?
Regards,
Ashley
[3/13] from: brian:hawley at: 13-Feb-2003 13:07
At 04:40 PM 2/13/03 +1100, Ashley wrote:
>>And has anyone tried /view on a Zaurus yet?
>
>No, but I've got /view working on a two disk (1.4Mb) linux distro based on
>Tiny-X w/o any issues. What kind of X11 support does the Zaurus provide?
None. It's based on Qt Embedded. StrongARM platform.
Brian
[4/13] from: brian:hawley at: 13-Feb-2003 13:04
At 02:08 PM 2/12/03 -0800, TBrownell wrote:
>Why oh why is there no Windows CE/view product?
Memory and speed requirements. View typically uses at least
4 to 5 mb of memory for every instance, and that's before
you take any data or scripts into account. Also, /Core on
CE is dog slow (at least on ARM, I haven't tested others).
Both of these problems together make REBOL impractical for
any embedded systems platform, even a generous one like CE.
Fixing the memory problem would require reorganizing REBOL
to share more resources between instances. The speed issue
would require a lot of profiling and hand optimization.
Both together might require almost a separate code base,
just for embedded platforms; at least some code could be
shared between CE and Linux, though. All this would require
more time and resources than REBOL can allocate for this
kind of thing for now - closed source, remember.
Personally I would appreciate /Base/Pro for CE. The memory
requirements would be less and I could have the libraries
already in ROM do the grunt work. Even command line param
support or clipboard support for the existing /Core would
make REBOL more useful on CE right now.
I can dream, right?
Brian Hawley
[5/13] from: tbrownell:l3technology at: 13-Feb-2003 11:38
I'm sure some have thought of this already, but given that Java and
PocketPCs don't get along very well, a large opportunity exists for a /View
GUI on the Pocket. That is, if it's possible/fast enough.
TBrownell
[6/13] from: petr::krenzelok::trz::cz at: 13-Feb-2003 22:53
Brian Hawley wrote:
> At 02:08 PM 2/12/03 -0800, TBrownell wrote:
>> Why oh why is there no Windows CE/view product?
<<quoted lines omitted: 4>>
> Both of these problems together make REBOL impractical for
> any embedded systems platform, even a generous one like CE.
Yes, very strange thing. Carl designed AmigaOS - modular concept, fast
enough even on 7MHz machine, yet View is sometimes laggy even on pretty
decent machine. Rebol is very good concept, but inability to compile (or
overall lack of free time of RT to add domain specific dialect virtual
machines) does not provide us with general enough language - we are
magnitude slower than C or even Java on general math and GUI stuff
(general primitives, bitmap handling). Maybe we should wait for next gen
devices?
The question is - is e.g. iPAQ (or other) PDA, running XScale at 400
MHz, 64 MB fast enough? If so, maybe RT could think about their "next
thing" as mobile devices support - Symbian + PocketPC + Linux?
I think that Ed said it very well! On nearly month basis we see various
products popping up here or there, which could be done using rebol ...
nearly done. We should stop playing the lowest common denominator game,
that is plain silly. In the long term, we are killing rebol oportunities
in certain areas. We need more open aproach and no that pseudo
efficiency game - not adding usefull features just because they would
add to executable size - the rest of world does not care - the rest of
world will not judge rebol upon its executable size, but what can be
done using rebol - and that is the only thing we should keep in mind
(and that does not mean we should forgot efficiency) ...
> Fixing the memory problem would require reorganizing REBOL
> to share more resources between instances. The speed issue
> would require a lot of profiling and hand optimization.
> Both together might require almost a separate code base,
maybe few things could be done even today ... during czech rebol
workshop Ladislav told us few hints that could possibly help (GC and
memory allocation related), but only Carl could answer those ones ...
> I can dream, right?
Who knows? The last dev. update is dated November, we have yet to see,
what RT plans for 2K3. So far we know that RT is working on OsX ports,
SDK is still beta ... I just hope RT will not be silent half a year ...
So, in the meantime, we can forget multimedia and other cute things
Rebol could shine in, and code few boring enterprise apps, can't we? :-)
There is always something usefull to do with Rebol ...
-pekr-
[7/13] from: ammon:addept:ws at: 14-Feb-2003 1:42
I beleive the Zaurus uses QT not X-11 Carl has signed up to be a QT
Developer (quite some time ago actually) but /View hasn't been ported to QT
yet...
HTH
Ammon Johnson
CIO of Addept ---------- (www.addept.ws)
435.616.2322 ---------- (ammonATaddeptDOTws)
[8/13] from: krobillard:san:rr at: 15-Feb-2003 14:46
On Thursday 13 February 2003 01:53 pm, Petr Krenzelok wrote:
> Yes, very strange thing. Carl designed AmigaOS - modular concept, fast
> enough even on 7MHz machine, yet View is sometimes laggy even on pretty
<<quoted lines omitted: 4>>
> (general primitives, bitmap handling). Maybe we should wait for next gen
> devices?
...
> So, in the meantime, we can forget multimedia and other cute things
> Rebol could shine in, and code few boring enterprise apps, can't we? :-)
> There is always something usefull to do with Rebol ...
Hi Petr,
Since I can't embed REBOL into C programs and use it directly, I've found that
using it as a compiler for custom virtual machines works pretty well. This
may be better than using REBOL directly as there is no run-time overhead or
speed penalty of a general purpose language. The only downside is that
generating binary values from REBOL is a little messy (such as the code
required to convert decimal values to IEEE floats).
The article you found on linking C and Python to build GUIs on MacOSX is a
good example of what would be possible if programmers were allowed to 'get
down and dirty' with REBOL.
-Karl
[9/13] from: rotenca:telvia:it at: 16-Feb-2003 1:18
Hi,
> speed penalty of a general purpose language. The only downside is that
> generating binary values from REBOL is a little messy (such as the code
> required to convert decimal values to IEEE floats).
Perhaps this could help:
>> third make struct! [a [float]] [3.53]
== #{85EB6140}
>> third make struct! [a [double]] [3.53]
== #{3D0AD7A3703D0C40}
---
Ciao
Romano
[10/13] from: krobillard:san:rr at: 15-Feb-2003 23:04
Aha, that's much better! I was using functions taken from Eric Long's
decimal.r script in which the conversion takes almost 40 lines of code.
Thank you.
-Karl
On Saturday 15 February 2003 04:18 pm, Romano Paolo Tenca wrote:
[11/13] from: krobillard:san:rr at: 15-Feb-2003 23:23
Hmmm... It just occurred to me that struct! is only available in the command
and view/pro versions of REBOL. Is this still true? If so, then using
struct! is not a good solution for code which can be used by others.
-Karl
On Saturday 15 February 2003 04:18 pm, Romano Paolo Tenca wrote:
[12/13] from: sunandadh:aol at: 16-Feb-2003 4:13
Karl:
> Hmmm... It just occurred to me that struct! is only available in the
command
> and view/pro versions of REBOL.
It works fine for me in View 1.2.1.3.1 (21-Jun-2001) -- that's a slightly
out-of-date version of View (not View/Pro, just View).
It doesn't work in the latest Core beta 2.5.0.3.1 (23-Mar-2001) -- though the
download page at rebol.com says a new version is available soon
Sunanda
[13/13] from: rotenca:telvia:it at: 16-Feb-2003 10:15
Hi,
> Hmmm... It just occurred to me that struct! is only available in the
command
> and view/pro versions of REBOL. Is this still true? If so, then using
> struct! is not a good solution for code which can be used by others.
It is also in standard View.
---
Ciao
Romano
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted