AltME groups: search

I think that Sunanda could be able to filter out Geomol's post and 
my reply from the web export.

the main chief guru in my mind it's carl the guy with all the answers 
and all the keys and keeping them for him ...

how do you want people to be more implicated in rebol VM  enhancement 
if  they can't learn from what already exists in it ... and once 
again i'm sorry but it's a mater of fact compared to public accessible 
open source VM  REbol is clandestine...  and what is the purpose 
to do a revolution that is kept in a bottle ...

and the problem is not R2  or R3  or R20 ... you see ... the matter 
of fact carl tomorow decide to stop rebol we are all fucked up ... 
Openning the source code of rebol is a way too write it in history 
many where the langage with close  source VM. No one now in days 
remember them and the only ones  getting all the attentions are the 
ones with GPL  like system

Pekr open source or not open source is a long rate debat man it's 
been on the table since day 1 I met rebol 6 years ago and what i 
can see is that the rebol community is skrinking and not extending.

The trouble is, that you constantly repeat your point of view on 
all possible places, whereas we have more important things to do 
right now. REBOL should be open-sourced long time ago, or we should 
wait a bit for open-sourcing it in future. And open-sourcing host 
code is good for starters. Yes, we are slow, but we are getting there. 
Carl needs to finish Parse, then he is back to Extensions, which 
apparently are going to be used for Host code isolation. Once that 
is done, the code can be released.

Yes, REBOL community got shrinked. Because our only product is R2. 
And R2 is stagnating .... because most resources are now dedicated 
to R3, which is not production ready yet. Once in beta, or 3.0, we 
can start looking for new users, and we can start to reconsider to 
ask Carl to open-source Core. I see no point raising such questions 
nowadays. Let's wait half a year at least ....

Pekr for example by  solving directly the bugs instead of filling 
a bug track and than wait for example ... you still can document 
on a bug track what evolution you maid... The question is can carl 
work on all the topic related to rebol at the same time ? the answer 
is no. And until now carl take a topic enhance it correct the bug 
related to the new topic addition and then move on to the next topic 
.... i'm not sure that's the more efficient way

Shadwolf - what are you talking about? Just look at CureCode. CureCode 
is absolutly cool and it much helped to shape-up R3. We get 100 tickets 
implemented a month. That might be even more, than you might get 
with some even open-source systems. And you also make it sound, like 
there is no plan, whereas there is a concrete plan for beta - http://www.rebol.com/r3/project-plans.html
.... Carl even offered to wikify it, so that the community CAN influence 
release priorities ....

I had no intention to go into Parse. My only note of Parse was, that 
it is the actually undergoing priority, and you can note the fact 
by looking into R3 Blog topics .....

ofcourse it is a priority to polish parse ... but the thing is only 
car can try new feature...  having opensource accessible to all mean 
alot of tries can be done and shown and that's better than the 1 
to  X  relation we have. Mainly and i'm not the only one to say it 
we propose alot of things but since we can't show them they are. 
what do i want is a rebol that evolve faster ... it's been 2 years 
since rebol 3  enhancement started we lost alot of time in futil 
consideration like how do we name that and how about changing the 
name of this ... and we skipped during a loooooooooong time the main 
topic ....

and then carl said ok lets redo it all and 2 years and around 100 
 alpha version havec been made and we are still in the process ... 
 Mainly why because it's the work of a single man... and that's all. 
If carl don't push the rebol car the car stop and that's all ... 
you see all the comments you can do or not will not have a real impact 
on how the car rebol progress or not.

Shadwolf - then please go and ask Carl privately about open-sourcing 
topic. It sounds like I am against it - I am not. I just don't think, 
in comparison to you, that open-sourcing it NOW would bring us R3 
any faster. Soon enough (which I ufff, repeat for so long) we get 
EXtensions and host code. I bet it comes in few months. Then ppl 
can start porting efforts and extending the language .... ask Maxim 
for his plans :-)

Shadwolf - I talked to Carl, and he wants go into beta Autumn 2009. 
I actually think it will be Winter 2009, but I would like beta to 
include all important Core stuff, including tasking ...

