AltME groups: search

Bolek, it's mentioned in a comment in the CureCode ticket which thought 
'- referred to unsigned (probably the motivation for the change). 
It's otherwise undocumented as of yet.

If it's not in a CureCode ticket, the sggestion doesn't count.

Steeve, the basic math operations generate new values, they don't 
modify in place. This cold cause a lot of memory overhead. Modifying 
operations might be better to do as functions, perhaps even native 
functions loaded in plugins.

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.

image/rgb returns a binary serie

Has anyone tried to-binary of a vector! in alpha 51 yet? Don't knock 
it until you've tried it.

Vectors have been put on hold for a year, they didn't work at all. 
At first means since two nights ago.

i have a very slow connection currently, most of the time i'm disconnected 
-_-'

Brian --- R3-alpha is archived on REBOL.org, for world-members only 
(ie the same read rules as the AltME version itself).

So good news -- we have a persisent archive of that world: no need 
for Rebolek to rush

But bad news -- not many people can see it -- so any gems do need 
to be ported to more visible locations.

Yes, I will. I just miss the easiness of doing that from Altme, I'm 
not a big fan of web-services :)

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

I think I get what Steeve is requesting. If he doesn't get it submitted 
by tomorrow, I'll have a go at writing it up.

lol
>> v: make vector! [integer! 16 2 #{01020304}]
== make vector! [integer! 16 4 [
1 2 3 4
]]


Brian, no Big endian, no little endian, it's a new format: little 
byte

How do I fix this:

Couldnt get a file discriptor referring to the console.

That should open a browser window, which may not work under Linux 
yet.

Interesting. Curecode reports a very different issue in ticket 710.

Wait a minute: Are you typing the browse command in R3 or in the 
shell? You must type it in R3.

It won't help in the shell, so it's a BROWSE bug.

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.

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

The system/user object was removed in the great system reorg of alpha 
46. The only setting in system/user that was of any use was system/user/home. 
That setting is likely to be put back somewhere else, probably in 
system/options with a different name.

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 noticed that. I'm giving it some thought - it seems like a cheap 
fix, but it might not be bad. The HTTP scheme needs some work.

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

ordinal accessors still exist in R3:
    fifth [1 2 3 4 5]
    == 5

(There's a discussion in Core about them no longer working with money!. 
But that's the only case I know)

having money descriptor is of no value for general math. It does 
not do any conversions either, so there is imo very little value 
in money! (datatype :-) - just a cosmetic visual representation

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

Maybe if you develop banking or other financial applications, money 
datatype could be very nice thing!? Some things are not useful for 
all of us, but very useful for a few of us. (I haven't used money 
datatype myself.)

if the issue is code maintenance, I think its not a good reason not 
to fix this.

I haven't used it, since the readability of the currency string is 
not good. However if you drop the datatype, parsing dialects with 
money as numbers would be a little harder.

money is usefull, just that it doesn't replace a real BCD type.

I posted a comment with an idea, but i'm afraid there would be too 
much drawbacks in the core. It's hopeless...

that was a strange reaction on Carl's part, but I think its consistent 
with how R3 is being developped.... do not let incomplete features 
creep in releases.

R2 "incompleteness" in one of the major reasons why many initially 
love the language, but after they try to build a "serious" app, they 
discover that some things need to be fixed.

for me, R3 is a real attempt at delivering a finished product.  probably 
the first time since rebol's creation.

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.

maybe your will be a case to put that higher in priority  ;-)

For my revenge i posted a puzzle

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.

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

There's a bug too, with mold of vectors.

I think that we need - plugins, security, gfx, gui, few protocols 
(later some engine like cheyenne inside), well, we need many things. 
Also current implementation of codecs is absolutly useless, no concept, 
just a workaround ...

BrainH: I'll point you to one article, wait a min., I need to find 
it. Actually - it was Cyphre who found it IIRC.

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

It's a speed/simplicity thing.

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]
]

funco remains me pulco citron (pulco citrus) a beverage

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
]

