AltME groups: search

I suggested to Carl to consider KDE 4 aproach. It was in development 
few years, and it seeemed like there is no end to this. So the team 
decided to cut some features for 4.1 and later, mark recent state 
as 4.0, and release it. They were criticised, but I do understand 
their motives. Those are mainly psychological - release, and never 
look back. Use current one. Are there bugs? OK, let's fix them, and 
go ahead ...

and retrofitted as needed

Henrik - I am not sure I have any intention to participate in VID 
world, even if invited. I suggested you and BrianH initially to Carl 
on purpose. My understanding of situation back at that time was, 
that VID 3.4 is almost finished, and 2 ppl are needed to help it 
to finish it. I was probably wrong, as now it once again seem, as 
a regular release. So as for me, what was initial purpose of r3-alpha 
world, now moved to new GUI world.

Henrik - I understand your attitude and am sane enough to know, that 
I make very often stir/noise. But you are typical example of elitism, 
and I don't like it :-) While you might enjoy being close to source, 
you might not understand frustration of other devs out there. I think 
that Carl is not used to work with larger teams, makes his decisions 
himself. It is very difficult to proceed faster, unless Carl finds 
some leutenants. Pity Ladislav is not here anymore. Hopefully BrianH, 
Maarten, Gabriele, Cyphre, Dockimbel are trustworthy coders, to delegate 
some work.

henrik, you claim that working on the BBS was a good thing .. but 
if development had been opened up, these show stoppers would have 
been detected long ago, and we would not have this embarrassment.

The whole development process is missing some signs of good project 
management. I don't say it like critique, it is not ... I am just 
stating facts. We are not able to stick to even close targets. The 
initial purpose of Bugbase, DevBase, BBS, etc., was to provide cooperation 
infrastructure, and provide it ASAP. Instead there is now REBOL based 
effort to develop BBS, but without keeping to initial reasoning, 
what should BBS provide us.

We should drop the VID work .... and just fix core for a release 
as in Rebol 1

Henrik - I can tell you one thing, which I smiled to :-) Carl is 
imo worrying, that releasing in current state could put us in situation, 
where we would not be able to handle the load. And I know, that you 
mostly back up everything Carl says ;-), but then I pointed him to 
R3-alpha release wiki page. He told me he forgot about that site, 
and that he forgot we already did something like that. So please 
- give me an answer - first public alpha was released in last january, 
and NOTHING bad happened. It was released only because of my constant 
push and ramblings. So - why should devs collapse under some heavy 
load now, one year later? Nothing like that will happen.

this bottom up, top down, and anything that grabs Carl's attention 
is not working.

Henrik - this was so nice. Release often, ppl felt the process is 
dynamic, ppl felt constant progress. We tried it several times in 
the past, but not longer than for one months, and then - another 
blackout: http://www.rebol.net/wiki/R3_Earlier_Releases

Henrik - we are dealing with human beings here. And you might be 
forgetting about it. If we want the community, not just customers 
to buy products, we have to support them, provide them ways to get 
involved. Even if the alpha was released to satisfy those unsatisfied 
ones, it served the purpose. Ppl will become familiar with it, play 
with it, maybe find some bugs. Who cares, if CureCode is loaded with 
thousands of tickets? The bugs are there, or they are not there. 
DevTeam can choose what to fix ....

The release early and often style doesn't hold up for early alphas. 
It works better when the product is more stable, so you can get reasonable 
feedback. I wonder how much time the KDE team would have saved, had 
they waited till 4.1 with a release.

But enough of that. I want to have some influence, as a suggesting 
voice. It is upon Carl to choose, how to further proceed. I am just 
stating, how I would proceed, and what consequences current aproach 
carries. If the majority thinks I am wrong, that I will stay unheard. 
But my experience is, that as for organisation of efforts, I am aften 
right.

I can understand how Pekr, Graham and many others feel about the 
lack of R3 releases especially given all the early announcements 
and the first public alpha. However, I really feel that Carl is still 
prototyopng R3, he is a long way from settling on the design of R3. 
There is too much missing for the current version to be considered 
an Alpha (e.g. No modules, no threads, ASCII GUI, Host environment 
& Runtime Core in a single executable,)


This is seems to be Carl's way of working and something that he has 
to work through step by step.