cyphre working on R3 actually ? Cyphre didn't loged to atme since 
july 27 how active is that ?  I don't see many topic poped around 
at same time i see 1 main topic wroked and the related things worked 
at same time that's all. 

Complete architecture change .... hum ? but that's came along the 
flow my brother it wasn't a from the begining statement.

did i said R3 wasn't good ? i like many features in it but the progressing 
is slow that's all and repose entierely on carl...

well, the ports system has been done for over a year and is documented, 
but where are the protocols?

but yes I would say R2 lasted too long ... carl was glued in endlessly 
bug correction and few where the real improvements... the major addition 
in R2  was the AGG/draw dialect which since then have not evolved 
a bit... look at the number of tickets in old rambo. So yes starting 
with a ew base and bring alot of enhancement was a certain thing 
the problem is along the process we lost alot of people mainly interrested 
in rebol but not seeing it evolving fast anough and that how do you 
solve it ?

Henrik - we are bunch of lazy and uncapable lamers :-D

yeah... but we assume it :P or at least i assume my lazyness and 
my stupidity but in other hands most of things I done with rebol 
where totally unexpected things .. and  once again every time i faced 
limitations that forbided me to push them till the end and release 
and maintain a product more than a demo ...

Shadwolf - we do wish, and we do hope for those ppl to return. We 
also hope to attract many new ppl.

Shadwolf - what imo Henrik tried to point out is, that R3 networking 
seems to be kind of solid for 1-2 years, yet noone picked-up and 
rewrote networking protocols - and that layer is of cource open-sourced 
...

pekr i think maybe if in those last 8 years of rebol if i had from 
the begining access to the code i could solve some of the limitation 
or organise myself  with other  people in the community to bypass 
the limitation and enhance at the same time rebol VM  you see that 
is the dynamic i want to see ... and that is the dynamic that only 
 opensource open access can bring...

Pekr ... opensourced sorry but i don't have access to it i need to 
ask carl and  then it's up to carl to grant me the codes or not and 
as i'm an idiot and everyone knows it that's not going to happend

i think steeve had maid some suggestion on the topic but noone listen 
to him ... so this means the source code are not as easy to put their 
hands on them as you say  pekr..  and i'm pretty sure if steeve could 
put his hands on that topic the result would be fun ..;

There is some chance that after the Parse enhancements, BrianH overhauls 
Scheme dialect and will start work on protocols ...

for me networking starts and stops with read htttp://www.mysite.org/mydocument.html 
...

ldci pointed that link ...


What do "Livin La Vida Loca" by Ricky Martin, "Mambo No. 5" by Lou 
Bega and REBOL all have in common? They all peaked for about a month 
in 1999 and nobody has thought they were cool ever since.
... man that's hard ...

A two-pronged attack killed REBOL. First, the fact that the end user 
had to single-handedly install an interpreter and do a good amount 
of legwork to get it and the application in sync ensured that the 
language wasn't going to be adopted by the masses" - the person clearly 
does not know, what he is ranting about ...

lol

[] maybe are a ponctuation in his mind .... too much brackets ho 
common less than lisp anyway ... LISP ...  Lot of Insipid and Stupid 
Parenthesis :P

and you know once people decided that rebol is another meaningless 
toy that's hard to show them the contrary ... That's why i always 
thought big language are made famous by big projects ...

even if I'm agree that the rebol concept could or should be pushed 
further and that it was spread over too much OSes without taking 
full capabilities of the 3  or 4 main ones  ... that's not a reason 
to say it's  useless ...

man this guy is not cool in this article not only rebol is scratched 
and at the limit on the whole page the best comments are made on 
rebol lol... java2K .... lol ... poor java2K ...

i don't understand the install issue with rebol like java and .NET 
runtime ... i don't see the problem  there  or the point ... maybe 
he refers on other os like linux but even being half an idiot you 
put rebol VM in /usr/bin and you dont need to set up your path environement 
...

Then there is also a bit more talk about ports and why there still 
are no protocols. There is no conclusion, other than people are either 
busy or lazy.

