AltME groups: search

Yes, it managed only a single page, and yes, the hard part is flow 
of paragraphs across pages, not generating multiple pages in itself.

and I hope DRAW or similar will be available for Red.

Kaj - sounds like sure thing but also news for me :-) AFAIK you and 
Doc were not much interested in bringing View to Red. Well, unless 
you mean DRAW equivalent done using different engine ...

The exports of regular modules are collected in the lib context (the 
"runtime library") when they are initially imported. All potential 
conflicts between exports of different modules, any overrides that 
need to be done when you upgrade a module or use another module to 
make changes, these are all managed in lib. All modules import stuff 
from lib. You can tell if a module is loaded by checking for it by 
name, and for that matter even the module system itself can only 
tell if a module is imported by checking for it by name.

Private

 modules were a side effect of the module name being optional. If 
 a module doesn't have a name, you can't check for whether it is already 
 loaded, so you have to load it again every time it is requested. 
 The module itself can't even tell if it was loaded before, so it 
 can't know whether it needs to resolve conflicts between itself and 
 other instances of itself. That makes it basically unsafe to have 
 an unnamed module export to lib. So instead, we skip the lib middleman 
 and import those exports directly into the target module or user 
 context, which makes the unnamed module effectively owned by that 
 target, a "private" module.


We found this facility useful enough that we added an explicit option 
to make it private (options: [private]). That makes it possible to 
have a named private module, which has some interesting abilities 
just from having a name. Having a name means that you can have the 
module load only once, and being private means that if you want to 
use its exports you have to import the module explicitly, so combined 
it means an explicitly accessed module that can share resources with 
other targets that also explicitly import the same module.

one big difference is that slim doesn't bind to a global library 
area.   each module is completely shielded and imports "on its own". 
 

its a hierarchical system without namespaces.

but I'll probably be using modules as the basic construct for slim 
R3, instead of objects... in my model, it might not really matter, 
I manage access/biding to/from modules actually altering and expanding 
the module when it is being loaded.


the data being sent to slim isn't executed directly, the block is 
sent to a manager, which does some binding and security stuff first.

anyhow... Brian and I will eventually get to actually implementing 
the R3 module /  slim model sometime this year.  I don't want to 
start a philosophical debate here.  :-)

I mean, I will implement, based on discussions and tests I'll have 
with Brian, to understand the intricasies of why/how modules are 
as they are now.

Brian, is there a doc that has your above comments in it? http://www.rebol.net/wiki/Module_Design_Details
looks like it covers a lot of ground, but I don't know if you wrote 
it, and whether it has some of the design notes included. I think 
they're very useful and informative.

And it should have links to Slim and other alternatives.

Gregg, I wrote that doc (and forgot the link, thanks), but it needs 
updating. It is about one or two rewrites behind.

Hard to keep up, and keep track, with everything. :-)

Maxim, slim modules are like R3's named private isolated modules. 
And the equivalent of the "global library area" in R2 is system/words, 
so if you have any code that binds to or imports from system/words 
then you have the equivalent of lib.

Btw, module systems like slim are the reason why I changed the underspecified 
parts of Carl's original module system into features that you might 
find familiar. It wasn't based on slim specifically, or even Gabriele's 
system, but an earlier module system that I wrote for the Apache 
module version of R2 back in 1999. It had similar characteristics 
to your module systems because I had come from strong modular languages 
like Oberon and Delphi, and because I had to solve some of the same 
problems you did.

Most of the characteristics of R3's module system are the result 
of combining the system model of R3, the binding model of Rebol, 
and Carl's goal of simplifying things for developers not familiar 
to modular programming. Every bit of syntax that Carl wanted to be 
optional or minimal in order to make things easier for end-developers 
had semantic consequences. The runtime library lib, for instance, 
is the result of having to manage a modular multithreading system 
that can be used by scripts that can be written as if R3 were single-tasking 
and monolithic like R2. Doing that requires that modules have certain 
characteristics (such as a name).

If R3's system model changes, that *would* affect the semantic model 
of modules. Right now the task! model is a bit underspecified and 
extremely underimplemented, and the module system is built around 
Carl's proposed tasking behavior. If that changes, as it might since 
Carl's proposal isn't fully implemented yet and is incomplete even 
in spec, then we might have to tweak the semantic model of modules 
accordingly.

And, BTW, Andreas, regarding the 15 vs 17 digits: I think that we 
can give in easily in this case, just put 

system/options/decimal-digits: 17


to your rebol.r and MOLD decimal will behave exactly like MOLD/ALL 
decimal.