I had a funny observation: You can edit rich-text with the DOC style 
due to a bug, by clicking over the pieces of text and start typing. 
It works nice and fast, although there is no cursor management, ways 
to move between different text styles with the keyboard or any font 
settings. But then rich-text editing should not be so far away.

thought about it, yes. who will do it and how it will be done? don't 
know. if anyone wants to, I'm sure Carl will approve.

thank you to henrik for those examples  of REBOL3 GUI ;-)  it seem 
to be faster than R2 and perhaps we could have some grid and db grid 
and others..........

don't see the point, if you want and SQL DB the you can  use any 
lib

and make routines

Steeve? DB scheme? Come on, guys, you must live in wonderland, no? 
So supporting sqlite, mysql, postgress, and others via ODBC is not 
enough?

for developpement and support R3 need more guys !!!!

and i'm not waiting for RIF, i know Carl

Steeve, when Reichart posted that photo and you said I looked crazy, 
I was worried that my eye strain from the glare was showing in the 
picture. I couldn't see the picture, as I was in it. Having seen 
it now I should have been more concerned about how loose clothing 
makes me look 30+ pounds heavier. By the way, last week was the first 
time most of the REBOL community had seen me, or any met me.

Dide - look at picture name, you will decode it :-) But - BrianH 
is imo the guy similar a bit to the mixture of The Edward Scissorhands 
and Thec Cure singer Robert Smith :-)

Henrik - Anton or Gabriele. Gabriele did text handling for first 
VID prototype, and it was probably more complete, no? But of course, 
Anton is guru here :-)

I am really very happy and well adjusted, which weirds out my friends 
:)

Oldes: Is there something new with Rebcode?


Nothing new, but your requesting it means that you don't remember 
the problems the old rebcode had.

The bad news:

- Rebcode didn't work in R2, it was unstable and frequently crashed 
REBOL, very pre-allpha.

- Carl is unlikely to make a build with rebcode because of the above, 
and because he is focusing on R3.

- R2-style rebcode would be slower in R3 relative to the speed of 
regular R3, partly due to changes in function word lookup.

- Any rebcode dialect for R3 would be incompatible with R2 rebcode 
on a basic semantic level.

The good news:

- R3 has features that will make it relatively easy to add our own 
rebcode-like dialect.

- Even though the R2 semantics wouldn't be good, there are more tricks 
we can do to get more speed.

- The main reason that we don't get as much of a relative speedup 
for R2-style rebcode in R3 is that R3 is faster itself.

I'm looking forward to the reduce/into enhancement. In general we've 
had a lot of clever optimizations through better design, and I'm 
sure there are many more that can go in.

Small status update:

- CureCode is now the official bug tracker for R3.
- Clipboard now supports unicode. This took longer than expected.

- HTTP 1.1 has been degraded to 1.0 due to some problems with 1.1. 
Rebtalk will continue to work as always though. Maarten is looking 
into this.

- Carl is attacking font code (this does not involve altering the 
poor anti-aliasing unfortunately) and text handling, so text areas 
will finally grow up and act like real text areas. This makes Rebtalk 
usable for more than messages. :-)

- Also yesterday, code was added to allow cell based vertical and 
horizontal alignment of faces. It's interesting to see these changes 
in VID3.4: A new feature like this is rarely more than 5-10 lines 
of code, which is a sign of a great design.

- MAX-SIZE won't go away. Instead it might (I'm not sure Carl is 
convinced there is a problem) be split in two. It currently acts 
as both a pressure factor and maximum size for a face, which is the 
cause for most of its problems.

I can explain, but not give you code yet because it depends on user-defined 
datatypes and we don't even have the syntax for those yet.

Perhaps you have noticed that in R2 there are 4 function types, 5 
with rebcode builds: function!, native!, action!, routine!. Each 
of these behaves completely differently on the inside, but are called 
the same on the outside. This is because each of these datatypes 
defines a different execution model. R3 will have allow the user 
to create their own datatypes, and that includes function types. 
All a datatype needs to do to be a function type is to act like a 
function on the outside. How it behaves on the inside is up to it.

User-defined datatypes (UDT) depend on the R3 plugin model (that's 
not done yet either) and plugins are a REBOL module wrapper around 
native code. UDTs can be defined in REBOL code or a mix of REBOL 
and native.

