AltME groups: search

I would if he were talking about DevBase (and did), but I think you 
are overestimating just how long it will take to write. We aren't 
talking about a web forum here, it is clear from the blog that he 
is talking about a R3 GUI client. He can knock that out in no time.

Now how to force a client update each time you change some functionality?

Perhaps the client should download the source each time ...

One rule to learn is never to trust time tables from Carl.

Not at this time, no. I think that will be left up to a 3rd party 
to do such a thing.

You might need to deal with that anyway. I find myself needing to 
place a number on how many columns I need most of the time, and how 
hard is it really to type a single digit? :-)

Graham, in case you missed it: The BBS gave a good range of bugs 
to fix. It was probably built in half a day. The rest of the time 
was (and still is) spent fixing bugs in the core and my skin. We 
are not "wasting time".

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.

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 i turned crazy long time ago

ahah, i like to waste my time

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.

I could never afford to go before, but next time I might make it 
:)

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!

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

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.

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.

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.

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  :-(

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.

Paul, I don't know. I don't think he wants to spend much time in 
2009 on R2. The schedule for R3 is pretty long as it stands.

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

The debugging problem is that the locality of the error is lost. 
By allowing invalid data to be loaded, you put a timebomb in your 
data to be triggered at some later time, by code that doesn't see 
it coming. You want errors in your scripts to be triggered as soon 
as possible, and as close to the source of the error as possible, 
or you'll never find it.

depends what your problem is... really. 


 I've had scientific data which was 100% compatible with rebol expect 
 that it used "," to separate things.


having to use parse for that was both tedious, and for me at the 
time, extremely complicated.

but I would like to USE data which has some of it... which isn't 
even code, most of the time...

[

, "]", "/" and "-" were chosen because they can be typed on a US 
English keyboard without using the shift key. The fact that you can 
program in REBOL without using the shift key most of the time speeds 
up your typing of REBOL code (though not the name REBOL).

If I had known English and REBOL the same amount of time, I would 
be able to read REBOL quicker because the rules are stricter, and 
because I wouldn't have to look for periods and commas. This goes 
more so for C-like syntax - even slower to read.

Some time ago we discussed this on a blog post.  Carl had some valid 
concerns about "where to restart the lexical scan", but I trust him 
and you and Gabriele to get that right, in an explainable way.   
So yes.

But now it's sack time for me and I've broken a promise that I'd 
keep quiet on the issue (for another 2 months ... then I'll whinge 
again)   ;)

not anymore, I guess I should get involved again, now that I have 
some time for it.

what about sound ports in R3 ?
have we the same bugs (unable to do streaming in real time) ?

I have to spend more time not less to see what's new...

kib2: why? Perl 6 is in development two times the R3. And one year 
ago there was a public alpha. Soon enough there will be another one. 
This time with final GUI architecture (although not complete yet)

kib2, I know, but as I can see now, making a programming language 
is no picnic. This is the first time I've witnessed it close up. 
There is still a long way to go.

When we use to block! on input data, most of the time we don't want 
 duplicate them if data are already a block.
(we use copy instead if we really want that behavior)

i think to block!, to string! , form and some other native conversions 
should never duplicate the data if they already have the correct 
format.

This, should limit the memory overhead in many scripts or mezzanines, 
and save us from coding many useless tests.

I tried timing tests on my R2 ad R3 examples.
R3 runs in about half the time. 

Conclusion: 'continue is a good optimisation over loop 1 [...break...]

That does not say anything about the overheads of 'continue.....Just 
that an extra loop is an extra overhead.

Right Brian,  but more the client grows more it will  need time to 
rewrite it.

The hard work doesn't come from the replacement of blocks with  virtual 
blocks (it's minor).

The problem comes from useless needs to reload and sort blocks in 
memory after each connection.

Outside the big respect i have for Carl, it's a poor conception, 
sorry.

Paul, i can't test the perfs currently, because there is some remaining 
bugs in the file scheme, so that i have to open close the ports each 
time a value is append in the block.

brb (shower time)

ot, Brian: could you have Carl build a 2.7.7 alpha/beta with all 
the work you have done? shouldn't take much time for him 8)

Question for the community:

It has been a long time since REBOL 2 was first released. Is it finally 
OK to remove the ELSE native from R3?

rebol is both very small and very big at the same time

hm.. I would be a little disapointed to :(  ... but when will RIF 
be available then.. isn't time in general problem with RT

his loading the full database in memory, in 2 different blocks (the 
second one rebuild and sorted each time you connect)

A couple things to realize:

- The chat client can change easily, independent of R3, and does 
change daily.

- Our priority is on making the public release happen ASAP. Chat 
reaching its limits is months down the road at worst. We have time.

For some of us, outside of work time of course.

The chat database will be tiny enough for months. We aren't even 
done with the feature set. The internals can change easily. There 
are less than 700 messages, and we don't start having problems til 
100000. I think we have time for this.

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

Steeve, exactly as I said, it is your opinion that you don't want 
to be efficient. It is my opinion that I want most of the time.

Can anyone give a range of time where rebol 3 will be released? If 
not, can I just be notified by email when it is?? I'm sick of logging 
onto rebol.com and checking the blogs. I've been doing this for at 
least a year and I'm sick of it.

I think I know what is wrong: Carl is thinking near the speed of 
light, thus time slows down for him, so while it takes two months 
to get the next R3 release to the public, it only takes a day for 
him. :-)

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

Nicolas, you could do what I did: Instead of waiting, help. If you 
passively wait you get back exactly what you put into it. All of 
that eagerness was wasted energy that could have been applied to 
helping get R3 out, or writing documentation, or even discussing 
semantics here. Complaints are a waste of time that could instead 
have been spent volunteering.

yes Paul , it's an alpha, help us to add many improvements, documentation 
or tests if you have time to do

I'm not sure how much time I will have.

Primary issues with the GUI:


- Layout resizing can result in too much horizontal stretching and 
too little vertical stretching.
- Style list is very incomplete.
- Keyboard navigation is very sparse.
- No rich text editing.
- Skin will become more esthetically pleasing later.

- Some nasty bugs in the low level graphics engine, not yet solved.

What is not likely to change:


- The design of the system feels very solid. Every time a change 
or addition is made, it's 5-10 lines of code.
- Style creation process, so feel free to make your own styles.

What is likely to change:


- The layout engine gets new features now and then to simplify the 
dialect.
- Popups, dialogs.

Brian, I'm critical of how Carl and the dev team are handling things 
at this point.  At least from my perspective this project is being 
managed poorly.  The rollout to the new developers to test and provide 
feedback is not being equipped with a "hit the ground running" gameplan. 
 In order for anyone to know what a function is they must source 
it and they have no access to examples.  Sure we can eventually figure 
out how the code works but that comes at a cost to each of the new 
contributors in time and energy when this could have been facilitated 
by others of the reb dev team.  Regarding, the mezz functions, I'm 
glad to here they won't be built inside the main bin and includes 
as modules.  That is good news.  Regarding, chat, Carl needs to run, 
not walk, away from using console for chat.  The more that console 
chat is used the more concerned I get a feeling that R3 is a mirror 
of that same level of usability which is not a good impresion.

I found two bugs, one issue and a potential language enhancement, 
all about the map! type, all during the writing of one function (REWORD) 
that many people may not use - it might be one of those functions 
put in a module that isn't loaded by default. Still, time well spent 
if it makes map! better for all of us.

Graham, an issue with 100% CPU usage every time a GUI was invoked.

March is fine for me.  About that time I really expect my project 
to be in a mature state via 2.7.6 and can then hopefully begin porting 
at that time.

The above have been submitted. Time will tell if they are accepted, 
or will be included by default. They work though.

I hope you realize that every time someone says "people have to think 
differently" that excludes the vast majority of programmers.

I haven't asked. He posted less than 30 mins ago. Probably same time 
as the Linux version.

never mind, I forgot to type the user name. :-) it's been a long 
time since I last had to log in.

I think it is the amount of movement via the index that is time consuming 
for the other method.

And I didn't fine remove to be better consistently. Clear won half 
the time with the same code.

I submitted a tweak to dp that improves the accuracy, but the profiler 
is too inconsistent to time differences this small well enough.

Yes, I reported it some time back.

something related, in the past i made some tests to simulate hashs 
with integer keys in R2. I used a bitset as an index, mixed with 
block of blocks to store data.

my tests show that for 10000 records,  finding data is near as fast 
as with hashs. 
actually it's incomplete but you have the idea with this:

REBOL []
f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
] 