That's why the only function creation function with a refinement 
is FUNCT - since it does so much work anyways that the refinement 
overhead is much lower in comparison to the rest of the code.

Then we need new format supported in native code - having named sections, 
which would be just a jump point for refinements: body: [copy [this 
is copy code] nocopy [this is nocopy code]] :-)

I got a copy but it was not useful for me.

He is slightly sloppy with his english, in a way that made me think 
it is not his first language.

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.

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.

this can be a big discussion... want to do so privately?

cause all I've read of the R3 engine, slim already handles a part 
from actual enforcing of the privacy.

it acutally does a lot more.

Not discarded, scheduled for a redesign. R2's FFI is really bad.

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.

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

rebol3 [ ] or using a 'needs ?

This is what I get when I try to upgrade on my Ubuntu 8.10 box:

>> upgrade
Fetching upgrade check ...

Script: "REBOL 3.0 Version Upgrade" Version: 1.0.0 Date: 7-Apr-2009
Checking for updates...

R3 current version: 2.100.54.4.2 
It was released on: 16-May-2009/22:45:17 

You need to update R3.
Download new release? yes
Downloading...
** Access error: protocol error: "Timeout"

** Note: use WHY? for more about this error

>> why?
Opening web browser...
Couldnt get a file descriptor referring to the console
>>

Have you tried downloading manually from the web site? There were 
problems in a53 with permissions. That would be a different error 
on Windows, buut who knows?

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

So, you're asking if the plugin model will still follow the initial 
stated base requirements for a plugin model? :)

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.

I don't understand your comment Brian. I am simply asking for R2 
DLL interface, but improved. I can understand that there is probably 
no need to introduce more than one way of how to interface external 
environment, but then I want R2 DLL like interface being a plugin. 
Of course, this capability is so basic though, that I want it inside 
of REBOL.exe

Brian: could such a "new evaluation model" help with something like 
rebcode replacement? :-)

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.

Of course that wouldn't be as good as actually writing a custom plugin 
for the DLL (or more likely using one that someone else wrote).

As for other blog - Objects as a base type ... is there any implication 
what it means for object semantics? IIRC you expected some changes 
in object semantics, but Carl states, that other types as ports, 
tasks, etc. share the implementation, so I wonder if you can really 
expect any change here?

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.

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

there is a better way to write that request: AT should support block 
directly as index.

yeah but that is a copy.

BACK TAIL series sets the position - the AT is a noop in your example.

BrianH, not if the AT specifies a different series than the BACK 
TAIL.

you can always use skip -n if you want to jump relatively in a series.

Wait a minute - Carl's method is simple things should be simple to 
do (STSBSTD).  A longer acronym.

You can write what you want.  It is just a placeholder for me to 
not suggest it again.

i think he wants AT working like COPY/PART (the index could be an 
integer or a serie aswell)

Well, if the index is a series offset, even a calculated one, then 
you can already have a reference to that offset without the AT.

Yeah I know but in this case if it has a navigational argument I 
was thinking it should.

I will in a few minutes.

http://www.rebol.net/r3blogs/0207.html- Should UNSET act as a value?

Having the copy operation when applied to a binary! return a binary! 
is an improvement of R3 over R2 already though :)

Because it's a bug.

A bug in PARSE.

hum ... yeah but that's a pain to have to switch betwin them

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

I've been waiting for this siince last year. I posted a comment about 
usage :)

He's aware of the value of chaining, but is wary of the "bug" reports 
he already gets about INSERT. Apparently there is some tiny amount 
of overhead too, which for a function as low-level as REDUCE might 
matter. "Penny wise, pound foolish" - I'm trying to convince him 
otherwise.

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.

See this line of code i do to rebuild a draw block in area-tc (it's 
called thousand times when the style is scrolled)


    out-style: insert insert insert insert insert insert insert insert 
    out-style
					'pen color/2 'fill-pen color/2 'box

     as-pair abs-x 7 as-pair (f/x * length? str) + abs-x 7 + f/y 3

Insane ;-)

it's slower than a reduce, but it's save memory, a lot.

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