AltME groups: search

My directory structure is:

build\tools:

\api\android.jar
jli.dll
aapt.exe
keytool.exe
zipalign.exe

I'm trying to extend the build script for other platforms, but my 
Ubuntu 11.04 image somehow got stuck with old source repository versions 
and no way to install/update any packages...So I now need to install 
a 12.04 package in order to check the requirement for the build script 
and test it. I'm baffled that the support for a 2 years old Ubuntu 
version is so bad...

APK build script now works on Linux!

Android APK build script now works fine on OSX too.

So, I gave my new BeagleBone Black (BBB) a quick test. With latest 
Arngstrom Linux, I was able to upload Red ARM tests (generated using 
%build-arm-tests.r). All tests pass, except %function-test, which 
crashes with Runtime Error 1: Access violation ....

I'll add the /deep to %build-arm-tests.r Pekr (Runnable dir is required 
and built by quick-test.r)

I'll also suspend the function tests from the Arm build.

Pekr: answer is yes to your above question. But I will wait after 
the 0.3.3 release to add a Red binary to the repo and a build script 
to encap the Red compiler. Also I need to update documentation and 
see with Andreas how we can set up automated builds for each new 
commits.

Doc and/or Kaj, at what point will we be able to use Red and R/S 
to start things off by programming the MBR and jumping to a Red OS. 
What I am interested in is learning to use Red and R/S to build a 
native O/S from the ground up as this is the best way to truly understand 
computers. Also a PC that is Red and R/S from the ground up is a 
very exciting prospect.

In any case, you might find my attempts at a CMake-based build useful, 
as I explicitly list the `make prep` scripts and their dependencies 
there:

https://github.com/earl/r3/blob/wip-cmake/CMakeLists.txt#L109

Hello MaxV: Congrats to your first R3GUI app! ;-) I have some questions/notes 
though:

1. Why one needs to download the two DLL files to get R3B running?? 
(not much user friendly IMO)


2. On your Blog page you say: "First of all there are some bugs, 
most of them depends on R3GUI, for example this one: https://github.com/angerangel/r3bazaar/issues/8"

I bet this is not related to R3GUI at all but more to your R3B build. 
The REQUEST-FILE works without any problems in our Saphirion build 
(and I think also the "official" Carl's build works well but haven't 
tried it). I tried to download and run your R3B binary and I can 
confirm the bug is related only to this version so it would be fair 
enough if you remove your R3GUI blaming from the blog entry if possible. 
I know R3GUi is not perfect so maybe you can just change the blame 
for some other which is really related to the framework. Or better 
feel free to ask any questions in RgGUI group here!