https://github.com/gchiu/Rebol3/blob/master/protocols/prot-send.r
and with the latest prot-smtp.r can now send attachments .. I tried 
a 60Mb one and it went fine.


same syntax as in R2

send/attach [carl-:-rebol-:-com] "Carl, need to remove the spam from blog 
comments" %attachment.exe

And [carl-:-rebol-:-com] is not Carl's email address any longer. :-)

I know what Carl uses as his email and yes, I knew it wasn't what 
I wrote above.  Last time I looked he had an s at the end of this 
name.

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.

This is a public group, MaxV! I assume that your action will force 
Carl to change his address and not give it to you...

As a matter of practice I generally share contact information for 
other people ONLY through individual private channels and NEVER on 
email.  Just a thought.

Has anyone had any contact with Steven Solie about the Amiga R3 build? 
 I see from his site http://solie.ca/that in 2010/11/23 he had R3-GUI 
up and running.

Since he didn't ask about exporting and the 'private option, I didn't 
mention such issues.

I believe you can email the stackoverflow admins, Brian, and they 
can transfer stats to your new account.

For completeness I've asked the question about exporting and private

SO didn't previously require you to create an account or even provide 
an email address to answer questions. Since I didn't care about SO, 
I didn't bother to make an account. Now they require an email address, 
and use that email address to determine who you are. Creating an 
account is almost an extra, just a way to give you a nickname and 
profile info.

You need a reputation of at least 20 to use the SO chat system ... 
and with ticks, you're already there.

Also, SO has an API so we can potentially grab all the Rebol tagged 
questions and also host them on rebol.org if we need to.  It's not 
stuck in the SO system

