AltME groups: search

Vector types take up less space for the same data, and you don't 
have to use type tests when working on them. They're for fast processing 
of numeric data, conversions, all sorts of low-level goodness.

I suspect things like audio samples and very large data sets (geographical 
data, 16-bit image data) could be used for this.

Why not math? Because all of the alpha 51 changes were implemented 
in one night (afaIct), and because noone has suggested it yet.

And asking for it here doesn't help. Put in a CureCode ticket with 
proposed semantics (equivalent REBOL code is fine).

My point is that it is much more likely to get implemented as an 
action!, and actions dispatch based on the type of their first argument.

That's what I mean. It's an implementation detail, but it could be 
the difference between having this feature and not having it. We'll 
see.

I must admit I haven't used CureCode for about 3 months I think. 
And my vector! document on R3-alpha precedes CureCore for about a 
year. Because no one but me payed attention to vectors for so long 
I never cared about rewritting those requests to CureCode.

But it's nice to see some progress in this area, I'd like to experiment 
with vectors bit more and post some new tickets to CureCode :)

That's the point Pekr, If we can't convert vectors to binaries (and 
the reverse) it's useless

It's not exactly true that they didn't worked at all. I was able 
to do drum and subtractive synthesis plus AIFF/WAV loader/saver with 
vectors. It was just NOT easy :)

Having the ability to apply some math and matrix operations over 
vectors would be nice. Having the ability to use such functionality 
to modify some binary (e.g. image) would be cool too.

I can only emphasize the importance of submitting Curecode reports. 
Curecode is the only place Carl looks, and he personally thanked 
me for submitting the /SKIP reports, which are now all fixed.

Curecode scales better than AltME's bug tracker and we can comment 
bugs.

CureCode makes the job of reviewing and tracking bugs *much* easier.

Well, I can write anything, it is just that in order to properly 
specify such stuff, you have to understand the topic, which is not 
my case. Maybe you could write it down to text file off-line, and 
once connected send it over the email to someone here, who would 
then put it in CureCode ...

oh come on !!! i'm just asking for scalar math operations, like it 
works on tuples and pairs

It's not a big deal. Steeve can post to Curecode and request for 
a clean up.

note that the code is from Oct 2007 and probably won't work in current 
alpha.

I'll post the links and say they are from you. Seriously, participate 
:)

Louis: You can redefine browse at R3
browse: funct [ url ][ print ["Can't open "  url]]

So when you write docs o bugs command you'll see the url and can 
copy and paste to Firefox or Opera

Louis: Better solution
browse: funct [ url ] [ call reform [ "x-www-browser" url ]]

And browse works, and all commnads based on browse ( docs, bug, changes 
) too

Is anyone else following the Rebol3 blog using the Google Reader? 
 Its the only blog that i follow in which the text is poorly formatted. 
 Basically the entries appear as one big paragraph., and is hard 
to follow as a result

I don't think there is a big chance it will be fixed by Carl right 
now. However, if you get the source and provide your own fix, it's 
likely that he would use it.

I use Safari's RSS reader and it's badly formatted there too.

I was going to compare the output of his feed to that of Monologue, 
and make it match. Monologue works in Google Reader.

What happened to the system/user object?  I just downloaded Rebol 
3 a-51 and it's not there anymore.

Brian - Carl did some change to module creation and referred to objects 
too. I know that you are after context spec changes, so just a reminder 
to watch Carl's changes :-)

I recently skimmed over a *new* implementation of multiprocessing 
in Python 2.6 and 3.0. Really new. Great model - it could be how 
tasks work in R3

Henrik:<I can only emphasize the importance of submitting Curecode 
reports.>


If you look at some very recent bug reports (numbers 700 -- 799), 
over half of them have been resolved, often within days
    46 built and/or tested (ie fixed) 
     8 dismissed (not actual bugs)

There seems no better time to report R3 problems than now!


The rest are Reviewed, Deferred or Waiting.....So still on the action 
list.

There seems to be bunch of fixes for A54 coming. I really like the 
progress of last few months. While there is still lot's of work, 
some areas are getting fixed and being really usable ....

Most of those are replacements for FIRST, SECOND or THIRD for objects, 
fuunctions and such.

That guys post tickets related to bugs on ports which are not.
And Carl seems trust him, My...

I was exacty wondering the same. IMO there shoud be Carl, and few 
other moderators, as BrianH, Steeve, Ladislav ....

there there pekr... dont start down that negativity path... we all 
like the new and happy pekr   ;-)

yes... decimal! should be BCD and we should have a new float! type 
which equates to current decimal


if no current R2 is going to be compatible anyways... I think this 
is a good time to fix this issue once and for all... its always been 
an issue, since core 1

Steeve: <Geez, who is Meijeru ?>

Someone who posts the bugs he finds ..... And gets them attended 
to.
Not someone who thinks bug posting is ineffective :-)

i made a script with R3 which vectorizes simple images (initialyy 
to build vectorial fonts usable with the draw dialect) 