3. I've looked into the EDITOR function code and comparing to the 
R3 editor code (which is still twice as big as the R3GUI version 
- but I don't know if they match the features though) the R3GUI code 
looks much cleaner and abstracted that the R2 style even if you are 
not expereienced writing R3GUI apps. Some notes:


3.1 I'm curious why are you accessing the internal AREA style value 
like face/names/tb or aa/names/tb/state/value? Is that for some reason? 
Why you don't use the AREA directly like:
do-actor/style face 'on-key arg 'area
instead of
do-actor/style face/names/tb 'on-key arg 'text-box

or

write (to-file AA-INFO/OPTIONS/text-edit) get-face aa


write (to-file AA-INFO/OPTIONS/text-edit) aa/names/tb/state/value 


3.2 There is "classic" but anoying bug. If you open file requester 
and close it without selecting a file the editor errors out. (but 
you probably already noticed)


3.3 Would be great if you add keyboard shortcuts. It's easy to add 
them. See the layouts-15.r3 file in R3GUI Saphirion package as an 
example.


3.4 Maybe you could try to write your first R3GUI style - MENU It 
would be handy in the editor(and also in other apps) instead of the 
buttons on top.


Anyway, thanks for promoting R3 and R3GUI. I appreciate all your 
efforts!

re 1. Saahirion's builds never needed to have such libraries copied 
in the program dir. I'm using MinGW includes in combination with 
MSYS make to build R3. To me it looks like some problem in your make 
procedure.

re 2. REQUEST-FILE native! has nothing to do with graphics. It is 
present even in the "official" R3 release.

re 3. by "R3 editor" I meant eht EDITOR function you have ennounced

re 3.1 here is quickly cleaned-up version: http://cyphre.mysteria.cz/stuff/editor.r3

re 3.3 Note the keyboard shortcut code stub in the link above, this 
is the way how to support shortcuts in R3GUI. Easy, isn't it?


As I said feel free to blame R3GUI where appropriate, there are surely 
bugs around...the REQUEST-FILE bug just simply have really nothing 
to do with R3GUI but more with your compiled exe.

Compilation depends on a Red development branch, so I can't integrate 
it with my build runs for binary downloads yet

You have to build it yourself out of 3D particles such as triangles, 
polygons and textures. Or use an existing one and write an extra 
binding for that

most of the stuff I've needed I've had to build myself :(

Thanks for noting the blog update Petr. Nice to hear he's enjoying 
himself so much. Maybe we'll get him back into REBOL when he sees 
that he can build Roku stuff in Red.

And then we build a spaceship and take a trip to the Moon. I always 
wanted that!

OK, I build a telescope for our observatory, to watch you walking 
on the moon :-)

Raspberry Pi is just medial thing. That thing is just small computer, 
nothing more imo, much hyped, than usefull, unless you build some 
kind of min-pc or player. IMO something like Beagle Bone (Black), 
with many IO pins, is more interesting. BTW - during SO chat, Carl 
mentioned he is getting Beagle Bone Black. That's imo, where Rebol 
could find some niche - embedded, automatition, etc.

When you buy such a bare board, you have to build a computer around 
it, which makes it much more expensive and uses a lot more power

Yes, but it seems to make sense to base body text on this and build 
the rest around it. MDP has a particular way to format body text, 
but we've found that it's hard to extend. I would like an MDP2 that 
much better is capable of outputting right down from a single paragraph 
of markdown to a full multi-page document.

I've been rather dormant in many rebol spheres in the last months 
because I've been working a lot and most of it is commercial and 
private work, but I feel like its time for Rebolers to break out 
of their inferiority complex and show others that Rebol is better, 
more cutting edge than ever.  

And it still stays simple, overall, even in large projects.


I think the community has lost a bit of its resolve, and I am trying 
to make a point with the devcon.  Rebol has never gone away and its 
back on track.  


I think its up to everyone involved in public projects to promote 
this by actually playing on Its strengths.   I resisted the urge 
to build the site using public tools, and I think, Chris and I and 
building a super default framework just by catering to the needs 
of the devcon's web site.   Chris just added a news module to it 
(in one day).  we will show the site's internals at the devcon, showing 
how easy it really was to build up, using a centralized Git Repo 
to share the code and with the server, when ready for production.


Its ALL coded with REBOL.  at the devcon, we will look at packaging 
QM with cheyenne, Remark and making sure it all works with my web 
service API... with this l think the rebol community will have a 
pretty nice framework to rival RR and others.

Pekr, we are talking about ability to build kernel device drivers, 
nothing to do with a user-mode dynamic library, it's another world.

The spaces problem is probably in the 12,000 lines build script I 
mentioned. I didn't feel like modifying that to make it space-proof

r3-gui.r3 is exactly as long as the MS build script for a Windows 
driver :-)

Good news are that there already is a language following this design 
goal:
#[[Wikipedia

One of the design goals of it was that non-programmers—managers, 
supervisors, and users—could read and understand the code. This is 
why it has an English-like syntax and structural elements—including: 
nouns, verbs, clauses, sentences, sections, and divisions. Consequently, 
it is considered by at least one source to be "The most readable, 
understandable and self-documenting programming language in use today. 
[...] Not only does this readability generally assist the maintenance 
process but the older a program gets the more valuable this readability 
becomes." On the other hand, the mere ability to read and understand 
a few lines of its code does not grant to an executive or end user 
the experience and knowledge needed to design, build, and maintain 
large software systems."
#]]Wikipedia