One thing you are missing is that the input data of the MAKE action 
of a datatype does not have to be the same as what is on the inside 
of the value created. That means that you could pass a block of code 
or string containing another language's syntax to MAKE and the datatype's 
MAKE handler can translate that data to whatever internal format 
it needs. This means we can compile.

R2 does not grow infinitely, but it does not hand back memory -- 
it prefers to keep what it's got and use that again when needed.

That is faster than continually handing back and reacquiring memory 
in many cases.

But if an application needs a large amount of memory at start-up 
(or some other peak time), it keeps that memory until the end. That 
is not very friendly!

so I just quit, started back... got me a nice 50MB process and all 
is well.

and sunanda... I've also discovered that it doesn't always recycle 
the memory its got !  image manipulation is an example of that.

There is a bug in R2 that causes a memory leak related to a specific 
use of GUI events and network ports. I've encountered this a few 
times.

How R3 handles memory, I don't know. There are several new debugging 
functions to explicitly let you know what is used and what is released. 
I would guess that Carl has also tried to make sure it's easier to 
find leaks.

I just hope that we can *force* a memory shrink.  I've got an application 
which needs a 900MB bitmap to be generated and drawn on... this works 
in rebol... but the moment I try to allocate a new one... it crashes. 
 the one is never released  :-(

Hm, sounds like one of the root causes why the AltME server can overflow 
the memory and swap space when a slightly larger file is downloaded

exactly :-) Ask sound gurus as Rebolek for details :-) But - Carl 
is very open in this regard. R2 currently uses wave win32API, and 
there seem to be a bug (which we noticed when we tried to do a video 
playback). Carl released sources, which are rather short for sound 
module. Maybe it could be fixed a bit for next 2.x release, if there 
is going to be any ...

It seems that every GUI has a version of Apple's Coverflow these 
days. Flash, JavaScript, JavaFX, even WPF and Delphi. A R3 coverflow 
would be a much better application to test out the GUI than a colour 
selector and a forum client. It would be a great demonstration of 
R3's capabilities.

I've done a basic coverflow layout--no slick animation or reflections 
(too slow under R2 when I tried it)--but fully keyboard and mouse 
driven. Animation could be done, but hasn't been needed yet.

Same he didn't called it xxxBase to go with DevBase and DocBase.

I thought we could release too. Good thing is, that Carl thinks, 
that we need to get many more developers on-board, and so he is doing 
some preparation work to handle the load.

be nice to do something like:

op? second [this + that ] 


and have it return true.  I know it is a word value now but I never 
understood why it was made word there.

The client appears to be a bit over 20 kb of code and is fairly simple 
to use. Still some bugs left to solve, but moving quickly forward.

Even if the server is running on R2, all the strings could be stored 
with a consistent encoding method, such as ISO-8859-1. Of course, 
there'd be a lot of work detecting the client encoding method and 
converting all input strings to the chosen consistent method. Most 
of this work would be needed even if the server supported Unicode 
strings.

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

And yes, it does say something about the design of RebDev, that character 
encoding issues of R2 won't affect it, by design.

This is one of those things where a picture is worth a thousand words. 
 We need a diagram of the hardware and software set up, and show 
WHERE encoding becomes a problem.

For example, if you paste some text from a Word doc into a webbrowser, 
 this then gets moved to the server.  Then it gets rendered out again...you 
wil run into problems with encoding.

Word use some SPECIAL encodoing for things like " : - and '

That sounds like an issue between Word and the browser edit field, 
or between Word and the clipboard

:-) it runs in the iPhone simulator, but it works the same as on 
a real iPhone. If you have XCode and OSX Leopard you can test it 
out yourself.

because it's just a simple HTML page. you can't post yet and you 
can't login to your own account yet like the console version. it's 
meant to be used with lesser browsers for smaller phones than iPhone 
as well.

and it was convenient for Carl since he owns an iPhone.

Reichart: From my point if view, the root of the problem is not so 
much that Word replaces key certain key sequences with other characters 
but on eof character encoding. The text will look okay on your machine 
but unless it is correctly converted may display incorrectly on other 
machines.


As I understand, Rebol/View uses the users default "codepage" on 
Windows and  MacRoman encoding on Mac. AltME doesn't take into account 
the different the different text encodings so when I type £ (a British 
pound sign) you will probably see some thing different.
 .

Peter....I'm confused....

Word, nor REBOL have anything to do with the problem....


