AltME groups: search

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. 


I don't get this part...Your program seems to be still running while 
you think it has finished.

If you have no loop in your code nor system calls that might block, 
you could try disabling your anti-virus program to see if that's 
not the one interfering.

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...

Well, it would be strange from you to try to push us to recreate 
an object just to expand it, whereas in REBOL3 group you are wondering, 
why function bodies are not hot-patchable anymore, no? :-)

it would be strange from you to try to push us to recreate an object 
just to expand it


That is part of the basic semantics of the R2 object! datatype, it 
follows the prototype-based model. You construct new objects by copying 
existing ones, it can be just a copy (cloning the source object), 
or derivation (extending the source object with new words). Changing 
object context (adding/removing words) without creating a new one 
is not consistent anymore, so it can look like a big hack.

I freed up some space on my mac I'll download latest version from 
github and have a little go. Anything specific to look for/try? Imho 
you are allowed to patch as much as you want, release or not. We 
will follow anyhow.
Great reply! Thanks.

I am going to spend 3 months at least in Peking for working on Red, 
but not only on the coding part. I will try to setup a business activity 
around Red in order to fund its development further. I prefer to 
not talk much publicly about it for now, as I am not yet there and 
there are some potential NDA clauses that I would like to avoid having 
issues with. ;-)

You can try to compile it with -v 9 option to better locate the line 
that trigger the error.

Actually I know there are errors in the script since I did not try 
to translate it from R3 to Red. But I was expecting something else 
for a starter

Yes I wanted to give it a try for the doc scripts. But parse is not 
my expertise, and at the moment I am short in time as I can make 
extra hours at work. So everybody step in please and publish your 
baby-doc-scripts so we can all contribute little bits.

Wow! That's great Doc.

We'll try to keep you supplied with plenty of pizza. :-)

Yes, go Doc! I wish I was better at low-level programming so I could 
help a little. If there would be any examples of simple bindings 
or base of TCP that we could extend to different protocols I would 
try to participate a little.

1. _zone_ is a struct pointer. I need to pass a pointer to a struct 
pointer as the 3rd parameter, that's why I try to use get-word here.

I've stressed the current Red runtime source code a bit so it keeps 
"tilting" as I try to make it work. :-)

BREAK/GOTO/FSM: I also try to avoid BREAK, although it can come in 
handy. GOTO would make my 6502 emulator faster, but it's ugly. Having 
FSM support would be brilliant

(you can try resizing too)

brianh - try to locate related blog. carl asked for help - if you 
link view, he was not able to let the conole work in a real console 
way, or something lik that :-) Well, off topic here ...

Yeah, I'll try WINE first, but R# looks awful on it

I'll try to speed things up.

Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 

http://static.red-lang.org/rpi-gtk-widgets.png

You can see the source code for this GTK+ demo here:

http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).

De rien, merci à toi!

I cannot really find a startup guide for Red: so, if no one shouts, 
I'll try to write one, during my long hours of flight next week.

Well, I try to switch to dark themes to both save powers and my eyes. 
;-) 