2.100.86: PARSE fixes and enhancements. Major rewrite of the main 
PARSE function. Watch for any new side effects.

http://www.rebol.net/r3blogs/0259.html

And what A86 can do.

henrik or the 3rd thing ... that's don't have a beggining of a clue 
on what and how to do protocols....

see for example i have lot  of "free' time that I could spend on 
that topic but then i'm not sure the result will feet your expectations 
and i absolutly don't know how to proceed

it is confusing and absolutly nothing telling to the end user

I just run trace/back on, demo, trace/back 20 ... I can't understand 
the output, yet, but interesting :-) But really - Windows console 
just sucks and downgrading my REBOL experience by tens of percents 
in comparison to R2.

just read the output from left to right. it shows that PARSE called 
MAKE-TEXT-STYLE, that FONTIZE called PARSE, that DO called FONTIZE, 
etc.


R2 would only point to the source location of MAKE-TEXT-STYLE, and 
then you would just have to hope that the place was unique enough 
to find it with a text editor's search function. That would be hard 
if MAKE-TEXT-STYLE existed in 20 different places in the code, and 
so you would have to proceed with several minutes of probing. No 
need for that anymore.

Here, I can immediately tell the path to the problem.

Henrik - as for protocols, dunno who, but someone here said, that 
the http protocol is done in an old-school way, and that it deserves 
new aproach. I will gladly wait for BrianH to take over this area 
...

For BASE font style there is no parent, and we have a new rule that 
says that SET does not set a new value, if the  value shouldn't be 
set.

Maybe it's not entirely that. Because parent is a block, and it's 
set to the next value, so it borrows the next value after opt, where 
it shouldn't. That could be a parse bug.

Bug #1254 is a direct result of the A85 changes to the INSERT, CHANGE 
and APPEND functions, so we should probably test all functions that 
use those.

Does function! and closure! work backwards when dealing with indirect 
values (block!, string!, ...)?

>> f: func [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> f
== ""
>> f
== "1"
>> source f

f: make function! [[/local b s][b: [1 1] s: "11" insert b 1 insert 
s 1]]

>> g: closure [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> g
== ""
>> g
== ""
>> source g

g: make closure! [[/local b s][b: [] s: "" insert b 1 insert s 1]]

Souldn't the functionality be the other way around?

I got the feeling, closures should work as R2 functions, that would 
remember local variables, after the function returned. And functions 
in R3 are implemented using stack-frames.

What a closure seems to do (sort of):
func [][
	compose context [
	 (copy/deep body)
	]
]


It's not a correct simulation of R2 functions, which should be something 
like:

context [
	func spec body
]


You see, the context created should be outside, so that it would 
be build only one time and not each time the function is called.

Actually, it's what i do to create local persistant variable in a 
function. I wrap the function in a context and declare the persistant 
variable in the object instead.

More i think about that, more i think the closure! type is useles, 
at least less than the above case.

And i posted the same request than you

Carl wikified the project plan - http://rebol.com/r3/docs/project.html


I am now suggesting the following aproach - to create October plan, 
describing R3 beta release. My proposal is to discuss particular 
items here and on chat, but the main channel should be blog. There 
we can post our priority lists. Once agreed, we edit the doc.


So hopefully soon enough, we open the discussion. We might already 
start, but save your comments for the blog. This group is moving 
fast with discussions, maybe we could set-up (temporarily?) an R3 
priorities group, and each of us could post his numberred/bulleted 
list of requested features? It would be then easier for Carl to look, 
or for us to gather ideas and repost them to blog, etc.

What do you think?

how can I become an editor for the wiki?  I would eventually add 
some stuff for the extensions (from me and others).

writting up a complete,  revised, and proper document for a devices/callbacks 
spec, which I will link within the projects plan when its done  :-)

the goal is to make it a working document, we (those who care about 
this issue) can pitch in and improve.

Agreed, and a few links in the comment column would help here and 
there :)