Encoding problems happen on hundreds of websites (big, popular website), 
that do not use REBOL, and where Word is not the source.


I'll state again... we need strong clear black box logic that unifies 
all character maps (yeah, all).

WE need a single unified character system.

If I was a betting man, by 2020 UTF-8 will reign and compsci grads 
will need a history book to learn about ASCII.

Reichart, what I mean is that you don't even need tools, as long 
as the server software properly emits only utf-8 and reports that 
it accepts only utf-8... after doing that, if there are still browsers 
that do not comply, then we can start talking about tools (which 
are trivial, most of the time, by the way).

With QM, I try to assume (and enforce) UTF-8 (declaring on forms, 
html escaping everything ASCII+), but it's definitely a chore.

Yes. It's 2009 and we (as in industry) don't even get the computers 
to do *this* for us.

... and me panicking :-)

Another thing - today I asked Carl about differences between RebDev 
messaging system, rmp:// (IOS protocol) and LNS (RebServices). As 
you probably know, LNS is not fully finished, although functional. 
Carl might introduce some small shift to its architecture, to make 
its usega a bit easier.


Some few weeks ago, I chatted with Carl about messaging. While he 
likes syndication of communication channels for RebDev, I think there 
are systems out there, which provide real multi-protocol, multi-system 
syndication. E.g. Python's Medusa, or our Uniserve. As for me, I 
will always prefer dynamic, exensible, run-time pluggable system.


The most important opinion of mine on that is - let's accept any 
such system as a standard for R3 (that does not mean, there can't 
be any other system done by developers).


So, because RebDev messaging is third such system from RT (rmp://, 
LNS the former ones), I asked Carl to make some higher level decision, 
if possible. Carl agreed, and said that it would need more developer's 
input, probably a virtual conference.


... we have networking gurus like Maarten, Gabriele, Robert, DocKimbel, 
who worked on some such frameworks in the past. I would like to know 
interest of ppl in such a topic.

Petr, I agree on having one such system as the R3 standard and not 
to fragment right from the start. I think RS is quite good and done 
for 80%? So, using this, finishing it and than polishing it should 
get a pretty good base for everyone.

Robert - discussion of you, networking gurus is needed. I don't know, 
where is the distinction of transport and service layer in LNS. If 
LNS is mostly services layer, which can be used over whatever transport, 
well then. But if not, why not to go with some multiplexing engine 
like Uniserve, which, via plug-ins, dynamically can "syndicate" (interconnect) 
us with the rest of the world - IRC, Jabber, ICQ, http, SOAP, webservices, 
whatever ...

Uniserve works at a lower layer. You can implement LNS on top of 
Uniserve, and RebDev on top of LNS.

hmm, but LNS is also a transport in itself. It at least can work 
upon http and cgi ...

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

and are there any specs on how to use the rebol.dll itself outside 
of the environment RT is building?

Petr -- But there needs to be some evidence that the project is still 
alive and deliverying.
A one-year old public alpha is not that.

yes... I am doing so right now... implementing the windows bitmap 
handling and gdi is *NOT* fun.

I always tought that the load/save refinements for library and image 
formats was pretty strange.

I think, that having really good /library component could bring us 
many more wrapped external libraries - call it a deployment. Currently, 
we are missing on most of outer library stuff, and we are living 
in rebol-only world.

Maxim - not much word on it. I do remember there was posted main 
wrapper even for R2 (look at plug-in groups here). But, there will 
be both .dll and also object file for static lingage with R3.

I am slowly working towards elixirOS and that is a C version of elixir 
with rebol being the conscious brain, driving subconscious C datatypes 
and binary code...

not ready yet, but just wanting to see where things are now, so I 
can place my time and efforts properly.   Already started to look 
at OpenGL a bit and started doing C++ again.

one question - isn't there any cute, cross-platform C compiler, which 
would not add more than 30KB to REBOL.exe, and could be included 
as a variant of rebcode? :-)