I can imagine that if you want to have a module somehow negitiate 
some passwords and don't want them to leak, or some other security 
issue, you might want to write the module to be isolated. Also, if 
Maxim wanted to port slim to R3, or someone wanted to port Qtask 
(I forgot what it's called now, sorry) or some other code written 
for Gabriele's PowerMezz modules to R3, they might want to use named, 
private isolated modules.

One interesting use of isolated modules is to use IMPORT/no-share 
to force a module to load isolated even if it wasn't written for 
that. This is a way to use modules that are too messily written, 
that make too many unnecessary changes, and try to limit the mess 
a bit.

Id depends, how fast is CALL, but especially on Linux, there should 
be very little overhead. E.g. I found out, that PHP, for Unicode 
conversions, just calls iconv. If you don't call the function in 
loop, I would go the CALL way, with tiny wrapper parsing results 
back. But - CALL on R3 misses /output and /wait ...

I'm getting metaphorically killed by the FOREACH function blowing 
a system assertion 1207 periodically. I'm trying to process a couple 
thousand files and it's dying before it's finished. The script will 
need to be rewritten to call another R3 instance per file, just to 
make sure that it completes.

There's only so much of the process that can be rewritten to uzse 
FORALL. And of course MAP-EACH is getting hit by the same bug.

and it's not a memory leak?

I'm going to switch the rest of the code to non-rebinding loops and 
see if that helps.

And it's an emergency too, we really need that analysis.

It might be easier. It's parsing, and uses MAP-EACH a lot, and there's 
a bug in MAP-EACH in R2 (that's my fault, sorry), but that is one 
approach I'll have to consider.

I mean, can you quickly run a test binary and see if things improve?

Apparently I can make it last longer by using the *EACH functions 
less., switching to loops that don't allocate contexts. However, 
I create objects to store the data, so those eventually cause the 
crash. Still repeatable, so it's probably happening after allocating 
a certain number of objects/contexts. It acts identically on 32bit 
and 64bit Win7, crashing at the same point in the process.

Ladislav, document it then. It's too useful to drop. And according 
to the docs you couldn't use get-words in SET block at all, so I 
never wrote code that had them. SET block with anything other than 
word! is rare, at least until R3 added FUNCT, which makes set-words 
very common.

Not really. It would only be a problem if people started using this 
and someone wanted to remove the feature.

It hasn't been a problem so far, and there's nothing wrong with the 
code. This code:
    set [:get-word] [word]
is currently equivalent to this code in R2:
    get-word: get 'word

Agreed, and speaking of which I also noticed RETURN/redo, which even 
has a visible option and I didn't notice it before. It's a general-purpose 
function trampoline, and as hard as I try I haven't run out of new 
ideas for how to use it.

And, it does break through the APPLY security trick, which I might 
want to review some code about. I think that needs a ticket.
>> apply does [return/redo :add] [1 1] 1 1
== 2

If you have any code that uses SET block! block! or SET object! block!, 
and the values block might possibly have unset values in it, then 
*your code is buggy*. If you want the unset values to be assigned, 
you should be using SET/any. If you want the unset values to trigger 
errors (a fair assumption, since you're using SET instead of SET/any), 
those errors are currently *not* being triggered because of a bug 
in R3. Either way, check your code.

If you're using SET block! block! or SET object! block! in cases 
where you can get unset values and are expecting errors to be triggered, 
then your code is buggy until this is fixed. If you are expecting 
it to *not* trigger errors, then your code will be buggy until you 
change to using SET/any - it's just accidentally working until this 
is fixed, and then will properly not work after it is fixed.

So there's no short list (i.e. not something that goes into the kind 
of detail Bindology covers) of documented changes? In the meantime 
I asked this on StackOverflow:

http://stackoverflow.com/questions/14818324/is-there-a-summary-of-the-differences-in-binding-behaviour-between-rebol-2-and-3

It can do more than that, but that's the basics. And you can have 
words as well, not just numbers.

If you are writing tests, there are a few things you should know 
about the behavior-as-designed of REWORD:

- values is a collection of key/value pairs, like a map. If a block, 
no reduce is done, it's just data.

- Keys are converted to strings if they aren't strings already, and 
are considered equivalent if their strings are equivalent.

- Empty strings don't count, but the check for empty keys is done 
after the string conversion so none is not empty, it's "none".
- If a value is unset or none, the key/value pair is ignored.

- If the same key is specified more than once, the last value of 
that key takes precedence.

- After all of the key/value conflicts are resolved, if there are 
ambiguities between keys (like "ab" vs. "a") then the first key gets 
priority. That means that you probably want to put the longer key 
first, same as with PARSE alternates.


If we're writing tests, we need to write tests for all of those. 
And we probably need tests because it was intended that REWORD be 
converted to a native for speed after we settled on its behavior. 
The current REWORD works as designed, but we might want to tweak 
the design after further discussion.

Oh, and if a value is a function, that function will be called every 
time with an argument of the string at the position of the escape. 
We need to test for that too. This makes *really* flexible replacement 
possible.

just cut and past - almost

And edit, because SO is much better for this kind of thing. And maybe 
provide a little context for why the function exists at all.

And that calls for a downvote? Well, that's a great incentive to 
ask questions.

One of the problems of SO (generally, not in this case I hope) is 
that the asker chooses which answer is the accepted one, not someone 
who knows enough about the situation to know which answer is better. 
So I tend to try to work around this social bug by answering earlier 
to discourage less-informed people from trying to answer badly. In 
this case, I have to answer because I'm the one who designed and 
wrote the function, at Carl's request.

AdrianS: I don't think BrianH downvoted your question. But whoever 
did (I didn't either) probably has a point, as it's a very broad 
and open question. SO generally prefers more specific questions based 
on actual problems, so that it's reasonably clear when an answer 
is practical.

I didn't downvote it, and I might have enough reputation to rewrite 
it so it's a better question. Or request that Fork does, because 
he certainly does.

From now on, I'll have to be careful in asking question where you're 
the intended answerer since you go overboard in the details. It might 
makes sense in some cases to just put a summary and leave a note 
that there's more to be said somewhere down the road.

Well, we've been encouraged lately to put these up, and we can point 
other pages to SO if need be, or copy the answers to a documentation 
page when we have those. I mostly see it as a place to write short 
documentary articles in a Q&A format, much like Yahoo answers is 
a place to write jokes in Q&A format.

yes, the problem is MINGW is using own 'custom' version of MAKE called 
"mingw32-make.exe" which doesn't behave well on the R3 makefile (at 
least from my experience).
So my Windows setup is:
-I installed CodeBlocks with MINGW support

-then I installed MSYS and extracted only 'necessary' files from 
MSYS/bin folder and put it into CodeBlocks\msys\bin\ folder
-then I deleted the MSYS instalation to not have bloat on my disk

-I set paths to CodeBlocks\MinGW\bin CodeBlocks\msys\bin in the WIndows 
console

-from now I can  just type MAKE ALL in the CMD console and R3 builds 
fine


Just in case here is the list of "necessary" MSYS/bin files I extracted 
(around 3MB of data):

cp.exe
make.exe
mkdir.exe
msys-1.0.dll
msys-iconv-2.dll
msys-intl-8.dll
msys-regex-1.dll
msys-termcap-0.dll
rm.exe
rmdir.exe
sh.exe

If you wantt I can put the "minimal" MSYS bin folder into a zip archive 
so you can download it and just copy it into your codeblocks instalation...

I did the same for Ladislav and it worked for him well AFAIK.

just unpack it and copy to <your path to codeblocks>/CodeBlocks/ 
main dir

Actually, to keep things as simple as possible for people, all you 
need is Code::Blocks, the CB project file and a slightly modified 
make-make.r that is soon to be checked in by Andreas (or which I 
could provide). Then, you can build from CB (and debug), navigate 
your C source propertly, etc.

And starting first with the basics I need (/wait + /input /output 
/error). (So no full scheme & async at the start.)

Great news, Andreas! Linux is good for me and basic input/output 
is enough too. Just what I need.

I discovered some interesting PARSE functionality, which I have not 
known about before. TO and THRU with integer arguments seem to do 
absolute positioning:

>> parse "abcd" ["abc" to 2 "bcd"]
== true


Anyone seen this before? I added a CC ticket as a reminder to document 
it (http://issue.cc/r3/1964) -- if anyone knows about a place where 
this is documented already, I'd be happy about a pointer.

(And it does so in R2 as well, so I may have picked the wrong group.)

Ladislav: thanks, forgot to list that. And it's at least a place 
where we can add it right away.

Well, that behavior seems like an undocumented feature. And a useful 
one :)

I find that becomes quite assymetric in use.  if TO is going to change 
behaviors... relative in some cases and absolute in others... using 
weird datatype conventions (which seem to be completely different 
from the rest) then I'd rather have a new Absolute keyword which 
works just like to on All datatypes.

But this was pretty much the first thing I started looking at, which 
already lead me down the rabbit hole of testing it in R2 and R3, 
looking for documentation, filing a documentation request against 
R3 and discovering and reporting a bug against R3 (and I'll probably 
continue down the hole and fix that bug). So I didn't get much further 
towards other goodies, yet :)

Guys, was there any discussion about the COMPRESS/DECOMPRESS natives 
in R3? Do we really need these functions to use some 'custom' compression 
format that noone in the world uses and when it is based on zlib 
anyway? Wouldn't be better to change this in R3 and use for example 
ZIP format? What do you think?

I remember Carl saying the custom format is more efficient but I 
tried to compress couple binary or text files to compare with ZIPped 
results and I don't see any significant difference that would be 
worth the current format incompatibility.

Henrik, I was more thinking to rip the old zlib code out of Rebol 
and put there some more actual(or even smaller) implementation (latest 
zlib or miniz etc.)

Pekr, I don't think it's the same thing, plain and simple.

Would you not want a single, universal way to store and retrieve 
application state from disk? ZIP does not do that.

Well, then I am wrong, ok. Not sure .rip format was anything in common 
with app state serialisation. I thought it was just plain and simple 
packaging mechanism - having a header, and binary container for compressed 
app modules/scripts ...

(and if it turns out, that it was not the goal with .rip, then the 
goal should be changed to do this)

If you want something modern, add support for LZMA compression. And 
please don't mix compress with zip - zip is high level, compress 
should be low-level function (idealy supporting more formats)

Storing bindings, managing upgrades of data structures, structural 
checks and error handlign, type assertion, etc.

as far as i know, zip files allow prefix payload, so you can put 
stuff before the actual .zip file starts... just like REBOL allows 
stuff before the header.   I've seen a demo of a single file which 
is  an .exe,  .pdf ,  and .zip all at the same  time!

Old Bug, New Bug, Red Bug, Blue Bug?


I'm using the ARM build from rebolsource.net and getting the following 
unexpected behavior:

>> template: read %template.html


It outputs template as if it was a binary file, although it is plain 
text.

The build date on the package was 24-Jan-2013.

Cyphre, Rebol compression is the same as zip deflate, but it's not 
the compressed part that's more efficient, it's the headers. The 
zip format has some fairly extensive headers, and Rebol compression 
doesn't. We do need compression to support compressed scripts though, 
so we need something. That doesn't mean we can't have something more 
flexible, and if we stick to what we can get from zlib (since we're 
linking it anyway) we can get this flexibility nearly for free.

The ZIP format is supposed to be like a directory/file structure. 
I would rather have it supported as a zip:// port scheme, like file:// 
is for files and directories.

It's not a single-stream model like zlib or gzip - those would be 
better supported by COMPRESS and DECOMPRESS.

BrianH, yup I realized how it works now and I even fixed the /gzip 
quirks in DECOMPRESS...so I can decompress zip chunks with CRC32 
checksums now. But there is still one annoying bug, that the current 
zlib code doesn't handle the CRC32 calculation well on bigger files 
than 32kB :-/ Now I'm trying to fix it so the crc32() calls works 
in the "CRC running" mode where the final CRC32 is calcualted from 
smaller chunks of data which a file consists of.

I'll hopefully push this on github If I manage to fix it succesfully.

We would still need to be able to compress and decompress in a R2-compatible 
way, even if it's optional, not the default. For interoperability.

BrianH: I think we should change the /GZIP refinement to /CRC32 so 
it is independent of the format. Then we can create mezanine/scheme 
support code for various higher-level formats (ZIP, GZIP etc.) at 
the REBOL scripting level.

BTW I have finally fixed the current /GZIP refinement problems so 
now I'm able to ZIP/UNZIP uzing rebol script without the 'PNG load 
hack' that is on rebol.org. In fact I modified the rebzip.r to work 
with R3 and the ZIP/UNZIP operations are now "instant" when comparing 
to the R2 version. So I guess this is a good proof we can write fiast 
zip:// scheme with just the current COMPRESS/DECOMPRESS natives.

cool, so looks like we could try to replace the old code in the future 
with these and see if it makes R3 better.

Is anyone working on the mezzes CHANGES and UPGRADE ?

When run from the new builds, they simply head back to rebol.com 
and do not show the latest goodies from the github.

Miniz looks nice. Smaller is better for something we're statically 
linking, and the license works too. How is the error reporting and 
recovery? That has been a problem with DECOMPRESS.

and async parse! :-)

