AltME groups: search

Maxim's suggestion might work syntactically, but we would lose the 
money! syntax, which is the ISO standard syntax for currency. If 
we added a unit! type with Maxim's syntax we could use the same implementation 
internally for both money! and unit!.

However, remember that there are limits to the number of possible 
distinct units loaded at once. The value doesn't have more than 1 
byte available to refer to a unit, which means 255 possible units 
in use when you subtract the unspecified unit.

Carl had a blog about this related to money! ...

I'm just using money! and unit! as placeholder names for the two 
datatypes though. Final names should be decided. The money! name 
is a good one for the current money! syntax because the syntax matches 
the international currency syntax standard.

I just translated the function to a more efficient method in my head. 
What is the lexical change you mention, aside from the unit syntax?

If you want continuations supported well you need to build on a continuation-passing-style 
runtime. As far as I know, the only practical one with good performance 
is Parrot.

That is, unless you switch to a compiled language.

brian, you seem to really know what's happening at various languages 
scene.. cool .. I was just looking a talk (video) about parrot VM 
where it presented these things few weeks back where a woman was 
presenting these features (and I consider myself a language nutcase 
;) )

I haven't really followed Parrot for a couple years - lost interest. 
Suppose I should take another look.

Stackless moved away from CPS towards coroutines. I think Gambit-Scheme 
(even without compiling) does a decent job. 


I don't want to go the CPS route, but I find it intriguing that the 
Elephant in the room of re-entrant data blocks is .... an ELEPHANT. 
The fact that a problem is hard is no reason not to solve it.

Sorry, the code-vs-data distinction I made above isn't really a code-vs-data 
distinction, it's a path-vs-stack-referencing one. Janko and I have 
been talking about something other than your AT series path request.

Paul, I am taking a look at a good suggestion for a function that 
is similar to one of your mezzanine proposals. Could you take a look?

I think they are great ideas.  A bit more extended then my any+ function.

Probably a bit more practical also.

(Mostly curiosity, but with all-of, would be a simple way to see 
if data is already sorted)

If you provide multiple words, they get treated like a record, just 
like *EACH.

Here's a better check for sorted:
>> all-of [x y:] [1 2 3 4] [x <= any [first y x]]
== true

I would change the any-of syntax up a bit myself.

That would require a REDUCE or DO/next to use referenced data, and 
this function is too inefficient to use with inline data, as compared 
to the ANY and ALL equivalent code. These functions would only be 
worth using for large datasets, or otherwise their overhead would 
be too much. That is the problem ANY+ had :(

** Hint
Currently there is problem to complement charsets in R3.

To have 256 values in the complement (like in R2), I add the char 
#"^(FF) in the charset:
c: complement charset "0123456789^(FF)"


But it's not exactly the same thing (cause the value 255 is not allowed 
in the complement).

Have you any idea to have the "exact" complement (without using a 
nasty loop to construct the bitset!) ?

I mean, instead of adding 255 in the initial charset, i should add 
256, but i got a curious result doing that.
So i may doing it bad.

Complement charsets is almost completely broken in R3, mostly because 
a full complement of a charset would overwhelm your memory - about 
512 megs each. This has been a known problem since last fall, and 
was the initiial reason for the Parse Proposals.

well, you didn't read what i've said, because i show a temporary 
solution

we can't add 256 directly in the intial charset, i guess, anyway 
it's a clever solution.

btw. is there a reason why we can use 'unique on a bitset?

Wait a minute... UNIQUE on a bitset! means nothing, they already 
contain unique values

Yup, it's a noop. It was deemed more important to eliminate all potential 
test-to-see-if-something-is-a-bitset-and-not-call-unique code.

Where it makes sense, of course (meaning: we can come up with a rationale).

it is a test suite I wrote for Carl

Carl gave me some requirements how a test suite should work and I 
wrote my implementation of his spec. Carl looked at it and he probably 
felt it was more complicated than what he liked. OTOH, the main difference 
was, that my test suite tries to give useful informations always 
when it is possible and continue with testing.

Did you write the suite before he added the *-of functions? I remember 
he did a lot of work on those right when he wrote his own test suite.

(a block of code, that should evaluate true)

when comparing two interpreters, I can generally run all the non-crashing 
tests by both interpreters (a crashing test is a problem, since it 
stops the testing process) and show the differences