I've provided a switching option to more classical "light" theme 
for the docs, but doing the same for the web site was too much work 
for me, so I've left it with the dark theme only. I will fix that 
once we get a new web site for Red (or if someone skilled enough 
can make the changes, I'll be glad to push them online).

I'll have a try

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:
 

I must have missed that remark before. But then again, I like to 
try this using Red or Red/System as an exercise or for fun or to 
not be dependent of using C (Why not do it all in C? Because we have 
Red/System.)

Just want to briefly describe that in my expectation a C-level language 
means you can do things like you would when using C. So it is not 
that you would have to call functions/programs/libraries with C programs 
to do those things. So for speed issues or fast prototyping purposes 
or to do things not yet possible in another way you use the bindings. 
In my case I wanted to try to program a relative simple algorithm 
of which I have an example in C and I want to do that using Red or 
Red/System. I can accept it is too early at this stage.. at least 
for me but this kind of thing is what others will be doing in the 
near future and they discover you can do literally anything using 
Red and Red/System, as long as you make a C program to do it and 
call that. That is a bit of a black and white view, but that is how 
I see it.

Actually, this is supposed to be the compiler fallback strategy for 
cases that are not statically solvable. I haven't needed it so far, 
and I'll try to push the compiler as far as possible before implementing 
it.

@Kaj: I'm trying to get the JPG data without having X11 installed. 
 If I were to do something with LibJPEG directly, I would try to 
make it look like the R3 image! datatype.

I will try to answer the question of how I see possibilities to make 
Red more suitable for funding. And have it get the attention a first 
proper release needs. Everybody else is hereby invited to think along 
how to make this possible.

Doc - I was quite surprised with your argumentation. I really don't 
know, if we are so much in an IT, but are you guys serious, that 
for normal user, in order to just give some tool a try, such user 
should use systems like Fossil or Git? I find myself competent enough, 
but unless new Windows client appeared, it was just nightmare to 
get things going, especially if one does not feel the need to understand 
all that pull/push etc. stuff.

If users have no clue what Github is, then they are probably not 
ready for contributing.

 - Doc, that is so much off ... It is not imo about users contributing. 
 It is about various possible future Red users, who just found out 
 about Red, and want to have their first touch with the language, 
 no matter how complete the language is imo. Ppl's will to give it 
 a try should not be prevented by crappy overcomplicated things like 
 Git imo.

Is that really so much of a problem, to add link to latest zip archive, 
with just one sentence, that it points to kind of "nighty" pre alfa 
builds? Or do you really find R/S and Red not being worth giving 
a try even in an early phase of development?

that for normal user, in order to just give some tool a try, such 
user should use systems like Fossil or Git?


That's precisely my point, it's not ready yet for "normal users". 
That's what I mean with not ready for prime time.


I really don't  want to have to maintain two copies of the same instruction 
page on both red-lang.org and github site, just because of people 
passing by and not curious enough to click on the very visible "Fork 
me on github" red banner.

The latter, the ticket needs to be rejected, I was wrong. There is 
another ticket about adding support for Unicode whitespace as delimiters, 
and we should probably try to figure out how to implement that one 
(though the zero-width spaces are a bit iffy).

I still have work on MOLD tomorrow, I'll try to do PRINT too.

About the path composition for files, I might give it a try tomorrow.

Can you try it with /Core 2.7.6? (just in case...)

Try with this link: https://trello.com/b/FlQ6pzdB

You mean the SDL program? Yes, the window is already hidden, but 
if I try it on Linux I do get a task bar icon

I suggest to change the relaive part of "Readme.md" to:

Running the Red/System hello script
------------------------

1. From the REBOL console type:

    `call/show ""` ; (type this only once to fix Rebol 2 bug)

    `change-dir %red-system/`

2. Type: 

    `do/args %rsc.r "%tests/hello.reds"`
	

    the compilation process should finish with a `...output file size` 
    message.


3. The resulting binary is in `red-system/builds/`, go try it! type 
(on Windows):

    `call/wait/shell/console %builds/hello.exe`

Can't you just return unset! from an undefined path, like for an 
undefined word?

I will give it a try.

We have made an other big achievement of bringing R3 to Android OS 
based devices. In the last couple of days Cyphre added console support. 
So you now can input stuff on your Android. Further .r extension 
is now associated with the interpreter. So you can run downloaded 
scripts. We have uploaded a script, so you try it out.


Android R3 installation package: http://development.saphirion.com/experimental/R3droid.apk


Test script, for direct access from Android device: http://development.saphirion.com/experimental/oneline-prime-numbers.r


Thanks again to all who made a donation to drive this stream. We 
still can spend 10-15 days on this project at the moment. If you 
would like to help push this developement forward, feel free to donate, 
sponsor or make a bounty for features.

Hello, now http://rebol.informe.com/portal.htmlworks weel, I''m 
including all Rebol wiki around the web in it. So with just one account, 
you can:
- improve wiki
-discuss of rebol on forum
- upload images on Gallery
-... and much more
Take a look and try...

New Android release:

URL		: http://development.saphirion.com/experimental/

Direct URL	: http://development.saphirion.com/experimental/r3-droid.apk

Changes:
-added DH and AES 128/256 encryption
-rewritten console syncing code
-TLS scheme improvements
-fixed runtime stack size issue
-fixed FP math using dtoa()  (thanks to Ladislav!)
-fixed shared lib unloading issue
-fixed "exit on script error" bug
-minor app handling tweaks

Please give it a try and have fun.

I added seven Red GTK+ examples to the test builds, including the 
new text editor and simple IDE, so you can try them out right away.

The sources are here:
http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip&name=examples

The binary programs are here:
http://red.esperconsultancy.nl/Red-test/dir?ci=tip


*/Red/console-pro now includes the GTK binding, so you can make GUIs 
interactively right from the Red interpreter console.

Further, HBOX and VBOX styles are now available for layouting.

I added the new Red examples for 0MQ to the test repository with 
ready builds, so you can try them without compiling:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


I enhanced the Red versions with support for a program parameter 
giving the network URL, so you can adapt it to your environment and 
try different transport protocols.

I added binaries for the 0MQ ventilator example to the test repository, 
so you can try it right away:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


Like the client/server example, you can give program parameters to 
change the network URLs.

I added binaries for the Red browser example to the test repository, 
so you can try it right away, in */Red/GTK-browser:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


The latest Red interpreter enhancements are also in the build run. 
In the console, GTK-IDE and GTK-browser, path accessors can now be 
used.

New Android release:

URL		: http://development.saphirion.com/experimental/

Direct URL	: http://development.saphirion.com/experimental/r3-droid.apk

Changes:
-fixed console output crashes
-implemented CLIPBOARD:// device
-implemented BROWSE
-added circular buffer to console

-release has now correct platform, version, product and build information
-fixed console input hang-on-destroy bug

Please give it a try and have fun.


This release is a milestone since now Rebol CORE is fully done for 
Android. We will now start to get the VIEW (graphics) to Android. 
As soon as we have this, R3-GUI should almost work on Android too.

At a request, I upgraded R3 on Try REBOL from 2.99.111, the last 
official RT version, to Andreas' current build, the ongoing 2.101 
series. Not many changes, but some bug fixes.

http://tryrebol.esperconsultancy.nl


Graham programmed a nice bot for Stack Overflow chat that is able 
to call the Try REBOL web service to execute code examples and post 
the result.

Just in case nobody saw, Carl wrote in R3 github the following:

Been busy. Will check-in more frequently in March.


Sorry folks, Dec-Feb is the "crazy crazy busy" time for new product 
development. Yes, I know, I'm bad. But, I'm quite addicted to making 
new products... especially cute little electronic ones that sell 
in all the major stores in the US. Each one presents special new 
challenges that I just can't resist.


Starting in March I'll break away for a few hours a week to take 
care of things here.


Also... I really want to try using R3 with graphics running on DirectFB. 
It would be quite cool.


One other thing... has anyone got R3 running graphics on Raspberry 
Pi yet? If not, let's talk about how we can make that happen. What 
do we need?

I updated our Redsite for the latest Red features, specifically runtime 
function creation in the interpreter (which executes the Redpages):

http://red.esperconsultancy.nl/index.red

I added a simple IDE example to the list of apps:

http://red.esperconsultancy.nl/examples/IDE.red


It's a cross between the standalone GTK-IDE example and Try REBOL; 
basically Try Red written in Red itself. There are two main areas: 
one for editing your code and one for showing the result. Since it 
runs on your computer, unlike Try REBOL, it keeps state between execution 
of code snippets.


To browse the site and the apps you need the latest binary version 
of the GTK-browser. See above.

Cool - so many new things to try.

I've added a Red interpreter to the Try REBOL site:

http://tryrebol.esperconsultancy.nl


Also reorganised many outdated REBOL links. The Red functionality 
is also available on StackOverflow through Graham's bot.

I updated the Try REBOL site to the latest red-core:

http://tryrebol.esperconsultancy.nl


I've moved the About button behind the Red button, as this function 
is now executed in Red by default.


Also fixed several bugs in the site. Thanks to Graham for reporting.

An interesting thing to try is to enter "stats" and then press the 
Compare button. It will report memory usage for each language.

Tomorrow, Wednesday 10, our Internet connection will be down for 
scheduled network maintenance. During most of the European daytime, 
our Red and REBOL web sites will be down. This includes Try REBOL 
and our source code repositories. Our static web sites will be partly 
served by CloudFlare.

If you need access to our source repositories or Try REBOL, you can 
temporarily define our hosts locally on your system to our current 
IP address. For example in the /etc/hosts file on Unixy systems:

I've temporarily rerouted our most important domains to our current 
IP address, so they work again, but they will break again when our 
network provider changes the address back.


Try REBOL works again, but it being half down allowed Graham and 
Andreas to find a bug in R3's HTTP handler. :-)

I'm happy to announce that we reached a major milestone and can release 
a bunch of new things. All the different versions have been merged 
into one code base which makes things easier for us. This was possible 
because the new 'retargetable' graphics subsystem was finished. This 
allows us to port R3 to other platforms much easier. Next target 
Linux. The release in detail:


R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the 
feedback. The main milestone we achieved was to switch to a resolution 
independent sizing system. This will scale your app widgets to look 
the same on different display densities. It's a must have for mobile 
apps. Next for R3-GUI is to create a simple mobile style set. Fruther, 
we are going to push the source code to GitHub. We need to setup 
a bridge to our internal SVN repository, so expect some back and 
forth on Github before we are stable.	Anway feel free to help making 
R3-GUI better and better.


Android: This release is now mostly the same as the windows release. 
So, yes, it's now possible to do R3-GUI apps on Android. I'm going 
to try to run Treemapper on it. Type DEMO to see the new R3-GUI version 
and widget scaling feature. Post as much screenshots / pictures of 
your phone as you can :-)