The LiveCode KickStarter campaign to first re-structure the code, 
make it easy to accpept contributions, build a new IDE and some modernisation 
has raised over 500,000 GBP (more than 750,000 USD).


Same Carl didn't try something along those lines before releasing 
REBOL 3.

It's actually pretty easy to see how they managed it. It was:

- A multi-language IDE (not a programming language, people already 
get those for free)
- With a GUI with an emphasis on modern graphic design (pretty!)
- With a fancy demo (more pretty!)

- With an initial focus on programming languages and development 
platforms that are already popular (built-in customer base)


Powerful IDEs are some of the only development tools that people 
are still willing to pay money for (i.e. Visual Studio). Most people 
can't choose what language they write in, but they more often can 
choose their IDE. And for crappy-but-IDE-friendly languages, an IDE 
can make all the difference in your productivity. They're not as 
helpful for really powerful extensible languages like Rebol or Perl, 
unless the language is so bad that just about anything would help 
(Perl). Plus, since an IDE is an end-user app you can afford to GPL 
it, since the only stuff built on it are add-ons - that doesn't work 
for programming languages unless they have a clear distinction between 
user code and built-in code that is distinct enough to not violate 
the GPL distinctions, because most of the competition is permissive 
- and without the GPL restrictions there is nothing to sell, so there 
is no business model to get a return on investment.