Some other good news:

- the wheel has already been invented:
- the language is mature, having been designed in 1959


So, Giuseppe, aren't you eager to try it? It might be quite an enlightening 
experience for you, realize that you would immediately understand 
the expresions!

You could try to follow the Syllable build description

Here are some optional environment variables that you may have to 
set for a Windows build:

It's a formal file for my build system. A build dialect

funny, I have a power build system too..  called maker.

Right, but how did they get funding and support? For Rails, at least, 
they wanted to build the tool for their own use. And they're built 
on top of other infrastructures.

If there are a significant number of items, do the transform once 
and build yourself a structure with the numbers in place so you can 
just sort on them.

you can build your own parsing, and your own dialects as well...depending 
on your application

you can build the binary! array using this function

I'm trying to build a string with rebol content inside (also strings). 
And I get into trouble. I think, it's a bug. Try this:
>> s: "^"abc^/def^}ghi^""
== {"abc
def^}ghi"}
>> to-block s
** Syntax Error: Invalid string -- "abc
** Near: (line 1) "abc

eFishAnt, yes that's a string. I'm trying to build REBOL content 
within a string, so I have to figure out how to type strings within 
strings.

Not really. I start with a string:
output: make string! 10000

then I go into a parse, where I build REBOL content within my output 
string. Sometimes I have to append a string (as a string) to output, 
and it fails, when I have newlines and { like characters.

Oki doki! :-)

I then just save my result to disk (because I can't use it directly, 
as those [ and ] are words (and not a real block). After reload of 
the result from disk, it should be real REBOL, right? Would be great, 
if I could build in a block and not a string.

pow!  all fixed  :-)  just need to let slim  build the new release 
from all the included files and we are set !  I will also be doing 
just a little bit of cleanup within GLayout to reduce the size of 
the final single-file app...

Part of the "problem" is that REBOL is really built for programming-in-the-small 
today, and being interpreted, you can't optimize out things you don't 
need--not without a preprocessor of some kind. It also lends itself 
to simple, direct word use, not the more verbose context/func approach. 
That makes it harder to build effective libraries. 


I've often thought that the best approach might be a simple library 
of "global" functions, which would basically add to the available 
words in REBOL, so they should be very generic, and there might be 
a lot of them. More complex modules would be contexts, and we'd need 
an agreed upon system for naming, exported words, etc.

build in older versions into the exe ;-)

First example with test of colors: http://www.fys.ku.dk/~niclasen/rebol/example.html

My idea is to build an example, that satisfies the need. Then I look 
at implementation for the Library, so sources in the library can 
be viewed this way.


Maybe refinements shouldn't be that yellow!? Should background be 
a little gray like this? #f9f9f9 Or should it be white? The purple 
and blue might be a bit too bright compared to the red and green? 
Or should the red and green be brighter?

It is, Gregg, understandable, of course, and a nicety to have for 
people not used to thinking in math terms. That's supposed to be 
the reason why both approaches are build in: Let people decide what 
fits their needs. Admittedly, me too apparently use REMAINDER, especially 
in cases where operators otherwise would catch a functions argument 
to it's left without parens.

Yeah, they ported /Core 2.50 to WinCE on StrongARM at my request, 
but apparently I and my clients were the only ones interested. You 
can run this build on Windows Mobile but since this was for a Handheld 
PC it doesn't adjust its window to an onscreen keyboard, making it 
significantly less useful on the Pocket PC platform.

A document format should build on the hierarchical datamodel. That 
can lead to problems, when sections are defined with "tags" like 
\in and /in (to make something indent) and \note and /note (to make 
a note).

This is valid:
\in

\note A note

example

/note

/in

Ahum; that's my area and it's kind of a struggle. I like high-level 
languages, but when I joined Syllable I had already established that 
there were better things than Python. I had ported Ruby to AtheOS 
and that's what we're using now in my build system and in the installer

