r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

BrianH
18-Sep-2006
[1508]
APPLY would take refinements as positional arguments. That meant 
you would need to match the order of refinements in the declaration 
of the function you are calling, and that your function call would 
break if the function changed the order of its arguments - fragile. 
For some reason APPLY was slow too, and would crash REBOL if run 
too many times in a rebcode function.
Ladislav
18-Sep-2006
[1509x2]
ah, really? can you supply code for that?
function call would break if the function changed the order of its 
arguments - fragile
 I am afraid, that it is hard to find a less fragile spec, though
BrianH
18-Sep-2006
[1511x3]
Look back on the rebcode group. It was a standing problem. I was 
more concerned about it being slow as dirt though - the instability 
was likely to get fixed, but the slowness may be structural.
Can you get from a refinement to the word it is based on? Are refinements 
bound?
If so, you could pass along the refinements as keyword arguments 
in a REBOL version of APPLY.
Ladislav
18-Sep-2006
[1514]
Are refinements bound?
 - refinements are not bound usually
BrianH
18-Sep-2006
[1515]
Oh well, there goes one idea for a less fragile interface.
Ladislav
18-Sep-2006
[1516]
...but if you write f: func [/a] [/a 'a], then the /a refinement 
isn't bound, but the 'a *is*
BrianH
18-Sep-2006
[1517x2]
But if you write
    a: none
    apply :f [/a]

then the apply function can't tell that it should be passing the 
/a refinement as none.
If /a is not bound, I mean.
Ladislav
18-Sep-2006
[1519x2]
right, you would need to write apply :f [/a a]
(or something similar)
BrianH
18-Sep-2006
[1521]
Not bad really, but slower than positional arguments I suppose.
Ladislav
18-Sep-2006
[1522]
highly probable
Maxim
21-Sep-2006
[1523x2]
Regarding R3 tasks...
Will any thread be able to kill the main process?   or are we stuck 
like with python?
Gabriele
21-Sep-2006
[1525]
hmm, that depends on a lot of things. i'd say yes, but otoh there 
may be cases where that is not a good idea. it's to early to say 
anything about that, anyway.
Dockimbel
21-Sep-2006
[1526]
Gab, do you know if R3 threads are soft or native threads ?
Gabriele
21-Sep-2006
[1527x2]
native, at least that was the idea.
personally i somewhat prefer soft, but native has the advantage of 
making use of multiprocessor machines.
Maxim
21-Sep-2006
[1529]
I agree... and with dual cores becoming increasingly main stream... 
there is a definite advantage in that.
Gabriele
21-Sep-2006
[1530]
i don't know if it will be easy to use native threads across all 
platforms though.
Maxim
21-Sep-2006
[1531x2]
hehe if windows didnt design "kill a task" from inception... I can 
only imagine how well its threads must be implemented.  <sigh>
although they require very little RAM IIRC
Gabriele
21-Sep-2006
[1533x2]
unix is probably not that great on threads either, i think everyone 
is using their own variant.
there is a crossplatform library iirc, i hope it works :)
BrianH
21-Sep-2006
[1535x3]
Threads are actually done very well on Windows. They also have a 
fast shared-memory thread-like thing called fibers. It was only recently 
that some of the Unixes were able to catch up (except Solaris, which 
may be better).
Windows sucks at processes though.
(BTW, I meant that Solaris may have been better than Windows at threads 
already. Stupid English.)
PeterWood
21-Sep-2006
[1538x2]
Please refrain from calling we English stupid ;-)
Just teasing
Gabriele
22-Sep-2006
[1540x2]
brian, my fear is having differences across platform. the complexity 
can go up very easily, especially when there are platforms that support 
threads badly.
i hope that, as you say, most unixes have catched up at this point...
Pekr
22-Sep-2006
[1542x2]
then Carl should look for very small kernel to license, which solves 
that - e.g. QNX - it has 75KB kernel IIRC :-)
I really wonder, what R3 will be about - tasks (threads), new event 
system ... when thinking in cross-platform terms ...
BrianH
22-Sep-2006
[1544]
Linux and all of the commercial Unixes are good at threads now. I'm 
not familiar with the BSDs.
JaimeVargas
23-Sep-2006
[1545]
OpenBSD and FreeBSD have very good support for them. NetBSD is lagging 
behind. DragonFlyBSD has even better threading model.
Volker
26-Sep-2006
[1546x2]
http://www.plausible.org/nasal/

http://wiki.flightgear.org/flightgear_wiki/index.php?title=Nasal_scripting_language
Nasal - small, os-threads, used in flightgear.
Maybe the treading is usefull?
Ladislav
5-Oct-2006
[1548x2]
anybody able to find good  names for zero-based index series functions 
like variants of PICK, POKE, etc...?
(any other any zero-based indexing suggestions welcome)
Anton
5-Oct-2006
[1550]
peekus and pokus - more like ancient Latin language roots...
Ladislav
5-Oct-2006
[1551]
pokus
 means "trial" in Czech
Anton
5-Oct-2006
[1552x2]
zpeek, zpoke ?
Didn't we have this kind of discussion with rebcode ?
Tomc
5-Oct-2006
[1554]
cee caw
Anton
5-Oct-2006
[1555]
what's the logic behind that, Tom ?
Tomc
5-Oct-2006
[1556]
four days of fever and chills
that and c - zero based arrays
Ladislav
5-Oct-2006
[1557]
(the latest names are PICKZ and POKEZ, but I am not sure they are 
acceptable)