It's nice to point to other open source projects and say "See! We 
could have done that!" but unless those are comparable projects their 
success isn't comparable either.

Programming language projects for (unfairly) unpopular programming 
languages are not commercial endeavors anymore, they're charities. 
GPL/commercial programming languages that might possibly GPL-infect 
the user programs are just dead now - they're not even sad anymore. 
It doesn't matter if the license is carefully arranged to make user 
programs not affected; most users aren't lawyers and there are much 
more unambiguously permissive no-cost alternatives out there that 
might be good enough, and some of them are popular.

Don't knock charities though. Charities can be very successful if 
they get enough industry support. Python, Perl and GCC are made by 
charities.

And it doesn't take a lot to run a programming language charity for 
a somewhat minimalist language. You don't need a lot of people to 
get the job done. Something maximalist like .NET or Java (when you 
include their runtime libraries) can need a lot of people, but something 
small like Rebol or Red doesn't need as much. You can get enough 
people to fund development even for a charity project just by being 
useful enough.

OK, so it's a single-language IDE aimed primarily at the education 
market, still with a nice-looking GUI if not as modern, with an appeal 
based on Apple-fan nostalgia for HyperCard. That's a tougher sell, 
but since it's education market you can get away with GPL/commercial, 
and since it's Apple-nostalgia you can raise that much money from 
merely thousands of investors instead of the millions that you'd 
need if you were going for a less-well-off target market. Makes sense, 
but it's still nice to see.

Livecode is a great tool - the values remind me a low  of what made 
REBOL attractive years ago.  It's just a really productive and well 
designed tool, easy to use, powerful, cross platform (iOS, Android, 
Windows, Mac, Linux, server), it's SIMPLE and geared towards getting 
work accomplished.  That's it's only goal, and the company has always 
tried to make good real-world choices about productivity.  And they're 
keeping the system modern and relevent.  The REBOL community would 
be helped by watching what they do...