R3/Saphir: New version for windows with bug-fixes are released as 
well. Please see the change-log on our web-site for details.


Thanks to all the team for the great work! I really think we are 
close to have a very good and stable base with R3 and R3-GUI. Looking 
forward to see more and more people joining and becoming part of 
it.

Links:
http://development.saphirion.com			(Change Logs, Downloads, etc.)
http://development.saphirion.com/experimental	(Android)
https://github.com/organizations/saphirion		(Documentations)

New World alpha release at
https://github.com/Geomol/World


- Added better networking using cURL library, libcurl (OS X and Linux)
- Added tasks incl.:
	- task! datatype
	- task-id! datatype
	- TASKS native function
	- task? and task-id? mezzanines

 - Task support for many functions incl. HELP, SOURCE, FIRST, SECOND, 
 PICK, COMPILED? and DISASM
	- KILL mezzanine to call TASKS/KILL

- Added inter-task communication using SEND and RECEIVE native functions
- Added support for messages to WAIT as: wait 'message

- Added preemptive multitasking using TASKS/TICKS to specify number 
of Virtual Machine instructions per task run (default is 200)

- Added timers for tasks triggered by WAIT native and READ native, 
when reading from url
- Task yield can be achieved by: wait 0
- Changed ;{ } comment syntax to ;( )
- Parens can now span several lines at the prompt
- Added system/console/paren
- Added support for pressing <Esc> to stop execution of main task

