AltME groups: search

here is a tool I built which allows one to set or remove the "always 
on top" flag of any opened window, dynamically.


http://www.pointillistic.com/open-REBOL/moa/files/window-controler.exe


when you start the app, it lists all windows, using both exe and 
window title, depending on what is viable for that window.  if you 
click on the title, that window becomes always on top (immediately), 
and if you press on the X besides it, it loose that flag. 


just close and re-open to update the window list... simple and stupid, 
but reallly useful.

(its not a rebol app, its built using C#, unfortunately)

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.

Please put in your agenda the weekend of saturday the 26th and sunday 
the 27th of january. Then we will have the DevCon 2013 in De War 
'Place for Pioneers' in Amersfoort, the Netherlands. This year we 
will combine the Syllable Winter Conference with the DevCon, Conference 
for the REBOL Programming Language Family, as they have much overlap. 
Presentations will be done by Nenad Rakocevic and Kaj de Vos. We 
are open to other guest speakers and presentations? Entrance is free, 
but donations are very much appreciated. Keep an eye on this website:
http://devcon.esperconsultancy.nl/(will be updated soon)
and this Twitter-account:
https://twitter.com/devc0n

It is easily reachable by airplane (Schiphol, Amsterdam Airport) 
and by international trains. 

It's an old matches factory marked 'Spullenmannen', which is now 
being used by artists.

DE WAR


DE WAR is a breeding ground for art, technology and sustainability 
in Amersfoort, and is host to  a wide range of activities. Since 
2002 the Spullenlab has been the headquarters of Spullenmannen, an 
artists\u2019 collective making theatre, installations, visual art, 
and purposeless contraptions. A  shared office space was set up in 
2006, with different working places, a meeting room, and other facilities 
shared by a number of cultural enterpreneurs. The OpenTOKO workshops 
started in 2008, as a series of \u2019open knowledge\u2019 workshops 
on the connection between art and technology. Since 2010, DE WAR 
has also been housing FabLab Amersfoort, TransitieLab, and Studium 
Generale Amersfoort.  Moreover, a performing space for small theatre 
productions has been set up in 2011.


DE WAR has been established in the old match factory on the river 
Eem.  The factory complex dating back in 1881 has, besides from other 
activities, operated as a production facility of the Dutch colour 
dye industry, and is also known by the name of its last owner, Warner 
Jenkinson. Nowadays owned by the municipality of Amersfoort,  the 
factory complex faces an uncertain future, either to be demolished 
or to be renovated. Besides DE WAR several other offices and ateliers 
are housed within the same factory complex.


DE WAR is initiative  of PLAN B, at the address KLEINE KOPPEL 40, 
3812 PH in Amersfoort,

A pull request to mainline Red has been submitted:

I posted a short primer for CGI with current Rebol 3 releases as 
answer to a question on Stack Overflow:


http://stackoverflow.com/questions/14123618/how-to-write-a-hello-world-cgi-with-rebol-3


If you want to play with R3 and CGI but don't know how, that should 
get you started.

I've started a file common.red for common definitions for Red:
http://red.esperconsultancy.nl/Red-common/dir?ci=tip

Notably, there's marshalling in there for program arguments.

ARGS-COUNT gives you the number of arguments, including the program 
file name, like system/args-count in Red/System.

ARGUMENTS gives a block of string arguments, excluding the program 
file name, or NONE, like ARGS in Boron.
ARGUMENT 0 gives the program file name, like argv[0] in C.

It still uses a Red/System callback for processing result rows, so 
that's not done on the Red level yet. That's next

Robert : A gotcha appeared in your last post about the oneline-prime-numbers.r 
script the correct address should include as its filename the following 
: oneliner-prime-numbers.r instead of the submitted one. I then copy-pasted 
the content of the script in the console and here is what I got : 
97 89 ...   5 3  which is correct !  Thanks again !

I'm happy to announce a website for downloads of (unofficial) Rebol 
3 executables:

http://www.rebolsource.net/


Currently, binaries for Linux, OSX, and Win32 are created fully automatically, 
from Carl's latest R3 sources. So whenever Carl updates his Github 
repository, those binaries will be updated automatically (typically 
within ~10 minutes) as well.

I hope this makes it easier to partake in R3 development without 
going through the hassles of setting up a build environment first.

I'm happy to announce our next Android release. Cyphre did a great 
job and pushed the port further forward. Here are the highlights 
of the new release:

-added full file access
-added networking
-added console user input (ASK etc. works)
-improved threading (at the app level, not R3)
-misc small internal changes in the console code


With this it's possible to run R3 chat on your Android phone :-) 
Here is how to do it:

make-dir %/mnt/sdcard/r3/
change-dir %/mnt/sdcard/r3/
chat


The paths might be a bit different on your device. The trick is to 
use the /sdcard path and put everything below it.

The link is as always:

http://development.saphirion.com/experimental/R3droid.apk

Again, thanks to all who made a donation for this project!

I've started a Red counterpart of the Red/System binding with the 
C library:
http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip


I'll implement C library bindings there as far as they're useful 
at the Red level. So far there's a simple CALL implementation.

There's a WAIT refinement, but like in R3, this simple CALL always 
waits, and there are no other refinements yet

I've extended the Red interpreter console with the ability to load 
and run a script file, given as an optional program argument. It 
also has CALL now, so you can run simple programs with the intepreter 
and script the operating system.


As before, ready built binaries are available in the test repository, 
in */Red/console-pro:
http://archives.esperconsultancy.nl/Red-test/dir?ci=tip

After executing a script, you still end up in the console, to help 
with debugging. To prevent this, end the script with QUIT

It's pretty horrible what one has to do to hammer the chaotic C library 
API into a neat REBOL model

RANDOM has /seed. It only works on integers so far. As a bonus, random/seed/secure 
seeds the pseudo-random number generator with a clock value, so the 
start of the sequence is really random

now gives a string with date and time, but using  the refinements 
dont't give back a result.
This is on Windows XP

I've added a download/update script for the source code of the Red 
bindings to the test repository:
http://red.esperconsultancy.nl/Red-test/dir?ci=tip

I made simple implementations of READ and WRITE for Red. They need 
to be included from a new file input-output.red:
http://red.esperconsultancy.nl/Red-common/dir?ci=tip

It's now possible to read and write text files with Red.

I've updated the console-pro interpreter in */Red/:
http://red.esperconsultancy.nl/Red-test/dir?ci=tip

Red doesn't have a file! type yet, so the file names need to be passed 
as strings for now

There's no error! yet, either, so READ returns NONE on error. WRITE 
returns a true/false value indicating success

Nick Antonaccio made a beautiful advanced guide: http://re-bol.com/business_programming.html
go to see it.

This is not really a Red binding for the cURL library yet. I didn't 
have to add any Red code, because the extra functionality is handled 
in the corresponding Red/System functions, so it's supported at both 
levels

I have just created http://rebol.informe.com/portal.html, there 
is a forum, a wiki, a blog and a gallery. Do you think it can be 
the rebol community portal?

Carl just posted a new blog entry at http://www.rebol.com/article/0527.html

I've got a preliminary Red binding and dialect working for GTK+:
http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip

You can also give a window title like in R2:

Once rebol went open source and decided it's time to return to rebol, 
it was rather frustrating for me to find resources about rebol. I'd 
like to create such a page for other people's convenience. Should 
it be reboler.com or rebolista.com or anything else? The page will 
be a compilation of resources that will help newcomers get an idea 
of what rebol is all about and how to get started, such as: where 
to get the latest news, relevant contributors, blogs, important libraries, 
etc. I'd like to register the domain tonight and have the page ready 
in a couple of weeks. Not a big deal - just a quick reference at 
least for myself. Please suggest name and stuff to put on the page. 
Congrats to the community for sticking to rebol thru the quiet times 
- I did not.

Is like that says: 
.
 is not a command

Probably it is a missed file on your fork. I didn't build R3 on Windows 
yet. Cyphre can send that file I think.

I posted an old binary several days ago. Let me build a fresh one.

MaxV, are you running the above from a MinGW shell?

Or just from a plain cmd.exe?

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

We could use a separate group to talk about building and porting 
R3. This group is getting a bit polluted.

I have a couple significant changes to make to TRANSCODE. Can all 
interested parties please review http://issue.cc/r3/1915and http://issue.cc/r3/1916
and comment what you think? AFIAK I have used TRANSCODE more than 
anyone else, but we're at the point where more opinions are needed. 
It's low-level, so most people won't be affected by this. They're 
not syntax changes, they're changes in its external behavior.

Sorry, but I don't think so. 

A good wiki is a wiki where is easy to register and edit. The one 
on the Rebol.com is not a good wiki.

People will register and use GitHub, so a wiki must be on GitHub. 

If youlike, you may have an "offical" wiki in Rebol, but a living 
wiki is the GitHub.

I can copy all rebol wiki on GitHub, you you want; but please reactivate 
the GitHub wiki!

Don't do the same errors of Rebol 2, where there was a wall between 
people and reboltech.

MaxV: I will gladly let it to Carl to sort out. He was reshaping 
a wiki for nearly 3 months, and there are something like 75K pages 
of content. It is also kind of autogenerated/automated. So - do you 
want to do many things manually?

(a little bit fo wget, a little bit of rebol and my will)

Getting a implicit declaration warning while compiling (Ubuntu64) 
for strdup() line 86 and free() line 88 in src/os/posix/dev-stdio.c
Adding includes (stdlib.h and string.h) clears this.

I needed months about Rebol to understand what is altme and how to 
subscribe. Altme is not good. Rebol3 needs to be open also for documentation, 
needs also a public forum, linke Nick one. Please reopen the GitHub 
forum, Rebol 3 needs also common/occaional people tha wants to contribute.

This is open source, otherwise it will not reach a big audience.

MaxV - that's an old song - Altme will be used by those, who want 
to use it, easy as that, no? Yes, public forum should be available, 
but please let's ppl use what they like or are used to. Some of us 
simply prefer IM nature, so we will either use Altme or IRC. That 
does not mean, that we will not participate in a forum, or mailing 
list. I can bet, that if ML was still active, many of us here would 
contribute. I quite miss ML a bit :-)

