AltME groups: search

Yeah I have never seen a need myself but its cool none the less. 
 Rather have a feature than not have it.

The APPLY discovery is bigger news, since that code injection trick 
is a real concern.

>> help apply
USAGE:
        APPLY func block /only

DESCRIPTION:
        Apply a function to a reduced block of arguments.
        APPLY is a native value.

ARGUMENTS:
        func -- Function to apply (any-function!)

        block -- Block of args, reduced first (unless /only) (block!)

REFINEMENTS:
        /only -- Use arg values as-is, do not reduce the block

>> a: func [b c][print b + c]
== make function! [[b c][print b + c]]

>> apply a [2 3]
** Script error: a is missing its c ar

No, your error is that you didn't pass a function, you passed the 
name of a function, without expecting it to evaluate. Try this:
    apply :a [2 3]

Apply takes a function, not a word. The func parameter is not a 'func 
lit-word! parameter.

But it is still a function

I'll put in a ticket to change the help string from "Function to 
apply" to "Function value to apply", just in case.

Brian, I'm not sure that value is a good term either - maybe others 
can comment.  I like to say spec.  As that makes more sense to me. 
 Newbies might think value means argument.  No matter how silly these 
 things seem - not everyone that is going to learn REBOL will have 
a programming background.

Brian .. some most certanly a crazy question ... is there a way you 
could walk/execute a block of code in steps ... this is probably 
possible (if they take no arguments)  [ func-1 func-2 func-3 ] ... 
but is there some "magic" way to execute make func consume their 
arguments, like this >> b: [ print "hello" add 4 6 ]<< and >>do get-expr 
b 1<< would print "hello" and >>do get-expr b 2<< would calcualate 
10 ... I know this is probably not even remotely possible

Yes, DO/next. But it doesn't work in R3 yet, just R2. That is a bug, 
btw.

what is a bug?

aha... I was scared do/next is a bug :)

LOAD was rewritten too, as a mezzanine, by me. There is still some 
missing functionality, and some fixes to bugs in R2's LOAD.

I am trying the do/next .. I can execute first expression but then 
I am a little lost of what to *do next* ( hehe)... >> b: copy [ empty? 
"" empty? "a" ]     do/next b == [true [empty " "]] <<  I tried >> 
b: next do/next b <<

so code is a code block and value is something that has a result 
that code block would return if I do it at the end ?

I mean the whole block .. (in a loop)

I thought I will ask a very very stupid question and it turns out 
this is very nicely possible already

Yes, but watch out: If there is a function call, the *whole* call 
gets executed, even if it is long. Your granularity of preemption 
of your manual multithreading is going to be pretty coarse.

basically I don't have the full picture, it's just awesome that something 
like this can be done inside a language itself

yes, it looks like that .. I will try to make a simple step-blocks 
function and see what it does

if you would want to switch you could also step until you hit a certain 
word probably and then switch to other funct

Sorry, meant Protothreads: fake threading done with macros and special 
tricks. A C version: http://www.sics.se/~adam/pt/

these things are very interesting to me but I am a little

Aren't we all "a little", sometimes :)

my "I am a little" was meant to be "unknowledgable on lower level 
things"

They were used to implement Contiki, a multitasking embedded OS that 
runs on computers of Commodore 64-level capabilities.

I made a simple paralel block executor .. not sure if it can be used 
for anything but it's interesting to see it work

Well, I mostly play with mezzanine and library code and backports, 
then generate a *ton* of bugs and wishes in CureCode about fixes 
for or enhancements of natives. Because I tend to be public with 
my work, that's what you see. Carl is mostly working on the new DevBase 
right now (and possibly articles and interviews). Once the new DevBase 
is up and running the source will be posted to it, then we can all 
work on stuff.

Add file management to RebDev and you have the new DevBase. "RebDev" 
was always a codeword - the real name is DevBase.

you have to create a name first (command: name)

My rank is high enough, but I don't think the commands work yet. 
There wasn't even a public decision on whether the file tree would 
be seperate or integrated with the message tree.

i think it will be mixed, reading the source, i guess than a file 
can be attached to a an header or to a name msg

The trick with FIND-ALL is that it doesn't reeturn anything - it 
executes a code block wioth each find.

Then I think the name is misleading. Or will there be a FIND/ALL?

That could be, or as a step argument to FOR.

(who says step must be a constant?)

This kind of function is usually easier to implement as a mezzanine.

Steeve, I know. You can do everything with PARSE in only 10 times 
as much code as with a single mezz. :-)

QUOTE is a Peta special, a simple function to perform a nasty trick 
in as little code as possible. It blocks evalation :)

; R3 version
quote: func [
	"Returns the value passed to it without evaluation."
	:value [any-type!]
] [
	:value
]

; R2 version
quote: func [
	"Returns the value passed to it without evaluation."
	:value [any-type!]
] [
	get/any 'value
]