t: now/time/precise
loop 10000 bind [flag random 99999] f
print now/time/precise - t
t: now/time/precise
loop 10000 bind [flag? random 99999] f
print now/time/precise - t

At least I think Carl was somewhere talking about that. And that 
it could for example speed the boot time, which could be useful for 
cgi aps.

Yes, it's been like this for some time, I believe.

You would not be able to recall the position of the subblock. You 
would have to recalculate it every time.

Also I'm pressed for time for about another month.

Most of the time a function using build/into functions will preallocate 
a series, build some data into it, then return the series. Builder 
functions can use lower-level builder functions. You get a reduction 
in intermediate series creation overall.

... untill there is GUI to DevBase, many ppl will prefer Altme channel 
for quite some time ...

I was speaking on Gabriele's behalf dring that time because he was 
busy. Now he doesn't answer these questions here.

I've spent some time thinking about that in the past, and it's difficult, 
if not impossible.

Ok, so you as the programmer know that your table has a specific, 
static order at the time you need to fill it. No problem.

Must go - exercise time.

Well, I change button colours all the time trying to direcct users 
on which path to take.

I'm very carefull of colour blind issues, have been on all my interfaces...simple 
trick in the old days was to view it on a B&W TV or device.

Now I have to take screen shots from time to time nad review with 
no saturation.