- Sending input via pipe to World started with a script will activate 
input without echo and without <tab>-completion etc.. (Not sure how 
and if this works under Windows.)
- Added support for picking 'Re and 'Im of complex numbers
- Better implementation of TRY

- New test versions of IF and EITHER, that can take other than block! 
arguments
- Added more tests

However, when writing something like:

a: []


into a file, you may not be totally sure that somebody does not LOAD 
your code and try to evaluate it twice....

let me try

Thanks a lot!! Tomorrow I'll try with salesforce, I hope this is 
the only problem.

Another question. On linux (linux mint debian) these segments of 
code are part of a larger program. I separated them out because they 
are causing trouble when I try to 'enface' them.


    set-net [[me-:-mydomain-:-net] mail.mydomain.net pop.mydomain.net none 
    none none "[me-:-mydomain-:-net]" "PASSWORD"]


    open [scheme: 'pop user: "[me-:-mydomain-:-net]" pass: "PASSWORD" host: 
    "mail.mydomain.net"]


The code encapsulates without errors, but when I run the program 
after 'enface' it gives the following errors:

    Set-Net not provided.

    ** Access Error: Invalid port spec: scheme pop user [me-:-mydomain-:-net] 
    pass PASSWORD host mail.mydomain.net

    ** Near: open [scheme: 'pop user: "[me-:-mydomain-:-net]" pass: "PASSWORD" 
    host: "mail.mydomain.net"]