If you want documentation of the differences in behavior between 
the old reflectors and the *-OF ones, start with R2-Forward: I did 
a lot of testing to determine the behavior of the *-OF functions 
so that I could replicate their behavior in R2. I am not able to 
emulate some R3 datatypes in R2, so the behavioral model is not complete.

There are numerous bug fixes in R2-Forward, and every one of those 
fixes is a change: No longer bug-for-bug compatible. I am particularly 
interested in which changes would break legacy code.

I started a deep deep thinking process wich is a heavy task for an 
idiot biain of mine concerning the futur of viva-rebol and where 
i want to lead it.


If you have a little interest for what i'm doing actually you know 
that i'm actually working  on 2 projects viva-rebol and rekini. I'm 
interrested in transforming viva-rebol into a real time collaborative 
project. manager/editor something like wave but done in rebol to 
create rebol application.


The idea that comes to my brain is to mix IRC and vivarebol. IRC 
would be the supplier for sharing real time documents content information 
and viva-rebol will be at the same time manager and the renderer 
that will catalise the informations collected by irc.


Why irc?  first because they have lot of control feature wich can 
allow anyone to join and see an onShared-creation docuiment  or script 
and only look at it without active participation. That can allow 
a hierachy system with master, co-writer and only viewer. and the 
allow the master to select who participate or not to the création.


We saw with area-tc that rebol and VID and the dialect concept was 
really feat to handle uncomon text handling  at light speed so the 
appears clear for me that this is the next step to go.


Some people will say to me "but it's more important to have an advanced 
rich text editor tool"  which i answer that boring to do and in the 
result the gain in notority for rebol is close to 0. So instead of 
 clonning MS-Word using VID I prefere move to the next step wich 
I hope will lead us to make people see all the potential of rebol.


It took me looooooooooong time (6 years in fact) to see how to merge 
all the interresting part of rebol to make a big project wich we 
could be all be proud of and show all the interesting part of rebol.


Our comminuty is small and working together to make advance the projects 
is obvious if we want our project to be recognised in some way. If 
we all work on our sides on our own project achieving a high quality 
for those projects is hard.  So externally we only show to the world 
project that looks more like teasers than completed project and that 
not a good thing for rebol promotion. We can say all we want about 
the way rebol is done by Carl but us as community which goal is to 
spread rebol world wide we have a part of reponsability in that too.

I think proposing a collaborative real time tool for making rebol 
script is a good idea as a leading project to make every one acquiere 
or show high level skills. That's in my opinion more productive than 
having Gurus explaining to stupid morons like me things during weeks 
with no concrete result to it.  Sooooooooooo I propose to KEEP IT 
SIMPLE. Instead of explaining me the solution take half of the time 
you normally use to answer me to edit my script make the changes 
and then ofcourse we can have a nice chat on why you used that and 
not this and that will make my level progress a lot. And most important 
of all the problem and my project will be solved and working.

ofcourse if that tool allow 10  personne to build from white page 
a rebol script that can allow them to write a documentation allowing 
them to see how are feeled each part of the documents by the contributors 
and make comment on those parts on real time.

this project that will start as a commuty oriented project can then 
be retaken as it by compagnies to speed the way they work. and not 
only for rebol scripting porpose.

another motivation for basing the data exchange part on irc is that 
their is a lot of irc server all around and using them is really 
easy stuff. That's in my opinion faster than making a web oriented 
tools then convince the hoster to allow us to install rebol on his 
web server etc...

but if you want a persistant extension of that making an irc bot 
that collect all the project worked with the viva-rebol online feature 
and making the bot publish them on web that's easy to do.

of course it's totally up to you.. but I try to make bigger projects 
in *finalizable* steps. My advice is to first release at least simple 
but usable IDE and when you have that nailed transform it into a 
realtime editing thing :) . There is still a lot of problems to solve 
when you try to finalize an app and it also teaches you a lot about 
the product you are making. Moving target higher and higher is a 
nice way of not releasing anything at the end.

perhaps it would be possible some day to apply specific attributes 
to a heading.

The chat protocoll doesn't know how to request a specific message 
from the server, all is loaded in local and the requests are performed 
in your client memory

files are the exceptions, but the tag message for a file (the link) 
is loaded in your local file, even if you don't download it

The R3 chat protocol (as it is now) is not suited for real chatting 
with a massive exchange of short messages between users or specific 
channel.
Because each time you sync, all is loaded in local.