I'm checking a thesaurus.

BrianH, check #1804, for a GATHER function that does something else.

That sounds like a better function to call GATHER. ACCUMULATE will 
get called less than that.

ASSEMBLE might be a nice word to reserve.

Could be disturbing for beginners, a same thing can be writed  using 
so many various ways with the tons of mezz we have now.

Steeve, you have a point. For a couple of years, I would write mezzanines 
for things that already existed in R2, but hadn't noticed.

Mezzanine-quality version of Henrik's GATHER, R3 version:

gather: func [
	"Get the values of a given field from all objects in a block."
	block [block!]
	word [word!]

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	forall block [
		all [
			object? block/1
			in block/1 word
			output: insert/only output select block/1 word
		]
	]
	either into [output] [head output]
]

>> a: make function! [spec] [body]

** Script error: cannot MAKE/TO function! from: function!

** Where: make

** Near: make function! [spec] [body]

>> my-func: make function! [[b] [print b]
]
== make function! [[b][print b]]

FOREACH does a BIND/copy of its code block, but you might have a 
point in this case because the 3 paths are N*3.

Final submitted R3 version:

gather: func [

 "Get the values of a given field from all objects in a block that 
 have it."
	block [block!] "A block which may contain objects"
	word [word!] "The field to look for"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	foreach item block [all [
		object? :item
		in item word
		output: insert/only output select item word
	]]
	either into [output] [head output]
]

Henrik, if you can write up a CureCode wish for this function I can 
mark it as pending.

Write up a descriptive request, explaining why you need it, or reference 
your R3 chat message number.

If we don't have a record of why the function was added we won't 
know where to puut it when we modularize R3.

Curecode needs a trigger for rebdev links.

Here's the R2 version of GATHER:

gather: func [

 "Get the values of a given field from all objects in a block that 
 have it."
	block [block!] "A block which may contain objects"
	word [word!] "The field to look for"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	foreach item block [all [
		object? get/any 'item
		in item word
		output: insert/only output get/any in item word
	]]
	either into [output] [head output]
]

Do you want a /deep option?

for me it makes the most sense to gather values from a particular 
level.

I think there is merit for a cookbook recipe which briefly describes 
a table of all block manipulation functions, or we have a way in 
HELP to relate these functions, so they become very visible to beginners. 
The problem is that beginners are not likely to be looking for them, 
because they don't expect them to be there. They were created by 
experienced users who have been coding REBOL for years.

will there be something like mezz fold/reduce function for r3? I 
would use it a lot

Would you need a /reverse option? ACCUMULATE is already almost as 
fast as we can make it in REBOL, and more options would slow it down. 
The only way we could speed it up more now is to fix an APPLY bug 
with op! functions.

This group needs more abstraction.  The group is turned into mainly 
an R3 mezzanine group.  Should we have a different group for that? 
 Originally, I thought this would be about how R3  is developing 
  more along the native level.

I think it is a good idea Pekr.

I was just wondering, it there is someone else "who know the internals"... 
I know that Cyphre is waiting for new sources from Carl to do something. 
And of course it's good to have a place where one can write message 
to Carl and with a feeling, that Carl will read it one day.

Right now Carl is busy getting things in place to get the source 
out. Then we can discuss native changes that *don't* affect core 
code. We have already been discussing native changes that *do* affect 
core code, here and in R3 chat, a lot lately :)

hi, i would like to know if carl have a rebol3-db for us within R3 
 like the very good rebDB http://www.dobeash.com/rebdb.html?

until we have a odbc plugin. we need a good diskbased datastore in 
R3

If you look inside devbase you can see kind of DB there, but finally 
it should be a Module with methods, or Protocol with functions both 
simple and for general use IMHO.

a good demo In My Humble Opinion, will be a CRUD example application 
full R3

I've just been reading a little about something called Unobtrusive 
Javascript which aims to separate the behavior from the structure 
of html document.  


Doesn't VID suffer with the same problems where behavior is closely 
tied to the structure of the GUI?  And shouldn't we be looking at 
also solving this problem?

It should be pretty easy to write a function that maps an ACTIONS 
block such as the following into a window:

	actions: [
		my-text-list [
			do [set-face ... ]
			"other-event" [ blah blah..]
		]
	]

But I know what you're saying. You probably want such a function 
built in and used in the examples, so it becomes commonplace.

Maybe there could be a stylize type of way to deal with actions

yes just like a html page

Why?  If there's a tab order ... then there must be a serial structure

Or, as you say, a tab could be inserted/removed.

But I need to overlay a busy graphic which I can then remove ...

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.