I want that people will continue to use what they prefer, but Rebol 
misses all the common tools of open projects:
- public forum
- public wiki

The way to eneter in connection with others is too complicated by 
now. GitHub is making all a little easy, so why closing GitHub wiki? 
Leave it open, people will decide if usinig GitHub Wiki or the old 
complicated way to enter in the rebol community.

I wrote the page to build Rebol3 with mingw (it's complicated), and 
now it disappered! Someone who has a Mac could write his way to bouild 
that, and nobody heeds to ask to rebol.com, nobody has to prove to 
be an expert about Rebol.

Max, the problem is that most web tools actually suck... not because 
their developpers are bad... but because the web, as a platform sucks... 
in all regards.   its slow, super complex, apps break up every other 
month, and even the basic framework on which the web is layers was 
NEVER meant to be used like it, so even that is corrupted to start 
with.  Also, the apps we use keep changing from under our feet, which 
as a user we have NO control, and it gets very tiresome... it seems 
like every other time I log on to any of the bigger web sites, its 
changed, and I'm lost... again.


I have not seen a single altme-like product which I could chat in 
**real-time** with many people in groups as we do here.   its always 
either super slow, very slugish, insanely complex or insanely dumb. 
 


The only platform which has some appeal so far is the Stack Overflow 
engine, which has a pretty good architecture... but man would it 
be sooo much better if it wasn't built over web technologies...

The win32 builds are working. We have a single EXE including View. 
Will be published too.

Does anyone know if it would be possible to have Rebol included in 
Ubuntu now that it's open? I don't mean just to make a package available, 
but to have it be installed in the base system.

Maxim, I agree that AltME is a great platform, but it could be much 
better.  For instance, things like the Calendar and Checklists that 
work OK, but are not really polished and feature-rich yet.  But I 
think AltME could be made to look a lot better by borrowing from 
some concepts seen in Facebook and Google+, and maybe even have an 
almost-real-time bi-directional link to a web forum for people who 
need to access the groups from a web browser.


Another thing that I would really prefer would be to allow connection 
to multiple AltME worlds from within a single AltME window.


Hmm...if AltME was also open-sourced, we could start adding these 
features!  I have a more feature-rich calendar I could add right 
away. ;-)

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.