So more there will be traffic and users, more it will be slow and 
like with Altme, there will be a need to clear the database after 
a while

Yes But i'm afraid that twitter will generate a massive flow of messages 
after a while.
And even if you dont read them, you download them after each sync

Massive

 is relative. A sync of 4500 messages from a scratch takes roughly 
 10 seconds here. I don't think it poses a big problem.

Well it's a problem for my poor connection

loading http://twitter.com/rebol3here is a 14 kb webpage for 8 messages, 
excluding images, so it's probably 20-30 kb each time you want to 
read it. With the information amount we want, R3 Chat can probably 
deliver over 200 times more messages in the same bandwidth, assuming 
that each message is < 140 chars. And also R3 chat only retrieves 
them once. After that, they're local. Twitter loses. :-)

I guess someone needs to make a REBOL client for Twitter.

steeve, local caching is not a drawback, its a feature... it prevents 
the client from having to check all messages EVERY time it starts 
instead of just once.  there should be more parameters though, I 
agree, giving a time frame would be good, so that it knows to forget 
old messages you don't care about, for example.

Not really a problem for R3 chat, but a big problem for AltME.

Hi all. A percent! datatype question. What are your preferences with 
respect to the full IEEE754 64-bit range?


1) Current state: the whole range is used for percent, except for 
the fact, that LOAD and MOLD cause error when encountering results 
such as: 10% + 10% + 10% - 30% (not exactly zero)

2) Use the complete range and correct both LOAD and MOLD to be able 
to show any value from the range - this means, that the E notation, 
like 1E-15%, or 1E20% may be needed.

3) Change the %arithmetic limiting it to a subrange of IEEE754 (may 
be complicated - every operation needs bound checking and slow)

is there a problem? He's just sleeping now, so he hasn't received 
the solutions yet.

(in the previous version the expression caused a mold error)

its a question of speed...

display and value are two different things.  I understand the need 
for scientific notation to represent the value, only that there are 
no easy ways within core to deal and show the result below at a given 
decimal point without having to convert it to a string and always 
check the scientific notation in uneeded cases.

how much time to get a gui in rebol3 linux and other ?

I wouldn't rely on any kind of Gui expectations for a while in R3. 
 AFAIK, a lot to do still.

but i read in rebol.com that a gui for rebol chat will be proposed 
!!! normaly in february 2009 "Resume work on the R3 GUI. The primary 
focus needs to be on styles for lists and tables." (carryover)."

and for MARCH 20009 "The R3 GUI has been running for several months, 
but it needs a few more key components. For example, we can ask why 
the new DevBase (RebDev chat) runs in the console, not in the GUI. 
The reason is simple: the GUI does not yet have an efficient table 
display style. So, although it does have dozens of other widgets, 
a way to display and scroll large message lists is really the key 
here. I will be happy if this can be accomplished this month, and 
we can begin using the R3 GUI for an actual application."

a native port of image magic would also allow rebol to load/save 
a few hundred different file formats directly... even some movie 
formats are supported.

image magic also supports floating point image manipulation and has 
a lot of built-in high-quality filters (real time 200 pixel gaussian 
blur anyone ? :-) and more than 10 image filtering functions IIRC.

Next time the GUI will be touched, will be a redesign of the layout 
engine, which performs poorly right now.

a general question for those of you actively testing using REBOL3. 
 Is it stable, a part from the known bugs or function differences.... 


Once a rebol3 source works... can it be expected to run for a long 
time or are there still many internal bugs which will inevitably 
cause the app to crash (gc instability for example).

The problem is that most of the code written in R3 has been written 
by people who have a good idea of the internals, who know what is 
optimal and what is not. This means that the code tends to more heavily 
represent good code techniques and practices - thus, those code patterns 
are more thoroughly tested and stable. What hasn't been as tested 
as much is bad or erroneous code: Some of that can still crash R3 
at this point.


Fortunately, new users have been joining the fray, and many of them 
are not aware of the internals or best practices. Or in Ladislav's 
case, exhaustively thorough in their testing coverage. Because of 
this R3 is much more stable than it was a month ago :)