yess I did, but in this case, the goal is to do interactive AGG manipulation 
of one image at a time and stamp it on a layered composition.  by 
the time I load the third image (from a digital camera at 7.1 MPixel), 
rebol crashes  :-(

(well maybe more than 7.1MPixel. but anyways... the fact that REBOL's 
memory footprint grows everytime I do load on a .png... and never 
shrinks... means it will eventually crash, whatever I do  :-/

And then I call 'recycle .. and boom!

Maxim, does it also happen if you load it into a pre-allocated binary 
and clear it when you're done?

Maxim, no forget my question (takes too long for me to come up with 
a solution, and I must get back to work).

when I was doing my app, I was able to break rebol just with a make 
image! and some use of it in a function... but right now... can't 
remember the exact pattern I was using... calling make image! 10000x10000 
twice is currently behaving correctly, growing to 800mb and shrinking 
back to 400mb

and using 'recycle actually throws the bitmap data away... so I just 
look dumb right now, cause I can't figure out exactly what pattern 
led me to give up... but anyways, I tried getting it to work for 
3 hours... and it always crashed, because of memory footprint... 
 ' :-/

image magic rendered the equivalent of 100GB of image data for 1h30 
at 100% CPU usage (and only a few hundred MB or RAM) and didn't fail... 
so I was very impressed by it, in any case

I'm having a memor issue too.

I have an app that uses a scroll panel that I fill with text and 
images (a "page"). Each time I change the panel data (the "page") 
the memory footprint increases. But If I reload a "page" that was 
previously displayed memory size  does not change.

I can see if the memory holding the "page" does not clear properly 
but how does it know that the "page" is already in memory?
I'm holding the composed data in a block - 
	page: copy [ composed page data ] 
and I clear it befrore rebuilding it - 
	page: copy [ ]

I'm changing the content (text and images) of the page each time 
I "show" it in the scroll panel. And each time I "show" a new "page" 
memory use increases but if I re-"show" a page that was previously 
viewed memory use does not change significantly.

I am not very experienced in how making bindings in various scripting 
languages work but I have fiddled around this a little... python 
by itself doesn't do anything automatic I think - and to my knowledge 
python isn't the best example of easy binding to c libs, but there 
are comunity provided tools that help you generate the interface 
code etc...  most people I saw used SWIG (which works for a lot of 
languages) http://swig.sourceforge.net/.. but the chat was that 
if you use that tool you geet quite a bloated code for interface.

many people link the stuff on the C side and recompile python itself.

If you want to look for languages that provide very elegant way of 
making bindings you should to my knowledge look at Lua (lua started 
with this) , lua provides simple to understand stack approach. Then 
there is haxe which provides even more elegant way to do this . Both 
languages also enable to embed the VM/interpreter into C++ app. I 
have used both to do both and it was very simple as I am not a power 
low level programmer

The most elegant binding I have seen so far was done by Factor .. 
there you don't even have to "code" in a classical sense, you just 
define the interface and that's it ... as I said I am not very experienced 
in all this (I hacked factor's sqlite binding and to add another 
c function inthere I just added 1 line.)

Would be nice to just pass the arguments to a rebcode module and 
have it pass them back.  Even giving rebcode networking features 
might enable that.

But I would think it would be somethign that he just drops in and 
compiles isn't it?

I think that TCP/IP is pure async and HTTP also, but functions like 
READ would work in a synchronous manner.

... yes, and it seems to me we are aproaching the release .... slowly 
but surely .... http://www.rebol.net/wiki/R3_Alpha

Petr (from Ports):
http://www.rebol.net/wiki/Port_Implementation
http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples(a good one ....)

http://www.rebol.net/r3blogs/0127.html"Pruning down Read and Write"
http://www.rebol.net/r3blogs/0128.html"Skip and Seek on ports"

http://www.rebol.net/r3blogs/0129.html- async http transfer using 
tcp

http://www.rebol.net/r3blogs/0130.html"More about port layers" (continuation 
of Pruning down Read and Write article)

sounds like some good stuff to put in notes and upload to the 2.7.7 
world

Re; LOAD; well yeah ... TRANSCODE can be used to support junk! now. 
 ;)  You'll love it Brian, really.  You can have your grandma asking 
you questions about deep deep PARSE problems as she dances around 
the console analyzing her grocery list, while you point out that 
the total is actually wrong due to a lexical problem with some of 
the money! values.  Then, 4 months later, she'll teach you something 
that her new perspective and point of view made possible as she unveils 
the world's greatest home management software ... like evv-a.   :)

Sorry BH, I meant junk!  and a version of REBOL that loads any value 
any time any place by anybody.

And do dis' meant toward grandma.  I would have guessed she had IQ, 
many times it is a family trait.  ;)