Bo, possibly, but as I see it, AltME has some specific design flaws, 
such as dependency on world servers we have no control over. We decided 
not to let a trojan decide whether the name should be used or not.

For me Altme is almost unusable if not used on Windows. I miss a 
way how to customize it. Just 2 font size versions and hardcoded 
font is a big problem.

Andreas, do you know what a scripting language needs to have in order 
to be included by default? Is it just a matter of popularity?

Bo, along with open sourcing AltME, the R3 chat would be good to 
have opened as well. This has been asked of Carl on the blog (more 
than once), but the question keeps being ignored. Almost as if on 
purpose - might be possible that Carl is trying to figure out a way 
to monetize that side of Rebol.

I've had a number of face-to-face conversations with Carl recently, 
and I don't get that feeling at all.  I'm sure it's just a matter 
of time - Carl is highly pressed for time in his current job.  Plus, 
now he is spending a lot of time looking over the R3 code changes 
on git and merging them.

But I'm not sure Ubuntu has a published or defined policy for what's 
included by default in  the base or desktop installations. I think 
it's a decision made by a board.

JPG support in R3 would be amazing, even though I know it would bloat 
the size of the executable by a significant amount.  Maybe it could 
be available as a plug-in so if you don't need JPG support, you don't 
have to sacrifice the space.