I think, that naturally, such document should be part of CureCode. 
But that is for the future. Simply put - in cure-code, you post a 
wishes too. Those might be dismissed, or accepted. There should also 
be a table called releases, where admin could add version numbers. 
Then fixed-in could use shortcuts as fixed-in 'next release, and 
the correct version would be filled-in, etc. From there, such pririty 
list and milestone releases description could be automated. But - 
we don't need it now ...

I am not sure if to create the priority group? Because then regular 
discussion might start there, and we will have channel split. OTOH 
why have things all in one channel? What do you think?

Well, save your changes locally and ping Carl with the error. It's 
probably a file permissions missetting on the host.

I think that our Linux and OS-X friends are going to get 2.100.87 
release soon too :-)

Actually - they were released already - but only for OS-X Intel and 
Linux/Fedora, so far ... I think Kaj can upload new version to his 
R3 demo site :-)

I have thought of a way to re-cycle devices as the actual interface 
for threading.  the nice thing is that my new proposal includes function 
calling and port modes... so we could build threads inter-comms using 
any of the two methods  :-)  actually, we could implement the WHOLE 
threads system ourself... we don't actually have to wait for Carl 
to do it.

do-something-in-other-thread  would be handled like a callback in 
the thread.


so its uber simple to setup.  you could also do a reverse device 
setup, since the R3 process would contain both driver and client 
code, all you'd need is for the device to have a command which tells 
it how to connect to you, and you become both driver and clients 
for each other.  making it very easy to provide async comms in both 
directions.

I'm still working on the details... the draft is going to be ready 
in a few days, while I iron out an actual implementation example 
and work on the details.

it also has to be consistent, and there are some things I can't really 
go in depth, because the host code isn't yet available.

Max - OK. Just remember, that Carl wants to get it quick, or so is 
my feeling. So you should better finish it ASAP, as once Parse is 
done, he might be back to revisit the list, and reorder priorities. 
Hopefully I think that Extensions will remain high priority, as it 
seems they will be used even for Host to Core isolation ...

Its a proposal, an idea, something to reflect on... I'm not trying 
to prove that I have the best idea, but I really think we should 
see if what I propose is dooable... imagine, threads, dll interfacing, 
inter process coms, callbacks, LNS, all using the exact same client 
code, and much of the same on the driver side too  :-)

R2 has 'parse-xml and its helper function 'xml-language.

You can copy their sources to R3 .... but they are currently seriously 
buggy there.


Gavin's XML parser was better in R2....It has no equivalent in R3 
yet:
    http://www.rebol.org/view-script.r?script=xml-parse.r


I guess we are waiting for parse to settle down before getting decent 
XML tools.

Well, i only wanted construct a block of tags and strings.
So i came with that, it's enough for me currently.

src: read %frog.svg
out: []
parse src [
	any [
		copy str to [#"<" | end]
		opt [if (not empty? str) (append out to-string str)]

  not end src: (set [data src] transcode/next src append out data) 
  :src
	]
]

Good to see the old news documented somewhere outside of CureCode 
and the blog :)

I don't like the entire removal of security in order to be able to 
raise the stack. We need secure [stack allow] or even better secure 
[stack 1000000], and in such a case evoke is not needed ...

aha, so it just "switches" to >> prompt, and here we go - R3?

And the lack of that effect is what makes CGI not work on Windows 
(in addition to Unicode issues).

I want to be able to pop up a new console if I need to, but it should 
be a GUI console and I should be able to pop up more than one in 
the same R3 process, in different tasks. Text mode console usage 
should use the text mode console.

I am curious about HOW do we actually fix the unicode issues. This 
might be more deep problem, that might seem. Because If I am not 
able to print in UTF-8, I need to first print the header, using some 
conversion, and then the content = the code is not easily cross-platform 
...

CGI output should be binary, and the headers output in 7bit ASCII 
(not UTF-8) through that binary output.

Any encoding is none of the business of the CGI channel - it is a 
matter between the script and the cliennt.

As to your remark - I wonder, how R3 itself decides, what is, and 
what is not a header :-) You probably mean, that I have to be responsible 
for the conversion?