I would like to be able to 'enface' these code snippets. Any suggestions 
as to how to fix this would be most welcome?

I was wrong. Simple programs like (print "Hello World") compile and 
execute, but programs with a lot of code compile but produce a series 
of errors when executed. I noticed a pattern. Wherever a word is 
not followed by ':' causes errors, examples below. Perhaps it's just 
this linux version of enface?

    stylize [
        fld80: field 80x28 font-size 17 white ivory center
        .......
    ]

produces the error:

    ** Script Error: stylize has no value
    ** Near: new-styles: stylize [
        fld80: field 80x28 font-size 17 white ivory center 
        fld400: field 400x28 font-size 17 whit...

I'll try this on windows when I have the opportunity.

Try each line above.  Mine gives 325 anagrams for "asdfg".  Yours 
is much faster, but only results in 120 anagrams for the same input 
string.

OK, I will try to write it as I think it should be both faster and 
less buggy.

@SWhite: I think it happens to all of us. If you know what that ONE 
LINE does try to do it in as many lines you prefer and then try to 
shrink those lines to only one and maybe you will end up with that 
ONE LINE !

Ah, R3. Let me try.

Try ++ idx instead of idx: idx + 1

I'll give ++ idx a try

try ? 

clear skip tail series -3

Thanks Graham,


I'm getting an error with ++ idx,  help ++ indicates incrementing 
a 'word, but I'm not understaning it
I'll try your suggestions

Thank you Geomol. I saw AltXML from Christopher Ross-Gill, I'll try 
both. Thanks.

try on one line in console:


>> str: "abcdef" end: find str "d" print end insert str "0" print 
end
def
cdef

but let's first try to help afsan, if his script is running he can 
improve it.

depends on the needs. I always try to detach the data sink from input 
logic. this way you can change your db backend very easy but of course 
everybody has it's own style in this.

pity Saphirion's excel dialect is not available for download anymore. 
Will try with Anton's old COMlib code ...

I think I should chime in here because I am one of those people who 
are not naturally inclined toward the programming arts. I see that 
many of you realize that the docs have to reach a vast audience from 
novice to expert. That will involve using different methods of presentaton 
and detail. How would you envision the database to look like. If 
we could create something pretty complete then I think all the desired 
above could be accomplished. For what it's worth I use the following:

The rebol dictionary - to look up words and usage I can't remember, 
try to decipher some functionality I need, hopefully find examples.

The View docs - to find out how things works and to remember how 
certain words work

Everything I can find on Parse - This is one subject that is all 
over the place.

Nick's tutorial and Reboltutorial - To learn about topical items 
that one can do in rebol such as sound and animation.

Altme - Asking all of you, especially Henrik, if I can do something 
and how or when something doesn't work.
Rebol.org - To find scripts that do things I need to do

Google - OK, this is generic and possibly obvious but when I am trying 
to figure something out, it's "Rebol ..."

The above items are my  most used resources and not exclusive. Note, 
for me the R3 docs were harder to navigate, especially a few years 
ago when I was looking at the GUI stuff. To me at least they seemed 
all over the place.


So, if one were to analyze that usage, it may help to develop something 
that can accomplish those different needs.

I'll try to get back later, to pull other doc links from the #Red 
group. In the meantime, here is one:

http://wiki.gigaspaces.com/wiki/display/XAP9/XAP+9.0+Documentation+Home


I like the upper right link categories: API docs, Forum, Blog, White 
Papers.

Let me try building with an older GCC to see if that changes anything.

AdrianS: re OpenGL. I see multiple ways here:

-try to HW accelerate the AGG graphics engine (currently used in 
R3) : I did some experiments which looks interesting. But the more 
you 'accelerate it' the more compatibility problems you get on different 
HW so it's about wighting the pros/cons.

-build completely OpenGL based engine (big task, brings lot of crossplatform/HW 
issues)


Otherwise it would be great if the current R3 graphics codebase is 
reviewed and some parts made more modular so different graphics engines/libraries 
are easier to plug-in. That should be not so hard work to do.

Ok, I'll try your forks. Thanks

Try running make make directly:
./r3-make ../src/tools/make-make.r 0.3.1

So better try running from a MinGW shell.

(Otherwise, if you absolutely don't want to use a MinGW shell, try 
using CD=.\ or CD=%CD%\ -- the trailing backslash is important.)

Henrik, now that you mention it, I do recall that.  But wouldn't 
it be even better if we could have access to the current AltME source 
code and just work from there?  Unfortunately, OpenME may not be 
the best name because there is a trojan virus with the same name.


It would be great if there were some basic instructions for people 
wanting to try out the current latest version of OpenME in the Readme 
of the OpenME project on github.

Andreas:  Sorry. I wasn't really commenting as much on Make-Doc-Pro 
as the impending realization that we are going to see a ton of forks 
branching off.  Make-Doc and Make-Doc-Pro have been associated in 
my mind with the "official" RT over the years. 


Hopefully the R3 team will be able to keep this thing focused.  Still 
not sure who those people are.  As long as Mark Down is pure Rebol, 
I suppose I don't have much preference.  Rebol has always taken the 
high road, so if MDP is better, I think we should stick with it. 
 Widespread adoption has never been as important as top quality better 
design.


If we continue to adopt whatever is widespread we'll end up losing 
everything that is better.  Amiga OS, Be OS, QNX Nutrino, etc.  All 
far better OS designs than Unix and Windows NT.  What do we end up 
with?  Unix and NT and of course the dreaded DOM (don't try to convince 
me that a flavor of Linux is anything more than a Unix OS).


So better is better.  If MDP is better, then we should adopt it, 
not because it is widespread, but because it is better.

we should probably try to make it clear for newcomers when we mean 
MakeDoc(2) vs Markdown, which some people might think MD refers to

Brian, I build the Red examples in both modes, so you can try out 
the effect if you want. MSDOS/console programs can open a window, 
but Windows/GUI apps don't seem to be capable of using stdout, at 
least not to a console they're started from

for example, synchronous operations are just a hack, they fail if 
you try to download a larger file as there is a time limit to the 
whole operation.

Since I didn't get any response, next try: What do you think about 
re-activating Rebol/Service?

Will you try to "sync" your changes with the "official" source in 
the future or let the sources diverge?

I'll try to read the latest article soon Ladislav, though my scheule 
is packed right now. Thanks for posting it.

Is there a document anywhere that outlines the differences between 
R2 and R3 for those porting/writing apps now?  I'm thinking that 
those of us still using R2 should try and stick to something that 
will be compatible with R3.

for embedded modules, it could be as simple as dropping your module 
in src/mezz/, including its filename in src/mezz/boot-files.r and 
doing a full rebuild (including `prep`) after that. didn't try yet, 
though.

Did not know that program, I will give it a try soon. Thank you for 
the link Graham!

Some people holds to the saying "if it works for you well, dont try 
to fix it"...I belong to them and don't update apps just because 
'update is available'. I got bitten by updating to 'newer and better' 
version many times.

Something is wrong in all this.


I try to see software as tiny bits and pieces, each doing a certain 
task. Like very simple Lego building blocks. So each piece takes 
some input (like a function does) and produces an output. If that 
piece needs to be updated, then it's because it has some error, or 
that there is a faster way to do, what it already does. If new building 
blocks arrive, because new software needs them, then they're just 
added to the system.


If that is done right, then updating should be very simple and only 
include very little data to be transfered to my system.