I've got a question about using MakeDoc/MakeDoc Pro vs Markdown/MultiMarkdown. 
Are there significant advantages with MakeDoc that outweigh going 
with Markdown which seems to be the defacto standard for lightweight 
markup? I guess when MakeDoc first came out it was pretty unique, 
but if you were to need this kind of tool today wouldn't it make 
sense to use something with wider adoption?

On a pure feature basis, I think make-doc-pro somewhat surpasses 
plain Markdown. I fear you'll have to decide on your own if you need 
something MDP adds.

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.

MDP struggles with markdown syntax. We talked about rewriting it 
with a cleaner implementation.

Henrik: So MDP was intended to parse Markdown syntax to a certain 
degree?

Robert:  Do it.  Make MDP cleaner.  Then we make a Wiki that uses 
the cleaner MDP.  Or fix MarkDown so it is better than MDP.

AdrianS:  That is a better question.  What have we learned about 
the approach taken by MDP versus MarkDown.  I am personally much 
more inline with the approach taken by MDP.  It hasn't been attended 
to in quite some time.

The MDP code is quite a bit a mess. So, perhaps it's better to reuse 
the name as mark-down-pro

Well, if the Markdown syntax is too limited, there's also MultiMarkdown 
which has the benefit of being a superset of Markdown.

So what would it take to make a Make Doc that can scale?

Scot, it has to be rewritten. The code is a mess. So, we could start 
with a pure markdown parser and build on top of that.

That's the whole point of dialects.  MDP is a dialect of Rebol.  
It needs attention.

Whew!  Not being clear.  The DOM is the result of taking a simple 
Hypertext engine and trying to turn it into a application architecture. 
 Everyone adopted it because it was widespread, not because it was 
good at appications.

MDP is a dialect of Rebol.  It takes advantage of what Rebol does 
well.  Is Markdown a dialect of Rebol.  Is the syntax optimized to 
play well with rebol?  That is my question.  If not then we need 
somethign that plays well with REBOL.  We can alway output MarkDown 
if somebody really wants it.

MDP is string parsed
 - and this part is actually a big mess.