There is surely still time to talk about those things for R3 gui.

Time for everyone to update their phones then.

That's why the only alternative development platform fot the iPhone 
is based on Mono: ahead-of-time compilation with static linking.

ammon, image loading is not available at this time.

Specialized is good. Let the programmer decide what they want to 
do at programming time, not the interpreter at runtime.

The error that has occurred above is that the "demo-let" that kib2 
looked at is not properly documented. Its script header should declare 
what its dependencies are and in what environment it should be run. 
This is a constant source of time-wasting for everyone, as an undocumented 
script apparently advertises that it has no dependencies and can 
run on its own. So all new-comers to the script will try it in the 
console themselves and see it doesn't work. Now the wondering begins: 
"is it supposed to be working or is it still in development?" etc. 
It's not kib2's fault for not having studied how the R3 GUI works.

I find I'm using the help function in the console all the time. It 
would be good if the help function could have some refinements for 
searching throughout the function definitions, or limit the search 
to specific parts of the definitions. Would this be a difficult enhancement?

I have a long time proposition for help on dialects. Imagine e.g. 
VID, where styles do have help strings too. Gabriele proposed:

help/vid button

... whereas I proposed: help/dialect vid button

Not sure, if we can make help system pluggable that way?

Typeset! is a new datatype in R3. Function argument type specs are 
converted to typesets at function creation time.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

well, if you can believe it, I've been "following" REBOL since it's 
beginnings, but never really pursued a deeper understanding of it 
due to various reasons (lack of adoption, closed nature of the language, 
lack of time on my part, etc). I have always, though, felt a very 
strong attraction to it because of all the possibilities hinted at 
- the lightweight nature, the clarity of expression, the built-in 
GUI, dialecting, and so on.

with R3, I'm trying to take the time to really learn it - I'm also 
learning patience at the same time

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Steeve, one of the problems with multiple value replace is that there 
are basically two ways to do it:

- One value/replacement pair at a time (like your FOREACH loop above).

- In order using either an inner loop of FIND/match calls, or PARSE 
rules and alternation.

Neither of those are very efficient, but the PARSE rules tends to 
be more so, at the expense of building the rules. REWORD uses the 
compiled PARSE rules method. Most of its overhead is working around 
bugs in map! or going away with new REBOL features. If we do an inplace 
replacement, we'll have the same overhead. The only solution is to 
optimize the runtime, or hand-write the PARSE rules.

I have some questions regarding timestamps on files.  They look like 
they are all GMT and don't take into account what time zone you are 
in.

To my way of thinking, they probably should default to what the system 
is doing.
For example:
Create any file TEST.r in your what-dir
>> GET QUERY %TEST.r

== [%TEST.r 7329 13-Mar-2009/20:26:42.429 file]		<-- notice the timestamp 
is not CST where I created this at 3pm, not 8pm

If you look at the file through Windows Explorer, you will see it 
is dated at the local time, not GMT.

Do I need to subtract 5 hours (DST) or 6 hours, depending upon my 
timezone and if we are on Daylight saving time?
Do we have some refinements or another way to handle that?

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

Ammon, it sounds simply to me that some features for setting window 
titles, etc. are either missing or undocumented. I'm pretty sure 
you're not meant to use obscure paths to access features, but to 
use SET-FACE, GET-FACE, SET-FACET and GET-FACET. These features are 
much more powerful in the R3 GUI than the ones in VID.

And if they're missing, it doesn't take long to add them, so instead 
of "getting annoyed as hell", ask nicely on rebdev and Carl will 
probably find some time to add them. :-)