I used a lot bitwise operators like OR and XOR on that images as 
a prefiltering process.
I can put in the te trash my work now.

Steeve, cannot you just get the RGBA raw data and do the math on 
it instead of image directly? Also is your script available. I have 
own script for making vectorial fonts from bitmap but it works on 
black and white tracing (in rebcode)

Oldes i used XOR operator on black and white images of letters to 
extract the contours

BrianH: it is a strange situation - we are giving up on some "polymorphism", 
and replacing it with more functions to get the same reflectivity. 
No more first, second, third, etc. working on multiply types, but 
instead using values-of, words-of, etc.

I don't understand, why XOR and OR should be removed from functioning 
upon image datatype?

We got a lot of port! bugs fixed - and tickets usefully documented 
through their dismissal - thanks to Steeve.

My experience is, that Carl works in his own world, and it is good, 
we communicate with him via some "API" :-) E.g. I had to mention 
article about the need to use better timers (not done yet) for something 
like 3 or 4 times. Then, when I found the right time and his mood 
to actually look into it, I think that he agreed that there is better 
solution than what we now have ...

We needed the system object changes for modularity and security too. 
Once we clean up for those, multitasking won't be that hard.

http://www.codeproject.com/KB/system/timers_intro.aspx


we imo need multimedia timers, definitely. So "small" change can 
make big difference. We don't ned to look pre W2K imo. And it is 
crazy that MS has all this mess in their API. The good thing is, 
that timers are host layer, so community can advance it ...

could this help in R3? http://www.cilk.com/The Cilk++ cross-platform 
solution offers the easiest, quickest, and most reliable way to maximize 
application performance on multicore processors.

The reason Carl is focusing on these simple datatype changes now 
(like vector!, image! and money!) is because they affect rebin, and 
rebin not being done is currently what is blocking the release of 
the host code.

Well, if Carl uses CureCode, I should post Timer related ticket probably 
:-) ... and maybe BlitJit/AsmJit ones too :-)

FIRST+ takes a word that refers to a series and it advances the word 
to the next position while returning the first value.

Here's the R2-Forward version:

first+: funco [
	{Return FIRST of series, and increment the series index.}
	[catch]

 'word [word! paren!] "Word must be a series."  ; paren! added for 
 R2
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? :word [set/any 'word do :word] 
	throw-on-error [also pick get word 1 set word next get word]
]

Pekr, you have the sources of func and funco in R3

funco: make function! [
	"Defines a function, but does not copy spec or body."

 spec [block!] "Help string (opt) followed by arg words (and opt type 
 and string)"
	body [block!] "The body block of the function"

][ ; For functions known to have no syntax errors or recursive issues.
	make function! spec body
]

R3 alpha 54 released...... Two days after A53, and 32 curecode issues 
addressed.
That's fast work!

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.54_14-May-2009

continuing discussion in I'm new group...


brian: no R3 chat account yet... its basically that I'm keeping my 
energy.  I really would love to participate more in R3 but since 
most of what I do is commercial (REBOL), time invested in R3 is severely 
lost in the short to medium term.


but I think its now progressed enough that I really should participate 
more.  


I think I have a lot of insight to bring to the table since I'm one 
of those few developpers who has been using REBOL commercially for 
just about ever, I've been using a module clone for the last 7-8 
years,  built 4 complete view engines (even ported glayout to python 
;-),  implemented some of the largest apps (code wise), and have 
several dozen REBOL APIs under my belt.

I am reviewing the module system now (well, not right now since I 
am working). We have tried to balance simplicity and security, but 
I think the way we did that balance is to have two extremes which 
you can choose between with one refinement. I'm checking whether 
the simplicity extreme is too insecure, and whether the security 
extreme is too difficult to use.

The reason I am checking this now is because it is time to backport 
the module system to R2. The code is pretty easy (and mostly written) 
- the design issues are not. Since you've written a module system, 
your input may be valuable.

my input can be on what I did and didn't end up using afte 7 years... 
some features sound great on paper, but then don't really get you 
more productive and some features I've never used myself.

It's funny to see Carl wondering why there is not more requests related 
to the use of external libraries in R3.
Not so funny in fact.

If that feature, had not been discarded in R3, perhaps there would 
be more tries and more requests.

Alpha. And the new model won't be compatible, though there is a proposal 
to make a plgin that implements a variant of the R2 FFI.

But Steeve is right - I had to correct Carl - the motives were quite 
different: some few weeks ago, he said that we should write it down. 
Once done, he said he tried to design plug-in interface, and got 
some issues with dynamic code like draw. So he worked on another 
proposition. I asked for more info, but he said he will release it 
later, because it had wider consequences ...

Did we ever reach a conclusion about Rebol scripts .. and to distinguish 
R3 vs R2 scripts?

There's nothing enforced about that, but it's good practice, and 
file association friendly.

we should skip R4 and go directly to R10  or should it be ... RX 
 ;-)

More or less. The linux and osx versions are much more alpha than 
the windows versions. Lots of missing functionality.