We could combine both approaches. In the ACTIONS section, if there's 
a word followed by a block, then the word is the name reference to 
the element (eg. 'my-text-list), but if there is just a block, then 
the next element is taken anonymously.

Yes, that could make some confusion. Specifying empty brackets [ 
] could act as a "ignore this element".

Just thinking, should the actions section be specified in a block 
? eg:

view [
	; Structure
	my-text-list: text-list

	; ACTIONS
	actions [
		my-text-list [ ... ]
	]
]

Hmm. Using SKIP would be like using GOTO. The trouble it's trying 
to avoid is having lots of dummy empty brackets, of course - a noble 
goal.

It would be better to simply use a name-reference (keeping in mind 
that these are now, in Rebol 3,  local to the window context), for 
jumping across a (possibly varying, during code maintenance) number 
of empty action placeholders.

Perhaps lit-words could be used to indicate that it's a type, eg:

	actions [

  'text-list [ set-face ... ]  ; <-- Action for all text-lists in the 
  window.
	]

(Ugh... the sight of hard-coded numbers make me a bit queasy...)

I think it makes things harder, at least for a short while. After 
that I cannot see...

I think other aspects of a program could be more important, at other 
times, or simply at different places in the code. :-/

so, say you had a number of text-lists that all had the same event 
handler, you just define it once instead of 3 times

It's a form of code factoring.

inline syntax prevents the registration of more than one event handler 
for the element's onchange event

 - we don't have this problem in rebol. It looks like they are working 
 around a problem in html inline javascript specification.

Well, I think it can pretty easily be done for your own forms, by 
making a function that accepts an action specification, as above. 
Apply it to your forms and that's that. Eg. if you could say:

	window: layout [ ...text-list ... ]
	set-behaviours window [ text-list [...] ]
	view window


Wouldn't that be almost as good (if not better) than any built-in 
inline action specification ?

I think that your talk here is a little bit late for VID3, as it 
seems to me (according to docs), that those things were already decided 
...

I am sorry for my extreme oppinion on this subject but I think "unobtrusive 
javascript" was invented when web2.0 got hip and cool and when web 
designers started coding. To me as a user it meant that basecamp 
blocked my whole browser (even the mouse pointer didn't move) on 
every page reload for 1-2 seconds (while js was attaching events 
to all the nodes).

J: I'm not sure that's fair - UJS addresses many problems faced confronting 
a very complex development environment to perform even elementary 
manipulation (see also Progressive Enhancement/Graceful Degradation). 
 At that, the three sites you cite are neither examples of UJS or 
PE/GD, nor typical examples of usage.

No problem , I said I have a little exptreme oppinion on this, and 
extreme opninons are usually not correct ;) . But I think "unobtrusive 
javascript" is an extreme option too, I believe that eingeeners have 
to find fastest, cheapest, most robust and mainainable solutions 
that *work the best* for their problem. But something like UJS is 
a label or an ideal that you can hold to in your work and more you 
hold to it better you are from this ideal's viewpoint, but I like 
to be more flexible. I will adhere to it or only so far as I think 
it get the best coctail from the 5 points I mentioned above.

I think the web is a special case though.  I don't think there is 
any other environment where language interpretation varies so widely, 
and where binding the language can have harmful effects.  Yes, heady 
concepts are not always pragmatic, but the short road to pragmatism 
on the web is fraught with pitfalls.

G&A: I'd like separation too - in the long run, it makes for code 
that is easier to adapt and maintain, and allows you to refine language 
around the individual components

First, I think JS is not something we should look at for models. 
It's new enought that it is just going to reinvent what's been done 
before, unless they come up with something truly revolutionary, and 
my gut feeling says that's not going to happen. It also depends on 
what kind of apps you're writing, and what you want the language 
to hide from you.


What's been done before that works, or not?  MVC has seen a resurgence 
with RoR and other frameworks being built on it. 


Now look at a low level approach, where you handle the main event 
loop yourself. Anyone remember writing C programs for Windows early 
on? Maybe some still do. You had a huge switch statement to dispatch. 
On the downside, that was hideous to read and maintain. A benefit, 
though, was that you could hook into it very easily, because it wasn't 
spread throughout the app.

Then there's the whole VB/event-driven model.


R2+VID is wonderful for very simple things, because you don't have 
much to do, actions are right there with their faces, etc. It starts 
getting in the way when you build larger apps that need to track 
relationships between faces and such. And it is not well-suited to 
large apps, just like REBOL itself. It doesn't provide the organization, 
tools, and features needed. Of course, we can build all that ourselves, 
if we have the inclination. RebGUI is the best example of that.

I like the idea of apps based on FSMs and message dispatch. That 
means simple apps aren't nearly as simple anymore, but it gives you 
the tools to build bigger things. It's also a different way of thinking, 
which can be hard to get people to accept. 


Anyway, rather than asking if UJS is the right model, we first need 
to ask what our goals are.

If you have a one screen application, it doesn't matter how you write 
it.  If you have over 300 screens as I do, then you look at ways 
it might be more easily maintained.

Gregg, JS is a few years older than REBOL.

Not really, ask Henrik. I'm a Core guy.