My complete build system for building the entire Syllable operating 
system is 1600 lines of Ruby. 13,000 lines should be able to do something 
constructive

OK, but those 1600 lines build a complete desktop operating system 
with applications, while those 13,000 lines install and configure 
one application - without checking for destroying your system

You can get there through the descriptions in the recipe for the 
Syllable build system:

It is missing important apps like CVS and SSH for instance, and I'm 
not a typical Linux user who can spend hours to find and download 
the GNU sources for an app, configure the build, and compile it.

 <--- don't know how Mandrake handles packages other than it's RPM, 
 but Debian handles these things in seconds with a single CLI command, 
 and it surely isn't necessary to hunt down sources manually. :-)

I always regarded Debian as a bit harder to start with but many times 
easier to maintain once it runs.

Carl told that the command build for linux was done on 15-Jun, with 
Pro, Base and Core, but I cannot find it!!

Nope, i have been directkly to the build...

why the build use libstdc++ v5 and not libstdc++ v 6 ?

curious distro is targeted by the Rebol/View linux build. I know 
compatibility is not an issue, just idle curiosity.

and for your script:
print "Content-type: text/html^/" 
read-cgi: ...
args: decode-cgi read-cgi 
template: {
 <html><body> <pre> <% mold args %> </pre> </body></html>
}
print build-markup template

btw - always build your resulting string first out: copy "" ... and 
then everything append out stuff-you-want-to-add .... print out at 
the end ... it is MUCH faster to print everything at once, then to 
print incrementally to the client ...

otherwise, you need to ask Carl (repeatedly ;) for a new freebsd 
build for you.

do you need to write binary, or a multipart?could be multipart can 
use base64. then its somewhat bigger, but has no problems with text-mode. 
could even be that multipart of email works the same. in that case 
there is 'build-attach-body.

The biggest restriction of CSS is you have to work harder to build 
layouts.  Otherwise CSS gives you *all* the control that depricated 
HTML attributes give you -- *plus more*.  So perhaps there is a dominant 
web style used by those experimenting with CSS (understandable if 
designers are learning from the same source, whether that is Eric 
Meyer, A List Apart, or WPDFD); but to use CSS as the excuse for 
this is a copout...

CSS Workflow -- easy: create a concept based on information needs; 
plan how to acheive this with the box model; create a base HTML template 
and build up styles around that, incorporating background images 
as required; then test and revise, test and revise, test and revise, 
etc.  Simplified somewhat.  Basically the same as any legacy HTML 
project, only easier.

re workflow - interesting - I will order Zeldman's book too .... 
Alistapart seems to be a good resource too. I never build large site, 
just few webpages, generated by script or using DreamWeaver 4 long 
time ago. My mine problem right now is - how to start to think of 
a design. From typographics area I know I should divide page into 
some sections. I did so using tables extensively, now I wonder, if 
I should use css columns, simply using "div" tags ...

So - if you would build "typical" webshop, would you go for tableless 
design?

Nearly the only thing I did not like about Temple (well, except the 
lack of higher level dialect and docs :-), was that it uses two-phase 
process, and once you build web-page from rebol block structure, 
it knows nothing about original template formatting, I mean - html 
source code formatting, so you may end-up with ugly code, but that 
is not relevant to 99% of users :-)

There's never any such thing as perfect code .. better to get something 
up, and let others build on it .. paraphrasing Isaac Newton

As programmer not AFAIK. with a dom you can use path-notation. with 
SAX you build that tree yourself. I guess SAX makes sense when you 
convert data, like xml-make-doc. one tag, output something, another 
tag, output something other.

There are two major types of XML (or SGML) APIs:

Tree-based APIs

    These map an XML document into an internal tree structure, then allow 
    an application to navigate that tree. The Document Object Model (DOM) 
    working group at the World-Wide Web Consortium (W3C) maintains a 
    recommended tree-based API for XML and HTML documents, and there 
    are many such APIs from other sources. 
