probe/dump-binary survey
[1/14] from: greggirwin:mindspring at: 2-May-2004 11:23
Jaime et al
JV> Greg, I think your suggestion that probe should produce output
JV> similar to dump-bin by default is great. I hope Carl goes for it.
For those who don't know, I posted this idea on an AltME world for
comment.
For those who want to express an opinion on the matter, there are two
scripts below; one for Core, and one for View. All they will send to
me is your answer -- how strongly you agree that PROBE should produce
output like dump-bin, given a binary! value. I'll collect the results
and pass them on to RT.
Thanks!
-- Gregg
; Core Version
address: head reverse [moc--gnirpsdnim--niwriggerg]
reply: func [data] [
print "^/Sending response..."
send address rejoin [data]
print "^/Thanks!"
]
reply ask {
Enter YES or NO (case insensitive) if you feel
strongly one way or the other, or a value between
0 and 1 to indicate agreement (0 = no, 1 = yes,
..5 = don't care).
Should PROBE produce output like Jaime's DUMP-BIN
function? }
; View Version
address: head reverse [moc--gnirpsdnim--niwriggerg]
reply: func [data /local wnd] [
h/text: "Sending response..." show h
send address rejoin [data]
h/text: "Thanks!" show h
]
view layout [
h: h3 as-is {Should PROBE produce output
like Jaime's DUMP-BIN function?}
text as-is {(Select an answer or set the slider value
and click Send)}
across
text "NO!" [reply 'no] tab
text "don't care" [reply .5] tab
text "YES!" [reply 'yes]
return
answer: slider 210x16
return
across
button "Send" [reply answer/data]
;button "Quit" [quit]
]
[2/14] from: antonr:lexicon at: 3-May-2004 4:45
Please consider that molded code should be able to be
loaded back by rebol. So I say no.
I have no real objection to including dump-bin named as is
though.
Anton.
[3/14] from: rotenca:telvia:it at: 2-May-2004 23:50
Hi,
> Please consider that molded code should be able to be
> loaded back by rebol. So I say no.
I agree.
Could be an help service.
---
Ciao
Romano
[4/14] from: greggirwin:mindspring at: 2-May-2004 18:13
Hi Anton,
AR> Please consider that molded code should be able to be
AR> loaded back by rebol. So I say no.
AR> I have no real objection to including dump-bin named as is
AR> though.
Are you saying that because that's how PROBE currently works
(i.e. the molded result is exactly what is displayed)? We wouldn't
be affecting molded code in general, only what PROBE prints out. The
value given to PROBE would be returned just as it is today.
It's important to think of all these things though, so thanks very
much for commenting!
-- Gregg
[5/14] from: moliad:aei:ca at: 3-May-2004 4:38
nope, no go... just like probe on an object! does not do a dump-obj.
especially since we often insert a probe within a line to get status at that
moment, like just before an assignment... dump-bin would break that behaviour.
dump-obj as a function is cool though, so it should be included :-)
-MAx
[6/14] from: moliad:aei:ca at: 3-May-2004 4:47
> Are you saying that because that's how PROBE currently works
> (i.e. the molded result is exactly what is displayed)? We wouldn't
> be affecting molded code in general, only what PROBE prints out. The
> value given to PROBE would be returned just as it is today.
that would make probe a little obsure ... probe is meant to show what the code
is ... internally. If you want to make a datatype based format print or probe,
then user should just implement this:
dprobe: func [data][
switch/defsault type?/word [
object! [dump-obj data data]
binary! [dump-binary data data]
;--- add you favorite datatypes here--- :-)
][
probe data data
]
]
its so easy to do that there is no point in obfuscating probe IMHO...
-MAx
[7/14] from: greggirwin:mindspring at: 3-May-2004 3:54
Hi Max,
MOA> especially since we often insert a probe within a line to get
MOA> status at that moment, like just before an assignment... dump-bin
MOA> would break that behaviour.
It shouldn't, unless I'm missing something. What it displays and what
it returns are two different things.
MOA> that would make probe a little obsure ... probe is meant to show
MOA> what the code is ... internally.
This is interesting. I've always thought of PROBE as "show me the
value" where the inlining aspect was the big benefit, but that it
didn't add as much as it could for certain types of values (e.g.
binary! and bitset!). That is, I thought in terms of "show me the
value in a way that is most informative to me." A molded object spec
is just that, as are many values they way they are returned. A date!
displayed as fields/values for each possible refinement would be more
verbose and less useful than a plain molded date.
MOA> If you want to make a datatype based format print or probe, then
MOA> user should just implement this:
MOA> dprobe: func [data][...
I would probably call that one DUMP. :) Having a single wrapper for
all datatypes would be a good thing in any case, and I think we also
need to have a way to see the values as PROBE returns them today
(inlining it can be a big benefit after all).
What about a refinement on PROBE that makes it produce DUMPed output?
-- Gregg
[8/14] from: andreas:bolka:gmx at: 3-May-2004 16:36
Monday, May 3, 2004, 11:54:45 AM, Gregg wrote:
> This is interesting. I've always thought of PROBE as "show me the
> value" where the inlining aspect was the big benefit, but that it
> didn't add as much as it could for certain types of values (e.g.
> binary! and bitset!).
that's interesting indeed ;) different mindsets :)
i'd strongly urge for 'probe to be not modified for exactly the same
reasons anton, romano and maxim have expressed before.
i see probe as a way to inspect data and be able to immediately use
the probe's output (e.g. feed the probe'd data back into a REBOL
console).
> What about a refinement on PROBE that makes it produce DUMPed
> output?
no problem with that ;) however i don't how the refinement would
produce a benefit compared to adding just another function (named
dump, for example :)
--
Best regards,
Andreas
[9/14] from: antonr:lexicon at: 4-May-2004 0:46
Gregg, I'd like probe to remain the simple function
that it is. Something beautiful about it.
(I think, because there is nowhere for bugs to hide
in there..:)
Anton.
[10/14] from: antonr:lexicon at: 4-May-2004 0:44
I was thinking the dump-bin output could be made
loadable again, therefore achieving orthogonality:
what can be molded can also be loaded.
The output could be changed like so:
dump-bin to-binary "abc"
make binary! #{6162 63} ; 0000: abc
dump-bin to-binary "all the king's horses and all the king's men"
make binary! rejoin [
#{616c 6c20 7468 6520 6b69 6e67 2773 2068} ; 0000: all.the.king.s.h
#{6f72 7365 7320 616e 6420 616c 6c20 7468} ; 0001: orses.and.all.th
#{6520 6b69 6e67 2773 206d 656e} ; 0002: e.king.s.men
]
Maybe some other tricks to get more syntax out of it,
and get the line numbers back to the left...
Anton.
[11/14] from: greggirwin:mindspring at: 3-May-2004 15:23
Hi Anton, Andreas, et al
AR> I'd like probe to remain the simple function
AR> that it is. Something beautiful about it.
I agree that simple is beautiful; if we can simplify all the code
that uses this functionality, even at the expense of a little added
complexity inside, that's a gain IMO. Of course, it's all a balancing
act to find out what we think will be best.
So, here's PROBE today:
probe: func [
{Prints a molded, unevaluated value and returns the same value.}
value
][
print mold :value :value
]
And here's what it might look like with a /dump refinement:
probe: func [
{Prints a molded, unevaluated value and returns the same value.}
value
/dump "Display data in non-molded format"
/local fn
][
either not dump [print mold :value][
fn: switch/default type?/word :value [
object! [
either attempt ['face = value/type] [:dump-face] [:dump-obj]
]
binary! [:dump-bin]
;function! [:dump-func]
;bitset! [:dump-bitset]
][:probe]
]
fn :value
:value
]
The complexity jump is quite large. :(
Any other candidate host functions that map to this functionality?
GI> What about a refinement on PROBE that makes it produce DUMPed
GI> output?
AB> no problem with that ;) however i don't how the refinement would
AB> produce a benefit compared to adding just another function (named
AB> dump, for example :)
Ahhh, this is a really good question, which came up during the
development of the ROUND function for View 1.3. Should it be separate
functions for each type of rounding, or a single function with
refinements? In the end, we went with the latter because the function
itself gives you context.
* If you type HELP ROUND, you instantly see all the options
in one place
* It's a way to group things
* It means less to learn because once they find PROBE they've
already found DUMP
* You don't have to add extra docs in each one saying how they
differ, you just doc the refinement that tells how it changes
the behavior.
I'm not trying to defend the idea here, just rambling. It's not always
appropriate, and it can be misused of course, but I think there's a
lot of leverage to be applied with refinements. They do make it much
more important that you choose your words well and wisely though.
-- Gregg
[12/14] from: nitsch-lists::netcologne::de at: 4-May-2004 4:48
On Montag, 3. Mai 2004 23:23, Gregg Irwin wrote:
> Hi Anton, Andreas, et al
>
> Any other candidate host functions that map to this functionality?
>
> GI> What about a refinement on PROBE that makes it produce DUMPed
> GI> output?
>
probe/dump - longer to type. when i debug i want it short. even shorter than
probe. ?? most of the time. How about a name similar to that? but 'dump would
work.
> * It means less to learn because once they find PROBE they've
> already found DUMP
>
how about:
help probe ->>
Prints a molded, unevaluated value and returns the same value. similar: ? ??
dump
Also
!>>help dump
Found these words:
dump-face function! Print face info for entire pane. (for debugging)
dump-obj function! Returns a block of information about an object.
dump-pane function! Print face info for entire pane. (for debugging)
there is a convention to call such functions dump-*. that the integrator is
called 'dump makes sense.
> * You don't have to add extra docs in each one saying how they
> differ, you just doc the refinement that tells how it changes
> the behavior.
>
that can be done with a naming-convention too. because "help round-" would do
a "wildcard-search". In case of 'round i prefer refinements. In case of 'dump
i would prefer lots of dump-* and dump with a switch. because then its most
easy to add new dumpers. We could even have some support to add new dumpers
on the fly, like
add-dump ['my-type = val/type][dump-my-type]
Now instead of "send" i could not resist to press "hack", and here is:
;the code
dumpers: copy[]
add-dump: func[guard dump-how][
insert dumpers reduce[guard dump-how]
]
dump: func[val][
bind dumpers 'val
foreach[guard dump-how] dumpers [
if attempt guard [attempt dump-how break]
]
:val
]
add-dump [true][probe val]
;demo, dumping an object smart
ctx: context[type: 'my-type id: 1 lots-of-data: [1 2 3]]
dump 1
dump ctx
add-dump ['my-type = val/type][
print ["my-type" val/id "has" length? val/lots-of-data "elements"]
]
dump 1
dump ctx
;demo-output
;first unsmart
1
make object! [
type: 'my-type
id: 1
lots-of-data: [1 2 3]
]
;now smarter
1
my-type 1 has 3 elements
> -- Gregg
-Volker
[13/14] from: andreas:bolka:gmx at: 4-May-2004 15:31
Tuesday, May 4, 2004, 4:48:10 AM, Volker wrote:
> Now instead of "send" i could not resist to press "hack", and here
> is:
thanks for sharing!
i found it exciting that this piece of code uses loads of typical
REBOL idioms - i.e. it can be considered a piece of REBOL wizardry :)
> ;the code
> dumpers: copy[]
<<quoted lines omitted: 29>>
> 1
> my-type 1 has 3 elements
--
Best regards,
Andreas
[14/14] from: maximo:meteorstudios at: 4-May-2004 11:59
> how about:
> help probe ->>
> "Prints a molded, unevaluated value and returns the same
> value. similar: ? ??
> dump"
YESS A "RELATED:" or "SEE ALSO:" WOULD BE SOOOOO USEFULL IN ALL RT Function defs.
AND A CLASSIFICATION ID TOO ... like in the ref-words doc where there the words are split
up/sorted in different related domains.
then you could do help/topic series
and get a list of 30 words, all related to series...
> there is a convention to call such functions dump-*. that the
> integrator is
> called 'dump makes sense.
yess!!! my opinion too.
> > * You don't have to add extra docs in each one saying how they
> > differ, you just doc the refinement that tells how it changes
<<quoted lines omitted: 3>>
> round-" would do
> a "wildcard-search". In case of 'round i prefer refinements.
because all the different operations are related... me too
> Now instead of "send" i could not resist to press "hack", and here is:
>
> ;the code
[...]
cool stuff :-)
-MAx
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted