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

World: r3wp

[!REBOL3]

Andreas
15-Nov-2010
[6168x3]
like snmp
or x.509, or ldap
and most likely some super complex healthcare standards do, which 
is where graham enters the picture :)
GrahamC
15-Nov-2010
[6171]
yeah ... the CDC uses OIDs for everything now
BrianH
15-Nov-2010
[6172]
So, sounds like a good idea for a community utility module :)
GrahamC
15-Nov-2010
[6173x2]
I had to get an OID for my medical app
so I can report anthrax cases :)
BrianH
15-Nov-2010
[6175]
Are they objectifying you at work, Graham?
GrahamC
15-Nov-2010
[6176]
this is object identifer programming
BrianH
15-Nov-2010
[6177]
Nevermind, bad pun :)
GrahamC
15-Nov-2010
[6178x3]
for instance , Y means yes according to the following code system 
2.16.840.1.113883.12.136
which is in the HL7 directory
If you want a free OID, you can apply for one from IANA http://pen.iana.org/pen/PenApplication.page
Pekr
15-Nov-2010
[6181]
IIRC OID is used for snmp (simple network management protocol), and 
this one is really big and important ...
GrahamC
15-Nov-2010
[6182]
As Andreas mentioned above.  MS also use them and I think might issue 
one to you as well.
GrahamC
16-Nov-2010
[6183]
Is this compatible with R3 http://www.yassl.com/yaSSL/Docs_FLOSS_Exception.html
Maxim
16-Nov-2010
[6184]
I think if used as an extension, it would be.
Ladislav
16-Nov-2010
[6185x7]
You can't have the words in functions lose their bindings once the 
function returns!
 - I demonstrated before that it is false
I am able to bind a block to a function even when the function is 
not running, so pretending that it is impossible is just that: pretending.
FYI: the MAKE function does it natively, and when the function is 
not running
Anybody can pretend whatever he likes to pretend, but I do not understand, 
why a blind faith is required from me.
You can't have the words in functions lose their bindings once the 
function returns

 - aha, sorry, I misunderstood, the fact, that I am not a native speaker 
 applied
What I wanted to demonstrate was, that:

block: [a]
g: closure [a] ['a]
f: func [a] ['a]
; this works
bind block g
; this does not work
bind block f
; but it can be replaced by this, doing what was requested:
change block f


, i.e. there is no reason why the operation should not work, except 
for the fact that somebody does not want me to do it (ineffectively, 
since I demonstrated, that it can be done anyway
Thus, a malicious user can do it, while, for a "good intent" it is 
"dead" because the workaround is slower than the native way
BrianH
16-Nov-2010
[6192]
I'm sure it was all a misunderstanding :)
Ladislav
16-Nov-2010
[6193]
you can't rebind because definitional binding depends on the order 
of binding operations

 - there are at least two things I do not understand in this sentence:

* "you can't rebind" - I am not trying to "rebind" above

* "because definitional binding depends on the order of binding operations" 
- sure it does, does that mean, that the BIND function should not 
work at all?
BrianH
16-Nov-2010
[6194]
It was a misunderstanding. Everything I said derived from something 
you said that sounded like you wanted function words to be unbound 
after the function ends. It is now clear that you don't. Ignore the 
rest.
Ladislav
16-Nov-2010
[6195]
Aha
Jerry
18-Nov-2010
[6196]
Anyone has JSON-to-REBOL code in R3? Thanks.
Gregg
18-Nov-2010
[6197]
I haven't tried the code on json.org under R3. Have you tried that?
Jerry
18-Nov-2010
[6198x2]
Gregg, I tried it. It won't work.
It's for R2 only.
Sunanda
18-Nov-2010
[6200]
It's a Core-only script, so the changes to create a version that 
runs under R3 (or even runs under R2 and R3) may be fairly simple.

Ladislav and I have both documented our early efforts to convert 
scripts. If someone does convert JSON.r, that may uncover other useful 
conversion guidelines.
   http://www.rebol.org/art-display-index.r?a=R3
Andreas
18-Nov-2010
[6201x3]
Hmm, I think I have a json.r adapted for R3 somewhere.
Let me check.
Nope, I was mistaken. Sorry.
BrianH
18-Nov-2010
[6204x4]
In theory, JSON-to-REBOL should be better in R3. The JSON and Javascript 
object type more closely corresponds to the map! type in R3 than 
it does to anything in R2.
map! with string keys, mind you. But map! won't show values assigned 
to none, so if you use map! you might want to use a 'null keyword 
instead of none for the null value. You could use object! instead, 
but then you would have problems with some keys not getting through 
TO-WORD's character restrictions.
I would guess that for most JSON data the string-to-word conversion 
would work, so you might get away with using object! in R3.
One thing will definitely be easier though: JSON and Javascript define 
that they have Unicode source, but don't have a way to specify the 
encoding (they are text standards, not binary). They can be handled 
easily in R3 once the source is converted to a string though, since 
that conversion will handle the encoding issues. In R2 you'd have 
to either stick to ASCII data or use Gabriele's text codecs and then 
parse the UTF-8.
Andreas
18-Nov-2010
[6208]
And of course you'll have to work around map! being case-insensitive.
Kaj
18-Nov-2010
[6209]
Hm, does that differ from hash!? I can do a find/case on a hash!
BrianH
18-Nov-2010
[6210x2]
Yes and no. It depends on whether the source of the dataset is also 
case-insensitive. The JSON standard doesn't specify one way or the 
other.
Kaj, map! is object-like, hash is series-like.
Kaj
18-Nov-2010
[6212x2]
That's a problem
I'm using hashes to cache directory contents. They need to be case 
sensitive to support Unix file systems. Now I have a problem with 
porting to R3
BrianH
18-Nov-2010
[6214]
Binary is treated case-sensitively. Convert the file names to binary.
Kaj
18-Nov-2010
[6215]
Cool, thanks
BrianH
18-Nov-2010
[6216]
The map! type is not a direct replacement for hash!, it is a different 
type that serves the standard purposes that hash! usually served 
in R2, where it was mostly used in the way that map! can be used 
now. As a related benefit, object! can also be used in ways that 
hash! used to be used: SELECT and APPEND work with object! and map!.
Kaj
18-Nov-2010
[6217]
Yeah, that's good. I never understood why R2 objects can't be expanded