Event-based APIs

    An event-based API, on the other hand, reports parsing events (such 
    as the start and end of elements) directly to the application through 
    callbacks, and does not usually build an internal tree. The application 
    implements handlers to deal with the different events, much like 
    handling events in a graphical user interface. SAX is the best known 
    example of such an API.

Chris - following is true imo which favors SAX with me:


Tree-based APIs are useful for a wide range of applications, but 
they normally put a great strain on system resources, especially 
if the document is large. Furthermore, many applications need to 
build their own strongly typed data structures rather than using 
a generic tree corresponding to an XML document. It is inefficient 
to build a tree of parse nodes, only to map it onto a new data structure 
and then discard the original.

The thing is - result of DOM parsing is tree representation of document 
- in Rebol .... the question is, what if you need data organised 
otherwise? You will have to search that tree and build such structure 
which fits you anyway ....

hmm, not so easy and small anyway ... probably the best aproch will 
be to decide what direction we go and then starting to build rebol-oriented 
solution, not trying to port something. Looking at some stuff it 
seems to me sometimes it is designed to fit target language, e.g. 
java ....

To Michael:

I'm not sure if need DOM and SAX, there problem is, that the commitee 
tried to develop language independant interfaces - so both APIs have 
problems in the targeted programming language. DOM is inefficient, 
and you should avoid it. The best way seems to be:
1. have a parser like SAX with events
2. build the model in the best way for your language
3. provide a API for your language

Basically XOM does it for JAVA very well, E.R.H. uses a SAX parser 
and converts to its own object model that is optimized for java. 
For REBOL this should be something like a block, I think. (Blocks 
are best way to store things in REBOL ?). But thats internal side 
of the the tool and could be the rebxml block structure. As api there 
should be a dialect, maybe one that uses a port (there I have less 
knowledge - have to learn about this).

I think us REBOLer's should build up our products and tools to make 
this easy to do.

It is already a time to do a call for papers/presentations to build 
up publicity, and to do a press release, which gives plenty of time 
for it to google up.

I would welcome if interim releases would be commented in the same 
way, as Carl did with View 1.3 Build Change Log. It keeps ppl informed 
....

I will just addon..with the vaious 'powerpacks' in place.. it is 
possible to build something similiar to 'Ruby on Rails'


I believe the French community already have some well defined framework 
called Magic!... and we have Temple(?) lying around somewhere.

Well, creating a swf with a single checkbox is rather impractical... 
but all the components can be skinned using CSS (also cool).. so 
you can build things like this... 
http://scalenine.com/themes/wmp11/wmp11.html
or this
http://fleksray.org/skins/edding/Edding.html

RT will have the main "kernal" closed and its this part that RT will 
develop other parts are left to the community to build

Why is the View 1.3.2 release for Linux not on the main RT View download 
page? On the test build page it has release status, and I'm getting 
people who are unable to find the Linux download

Hey, not all of us have that luxury. Some of us occasionally are 
forced by circumstances to use applications other than REBOL, if 
only because they have been written already. I would prefer to use 
REBOL to script these applications simply because the alternative 
would be any one of a couple dozen languages with ActiveScripting 
support (every major scripting language with a Windows build, including 
almost all of the open-source languages). Rewriting Excel in REBOL 
just isn't an option for me.

- .NET interfaces to COM and implements some of the framework by 
referencing existing native-code libraries, some of them through 
COM, but it doesn't use COM internally. It does include standard 
facilities for COM and .NET applications to interoperate. Other .NET-like 
runtimes don't use COM, and may not be able to.

- Good catch on Firefox and the Mozilla stuff, their XPCOM framework 
they build their components on works very similar to COM. It would 
require binding to different libraries through a slightly different 
interface but the REBOL-side dialect could be the same.

Oh. a real plain /pro? But sure somebody else can encap? Just build 
a tcp-proxy and they encap it?

I have rhe SDK and Rugby: want me to build it for you?

The thing is Linksys routers run linux.. so it shouldn't be that 
difficult to build in the skype code.

