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

World: r3wp

[!REBOL3-OLD1]

BrianH
17-Jul-2009
[16313]
For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.
Pekr
18-Jul-2009
[16314]
Debugging capabilites enchanced - track/back - http://www.rebol.net/r3blogs/0224.html
Graham
20-Jul-2009
[16315]
Will there be a way for R2 users to call the R3 dll and use it that 
way?
BrianH
20-Jul-2009
[16316]
In theory something like that could be possible, but it would run 
into the limits of R2's DLL wrapping support pretty hard. The official 
answer to that question continues to be REBOL/Services, once that 
is revamped.
Pekr
21-Jul-2009
[16317]
File Paths for Windows Servers - http://www.rebol.net/r3blogs/0225.html
BrianH
21-Jul-2009
[16318]
Glad to hear it, and look forward to finding out if you will be able 
to change-dir to those paths :)
Pekr
21-Jul-2009
[16319x2]
BrianH: is there any difference between R2 and R3 'call functions? 
I would like to test the boot time of R2 vs R3, and I thought I might 
use one REBOL process to call another one in a loop. I want test 
R3 vs R2 and R3 vs Rebbase. What methodology would you eventually 
suggest?
I don't want to go the way of installing and configuring Apache, 
and using some scripts to test throughput in real CGI scenario, as 
R3 CGI mode is not properly implemented yet ...
BrianH
21-Jul-2009
[16321x2]
At least not on non-posix platforms (Windows) from what I hear. REBOL 
CGI on posix systems (Linux, OS X) should work fine.
CALL has been completely rewritten in R3 - it has almost nothing 
in common with CALL in R2, and is much lower-level. If you want to 
compare the startup times, if you use the same method to call all 
of them you should have something comparable. R3's CALL doesn't wait 
for apps to return yet on Windows, so writing your wrapper script 
in R2 might be easier.
Pekr
22-Jul-2009
[16323x2]
BrianH: looking at tickets ... have we reached some positive point, 
where we fixed most of datatype conversion related tickets, and hence 
can move on ... to finally see the plugins released? :-) What can 
you see as the next logical priority to take? Or should we move to 
let's say networking? Networking is still not comparable to R2 - 
many protocols missing ....
Why is 'call limited in functionality in comparison to r2 version, 
and why also 'shift misses all its refinements?
BrianH
22-Jul-2009
[16325x3]
CALL is lower-level, and thus faster in theory, and easier to implement 
on different platforms which might not have all of the concepts in 
the old R2 CALL. SHIFT doesn't need any refinements, and is *much* 
faster without them. Refinement processing overhead is really significant, 
even for natives, so low-level math functions tend to not have them.
Datatype conversions: I think that once TO-HEX is removed for most 
datatypes the conversion issues of the TO-* set will be done. The 
rest will be handled by proper conversion functions, that we don't 
need to write immediately. We should probably wait on implementing 
those as natives until the APIs are worked out in REBOL versions, 
or plugin code. We can speed them up later once their behavior is 
agreed on.
As for what's next: Carl is working on finalizing the plugin model 
- apparently getting the decoupling right has been tricky. I am fixing 
module importing and making a semi-formal model for the module system, 
and working on R2/Forward. I have an idea on how to simplify the 
specification of port schemes - implementation of port schemes is 
already simplified - but the module stuff is stuck in my head so 
I have to work on it first. If someone else wants to work on protocols, 
go right on ahead, preferably the useful ones first :)
Rudolf
22-Jul-2009
[16328]
There are a few data making/conversion tickets pending (some classified 
as "problem"): 984, 1001, 1034, 1056, 1081, 1109,1110. They don't 
seem too difficult to me, but then again, I have no accesss to source 
code.
Henrik
22-Jul-2009
[16329]
Rudolf, can you set your user color slightly different? I can barely 
see your name. Thanks.
BrianH
22-Jul-2009
[16330x2]
984 is no longer a problem, but might be misguided. 1001 and 1056 
had one attempt to implement them that hasn't worked yet. 1081 is 
probably a bad idea (no offence intended, meijeru). 1109 and 1110 
are dependent on the result of the blog #222 discussion. 1034 is 
critical in the long run, but not as important in the short run.
Thanks for bringing up #984 - I had forgotten to remove the problem 
status when the problem was solved.
Henrik
22-Jul-2009
[16332]
hmm... immediate! and internal! typesets. I wonder what the first 
one is?
BrianH
22-Jul-2009
[16333x2]
My guess is that immediate! types are ones whose values fit within 
a value slot of a block or context, and thus are not reference types. 
I would put all of the numeric types including money! in that set, 
as well as date!, time!, tuple!, and event!. Most of the time gob! 
can fit in there too, afaict, as can error! with codes less than 
100.
I was requesting such a typeset for documentation purposes months 
ago.
Rudolf
22-Jul-2009
[16335]
Henrik, my copy of ALTME does not allow me to change my colors anymore 
(or I haven't found the trick).
Henrik
22-Jul-2009
[16336x2]
Robert, go to Home and Settings. There you can set your user color.
Rudolf, that is. :-) Sorry.
BrianH
22-Jul-2009
[16338]
Third icon from the right on the upper right of the screen. The "Your 
User Color" setting.
Rudolf
22-Jul-2009
[16339]
#984 is not solved, because mold/all still does not reproduce the 
header -- I accept fully that the value is not recoverable , but 
mold/all should preferably provide the information
BrianH
22-Jul-2009
[16340]
It is not solved, but it is no longer a problem.
Rudolf
22-Jul-2009
[16341]
I take that to mean that you know HOW to solve it, but haven't gotten 
around to it...
BrianH
22-Jul-2009
[16342]
Having "problem" status means that there is some (possibly temporary) 
reason it can't be solved at the moment. Then you look to the comments 
for why.
Rudolf
22-Jul-2009
[16343]
As to #1081, I merely pointed out the inconsistency, and did not 
advance a solution. The more inconsistencies, the more documentation 
is needed, and the more there is for the user to remember.
BrianH
22-Jul-2009
[16344x2]
As for why it might be misguided, that is because the stated purpose 
of that request - recovering the module in serialized form - is definitely 
impossible, and would be a major security hole if it were possible 
(which is part of why it is not).
Ah, you're meijeru, cool. Nice to chat with you :)
Rudolf
22-Jul-2009
[16346]
The system wouldn't let me make meijeru my username on Altme, even 
though I requested Altme membership through rebol.org where I also 
known as meijeru.
BrianH
22-Jul-2009
[16347]
The problem with getting rid of inconsistencies is when they are 
there for good reasons. In most cases you reported, they were not.
Rudolf
22-Jul-2009
[16348]
On modules again, I said already I accept the non-recoverability. 
But mold/all is there (also) for providing the fullest information 
about the value possible.
BrianH
22-Jul-2009
[16349]
Why don't you try the settings change for the user color...
Rudolf
22-Jul-2009
[16350]
How's that (black now)
BrianH
22-Jul-2009
[16351x2]
Cool. Back to modules, that is why the ticket was undismissed. It 
was only marked as a problem because one alpha temporarily made it 
even worse (later fixed).
Look at #1081 - Carl asked you a question that you didn't answer. 
Having no answer to that question is why it is still problem status.
Pekr
22-Jul-2009
[16353]
meijeru: dunno what rules here are. I always agreed that ppl should 
be able to choose their nick-name here, but some other had different 
opinion on that IIRC. But maybe we could ask for change, as you are 
here for short time yet ....
Rudolf
23-Jul-2009
[16354]
BrianH: I answered the question now -- for me, explicit specification 
has precedence over implicit specification.
BrianH
23-Jul-2009
[16355]
Thanks for that - now Carl can decide (this is in his purview).
Rudolf
23-Jul-2009
[16356]
Carl has announced the applicability of logical operators to type(set)s 
for a77. At first sight, this duplicates union ( ~ or) intersect 
(~ and) and difference (~ xor). Then again, both sets of operators 
are also defined on bitsets, so there is consistency in this duplication, 
and I suspect that typesets are really bitsets, internally. However, 
there is one extension: and/or/xor may have a single datatype for 
their second operand (also for their first???). This is not the case 
with union etc.
BrianH
23-Jul-2009
[16357x3]
Typesets are bitsets internally, but they are immediate types, while 
bitset! is a reference type. This puts an upper limit on the number 
of built-in types - based on the number of free bits in a value slot.
I think your assessment is accurate though.
There are some occasions where the behavior of an op! or action! 
is different depending on what datatype its first argument is. Actions 
dispatch based on the type of their first argument only, so making 
the behavior work with the types reversed might require double-dispatch 
to work. This is a similar situation to that of Smalltalk classes.
Pekr
24-Jul-2009
[16360]
hmm, it seems Carl did not succeed to resolve Plug-in interface, 
so we are getting some "simple method" ....
BrianH
24-Jul-2009
[16361]
It's also possible that excessive complexity was the problem that 
needed resolving, and the "simple method" is the solution :)
Pekr
25-Jul-2009
[16362]
yes. It is now at least clear, we will see soon :-)