hehehe  I think I`m going to give A56 a real run for its money  :-)

I'll be using modules if possible.   an earlier version of R3 just 
crashed when trying to allocate a single node... we'll see.

is there a page which explains various optimisations one can do to 
R2 code to allow it to take advantage of newer and faster functions 
in R3?

Maxim, try to look through the cookbooks section in the wiki at http://rebol.net/wiki/Cookbooks

There are a few things. Not much yet.

I've just finished helping the plumber install a new submersible 
pump in my 50 meter deep well, changed all the electricals too... 
I didn't have water for the last 4 days... 


now I can give myself a rare treat.  taking the rest of the day off 
today, so I can do my things.... and that includes one "fun" project... 
usually a short project that I've been putting off of a long time... 
today its liquid/R3  :-)

well SAP is going to be a big one to topple for that bragging right 
 ;-)

Sunanda, your "memory exhaustion" ticket (bug#920) was not a GC bug, 
in fact not a bug at all. Look at the comment for details :)

You are quick with the bug analysis!


Not entirely sure why you consider it not a bug. Recast this way, 
it looks a horrible problem....
   for n 1 10 1 [print n a: mold system]
....It gets slower and slower and then dies.

...And the I may need a new session as:
  b: mold system
now does not have enough memory.

devbase is a strange space.  its like: "altme in the twilight zone" 
 even the white letters on black of the dos shell  bg re-inforce 
this  ;-)

I've noticed that devbase has the same problem as altme at recognising 
the daylight saving time... I have a one hour offset in time postings.

is that a known issue?

yes, it's a very known issue

there is a list in devbase help in the wiki

If you feel like adding a feature, go ahead, and post it to curecode. 
Carl probably prefers 1-2 line fixes, though.

could someone either raise my rank so I can add a lib within Community/Libraries 
or add a heading called liquid there.  I'd post my R3 related comments 
for liquid there... I think Carl would like some feedback on my efforts/problems 
porting such an advanced tool into R3.  when it will work, I'll also 
be posting comparative benchmarks.

Sunanda, the reason it's not a bug is because for every iteration, 
'a is set to mold system, and mold system includes the previous value 
of 'a from the previous iteration, as a string. So that means that 
every iteration is the length of the rest of the system, plus the 
length of the previous 'a times the number of visible references 
to it. Since there are 4 visible references to the collection of 
global words, this means that the growth is exponential, and of a 
larger exponent than R2 (which has only one visible reference to 
the global words, so it just doubles).


The way to prevent the exponential growth is to assign none to 'a, 
or unset 'a, before you mold the system again.

I've officially just created a new file on my system.... its called: 
   liquid.r3  
let the fun begin  ;-)

I do everything and its not in the extensions list, but strangely, 
it is working, since clicking on a liquid.r3 loads it properly.


what is even stranger is that I scanned the registry and its not 
there either!

Associating a file extension is easy enough, but for now it is better 
to make shortcuts or batch wrappers instead. R3 is alpha :(

good point.  that should be a configuration in the future IMHO.

The requirements for a module system in REBOL are pretty much defined 
by the task and the language semantics, and those haven't changed 
much in 5 years. It's not surprising there are similarities :)

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

as people will start building public modules, name clashing will 
become an increasing problem... there is already some of that on 
rebol.org... altough not much... but there aren't a lot of similar 
libs there either.

or using only one feature from a newer version of a library and all 
the rest from the older one, cause the update isn't compatible... 
that should be allowed.

well, I'm giving you 5 years of daily real-world usage above  ;-) 
  a lot of the slim spec has not been used, by natural selection, 
but the above is in just about 95% of all of my code.

I've been giving the module system a lot of thought lately - but 
it needs a bit more...

One thing to remember is that simplicity is a real value here. We 
need to make sure that any features we add integrate well with the 
rest, and don't create a burden on the programmer. Any setting that 
you can make is a setting that you will have to decide whether you 
need to make, so that adds to the development overhead.

brian I know all of that...   /only is a choice, not a burden.   


the way it is setup up now, we are imposed the decision of the module 
author.  its EXACTLY like people who currenly use:

set 'word func [][]


this is very bad design, even more if the module functions themselves 
require words to be global.


PITL requires control over modules.   in all languages which have 
modules, name clashing is always annoying.


python has a very nice module system, cause you import specific words 
or all of a module.   with a few hundred libs as standard they had 
to make it clean.  I think they did their homework.

Oh, I get it, you forgot to make Needs a set-word.,

that was such a stupid error.  :-)

but a file content search of the whole code doesn't return anything 
relevent to the needs block.

yeah... maybe carl can just add a hook for you in the loader.