Check the build pages.

Josh, is there some way to automate the build process, and do the 
certificates or whatever, so when you leave again, a new version 
can still be easily built?

Josh is writing details notes about the build process.

Yes, but as far as I know, the plugin C source is locked down to 
RT. maybe an automated build process that doesn't expose the source 
would work.

A few notes:

* There is currently no documentation (I'm sure you can figure it 
out from the HTML).

* The Mozilla plugin has only been tested with FireFox on Windows 
XP. 

* This is a Windows/Intel/x86 build; it will not work on Mac or Linux.

Now I recall one my old rant... would be very nice if  there's a 
way to call rebol func from javascript.  Something like: 

<input type="button" value="Send" onclick="rebPlugin.evaluate('send');"> 

So we can build an html interface and use plugin & rebol instead 
of  XMLHttpRequest and Javascript

Bugs found in Firefox with Cyphre demo: 

- starts with no sound (the music started when I opened a parallel 
session with Opera, in Opera the sound is ok)

- seems there are some problems with AGG: no rotating Carl Head, 
some flash with gears, no "rebol rulez" in the sky... (Opera is ok)

- when I close firefox the music continue for 4/5 seconds (until 
the buffer is empty ?). In Opera too.

- sometimes the plugin disappear if I refresh the page. I have to 
close the browser. In Opera too.


WIn2000, nVidia GeForce4 MX 440, Firefox 1.5.0.3, Opera 9.0 beta 
build 8393

2) Build an automatic updating mechanism into the plugin, so it will 
check for new updates, prompt the user if he or she wants to download 
those updates, and then install on-top of the previous installation.

thanks for the feedback. i apologize if i conveyed the idea that 
security discussions are noise. What I mean is that I don't have 
the bandwidth to sift through pages of discussion and build the plugin 
at the same time. So, for my sake, we need some kind of itemized 
system where Carl and I can tackle the issues one-by-one.

Security extension, yes, removal of something - hehe, how uneducated 
imo :-) Is smtp so difficult to build? Having tcp socket is dangerous 
already, as I can build my custom smtp in script, and have server 
at the other end of the country, which listens on 8080 and doing 
smtp ....

Pekr, you can not build smtp if the sandbox does not let you connect 
to a mailserver.

what if I dynamically build my-send function?

need time to build my own plane!

you have one hour to build the most impressive:
-parser (using parse)
-view app
-core app

I don't know where I put it, but I once built a detailed checklist 
of functions we would build for each game platform we worked on. 
 I designed the game interface for WebTV, which also did not have 
Key Up.

The basics are:


Input: Key up, and at least 3 simultaneous key overlap.  This is 
needed because during actual game place, people will press directional 
and fire buttons at the same time.


Video: Double buffer - triple buffer is better.  Without this, one 
needs to know where the beam is (called beam tracing) so that rendering 
happens on the sync.


Threading:  It is very difficult to write a game in a single thread. 
 At the very least it needs to be able to trigger functions.


Sound: Sounds need to be started, stopped, and volume changed on 
the fly.  Multiple channels (4 minimum) for a full experience.

We need a Rebol tile set.  Perhaps someone will build them from famous 
Rebol programmers.

I'm still trying to build a 40 card starter deck and balance it at 
the moment before i finalise needed images

then some building related images for walls / towers probably 2 wall 
building, 2 tower building, 1 dual wall + tower build

6 resource based images - 1 each for gold, wood and energy.  then 
1 each for destroyed mine, energy vortex, burning forest.

6 resource conversion images - wood seller (wood to gold), gold to 
wood, gold to energy, energy to gold, energy to wood, wood to energy

3 stockpile (as opposed to mine/forest) depletion images - energy, 
wood, gold.  3 stockpile increase images (energy wood gold)

then some building related images for walls / towers probably 2 wall 
building, 2 tower building, 1 dual wall + tower build

;) then a few combat wall/tower destroying images - ive yet to balance 
that bit  :)