That should be fixed, no? :-) I want to start to do some tests with 
CGI, and no will to mess with Linux here :-)

Well, we were careful to design the module system so that you could 
specify requirements and relationships statically. This makes it 
relatively easy to adapt modules to a preprocessor that collects 
them into a single script, without necessarily needing special directives. 
This might make encapping easier.

I think so.
The only remaining problem will be the transform attribute.

They can apply a matrix to transform the gradient. But we don't have 
that, as-is in Draw.

We can apply rotate, scalling, and translation (i guess) on gradients, 
but separatly, not as a matrix.

Do you mean, taking the matrix and extraction the different components 
(rotation, translation, scaling) ?
I don't know if it's possible, i'm not good enough with maths ;-)

I have one curiosity: REBOL3 VID is going to be an old style 2D interface. 
New interfaces, expecially for mobile device are PSEUDO 3D and touch 
based. Could this kind of interface be inplemented to support current 
and future generations of  products ?

yes, both touch and 3D are possible.

that is strange... never had one without the other in R2... although 
in R2 if you put the to-image call in an attempt and the effect was 
invalid (and would usually cause a rebol error), that face will never 
render again, whatever you do with it... is stays in a corrupt internal 
state.

No, it doesn't exist, and would be one line of code. However, so 
would calling this function, so it doesn't save anything. Probably 
best to remove the reference/page.

but, I'm about 40% through the list, and I'll compile a list of changes 
and things that need to be looked at.

IN-DIR is used for file manipuulation code, when you need to change 
the directory for onne bit of code and then change back.

thanks for your time and effort Henrik... this type of volunteer 
work often (usually) goes un-noticed and it really is a lot of work.

There is probably still going to be a lot of bugs and missing refinements. 
I noticed that some functions aren't written properly in the summary, 
and of course there are obsolete and missing pages.

It looks to me like some GUI functions like 'handle-events and 'base-handler 
that belong inside View are also available in the main context and 
are also listed in the docs. I assume those functions will disappear, 
once the GUI goes into a module.

I posted a note to the R3 blog article on a89 as I cannot get it 
to return a prompt on Win XP SP3  - I have tried getting r3-a89.exe 
to consume a script and tried not only under cmd shell but also under 
cygwin

A90 now also for Linux and OSX

Both fine on my Untu and XP. Whatever.. BTW, was there ever a chat 
about assert {}   I am spending some time in Groovy and thinking 
about the errors in a Rebol book: the Manny Groovy book was generated 
so at least the code examples run ... groovy uses assert a a good 
deal ... which got me to thinking about REBOL  comment {}  which 
seems to suggest that we could have an assert {}  which is evaluated 
only when a REBOL option is set. and have it default to OFF

Oops - so funny - I went to look at rebol.org for any use of an assert 
but there it is  assert  in the R3  docs   missed it ...  but can 
it be flipped not to run?  Or would you just  set assrt: :assert 
 and wrap it?

this is really annoying and like you, I see absolutely no real-world 
usage ... it sounds more like an oversight on carl's behalf.

like... oops ... forgot to remove unset values in reduce native.

in the meantime, you can just make reduce a mezz , call the native 
inside of it and remove unset values... at least its going to be 
done automatically... although it will slow down your code a bit.

posting it to curecode is a good way for him to see that a change 
isn't beneficial in real world use.  he will comment it there, and 
it will be usefull as a reference for further users... I did a search 
for reduce on curecode, found a few things... but since curecode 
serves as a reference, this would be a good place to put your grievance.

See, why i can't remplace reduce by compose.
I use such rule to parse draw blocks
>> box: [ 'box  origin destination]


when i use this rule, it's auto intialising the variables origin 
and destination.


The interesting thing is that, when i change the content of the variables 
somewhere else in my code,
i can revert back the content of the draw block, just doing a:
>> reduce ['box origin destination]


You see, i use the same block of defintion to parse and change-back 
a draw block.

Afaik, we don't have any characters left that can be used for delimiters 
to surround some kind of literal value. [], (), <>, and {} are taken.