Please keep trying. It may time out 10 times in a row and then it 
comes.

What are all the types of procedures calls that R3 will support. 
 I'm assuming that pass by value and pass by reference will be there 
but what other forms?

Carl hasn't revealed that yet - which is why I keep asking for "in 
depth" explanations. This is another of those cases where Carl goes 
into a cave and comes out with something that is (usually) awesome. 
Design mode. He hasn't gotten to explanation mode yet.

The problem is that the R2 DLL interface sucked. One of the base 
requirements of the R3 plugin model wass that it be powerful enough 
that you cold write a generic wrapper dialect as a plugin, and then 
use that dialect to specify the API a DLL.

To write a rebcode replacement all you need is user-defined types 
and the knowhow - it's on my todo list. However, user-defined types 
will probably need to be defined in plugins, and at the very least 
we couldn't even specify how to define them without a working plugin 
model. So it will help, indirectly :)

Objects as a base type blog = documentation of the way things have 
always been, not a sign of things to come. It was probably in response 
to bug#838 and my reply to it.

Once you have plugins and commands, there may be less need for rebcode! 
- you can just write natives if need be. The reason for a rebcode 
replacement then would be security (not rebcode's strong suit), since 
rebcode would be managed code.

He doesn't say, but I expect GCC on *nix and OSX, and I'd be surprised 
if he wasn't using MSVC on Windows. REBOL has been around much longer 
than GCC has been usable to build normal Windows apps. We'll seee 
soon :)

what do you call words such as "back" and "tail" and "next"?  Is 
there a special term were using for these?

if so, there should be a way to classify them in a helpful way in 
documentation and help

These functions have been part of the recent debate over series! 
and its types...

if it isn't doable just update the ticket to state such.  I just 
wanted to get the wish in there in case I think of it again and forget 
we discussed it.

>> series
== [1 2 3 4 5 6 7 8 9 10]
>> series: back tail series
== [10]
The AT is implied by TAIL, and then again by BACK.

I had it written down from something I had been working on.  Go ahead 
and resolve the ticket if you like - if I come across the problem 
that resulted in my notes then we can revisit it.

I got two conversations going on - one here and another with Graham 
on his server.

Naw, the navigational functions are just functions for series - except 
++, -- and FIRST+. They are only modifying for ports. By design :)

(continued from !CureCode) When the time comes, the Parse Proposals 
will need to be reorganized so that there are separate sections for 
general operatioons, and for the operations that are specific to 
blocks, strings, binaries, ports. At the very least, there needs 
to be good binary pattern recogntion operations.

In R2 the underlying data of strings and binaries is the same: bytes. 
In R3, strings are made up of Unicode codepoints, binaries of bytes.

I too i love parse and i'm sad to not understand it enough to exploit 
it to its extend

and that's the kind of application where the use of parse to colorise 
the text would be fantastique

and 1 color for private message

you could enter 5 différente channel and see them all in the same 
window no need to switch channel to follow it

i will do a treeview with the server name as root and as leaf channel 
name you entered clickin on root you have the server messages displayed 
clicking on leaf you have the channel displayed

Actually, the first optimization i do in my scripts which need speed 
and low memory usage, is to remove all the reduce and compose usage.
It's always the first thing i do

Now, you will be replacing REDUCE and COMPOSE with REDUCE/into and 
COMPOSE/into and preallocated or reused buffers :)

but this optimization isn't always possible.  when nests are deep 
and composes are chained within each other, you can't just chain 
insert and remain sane  ;-)

although liquid-paint is already much faster than AGG and lazy so 
the gains might not be as noticeable, but still I can't wait to have 
time to try and port my stuff to R3, it does seem to be much more 
series stable, by all accounts.

Nested REDUCE and COMPOSE is not that common outside of code generation 
and nested data structure creation. I do that a lot, but I write 
my own mezzanines and some of them compile internally. I can think 
of many mezzanines that could be sped up with /into.

Actually, i'd do a test and choose the faster ;-)

Yeah, REDUCE/into and COMPOSE/into were designed to replace chained 
inserts or appends. They're pretty common in optimal code.

I just re-read docs about plugins and devices, and I still wonder 
what is the main difference? Are devices just for I/O? Because devices 
do use commands too. But - devices just don't define new functions, 
whereas plugins might do.

thanks. I just have a little problem understanding 1), but never 
mind. So plugins are superset, the ability to extend environment. 
And as they can contain REBOL code, C code, they can contain even 
Device in itself? Well, it will be better to wait for API docs probably, 
to see some real-life examples ....

Basically, the difference between plugins and devices is that pluugins 
are code that wraps code, while devices are objects that wrap hardware.

We need utypes for host interoperability, to replace rebcode, and 
more. A utype will need to be able to react to the actions, just 
like a type

Right. R3 is built like an OS. And designed by the same guy who designed 
*that* OS. It might follow a similar model.

Brian - ticket #588 does not crash here. It just takes lots of time 
and resources to display 20x9999999 size button :-)