I've spent a lot of time with MDP, written a whole distributed application 
with pages based upon the principles of MDP.  The biggest mess in 
MDP is the need to make HTML pages, which is a fossil and pretty 
awful, but widespread.  People need HTML so we output that.  People 
may want PDF, or RTF or Postscript or MarkDown, or whatever.  Those 
parts will always be a mess because the formats of all those outputs 
are a mess.

I've also spent quite a lot of time with MDP as well building now 
around 2 megabytes of manuals with it, and I spent some time adding 
new features to it. I wanted to add a glossary feature, but it's 
quite strained with what we can do now. The HTML part is not so bad. 
The line parser is much worse, both because we are running out of 
space for sensible inline rules (which all are one-char and markdown 
doesn't have this limitation), and the code itself is not very well 
organized.

I would gladly toss out the MDP parser for a clean markdown parser.

Gabriele also did a variation for Qtask. Not sure about compatibility, 
but it would be more modern, and likely a very clean implementation.

It is a superset though, iirc -- any MD(2) document can be processed 
by MDP.

MDP is a dialect of Rebol.

 - actually, it is a dialect of Rebol exactly like C, i.e., not at 
 all

To clarify, a dialect needs to be REBOL loadable data, not just a 
string that is parsed.

Pekr, R2's console was GUI on Windows, not a real console app. Carl 
had wanted to make an R3 console like R2's but better, in the R3 
GUI. We just never got around to it.

Carl's blog was about the inline text-mode problem, trying to solve 
the open-a-window bug. That wasn't about the planned GUI, it was 
about fixing the existing console.

brian, iirc, it was about inability to have view exe being used as 
real fonsole. Carl did not find a way of how to do it ...

If you are talking about the existing R3 console, the problem was 
that he couldn't make a real console-mode R3 program without losing 
functionality that he only knew how to support in GUI-mode programs, 
and he couldn't make a GUI-mode app use the Windows console without 
allocating its own console window, which lost all of the advantages. 
It's not to say that this can't be done, just that noone who had 
the interest and ability to do this had made the effort, because 
it was low-priority for the contributors at the time. With more contributors 
now, perhaps this will get fixed.

Hmm, maybe the author of ConEmu should be approached about this - 
maybe he'd be interested in order to get a scripting language included.

http://code.google.com/p/conemu-maximus5/

Right. But supposedly changing the app to console-mode like that 
caused other problems, which I don't remember because I don't have 
a link to the blog in question.

Also, is it possible to just compile it that way in the first place? 
And is it possible for such an app to bring up a GUI, say so that 
it can run console scripts and GUI scripts?

Such an app can bring up a GUI, yes.


However, it will always pop up a console window (which can be closed 
immediately, but this will result in the "console flashing" effect 
some dislike).

Yes, we should built it that way in the first place. We only recently 
added building in GUI mode, to avoid a crash with console mode binaries 
when launched from shells other than cmd.exe. (Another bug that needs 
fixing).

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

OK, but I really want to reserve the term "MSDOS" for programs that 
actually run on MSDOS, a still-common embedded systems OS.

First baby steps towards R3 64-bit builds:
https://github.com/rebol/r3/issues/45#issuecomment-11746288


TL;DR: We are slowly getting to a foundation for more serious 64-bit 
work.

I also have tested on a CPU where misalignment penalties are quite 
heavy. Trying this on different CPUs might lead to quite different 
results.

Running on a misalignment-tolerant machine, the unoptimised 64b binary 
is actually slightly faster than the unoptimised 32b binary.

Still a useless "user level" metric, at the moment :)

I use .r for scripts that are expected to run in R2 or R3, .r2 for 
R2-only scripts and .r3 for R3-only scripts. However, a lot of my 
scripts are .cmd and call themselves with the appropriate Rebol.

I use .cmd instead of .bat because the tricks you use to call Rebol 
safely require cmd.exe (in NT-based Windows) and won't work with 
command.com (in Win9x/Me). It's not necessary to use .cmd for this, 
but it's a good reminder.