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

World: r3wp

[!REBOL3-OLD1]

BrianH
23-Apr-2009
[13426]
They could be initialized at first call. We already have facilities 
to do what you describe.
Ladislav
23-Apr-2009
[13427]
it simply does not make sense to me
Anton
23-Apr-2009
[13428]
(You mean *specifically* initialized, with the initialization block; 
they could be initialized to NONE..)
Ladislav
23-Apr-2009
[13429]
aha, during first call - how does the user find out which call is 
the first one?
BrianH
23-Apr-2009
[13430]
VALUE?
Anton
23-Apr-2009
[13431]
I agree with Ladislav, using conditional code (eg. using VALUE?) 
is kind of ugly.
BrianH
23-Apr-2009
[13432]
Actually, we are going to make a DEFAULT function, but that is one-value-at-a-time 
until DO/next works.
Ladislav
23-Apr-2009
[13433]
...the VALUE? looks inefficient and (IMO) not the proper way. Why 
should I check always something, that can be done properly just once?
BrianH
23-Apr-2009
[13434]
Remember that the user won't be specifying the init block most of 
the time, just the body. Internal code would specify the init.
Anton
23-Apr-2009
[13435]
You mean the init block would be built automatically from the body 
block?
BrianH
23-Apr-2009
[13436]
FUNCT and FUNCTOR are for defining handlers, though FUNCT is also 
used a lot in mezzanine code. The user would only specify the body 
block.
Ladislav
23-Apr-2009
[13437x2]
when I used a static local variable, I always initialized it at the 
function creation time using my Lfunc. I am sure I wouldn't touch 
a function with static locals not having proper initialization.
, but YMMV
BrianH
23-Apr-2009
[13439]
We can initialize them to NONE if you like, but having them be unset 
was deemed more valuable from a debugging standpoint.
Ladislav
23-Apr-2009
[13440]
well, I do not like NONE (debugging purposes) either
Anton
23-Apr-2009
[13441]
I see no fault with Ladislav's proposed init block.
BrianH
23-Apr-2009
[13442]
So far FUNCTOR hasn't really been used, so now is the time to change 
it if we are going to do so. The variable capture is a must though, 
since it will be used where the spec can't be specified by the user.
Anton
23-Apr-2009
[13443]
Oh, now I see what you meant about handlers.
Ladislav
23-Apr-2009
[13444x3]
yes, that can be used, but I suggest the uninitialized variables 
to be captured as dynamic, while the initialized be captured as static
does that make sense?
(I mean for your planned use)
BrianH
23-Apr-2009
[13447x2]
In general R3 is moving towards specifying handlers as code blocks 
passed to FUNCT or FUNCTOR with standard specs specified internally. 
This is their reason for existence.
BBL, have a meeting :)
Anton
23-Apr-2009
[13449x2]
So how would a user, when specifying a handler, which becomes the 
functor body, specify that a given variable is to be static, and 
that another variable is to be dynamic?
If FUNCTOR scans the given body block and treats all variables the 
same, then that control is lost by the user. Are we happy to lose 
that control?

Maybe FUNCTOR should have the initialization block like Ladislav 
suggests, and a more specific "handler-func" function be created 
for the specific handler use Brian is talking about?
Ladislav
23-Apr-2009
[13451]
if you are asking me, then the static variables may be captured from 
the INIT block, all other from the body, but it looks, that BrianH 
intended to have all variables static in a Functor, except for the 
variables from the SPEC block
Anton
23-Apr-2009
[13452x2]
Why couldn't the init block be inside the body block, in first position?
(.... maybe not such a good idea..)
Ladislav
23-Apr-2009
[13454]
yes, then it might be better to use the same approach as the MAKE 
funtion in R3 seems to use
Anton
23-Apr-2009
[13455]
I need to sleep on that...
[unknown: 5]
23-Apr-2009
[13456]
Ladislav, great to see you back!!!  Now, tell us where have you been 
and why gone so long?
BrianH
23-Apr-2009
[13457x4]
One thing to remember is that these function-building functions will 
be called a lot, so fast-and-simple is better than complex.
Ladislav, strangely enough there are also persistent words defined 
for the words in the spec, if they are set with set-words in the 
body. You can access them through self. It's just that the spec takes 
binding priority, so direct access to the words in the spec will 
be bound to the spec. There are many potential advantages to this, 
but the main reason this was done was speed.
FUNCT works well, but is too slow and has too much overhead. We already 
had to make one error go away to remove the screen for spec words 
overhead (see bug#717), but it still has the overhead of a temporary 
object which we haven't removed yet (see bug#544).


If you had FUNCTOR work the way you say, you would have to somehow 
distinguish words in the persistant object (as specified with init) 
from words that should be made into locals, which would add back 
the same overhead that the change referred to in bug#717 got rid 
of, as REBOL code. This would make FUNCTOR have much less performance 
than the equivalent code: CONTEXT [var1: 'blah ... SET 'func1 FUNC 
[...] [...]]
In general we are trying to deal with the problem in R2 where many 
functions were optimized away in high-performance code, so they end 
up being a waste of space. Many former mezzanines are now native, 
and many others are changed to make their overall usage more efficient. 
It's a balance.
Steeve
23-Apr-2009
[13461]
Currently,  i have a crash  when i start the chat with r3-a48 under 
Vista.
Obviously, i can't see what is the bug, 

And when i try with the previous version i got  (a42)
i got this error: 
--- Note: checking for new messages

*** RebDev Error: server connection failed, is server down? (server-failed)
** Script error: cause-error-here has no value

** Where: error if unless request-serve if check-msgs check-new make 
context do
catch applier do try chat
** Near: error result


We have no way to return in a safe situation and can't guess what 
is the bug indeed.


Is Carl aware of that problem, i didn't see anything related to a 
crash of a48 when starting the chat ?
BrianH
23-Apr-2009
[13462x2]
try again
It works for me. Does this happen every time?
Steeve
23-Apr-2009
[13464x6]
Not anymore, but it was like that during 1 hour at least
damit, i tried during one hour and just when you say: try again, 
it works....
i have very
i have a very bad connection currently, could it be related to some 
network errors bad managed by the http scheme ?
but a crash, geez....
it's violent
BrianH
23-Apr-2009
[13470x2]
The HTTP scheme needs a lot of work at the moment - it's a work in 
process. What is there already works great, but it's incomplete.
I think error handling is part on the incomplete part.
Steeve
23-Apr-2009
[13472x2]
yep but there is more than just a missing part in the error handling, 
it's crashing rebol, it's bad...
and i can't say why, there is no given reason
BrianH
23-Apr-2009
[13474]
I haven't had the chance to go over the scheme yet, and Gab and Maarten 
have been busy.
Pekr
24-Apr-2009
[13475]
New blog posted - http://www.rebol.net/r3blogs/0193.html- collect-words